ci-failure-classification-loop: close the drive-to-green seam across CI cycles

New skill (skills/ci-failure-classification-loop/SKILL.md) codifies the
OODA loop the orchestrator runs to drive a red-CI PR to green without
per-cycle re-prompting from the maintainer. Classes the loop orients
into: A expected (skip), B structural impasse (surface), C tractable
(dispatch fixer), D regression (dispatch fixer urgently). Decision
rule: D first, then C, terminate on green or A+B-only or no-progress
or authorization gap. Worked examples distilled from the successful
fixer chain on kriscendobot/agoric-sdk#5 (ba72cd -> cb7a05 -> cc9bb5).

Wiring:
- roles/steward/AGENT.md gains a Fixer -> fixer (CI failure
  classification loop) sub-section under Auto-pickup chains, naming
  the skill as the standing form of the Shepherd -> fixer chain.
  Notes-from-the-field row cites the PR #5 precipitating chain.
- roles/shepherd/AGENT.md gains a cross-reference under Skills so the
  shepherd's escalation-class vocabulary aligns with the loop's
  rubric.
- CLAUDE.md inventory adds the new skill.

Per kriskowal directive on agoric-sdk#5 2026-06-16T00:39Z:
"there is a pattern that I have had to manually request continued
progress after CI settled ... please dispatch a gardener to fix the
loop and keep it going until CI is passing all tests."

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: endolinbot

CLAUDE.md

