[Spec 250] t3code is the front end: nested Workspace > Architect > Builders, porch gates, and approval from t3code

[pseudoseed]

Closes #250. Refs #146.

t3code is now the front end for Codev. Workspace → Architect → Builders renders as a tree in
t3code's own web app, porch gates render as their own thing rather than being smuggled into thread
titles, six builders tile at 1440x900 and seven tile 4x2 at 1920, and a gate can be approved from t3code over a same-origin proxy
with porch recording the session, machine and timestamp.

This PR is codev-side only. The customization itself lives in a private fork,
pseudoseed/t3code@codev, pinned at 2f64a1b0ee2b. What lands here is the harness that vendors it:
the pin, the regenerated contract, 33 exported patches, the tools, and the tests.

106 commits carry [Spec 250]; the rest of the branch's ~170 are porch bookkeeping
(chore(porch): ...). 11 plan phases, builder/spir-250. GitHub's own header is the live count of
commits and files — the figures here are the shape of the work, not a checksum of the branch.

What a human can see or do now

	Where
An architect and its builders as a nested tree, with the project as a heading	t3code sidebar
Two architects in one workspace as two subtrees, each owning its builders	t3code sidebar
A gated builder's gate name, #128's question and its choices	gate panel above the composer
Six builders at 1440x900, seven tiling 4x2 at 1920	/codev-builders
Approving a gate without leaving t3code	gate panel → porch status.yaml

Two blocking defects the review found, and what changed

The codex lane reviewed the finished PR after claude and opencode had approved it, and found two
things eleven rounds had not. Both are fixed here; the fork commit is 2f64a1b0e.

The approval path had no answer for a dead network. send in apps/web/src/codev/approval.ts
awaited fetch bare, and four of its five call sites had no catch; GateApproval.tsx had a
finally and no catch. A proxy disconnect while opening the session, issuing the capability,
minting the nonce, or taking the synchronous fallback stopped the spinner and produced nothing —
no error, no unconfirmed state. On the approval surface that is indistinguishable from having
pressed nothing, and the builder does not advance either way.

It survived every earlier round because the file's outcome vocabulary is careful — four outcomes,
unconfirmed kept apart from refusal in five places — and nobody asked what happens when fetch
itself rejects. A rich taxonomy of answers is not the same as answering.

send now returns transport failure as a value, ({reached:true} & Json) | {reached:false, error},
so the compiler asks at all five call sites. The outcomes are deliberately different: the three
pre-submit steps report a definite AGENT_UNREACHABLE_* because nothing was submitted and the
gate provably did not move, while both submit routes report unconfirmed because the request
may have arrived and only the reply been lost. Six tests, one per outcome; restoring the throw fails
all six, by rejection.

The proxy buffered the upstream response with no limit — the same defect as the request-body
bound fixed during phase 10, on the return path, where the bytes come from configuration rather than
from an authenticated caller. MAX_PROXIED_RESPONSE_BYTES at 1 MiB, a new oversized outcome that
is neither unreachable nor a truncated answered, and an upstream abort. The first version of the
fix settled after destroy(), which emits error synchronously — so it reported a reachable host
as unreachable until the test caught it.

Criteria 6 and 9 are unchanged: codex is right that a runbook is not acceptance evidence, and this
body says so below rather than claiming otherwise.

Acceptance

10 of 11 criteria met. Criterion 6 is UNMET and says why. Criterion 9 is met under the plan's
amended reading and not under a literal one. Full table with per-criterion evidence in
codev/resources/250-acceptance-evidence.md; the numbers in it are regenerated from the runs by
tools/t3-server/collect-spec-250-evidence.mjs, not typed.

Criterion 9 wants reading before you accept it. Its wording asks for a clean rebase and a
shape-check on the rebased tree. One of those is now run and one is not.

Regeneration is proved. The generator runs to completion against the rebased tree and the
regenerated contract is compared byte for byte to what is vendored here: schema.json, schema.ts
and types.d.ts all move. generate.mjs refuses any checkout whose HEAD is not pin.commit, so
this happens in a second throwaway — git merge-tree gives the merged tree an identity inside the
scratch clone, and a scratch copy of the codegen tool reads a scratch pin naming it. The guard is
satisfied rather than bypassed, and the real pin.json is neither read nor written.

The rebase does not complete cleanly. It stops at commit 6, which the plan states is the
result the drill exists to produce, not a failure. The plan's phase 11 amendment settles the rest:
criterion 9 is met by the procedure completing and reporting. The evidence document sets the four
clauses against what was actually run so the reading is yours, not inferred.

Criterion 6 needs an iPad on the tailnet and no device was available. It closes unmet with an
executable 16-step runbook (codev/resources/250-ipad-acceptance-runbook.md), not as passed and not
left open. The Playwright suite is not recorded as a substitute: it drives the same proxy in a
desktop browser, so it covers the approval path, and covers neither tailnet reach nor touch targets.

Runs behind the table:

• 32 Playwright tests against t3code's real web app, at the pinned fork head
• 8 vitest e2e through the real fork server's proxy
• 7396 + 180 codev tests, 58 skipped, 0 failed
• fork: 2984 web, 2873 server, typecheck clean

Reviewing this

Start with tools/t3-fork/FORK.md — every fork commit, the rebase risk table with measured beside
predicted, and a "do not tidy these" section covering two deliberate anti-rebase-debt choices.

