Situation-room view for the agent fleet: build it from native Claude Code parts, not a command-center product

[don-petry]

Idea

Turn the Claude Code session that drives the agent fleet from a chat transcript into a situation room: terse, graphical, and organised around the decisions a human has to make, from idea to production.

Verdict: don't adopt a "command center" product. Build the view from first-party Claude Code features plus the GitHub queue we already have. Every packaged option surveyed lists only the agents it launches itself, so none can show a fleet that runs as GitHub Actions workflows.

Researched and drafted with Claude Code on 2026-10-10 from public docs, READMEs and repository metadata. No third-party tool was installed or tested.

Status

Phase	Item	State
1	sitrep output style	Done 2026-10-10. Installed as a user-level style and set as the default for new sessions. Not yet observed in a fresh session.
1	Decisions as dialogs with phone push	Done 2026-10-10. The instruction is part of the style. Remote Control for new sessions, question banners and both phone-push settings were already on.
2	Artifact status board	Not started
3	GitHub Project pipeline view	Not started
4	Self-written mod	Not started

The installed sitrep style (supersedes the sketch in the full report)

---
name: sitrep
description: Situation-room replies. Verdict first, status as a table, decisions as choices, no narration.
keep-coding-instructions: true
---

# Situation report

The reader runs a fleet of agents and reads each reply to decide what happens next, not to follow what you did. Give them the state and the decision. Do the work as thoroughly as you otherwise would; only the reporting changes.

## Shape of a reply

1. **Verdict.** The first sentence is the answer, or the state as it now stands. A simple question gets one to three sentences and nothing else.
2. **Status table.** When more than one item has state, show it as a table: item, state, owner, next action. One row per item, a few words per cell. Name every issue, pull request and discussion by its title as well as its number.
3. **Evidence.** Only what would change the decision: the failing line, the number, the link. Not the path you took to find it.
4. **Decisions.** At most three, most consequential first.

## Decisions go through the dialog

When you need the reader to choose, ask with the AskUserQuestion tool, not with a prose question at the end of a reply. The dialog reaches their phone and waits for an answer; a question in prose gets buried in the transcript.

- Put the option you recommend first and say why in its description.
- Ask only what is theirs to decide. If the request, the code or a sensible default settles it, pick, say what you picked in a few words, and carry on.
- If nothing needs deciding, end the reply. Do not invent a question or offer further help.

## Leave out

- Preamble, restating the request, and announcing what you are about to do.
- Step-by-step narration of tool calls and the closing recap of what you just said.
- Method, background and alternatives you did not pursue, unless asked.

While working, stay silent between tool calls unless something changed the plan; then say so in one line.

## Prefer a picture to a paragraph

Comparisons belong in a table. Proportions, trends and flows belong in a chart or diagram when a visual tool is available. Do not describe in prose what a table would show.

## Write at full length for

- Errors and failing output: quote the output itself.
- Security warnings, and any destructive or irreversible action awaiting confirmation.
- Anything the reader explicitly asks to have explained or written up.

Brevity never justifies dropping a caveat that would change the decision. Mark what you did not verify, in a few words, next to the claim it qualifies.

Recommended plan

Phase	Build	Outcome	Cost / risk
1	Custom sitrep output style, set as outputStyle in the user settings file	Every reply is a verdict line, a status table and at most three decisions	None; an instruction, not enforced
1	Decisions asked as multiple-choice dialogs, with Remote Control phone push	Choices instead of prose questions, answerable from a phone	None
2	Private Artifact status board fed by a GraphQL snapshot of GitHub state	One page showing the fleet, ordered by what needs a human	Tokens per republish; a script should render the HTML so Claude only publishes
3	One org-level GitHub Project as the pipeline view, native fields only	Idea → spec → build → review → shipped across all repos	$0; avoid custom agent-state fields
4	Small self-written mod: a band above the prompt and a pane beside the transcript	Live heads-up display inside the desktop Code tab	Unsandboxed code, API still changing; write in-house
Reserve	Stop hook that blocks replies breaking the format	Hard enforcement of the reply contract	An extra model turn each time it fires

