@clipboard-health/ai-rules 2.40.0 → 2.41.0

package/package.json

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

package/rules/common/coreLibraries.md

@@ -34,6 +34,7 @@ When a bug traces into a `@clipboard-health/*` library, read the source code in
 - **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-flake-linter**: Shared configurable checks for Playwright flake anti-patterns.
 - **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.

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.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.
+**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.
 
-**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.
+**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.
 
 **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.19.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.20.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.19.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.20.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.19.0</code></sub>'
+SENTINEL='<sub>🤖 <code>cb-babysit:addressed v1 core@3.20.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.19.0</code></sub>
+<sub>🤖 <code>cb-ship:created v1 core@3.20.0</code></sub>
 ```

package/skills/flaky-critic/SKILL.md

@@ -16,6 +16,7 @@ Your job is adversarial: assume the plan papers over the root cause until its ev
 ## Rules
 
 - Load `references/rubric.md` (relative to this SKILL.md) before judging anything. Every rejection MUST cite rule IDs and quote the offending plan sentence or diff hunk. Every approval MUST name the fix class (A1–A7, C1–C5, D1–D5) and the evidence that satisfies its requirements.
+- In shadow/enforce mode, consult `../flaky-debug/references/root-cause-kb/README.md` for the plan's symptom signature and proposed mechanism, and read every plausible entry before applying B5's Prior-attempts rule. A KB entry's **What failed and why** section may supply substantive evidence that the proposed mechanism was already tried and failed; cite the entry and its linked recurrence evidence, not the index row alone. In backtest mode, do not open the live KB; use KB evidence only when the supplied historical snapshot includes the contemporaneous entry.
 - One verdict per ticket per content-state: skip tickets whose latest `<!-- flaky-critic:` marker is newer than the last substantive edit/comment.
 - Findings from automated reviewers (Mendral, CodeRabbit) are advisory inputs, never binding (rubric §1).
 - A plan outside the rubric's taxonomy is **needs-human**, not a guess. Uncertainty bounces up, never through.
@@ -32,7 +33,7 @@ If the queue is empty, skip to the digest. Fetch linked investigation tickets an
 ## Phase 2: Verdict per ticket
 
 1. **Classify** the proposed fix into the rubric taxonomy. Multi-part plans get classified per part; the worst verdict wins.
-2. **B-rules first** (any violation → reject): B1–B7, per rubric §2.
+2. **B-rules first** (any violation → reject): B1–B8, per rubric §2. For B5 in shadow/enforce mode, compare the plan's mechanism with candidate KB entries. In backtest mode, make that comparison only when a contemporaneous entry is part of the supplied snapshot. Reject substantively when an eligible entry documents that the same proposed mechanism already merged and then recurred; a shared symptom signature without a matching mechanism is not enough.
 3. **A/C requirements**: the named fix class's "Required evidence" must be present (A-rules), or the conditional justification stated verbatim (C-rules). A1 has a shared-helper carve-out that's easy to miss — check it explicitly before approving.
 4. **D dispositions**: a no-code plan must carry the disposition's required evidence (D1–D5).
 5. **Verdict**: `approve` / `reject` / `needs-human`, with confidence high/moderate/low. Low confidence → needs-human.

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

@@ -56,6 +56,8 @@ Opening one plan/PR per failing test when the failures share one mechanism (same
 
 **Prior attempts (amendment, 2026-07-16):** when a fingerprint family has prior implementation tickets, the plan MUST contain a **Prior attempts** section listing each prior ticket/PR, what it blamed, what it changed, and the recurrence evidence showing its diagnosis was wrong or incomplete. A missing section is statement-missing and gets amend-and-resubmit per §1. A plan that re-proposes a mechanism a prior merged fix already tried is a substantive reject. A family with **≥2 failed merged fixes** — merged fixes followed by recurrence — is disqualified from the normal fix path: verdict = reject and escalate as needs-human. Apply the `chronic` label and route the family to the credential-checked, dossier-first `flaky-deep-dive` skill. The ≥2 threshold is intentionally different from flaky-triage's ≥3-prior-implementation-tickets screen: triage counts tickets cheaply before any diagnosis exists, while the critic can see merge and recurrence outcomes and applies the sharper failed-merged-fix test. Either stage flagging chronic routes the same way; the counts are staged by the evidence available at each stage, not a contradiction.
 
+**Knowledge-base cross-reference (amendment, 2026-07-16):** in shadow/enforce mode, consult the flaky-debug [root-cause knowledge-base index](../../flaky-debug/references/root-cause-kb/README.md) using the plan's symptom signature, then read each plausible entry's mechanism and **What failed and why** section. An entry that links a prior merged fix for the same mechanism to later recurrence is evidence for a substantive B5 reject under the Prior-attempts rule, even when the current plan omitted that history. Cite the entry and its recurrence evidence in the verdict. An index match on symptom text alone is not sufficient: if the causal mechanism differs or the entry has no failed merged attempt, continue evaluating the plan on its own evidence. In backtest mode, do not consult the live KB; use an entry only when the supplied historical snapshot includes the contemporaneous entry, so later recurrence evidence cannot leak into the historical verdict.
+
 ### B6 — Code fix on low-confidence diagnosis
 
 Proposing a code change when root-cause confidence is ≤2/5, or any plan below 5/5 that omits observability follow-ups.

package/skills/flaky-debug/SKILL.md

@@ -58,7 +58,7 @@ If the type is ambiguous, check the test file extension and imports to confirm.
 
 If the type is E2E, also classify where the failure surfaced in the lifecycle -- see [Classify the E2E Failure Surface](./references/plan-e2e.md#classify-the-e2e-failure-surface) in `plan-e2e.md`. The failure surface dictates how broadly to investigate before reading or editing the test.
 
-## Phase 1b: Build the Dossier and Check for Existing Fixes
+## Phase 1b: Build the Dossier, Consult the Knowledge Base, and Check for Existing Fixes
 
 Before diagnosing, build the fingerprint family's dossier, then check whether someone (or another agent) has already fixed this flake. Do not limit the dossier to the failing file or recent activity.
 
@@ -74,12 +74,22 @@ Before diagnosing, build the fingerprint family's dossier, then check whether so
    For all four queries, omit the state filter so every state, including terminal states, is searched. Omit created/updated date filters; there is no 14-day restriction. The `query` field must search issue titles and descriptions, not the file name alone.
    - Fetch every matching issue with `get_issue`, then read its relations, comments, and linked PRs so closed and merged attempts are not lost to truncated list results
 
-2. **Build the `Prior attempts` table before diagnosis.** Add one row for each prior implementation ticket and linked PR found through either query. The table columns are `Prior ticket/PR`, `What it blamed`, `What it changed`, and `Recurrence evidence`. The table must list each prior ticket/PR, what it blamed, what it changed, and the recurrence evidence showing its diagnosis was wrong or incomplete. Use later investigation sightings and post-merge failures as recurrence evidence; do not infer failure merely because an attempt is old. If there are no prior implementation tickets, record `None found` plus the fingerprint and test-title searches run.
-3. **Search open PRs with the `flaky-test-fix` label** that touch the failing test file or its surrounding code. Use GitHub search scoped to the repo:
+2. **Consult the root-cause knowledge base alongside the Linear search.** Open [`references/root-cause-kb/README.md`](./references/root-cause-kb/README.md), compare the observed fingerprint, error text, failure surface, and causal evidence with its symptom index, and read every plausible entry in full.
+   - A matching symptom signature seeds the diagnosis with the entry's known mechanism; it does not prove the mechanism. Confirm or falsify it against the current artifacts and causal chain.
+   - Read the entry's **What failed and why** section before proposing a fix. Carry those failed-fix patterns into the dossier even when the current Linear family has no prior implementation ticket.
+   - Record one of these statements before diagnosis:
+     - `KB match: <entry link> — <matched symptom signature>; mechanism hypothesis: <mechanism>; failed fixes to avoid: <summary>.`
+     - `KB match: none — checked <symptom signatures/fingerprint> against the index.`
+   - If more than one entry is plausible, cite each candidate and state the evidence that selects or falsifies it. Create a new entry only when the causal terminus establishes a genuinely novel mechanism.
+
+   See the checked-in [KB lookup and close-out dry run](./references/root-cause-kb/dry-run-workplace-review-sheet.md) for one full cycle.
+
+3. **Build the `Prior attempts` table before diagnosis.** Add one row for each prior implementation ticket and linked PR found through either query. The table columns are `Prior ticket/PR`, `What it blamed`, `What it changed`, and `Recurrence evidence`. The table must list each prior ticket/PR, what it blamed, what it changed, and the recurrence evidence showing its diagnosis was wrong or incomplete. Use later investigation sightings and post-merge failures as recurrence evidence; do not infer failure merely because an attempt is old. If there are no prior implementation tickets, record `None found` plus the fingerprint and test-title searches run. Keep KB-derived failed-fix history in the separate `KB match` statement unless the entry links a ticket or PR to this fingerprint family; do not manufacture family-specific prior attempts from a mechanism-level entry.
+4. **Search open PRs with the `flaky-test-fix` label** that touch the failing test file or its surrounding code. Use GitHub search scoped to the repo:
    - Search PRs labeled `flaky-test-fix` for the test file name or test directory
    - Review the PR's changes to assess whether they address the same flake pattern with reasonable confidence — if so, stop and report it to the user rather than opening a duplicate fix
    - If the PR only partially addresses the flake or targets a different root cause, note it and proceed with investigation
-4. **Check recent commits on `main`** that touch the failing test file or its surrounding code:
+5. **Check recent commits on `main`** that touch the failing test file or its surrounding code:
    - `git log --oneline -20 origin/main -- <test-file-path>` and also check the parent directory or related source files
    - Read the commit messages — if one clearly fixes the same flake pattern, stop and report it to the user
 
@@ -89,6 +99,7 @@ If an existing fix is found, report:
 - A brief summary of what it addresses
 - Whether it fully covers the current flake or only partially
 - The `Prior attempts` table, including recurrence evidence for any failed prior diagnosis
+- The `KB match` statement, including the cited entry and failed-fix history when matched
 
 If no existing fix is found, proceed to Phase 2.
 
@@ -101,3 +112,5 @@ 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, 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`.
+
+After that fix merges, the knowledge-base close-out in `fix.md` is required. Update the matched entry with the new evidence, repository/surface, fix result, and any newly established failed-fix history, or add a new mechanism-indexed entry when the causal terminus was genuinely novel.

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

