feat(server): tell agents when to use the t3-code tools (#46)

[lukemaj]

Agents in Chromeria could not find the t3-code tools when their harness defers tool schemas. Claude Code and Codex show only tool names, and Grok not even those, so a planner missed prism_submit and spawn_thread and opened terminal sessions instead (#46).

Every harness's launch prompt now carries a short tool guide in <t3_code_tool_use>: prism_submit for an authorized job that should end in one PR, spawn_thread for small work or a named model and effort, plus the browser, device and Issue tools. The text lives in the fork file apps/server/src/mcp/toolInstructions.ts; the upstream edit is two lines in RuntimeInstructions.ts.

The launch prompt is the channel that reaches all six harnesses. MCP server instructions (Effect 4.0.0-rc.116+) would reach Claude Code, Codex, OpenCode and Grok, but a live ACP run showed Cursor does not show them to the model, and Antigravity only writes them to a file. Research: #46 (comment)

Proof: new toolInstructions.test.ts (every harness gets the rule; the Codex entry stays under Codex's 1,000-token additional-context cap), plus the existing RuntimeInstructions, Claude, Cursor, OpenCode and Codex runtime tests, server typecheck, lint and format on the changed files.

Refs #46

Done by Claude Opus 5.5 in Claude Code, running in T3 Code.

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+12 B (+0.1%)	15.1 KiB	✅
Codex	Thread snapshot wire	7.1 KiB	7.1 KiB	+8 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+4 B (+0.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	56.2 KiB	56.2 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	9	9	0 (0.0%)	21	✅
Claude	Total thread wire	13.5 KiB	13.5 KiB	−11 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.1 KiB	7.1 KiB	−3 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−8 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: f81f18b · PR result: 00822f9 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 113.9 KiB
• Claude decoded thread snapshot: 114.6 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[lukemaj]

Independent review of 00822f9c87181b08c2f396446db559439e6c899f

Blocking

• docs/fork-features.md and scripts/fork-upstream-edits.txt are changed upstream-owned files in this PR stack but are absent from the upstream allowlist/feature ownership. bash scripts/fork-check.sh --upstream origin fails with “upstream file modified but not allowlisted” for both paths. The metadata self-check passes, but the stack check does not. Please adjust the bookkeeping/checker so the documented feature-tracking edits are accepted, then rerun fork-check on the candidate.

Non-blocking

• None.

Reviewed and cleared

• All six buildRuntimeInstructions call sites use the resulting string through their expected launch/prompt field. Codex uses distinct t3_code_runtime and t3_code_tools keys, so this adds no key collision; its per-entry cap check remains separate.
• The guide’s Prism and thread tool guidance agrees with the live descriptions in apps/server/src/mcp/toolkits/prism/tools.ts and threads/tools.ts.
• npm run knip:check passed, including the server export scan. node scripts/fork-features.mjs check passed.
• git diff --check passed. The checkout was clean at the requested SHA.

[lukemaj]

Correction to my independent review of 00822f9c87181b08c2f396446db559439e6c899f: the fork-check finding used the wrong base. I ran bash scripts/fork-check.sh --upstream upstream, matching CI, and it passed. docs/fork-features.md and scripts/fork-upstream-edits.txt are correctly recognized as new fork files. I withdraw the blocking finding.