Design rules for the status board (phase 2):

• Columns: Working, Needs you, In review, Ready to merge. Copied from Orchestrator.inc, whose board computes them from PR, check and review facts.
• Never store status. Compute it at read time from GitHub, and show the snapshot age on the page.
• Order rows by the human action required: approval or input needed, failed verification, ready for review, running, stale.
• Use GraphQL. It has its own 5,000-point hourly budget, separate from the shared 5,000-request REST limit.
• Include a budget gauge. Anthropic's paused June 2026 re-pricing plan named the Claude Code GitHub Actions integration.
• Keep it private. An Artifact is a private page; a GitHub Pages dashboard on this public repository would be world-readable.

Options compared

Option	Cuts prose	Graphical	Sees the Actions fleet	Works in the desktop Code tab	Verdict
Custom output style (or built-in Concise)	Yes	Tables only	n/a	Yes	Adopt
Multiple-choice decision dialog + phone push	Yes	Dialog	n/a	Yes	Adopt
Artifact status board over a GraphQL snapshot	Moves status out of chat	Yes	Yes	Yes	Adopt
GitHub Projects	No	Board, roadmap	Issues and PRs only	Browser	Adopt as pipeline view
Self-written mod	At display layer	Yes	Yes, by polling	Yes	Adopt second
Stop hook format contract	Enforces shape	No	n/a	Yes	Reserve
caveman, attention-span	Yes	No	n/a	Untested by authors	Skip
Status-line HUDs (claude-hud, ccstatusline)	No	Text	No	No	Skip
Hook-fed dashboards (Claude-Code-Agent-Monitor, agents-observe)	No	Kanban	No, local sessions only	Separate page	Skip
Orchestrators (Orca, Conductor, Superset, Orchestrator.inc)	No	Yes	Only sessions they start	Separate app	Skip
Gas City	No	No	No	Terminal	Skip
GitHub Agents tab	No	Yes	No, GitHub-launched agents only	Browser	Skip
Linear, Graphite	No	Yes	Partly	Browser	Skip
Anthropic Projects, agent view, routines	No	Overview pane	No	Partly	Skip
Workflow frameworks (Superpowers, Spec Kit, BMAD, OpenSpec)	No, they add documents	No	No	Installable	Skip

Why the popular choices lose:

• caveman: on its own benchmark it is about 5% terser than the plain instruction "Answer concisely." (4,119 against 4,334 output tokens).
• Status-line HUDs: the desktop app never runs the status-line command. The feature request, anthropics/claude-code issue 41456 "[FEATURE] Add status bar to Desktop App", has been open since March 2026.
• Linear and Graphite: the only two that can see work they didn't start. Linear is a second system of record capped at 250 issues on its free tier; Graphite's inbox for organisation repositories starts at $20 per user per month.
• Workflow frameworks: they add documents and always-on tokens, and none produces a board.

Follow-up analyses

GitHub Projects

Useful as the backlog and pipeline board, not as the decision queue.

• Good at: where each idea sits in the pipeline, using board columns, roadmap, sub-issue progress and blocked-by fields. Free on all plans.
• Weak at: what is stalled and why. It can filter on a hold label, but not on check state, a dismissed approval or unresolved review threads.
• Trap: custom fields such as "Agent state" are a second copy of state that automation must keep in sync, and the label-driven agents cannot see them.
• Privacy: a project's visibility is set separately from its repositories, so it can stay private over public repos.
• Unverified, from memory: the workflow token cannot write to an organisation project, and the free plan allows one auto-add workflow per project.

Gas City

An SDK for building a multi-agent orchestrator, extracted from Gas Town. Active (v1.5.0 on 2026-10-05, MIT).

• Not a fit: it runs its own sessions in tmux, subprocesses or Kubernetes, tracks work in Beads on a Dolt database, and its README describes no dashboard or decision queue.
• Relevant only if the Actions-based fleet is itself replaced. Its controller loop and health patrol address stalled and timed-out runs.
• Not checked: the separate gascity-dashboard repository and the README's "optional GitHub gates".

