Essential session storage is required to sign in. Optional analytics remain off unless you allow them.
Build a task or notes app where Server Components read from a real datastore and SERVER ACTIONS ('use server') handle create/update/delete. Forms must work via `<form action={...}>` with progressive enhancement, validate input INSIDE the action, and use revalidatePath or updateTag so the UI reflects a mutation immediately. Add useActionState/useFormStatus pending UI, a loading.tsx, and an error.tsx boundary. Be explicit about cache policy and use revalidateTag only with a current profile when stale-while-revalidate is intended.
Mutations run as 'use server' actions invoked from forms; revalidatePath/updateTag behavior matches the consistency goal; input is validated server-side.
Reads happen in Server Components; caching/revalidation is intentional and correct for Next 15 defaults (no accidental stale or uncached data).
Pending UI (useActionState/useFormStatus), a loading.tsx fallback, and an error.tsx boundary that isolates failures.
The action authenticates/authorizes and validates input; no trust in client-supplied IDs; no secrets leaked to the client.
Use this README structure to make the work reviewable.
DevPath fetches a read-only, size-capped snapshot. Submitted code is never executed.
# A full-stack CRUD app with Server Actions
## Goal
Build a task or notes app where Server Components read from a real datastore and SERVER ACTIONS ('use server') handle create/update/delete. Forms must work via `<form action={...}>` with progressive enhancement, validate input INSIDE the action, and use revalidatePath or updateTag so the UI reflects a mutation immediately. Add useActionState/useFormStatus pending UI, a loading.tsx, and an error.tsx boundary. Be explicit about cache policy and use revalidateTag only with a current profile when stale-while-revalidate is intended.
## Acceptance criteria
- [ ] Server Actions & mutations: Mutations run as 'use server' actions invoked from forms; revalidatePath/updateTag behavior matches the consistency goal; input is validated server-side.
- [ ] Data & caching: Reads happen in Server Components; caching/revalidation is intentional and correct for Next 15 defaults (no accidental stale or uncached data).
- [ ] UX states: Pending UI (useActionState/useFormStatus), a loading.tsx fallback, and an error.tsx boundary that isolates failures.
- [ ] Security: The action authenticates/authorizes and validates input; no trust in client-supplied IDs; no secrets leaked to the client.
## Verification
- [ ] Document installation and run commands.
- [ ] Record automated checks and their exact commands.
- [ ] Add representative output, screenshots, or a short demo where useful.
- [ ] Confirm failure paths and known constraints.
## Decision log
### Decision title
- Context:
- Choice:
- Alternatives considered:
- Tradeoffs:
## Evidence
- Link each rubric criterion to the file, test, or artifact that demonstrates it.
## Known limitations
- List what is intentionally out of scope and what should be improved next.