🤖 refactor: derive tool dispatch tables from the TOOL_DEFINITIONS catalog

[ibetitsmike]

Summary

Makes TOOL_DEFINITIONS the single self-describing per-tool catalog (input schema + result schema + PTC bridging metadata) and rebuilds the parallel per-tier dispatch tables as derived views of it. Five hand-maintained tables are deleted outright, the browser registry loses its duplicated schema column, and the branch is a net simplification: 1321 insertions, 1586 deletions, net -265 lines (production and tests, vs merge base).

Background

The tool seam was fragmented into parallel string-keyed switchboards that restate what TOOL_DEFINITIONS already knows: the browser TOOL_REGISTRY duplicated every tool's zod schema, the CLI kept three separate name-keyed maps, toolDefinitions.ts kept a hand-written BridgeableToolName union next to a parallel RESULT_SCHEMAS table, and the PTC bridge kept its own EXCLUDED_TOOLS literal. Each table could silently drift from the spine, and one tool change was a shotgun edit across tiers. This PR deepens the existing catalog seam per-switchboard rather than introducing per-tool scaffolding.

Implementation

Deleted (derived from the catalog instead):

• RESULT_SCHEMAS table: each definition entry now carries its resultSchema directly.
• Hand-written BridgeableToolName union: now a mapped type derived from which entries declare resultSchema.
• EXCLUDED_TOOLS literal in the PTC bridge: entries declare ptcExcluded with their why-reason; the bridge derives the set (one inline special case for the dynamic status_set, which has no definition entry).
• CLI startFormatters + endFormatters maps and the MULTILINE_RESULT_TOOLS set: merged into one binding table.
• TOOL_REGISTRY's schema column: lookup derives the render schema from TOOL_DEFINITIONS by name; entries collapse to bare component bindings.

Surviving additions, each justified:

• Small renderer schema-override map in getToolComponent.ts: only genuine divergences from the definition schema (legacy history-only names such as task_terminate, agent_report's legacy file-backed args union, dynamic status_set, and task_workspace_lifecycle's historical args so old transcripts keep their proper card).
• One merged CLI binding table: the irreducible name-to-formatter binding; formatter functions themselves are unchanged.
• TOOL_NAME_TO_ICON deliberately stays in ToolPrimitives.tsx: generic chrome needs a name-keyed icon lookup from a leaf module that every tool card imports, so folding it into the component catalog would create a browser module cycle. It is already the irreducible one-line-per-tool form.

Diff-shape note: toolDefinitions.ts shows large +/- churn because the result-schema consts had to move above TOOL_DEFINITIONS (const ordering); the file is net -18 lines and the schemas themselves are unchanged.

Out of scope (parallel architecture PRs touch adjacent seams): assembly in tools.ts/toolAssembly.ts, per-tool execution factories, view components and stories.

Validation

• Remote dogfood UAT (Coder Agents, adversarial runner): PASS on this exact head. Verified tool cards (bash, file_read, edit diff, todo), legacy-name and MCP generic-fallback rendering, CLI formatting, plan-mode edit rejection, and the PTC sandbox exclusion set from inside code_execution.
• Wiring-only registry tests were deleted per the catalog derivation; behavioral tests kept (generic fallback, legacy agent_report routing, schema-mismatch fallback) plus a new red-green regression test for historical task_workspace_lifecycle rendering.
• Full bun suite: 13726 pass; the 8 failures are pre-existing (5 reproduce byte-identically on origin/main in a clean worktree; the 3 WorkspaceFooterBar failures pass in isolation on both main and this branch, a known full-suite interference flake).

Risks

Low. Behavior-preserving derivations with identical inputs and outputs; the riskiest surface is transcript rendering of historical tool calls, which is covered by the restored override map and its regression test. PTC sandbox type generation is guarded by the unchanged typeGenerator test suite.

---

Generated with xum • Model: anthropic:claude-fable-5 • Thinking: xhigh

[ibetitsmike]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Already looking forward to the next diff.

Reviewed commit: 64e9d2769e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".