Orchestrator.inc as a front end for Actions runners

Not extensible that far without a fork that fights its design.

• Runners are compiled-in Go adapters, and the only ones are local terminals. The adapter registry advertises two extension kinds, agent and issue tracker, with no runner kind.
• Every card is a live session it launched. PRs attach by signed-in author plus session branch prefix, and its docs state that terminated sessions' PRs stop being observed.
• The runner contract is interactive (attach a terminal, inject input, probe liveness), and status comes from agent hooks on the local machine. An Actions job offers neither.
• claim-pr is not a way in. The command attaches an existing PR to a session, but still needs a live local session per PR.
• It polls GitHub every 30 seconds with the signed-in credential. On the account the fleet uses, that draws from the shared quota.
• Its remote options run its own daemon (experimental self-hosted hosts, a cloud sandbox), not Actions.
• Worth lifting: its pull-request observer design, under Apache-2.0: status computed at read time, batched GraphQL, conditional requests.

Subscription rules for third-party front ends

Relevant to any future look at an orchestrator.

• Allowed: signing in to the unmodified Claude Code binary with your own subscription, including inside a tool that hosts it. Wrappers that launch the real CLI sit on this side.
• Not allowed: a third party offering claude.ai login in its own app or routing requests through subscription credentials. Enforcement was reported from 4 April 2026 (secondary sources only).
• Unresolved: the plan to move Agent SDK, headless and GitHub Actions usage onto a capped monthly credit from 15 June 2026 was paused with no new date.

Open questions

• Can a claude.ai GitHub connector feed the Artifact live and remove the republish step?
• How does the desktop app approve and hot-reload a mod written in-session?
• No source measures reading-time savings for any output style; only token counts exist.
• The desktop session exposes inline charts, transcript chapters, sidebar grouping and a shared artifact database. They have no public documentation, so treat their behaviour as untested.
• Whether the fleet should stay on Actions at all is out of scope here, but it decides whether Gas City or an orchestrator deserves a second look.

Not included here

• Raw research notes: four files, about 250 KB, covering 22 third-party tools, the plugin ecosystem and fleet control planes. They are local only; the collapsed report below is the synthesis.
• Implementation detail for phases 2 to 4: no issues or acceptance criteria exist yet.

When to revisit

• The desktop app starts running the status-line command.
• A supervisor product gains the ability to observe agents it did not launch.
• Anthropic revives the paused re-pricing of GitHub Actions usage.

Full research report with sources (2026-10-10)

Build the situation room from native parts

Recommendation: do not adopt a "command center" product. Assemble one from four first-party Claude Code features and the GitHub queue you already have. The third-party GUIs, orchestrators and vendor agent views surveyed list only the agents they launch, so they cannot show a fleet that runs as GitHub Actions workflows; the two exceptions, Linear and Graphite, add a second system of record or a per-seat fee. The parts that do fit are: a custom output style that forces verdict-first, table-first replies; decisions routed through the AskUserQuestion dialog with phone push; a private Artifact page that renders fleet state read from GitHub; and, second, a small self-written mod that draws a live band and pane inside the desktop Code tab. All four run in the desktop app on macOS, cost nothing to license, and keep GitHub as the single system of record. The popular terse-output and HUD add-ons are poor buys here: caveman beats a plain "Answer concisely." by about 5% on its own benchmark, and every status-line HUD is terminal-only because the desktop app never runs statusLine. Nothing below was installed and tested; versions and star counts are as read on 2026-10-10.

Five of fourteen options earn a place

