@clipboard-health/ai-rules 2.39.0 → 2.40.0

package/package.json

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

package/rules/common/coreLibraries.md

@@ -30,12 +30,12 @@ When a bug traces into a `@clipboard-health/*` library, read the source code in
 - **execution-context**: A lightweight Node.js utility for managing execution contexts and metadata aggregation using AsyncLocalStorage.
 - **json-api**: TypeScript-friendly utilities for adhering to the JSON:API specification.
 - **json-api-nestjs**: TypeScript-friendly utilities for adhering to the JSON:API specification with NestJS.
-- **mongo-jobs**: MongoDB-powered background jobs.
 - **notifications**: Send notifications through third-party providers.
 - **nx-plugin**: An Nx plugin with generators to manage libraries and applications.
 - **oxlint-config**: Shared Oxlint configuration for Clipboard Health repositories.
 - **phone-number**: Phone number utility functions.
 - **playwright-reporter-llm**: Playwright reporter that outputs structured JSON for LLM agents. Minimal console output, flat schema, easy to filter to failures.
+- **playwright-toolkit**: Shared anti-flake primitives for Clipboard Health Playwright suites.
 - **rules-engine**: A pure functional rules engine to keep logic-dense code simple, reliable, understandable, and explainable.
 - **testing-core**: TypeScript-friendly testing utilities.
 - **util-ts**: TypeScript utilities.

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.18.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.19.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.18.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.19.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.18.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.19.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.18.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.19.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.18.0</code></sub>'
+SENTINEL='<sub>🤖 <code>cb-babysit:addressed v1 core@3.19.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.18.0</code></sub>
+<sub>🤖 <code>cb-ship:created v1 core@3.19.0</code></sub>
 ```

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

@@ -8,7 +8,7 @@ This rubric turns Rocky's observed review standards into checkable rules for fla
 
 Findings from automated reviewers (Mendral, CodeRabbit, etc.) are **advisory inputs, not binding rules**: the critic evaluates each on rubric merits and may decline one with stated reasoning, exactly as cb-babysit's Disagree replies do.
 
-**Statement-missing vs substance-missing (backtest amendment, 2026-06-11):** B5/B6/B7/B8 each require an explicit statement in the plan (dedup-check results, Prior attempts section when applicable, confidence score plus observability section, current-main status, causal-chain section). When the _statement_ is absent but the violation is not demonstrated — no actual duplicate found, no actual prior implementation tickets for the fingerprint family, no actual low-confidence code fix, no actual staleness, no demonstrably symptom-terminated diagnosis — the verdict is reject with disposition **amend-and-resubmit**: one bounce asking for exactly the missing sections, never escalation. A demonstrated violation (a real duplicate, a mechanism already tried by a prior merged fix, a real ≤2/5 code fix, a diagnosis that demonstrably stops at a symptom) is a substantive reject. The 2026-06-11 backtest showed 6 of 7 false rejections were statement-missing on plans predating these conventions; live plans carry the sections by template, but the distinction stays load-bearing for the agreement metric.
+**Statement-missing vs substance-missing (backtest amendment, 2026-06-11):** B5/B6/B7/B8 and C6 each require an explicit statement in the plan (dedup-check results, Prior attempts section when applicable, confidence score plus observability section, current-main status, causal-chain section, sibling-repo check when applicable). When the _statement_ is absent but the violation is not demonstrated — no actual duplicate found, no actual prior implementation tickets for the fingerprint family, no actual low-confidence code fix, no actual staleness, no demonstrably symptom-terminated diagnosis, no confirmed sibling-repo match — the verdict is reject with disposition **amend-and-resubmit**: one bounce asking for exactly the missing sections, never escalation. A demonstrated violation (a real duplicate, a mechanism already tried by a prior merged fix, a real ≤2/5 code fix, a diagnosis that demonstrably stops at a symptom, a confirmed sibling-repo match with no linked mirror implementation ticket deliverable) is a substantive reject. The 2026-06-11 backtest showed 6 of 7 false rejections were statement-missing on plans predating these conventions; live plans carry the sections by template, but the distinction stays load-bearing for the agreement metric.
 
 ## 2. Banned patterns
 
@@ -167,6 +167,12 @@ Allowed when many tests fail before user-flow code and the evidence is a tool/ve
 
 When the root cause is in another team's service, the plan may ship the local resilience fix and must route a recommendation to the owning team (STAFF-1413: frontend rethrow fix + "backend follow-up recommendation (… 503 instead of 401) is noted in the ticket for the owning team"). It may not silently absorb a backend bug into test code.
 
+### C6 — Sibling-repo propagation
+
+**Sibling-repo propagation (amendment, 2026-07-16):** For a mechanism plausibly shared between `cbh-admin-frontend` and `cbh-mobile-app`, state the sibling repository, current `main` commit searched, exact helper names or grep-able code patterns, commands and scope, and matches found (or `None found`). A mechanism is plausibly shared when the proposed fix touches the test harness, authentication/session/bootstrap, cache, API client, or a copied capability, helper, or convention. If the same mechanism is present, state that the fix deliverable will include a linked mirror implementation ticket following the Groundcrew ticket conventions, linked to the source implementation ticket and referencing the landed source fix as the pattern to adopt. If the mechanism is not plausibly shared, state `N/A` and why.
+
+A plan that fixes a mechanism plausibly shared between the frontend repositories, including a shared-harness mechanism, without a **Sibling-repo check** statement is statement-missing and gets amend-and-resubmit per §1. A confirmed match with no linked mirror implementation ticket deliverable is a substantive reject.
+
 ## 5. Dispositions that need no code
 
 ### D1 — Infra blip / environment incident (close as Canceled)

package/skills/flaky-debug/SKILL.md

@@ -100,4 +100,4 @@ If you are in plan mode, present the plan and stop here.
 
 ## Phase 3: Apply the plan (fix mode only)
 
-Follow [`references/fix.md`](./references/fix.md). It takes the plan from Phase 2, applies the proposed fix, searches for sibling anti-patterns, and verifies. PR creation is out of scope -- if the user later opens one (or invokes a PR-shipping skill), label it `flaky-test-fix`.
+Follow [`references/fix.md`](./references/fix.md). It takes the plan from Phase 2, validates the recorded sibling frontend check and reruns it when stale or missing, applies the proposed fix, searches for same-repo sibling anti-patterns, and verifies. PR creation is out of scope -- if the user later opens one (or invokes a PR-shipping skill), label it `flaky-test-fix`.

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

@@ -12,6 +12,41 @@ Before editing, verify the plan is still current:
 - 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.
 
+## Validate the Sibling Frontend Check
+
+During Phase 2, after the proposed fix is designed and before the plan is finalized, use this recipe to complete the plan's **Sibling-repo check** when the current repository is `cbh-admin-frontend` or `cbh-mobile-app`. During the fix preflight, consume that result by confirming that the recorded sibling `main` commit is still current; rerun the search only when it changed or the plan omitted the field.
+
+For a mechanism plausibly shared between `cbh-admin-frontend` and `cbh-mobile-app`, state the sibling repository, current `main` commit searched, exact helper names or grep-able code patterns, commands and scope, and matches found (or `None found`). A mechanism is plausibly shared when the proposed fix touches the test harness, authentication/session/bootstrap, cache, API client, or a copied capability, helper, or convention. If the same mechanism is present, state that the fix deliverable will include a linked mirror implementation ticket following the Groundcrew ticket conventions, linked to the source implementation ticket and referencing the landed source fix as the pattern to adopt. If the mechanism is not plausibly shared, state `N/A` and why.
+
+Use this search recipe:
+
+1. Map `cbh-admin-frontend` to `cbh-mobile-app`, and `cbh-mobile-app` to `cbh-admin-frontend`.
+2. Search a temporary shallow clone pinned to the sibling repository's `main`:
+
+   ```bash
+   sibling_repo="<cbh-admin-frontend-or-cbh-mobile-app>"
+   sibling_root="$(mktemp -d)/$sibling_repo"
+   gh repo clone "ClipboardHealth/$sibling_repo" "$sibling_root" -- \
+     --depth=1 --branch main --single-branch
+   git -C "$sibling_root" rev-parse HEAD
+   ```
+
+3. Search for both the exact helper or capability names and the grep-able structural pattern behind the fix. Limit the first pass to likely harness and test paths, then widen to the repository if needed:
+
+   ```bash
+   rg -n --glob '*.{ts,tsx}' \
+     '<exact-helper-name>|<grep-able-structural-pattern>' \
+     "$sibling_root/<likely-path>"
+   # Run only when the scoped search cannot rule the mechanism in or out.
+   rg -n --glob '*.{ts,tsx}' \
+     '<exact-helper-name>|<grep-able-structural-pattern>' \
+     "$sibling_root"
+   ```
+
+4. Inspect each match to decide whether it carries the same mechanism, rather than relying on the text match alone. Record each query run, its scope, and the matching files or `None found` in the plan before applying the fix.
+
+Do not edit the sibling repository as part of the current fix. When the same mechanism is present, the deliverable includes a linked mirror implementation ticket created after the source fix lands. Follow the `create-groundcrew-ticket` conventions: include the exact `Repository: <sibling-repo>` line in the description, assign the current Linear user, use Todo with exactly one appropriate `agent-*` label, link the source implementation ticket, and cite the landed PR or commit as the pattern to adopt. If the current workflow stops before merge, carry this as an explicit post-merge deliverable and do not report sibling-repo propagation as complete until the ticket exists.
+
 ## Apply the Proposed Fix
 
 Edit the files listed in the plan's **Proposed fix** field. Keep the change minimal -- the plan already chose between test harness, product, and both.
@@ -59,7 +94,7 @@ Run the plan's **Validation plan** commands — including the previously-flaky t
 
 When opening a PR for a flaky test fix, include `--label flaky-test-fix` in the `gh pr create` command so other agents can find it during Phase 1b deduplication.
 
-When documenting the fix in a PR or issue, use this structure. Carry **Confidence**, **Symptom**, **Root cause**, **Evidence**, and **Residual risk** straight over from the plan. Three plan fields rename: **Proposed fix** → **Fix**, **Sibling candidates** → **Siblings fixed**, **Validation plan** → **Validation**. Drop **Open questions** (resolved by fix time):
+When documenting the fix in a PR or issue, use this structure. Carry **Confidence**, **Symptom**, **Root cause**, **Evidence**, **Sibling-repo check**, and **Residual risk** straight over from the plan. Three plan fields rename: **Proposed fix** → **Fix**, **Sibling candidates** → **Siblings fixed**, **Validation plan** → **Validation**. Add the linked mirror ticket URL to **Sibling-repo check** once the source fix lands and the ticket exists. Before then, record `Pending: create linked mirror implementation ticket after <source-PR> lands`; replace that status with the ticket URL when created. Drop **Open questions** (resolved by fix time):
 
 - **Test ID:** if provided in prompt
 - **Agent session ID:** your running session ID to resume if needed
@@ -71,5 +106,6 @@ When documenting the fix in a PR or issue, use this structure. Carry **Confidenc
 - **Evidence:** artifacts supporting the diagnosis (traces, network, error messages, screenshots as applicable)
 - **Fix:** test-only, product-only, or both
 - **Siblings fixed:** list of other files where the same anti-pattern was or should be corrected (or "N/A -- fix was test-specific")
+- **Sibling-repo check:** sibling repository and current `main` commit searched; exact helper names or grep-able code patterns; commands, scope, and matches; linked mirror implementation ticket URL when created, or the explicit pending post-merge deliverable before then; or `N/A` with the reason the mechanism was not plausibly shared
 - **Validation:** commands and suites run
 - **Residual risk:** what could still be flaky

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

@@ -102,6 +102,7 @@ Produce the plan with these fields:
 - **Proposed fix:** test harness, product, or both — with the specific file(s) and the change you would make
 - **Observability to reach 5/5:** required when confidence is less than 5/5. List the frontend and/or backend telemetry, logging, tracing, reporter, or metric changes that would make this flake's root cause directly visible in artifacts next time (reproduction then completes 5/5). Include another repository only when the evidence implicates it. Use "N/A -- confidence is 5/5" only for a 5/5 plan.
 - **Sibling candidates:** files that appear to share the same anti-pattern, for the reviewer (or fix.md) to confirm. Or "N/A -- fix is test-specific" if the issue is one-off (see [`fix.md`](./fix.md) for what counts as a structural anti-pattern worth searching for).
+- **Sibling-repo check:** for a mechanism plausibly shared between `cbh-admin-frontend` and `cbh-mobile-app`, state the sibling repository, current `main` commit searched, exact helper names or grep-able code patterns, commands and scope, and matches found (or `None found`). A mechanism is plausibly shared when the proposed fix touches the test harness, authentication/session/bootstrap, cache, API client, or a copied capability, helper, or convention. If the same mechanism is present, state that the fix deliverable will include a linked mirror implementation ticket following the Groundcrew ticket conventions, linked to the source implementation ticket and referencing the landed source fix as the pattern to adopt. If the mechanism is not plausibly shared, state `N/A` and why. Use the concrete search recipe in [`fix.md`](./fix.md#validate-the-sibling-frontend-check).
 - **Validation plan:** lint/typecheck commands and test commands to run after applying the fix
 - **Open questions:** anything that needs human input before fixing
 - **Residual risk:** what could still be flaky after the fix