Build a Server Action form with real validation, not a client fetch call in disguise

You are building a form wired directly to a Next.js Server Action, not a client component that calls preventDefault and fetches an API route from inside an onSubmit handler. The form element's action prop points at a function marked 'use server', and pending/error state comes from useActionState and useFormStatus, not hand-rolled useState.

FORM FIELDS
title (text, required, max 120 chars), dueDate (date, optional), assigneeId (select, required)

MUTATION
Creates a new task row scoped to the current project and the signed-in user's workspace

VALIDATION LIBRARY
Zod

SUCCESS AND FAILURE BEHAVIOR
On success, clear the form and show the new task at the top of the list without a page reload; on failure, keep whatever was typed and show the specific field error inline.

EXISTING CLIENT-SIDE VALIDATION
A simple required-field check already runs on blur in the browser, mostly for instant feedback while typing.

BUILD RULES
Validate the submitted FormData against a schema inside the Server Action itself, every time, regardless of whatever validation already runs client-side — a Server Action is a callable server endpoint that can be invoked directly, bypassing the form component entirely, so client-side validation alone is not validation, it is a UX nicety layered on top of a server boundary that must enforce the real rule on its own. Return field-level errors from the action in the shape useActionState expects — a small object keyed by field name — so each input can render its own error message next to itself, rather than one generic banner at the top of the form that leaves the user guessing which field actually failed. After a successful mutation, call revalidatePath or revalidateTag for whatever page or cached data this action affects, inside the action itself, so the UI reflects the change on its own without the client having to trigger a manual refetch afterward. Read pending state with useFormStatus inside a separate child component nested under the form — never in the same component that renders the form element itself, since useFormStatus only returns real pending status when called from a descendant of the form it is tracking, and returns default, always-false values everywhere else, a bug that a quick manual click-test will not catch because the developer usually only tests the one render path they happened to write. Do not add useOptimistic unless the interface genuinely needs to show a result before the server confirms it; if it does not, say so explicitly and leave it out rather than adding it because the API happens to be available and looks like the more modern choice. Keep the JavaScript-disabled path working: since this is a real HTML form submission through a 'use server' action, do not add a preventDefault call or a manual fetch anywhere in the flow, because that silently reintroduces the exact client-fetch pattern this build is meant to replace, and defeats the progressive-enhancement guarantee the action prop provides for free the moment it's used correctly.

OUTPUT FORMAT
Two code blocks: the Server Action file, including its validation and its fully typed return shape, and the form component using useActionState alongside its separate submit-button child component using useFormStatus. Close with one line stating exactly what gets revalidated on success, named by path or tag rather than described vaguely.