Option	Cuts prose	Graphical	Sees the Actions fleet	Desktop Code tab	Cost / risk	Verdict
Custom output style (or built-in Concise)	Yes, by instruction	Tables only	n/a	Yes, via settings file	None; not enforced	Adopt now
AskUserQuestion + Remote Control push	Turns prose questions into choices	Dialog	n/a	Yes	None	Adopt now
Artifact status board fed by a GraphQL snapshot	Moves status out of chat	Yes	Yes, you write the query	Published from it; opens on web and phone	Tokens per republish	Adopt now
GitHub-native queue: hold label, saved searches, dependencies, environment approvals	No	Board	Yes	Browser	$0 on public repos	Keep; make it the data source
Self-authored mod (band + pane)	At display layer	Yes, SVG	Yes, via gh on a timer	Yes, v2.1.286+	Unsandboxed; API still changing	Adopt second
Stop hook format contract	Enforces shape	No	n/a	Yes	Extra model turn each time it fires	Hold in reserve
caveman, attention-span	Yes	No	n/a	Untested by authors	650–1,160 always-on tokens; caveman telemetry on by default	Skip; copy the structure
Status-line HUDs (claude-hud, ccstatusline)	No	Text	No	No	n/a	Skip
Hook-fed dashboards (Claude-Code-Agent-Monitor, agents-observe)	No	Kanban	No, local sessions only	Separate localhost page	Node or Docker	Skip
Third-party orchestrators (Orca, Conductor, Superset, Orchestrator.inc)	No	Yes	Only sessions they start	Separate app	$0–$50/month plus the same Claude budget	Skip; copy the "Needs you" column
GitHub Agents tab / Agent HQ	No	Yes	No, GitHub-launched agents only	Browser	Paid Copilot plan plus AI credits	Skip
Linear, Graphite inbox	No	Yes	Linear by API; Graphite sees all PRs	Browser	Linear Free caps at 250 issues; Graphite org repos from $20/user/month	Skip
Anthropic Projects, agent view, routines	No	Overview pane	No	Projects yes (beta); agent view is terminal	Subscription usage	Skip; routine optional as refresher
Workflow frameworks (Superpowers, Spec Kit, BMAD, OpenSpec)	No, they add documents	No	No	Installable	550–1,676 always-on tokens	Skip

An output style does what caveman sells, for free

An output style is a Markdown instruction file sent with every request, and the desktop app honours one set as outputStyle in a settings file. The built-in Concise style already leads with the result and drops preamble, narration and recaps while doing the engineering work as thoroughly as Default (Output styles). A custom style goes further and fixes the shape. Save this as ~/.claude/output-styles/sitrep.md and set "outputStyle": "sitrep" in ~/.claude/settings.json (the value is case-sensitive; a mismatch silently gives Default):

---
name: sitrep
description: Verdict, status table, decisions. No narration.
keep-coding-instructions: true
---
Line 1: the verdict or answer, in one sentence.
Then, only if state changed: a table of item | state | owner | next action.
Then at most three decisions, each asked through AskUserQuestion, never as prose.
No preamble, no step narration, no closing recap. Name every issue and PR by number and title.
Write at full length only for errors, failing output, security warnings and destructive actions.

The evidence says this captures nearly all the available saving. On caveman's own ten-question benchmark, no instruction produced 6,983 output tokens, "Answer concisely." 4,334 and /caveman 4,119, so the 111k-star plugin adds about 5% over one sentence of instruction, and its README concedes that line "is the real baseline" (caveman). The more useful community idea is structural: attention-span's Rundown style opens with a TL;DR, shows status as a checklist and numbers next steps, and self-reports 43% shorter output with an unchanged 97% task pass rate (attention-span). The sketch above borrows that shape without the dependency.

Three limits matter. A style is an instruction and "nothing enforces it"; it does not reach subagents, which run their own system prompt; and the desktop app's condensed Summary transcript view was removed in v1.46388.1, leaving Normal (tool calls collapsed) as the tersest view (Output styles; Desktop). If the style drifts, a Stop hook receives last_assistant_message and can block a reply that breaks the format, in desktop sessions too (Hooks). Each block costs another model turn, so on a constrained budget it belongs in reserve. Routing decisions through AskUserQuestion pays twice: the dialog stays open on Remote Control devices until answered, and "Push when actions required" sends it to the phone (Remote Control).

Supervisors see only what they launch, so read GitHub directly