codev/reviews/250-t3code-front-end-customization.md carries the retrospective — spec compliance
per criterion, deviations, and the disposition of every consultation finding across 21 review rounds
(20 implementation, 1 plan) — over the per-phase findings log it was written as, which is kept below it unmodified.

The agy/Gemini lane produced no output for this project. It is recorded as absent from every
round rather than as an approval; Claude and opencode ran on every phase, plus codex on the plan.

The rebase drill (tools/t3-fork/rebase-drill.mjs) is worth a look on its own: it measures the
rebase job against a live upstream 104 commits ahead, in a throwaway clone, and discards its own
result if either real checkout moved. A sequential rebase stops at commit 6, the whole conflict
surface is 3 files of the 35 we modify, 4 of the 9 contract-closure files come out of the merge with
different bytes, and the contract regenerated from that tree moves 3 shape artifacts.

Its header carries the reasoning for each of those choices, including two versions of one defect it
was itself caught in: a documented outcome no code assigned, and a measurement that would have
compared the fork to itself had it been taken one line later.

Known state, stated rather than waved at

• apps/client is kept as the fallback and frozen. Nothing from phases 7-10 is backported. One
  test fix landed (a session-status enum moved _6→_7 when the contract was regenerated in phase
  5), because a fallback whose suite is red is not a fallback. Gap filed as The frozen fallback client's suite runs only in CI: root npm test filters to @cluesmith/codev #265: root npm test
  filters to @cluesmith/codev, so nothing local runs it.
• apps/server/src/entrypoint.test.ts > matches through a symlinked entrypoint fails in the
  fork. Pre-existing, byte-identical to the base commit, macOS /var → /private/var. Not
  skipped and not modified.
• A page-level CSP for t3code is not done. Recorded as a follow-up in the plan; the same-origin
  proxy already gives the guarantee structurally.
• The proxy's idle timeout does not bound a trickling upstream. Stated in agentProxy.ts rather
  than closed: a total-duration bound would have to fit the slowest legitimate answer, and the
  origin allowlist narrows the threat to the operator's own hosts.
• SAFETY: a gate-approval notification crosses workspaces and can tell a builder its gate was approved when it was not #264 is filed and not fixed here. porch approve sends the bare project id as the afx send
  target and the recipient is tail-matched with leading zeros stripped, so a gate approval can reach
  a same-tailed project in another workspace. Folding it in would put an unrelated change in this
  PR.

Migrations

Codev's two columns stay out of upstream's numbered migration registry, via
apps/server/src/codev/schemaGuard.ts rather than a migration. FORK.md says why. The drill
re-checked the watermark against a real new upstream migration: upstream added 043, above the
042 our base leaves, so it runs.

🤖 Generated with Claude Code

[pseudoseed]

3-way integration review

Lane	Verdict
claude	APPROVE (HIGH)
codex (gpt-5.6-sol)	REQUEST_CHANGES (HIGH)
opencode	COMMENT (HIGH)

Note on how this was reviewed. The first attempt produced nothing: gh pr diff returns HTTP
406 over GitHub's 20,000-line API cap and all three lanes refused with "produced a 0-byte diff —
refusing to run a review on nothing." That refusal is the only reason this was reviewed at all
rather than assumed. Re-run with --base main, which computes the diff locally. Filed as #267.

Two blocking, both from codex, both real

1. Pre-submit network failures escape as rejected promises — on the approval path

approval.ts:102-123 does not catch fetch, and GateApproval.tsx:95-130 has only a finally.
So a proxy disconnect during session creation, capability issuance, nonce minting or the
synchronous fallback gives the user no error and no unconfirmed state.

This is the defect class this project has spent 11 phases eliminating, landing on the highest-stakes
surface in the product. A gate approval that silently does nothing is worse than one that fails
loudly: the human believes they approved and the builder never advances, and nothing anywhere says
which happened.

Wanted: an explicit named outcome for each pre-submit failure, and a test per outcome.

2. The proxy bounds request bodies and not responses

agentProxy.ts:469-478 buffers the upstream response with no limit. You found and fixed the
unbounded request-body buffer before review; this is the same defect on the return path. A faulty
or compromised configured agent exhausts server memory. Bound it and abort the upstream response
when exceeded.

Not changes — my rulings, already disclosed in the body

• Criterion 6 unmet. Codex is right that a runbook is not acceptance evidence, and the PR says
  exactly that. No iPad was available. It ships unmet with a reason, which is the honest outcome.
• Criterion 9 met under the amended reading. The amendment is recorded in the plan with my
  ruling behind it: the drill runs on a throwaway clone and the real pin does not advance, because
  moving it makes every spec 146 and 236 result untestable. The body tabulates the literal gap
  rather than claiming the literal reading. That is disclosure, not a change to make.

Follow-up, do not fix here

Claude's point, and it pairs with #265: the vendored contract now sources from a private repo, and
40 e2e tests live permanently outside CI. Both are "the only thing that proves this works runs
nowhere automated." File it.

Also noted: arch-critical.md is at its 10-fact cap, so the next hot-tier addition needs an
explicit demotion.

Verified myself rather than read

• pseudoseed/t3code — visibility=PRIVATE, isFork=false
• /Users/chris/dev/t3code — HEAD 082e6ea52186, clean tree
• pin.json — both identities present, contractSource: fork