ops: morning-ritual dashboard — one command for queues, merge-ready, decision list

[kyle-sexton]

Category: operational/automation · Source: daily rhythm — the morning pass starts with the same hand-run queries every day.

Ask

One script (bin/, repo-local or claude-ops skill candidate) that prints the operator's morning view: open counts per queue label (needs-triage / ready / needs-decision / needs-human), the babysit MERGE-READY list, parked decisions with their RECOMMENDED lines, lane telemetry freshness (#502 last-cycle ages), and anything flagged in telemetry "flags" fields. Read-only, gh-based.

Value

30-60 min ritual starts with a 5-second complete picture instead of ad-hoc queries; also the natural seed for the WP2-telemetry-era dashboard.

[kyle-sexton]

This was generated by AI during triage. · Category: operational/automation · Priority: priority: high (pipeline-ops throughput; note: operator-convenience tooling — sub-sort below core correctness items within high). Routed status: ready.

Plan

One read-only, gh-based command printing the operator's morning view:

• open counts per queue label: priority: needs-triage, status: ready, status: needs-decision, needs-human
• the babysit MERGE-READY list
• parked decisions with their bolded RECOMMENDED / "Decision defaulted" lines
• lane telemetry freshness — ops: loop-lane telemetry — running per-lane status (babysit / triage / work) #502 per-lane last-cycle ages
• anything in telemetry flags fields

Placement: a claude-ops skill (the ops toolkit — sibling to observability/known-issues) is the natural home; a repo-local bin/ script is the lighter alternative. Read-only, no writes.

Acceptance

• One invocation prints all of the above from live gh queries; no mutations.
• Telemetry freshness surfaces stale lanes (last-cycle age) and open flags.

Composes with #508 (lane launcher) and #502 (telemetry) as the operator's ops surface; natural seed for a later telemetry-era dashboard.

Decision defaulted: ship as a claude-ops skill (vs a bare repo-local bin/ script) — veto before merge

[kyle-sexton]

Parking a design decision the worker made unilaterally while building this (per this lane's rule 7, a subagent's own decision question parks the same as the orchestrator's).

PR #569 implements the dashboard as a new plugins/claude-ops skill (morning-brief). Everything in the issue's ask is covered except one facet: how the MERGE-READY list reuses babysit-prs's existing readiness classification. This issue's own body said "reuse that existing logic"; the worker instead built a lighter gh-native filter (non-draft + mergeStateStatus=CLEAN) with a pointer to /source-control:babysit-prs as the authoritative gate, reasoning that shelling into another plugin's Python engine crosses the plugin-cache boundary (an installed claude-ops consumer can't reach source-control's scripts, which may not even be installed) — and this repo has no existing precedent for one plugin's skill directly invoking another plugin's scripts at runtime.

Question: accept the gh-native + pointer approach as shipped, or invest in true classification-parity reuse now?

RECOMMENDED: accept as shipped (option 1) — it's boundary-clean, matches the issue's own "read-only, gh-based" framing, and gives the 5-second glance view the issue actually asked for; deeper parity is a legitimate but separable enhancement.

Options:

1. (RECOMMENDED) Keep the gh-native mergeStateStatus=CLEAN filter + slash-command pointer, as shipped in PR feat(claude-ops): add morning-brief operator dashboard skill #569.
2. Shell out from claude-ops's skill to source-control's pr_queue_snapshot.py for exact reuse — breaks for any consumer who installs claude-ops without also installing source-control, and there's no existing cross-plugin runtime-script-invocation pattern in this repo to follow.
3. Materialize babysit's classifier as a drift-checked shared source cluster consumable by both plugins (mirrors this repo's existing sync-checked-duplication conventions) — exact parity, boundary-clean, but a heavier lift than a glance-view dashboard needs today.

PR #569 is in DRAFT (CI green) pending this decision; the code as shipped implements option 1.

[kyle-sexton]

Class-B research resolution (control-tower agent, Opus). Operator-sanctioned research-resolution pass, 2026-07-20.

Question (the sole open facet parked on this issue): Can a claude-ops plugin skill reliably invoke source-control's bundled babysit scripts across the plugin install/cache boundary at runtime — or does the install/cache model make sibling-plugin presence and script-path access non-guaranteed? I.e. accept PR #569's gh-native filter + slash-command pointer as shipped (option 1), or invest in true classification-parity reuse now (option 2/3)?