@@ -90,6 +90,44 @@ Skip this step when the fix is **specific to one test's logic** -- for example a
 
 Run the plan's **Validation plan** commands — including the previously-flaky test, repeated enough times to give reasonable confidence the flake is gone. Lint and type-check touched files as the floor; do not stop there.
 
+## Required Knowledge-Base Close-Out After Merge
+
+After the target fix merges, close out the root-cause knowledge base in `references/root-cause-kb/`. This is required even when the plan matched an existing entry. A merged fix is new evidence about the mechanism and must not remain only in a target-repository PR.
+
+1. In a core-utils checkout, reopen the plan's **KB match** and the [KB symptom index](./root-cause-kb/README.md). Read the matched entry, or identify the proposed entry path when the plan established a novel mechanism.
+2. Print a dry-run statement before editing:
+
+   ```text
+   KB close-out dry run
+   Entry: <existing path or proposed new path>
+   Symptom signature: <signature being added or confirmed>
+   Mechanism: <causal mechanism>
+   Update type: <new evidence | new repository/surface | failed fix | new entry>
+   Sections: <entry sections and index rows to change>
+   Evidence: <merged PR, ticket, recurrence, trace, or fault-injection links>
+   ```
+
+3. Update the existing entry when the causal mechanism is the same:
+   - Add or refine symptom signatures only when the new evidence makes them more discriminating.
+   - Add a newly implicated repository or surface.
+   - Add the merged fix and its validation under **What fixed it** and **Evidence**.
+   - Add a failed or partial fix under **What failed and why**, including the recurrence evidence that falsified it.
+   - Refresh **Current status** and `Last reviewed`.
+4. Add a new entry only when the causal terminus proves a genuinely novel mechanism. Use the seven required sections from the KB index, index it by symptom signature and mechanism cue, and link evidence. A new test name, repository, or failure site is not by itself a new mechanism.
+5. Run the core-utils sync and verification commands, open a focused core-utils PR for the KB change, and link that PR from the flaky implementation ticket or target fix PR. The close-out is not complete until the KB PR link is recorded.
+
+Use the same statement discipline as the diagnosis plan. The final close-out must state:
+
+```text
+Knowledge-base close-out: <entry link>
+Update: <new evidence | new repository/surface | failed fix | new entry>
+Mechanism: <mechanism>
+Evidence: <merged fix and recurrence/validation links>
+KB PR: <link>
+```
+
+If the target fix has not merged, write `Knowledge-base close-out: pending — <target PR> is not merged` and leave the close-out open. Do not use `no KB update needed`. The checked-in [workplace-review sheet dry run](./root-cause-kb/dry-run-workplace-review-sheet.md) demonstrates the lookup, cited plan, and post-merge entry update without external writes.
+
 ## Output Format
 
 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.