Nearly every surveyed supervisor lists only what it launched. GitHub's Agents tab shows Copilot plus the partner Claude and Codex apps, requires a paid Copilot plan, and offers no mid-run steering for third-party agents (GitHub Docs; Manage agents). Anthropic's agent view covers local background sessions, and Projects covers its own cloud threads (Agent view; Projects). The desktop orchestrators wrap the local claude CLI in worktrees; adopting one means moving execution off Actions and spending the same subscription budget on parallel local agents. That category is also unstable: Terragon shut down in January 2026, Crystal was deprecated in February and Bloop, maker of Vibe Kanban, closed in April (Terragon; Crystal; Vibe Kanban). Linear could ingest the fleet through its agent API, but it duplicates state that lives in issue bodies and its free tier stops at 250 issues; Graphite's inbox sees every PR regardless of author, but covers organization repos only from $20 per user per month (Linear pricing; Graphite pricing).

So the board has to be built, and the cheap, robust pattern is a snapshot. A handful of GraphQL queries pull open PRs with review decision, check rollup, labels and merge-queue state. GraphQL has its own 5,000-point hourly budget, separate from the shared 5,000-request REST limit, and by the documented cost formula such a query costs an estimated 1–12 points per page (GraphQL limits; REST limits). An Artifact is the right canvas: a private claude.ai page that Claude republishes to the same URL, available on Pro and Max plans from the desktop app, and documented for exactly this "status board" use (Artifacts). It suits this org better than GitHub Pages because the repositories are public and the artifact is private.

Two design rules come from practitioners. Order rows by the human action required: approval or input needed, failed verification, ready for review, running, stale; "more transcript text usually creates more scanning, not more control" (DEV). And derive every row from GitHub truth with a visible snapshot timestamp, because the common dashboard failure is drift: Anthropic's own cloud list leaves sessions "Ready for review" after their PRs merge, and a green routine run "does not mean the task in your prompt succeeded" (anthropics/claude-code issue 57939; Routines). Orchestrator.inc's column set (Working, Needs you, In review, Ready to merge, each computed from session, PR, CI and review facts) is the layout to copy (Orchestrator.inc). Decisions should still execute in GitHub; the documented bridge back is a "Copy as prompt" button on the page.

Budget shapes the refresh path. A styled page costs more tokens than the same content as text, so a script should render the HTML from the query JSON and Claude should only publish it. The published page cannot call local tools or outside URLs, so the session, not the page, does the fetching (Artifacts). Refresh on demand or from a local scheduled task, which runs as often as every minute while the app is open but stalls on its first unapproved permission prompt, so publish the artifact once interactively first; a cloud routine can republish unattended but runs hourly at most and draws down subscription usage (Scheduled tasks; Routines).

Mods are the only HUD the desktop app draws

The star-heavy HUDs do not apply. claude-hud (28k stars) and ccstatusline (13k) are statusLine commands, and the desktop feature request for a status bar has been open since March 2026; a second issue reports the command "is never invoked" in desktop sessions (anthropics/claude-code issue 41456; issue 84904). Hook-fed dashboards such as Claude-Code-Agent-Monitor do render a Kanban, but of local sessions, in a separate localhost page.

Mods fill the gap. Since v2.1.286 in the desktop app, a plugin of JavaScript handlers can draw a pane beside the transcript and a band above the prompt, with buttons, selects and (desktop only) SVG, and can redraw the assistant-message row and the AskUserQuestion dialog (Mods overview; Mods reference). The API supplies what a situation-room strip needs: $.session.usage() for context, rate limits and cost; $.process and $.clock to poll gh; and digit-hotkey buttons that submit a prompt. Claude writes the mod on request through the built-in plugin-authoring skill, with hot reload (Create a mod).

Sequence it second for two reasons. Mods are unsandboxed code that can approve tool calls and spend usage, and Anthropic warns the events and methods "can change between releases." A security firm has already demonstrated a marketplace plugin whose hook rewrites permission settings (PromptArmor). Write it in-house, keep it small, and do not install a stranger's. The search found no widely adopted in-session plugin or mod branded "command center"; the label belongs to standalone apps such as the self-hosted mission-control (6.3k stars).

