claude-ops: lane-launcher never captures launch commit, leaving refresh.md's staleness probe unfillable

[kyle-sexton]

Problem

plugins/claude-ops/skills/lanes/context/refresh.md's git staleness probe (added in #514 / PR #791) references a <lane-launch-commit> placeholder described as "the repo HEAD when lanes start/restart last ran" — but plugins/claude-ops/skills/lanes/scripts/lane-launcher.sh never captures this value anywhere (confirmed by inspection: the only rev-parse call in that script is rev-parse --show-toplevel for the repo root). An operator or future automation following the probe literally has no automated way to retrieve <lane-launch-commit> — it's advisory-only today.

Observed vs expected

Observed: the probe is conceptually correct (git log --oneline "<lane-launch-commit>..${default}" -- plugins/claude-ops/) but the placeholder has no producer.
Expected: lane-launcher.sh captures git rev-parse HEAD at launch time (after its pre-launch pull step) and persists it somewhere the probe doc can point at — e.g. ${CLAUDE_PLUGIN_DATA}/lanes/<lane>-launch-commit.

Fix direction (from two independent review passes on PR #791)

Launcher patch: after the pre-launch git pull, capture git rev-parse HEAD and write it to a per-lane file under ${CLAUDE_PLUGIN_DATA}/lanes/. Update context/refresh.md's probe instructions to read from that file instead of an unfilled placeholder. A hex-only SHA from git rev-parse HEAD carries no injection risk; if this is ever instead sourced from external/user-controlled input, that input must never be interpolated unquoted into the probe command — call this out explicitly in the doc once the launcher change lands.

Lighter-weight fallback if the launcher change is out of scope for now: document claude agents --json's startedAt field as a time-based approximation (git log --after="<startedAt>" origin/main -- plugins/claude-ops/).

Category

behavioral (documentation gap / incomplete automation surface, not a bug in shipped behavior — the probe is correctly labeled advisory)

Lane / source

work lane, 2026-07-21. Deferred VALID finding from PR #791's post-green review pass (two independent review-bot passes both flagged it, before and after a follow-up commit; both classified it non-blocking for a doc-only PR).

Work-class: C3 (bug-fix-shaped) — attended triage 2026-07-23, operator-ratified. 🤖

[kyle-sexton]

This was generated by AI during triage.

Triage: verified (VALID deferred review finding, confirmed by inspection) — BRIEFED but BLOCKED (not routed status: ready, per rule 8d). Decision-defaulted.

Category: behavioral (incomplete automation surface / doc gap — the probe is correctly labeled advisory today, not a shipped bug). Priority medium (rule 5 default; claude-ops sits outside the week's priority-plugin set → order low within tier; lane-launcher is pipeline machinery, so pipeline-correctness weight applies to within-tier ordering only, never a priority grant per 8c).

Blocked by #514 — do not pick up yet

The refresh.md staleness probe this item makes fillable is introduced by PR #791 (closes #514), still OPEN/unmerged. Editing refresh.md's probe now would conflict with that PR. When #514 closes (PR #791 merges), promote this to status: ready — the brief below is already complete.

Problem (behavioral)

claude-ops refresh.md's git-staleness probe references a <lane-launch-commit> placeholder ("the repo HEAD when lanes start/restart last ran"), but the lane launcher never captures that value — its only rev-parse is --show-toplevel for the repo root. The placeholder has no producer, so the probe is unfillable by automation and advisory-only.

Acceptance (behavioral contract)

• The lane launcher, after its pre-launch pull, captures the repo HEAD commit and persists it to a per-lane location under the plugin data home (${CLAUDE_PLUGIN_DATA}/lanes/), so each lane's launch commit is retrievable by lane name.
• refresh.md's staleness probe reads the launch commit from that persisted location instead of an unfilled placeholder, making the probe runnable end-to-end.
• Security note to carry into the doc: a git rev-parse HEAD SHA is hex-only and injection-free; if the launch commit is ever instead sourced from external/user-controlled input, it must never be interpolated unquoted into the probe command — state this explicitly in the doc once the launcher change lands.

Decision defaulted: full launcher-capture fix (recommended) — veto before merge

Two forks: (recommended) the launcher captures + persists HEAD and the probe reads it — the root-cause fix; (alternative) a lighter doc-only stopgap documenting claude agents --json's startedAt as a time-based approximation (git log --after="<startedAt>" origin/main -- plugins/claude-ops/). The stopgap is a workaround, not a fix; recommend the launcher change. A maintainer may veto to the stopgap if the launcher change is out of scope for now.

Source: deferred VALID finding from PR #791's post-green review (two independent review passes both flagged it, both classified non-blocking for a doc-only PR).

[kyle-sexton]

This was generated by AI during triage.

Unblocked → promoted to status: ready. Blocker #514 closed (PR #791 merged 2026-07-21T05:04:16Z); the refresh.md staleness probe is now on main, so the brief above is fully workable. Recommended fork stands (launcher captures + persists HEAD; probe reads it) — decision-defaulted, veto before merge.

(Manual promotion by the triage lane — the blocked-by #514 edge auto-resolved on close, but no mechanism auto-flipped this to ready; logged as the re-promotion-gap observation in #657.)

[kyle-sexton]

This was generated by AI on operator direction.

Superseded — this item was already ratified and should not have been queued.

The earlier first-drain ratification request on this issue was raised in error. The admission gate dispatches a C3 bug-fix-shaped item when it carries either its own recorded ratification or a completed first drain — and this issue already carried recorded ratification in its body from attended triage on 2026-07-23. The drain cycle applied the blanket first-drain rule without first reading bodies for an existing ratification, so it queued an item that was already admitted.

Restored to the autonomous frontier: agent-ready re-applied, needs-human removed. No human action is required, and this issue no longer appears in the attended queue's ratify view.