@@ -101,6 +139,7 @@ When documenting the fix in a PR or issue, use this structure. Carry **Confidenc
 - **Confidence:** score (1-5) with brief justification
 - **Failure surface:** where the failure first surfaced and why the fix belongs there
 - **Current main status:** whether the failure path still existed when the fix was made
+- **KB match:** the cited entry, matched symptom signature, mechanism hypothesis, and failed fixes to avoid; or `None` plus the fingerprints and symptom signatures checked against the index
 - **Symptom:** what failed and where
 - **Root cause:** concise technical explanation
 - **Evidence:** artifacts supporting the diagnosis (traces, network, error messages, screenshots as applicable)
@@ -109,3 +148,4 @@ When documenting the fix in a PR or issue, use this structure. Carry **Confidenc
 - **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
+- **Knowledge-base close-out:** the entry update and KB PR link after merge, or the explicit pending statement before merge

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

@@ -94,6 +94,7 @@ Produce the plan with these fields:
 - **Confidence:** score (1-5) with brief justification
 - **Failure surface:** CI/job setup, test setup/auth/data, app bootstrap, user action no-op, backend request, post-success render, assertion/locator, or mixed
 - **Current main status:** whether the failing commit's code path still exists on current `main`, has already been fixed, or has changed enough that the plan must be adjusted
