Idea: topic-based status line — LLM-callable pub/sub with multi-channel routing

[kumaakh]

The Idea

Evolve the fleet status line from a passive display into an active, LLM-callable pub/sub system. Any skill, LLM, or user can publish named topic segments to the status line (and eventually other channels like Slack/Teams) without knowing about other topics or the full layout.

---

Relationship to the Fleet Dashboard (#188)

Discussion #188 proposes a Fleet Dashboard + VS Code Extension — a rich, interactive surface that visualizes everything fleet knows: member state, session history, token spend, active tasks. This discussion and #188 are complementary, not competing.

	Status Line (this discussion)	Fleet Dashboard (#188)
When you use it	Mid-session, eyes on the terminal	Dedicated investigation or fleet management
Cost	Zero tokens — just look	Requires opening a separate panel/browser
Latency	Always current, updated by the LLM as it works	Polled or event-driven from MCP
Depth	1–3 short topic segments, always visible	Full member detail, logs, history
Audience	The PM running the session	Any stakeholder watching fleet

The status line is the zero-cost peripheral vision layer. The dashboard is the rich investigation layer. A natural integration: the dashboard's "live status" panel reads from the same topic registry that the status line renders.

---

Why the Status Line Matters

Two specific problems this solves:

1. Token cost of status queries — asking "what's the sprint status?" mid-session re-reads files, re-reasons about state, and costs tokens. A persistent status line makes the answer zero-token: just look.
2. Vertical scroll problem — CLI output flies vertically. Recalling sprint state requires scrolling or spending tokens to reconstruct it. The status line is always visible, always current.

The tool is general-purpose — any skill, the LLM directly, or the user can keep a short note permanently in front of their eyes. MCP does not know or care who the caller is.

---

Proposed Design

1. New MCP tool: publish_status

publish_status(topic, value?, channel?, size?)

• topic — a caller-chosen name reserving a segment. Callers are responsible for picking names unlikely to collide (e.g. pm stores its topic name in projects.md; a user can use any memorable string). MCP does not enforce uniqueness — callers own their namespace.
• value — the string to display. Truncated to size characters. Omitting value (or passing empty) clears and forgets the topic immediately — no need for a separate clear_status tool.
• channel — optional, defaults to "statusline". Future values: "slack", "teams", "log". Same tool, multiple destinations.
• size — optional, defaults to 16 characters. Set on first publish; resizable on subsequent calls.

2. Topic Registry (MCP-managed, persisted)

MCP maintains a topic registry persisted to a JSON file so topics survive MCP restarts. Skills re-publishing on their next update naturally refresh the registry; no explicit re-registration needed.

topic	value	size	last_updated
fleet	2↑ 1↓ idle	16	2026-04-17T10:00:00Z
pm-odm	ODM→DDDVI..o..o	20	2026-04-17T10:01:00Z
pm-avms	AVMS→██░░░░	20	2026-04-17T09:58:00Z
note	deploy after 5pm	20	2026-04-17T09:55:00Z

3. Freshness-Based Rendering

Topics render left-to-right ordered by recency. Because each topic's value includes its own identity (e.g. ODM→..., AVMS→...), positional shifts are not disorienting — the label travels with the value. Topics not updated in 24 hours are automatically forgotten.

fleet is the default topic, always registered at startup.

4. Value Format — Caller's Choice

Callers decide their own format. Examples:

• Sprint progress (pm skill): ODM→DDDVI..o..o where D=done, V=verified, I=in-progress, o=pending
• ASCII progress bar: AVMS→██░░░░ 3/6
• Build state: ✓ Release x64
• User note: deploy after 5pm
• Simple counter: lm: 4/7 tests

5. Clearing a Topic

publish_status("pm-odm")   # no value = clear and forget immediately

No separate clear_status tool needed.

---

Known Limitations

• Stale data risk — if a skill crashes without publishing a failure state, the status line shows the last known value until TTL expires. Skills should explicitly publish failure/abort states, not just happy-path updates.
• Only visible in the Claude Code terminal — does not help when working in other tools. For the core use case (reducing mid-session status queries), this is sufficient. The dashboard (Idea: Fleet Dashboard + VS Code Extension — surface everything fleet knows #188) covers the "other apps" case.

---

Implementation Scope

• publish_status tool: new MCP tool in fleet-mcp
• Topic registry: persisted to JSON (survives MCP restarts)
• Status line renderer: consumes topic registry, freshness-ordered
• pm skill: call publish_status("pm-<project>", "PROJECT→<progress>") on task state changes; call publish_status("pm-<project>") on sprint completion
• fleet_status tool: becomes a topic publisher (publish_status("fleet", ...))

Out of Scope for Initial Implementation

• Slack/Teams/log channel routing (channel param reserved for future)
• Per-topic color/style formatting
• Topic ownership enforcement
• Dashboard integration (tracked in Idea: Fleet Dashboard + VS Code Extension — surface everything fleet knows #188)

[kumaakh]

Technical direction: The design in the issue body is well-thought-out. Implementation sequence:

1. Topic registry (src/services/status-topics.ts): persist to ~/.apra-fleet/status-topics.json. Each record: { topic, value, size, last_updated }. 24hr TTL sweep on server start.
2. publish_status MCP tool (src/tools/publish-status.ts): write topic to registry. Empty/absent �alue = delete topic immediately. channel param accepted but only statusline handled for now (others logged + no-op).
3. Status line renderer (src/services/statusline.ts): on render, read topic registry, sort by last_updated descending, truncate each value to its size, join with | separator. The leet topic (from leet_status) is always registered at server start.
4. Update leet_status to call publish_status('fleet', ...) internally so fleet member state flows into the topic registry.
5. PM skill (skills/pm/single-pair-sprint.md and simple-sprint.md): add publish_status('pm-', 'PROJECT->...') calls at task state transitions; clear on sprint completion.

The channel routing (Slack/Teams) can be wired up later by adding a channel dispatch layer in publish-status.ts — the tool interface is already future-proofed for it.