@clipboard-health/ai-rules 2.41.1 → 2.42.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clipboard-health/ai-rules",
-  "version": "2.41.1",
+  "version": "2.42.0",
   "description": "Pre-built AI agent rules for consistent coding standards.",
   "keywords": [
     "ai",

package/skills/cb-babysit/SKILL.md

@@ -19,9 +19,9 @@ Resolve bundled "./scripts" paths relative to SKILL.md.
 
 The skill uses two sentinels with visible footer lines.
 
-**Addressed sentinel**: `<sub>🤖 <code>cb-babysit:addressed v1 core@3.20.0</code></sub>`. Appended on its own line at the end of every reply the skill posts so re-runs know which threads and review-body comments are already handled. Dedupe also recognizes the legacy `babysit-pr:addressed v1` prefix from before this skill was renamed.
+**Addressed sentinel**: `<sub>🤖 <code>cb-babysit:addressed v1 core@3.21.0</code></sub>`. Appended on its own line at the end of every reply the skill posts so re-runs know which threads and review-body comments are already handled. Dedupe also recognizes the legacy `babysit-pr:addressed v1` prefix from before this skill was renamed.
 
-**Follow-up sentinel**: `<sub>🤖 <code>cb-babysit:followup v1 core@3.20.0</code></sub>`. Attached to replies that defer an out-of-scope comment as a tracked follow-up. The sentinel is additive: the post-reply scripts still append the `addressed` sentinel at the end.
+**Follow-up sentinel**: `<sub>🤖 <code>cb-babysit:followup v1 core@3.21.0</code></sub>`. Attached to replies that defer an out-of-scope comment as a tracked follow-up. The sentinel is additive: the post-reply scripts still append the `addressed` sentinel at the end.
 
 **Sentinel recency rules.** The script emits a per-thread `activityState` with three values. Step 6a owns the handling rules for each state.
 
@@ -247,7 +247,7 @@ Body templates (the script appends the `addressed` sentinel if missing):
 - **Agree**: `Addressed in <commit-url>. <one-line what-changed>.`
 - **Disagree**: `Leaving current behavior. <reasoning>.`
 - **Already fixed**: `Already handled by <commit-url-or-file:line>. <brief pointer>.`
-- **Defer**: `Out of scope for this PR; this looks like follow-up work rather than something introduced or required by this change. <one-line rationale or pointer if useful>.\n\n<sub>🤖 <code>cb-babysit:followup v1 core@3.20.0</code></sub>`
+- **Defer**: `Out of scope for this PR; this looks like follow-up work rather than something introduced or required by this change. <one-line rationale or pointer if useful>.\n\n<sub>🤖 <code>cb-babysit:followup v1 core@3.21.0</code></sub>`
 
 For Defer replies, include the follow-up sentinel on its own line as shown. The script will append the `addressed` sentinel after it on its own line, so the final body ends with the follow-up sentinel followed by a blank line followed by the `addressed` sentinel. `grep cb-babysit:followup` finds the deferral and `grep cb-babysit:addressed` still marks the thread handled for dedupe.
 
@@ -263,7 +263,7 @@ The PR-level summary should:
 
 - Group by source. Use `## Review-body findings` for step-7 work and `## Conversation-tab comments` for step-6b work. Omit a section if its list is empty.
 - Inside each section, group verdicts under **Agree / Disagree / Already fixed / Deferred (out of scope)** subheadings. Omit a subheading if its list is empty.
-- Under **Deferred (out of scope)**, list each deferred item as a bullet, followed on its own line by `<sub>🤖 <code>cb-babysit:followup v1 core@3.20.0</code></sub>` so grep catches them individually.
+- Under **Deferred (out of scope)**, list each deferred item as a bullet, followed on its own line by `<sub>🤖 <code>cb-babysit:followup v1 core@3.21.0</code></sub>` so grep catches them individually.
 - Include the commit URL for fixes.
 - End with a fenced fingerprint block listing every current fingerprint (addressed and deferred) one per line. Include both `reviewBodyComments[].fingerprint` (whole-body, one per automated review) and `activeIssueComments[].fingerprint` (per Conversation-tab comment). Future runs dedupe by matching these against `priorBabysitSentinels`.
 

package/skills/cb-babysit/scripts/_sentinel.sh

@@ -10,7 +10,7 @@
 
 SENTINEL_PREFIX='cb-babysit:addressed v1 '
 LEGACY_SENTINEL_PREFIX='babysit-pr:addressed v1 '
-SENTINEL='<sub>🤖 <code>cb-babysit:addressed v1 core@3.20.0</code></sub>'
+SENTINEL='<sub>🤖 <code>cb-babysit:addressed v1 core@3.21.0</code></sub>'
 
 # Bot author allowlist (JSON array literal). Used by unresolvedPrComments.sh
 # as a fallback when GraphQL's `author.__typename == "Bot"` misses a GitHub

package/skills/cb-ship/references/pr-template.md

@@ -17,5 +17,5 @@ Concisely explain the user intent from session history and the meaningful behavi
 
 Optional, don't fabricate: ticket links, rollout plan, residual risk, or specific areas for reviewers to focus.
 
-<sub>🤖 <code>cb-ship:created v1 core@3.20.0</code></sub>
+<sub>🤖 <code>cb-ship:created v1 core@3.21.0</code></sub>
 ```

package/skills/flaky-closeout/SKILL.md

@@ -0,0 +1,281 @@
+---
+name: flaky-closeout
+description: Sweep the flaky-test pipeline after fixes merge by closing out the root-cause KB, closing clearly superseded tickets as Done under D3, and re-dispatching critic-rejected plans for amendment. Use for the recurring flaky close-out task, a post-merge flaky-fix sweep, or a dry-run/backtest of close-out decisions.
+---
+
+<!-- cspell:ignore backtest backtesting groundcrew redispatch worktree -->
+
+# Flaky Closeout
+
+Run three post-merge sweeps in one read-first, write-later pass. This stage
+maintains the pipeline's learning and dispatch loops; it does not diagnose new
+root causes or implement product fixes.
+
+Read these files before deciding or writing:
+
+- `../flaky-debug/references/fix.md` for the KB close-out contract.
+- `../flaky-debug/references/root-cause-kb/README.md` and every plausible KB
+  entry.
+- `../flaky-critic/SKILL.md` and its rubric for D3, marker, and second-reject
+  semantics.
+- `../create-groundcrew-ticket/SKILL.md` for dispatch eligibility.
+- `../blind-backtest/SKILL.md` when running `--backtest`.
+- [Comment templates](./references/comment-templates.md) before posting.
+
+## Invariants
+
+- Never cancel a ticket. Cancel authority remains human-only.
+- Close a superseded ticket as **Done**, not Canceled or Duplicate. Done enters
+  the 21-day verifying window so the recurrence loop can reopen a false
+  supersession.
+- Require a clear mechanism match before D3 closure: the same KB entry or
+  causal mechanism **and** the same failure-signature class.
+- Decide the complete action ledger before any external write.
+- Search existing comments for the exact marker before every write. A marker is
+  a lease for that action, not a substitute for checking current state.
+- Batch all KB changes from one run into one focused `core-utils` PR. Never
+  commit directly to the default branch and never auto-merge.
+- Do not schedule or re-arm this skill. When invoked by a recurring task, follow
+  re-arm instructions from the task description only after the digest.
+
+## Modes and window
+
+Support these modes:
+
+- **Production:** perform reads, build the ledger, then write.
+- **`--dry-run`:** perform every read and decision, but make no Linear, GitHub,
+  git, or repository write. Print the exact proposed comments, state changes,
+  and KB diff plan. Represent the unavailable KB PR URL as
+  `<future KB PR for run <run-key>>`.
+- **`--backtest`:** imply `--dry-run` and follow `../blind-backtest/SKILL.md`.
+  Freeze the requested historical cutoff and keep judgments isolated from the
+  answer key. If separate assembler and judge contexts are unavailable, stop
+  and report that the blind protocol cannot be satisfied.
+
+Before the first production run for a new rule revision, run a backtest and a
+current dry run as separate invocations. Do not promote from historical results
+alone.
+
+Use an explicit `--since` value or the last successful-run timestamp supplied
+by the recurring task, subtracting three days for overlap. If neither exists,
+look back 21 days. Accept `--bounce-age-days`; default to 3. Print the effective
+window, overlap, cutoff, and bounce age in the digest.
+
+## Phase 1: Build the source manifest
+
+Start these independent discovery reads concurrently:
+
+- primary merged-PR search;
+- missing-label Linear fallback;
+- non-terminal flaky-ticket universe;
+- bounced-ticket queue.
+
+After discovery, deduplicate ticket IDs and fetch each full issue and comment set
+once. Cache the records for the entire run.
+
+### Merged-fix manifest
+
+Search merged PRs across the `ClipboardHealth` organization:
+
+1. Primary source: every merged PR carrying `flaky-test-fix` in the effective
+   window. Paginate; do not trust a single result page.
+2. Label-hygiene fallback: recent `flaky-implementation` and chronic deep-dive
+   tickets whose linked PR merged in the window and demonstrably fixed a flaky
+   mechanism, even when the PR omitted the label. Require the PR body or Linear
+   attachment to identify the source ticket. Record a missing-label digest
+   risk; do not mutate PR labels.
+3. Exclude closed-unmerged PRs. Deduplicate by repository and PR number.
+
+Build a cheap first-pass PR record:
+
+- repository, PR URL, merge timestamp, merge commit, title, and labels;
+- source Linear ticket ID from the PR body or attachment;
+- cached source ticket ID and related-ticket IDs.
+
+Hydrate changed files, diff, detailed validation evidence, and full related
+tickets only after a pending KB close-out or plausible D3 join makes the PR
+actionable. From the hydrated records, extract `KB match:`, pending
+`Knowledge-base close-out`, causal mechanism, signature class, validation
+evidence, and every flake sighting timestamp.
+
+If a PR lacks a source ticket ID, report it as unresolved and take no close-out
+action for it.
+
+### Bounce manifest
+
+List `flaky-implementation` tickets in Triage. Fetch each issue and all comments;
+list results truncate descriptions.
+
+Keep a ticket only when it has:
+
+- a critic marker with `mode=enforce` and `verdict=reject`; current markers also
+  carry `disposition=amend-and-resubmit` or
+  `disposition=substantive-reject`, while legacy markers may omit disposition;
+- a verdict older than the bounce-age threshold;
+- no later plan amendment that addresses the verdict;
+- no completed close-out re-dispatch for that verdict.
+
+Use the verdict comment ID when available; otherwise use its timestamp. A later
+issue edit is only a possible amendment: read the current plan and confirm that
+it addresses each cited rule before skipping re-dispatch.
+
+Treat `verdict=needs-human disposition=second-reject` as terminal
+`needs-human`. Also classify two enforce-mode rejects separated by a plan
+amendment as `needs-human` when processing older marker formats. Never
+re-dispatch either case; include it in the digest for Rocky.
+
+A re-dispatch marker on a ticket that is still Groundcrew-ineligible means
+`eligibility mutation pending`, not `skip`. Resume only the missing eligibility
+changes; do not post the comment again.
+
+Phase 1 is complete only when every manifest item has full ticket descriptions
+and comments. Do not decide against truncated list results.
+
+## Phase 2: Sweep KB close-outs
+
+Inspect both the source ticket and related or superseded implementation tickets.
+A pending close-out can live on a different fingerprint family than the PR that
+fixed its mechanism.
+
+For every pending close-out:
+
+1. Confirm the target PR merged. If not, leave it pending and report it.
+2. Resolve the plan's `KB match:` to an existing entry. If the plan says none,
+   create a new entry only when the evidenced causal terminus is genuinely new.
+3. Compare the plan, merged diff, validation, and related recurrence. Prepare
+   the required dry-run statement from `flaky-debug/references/fix.md`.
+4. Record:
+   - the recurrence or variant addressed;
+   - the landed fix and PR;
+   - any newly established partial or failed-scope lesson;
+   - affected repository/surface, evidence, current status, and `Last reviewed`;
+   - symptom-index changes only when the new signature is more discriminating.
+5. Deduplicate updates by KB entry and mechanism. One PR can close several
+   tickets; one KB entry should receive one coherent edit.
+
+Use this completed-action marker only after the focused KB PR exists:
+
+```html
+<!-- flaky-closeout: kb-done pr=<full-core-utils-pr-url> -->
+```
+
+After the action ledger is complete, sort each KB action as
+`<entry-path>|<source-PR>|<affected-ticket-IDs>` and hash the resulting list.
+Derive the run key from the recurring task's scheduled occurrence ID or exact
+UTC cutoff timestamp plus the first 12 characters of that ledger hash. Use
+deterministic branch `flaky-closeout/<run-key>` and put this marker in the PR
+body:
+
+```html
+<!-- flaky-closeout: kb-run=<run-key> ledger=<full-hash> -->
+```
+
+Before creating a branch or PR, search that exact head branch. Reuse an open or
+merged PR only when its trusted PR-body marker has the same run key and full
+ledger hash. A different ledger always gets a different run key, even on the
+same day. This verified PR lookup is the idempotency key when a prior run
+created the KB PR but failed before commenting on every ticket.
+
+In production, create a fresh `core-utils` worktree on that branch, apply every
+recorded KB edit, run `node --run sync-ai-rules` and `node --run verify` with the
+repository Node version, and ship one PR through the repository's
+`cb-work`/`cb-ship` workflow. Link the PR in a close-out comment on every
+affected ticket. If the PR cannot be created, do not post the marker; report
+the failure and leave the close-out retryable. If the PR exists, reuse it and
+retry only missing ticket comments.
+
+## Phase 3: Sweep supersessions under D3
+
+From the Phase 1 cache, build indexes over every non-terminal ticket labeled
+`flaky-investigation` or `flaky-implementation`: normalized KB entry, causal
+mechanism, signature class, source PR, and fingerprint family. Join every
+merged fix against those indexes. Do not limit the join to the source
+fingerprint family and do not repeat the organization-wide ticket scan per PR.
+
+Use the KB mechanism as the cross-family join key:
+
+1. Resolve each candidate's `KB match:` line. If it has no line, require
+   equivalent explicit causal evidence in its plan; text similarity alone is
+   insufficient.
+2. Confirm the merged PR fixes the same causal locus, not merely a nearby
+   symptom.
+3. Confirm the signature class matches, such as provider-topology remount,
+   query-row overlay teardown, Cognito alias lookup, or CDC readiness.
+4. Parse the candidate's earliest relevant sighting timestamp and prove it is
+   earlier than the PR merge timestamp. If no reliable sighting time exists, do
+   not close.
+5. Check that the ticket has no post-merge recurrence for that mechanism.
+
+Classify the candidate:
+
+- **Clear match:** stage the D3 comment from
+  [comment templates](./references/comment-templates.md), then set the ticket to
+  Done. Include the PR, mechanism, sighting and merge timestamps, 21-day
+  verifying window, and recurrence-loop reopen safety net.
+- **Ambiguous:** stage one possible-supersession comment tagging Rocky and leave
+  state unchanged.
+- **No match:** take no action.
+
+Markers:
+
+```html
+<!-- flaky-closeout: superseded-by=<full-source-pr-url> -->
+<!-- flaky-closeout: possible-supersession pr=<full-source-pr-url> -->
+```
+
+Post the clear-match comment before setting Done. If the state update fails,
+retain the comment marker and retry only the missing state change on the next
+run. A supersession marker on a still-open ticket therefore means
+`state-change pending`, not `skip`. Never change a ticket to Canceled.
+
+## Phase 4: Sweep bounced plans
+
+For each eligible first-bounce ticket:
+
+1. Quote the decisive critic verdict and rule IDs.
+2. State the exact plan amendment required; do not propose the implementation
+   fix yourself.
+3. Validate every field against the eligibility contract in
+   `../create-groundcrew-ticket/SKILL.md`.
+4. Post the re-plan instruction with the verdict-specific marker, then make only
+   the state, assignee, and label changes required to restore eligibility. Do
+   not rewrite repository, parent, or blocker semantics.
+
+Do not re-dispatch when a later plan already addresses the verdict, the same
+verdict marker exists, or this is the second bounce. Leave second bounces in
+Triage and list them as `needs-human`.
+
+## Phase 5: Execute and verify
+
+In production, execute the already-decided ledger in this order:
+
+1. Create the single KB PR and add KB close-out comments.
+2. Post D3 or possible-supersession comments and apply D3 state changes.
+3. Post bounce instructions and restore Groundcrew eligibility.
+
+Execute each ticket's ordered mutation bundle, then refetch it once. Verify only
+the marker, state, assignee, labels, relations, and linked PR fields that bundle
+could change. Preserve individual mutation failures in the ledger so the next
+run can reconcile marker versus state. Continue independent actions after one
+failure, but never claim a failed action succeeded.
+
+In dry-run or backtest, print the same ordered ledger with exact comment bodies
+and state mutations, prefixed `WOULD`; write nothing.
+
+## Phase 6: Digest
+
+End with:
+
+- effective window, mode, merged PR count, source-ticket resolution count, and
+  missing-label fallbacks;
+- KB entries and tickets updated, pending, skipped by marker, and KB PR URL;
+- D3 closed, possible supersessions, no-match candidates, and state failures;
+- bounce candidates, re-dispatched, already amended, marker-skipped, and
+  needs-human;
+- every ambiguity, missing timestamp, missing ticket ID, incomplete evidence,
+  or failed write.
+
+When backtesting, use the blind-backtest output contract. See the checked-in
+[2026-07-17 acceptance report](./references/acceptance-report-2026-07-17.md).
+It records a targeted historical check, not a reusable backtest fixture or
+approval for future live rule revisions.

package/skills/flaky-closeout/references/acceptance-report-2026-07-17.md

@@ -0,0 +1,110 @@
+<!-- cspell:ignore backtest -->
+
+# 2026-07-17 Acceptance Report
+
+This is a targeted, write-free acceptance check for the handoff examples. It is
+not a promotion-grade blind backtest, a reusable test fixture, or a replacement
+for live shadow agreement.
+
+## Cohort and cutoff
+
+- Window: `2026-06-26T00:00:00Z` through `2026-07-17T14:30:00Z`.
+- Primary PR scan: 31 merged `flaky-test-fix` PRs: 23 in
+  `cbh-admin-frontend`, five in `cbh-mobile-app`, and three in
+  `clipboard-health`.
+- Source-ticket resolution: 30 of 31 primary PRs carry a `STAFF-*` ID in the
+  title or body. `clipboard-health#26528` is unresolved and therefore produces
+  no action.
+- Merged fix: `ClipboardHealth/cbh-admin-frontend#7608`, merged
+  `2026-07-17T13:08:25Z`, source ticket `STAFF-1846`.
+- Supersession candidate: `STAFF-1856`, sighting
+  `2026-07-16T14:30:36Z`.
+- Bounce cohort: `STAFF-1860`, `STAFF-1862`, `STAFF-1868`, `STAFF-1873`, and
+  `STAFF-1874`; critic verdicts were posted around `2026-07-17T12:09Z`.
+- Bounce evaluation time: `2026-07-17T14:30:00Z` with
+  `--bounce-age-days=0`. This override tests verdict detection and routing;
+  production retains the three-day default so later amendments can suppress
+  re-dispatch.
+
+The decision pass uses ticket plans, verdict text, PR body and diff metadata,
+merge time, and sighting time. Human close-out outcomes are used only in the
+result comparison.
+
+The KB contract landed at the end of this window. A full-description Linear
+search for `KB close-out` found two implementation plans: `STAFF-1856`, whose
+mechanism was fixed by merged #7608, and `STAFF-1874`, whose proposed fix had
+not merged and therefore remains pending. The bounce scan found the five named
+Triage tickets below.
+
+## Proposed dry-run actions
+
+### KB close-out
+
+`STAFF-1856` contains a pending close-out for
+`query-driven-list-dialog-teardown.md`. PR #7608 fixes the provider-topology
+variant that remounted the authenticated route above the open Home Health menu.
+
+Expected update:
+
+- Add the provider-topology recurrence as another replaceable-ancestor surface.
+- Record #7608 and its delayed or immediate-token regression coverage.
+- Record that the dialog-only hoist in #7574 was correctly scoped but could not
+  prevent a remount from a higher provider boundary.
+- Link the resulting focused `core-utils` KB PR from `STAFF-1856` and
+  `STAFF-1846`.
+
+### D3 supersession
+
+Would close `STAFF-1856` as Done under D3:
+
+- same terminal cause: token-dependent `KnockProviderWrapper` topology switch
+  remounts the authenticated route;
+- same signature class: an already-resolved menu item detaches before its user
+  action starts;
+- sighting `2026-07-16T14:30:36Z` predates merge
+  `2026-07-17T13:08:25Z`;
+- #7608 changed the same composition files named by the plan and added the
+  requested token-resolution regression.
+
+The PR lacked the `flaky-test-fix` label, so it is admitted only through the
+linked flaky deep-dive ticket fallback and reported as a label-hygiene risk.
+
+### Bounce re-dispatch
+
+Would re-dispatch each first bounce to Todo for plan amendment:
+
+| Ticket     | Verdict gap to carry into the re-plan instruction                                         |
+| ---------- | ----------------------------------------------------------------------------------------- |
+| STAFF-1860 | C1 requires same-identity reconciliation after ambiguous 504, fresh identity on collision |
+| STAFF-1862 | A3 plan must state fake-timer restoration in `afterEach`                                  |
+| STAFF-1868 | B1 forbids token-minting refresh retries without non-amplifying control                   |
+| STAFF-1873 | B1/B6/B8 require no uncapped 429 retry and a terminated causal chain                      |
+| STAFF-1874 | B1/B6/B8 require no uncapped 429 retry and a terminated owning-service cause              |
+
+No ticket had a prior closeout re-dispatch marker or a second critic rejection
+at the frozen cutoff. Their critic comments use the legacy
+`verdict=reject mode=enforce` marker without a disposition field; the bounce
+scan accepts that enforce-only shape while still excluding shadow markers.
+
+## Outcome comparison
+
+- **D3:** match. Rocky's `STAFF-1856` close-out cited #7608, the exact mechanism,
+  the pre-merge sighting, Done, the 21-day verifying window, and recurrence
+  reopen behavior.
+- **KB:** match. The human close-out explicitly transferred the
+  provider-topology recurrence, #7608, and the dialog-only-hoist scope lesson to
+  the KB close-out.
+- **Bounces:** all five verdicts are detected with the required amendment
+  content. This report evaluates routing, not whether the later planner
+  produced an acceptable amendment.
+
+## Limitations
+
+- The cohort was selected from named handoff examples and is not balanced.
+- The #7608 missing-label fallback is necessary for this case but needs live
+  monitoring for false inclusion.
+- The acceptance check does not grade ambiguous supersession precision,
+  second-bounce handling, KB edit quality across multiple entries, or live
+  tool/write idempotency.
+- Before production scheduling, run a larger blind backtest and a live
+  write-free shadow pass.

package/skills/flaky-closeout/references/comment-templates.md

@@ -0,0 +1,58 @@
+<!-- cspell:ignore redispatch -->
+
+# Flaky Closeout Comment Templates
+
+Fill every placeholder from fetched evidence. Do not post a state-changing
+template with an unknown timestamp, mechanism, or PR. A possible-supersession
+comment may use its explicit missing-timestamp statement because it leaves state
+unchanged.
+
+## KB close-out
+
+```markdown
+<Use the canonical final close-out statement from
+flaky-debug/references/fix.md verbatim.>
+
+<!-- flaky-closeout: kb-done pr=<KB PR URL> -->
+```
+
+## Clear D3 supersession
+
+```markdown
+Already fixed (D3): covered by merged PR <source PR URL> from <source ticket>.
+It fixes the same mechanism: <mechanism and causal locus>. This ticket's
+<signature class> sighting at <sighting timestamp> predates the merge at
+<merge timestamp>.
+
+Closing Done: the family enters the 21-day verifying window. If this mechanism
+flakes again, the recurrence loop reopens the ticket with its history.
+
+<!-- flaky-closeout: superseded-by=<source PR URL> -->
+```
+
+## Possible supersession
+
+```markdown
+@Rocky Warren possible supersession: merged PR <source PR URL> may cover this
+ticket through <shared mechanism>, but <specific ambiguity> prevents a D3
+closure. The relevant sighting is <timestamp or missing-timestamp statement>.
+Please confirm the mechanism match; state is unchanged.
+
+<!-- flaky-closeout: possible-supersession pr=<source PR URL> -->
+```
+
+## Bounce re-dispatch
+
+```markdown
+Re-dispatching for plan amendment after the critic verdict at <verdict link or
+timestamp>.
+
+Required amendment:
+
+- <rule ID>: <specific missing or contradicted plan statement>
+
+Amend the plan against the verdict, preserve the existing investigation
+evidence, and resubmit it to the critic before implementation.
+
+<!-- flaky-closeout: bounce-redispatch verdict=<comment ID or timestamp> -->
+```

package/skills/flaky-critic/SKILL.md

@@ -47,9 +47,15 @@ VERDICT: reject — B2, B6
 - B2: "increase the navigation timeout to 30s" — timeout inflation without a root-cause statement of why the operation is legitimately slow.
 - B6: plan states confidence 3/5 but has no observability-to-reach-5/5 section.
 Fix class claimed: A1 (readiness gate). Missing required evidence: polled signal is not shown to be the one the failing UI path uses.
-<!-- flaky-critic: verdict=reject mode=enforce -->
+<!-- flaky-critic: verdict=reject mode=enforce disposition=substantive-reject statement-missing=B6 substantive=B2 -->
 ```
 
+- Every verdict marker must record `disposition`, `statement-missing`, and `substantive`. Use comma-separated rule tokens and `none` when a bucket is empty. Distinguish B5's checks as `B5-dedup` and `B5-prior-attempts`; use the normal rule ID for every other rule. Use these dispositions:
+  - approve: `verdict=approve disposition=release statement-missing=none substantive=none`;
+  - statement-only reject: `verdict=reject disposition=amend-and-resubmit`;
+  - any demonstrated violation: `verdict=reject disposition=substantive-reject`;
+  - low-confidence or out-of-taxonomy escalation: `verdict=needs-human disposition=needs-human`;
+  - second reject on revised content: `verdict=needs-human disposition=second-reject`.
 - **enforce**: approve → move the ticket to Todo and assign it to the Linear API user. Reject → comment and leave in Triage; the investigating flow gets one bounce. A second reject on the same ticket → comment `needs-human` and stop touching it.
 - **shadow**: comment only, prefixed `[shadow]`, marker `mode=shadow`.
 - **needs-human**: comment with what the rubric cannot answer; never move the ticket.
@@ -60,7 +66,40 @@ When you encounter a ticket where a human's action contradicts your prior verdic
 
 ## Phase 5: Digest
 
-End with: tickets reviewed, verdicts by type with rule-ID counts, agreement events observed (human actions vs prior verdicts), amendment proposals drafted, and tickets skipped as already-current. When run as a recurring task, this digest is the run's final message.
+End with: tickets reviewed, verdicts by type with rule-ID counts, agreement events observed (human actions vs prior verdicts), amendment proposals drafted, tickets skipped as already-current, and the monitoring block below. When run as a recurring task, this digest is the run's final message.
+
+### B8 and Prior-attempts monitoring
+
+Monitor the first 14 days after both rules are live: **starting 2026-07-16 and ending before 2026-07-30**. During the window, query Groundcrew `flaky-implementation` tickets updated on or after 2026-07-16 across all states and read their full comments; list results and the current queue are not a cumulative data source. Recompute the window from `mode=enforce` critic markers so the result survives separate sessions.
+
+On or after 2026-07-30, coordinate finalization on STAFF-1818 with deterministic run key `2026-07-16--2026-07-30`:
+
+Only honor coordination markers authored by the configured Linear API user that runs flaky-critic. Read authorship and creation time from Linear's server-provided comment metadata; embedded `claimed-at` and `lease-until` values are descriptive, not authority. Ignore markers from other authors, markers with a mismatched run key, future-dated markers, and leases whose server creation time plus the documented duration has expired. For linked GitHub or Linear actions, also require the expected repository or project, exact title suffix, run key, and an artifact author/creator attributable to the same trusted automation.
+
+1. If a trusted `<!-- flaky-critic: b8-prior-monitoring-finalized run=2026-07-16--2026-07-30 -->` is present, omit this monitoring block.
+2. Otherwise post `<!-- flaky-critic: b8-prior-monitoring-claim run=2026-07-16--2026-07-30 claimed-at=<ISO timestamp> -->`, then re-read all comments. The earliest trusted non-stale claim by server creation time wins; later claimants stop. A claim is stale 60 minutes after its server creation time when no trusted action or finalized marker exists, allowing a later run to take over.
+3. Before creating side effects, search STAFF-1818 comments, Linear tickets, and GitHub PRs for a trusted `<!-- flaky-critic: b8-prior-monitoring-action run=2026-07-16--2026-07-30 -->`. Reuse the validated linked action when present.
+4. When a new action is required, the claim winner posts `<!-- flaky-critic: b8-prior-monitoring-action-started run=2026-07-16--2026-07-30 owner=<claim comment ID> lease-until=<ISO timestamp> -->` with a four-hour lease, then re-reads STAFF-1818. The earliest trusted unexpired action lease wins; later action starters stop. Calculate expiry from the server creation time, require `owner` to reference the winning trusted claim, and treat renewals as new trusted comments from that owner. Renew before invoking `cb-work` and at least every three hours while work continues.
+5. Revalidate trusted ownership and repeat the action search immediately before any PR or ticket creation. Search-and-re-read is a secondary guard, not the uniqueness mechanism: the creator must use a server-enforced idempotency key or unique external ID derived from the run key. For GitHub, use deterministic head branch `flaky-critic-monitoring/2026-07-16--2026-07-30`; if branch or PR creation reports that it already exists, look up and reuse the existing PR. A Linear fallback ticket may be created only when the available creator provides an atomic idempotency or uniqueness facility; otherwise post `needs-human` on STAFF-1818 instead of risking a duplicate. The `cb-work` request must carry these requirements through its shipping step. Any new PR or ticket must carry the action marker, an exact `STAFF-1818 monitoring` title suffix, and the deterministic run key. A takeover is allowed only after the prior trusted action lease expires with no validated action marker.
+6. Run the final aggregation and complete any threshold or amendment action below. Post the final digest and all action links to STAFF-1818 with the finalized marker. Write it only after required actions exist.
+
+- **Denominator — gated plans:** one verdict marker per unique ticket content-state in the window, including approve, reject, and needs-human. Exclude shadow/backtest verdicts, PR-checkpoint comments, and already-current skips. The one-verdict-per-content-state rule makes each marker one denominator event.
+- **Numerator — statement-missing bounces:** gated plans whose marker has `disposition=amend-and-resubmit` and names `B8` or `B5-prior-attempts` in `statement-missing`. Count a plan once in the headline numerator even when both rules fired; also report per-rule attribution, where one plan may count under both.
+- **Substantive rejects:** report `B8` and `B5-prior-attempts` substantive counts separately. When a human later releases one, compare the cases by mechanism. Any systematic substantive false-reject pattern, regardless of rate, requires a concrete rubric amendment proposal for Rocky's approval using `<!-- flaky-critic: amendment-proposal -->`; never edit or weaken the rubric silently.
+- **Harness-contract watch:** record every plan that invokes B8's harness-contract terminus, including whether the critic accepted an evidenced contract or rejected a generic detach, timeout, 401, or retry-success symptom as laundering. Compare later human outcomes for both accepted and rejected cases. Report any repeated stretch pattern in the substantive-pattern finding; do not broaden the exception from monitoring evidence without Rocky's per-PR approval.
+- **Threshold:** report the cumulative statement-missing numerator, denominator, percentage, and per-rule attribution as provisional during the window. When the denominator is zero, report `N=0`, omit the percentage as not evaluable, and do not trigger a breach. At the window close, **more than 25%** triggers a fix-forward change in the narrowest flaky-debug plan-producing source: normally `references/plan.md` for a missing output field, or `SKILL.md` when the investigation flow failed to collect the required evidence. `plan-e2e.md` and `plan-fast-path.md` already converge on the shared output template; do not duplicate requirements across them. Invoke `core:cb-work`/`cb-work` against `ClipboardHealth/core-utils` with the observed omission and required template change; if that workflow is unavailable, create a linked Groundcrew implementation ticket only through the atomic uniqueness path above. Include the resulting PR or ticket link in the final digest before writing the finalization marker. Do not change B8 or the Prior-attempts gate to reduce the rate.
+
+Use this digest shape:
+
+```text
+New-rule monitoring (2026-07-16..<2026-07-30):
+- gated plans: N
+- statement-missing amend-and-resubmit: N — rate: P% | not evaluable (when gated plans=0) — B8: N, B5-prior-attempts: N
+- substantive rejects — B8: N, B5-prior-attempts: N
+- harness-contract terminus watch: N invoked — accepted: N, laundering rejects: N, human reversals: N
+- threshold: provisional | pass | breached — <fix-forward action or "none">
+- substantive false-reject patterns: <amendment proposal links or "none observed">
+```
 
 ## PR checkpoint (when the task description asks for it)