docs(client): plan 706, the view tier as a pattern

[halcwb]

Implementation plan for #706.

Deferred is the client's view tier, undeclared: derived by toDeferred, read only by the pages, and Provisional carries a value each lane chooses for itself. The plan names the view tier as a DU per lane whose cases are the states a page can be in, states the five tiers of client state and the rule that a command is built in a Settled arm only, and schedules the Session, Signing and plain-fetch applications as follow-ups.

The code steps start after plan 646 step 4 (Seeded deleted, the domain Patient in the machines); the plan does not wait.

Questions for review are in the doc: the case names, decision c here or apart, the plain-fetch case here or apart.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K9K57bmde8G9rfreSMKZ6L

[greptile-apps]

Confidence Score: 5/5

The documentation-only PR appears safe to merge, with both previously reported concerns resolved.

Summary

This PR documents the planned introduction of explicit per-lane view-state discriminated unions for the client.

• Defines five client-state tiers and their ownership boundaries.
• Plans migration from Deferred projections to OrderContextView and OrderPlanView.
• Clarifies that plan 646 step 4 is a prerequisite.
• Accounts for every remaining Deferred.inProgress caller before deleting the helper.
• Defers Session, Signing, plain-fetch refresh behavior, and component-local state cleanup to follow-up work.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  D[Domain state<br/>Workbench or Cart] --> V[Pure view projection]
  C[Communication state<br/>InFlight] --> V
  S[Stored view fields<br/>Selection] --> V
  V --> U[Lane-specific view DU]
  U --> P[Pages through AppEnv]
  P -->|Commands only from Settled| M[Machine composer]
  M --> D
  M --> C

Loading

_{Reviews (2) · Last reviewed commit: "docs(client): plan 706 names the inProgr..."}