Renaming the Brain to the Assistant
A behaviour-preserving rename of Gantry's conversational LLM driver, from brain to assistant, across code and docs.
2 milestones 7 sprints 17 agents
4 plan 7 execute 9 review
184k peak context
91k median execute
1h 46m total 13m 4s per sprint
4m 3s plan 27m 43s execute 24m 5s review
59 edits 406 commands
codex harness
Gantry's chat and one-shot agent features are driven by a conversational LLM driver: the code that turns a user message into an assistant turn and connects that turn to harness selection, transcripts, logs, and the run-scoped MCP host. This job renamed that abstraction from brain to assistant while keeping the product-facing Gantry Agent name and the `gantry agent` command intact.
The work was split into an implementation milestone and a documentation milestone. The implementation pass changed the live Rust abstraction, the selection surfaces, diagnostics, menu text, and tests; the documentation pass then made the public and contributor prose match the names that were already in the tree. Historical and archived records were left as history rather than rewritten.
How this walkthrough is structured
Feature
What did the run build and ship?
The current tree still uses assistant as the live vocabulary for the conversational driver across source, selection, diagnostics, menus, and docs, while the product remains the Gantry Agent.
Build
How did Gantry structure the work?
The run put the source rename before every surface that depended on it, then adjusted the downstream split after review showed the foundation had already absorbed part of the diagnostics work.
Milestone 1
Implementation Rename
4 sprints 12 agents 1h 12m wall time 184k peak context
The implementation milestone is still visible in the live tree. `src/engine/assistant.rs` exists, assistant selection is resolved through the harness layer, `AssistantMcpHost` is the run-scoped host for assistant turns, and the TUI opens assistant logs by the assistant filename pattern. Later work has expanded those systems, so not every current line belongs to this job, but the vocabulary it installed is still the one the source uses.
This milestone carried the behavior-preserving source rename. Its boundary was broad enough to cover the Rust module, driver types, chat and MCP wiring, selection inputs, assistant logs, menu wording, diagnostic stderr, and tests, but it was still split so the central abstraction came first. The recorded stress was not a failed gate or retry; it was a review-driven re-plan after the first sprint. That re-plan narrowed later diagnostics work because assistant log files and the chat menu item had already moved during the foundation.
Assistant Core Layer
3 agents 23m 40s wall time 184k peak context 1 replan
The core layer remains recognizable. The old module is gone from live source, and `src/engine/assistant.rs` now holds the driver trait, harness-backed driver, turn runner, and tests around transcripts and assistant identity. MCP wiring refers to `AssistantMcpHost`, and chat wiring imports assistant types rather than the old module path. Some implementation has been rewritten by later assistant work, but the module and names created here are still the foundation.
The first implementation sprint was the foundation: it had to rename the internal assistant abstraction before flags, docs, or menu text could rely on the new term. That was a coherent unit for a fresh agent because the brief named the code boundary directly: module, driver trait, owned driver wiring, MCP host naming, chat engine wiring, transcript wording, and test doubles. The sprint passed its gates, but review forced a re-plan because it also moved assistant turn log files and the chat log action. That changed the remaining implementation plan from doing that rename later to preserving the as-built state.
Assistant Picker Surfaces
2 agents 10m 52s wall time 91k peak context
The assistant picker surfaces are still live. The command help advertises `--harness-assistant`, config documentation describes `[assistant]` preferences, and the harness resolver exposes `resolve_assistant` with assistant-specific harness and model precedence. `GANTRY_ASSISTANT_MODEL` remains the environment variable for the conversational assistant model. Later configuration work has added resume and settings machinery around it, but the renamed selection surface is still the one users and code touch.
This sprint took the external selection names after the core already compiled under assistant terminology. Its scope was narrower than the foundation: command-line parsing, environment and harness configuration resolution, precedence behavior, and the tests that prove old selection names no longer participate. The run facts show no local repair or retry here, which fits a propagation slice over a proven resolver. It depended on the first sprint for meaning but did not have to revisit the driver itself.
Assistant Diagnostics Menu
2 agents 14m 39s wall time 97k peak context
The diagnostics surface still uses assistant names. `gantry agent` writes per-turn logs under assistant-prefixed filenames and reports assistant status lines on stderr, while `src/tui/artifacts.rs` finds the newest assistant JSON log and ignores sidecars and the retired prefix. The Assistant menu still exposes a show-log action that opens the latest assistant log when one exists. The behavior is now part of a larger Assistant and Model menu system, but this sprint's naming contract remains visible.
This sprint was reshaped by the earlier re-plan. Its brief says not to redo the assistant log filename and chat menu rename because the foundation had already moved them; the remaining task was to keep that state, prove newest-log discovery, and update diagnostic stderr and stale test wording. That made the unit small enough for a fresh agent: it was a diagnostics polish pass over artifacts, command output, and menu behavior. It stayed green without a fix pass.
Consistency Audit Pass
2 agents 16m 32s wall time 71k peak context
The audit's direct edits are harder to isolate now because later work continued to rename, expand, and reorganize assistant code. The durable result is still checkable: the live source paths I inspected use assistant terminology for the conversational driver, while remaining old-word matches sit in historical plans, archives, or the rename plan itself. Tests now assert assistant behavior and selection names rather than the old abstraction. This sprint mainly left consistency, not a standalone subsystem.
The final implementation sprint was an audit unit rather than a new feature slice. Its brief asked for live source and tests to stop teaching the old abstraction name while leaving frozen ledgers and broad documentation for the next milestone. That was a good closing cut because a fresh agent could run targeted searches, align comments and assertions, and preserve the behavior checks already in place. The run recorded no gate failure or retry at this boundary.
Milestone 2
Documentation Rename
3 sprints 9 agents 28m 1s wall time 113k peak context
The docs still present assistant as the live term. The agent and MCP guide, harness documentation, and configuration reference describe assistant harness selection, assistant model pins, assistant logs, and the Gantry Agent product boundary. Some touched historical or planning documents have since been removed or archived, and the old term remains where the current tree is explicitly preserving history. The user-facing documentation now matches the implementation surface.
The documentation milestone waited until the implementation names existed, which kept the prose work from guessing at final flags, config keys, logs, and diagnostics. It split the docs by audience: first the user-facing surfaces, then deeper design and follow-up material, then screencasts and a final audit. The run facts show a clean pass through those documentation sprints, with no retries or re-plan. That makes the milestone a verification layer over the implementation rather than a parallel rename.
Assistant Docs
2 agents 13m 4s wall time 113k peak context
The public docs still carry this pass forward. The CLI reference points readers from `gantry agent` to the assistant and MCP guide, the harness docs describe `--harness-assistant`, and the config docs document assistant preferences and `GANTRY_ASSISTANT_MODEL`. The assistant log paths shown in documentation use assistant-prefixed files. The Gantry Agent remains named as the product rather than being collapsed into the driver abstraction.
This sprint handled the documentation a user reads first. Because the implementation milestone had already established the new names, the fresh agent could update command tables, harness setup, diagnostic examples, log references, and MCP attachment guidance without deciding what the code should be called. The boundary was language and examples, not source behavior. The sprint stayed green and did not trigger a repair.
Design Follow-Up Docs
2 agents 8m 4s wall time 64k peak context
Some of the specific design documents this sprint touched have since been removed or folded into newer docs, so the sprint's contribution is partly absorbed into later documentation churn. The surviving references still use assistant terminology for prompt catalog entries, harness selection, and live agent architecture. Where old wording remains, it is in archived material or in the rename plan that describes the change itself. The lasting feature is the contributor-facing vocabulary alignment rather than a single page.
The second documentation sprint moved from user surfaces into contributor and design material. Its brief was higher effort because those files explain how the Gantry Agent, assistant harness, prompts, MCP tool surface, and chat pane fit together, and stale vocabulary there would mislead future work. The unit was still bounded because it did not edit frozen records and did not reopen the implementation rename. It passed without a recorded fix or re-plan.
Final Audit
2 agents 2m 5s wall time 48k peak context
The screencast material still reflects the audit. Menu and MCP episodes describe assistant logs, assistant-aware chat behavior, and the assistant receiving Gantry's tool surface, while a demo without a live Gantry Agent says so directly. The edited narration outputs remain valid JSON in the tree. Later screencast rosters and generated assets have moved around the area, but the live scripts no longer teach the old abstraction as current terminology.
The last sprint was a final documentation sweep with screencasts in scope. That placement mattered: narration and demo notes should be updated only after user docs and design notes have already carried the new terminology. The sprint could focus on scripts, generated narration, and any remaining live-doc matches while preserving historical episode context. The run closed this unit green, with no retry recorded.