Answer: No — a plugin skill cannot reliably reach another plugin's bundled scripts by path at runtime. Accept PR #569 as shipped (option 1). The pointer-to-/source-control:babysit-prs approach is not merely "no precedent in this repo" — it is the documented-correct cross-plugin composition primitive.

This rests on four independent facts, each of which alone defeats a different workaround:

1. ${CLAUDE_PLUGIN_ROOT} resolves only to the plugin's own root, and changes per version. "Absolute path to the plugin's installation directory"; "${CLAUDE_PLUGIN_ROOT} changes when the plugin updates." There is no documented environment variable or mechanism that resolves a sibling plugin's root. (plugins-reference — environment variables / persistent data)
2. Path traversal outside the plugin root is explicitly documented as broken. "Installed plugins cannot reference files outside their directory. Paths that traverse outside the plugin root (such as ../shared-utils) will not work after installation because those external files are not copied to the cache." This kills the naive ../source-control/scripts/... relative path. (plugins-reference — referencing external files)
3. Each plugin is copied to its own version-pinned cache directory; the sibling's version segment is unknowable at authoring time and drifts independently. "Claude Code copies marketplace plugins to the user's local plugin cache … Each installed version is a separate directory in the cache." Verified empirically in this workstation's live cache: claude-ops materializes at ~/.claude/plugins/cache/melodic-software/claude-ops/0.13.1/ while source-control is at ~/.claude/plugins/cache/melodic-software/source-control/0.9.3/ — separate roots, independent version segments (0.13.1 vs 0.9.3). So even an absolute path to the sibling's cache dir is not constructible without hard-coding a version that changes on every sibling release. (plugins-reference — plugin cache)
4. The sibling may not be installed at all. Plugins install independently (claude-ops@melodic-software, source-control@melodic-software are separate install entries, separately scoped project/user). A consumer who installs the ops dashboard is not guaranteed to have source-control present. Failure mode of option 2: file not found / silent breakage for any such consumer.

On the dependencies mechanism (the one way to guarantee presence) — considered and rejected for this facet. Claude Code does document a plugin dependencies field that force-installs and force-enables a named sibling within the same marketplace (constrain plugin dependency versions). It was weighed and is the wrong tool here: (a) it would force-install the entire git/PR/babysit/worktree plugin onto anyone who just wants a read-only glance dashboard — heavy coupling directly contrary to this issue's "read-only, gh-based, 5-second glance" framing; and (b) even with the dependency declared, fact #2 still forbids path-access to the sibling's scripts — a dependency buys you invocation of the sibling's skill (slash command), which is exactly what PR #569 already does via its /source-control:babysit-prs pointer. Note that #569's pointer is prose guidance to the operator, not a programmatic call, so it carries zero runtime cross-plugin coupling — the cleanest possible resolution.

Disposition for PR #569: accept as shipped, un-draft, merge. The dashboard's MERGE-READY list uses a self-contained gh-native filter (non-draft + mergeStateStatus=CLEAN) as a fast glance signal, and names /source-control:babysit-prs as the authoritative readiness gate. This is boundary-clean, degrades gracefully when source-control is absent, and matches the issue's own framing. PR #569 as-shipped fully implements the issue's ask; merging it closes #507.

Option 3 (exact classification parity) — deferred with trigger, not excluded. If the dashboard later needs byte-exact reuse of babysit's readiness classifier (not just a glance signal), the documented mechanism is a within-marketplace symlink that is dereferenced (content copied) at install time: "Elsewhere within the same marketplace: the symlink is dereferenced. The target's content is copied into the cache in its place." That is a materialization-time, drift-checkable shared-source path (aligns with this repo's sync-checked-duplication conventions) — heavier than a glance view needs today, but the correct primitive when parity becomes a real requirement. Trigger: a concrete need for authoritative merge-readiness classification inside the dashboard rather than a pointer. (plugins-reference — sharing files across a marketplace via symlinks)

Labels: removing status: needs-decision (this comment is the awaited judgment call); leaving status: ready (PR #569 remains for the merge lane to pick up). needs-human was not present on this issue.