@@ -141,6 +141,6 @@ The constraint covers both **event-level** surveillance (the standing-monitor da
 ## Current inventory
 
 - Roles: `liaison`, `steward`, `monitor`, `review-queue`, `boatman`, `researcher`, `builder`, `assayer`, `cleaner`, `solicitor`, `barrister`, `justice`, `appellate`, `fixer`, `weaver`, `shepherd`, `conductor`, `designer`, `scout`, `botanist`, `major-general`, `gardener`, `evaluator`, `groom`, `investigator`, `journalist`, `librarian`, `scholar`, `timekeeper`. The prior `general-contractor` posture was retired 2026-06-03 per the maintainer's directive ("I have dismantled the contractor. The role has not been working and I would like to reconstruct it on the driver."); its design-queue-walk + slot-refill function is reconstructed as a deterministic `garden-design-poller` systemd service per `skills/design-poller/SKILL.md`, which posts jobs that driver lanes claim. The `researcher` (added 2026-06-03) precedes every designer and builder dispatch by default: orchestrators (liaison, steward) dispatch it with the proposed downstream prompt, inline its `## Library and project references` section, and only then dispatch the actual designer or builder. See each orchestrator's *Researcher precedence on designer and builder dispatches* section. The prior single `judge` role split into three on 2026-05-21: `solicitor` (designer work; design panel), `barrister` (builder work; first code-panel round), `justice` (fixer work; code-panel re-runs); `roles/judge/AGENT.md` is retained as a redirect. The `appellate` lands the same day to appeal `follow-up` and `acknowledge` dispositions on small-and-in-context items into `summary-fix` before un-draft. Plus the jury-seat roles dispatched by the three judges: a code panel for source-touching PRs and a design panel for design-only PRs (paths under `<project>/designs/`). See each judge's role file under `roles/<solicitor|barrister|justice>/AGENT.md` for the panel composition; the orchestrator never dispatches a juror seat directly.
-- Skills: `journal-sync`, `self-improvement`, `em-dash-style`, `relative-paths`, `no-latin-shorthand`, `agent-termination`, `rule-elision-test`, `inbox-drain`, `autonomous-loop-pacing`, `github-activity-poll`, `pr-ci-watch`, `review-queue-poll`, `rebase-before-followup`, `review-feedback-followup-commits`, `pr-review-thread-replies`, `pr-formation`, `pr-handoff`, `pr-creation-flow`, `pr-dependency-graph`, `pr-dependency-topo-sort`, `yarn-lock-separate-commit`, `pre-pr-checklist`, `regression-evidence`, `coverage-driven-testing`, `adversarial-tests`, `saboteur-adversarial-review`, `panel-review`, `ci-status-summary`, `ci-runtime-comparison`, `conflict-resolution`, `cherry-pick-followup`, `rebase-hygiene-audit`, `worktree-per-pr`, `process-documents`, `prompt-section-discovery`, `benchmark-comparative-report`, `verify-upstream-state-before-pinning`, `reactji-acknowledgment`, `changeset-discipline`, `rename-discipline`, `monitor-arming`, `context-library`, `journalism`, `dispatch-worktree`, `scheduling`, `velocity-recalibration`, `roadmap-projection`, `dependency-graph-maintenance`, `groom-open-questions`, `design-queue-drift-check`, `design-to-pr-pipeline`, `garden-ab-evaluation`, `merged-pr-feedback-watch`, `library-lookup`, `retcon`, `design-dependency-walk`, `stacked-pr-build`, `gap-revealing-build`, `at-mention-surveillance`, `job-board`, `pre-push-gates`, `node-lts-window-watch`, `panel-hints`, `frozen-base-branch`, `node-parity-test`, `test-title-spec-spelling`, `design-poller`, `model-selection`, `cleaner`, `gardener-inbox-error-reporting`, `driver-pr-creation-state-machine`, `driver-design-only-pr-workflow`, `driver-gardener-workflow`, `driver-librarian-workflow`, `prompt-on-failure-capture`, `activity-feed-watcher`. The driver workflow skills are the script-orchestrated PR-creation flow's agent context (per [designs/driver.md](designs/driver.md)); the executable counterparts live under `scripts/`. The `driver-gardener-workflow` and `driver-librarian-workflow` skills (added 2026-06-04) extend the driver pool to non-PR roles via role-prefixed lanes (`gardener-1`, `librarian-1`, etc.) per `designs/driver.md` § Role-prefixed lanes. Per-project monitor reaction skills (`monitor-endo`, `monitor-endo-but-for-bots`, `monitor-agoric-sdk`, `monitor-cosgov`, `monitor-garden`) live alongside but are configuration for the `monitor` role rather than independently reusable procedures. `monitor-garden` is the only one whose dispatched subagent runs as `liaison` rather than `monitor`; see that skill's *Dispatch role asymmetry* for why.
+- Skills: `journal-sync`, `self-improvement`, `em-dash-style`, `relative-paths`, `no-latin-shorthand`, `agent-termination`, `rule-elision-test`, `inbox-drain`, `autonomous-loop-pacing`, `github-activity-poll`, `pr-ci-watch`, `review-queue-poll`, `rebase-before-followup`, `review-feedback-followup-commits`, `pr-review-thread-replies`, `pr-formation`, `pr-handoff`, `pr-creation-flow`, `pr-dependency-graph`, `pr-dependency-topo-sort`, `yarn-lock-separate-commit`, `pre-pr-checklist`, `regression-evidence`, `coverage-driven-testing`, `adversarial-tests`, `saboteur-adversarial-review`, `panel-review`, `ci-status-summary`, `ci-runtime-comparison`, `conflict-resolution`, `cherry-pick-followup`, `rebase-hygiene-audit`, `worktree-per-pr`, `process-documents`, `prompt-section-discovery`, `benchmark-comparative-report`, `verify-upstream-state-before-pinning`, `reactji-acknowledgment`, `changeset-discipline`, `rename-discipline`, `monitor-arming`, `context-library`, `journalism`, `dispatch-worktree`, `scheduling`, `velocity-recalibration`, `roadmap-projection`, `dependency-graph-maintenance`, `groom-open-questions`, `design-queue-drift-check`, `design-to-pr-pipeline`, `garden-ab-evaluation`, `merged-pr-feedback-watch`, `library-lookup`, `retcon`, `design-dependency-walk`, `stacked-pr-build`, `gap-revealing-build`, `at-mention-surveillance`, `job-board`, `pre-push-gates`, `node-lts-window-watch`, `panel-hints`, `frozen-base-branch`, `node-parity-test`, `test-title-spec-spelling`, `design-poller`, `model-selection`, `cleaner`, `gardener-inbox-error-reporting`, `driver-pr-creation-state-machine`, `driver-design-only-pr-workflow`, `driver-gardener-workflow`, `driver-librarian-workflow`, `prompt-on-failure-capture`, `activity-feed-watcher`, `ci-failure-classification-loop`. The driver workflow skills are the script-orchestrated PR-creation flow's agent context (per [designs/driver.md](designs/driver.md)); the executable counterparts live under `scripts/`. The `driver-gardener-workflow` and `driver-librarian-workflow` skills (added 2026-06-04) extend the driver pool to non-PR roles via role-prefixed lanes (`gardener-1`, `librarian-1`, etc.) per `designs/driver.md` § Role-prefixed lanes. Per-project monitor reaction skills (`monitor-endo`, `monitor-endo-but-for-bots`, `monitor-agoric-sdk`, `monitor-cosgov`, `monitor-garden`) live alongside but are configuration for the `monitor` role rather than independently reusable procedures. `monitor-garden` is the only one whose dispatched subagent runs as `liaison` rather than `monitor`; see that skill's *Dispatch role asymmetry* for why.
 
 The `liaison` and `steward` are the two top-level orchestrator postures. When a user is in the loop (this terminal session), the liaison runs with excess authority and asks before acting. When the garden runs in the bot sandbox under safe bot credentials with no user present, the steward runs with bounded authority and may act on its own. Multiple stewards can run concurrently across hosts (and even within one host) and share work load via the journal's job board (`journal/jobs/`); the claim race resolves contention without a dedicated peer-role posture. Focused, parallelized PR-pipeline work that used to live in the retired `general-contractor` posture is now scripted: the `garden-design-poller` systemd service (per `skills/design-poller/SKILL.md`) walks the project's roadmap branch on a cadence and posts `build` jobs to the role-specific board, and driver lanes (per `designs/driver.md`) claim and advance them through the chain. The maintainer's framing on 2026-06-03: "I have dismantled the contractor. The role has not been working and I would like to reconstruct it on the driver." See `roles/liaison/AGENT.md` § Posture and `roles/steward/AGENT.md` § Posture for the two-posture contract.

roles/shepherd/AGENT.md

@@ -1,6 +1,6 @@
 ---
 created: 2026-05-13
-updated: 2026-06-14
+updated: 2026-06-16
 author: liaison, gardener
 ---
 
@@ -22,6 +22,7 @@ Assumes you have already read `roles/COMMON.md`.
 
 - [ci-status-summary](../../skills/ci-status-summary/SKILL.md): one-line-per-PR sweep across the open list.
 - [ci-runtime-comparison](../../skills/ci-runtime-comparison/SKILL.md): cross-branch runtime comparison via `gh api .../actions/runs`.
+- [ci-failure-classification-loop](../../skills/ci-failure-classification-loop/SKILL.md): orchestrator-side OODA loop wrapping multiple CI-cycle dispatches. The shepherd does not run the loop itself (its dispatch is one *Act* step inside the loop), but the classification rubric (A expected, B structural impasse, C tractable, D regression) is the same vocabulary the shepherd uses in its escalation classification. Cite the skill if a shepherd `result` enumerates multiple failure classes that span more than one cycle of follow-up work.
 - [pre-pr-checklist](../../skills/pre-pr-checklist/SKILL.md): applies in reverse. A failing lint check usually means the author skipped a step.
 - [autonomous-loop-pacing](../../skills/autonomous-loop-pacing/SKILL.md): for shepherd dispatches inside an autonomous-loop ticker, decide cadence per the cache-window rules.
 - [worktree-per-pr](../../skills/worktree-per-pr/SKILL.md): operate inside the dispatch root's `project/` worktree.

roles/steward/AGENT.md

@@ -1,6 +1,6 @@
 ---
 created: 2026-05-12
-updated: 2026-06-04
+updated: 2026-06-16
 author: gardener, steward, liaison
 ---
 
@@ -326,9 +326,20 @@ The chain does **not** apply when the shepherd's `result` carries `next: designe
 
 When the steward dispatches a fixer via this chain, the dispatch entry's `trigger:` field cites the shepherd's `result` path and the `next: fixer` verdict so the chain is traceable. A brief PR comment (when the staged authorization permits it) noting "shepherd reported real failures; dispatching fixer per standing rule" is preferable to a maintainer ping; the chain's visibility lives in the journal and the dispatch's own work product.
 
+### Fixer → fixer (CI failure classification loop)
+
+The Shepherd → fixer chain handles the first hop. The standing form (the OODA loop the steward runs across CI cycles on a single red-CI PR) lives in [`skills/ci-failure-classification-loop/SKILL.md`](../../skills/ci-failure-classification-loop/SKILL.md). Use it whenever a PR is mid-loop: a fixer returned, the orchestrator polled the next CI cycle, and the remaining red set needs reclassification and a next dispatch.
+
+The skill names the four classes the steward uses to orient (A expected, B structural impasse, C tractable, D regression) and the decision rule for picking the next class to dispatch against. The steward enters the loop whenever the maintainer's original directive on this PR was "drive to green" (or any of its synonyms in the *Direct-dispatch verbs* table) and CI is not yet green. The loop terminates on green, on A+B-only, on no-progress, or on a missing authorization; it does not terminate on the steward's uncertainty.
+
+The principle: the maintainer's authority to dispatch the next fixer is implicit in the original "drive this to green" directive and remains in force until the loop terminates. The steward does not stop at each red rollup to re-ask "what next?"; the classification rubric **is** the next-question's answer, and the per-cycle dispatch is the loop's *Act* phase.
+
+When the steward's per-cycle scan encounters a PR that is mid-loop (the most recent `result` entry for the PR carries a classification table and no termination block), this skill is the per-cycle action for that PR. It replaces the otherwise-default "stop and wait for maintainer direction" behavior on PRs the maintainer has explicitly delegated to the loop.
+
 ### Notes from the field
 
 - _2026-05-23_: this sub-section was added by gardener dispatch `fa60a7` per kriskowal directive 2026-05-23T07:07:53Z on PR #345. Precipitating cause: on 2026-05-22T22:46Z the shepherd-2abcf7 dispatch on PR #355 returned with six real failures recommending fixer dispatch, and the steward treated the recommendation as a hand-off requiring kriskowal authorization rather than as the authorization itself. The maintainer's correction ("Dispatch fixer." 2026-05-23T03:44Z; then the standing-rule directive on #345) made it explicit that the shepherd's "needs fixer" verdict is the authorization signal, not a request for one. The shepherd-side counterpart landed in the same engagement on `roles/shepherd/AGENT.md` § Escalation classification: name the next role.
+- _2026-06-16_: the *Fixer → fixer (CI failure classification loop)* sub-section was added by gardener dispatch `633f85` per kriskowal directive on `kriscendobot/agoric-sdk#5`: he had to manually re-prompt the steward three times to reclassify CI failures and dispatch the next fixer. Precipitating chain: fixer `ba72cd` (Class C async-flow type-check) → fixer `cb7a05` (Class A multichain-testing SES split) → fixer `cc9bb5` (Class A redux, dual-AVA install). At each cycle the steward stopped to re-ask rather than running the OODA loop autonomously. The new skill (`ci-failure-classification-loop`) codifies the rubric the maintainer was applying manually so the steward can run it forward without re-prompt; this sub-section is the steward-side citation that authorizes the loop's continuation under the original "drive to green" directive.
 
 ## Parked followup revisit