Enhancement: topic-based status line API — LLM-callable update_status with multi-channel routing

[kumaakh]

Summary

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.

Motivation

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 — publish_status can be called by any skill, by the LLM directly, or by the user to 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 a GUID or 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 — no skill changes needed when new channels are added.
• 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. Topic naming — caller's responsibility

MCP does not enforce topic name uniqueness or ownership. The tool description nudges callers to pick names unlikely to collide:

• pm skill stores its per-project topic name in projects.md (e.g. pm-odm, pm-avms)
• A user can use any string, including a GUID if they want guaranteed uniqueness
• Accidental collision = one publisher overwrites another's value — acceptable tradeoff vs. over-engineering a registration system

6. 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 Claude Code window — does not help when working in other apps. For the specific use case (reducing mid-session status queries), this is sufficient.

Why this is valuable

• Zero-token status check — sprint state, fleet health, build state visible at a glance
• Composable — multiple concurrent skills each own their topic; no conflicts
• General purpose — not tied to skills; user can publish directly to keep a note visible
• Multi-channel ready — optional channel param future-proofs for Slack/Teams routing
• Self-cleaning — 24hr TTL + explicit clear means no accumulation

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

[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.