Lesson 17 — React data ownership and the first Task workspace

Outcome

Use the desktop app to create/list/open a Task and start the Fake Adapter while seeing bounded live status/activity.

Why this comes now

This is the first moment Forge becomes something you can actually use. The goal is not visual polish; it is validating state ownership and workflow.

Understand

TanStack Query owns authoritative core/server data. Zustand is only ephemeral presentation state such as selected pane or sidebar width. A command mutation can show “accepted/pending” without pretending an external Operation already succeeded.

Start with Task List + Task Workspace, not Kanban. The Task workspace is where we will later add review, plans, decisions, and activity.

Build the real project

1. Add generated client/query layer.
2. Build Project/Task list and Task detail route.
3. Add create Task + criteria form.
4. Add state actions through command RPCs.
5. Start fake work through a real core command.
6. Display Task state, Operation/start status, Run/Turn state, and a small live activity list.
7. Add clear error and degraded/starting states.
8. Keep server data out of global Zustand.

Completion gate

Manual acceptance: create a Task, make Ready, Start, watch fake work, close/reopen and find persisted Task state. Frontend tests cover at least the main route and mutation states.

Pitfalls to avoid

Do not build drag-and-drop Board first. Do not duplicate Task state in a client store and manually keep it in sync. Do not render raw protocol history as the activity UI.

References

TanStack Query, TanStack Router, Zustand, SCREEN_BUILD_ORDER.md.

Checkpoint

M6 is complete when you can use Fake Forge through the desktop without touching the CLI harness for the happy path.