Spec 146 phase 10: full protocol on a second driver

[pseudoseed]

Spec 146 phase 10. Its premise is now true rather than assumed, which is why it was held and why
it is unblocked.

Phase 10 is "full protocol on a second driver", and "second" presumes a first driver works in
production. It did not. #179 items 3 and 4 established it live tonight (PR #221, merged as
e241326a1), and item 3 was not merely unrun — createArchitectThread sent branch: '', which
t3code refuses as NullOr(TrimmedNonEmptyString), so no architect thread could ever have been
created against a real server while every in-memory test passed.

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

---

Phase 10: Full protocol on a second driver

Dependencies: Phase 9

Objective

Run a complete protocol end to end with no PTY involved, on two provider drivers, and start the
24-hour gate clock that Phase 14 depends on.

Only Codex was exercised in the spike. Success criterion 10 requires a second driver before
deletion, and this phase is where a driver-specific failure surfaces while it is still cheap.

Files to Create / Modify

• packages/porch-driver/__tests__/full-protocol.test.ts
• packages/porch-driver/src/drivers/ — per-driver quirks, if any are found.
• codev/research/146-driver-parity.md
• codev/research/146-long-gate-evidence.md

Deliverables

• A complete BUGFIX protocol on a t3code thread: spawn, phases, checks between turns, a gate
  that pauses at least one hour, PR, merge. No PTY code path runs, asserted rather than
  assumed.
• Porch restarts mid-protocol, resubscribes with afterSequence, and loses no completion
  event.
• The same run on a second, non-Codex driver. Any behavioural difference is recorded in
  146-driver-parity.md rather than worked around silently.
• The 24-hour gate test is started in this phase and its evidence recorded when it
  completes. It gates Phase 13, so it must be running well before Phase 13 begins; starting it
  here is the only way the schedule works.
• Tests for this phase.

Acceptance Criteria

• Criterion 1 passes on two drivers.
• Criterion 2 passes: restart mid-protocol, no lost completion.
• A one-hour gate resumes with context on both drivers.
• The 24-hour gate run is started and its start recorded.
• Build and tests pass.

Test Plan

Integration, long-running, against a live server. The one-hour and 24-hour gates are elapsed for
real; a fake clock does not test what the reaper does.

---

---

What phase 9 actually left you — read the PR before starting

#221 is 22+ defects across ten review rounds. Its verification doc and PR body are the map of
this seam. The ones that shape your work:

• The engine registry is keyed by canonical workspace root, and the unkeyed slot is NOT a fallback
  in either direction. A keyed read that missed and then took the unkeyed one restores a
  cross-workspace misroute one indirection further away. Tower drains mail for every workspace from
  one process; a turn dispatched to the wrong server succeeds.
• Nothing on MailboxDrainer.tick may be awaited. The tick is sequential across agents, so any
  await there stalls delivery for every agent in every workspace including PTY-only ones. The
  synchronous requestThreadBackend, returning a state union rather than a promise, is the pattern.
  ensureThreadBackendReady is CLI-only.
• A mailbox row's intent carries its row id (ref) and recovery replays only that intent, under
  its own command id. Two earlier attempts were wrong in ways worth not repeating: matching on
  message text let duplicate text recover a stale intent, and draining the whole journal replayed
  siblings' intents so they duplicated one agent over.
• --no-enter is terminally refused on threads — thread.turn.start IS the submit, so there is
  no composer to stage into. Porch gate notifications use --no-enter, so a thread-backed architect
  receives no gate notice.
• afx interrupt and afx cleanup still throw on the thread path (Thread path: a process-global spawn factory in Tower, interrupt/cleanup still broken, and two smaller seams #227). The init-plus-attach
  shape in deliverToThread is the template; do not let each command grow its own copy.

Live harness

tools/t3-server/t3-server.mjs — acquire, verify, start, restart, ready, stop,
status. 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. restart
preserves the data dir; start wipes it, and NO_DATA_TO_KEEP exits UNDETERMINED so "nothing to
preserve" cannot read as a pass or a failure. The live test takes T3_LIVE_HARNESS /
T3_LIVE_MODEL, so a criterion about threads can be run under any driver — it is not a claim about
a provider.

Standing rules for this program

"I could not tell" must never be spelled the same way as "no." Reference implementations now in
the tree: found | none | unknown (project lookup), known: false only on spawn error or non-empty
stderr (lsof — the exit code alone cannot separate "nothing is listening" from "I could not run
the check"), UNDETERMINED as its own exit, and UNCONFIRMED as a client band distinct from refused.

A green suite is evidence only about what it ran. Name which suites exist and which files each
covers before quoting one. Five exist.

Assert the mutation applied before trusting what it proves. A mutation check that silently
no-ops produces a passing test, which looks exactly like the guard working.

Write what makes a claim true, or write the limit. Four comments in #221 asserted guarantees the
code did not provide, and two independent reviewers went straight to them. The corrected form now in
the tree: argv heuristic, not proof of parentage.

Not in scope

#179 items 6 and 7 remain held by the architect and unticked: the concurrency measurement (fleet RSS
was 2.4 GB with one builder) and the /arch-save runbook (the only architect here is the one running
the program). Do not attempt either.