@clipboard-health/ai-rules 2.43.0 → 2.43.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@clipboard-health/ai-rules",
-  "version": "2.43.0",
+  "version": "2.43.1",
   "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.22.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.22.1</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.22.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.22.1</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.22.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.22.1</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.22.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.22.1</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.22.0</code></sub>'
+SENTINEL='<sub>🤖 <code>cb-babysit:addressed v1 core@3.22.1</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.22.0</code></sub>
+<sub>🤖 <code>cb-ship:created v1 core@3.22.1</code></sub>
 ```

package/skills/flaky-critic/references/rubric.md

@@ -90,7 +90,7 @@ Proposing a code fix from a diagnosis that stops at the failure symptom — "the
 
 1. **Terminated:** the chain ends at a cause. A status code, timeout, or throttle is a link, never a terminus.
 2. **Explicitly broken:** the chain names the link where evidence ran out and the observability that would extend it; confidence is capped at 2/5 and B6 applies — the deliverable is the instrumentation, not a code fix.
-3. **Harness-contract terminus:** for a C1/C2 test-harness change, the chain may terminate at a specific violated harness contract in named code when artifacts prove the user action or downstream request never began, and the fix is bounded, idempotent, and diagnostic. If a product, service, or identity-provider cause may still exist, cap confidence at 3/5 and require owning-surface observability or a linked handoff. A generic timeout, detach, 401, or retry success without the named contract and evidence remains a symptom, not a terminus.
+3. **Harness-contract terminus (amendment, 2026-07-17):** for a C1/C2 test-harness change, the chain may terminate at a specific violated harness contract in named code when artifacts prove the user action or downstream request never began, and the fix is bounded, idempotent, and diagnostic. If a product, service, or identity-provider cause may still exist, cap confidence at 3/5 and require owning-surface observability or a linked handoff. A generic timeout, detach, 401, or retry success without the named contract and evidence remains a symptom, not a terminus.
 
 **Confidence ceiling:** 5/5 additionally requires reproduction by inducing the blamed cause — fault injection in the harness (delay or fail the specific response, disable the seed step) or a focused lower-level test that deterministically reproduces the race. Without reproduction, the ceiling is 4/5. One inferred _intermediate_ link with an evidenced terminus is still a terminated chain (≤4/5); an unevidenced terminus is a broken chain (cap 2/5).
 
@@ -230,6 +230,8 @@ The STAFF-1818 blind-backtest proposals were reviewed per the standing per-PR am
 2. **Harness-contract terminus — approved with live monitoring:** the exception is limited by the artifact, confidence, and observability guardrails in B8. The 14-day monitor specifically watches for generic detach, timeout, 401, or retry-success symptoms being laundered as a harness contract.
 3. **Mechanism-aware Prior-attempts counting — rejected:** agent-claimed novelty does not reduce the failed-fix count. The ≥2 route remains family-level, and the dossier-backed deep dive adjudicates mechanism identity first.
 
+**Live follow-up (Rocky, 2026-07-17):** the backtest's case 1865 analog and the live false-positive rejection on STAFF-1865 established the harness-contract terminus amendment. No additional Proposal 1 change was approved because the live run produced no applicable case; that follow-up is deferred pending live evidence. Proposal 3 remains rejected because the dossier-backed deep dive, not agent self-certification, adjudicates mechanism novelty.
+
 ## 8. Appendix: corpus stats
 
 **Read:** 753 Linear issues enumerated (636 flaky-labeled; statuses: Done 431, Duplicate 156, Canceled 37, open 12); comments read on ~35 sampled issues (weighted to Canceled/canonical/impl tickets — most per-test tickets have only bot sighting comments). 88 `flaky-test-fix` PRs enumerated (74 merged, 13 closed, 1 open); bodies/diffs/review threads read on ~25; Rocky-authored review/issue comments harvested across all 88 (79 inline + 37 conversation comments, mostly cb-babysit); 4 skill-update PRs in core-utils; flake-intake pipeline templates in ClipboardHealth/clipboard.

package/skills/flaky-debug/references/fix.md

@@ -10,7 +10,10 @@ Before editing, verify the plan is still current:
 
 - The failing commit's code path still exists on current `main`, or the plan has been adjusted for the current code.
 - The proposed fix targets the diagnosed failure surface, not only the final assertion.
-- Any retry/wait change is safe and idempotent; it must not repeat one-time credentials, duplicate writes, destructive actions, or rate-limited setup calls.
+- Any retry/wait change is safe and idempotent; it must not repeat one-time credentials, duplicate writes, or destructive actions.
+- The retry predicate names the exact transient failure signatures it matches: opaque 5xx yes; 4xx validation no; 429 only with a cap.
+- The retry has a finite attempt or total-call bound, and exhaustion reports the attempts plus the last stdout/stderr/status/body.
+- A retry against a rate-limited or quota-limited dependency such as Cognito, a 429-emitting API, token minting, one-time credential provisioning, or seed creation states its concurrency cap or call-volume bound. Without one, return to the plan and choose A7-style serialization or caching to de-stress the dependency. An uncapped retry is retry amplification and will be rejected under B1; a cap does not make a non-idempotent operation safe.
 
 ## Validate the Sibling Frontend Check
 

package/skills/flaky-debug/references/plan.md

@@ -51,9 +51,12 @@ Before proposing any retry, timeout, or wait change, pass the idempotency check:
 - Is the retried operation safe to repeat?
 - Does retrying preserve the same test scenario?
 - Could retrying amplify the root cause, such as rate limits, one-time credentials, duplicate writes, or destructive mutations?
+- Does the retry predicate name the exact transient failure signatures it matches (opaque 5xx yes; 4xx validation no; 429 only with a cap)?
+- Does the plan set a finite attempt or total-call bound, with exhaustion reporting the attempts and last stdout/stderr/status/body?
+- For a rate-limited or quota-limited dependency such as Cognito, a 429-emitting API, token minting, one-time credentials, or seed creation, does the plan state a concurrency cap or call-volume bound?
 - Is there a deterministic signal to wait on instead of a longer timeout?
 
-If the answer is no or unclear, do not add a retry/wait as the fix. Propose a root-cause fix or instrumentation instead.
+If the answer is no or unclear, do not add a retry/wait as the fix. Propose a root-cause fix or instrumentation instead. When a rate-limited or quota-limited dependency has no safe cap, choose A7-style serialization or caching to de-stress it. An uncapped retry against such a dependency is retry amplification and will be rejected under B1.
 
 Common valid fix types: