Spec 146 phase 11: codev-client tree and live status

[pseudoseed]

Spec 146 phase 11. This is the first phase of the initiative that produces something a human can
look at. Phases 1-9 are plumbing: the contract, the transport, the driver, delivery semantics,
the state service, approvals, security, thread identity, and afx parity. All of that is on main
and none of it is visible. This phase is the payoff, and it should be treated as the priority it
is.

The plan section is reproduced below verbatim so it is not fetched by path.

---

Phase 11: codev-client tree and live status

Dependencies: Phase 6, Phase 7, Phase 9

Objective

The left sidebar tree: machine, workspace, architects, that architect's builders, with correct live
status on every row — including a builder blocked on a gate showing #128's structured question, not
only a gate name. Multi-machine and honest degradation land here too, because a tree that cannot
say "disconnected" is worse than no tree.

The stack matches apps/v2: React 19, Vite 6, Vitest 4, Playwright.

Files to Create / Modify

• apps/client/package.json, vite.config.ts, tsconfig.json
• apps/client/src/tree/ — the workspace tree.
• apps/client/src/connection/ — per-machine connection, one per server.
• apps/client/src/status/ — row status derivation.
• apps/client/src/gate/ — structured gate rendering and approval.
• apps/client/e2e/

Deliverables

• The tree renders machine, workspace, architects, and each architect's builders.
• Every row carries live status: working, turning, blocked on a named gate, or settled.
• A blocked builder shows its structured question and choices without navigation, and is
  visually distinct from a settled one. A gate name alone does not satisfy this.
• Where porch and t3code disagree, porch wins and the client shows porch's value. Titles,
  pins and activity entries are display projections, never a source of truth.
• A thread with no porch record renders as unmanaged, not hidden.
• One client connects to more than one machine's server at once, each independently live.
• With one server stopped, its subtree is marked disconnected with a last-updated
  timestamp, other machines stay live, and nothing renders blank or silently stale.
• A human approves a real gate from the client through Phase 6's capability path.
• No dangerouslySetInnerHTML on agent output; a restrictive CSP; explicit origin rules. The
  client holds credentials for N servers, which makes XSS a credential-theft path rather than a
  defacement one.
• Tests for this phase.

Acceptance Criteria

• Criterion 3: correct live status on every row including the structured gate content.
• Criterion 7: two machines in one tree, independently live.
• Criterion 8: one server stopped, subtree disconnected with a timestamp, others unaffected.
• Criterion 9b: a real gate approved from the client, with session id, machine and timestamp in
  status.yaml.
• Criterion 15's scenario: revoking one machine's token fails that subtree closed and leaves
  others unaffected.
• A grep asserts no dangerouslySetInnerHTML in the app.
• Build and tests pass.

Test Plan

Unit and component: status derivation for every state; the porch-wins reconciliation; disconnected
rendering.

E2E under Playwright against two live servers: both trees correct, one stopped, the subtree marked,
a gate approved.

---

---

Architect notes

Dependencies are satisfied. Phase 6 (agent-farm/lib/approval-capability.ts) and phase 7
(agent-farm/lib/machine-credentials.ts) are on main. Phase 9 is on main partial — items
3 and 4 of #179 (an architect thread in production; a thread surviving a server restart with
context) are being run under #219 in parallel with this work. Nothing in phase 11 blocks on them.

The stack matches apps/v2: React 19, Vite 6, Vitest 4, Playwright. Follow that app's
conventions rather than inventing new ones.

A green test suite cannot detect design infidelity. This repo has shipped a client that passed
127 client tests, 3,394 server tests and 15/15 Playwright with correct tokens and correct colour
discipline, and was unusable — it had dropped every label prefix, the header bar, and rendered
idle sparklines as invisible dots (#112). Component tests that assert "the name renders" pass
happily while the thing that made the name legible is gone. Open the running client and look at
it before you call any of this done.

A pinned t3 server is already running on 127.0.0.1:3799 at commit 082e6ea52186, started
with T3_NODE=/opt/homebrew/bin/node node tools/t3-server/t3-server.mjs start. T3_NODE must be
an absolute interpreter path; the harness refuses to inherit its Node from PATH and reports
NO_INTERPRETER: could not check rather than guessing. Re-verify the pin yourself with status.

The two-server criteria need a second server. Criterion 7 (two machines in one tree) and
criterion 8 (one stopped, its subtree disconnected with a timestamp) cannot be satisfied against a
single server, and a single-server approximation of them is not evidence. Work out how to stand up
the second instance early rather than at the end.

On honest degradation, which is the deliverable most easily faked. "Disconnected" must be
distinguishable from "connected and idle" and from "connected and empty". A subtree that renders
blank, or renders its last known state without saying when that state is from, has failed
criterion 8 regardless of what the test asserts. This repo's standing rule is that "I could not
tell" must never be spelled the same way as "no" — three separate defects of exactly that shape
landed in one day (#214, #216, #217). The last-updated timestamp is what makes the difference
observable, so it is not decoration.

Where porch and t3code disagree, porch wins. Titles, pins and activity entries from t3code are
display projections, never a source of truth.