Phase 9 merged partial. Items 1 and 2 of #179 are now done — porch-driver reaches production
as a real dependency and thread-backend.ts installs the spawn factory before
chooseSpawnPath — which is exactly what made items 3 and 4 untestable before. They are now
runnable and have simply never been run.
This is the gate on phase 10. Phase 10 is "full protocol on a second driver", and "second"
presumes a first driver works in production. Items 3 and 4 are that premise. Until they pass,
phase 10's premise is unverified and the rest of spec 146 is built on an assumption.
Scope — these two only
Item 3: "An architect is a thread whose worktree is the workspace root."
Not true in production at the time of filing. Prove it in production, not against an in-memory
engine.
Item 4: "An architect thread survives a server restart and resumes with context."
Untested. Restart the server, not the client, and show the thread resumes carrying context —
not merely that it reconnects. A reconnect that loses context is a failure of this criterion, and
it must not be reported the same way as a pass.
Explicitly NOT in scope. Item 5 is met (air-180). Item 6 (one architect + six builders,
measured) and item 7 (/arch-save exercised) stay held by the architect: fleet RSS is 2.4 GB
with one builder, and the only architect in this workspace is the one running the program. Do
not attempt either.
The server is already up
Started and verified by the architect before filing:
$ T3_NODE=/opt/homebrew/bin/node node tools/t3-server/t3-server.mjs start
[t3-server] verified: /Users/chris/dev/t3code is clean at 082e6ea52186 (2026-08-25)
[t3-server] started pid 33389
[t3-server] runtime: Node 26.4.0; pinned CLI: t3@0.0.36
$ … ready
[t3-server] ready on 127.0.0.1:3799; pairing token present
{ "port": 3799, "token": "XKYGXPF8GKAR" }
T3_NODE must be set to an absolute interpreter path. The harness refuses to inherit its
server Node from PATH, on purpose, and says NO_INTERPRETER: could not check rather than
guessing. Node 26.4.0 is outside t3code's engines.node ^24.13.1 and the harness emits an
advisory and continues, because server readiness is the gate rather than the declared range.
Re-verify the pin yourself before trusting any of the above — status reports matchesPin.
How results must be reported
A criterion is met when it was observed, not when a test that would have observed it ran
green. Report what you saw. If either criterion cannot be exercised, say that it could not be
exercised and why — that outcome must not share a signal with "it failed", and neither may share
one with "it passed". This repo has been bitten three times in one day by a check reporting a
value it was not positioned to observe (#214, #216, #217).
Record the outcome in codev/projects/146-codev-client-on-the-t3code-ser/ alongside the existing
146-phase_9-verification.md, and update #179 with what is now met.
Phase 9 merged partial. Items 1 and 2 of #179 are now done —
porch-driverreaches productionas a real dependency and
thread-backend.tsinstalls the spawn factory beforechooseSpawnPath— which is exactly what made items 3 and 4 untestable before. They are nowrunnable and have simply never been run.
This is the gate on phase 10. Phase 10 is "full protocol on a second driver", and "second"
presumes a first driver works in production. Items 3 and 4 are that premise. Until they pass,
phase 10's premise is unverified and the rest of spec 146 is built on an assumption.
Scope — these two only
Item 3: "An architect is a thread whose worktree is the workspace root."
Not true in production at the time of filing. Prove it in production, not against an in-memory
engine.
Item 4: "An architect thread survives a server restart and resumes with context."
Untested. Restart the server, not the client, and show the thread resumes carrying context —
not merely that it reconnects. A reconnect that loses context is a failure of this criterion, and
it must not be reported the same way as a pass.
Explicitly NOT in scope. Item 5 is met (air-180). Item 6 (one architect + six builders,
measured) and item 7 (
/arch-saveexercised) stay held by the architect: fleet RSS is 2.4 GBwith one builder, and the only architect in this workspace is the one running the program. Do
not attempt either.
The server is already up
Started and verified by the architect before filing:
T3_NODEmust be set to an absolute interpreter path. The harness refuses to inherit itsserver Node from
PATH, on purpose, and saysNO_INTERPRETER: could not checkrather thanguessing. Node 26.4.0 is outside t3code's
engines.node ^24.13.1and the harness emits anadvisory and continues, because server readiness is the gate rather than the declared range.
Re-verify the pin yourself before trusting any of the above —
statusreportsmatchesPin.How results must be reported
A criterion is met when it was observed, not when a test that would have observed it ran
green. Report what you saw. If either criterion cannot be exercised, say that it could not be
exercised and why — that outcome must not share a signal with "it failed", and neither may share
one with "it passed". This repo has been bitten three times in one day by a check reporting a
value it was not positioned to observe (#214, #216, #217).
Record the outcome in
codev/projects/146-codev-client-on-the-t3code-ser/alongside the existing146-phase_9-verification.md, and update #179 with what is now met.