What remains unverified

Four points need a ten-minute check before relying on them. No source measures how much Concise or any style shortens reading time, only token counts. The desktop flow for approving and hot-reloading a session-written mod is documented for interactive sessions generally, not desktop specifically. Whether a claude.ai GitHub connector can feed the artifact live, removing the republish step, was not confirmed. And the researchers saw desktop-session tools with no public documentation (inline chart widgets, transcript chapters, sidebar grouping, a small shared artifact database); these would strengthen the design but should be treated as untested.

Conclusion

The search for a product resolves into a configuration: one style file, one query script, one artifact, later one mod. That outcome is specific to this architecture. A fleet whose state already lives in GitHub issues, labels and checks needs a lens, and every packaged "mission control" is instead a second place to run agents. Keeping state in GitHub also makes the lens disposable, which matters in a category where three well-known tools shut down or were replaced between January and April 2026.

The larger exposure is not the interface. Anthropic's paused June 2026 plan to move Agent SDK, claude -p and the Claude Code GitHub Actions integration onto a separate capped credit named this fleet's usage pattern directly, and Anthropic has said only that it will give notice before revisiting it (Let's Data Science; Zed). A budget gauge on the board, fed by the fleet's own per-run accounting, is the panel most likely to earn its space.

Additional sources for the follow-up analyses: gastownhall/gascity, OrchestratorInc/agent-orchestrator (docs/architecture.md, docs/scm-observer.md, backend/internal/adapters).

[github-actions[bot]]

Enhancement: the board's classifier and budget gauge already exist; build the data feed, not just the view

The plan is sound. This comment adds findings from this repo and from current docs. Three of them change it: Phase 3 already exists, the first open question has a documented answer, and the snapshot's API cost collides with issue #2197.

1. Sharper problem framing

The fleet can already tell what needs a human. What it lacks is a single place that gathers those findings, updated often enough to act on. The classification logic is in place, tested and detection-only:

Board column / panel	Existing source in this repo	Current delivery
Needs you (held)	pr_has_escalation_label in scripts/lib/pr-automation-budget.sh, which covers the hold-label set needs-human-review, dev-lead:needs-human and dev-lead:hands-off	Labels only
Needs you (stalled)	scripts/pr_stall_scan.sh + lib/pr-stall-detect.sh	Daily health-check issue (e.g. #2195)
Ready to merge (and stranded)	scripts/pr_mergeready_scan.sh + lib/pr-mergeready-detect.sh, built after #1451 sat idle for 77 h	Daily health-check issue
Failed verification	lib/ci-status.sh compute_ci_status (filters the agents' own checks), lib/standing-approval.sh	Used inside the gates
Runaway	scripts/pr_runaway_scan.sh	Daily health-check issue (e.g. #2194)
Fleet down	scripts/engine_liveness.sh (FLEET vs ISOLATED escalation)	Health-check issue
Budget gauge	scripts/budget_poller.sh, which polls at :17 and :47 every hour and keeps the budget-poller-log artifact for 14 days; fleet_monitor.sh already reads it with a staleness warning	Job summary only

Implication: copy Orchestrator.inc's columns, but not its classification logic. A third classifier written for the board would drift from the one the gates enforce. The board would then show "ready" for PRs that hold-gate.sh is holding, which is the same drift failure the research warns about. The board should be a read model of the gates' own verdicts.

The scanners also have two real gaps. They run once a day (daily-pr-review-health.yml, 06:13 UTC), and they scan one repo (REPO defaults to .github-private). The product repos (broodly, TalkTerm, markets, …) are not covered.

2. Corrections and answers to the open questions

• Phase 3 is already built. add-to-project.yml adds every issue and every dev-lead-labelled PR to the org-level Initiatives project (orgs/petry-projects/projects/1). It uses the petry-projects-planner GitHub App, not the workflow token. That also settles the "unverified" Projects question: the org writes through an App token. Phase 3 becomes "add a saved view", not "create a project".
• Open question 1 has a documented answer: yes. Since Claude Code v2.1.209, an Artifact can call claude.ai MCP connectors each time it loads and refresh them on an interval. The docs' own example is a dashboard of open pull requests pulled "through my GitHub connector when the page loads". This removes the republish step. It has two costs the plan doesn't account for (Artifacts → Pull live data with MCP connectors):
  • Calls run as the viewer's account. Here that means don-petry, the identity whose quota the fleet already exhausts (The fleet and every session share one GitHub API quota (don-petry, 5,000/hour) and the fleet alone uses about that much: it ran out on 2026-10-10 and failed a workflow #2197, 2026-10-10: 0/5,000 at 12:33Z, baseline about 95–115 requests a minute).
  • A page "can offer controls that invoke connector tools with side effects … through the account of whoever selects the control". That is useful for one-click "release hold". Combined with untrusted data (below), it is also a hazard.
• "GraphQL has its own budget" protects less than the plan suggests. The GraphQL limit is "5,000 points per hour per user", and that includes App or OAuth requests made on the user's behalf (GraphQL limits). gh pr view and gh pr list use GraphQL, and so does reviewer_report.sh. How much of that budget the fleet spends is unmeasured, so "separate" is not the same as "free".
• Artifacts cannot be published from CI. Artifacts are off in -p, the Agent SDK and the GitHub Action. A publish started by a scheduled task asks before the first publish of each artifact (Availability). CI can produce the data; only the desktop or CLI session can publish it.
• Mods can be audited in CI. claude plugin validate <dir> prints hooks: and calls: lines without running the mod (Mods overview). A bats test can assert that the in-house mod handles only ui.render and timers and never approves tool calls. That turns "unsandboxed, write in-house" into a gate that is enforced. Note that processes a mod starts run outside the sandbox even with sandboxing on.

3. Options for the data path

Option	API identity / quota	Freshness	Untrusted-content exposure	Build cost	Verdict
A. Session runs the GraphQL snapshot, a script renders, Claude republishes (current plan)	don-petry, shared with the fleet	On demand	Low if the script escapes HTML and Claude publishes the file without reading it	Low	OK as a stop-gap
B. Connector-backed live Artifact	Viewer's (don-petry) on every load and every refresh	Live	High: PR and issue titles on public repos are attacker-controlled, and the page holds side-effect connector rights	Lowest	Don't adopt until #2197 is fixed
C. CI writes sitrep.json from the existing detectors with the App installation token; session, Artifact and mod read that one artifact	App installation has its own 5,000 REST/h and 5,000 GraphQL points/h (REST limits)	30 min	Low: the data is classified upstream, and titles are rendered as text	Medium	Recommended
D. C plus the mod polling with If-None-Match	Same as C; a 304 "does not count against your primary rate limit" (REST best practices)	30 min, surfaced instantly	Low	Medium	Phase-4 form of the mod

Option C also covers #2197 acceptance criterion 5 (remaining quota and the day's low point in the health report) by adding a quota block to sitrep.json. It puts the "status computed from GitHub truth" rule in one tested place instead of three.

4. Risks and unknowns

1. Prompt injection through the board. All 12 org repos are public, so anyone can open a PR whose title is an instruction. In Option A, a session that cats the snapshot puts that text into Claude's context. In Option B, a page that renders titles through innerHTML could run script in a page with connector rights.
   • Mitigation: the renderer escapes all text. The session publishes a file path and never reads the contents. A connector page, if one is ever built, declares only read tools.
2. A polling mod makes The fleet and every session share one GitHub API quota (don-petry, 5,000/hour) and the fleet alone uses about that much: it ran out on 2026-10-10 and failed a workflow #2197 worse. A mod calling gh every minute adds at least 60 requests an hour on top of a baseline already above the limit. The mod should read the CI artifact with conditional requests (Option D), not call GitHub directly.
3. Scheduled cron is unreliable here. See Improving reliability of scheduled GitHub Actions runs (cron is best-effort) #656 and Retry and sweep crons run every 4–8 hours instead of every 2 h / 15 min, while PR comments promise specific retry times #2170 (retry crons firing every 4–8 h instead of every 2 h). Show generated_at prominently and turn the page amber after more than 2 missed slots, reusing fleet_report.sh's SCHEDULE_TOLERANCE_TICKS logic.
4. Detector fan-out cost. Running three scans × 12 repos every 30 minutes has not been costed. The first pilot run should log x-ratelimit-used before and after.
5. Unknown: whether a Pro or Max plan's connector-backed page counts against any claude.ai usage. The docs are silent.

5. Phased pilot

Step	Change	Exit criterion
0	sitrep output style + AskUserQuestion (unchanged from the plan)	One week of baseline output tokens per reply
1	Add --json to pr_stall_scan.sh, pr_mergeready_scan.sh, pr_runaway_scan.sh and engine_liveness.sh. Define sitrep.schema.json with fields repo, number, title, column, reason, since, url, following the signals.schema.json precedent. Add bats tests	Existing markdown reports byte-identical; JSON validates
2	sitrep.yml runs every 30 min, offset from budget-poller's :17/:47 slots, uses the App token and fans out over non-archived repos. It merges the detector JSON with the last budget-poller record and rate_limit, and uploads sitrep-snapshot (retention 2 d)	7 days at 95% or more of slots present; zero don-petry calls attributed to it
3	scripts/sitrep_render.sh turns the JSON into escaped HTML, and the session publishes it as a private Artifact (Option A, fed by C)	Every "Needs you" row matches a hold label or a detector hit (invariant test)
4	In-house mod band reads sitrep-snapshot with an ETag; claude plugin validate check in CI	Band updates within 1 slot; validate output allow-listed
5	Reconsider Option B only after #2197 lands an App-token fleet	—

6. Success metrics

• Time to human notice for held, stalled or stranded PRs: from the hold label or detector first-hit to the first human event. Baselines are 77 h (feat: implement issue #1450 — [bug] markdownlint lints node_modules/ — vendored READMEs fail Lint, silently halting pr-review #1451) and 4 days (feat: implement issue #846 — [Phase 2] Cache the LSP index and enforce the 30s cold-start SLA with auto-skip #860). Target: median under 2 h during working hours.
• Quota neutrality: the board adds 2 or fewer don-petry calls per refresh. Everything else is billed to the App installation.
• Single classifier: 0 rows where the board and hold-gate.sh / the detectors disagree, enforced by test.
• Alert consolidation: once the board is trusted, the daily health-check issues (PR Review Agent — failures detected 2026-10-10 #2193–Stalled PR candidate(s) detected 2026-10-10 #2195 pattern) become optional. That connects to 💡 Health-Check Issue Lifecycle Automation (💡 Health-Check Issue Lifecycle Automation for Alert Noise Reduction #1041).
• Reply terseness: output tokens per reply before and after the output style. This is still the only directly measurable reading-cost proxy.

Related threads

• The fleet and every session share one GitHub API quota (don-petry, 5,000/hour) and the fleet alone uses about that much: it ran out on 2026-10-10 and failed a workflow #2197: shared quota, a hard prerequisite for Option B.
• Factory MVP: rebuild the agentic factory around a declared control plane, one run contract and a council of Lenses #2226 (Factory MVP control plane): sitrep.json is a natural read model for a declared control plane.
• 💡 Agent Session Telemetry Dashboard for Fleet-Wide Runtime Analytics #1040 (session telemetry dashboard), 💡 Agent Pipeline Stall Detector & Automatic Recovery Escalation #791 (stall detector) and 💡 PR Pipeline Deadlock Root-Cause Attribution Engine #2023 (deadlock attribution) are partly realised by the detectors above. This board would be their first shared output.

Sources: Claude Code Artifacts · Mods overview · GitHub GraphQL rate limits · GitHub REST rate limits · REST best practices (conditional requests) · GitHub Agent HQ / Mission Control coverage · repo files cited inline (read at 4748e45).