RFC: T3 Code as the restaurant: one front of house for every kitchen

Status: draft for owner review · 2026-11-02 · fork-local (kvnloo/t3code). Nothing upstream until each piece goes through the gate.
Pieces: the UX wave (#57, with #48–#65) is the dining-room layer of this RFC, not the whole plan.
Evidence: data/operations/t3code-system-rfc/20261102/: audits/A-upstream.md, B-failures.md, C-reuse.md, C-graph.{md,json} (277 nodes / 542 edges), corpus/ (fork threads plus about 450 upstream threads with full comments). Upstream refs are written as plain numbers.

1. Why

On 2026-10-23 you decided: "let's just use t3code to manage everything — it acts as the restaurant that manages all the harnesses." (I couldn't confirm that Theo said the metaphor first; the X search was out of credits. It is your sentence in the record.) The OSS factory already uses the same frame: a Michelin kitchen where every station has one job.

Since then, most recurring failures happened because several systems each tried to be the restaurant: z0bridge identity, Dash notifications, phone loops, Kerdoios capacity, custom import timers. Each one adds a snapshot another layer has to read, and none of them is the default path. Measured today (B-failures.md):

2. The model

Rules (from your corrections):

1. One owner per concern. No second pairing layer, no second memory owner, no second OOM writer.
2. Built-ins first. T3 ships 1,695 commits beyond your 0.1.2. Use them before building anything.
3. Fix the generic door, not one kitchen. Theo answers "support harness X" with "use ACP" (upstream 6814, 6786), so every T3 ask is framed as a fix to the ACP path.
4. Small. No new planes, daemons or stores. If a layer needs a new service, it's wrong.

3. Layers

Each layer lists what T3 already does, what we change, and what stays outside.

L0. Open the doors: update off 0.1.2

• Do: update to stable v0.1.6 (or nightly). Re-check fix(acp): failed turns hide the real cause behind "Internal error" / "Failed to open … provider session" #58, Agent-started thread stuck in Plan mode on Android while Runtime says Full access #61, Android: native render errors, low-memory exits, and inline WebView taps blanking the feed #62 and Desktop/CLI setup friction found while setting up groot + MBP #64 on it before reporting anything (upstream's own triage playbook §6).
• Gains: 28419 (ACP exit code/signal in the error item), managed policy providers.allowedDrivers (replaces hand-editing settings to stop Codex/Claude launching, Desktop/CLI setup friction found while setting up groot + MBP #64.6), linked environments (delegate to MBP), guest links, t3 triage, Working section, t3 service protect.
• Cost: MCP tool names changed (25423), so agent prompts written for 0.1.2 tool names need a pass.
• Acceptance: t3 --version ≥ 0.1.6 on groot and MBP; Desktop/CLI setup friction found while setting up groot + MBP #64 re-checked.

L1. Kitchen door: ACP fidelity for Hermes (and every ACP agent)

Most of the dining-room P0s are really door problems.

Acceptance: a live Hermes turn on ≥0.1.6 shows effort control, inline renders, Working while children run, and a readable cause when it fails.

L2. Expediter: continuity without side loops

Your memory canon records that side loops, crons and self-wake promises failed every night. T3 has two primitives that do fire: scheduled tasks (server-side, bound to a thread) and wake on child completion.

• Do: one scheduled expediter tick per active project (e.g. every 30–60 min) with a fixed prompt: read finished child tasks, re-run their gates (or read the outcome ledger's tests_failed), harvest phone-lane returns, then report or re-dispatch. That is the whole "overnight" mechanism; delete ad-hoc self-wake promises.
• Do: every delegation brief ends with a verifier step. A child's completed is a claim (523 counterexamples).
• Owner decision D1: the memory canon says overnight runs go only through Hermes /goal. Either T3 scheduled ticks become the backstop, or /goal stays and ticks are daytime only. Don't run both.
• Acceptance: an overnight window with per-hour tick receipts in the thread and zero claimed_success-with-red-tests results reported as success.

L3. Stations: put agent threads where the capacity is

• T3 does: load balancing places new agent threads on the MBP when it runs a T3 server (prefer MBP, groot manual-only); linked environments let a groot parent delegate to MBP.
• Fix outside T3 (.files, one change): fleet-health must fail open and notify. A probe bug currently removes the only worker for days.
• Owner decision D2, the single memory/OOM owner: T3 launches agents into its own app-t3code-agents-* slice (caps exist in code but are infinity live), and t3 service protect writes oom_score_adj. That conflicts with fix(agents,k3s): harness survives child OOM; one memory owner; k3s reserves host budgets .files#79 (one memory owner) and fix(oom): never kill agent roots; one guard owns kill order .files#104 (one oom writer). Recommendation: .files stays the owner; configure or neutralize T3's slice caps and don't enable service protect.
• Stays outside: builds and tests (fleet-build / Kueue), GPU, phones. T3 balancing ignores disk and heat and never moves running threads.

L4. Purchasing: route by budget using T3's data

• Do: burn-pace reads Claude/Codex windows from T3 Usage (already ingested) instead of its own probes; launchers read orchestrator_capabilities as the live model catalog (kills the 212 unsupported_model runs); the expediter tick passes the burn-pace posture into delegate_task provider choice (today: prefer Claude, avoid Codex).
• Fix the rot, don't add a plane: P0: e2e trace — stop per-turn process spawn, missing Kerdoios interpreter, Groq quota fail-close z0intelligence#139 (missing interpreter) and the unmerged feat(dispatch): route factory jobs to the cheapest good-enough lane with capacity z0intelligence#178–180 stack; either merge them or drop them in favor of this edge.
• Gaps for upstream (Ideas, not code): no Hermes usage reader; OMP usage may already work by pointing a Pi instance at ~/.omp/agent (PI_CODING_AGENT_DIR; format unverified).
• Acceptance: Claude pace ≥ 0.8 over a week without manual model picking; zero unsupported-model launches.

L5. Dining room: the UX wave (#57)

Unchanged priorities, now with venues (A-upstream §5) and reuse (C-reuse):

• P0 fix(acp): failed turns hide the real cause behind "Internal error" / "Failed to open … provider session" #58 · Sessions started outside T3 (Tern, Hermes app) don't reach T3, and imported ones are empty #59 · Hermes threads show idle while its background work and subagents are still running #60 · Agent-started thread stuck in Plan mode on Android while Runtime says Full access #61 (fixed upstream by 29275/29267: verify, don't code) · Hermes effort.
• P1 one lab APK for feat(android): show active-thread context-window usage near composer #49 context meter (argue in upstream 14404, 56 votes; copy Dash's "no native snapshot" wording), feat(android): hold composer send to steer without opening queue menu #50 hold-to-steer (Ideas draft ready; cite 24718), fix(android): show Hermes identity instead of ACP fallback in composer #51 icon · inline renders (29141) · Worktree handoff on a Hermes ACP thread kills the run and leaves the continuation and cwd behind #63 · Android: native render errors, low-memory exits, and inline WebView taps blanking the feed #62.
• P2 feat(android): continuous hands-free voice in the active thread #48 continuous voice (Dash continuous-voice.ts is the reference; cite z0live's floor/barge-in contract) · feat(clients): one-tap nudge chips (Continue / Retry / Status) and PR verbs #54 chips (venue 6839) · feat(clients): "Needs you" queue for approvals, questions and review-ready results #65 Needs-you, reframed as a cross-project view of the Working section (venue 21377) plus Dash's bulk-safe approve/reject-with-reason · Desktop/CLI setup friction found while setting up groot + MBP #64.
• P3 OpenUI v2 boards · RFC: contextual next-action button (rules → per-user ranking → provider hints) #55 next-action · Android share target (Dash dash-share module; venue 25898).
• First, before any of it: commit the ~34 uncommitted files in ~/.t3/worktrees/t3code/{feat-needs-you-inbox,feat-android-voice-context-steer}.

L6. Pantry: memory stays out of T3

• T3 gets no memory feature.
• T3 as a source: z0intelligence reads T3 threads via outside-agent MCP (read-only) or t3 thread show --json.
• One capture point: when most sessions run through T3, corrections ("no, I meant…") have one place to be captured. Build the correction-capture arm (0.71 vs 0.24) in z0intelligence (memory: canonical continuity plan, State Packet, and implementation status z0intelligence#22, memory MCP: owner-first ranking (machine text sorts after human turns) z0intelligence#298), triggered from the expediter tick, not a new indexer.
• Fix ctx-import starvation by fixing L3 (memory pressure), not by adding retries.

4. Retire or freeze (no new code anywhere)

5. Work order (from the dependency graph)

1. Level 0, outside T3 code: update to ≥0.1.6 · commit + deploy fix(acp): edit-approval payload exceeds the 8 MiB gateway frame and wedges the session hermes-agent#688 · promote fix(acp): list and attach native gateway conversations hermes-agent#656 · verify 29141 and 29275 on Android · agree the subagent_update transport with the Hermes PR authors · fleet-health fail-open · commit the uncommitted fork worktrees.
2. Level 1: fix(acp): failed turns hide the real cause behind "Internal error" / "Failed to open … provider session" #58 re-scoped · Sessions started outside T3 (Tern, Hermes app) don't reach T3, and imported ones are empty #59 Ideas posts (27524 / 21080 / 22015) · expediter tick (after D1) · burn-pace reads T3 Usage · Android lab APK (feat(android): show active-thread context-window usage near composer #49–fix(android): show Hermes identity instead of ACP fallback in composer #51).
3. Level 2: Hermes threads show idle while its background work and subagents are still running #60 after 137380 · feat(clients): "Needs you" queue for approvals, questions and review-ready results #65 / feat(clients): one-tap nudge chips (Continue / Retry / Status) and PR verbs #54 Ideas · correction capture in z0intelligence.
4. Level 3: OpenUI v2 A/B · RFC: contextual next-action button (rules → per-user ranking → provider hints) #55 · share target.

Only #54 and #39 are T3-side code that unblocks anything else. The first wave is almost entirely updates, Hermes fixes and verifying other people's PRs.

6. Working with upstream

• Rules: CONTRIBUTING at origin/main (unchanged since 30654b3). Features need linked maintainer approval; one problem per PR; executed evidence; no line cap; Gemini and Muse Wonder banned. Attribution comes from AGENTS.md and the PR template. TRIAGE.md misstates the Muse rule (fix it).
• People:
  • Julius: reliability, mobile, VCS, linked environments; wants a test that is red on main; closes duplicates fast.
  • Theo: product and UX; redirects harness asks to ACP; owns Docker sandboxes (15350) and is doing multi-repo projects himself (7041).
  • maria: MCP tools and ACP usage; routes product calls to Julius and Theo.
• How to report: t3 triage flow (check newer release → prefer duplicates → via-triage template), everything through upstream-gate propose.
• Don't build what's in flight: 29141, 29275/29267, 28419, multi-repo projects, Docker sandboxes, LayerFS backends (no decision on 10853/11266 yet; evidence only).

7. Decisions for you

• D1: overnight continuity goes through T3 scheduled ticks or Hermes /goal, not both.
• D2: the single memory/OOM owner. Recommendation: .files, with T3's agent-slice caps neutralized.
• D3: freeze z0bridge identity and the Dash notification rebuild in favor of T3 Connect and mobile notifications.
• D4: pause the DeepSeek phone lane.

8. Non-goals

A memory feature in T3; a capacity plane; a new scheduler; first-class harness requests upstream; porting TSP, sonic pairing or the z0live broker; any upstream PR without linked approval.