Ship Captain’s Bridge in the Hermes Helmet Codex plugin

Outcome and approval

When someone returns to autonomous work, they need to understand what happened
before steering it. Captain’s Bridge provides a visual walkthrough inside Codex:
what changed, what remains unresolved, who acted, and the records that explain
each episode. The Captain approved the design and declared the local spike
successful on October 9, 2026. Continue with release implementation of that
experience.

The Captain is the human setting direction. The first officer is the coding agent
coordinating work on the Captain’s host. Hermes is the worker operating under its
own identity. These roles remain explicit in the walkthrough.

Approved experience

The first screen gives the work’s purpose and a fluent account of its outcome.
It groups recognizable work items under “What changed,” “What remains unresolved,”
and other recorded activity where useful. Keep the Changes First layout and the
subdued backgrounds that distinguish a completion report from its acceptance.
Navigation requests, operation counters, and raw transcripts do not replace the
substantive work above the fold.

Selecting a work item opens its explanation, actor handoffs, review and repair
steps, resulting changes, and supporting records. Where the records support a
comparison, “View before and after” opens it directly. Back navigation retains
the reader’s place. Detailed elapsed time and source excerpts remain available
without dominating the overview. Use descriptive names and meaningful issue/PR
links rather than planning codes as titles.

“Refresh records” rereads the same chat directly through the app, preserves
selection, and identifies an explanation that predates newly read records. It
does not send a task to the first officer.

“Update explanation” is optional background work. A dedicated read-only agent
prepares one source-grounded explanation for the explicitly captured originating
chat. The first officer delegates once and does not wait or poll for that work.
Project work already underway remains primary; opening the Bridge does not
start or resume project execution.

Keep the last useful walkthrough visible while preparation runs. Allow the
Captain to cancel; a newer substantive instruction supersedes an unfinished
explanation request unless the Captain explicitly retains it. Cancellation stops
the delegated work and invalidates its request identity, so a late result cannot
replace the displayed explanation. Each request has a bounded time/tool budget.
Failure ends the attempt with a brief status; no automatic retry, debugging loop,
or carryover into later project turns.

The originating chat may need one brief presentation call after preparation.
Make that call only for a still-active request and at a boundary that does not
hold up delivery. Independent agent preparation is not proof that a child can
update the parent’s panel directly; verify that host boundary before claiming
fully independent background updates.

Show Me requests a visual explanation of the chat’s substantive work or a selected
work item. Retro requests retrospective suggestions for the session without
applying them. Both return through the same chat. Their skill dependencies need a
portable installation/discovery story and a clear unavailable state; the public
feature must not require a private toolkit.

Implementation source

Build from PR #54, which preserves the existing Captain’s Bridge 0.2.3 prototype in the Hermes Helmet repository. The source and test guide covers the read-only adapter, MCP server, view, skill, manifests and synthetic tests. Reuse that code rather than reconstructing it from conversation history or an installed plugin cache.

Check PR #54’s current status before starting. If it remains unmerged, adopt the source through the normal review/merge path before integration. The source import does not activate the main plugin or implement background preparation and cancellation.

Implementation boundary

Integrate the reusable extension and its observation skill into the existing
Hermes Helmet Codex plugin. The inspected plugin currently packages the setup,
single-issue, and epic skills; Captain’s Bridge adds a local MCP App. Preserve
those skills and the Claude plugin’s existing behavior. The initial interactive
surface is Codex.

Keep three responsibilities separate: an adapter reads existing records; a
read-only agent prepares an explanation with source references; the view presents
that explanation and its sources. Data adapters and rendering technology remain
replaceable. No tracing service or new persistent collection infrastructure is
selected or required by this decision.

The spike reads Codex’s local index in read-only mode and its saved completion
events. This avoids launching an additional Codex server, whose initialization
failed under the tool sandbox. The storage format is private and version-dependent;
the production adapter needs compatibility checks and explicit unsupported-format
errors. Do not silently choose another chat or replace missing records with an
empty success state.

UI calls and model calls can run in separate server processes. A prepared view
must carry the chat reference and explanation needed for subsequent retrieval;
an in-memory binding from another process is insufficient. Handle the actual
Codex result envelope, including a complete MCP result serialized in a text
content block. Preserve original source identifiers and the explanation’s read
time across refresh.

For delegated preparation, capture the originating chat ID in the parent and
pass it explicitly. The worker must not substitute its own chat identity. Its
result carries the request identity, source fingerprint/read time, explanation
and evidence references. Validate those references and scope at presentation;
do not pass a process-local binding between agents. Preserve the preparation
snapshot time when newer records are available rather than stamping an old
explanation as current. The worker reads evidence only: it neither changes
project files nor resumes tasks, invokes project skills, or repairs the viewer.

Work can cross turns, scheduled wakeups, and asynchronous handoffs. Preserve
explicit relationships without manufacturing one parent-child execution tree.
A quiet interval is not evidence of a stall. A completion report is not the same
as acceptance. The spike can explain Hermes activity recorded in the chat; direct
Docker event collection and broader worker correlation are separate follow-up
scope, not claims established by this release handoff.

Acceptance for the released implementation

• Install through the existing public Hermes Helmet distribution on a host
  without the author’s private toolkit, paths, or local spike marketplace.
• Opening from a chat binds to that exact chat. Another recently active chat,
  repository, or worker is never selected by recency.
• The real Codex panel presents the approved overview, work details, source
  navigation, elapsed time, supported comparisons, and Back behavior.
• Reads and refresh succeed under the normal plugin sandbox without starting
  or resuming work, writing chat state, or exporting transcripts.
• In a real Codex chat with substantive work in progress, updating the
  explanation delegates preparation without a parent wait/poll loop. The first
  officer continues its authorized project task, and record refresh sends no
  agent message.
• Cancel, a superseding project instruction, a duplicate request, timeout,
  failed preparation and a late result leave the last useful view intact.
  Cancellation stops the worker and invalidates delivery; failures end the
  attempt without retrying or becoming unfinished work in the next project turn.
• Test delegated preparation and originating-panel delivery in the installed
  host, including separate tool processes and a parent that finishes before the
  worker. Child chat identity and stale request results never replace the
  originating chat’s view; original explanation freshness remains accurate.
• Separate-process retrieval, wrapped tool results, stale explanations,
  missing identities, unsupported records, and partial file appends have focused
  regression coverage. Missing data produces a useful error while preserving an
  already displayed view where possible.
• Source references belong to the selected chat. Reasoning is excluded, and
  uncertainty about activity, delivery, and acceptance remains visible where it
  affects the explanation.
• Show Me and Retro reach the originating chat with the selected scope.
  Exercise an installed-skill case and a missing-skill case; prevent duplicate
  submissions while a request is pending.
• Verify the installed release package in Codex, including its update and
  activation behavior. A successful tool response alone does not establish that
  the panel opened. Document the supported update path instead of relying on
  repeated global restarts as a troubleshooting loop.
• Update plugin documentation, installation guidance, packaging tests, and
  affected versions through the repository’s existing version policy. Complete
  normal review and release checks before shipping.

Scope and delivery

Implement the accepted experience rather than reopening UX exploration. Reuse the
spike’s reusable code after adapting it to maintained package structure and
tests. Ship only product code and synthetic fixtures; private session records,
screenshots, research artifacts, and personal paths stay outside public output.

This issue tracks release implementation, not an already shipped feature. No
specific release number, additional collector, fleet view, automatic productivity
judgment, or automatic remediation has been selected. Existing optional skill
licenses and ownership must be respected when deciding how to make the actions
available to adopters.