+- **KB match:** cite the matching entry, matched symptom signature, mechanism hypothesis, and known failed fixes to avoid. If none matched, write `None` and list the symptom signatures/fingerprint checked against the index.
 - **Prior attempts:** list each prior ticket/PR, what it blamed, what it changed, and the recurrence evidence showing its diagnosis was wrong or incomplete. Use a table with `Prior ticket/PR`, `What it blamed`, `What it changed`, and `Recurrence evidence` columns. If the dossier search found no prior implementation tickets, write `None found` and include the fingerprint-family and exact-test-title searches run.
 - **Symptom:** what failed and where
 - **Root cause:** concise technical explanation

package/skills/flaky-debug/references/root-cause-kb/README.md

@@ -42,3 +42,7 @@ When adding an entry, keep the same sections used by the seeded entries:
 - Read the candidate entry's failed-attempt section before proposing a fix.
 - If the evidence contradicts the entry, continue the investigation and add a new mechanism only when the causal terminus is genuinely different.
 - Update an existing entry when a new repository or test exposes the same mechanism.
+
+## Demonstrated cycle
+
+The [workplace-review sheet dry run](./dry-run-workplace-review-sheet.md) demonstrates one complete, write-free cycle: a diagnosis matches symptom signatures to an entry, the plan cites the mechanism and failed-fix history, and the merged fix close-out identifies the exact entry sections updated.

package/skills/flaky-debug/references/root-cause-kb/dry-run-workplace-review-sheet.md

@@ -0,0 +1,81 @@
+# Dry Run: Workplace-Review Sheet Knowledge-Base Cycle
+
+- **Mode:** Retrospective dry run; no external writes
+- **Repository:** `cbh-mobile-app`
+- **Surface:** Workplace-review comment and reply action sheets
+- **Fix evidence:** [cbh-mobile-app#12860](https://github.com/ClipboardHealth/cbh-mobile-app/pull/12860)
+- **Date:** 2026-07-16
+
+This dry run demonstrates the required diagnosis-to-close-out cycle using a real merged fix. It reconstructs the statements the workflow must produce; it does not claim that the historical investigation originally consulted an entry that was created later.
+
+## 1. Diagnosis lookup
+
+Observed symptom signatures:
+
+- A sheet opens from a query-backed review or reply row, then disappears or loses its actionable content.
+- The failure occurs while the backing list can refetch or reconcile.
+- Retries at the locator or interaction site do not make the sheet lifecycle stable.
+
+Index lookup output:
+
+```text
+KB match: query-driven-list-dialog-teardown.md
+Matched symptom signature: dialog or sheet opens, then its content does not remain stably visible
+Mechanism hypothesis: the sheet is owned below a query-driven mapped row and unmounts when that row reconciles
+Failed fixes to avoid: locator retries, response waits, expanded timeouts, and state preservation that leaves overlay ownership below the replaceable row
+```
+
+Candidate read in full: [Query-driven list dialog teardown](./query-driven-list-dialog-teardown.md).
+
+The failure surface and component ownership select this entry. A shared `element was detached` string alone would not be enough; the causal evidence must show that the open sheet is a descendant of the replaceable query row.
+
+## 2. Plan excerpt seeded by the entry
+
+```text
+KB match: Query-driven list dialog teardown
+Matched signature: open query-row sheet disappears during list reconciliation
+Mechanism hypothesis: overlay lifecycle is coupled to a replaceable mapped row
+Known failed fixes: interaction retries and timeout expansion leave ownership unchanged; preserving modal state does not preserve the active DOM subtree
+
+Root cause: workplace-review comment and reply action sheets are rendered beneath query-backed mapped rows. A refetch can reconcile the launching row and destroy the open sheet during interaction.
+
+Proposed fix: hoist the action sheets into one stable, entity-keyed host above the mapped list. Keep rows trigger-only.
+```
+
+The entry seeds the mechanism and failed-fix history, but the plan still has to prove the current ownership chain from source and artifacts. The plan cites the entry rather than presenting the mechanism as novel.
+
+## 3. Post-merge close-out dry-run output
+
+After `cbh-mobile-app#12860` merged, the close-out chooses an existing entry because the causal mechanism is unchanged:
+
+```text
+KB close-out dry run
+Entry: references/root-cause-kb/query-driven-list-dialog-teardown.md
+Symptom signature: workplace-review comment or reply sheet disappears while its query-backed row reconciles
+Mechanism: overlay lifecycle is coupled to a replaceable query-driven mapped row
+Update type: new repository/surface and new fix evidence
+Sections: Affected repositories and surfaces; What fixed it; Current status; Evidence
+Evidence: cbh-mobile-app#12860
+```
+
+Expected entry changes:
+
+- **Affected repositories and surfaces:** add the workplace-review comment and reply action sheets under `cbh-mobile-app`.
+- **What fixed it:** record that the sheets were hoisted to a stable host and rows became trigger-only.
+- **Current status:** mark the known workplace-review descendants fixed while retaining the lookup guidance for future surfaces.
+- **Evidence:** link `cbh-mobile-app#12860`.
+- **Symptom index:** no new row required because the existing disappearing-sheet signature already retrieves this mechanism.
+
+Resulting entry: [Query-driven list dialog teardown](./query-driven-list-dialog-teardown.md) now names the workplace-review surfaces, records `cbh-mobile-app#12860` as the repository-wide indirect-descendant fix, and links that PR in its evidence.
+
+Final close-out statement:
+
+```text
+Knowledge-base close-out: [Query-driven list dialog teardown](./query-driven-list-dialog-teardown.md)
+Update: new repository/surface and new fix evidence
+Mechanism: overlay lifecycle coupled to a replaceable query-driven mapped row
+Evidence: [cbh-mobile-app#12860](https://github.com/ClipboardHealth/cbh-mobile-app/pull/12860)
+KB PR: [ClipboardHealth/core-utils#785](https://github.com/ClipboardHealth/core-utils/pull/785)
+```
+
+The retrospective KB publication is [core-utils#785](https://github.com/ClipboardHealth/core-utils/pull/785). This is an entry update, not a new entry: the repository and sheet names are new evidence for the same mechanism, not a genuinely novel causal terminus.