` are each reported as orphans; the two fixtures guarding the new walker mechanisms fail under targeted mutation (presence-based band check; following bare imports); the push guard blocks on a committed-unformatted blob with a clean working tree, on a committed-only broken static config, on a committed-only broken **dynamic** config, and on a config-only change that breaks an untouched file — while a benign config change and a plain dependency bump both pass. `verify:cheap`: `Tests 4470 passed | 4 skipped (4474)`.\n\n### On the open one\n\nA pre-push hook cannot run `npm ci` for the pushed lockfile, so \"run with the pushed dependency tree\" isn't reachable in this context. The two honest options are to detect that the push changes `package-lock.json`/`package.json` dependencies and either report that the verdict used the local Prettier, or fail closed. Blocking every dependency PR seems worse than a visible note, but that's a judgement call.\n\nTwo notes for whoever lands this: auto-merge is armed, so any commit from this pass merges once checks pass; and `docs/outstanding-issues.md` has conflicted with `main` twice in the last hour because its table is padded to fixed column widths, so one row's edit re-pads all 116 rows. While conflicted, GitHub cannot build the merge ref and **every `pull_request`-triggered workflow is silently skipped** — that failure mode is now recorded as `#116`.\n\n---\n_Generated by [Claude Code](https://claude.ai/code)_{\"title\":\"docs(agents): require npm run format before pushing\",\"body\":\"## Summary\\n\\nDocumentation only. Two files, one line each — `AGENTS.md` gains a process-hardening bullet, and `docs/branch-review-ledger.md` carries a Cursor row that was stranded by the #1394 squash (see Notes).\\n\\n**The problem, from three occurrences on 2026-07-30.** Every one was the same shape: an unformatted file reached `Static PR checks` and `ci/circleci: verify`, which both run `prettier --check .`. In each case the author had run the unit suite, `typecheck`, `lint`, and a focused `prettier --check` on the file they were working on, and reported green in good faith.\\n\\nThe ordinary loop genuinely cannot catch it — `format:check` is in **none** of `test`, `typecheck`, or `lint`. Only `verify:cheap` and CI run it.\\n\\n**Why not fix it in tooling.** I checked before writing a doc, and a `format-before-push` guard already exists in `.githooks/pre-push` (delegating to `scripts/guard-push.mjs`), correctly installed here — `core.hooksPath` is `.githooks` and the guard's own header names this exact failure mode. It works. But `core.hooksPath` is configured by *this checkout's* `npm install`, and all three breaks came from pushes made outside a hook-configured checkout. Hooks are client-side, so there is nothing to add in tooling that would cover another environment. The instruction surface is the only lever, which is what this changes.\\n\\nThe bullet also records the specific trap, not just the rule: twice the missed file was a **doc or ledger edit made alongside a source change**, so a per-file `prettier --check` on the source file passed while the repository-wide check was red.\\n\\n## Verification\\n\\n- [x] `npm run format:check` — *All matched files use Prettier code style!*\\n- [x] `npm run docs:check-links` — *docs link check passed: 1375 repo path references resolve.*\\n- [x] `npm run check:branch-review-ledger` — *1266 table records, union merge active, six cells each, no conflict markers, mojibake, heading records, or duplicates.*\\n- [x] `npm run test` — **4459 passed, 4 skipped** (`AGENTS.md` is parsed by policy tests, so the suite is meaningful here)\\n- [x] `grep -c \\\"^## Dependency shortcut\\\" AGENTS.md` → `1`, per that section's own self-check\\n- [ ] `npm run verify:ui` — **UI verification not run:** no UI, routing, styling, reduced-motion or forced-colors behaviour changed.\\n- [ ] `npm run eval:retrieval:quality` — not applicable; no retrieval, ranking, selection, chunking or scoring behaviour changed.\\n- [ ] `npm run check:production-readiness` — not applicable; no clinical workflow, privacy, environment, Supabase, source-governance or deployment behaviour changed.\\n\\n**RAG impact:** no retrieval behaviour change — this adds one documentation bullet and one ledger row. No file under `src/lib/rag/**`, clinical-search, retrieval-selection, released-search-order, ranking-config, the eval harness, the golden fixture, or the retrieval RPCs is touched.\\n\\n## Risk and rollout\\n\\n- **Risk:** none to runtime; no code changes. The only sensitivity is that `AGENTS.md` sections are marker-delimited (``), so I confirmed no generator owns those blocks — `grep` for the marker names matches `AGENTS.md` alone — before editing inside one.\\n- **Rollback:** revert the commit; nothing depends on it.\\n- **Provider or production effects:** None. No provider-backed gate was run and no live service contacted.\\n\\n## Clinical Governance Preflight\\n\\nNot applicable — no ingestion, answer generation, search/ranking, source rendering, document access, privacy, production environment, or clinical output behaviour is touched.\\n\\n## Notes\\n\\n**On the second file.** The branch's remote head carried `60bdb32e`, a Cursor commit pushed *after* #1394 merged, adding one branch-review-ledger row that the squash therefore did not include. Restarting the branch from `main` and force-pushing would have destroyed it. I cherry-picked it instead, so it retains Cursor Agent's authorship, and only then used `--force-with-lease`. `check:branch-review-ledger` passes on the result.\\n\\n**What I deliberately did not do.** I had also proposed giving `docs/outstanding-issues.md` a `merge=union` driver, after today's genuine conflict where both sides claimed `#112`. On testing, that fix is wrong: union concatenates conflicting hunks, so two sides each bumping `` produce **two** marker lines. I verified this in a scratch repo — the merged file ended with both `next-id=012` and `next-id=011`. That is worse than the conflict it avoids, because a conflict fails loudly and a duplicated marker corrupts the ledger silently. The ID-allocation half of that problem is already tracked as `#112` on `main`.\\n\\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\\n\\nhttps://claude.ai/code/session_01Akwz3Sdms8uJ5AkDt3CduY\\n\\n---\\n_Generated by [Claude Code](https://claude.ai/code/session_01Akwz3Sdms8uJ5AkDt3CduY)_\\n\\n\\n\\n## Summary by CodeRabbit\\n\\n* **Bug Fixes**\\n * Improved route detection for search results pages, preventing the shared results header from appearing on pages where it is not actually rendered.\\n * Preserved correct header behavior for valid default-exported pages.\\n\\n* **Documentation**\\n * Clarified the required formatting step before pushing changes.\\n\\n* **Chores**\\n * Strengthened formatting checks to validate the exact commits being pushed, reducing formatting-related CI failures.\\n\\n\",\"base_ref\":\"c57318f4a58a50f8d0be6a2ccacd42b5cd2bf86a\",\"head_ref\":\"0ce9f5e632914b080e1fe9f8dd7bf69ca7691dac\",\"merge_commit_sha\":null,\"type\":\"pull_request_info\"}{\"type\":\"pull_request_comment\",\"body\":\"\\n\\n\\n[![Review Change Stack](https://storage.googleapis.com/coderabbit_public_assets/review-stack-in-coderabbit-ui.svg)](https://app.coderabbit.ai/change-stack/BigSimmo/Database/pull/1400?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack)\\n\\n\\n\\n\\n> [!WARNING]\\n> ## Review limit reached\\n> \\n> You’ve reached a temporary PR review limit under our [Fair Usage Limits Policy](https://docs.coderabbit.ai/management/plans#fair-usage-limits-policy).
\\n> Your recent review volume is higher than typical usage, so adaptive limits are currently applied.\\n> \\n> **Next review available in:** **44 minutes**\\n> \\n> Your organization has reached its usage spending cap. Adjust your spending cap in the [billing tab](https://app.coderabbit.ai/settings/billing?tab=usage&orgId=420f13a9-28c9-4ad8-9f2e-1fd2cf273b7c).\\n> \\n>

\\n>

How can I continue?

\\n> \\n> After more reviews become available, a review can be triggered using the `@coderabbitai review` command as a PR comment. Alternatively, push new commits to this PR.\\n> \\n> To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.\\n> \\n>

\\n> \\n> \\n>

\\n>

How do review limits work?

\\n> \\n> CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.\\n> \\n> For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.\\n> \\n> Please refer [docs](https://docs.coderabbit.ai/management/plans#rate-limits) for additional details.\\n> \\n>

\\n> \\n>

\\n>

Review details

\\n> \\n>

\\n>

⚙️ Run configuration

\\n> \\n> **Configuration used**: Path: .coderabbit.yaml\\n> \\n> **Review profile**: CHILL\\n> \\n> **Plan**: Pro\\n> \\n> **Run ID**: `441f3be8-cff9-4e36-8cef-75e3d76724e3`\\n> \\n>

\\n> \\n>

\\n>

📥 Commits

\\n> \\n> Reviewing files that changed from the base of the PR and between 20235ccba1413c54f3e34208adf5ffbd6144f511 and 0ce9f5e632914b080e1fe9f8dd7bf69ca7691dac.\\n> \\n>

\\n> \\n>

\\n>

📒 Files selected for processing (5)

\\n> \\n> * `AGENTS.md`\\n> * `docs/branch-review-ledger.md`\\n> * `docs/outstanding-issues.md`\\n> * `scripts/guard-push.mjs`\\n> * `tests/search-results-band-adoption.test.ts`\\n> \\n>

\\n> \\n>

\\n\\n\\n\\n\\n\\n

\\n

📝 Walkthrough

\\n\\n## Walkthrough\\n\\nThe PR strengthens pre-push formatting verification by checking pushed commit contents in temporary worktrees and refines route reachability analysis with Babel AST parsing and mount-aware import traversal.\\n\\n### Changes\\n\\n**Pushed-commit format verification**\\n\\n|Layer / File(s)|Summary|\\n|---|---|\\n|**Commit blob and policy inputs**
`scripts/guard-push.mjs`|Changed files are collected with commit SHAs, and Prettier policy files are detected.|\\n|**Temporary worktree formatting checks**
`scripts/guard-push.mjs`|Pushed commits are checked in detached temporary worktrees with cleanup, batching, policy escalation, and error classification.|\\n|**Guard orchestration and process guidance**
`scripts/guard-push.mjs`, `AGENTS.md`, `docs/branch-review-ledger.md`|Push orchestration uses blob-based checks, updated failure messages, and documents the format-and-commit process.|\\n\\n**AST-based route reachability**\\n\\n|Layer / File(s)|Summary|\\n|---|---|\\n|**Mount-aware specifier analysis**
`tests/search-results-band-adoption.test.ts`|Babel parsing identifies mounted JSX and default-export bindings and selects the corresponding specifiers to follow.|\\n|**Traversal integration and fixtures**
`tests/search-results-band-adoption.test.ts`|Route traversal uses the new helper and tests mounted defaults, unmounted imports, named re-exports, and star re-exports.|\\n\\n**Estimated code review effort:** 4 (Complex) | ~45 minutes\\n\\n### Sequence Diagram(s)\\n\\n```mermaid\\nsequenceDiagram\\n participant formatGuard\\n participant checkPushedCommit\\n participant GitWorktree\\n participant Prettier\\n formatGuard->>checkPushedCommit: check commit SHA and changed files\\n checkPushedCommit->>GitWorktree: create detached worktree\\n checkPushedCommit->>Prettier: run formatting checks\\n Prettier-->>checkPushedCommit: return check result\\n checkPushedCommit->>GitWorktree: remove temporary worktree\\n checkPushedCommit-->>formatGuard: return verdict\\n```\\n\\n**Possibly related PRs**\\n\\n- [BigSimmo/Database#583](https://github.com/BigSimmo/Database/pull/583): Related push-safety and format-before-push guard implementation.\\n- [BigSimmo/Database#621](https://github.com/BigSimmo/Database/pull/621): Related documentation for the pre-push formatting guard.\\n- [BigSimmo/Database#1394](https://github.com/BigSimmo/Database/pull/1394): Related route and search-results band reachability traversal changes.\\n\\n**Suggested reviewers:** `cursoragent`\\n\\n

\\n\\n\\n\\n\\n

\\n

🚥 Pre-merge checks | ✅ 4 | ❌ 1

\\n\\n### ❌ Failed checks (1 warning)\\n\\n| Check name | Status | Explanation | Resolution |\\n| :----------------: | :--------- | :------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------- |\\n| Docstring Coverage | ⚠️ Warning | Docstring coverage is 53.85% which is insufficient. The required threshold is 80.00%. | Write docstrings for the functions missing them to satisfy the coverage threshold. |\\n\\n

\\n

✅ Passed checks (4 passed)

\\n\\n

\\n\\n\\n\\n\\n

\\n

✨ Finishing Touches 💡 1

\\n\\n\\n

\\n

📝 Generate docstrings 💡

\\n\\n- [ ] Create stacked PR\\n- [ ] Commit on current branch\\n\\n

\\n\\n

\\n\\n\\n\\n\\n---\\n\\n\\n\\n\\n_{Comment `@coderabbitai help` to get the list of available commands.}\\n\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"[supa]:sjrfecxgysukkwxsowpy\\nThis pull request has been ignored for the connected project `sjrfecxgysukkwxsowpy` because there are no changes detected in `supabase` directory. You can change this behaviour in [Project Integrations Settings ↗︎](https://supabase.com/dashboard/project/sjrfecxgysukkwxsowpy/settings/integrations).\\n\\n

\\n\\nPreview Branches by Supabase.\\nLearn more about [Supabase Branching ↗︎](https://supabase.com/docs/guides/platform/branching).\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@Cursoragent fix merge conflict \",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Resolved and pushed on tip `87819325`. PR [#1400](https://github.com/BigSimmo/Database/pull/1400) is `MERGEABLE` again (currently `BLOCKED` only by required checks settling).\\n\\n### Classification\\n**Simple — no real content conflict.** Only `docs/branch-review-ledger.md`. GitHub showed `DIRTY`/`CONFLICTING` because the branch was behind `main` by the #1399 ledger squash (`cd2c6662`). Local `git merge origin/main` auto-merged via the ledger’s `merge=union` driver; no markers, no intent clash.\\n\\n| Side | Change |\\n|---|---|\\n| This branch | AGENTS.md format-before-push bullet + stranded #1394 closeout ledger row |\\n| `main` (#1399) | Same closeout family as squash `0d47141f` / ledger row for merged #1394 |\\n\\nNo product-code conflicts. `AGENTS.md` was untouched by `main`.\\n\\n### Resolution\\n- Reset local to remote PR tip `9b7cec23`\\n- Merged `origin/main` → `87819325`\\n- Kept both ledger appends; PR intent unchanged (`AGENTS.md` + one branch ledger row vs `main`)\\n\\n### Complicated conflicts\\n**None.**\\n\\n\\n\\n

\\n\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Require committing formatter output before pushing**\\n\\nWhen an unformatted file has already been committed, running `npm run format` immediately before the push only rewrites the working-tree copy; Git still pushes the unformatted committed blob. This is especially misleading because `scripts/guard-push.mjs` checks those current working-tree paths, so the guard can pass while CI fails on the pushed tree. Require formatting before committing, or explicitly require committing any formatter changes before pushing; the smallest proof is to commit an unformatted file, run the formatter, and compare the working copy with `git show HEAD:`.\\n\\nAGENTS.md reference: [AGENTS.md:L169-L169](https://github.com/BigSimmo/Database/blob/9b7cec230871a4cfefdfca826386032f1d386c54/AGENTS.md#L169-L169)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"AGENTS.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `9b7cec2308`\\n \\n\\n

ℹ️ About Codex in GitHub

\\n
\\n\\n[Your team has set up Codex to review pull requests in this repo](https://chatgpt.com/codex/cloud/settings/general). Reviews are triggered when you\\n- Open a pull request for review\\n- Mark a draft as ready\\n- Comment \\\"@codex review\\\".\\n\\nIf Codex has suggestions, it will comment; otherwise it will react with 👍.\\n\\n\\n\\n\\nCodex can also answer questions or update the PR. Try commenting \\\"@codex address that feedback\\\".\\n \\n

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**Re: \\\"Require committing formatter output before pushing\\\" — correct, and it made my own instruction actively misleading. Fixed in `2ac85d5b`.**\\n\\nI proved the mechanism in a scratch repo rather than reasoning about it. Commit `const a = 1`, then run the formatter:\\n\\n| | Content |\\n| --- | --- |\\n| Working tree after formatting | `const a = 1;` |\\n| `git show HEAD:f.ts` — what a push sends | `const a = 1` |\\n| `prettier --check ` (what `guard-push.mjs` runs) | **All matched files use Prettier code style!** |\\n| `prettier --check` on the committed blob | **Code style issues found** |\\n\\nSo the guard reports clean while the pushed commit is unformatted. That is worse than my bullet simply being incomplete — anyone following \\\"run `npm run format` before every push\\\" would have seen the guard go green and pushed anyway. **A passing guard is not evidence**, and the bullet now says so.\\n\\nRewritten to require *committing* the formatter output, with both traps named:\\n\\n- formatting without committing does nothing for the push, and the guard's working-tree check hides it\\n- a per-file `prettier --check` on the source file passes while a doc or ledger edit in the same push fails — that was the missed file in two of the three CI breaks\\n\\nWorth separating what's mine from what's the tooling's: the wording was my error and is fixed here. The guard checking working-tree paths instead of the pushed blobs is a real weakness in `scripts/guard-push.mjs` that this PR does not address — it would need to check `git show :` for the range. I'd rather that got its own change than be bundled into a documentation PR. Happy to record it as a ledger item or fix it separately, whichever you prefer.\\n\\n**Verification:** `npm run format:check` clean; `npm run docs:check-links` — 1375 references resolve; `npm run test` — **4459 passed, 4 skipped**; `grep -c \\\"^## Dependency shortcut\\\" AGENTS.md` → 1, per that section's own self-check.\\n\\n---\\n_Generated by [Claude Code](https://claude.ai/code)_\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Treat Prettier execution failures as blocking**\\n\\nWhen Prettier exits nonzero for reasons other than formatting—such as a malformed `.prettierrc` in the proposed push—this catch converts every result to `null`, and `formatGuard` consequently reports success because it only collects explicit `false` values. I reproduced the invalid-config case with Prettier exiting 2, which means CI's `prettier --check .` will fail while this guard allows the push; reserve the fail-open result for unreadable/deleted blobs and block on formatter execution or configuration errors.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Track the mounted binding for dynamic imports**\\n\\nOnce the traversal reaches a module, this adds every `import()` target regardless of which dynamic component is actually mounted. In the inspected `clinical-dashboard-lazy.tsx`, mounting any one export therefore enqueues all lazy surfaces, including `document-search-results.tsx`; removing `DocumentSearchResultsPanel` from the rendered dashboard can still leave the adoption test green through an unrelated mounted lazy export. Associate each dynamic import with its resulting binding and follow it only when that binding is mounted; a focused fixture with two dynamic exports where only the non-band export is rendered proves the failure.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `c0647aea97`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Do not count named exports as rendered mounts**\\n\\nWhen a reached page imports a banded component only to re-export it with `export { Banded }` while its default page renders different UI, this branch adds `Banded` to `mounted` and follows its source, so `routeReachesBand` returns true even though React never mounts the band. A focused fixture where the page re-exports `Banded` but renders `

` demonstrates the false green; propagate the binding through its consumer instead of treating a named export itself as a mount.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `fc166c8fb2`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Load Prettier configuration from the pushed commit**\\n\\nWhen the pushed commit contains a bad Prettier config or ignore file but the working tree has a post-commit correction, this invocation formats the `git show` content using the working-tree `.prettierrc` and `.prettierignore`, so it can approve a tree that CI rejects. I reproduced this with committed `{ \\\"tabWidth\\\": \\\"banana\\\" }`, an uncommitted `{}` correction, and formatted `a.js`: the guard exited 0 while `prettier --check .` in a checkout of the pushed SHA exited 1 for the invalid option. Fresh evidence in this revision is that formatter errors are now blocked, but the formatter still receives no config or ignore state from `sha`; run it against a temporary checkout/index of that SHA or materialize those files from the pushed tree too.\\n\\nAGENTS.md reference: [AGENTS.md:L169-L170](https://github.com/BigSimmo/Database/blob/055df85698efe2d91ee3a5ec8338da1f22749fdc/AGENTS.md#L169-L170)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Exclude direct named re-exports from mount traversal**\\n\\nWhen a route contains `export { Banded } from \\\"./banded-child\\\"` alongside a default page that renders unrelated UI, this branch unconditionally follows `banded-child` and reports the route as adopting the band even though the named export is never mounted. Fresh evidence after the earlier named-export finding is that the new fixture covers `import { Banded }; export { Banded }`, but this direct re-export syntax takes the separate `statement.source` path here; a focused fixture using that syntax still makes `routeReachesBand` return true. Follow only a direct default re-export that supplies the page's default component, not every named or export-all source.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `055df85698`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Check the full tree after formatter policy changes**\\n\\nWhen a push changes `.prettierrc`, `.prettierignore`, `.editorconfig`, or the `package.json` Prettier field, `files` still contains only paths changed by the push, so the scratch tree omits unchanged files whose formatting verdict may have changed. For example, a config-only `tabWidth` change can make existing source fail CI's repository-wide `prettier --check .` while this guard checks only the config file and passes; materialize/check the full pushed tree whenever formatter policy changes.\\n\\nAGENTS.md reference: [AGENTS.md:L169-L171](https://github.com/BigSimmo/Database/blob/25102a4d6a93788a065cc5d6ef66695be7af3a68/AGENTS.md#L169-L171)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Evaluate dynamic config from the pushed commit**\\n\\nWhen the pushed tree contains a dynamic Prettier config that differs from the working tree, this branch deliberately checks committed blobs using the working-tree config, recreating the mismatch the guard is meant to prevent. Fresh evidence in this revision is the new dynamic-config fallback: a pushed `prettier.config.mjs` with a validly formatted but invalid option such as `tabWidth: \\\"banana\\\"` is never loaded, so the guard can pass while CI fails loading that pushed config; evaluate it in an isolated checkout with access to the repository dependencies or fail closed.\\n\\nAGENTS.md reference: [AGENTS.md:L169-L171](https://github.com/BigSimmo/Database/blob/25102a4d6a93788a065cc5d6ef66695be7af3a68/AGENTS.md#L169-L171)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `25102a4d6a`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `20235ccba1`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Resolve Prettier from the pushed dependency tree**\\n\\nWhen a push updates Prettier or a config-loaded plugin without the current checkout's `node_modules` matching the pushed lockfile—for example, when pushing a dependency-update commit from another ref—this resolves the binary from the hook's current installation and also links that installation into the target checkout. CI instead installs the pushed lockfile, so version-dependent formatting can make this guard approve a commit that `format:check` rejects; verify dependency parity for each SHA or run with the dependency tree belonging to the checked-out commit.\\n\\nAGENTS.md reference: [AGENTS.md:L169-L171](https://github.com/BigSimmo/Database/blob/20235ccba1413c54f3e34208adf5ffbd6144f511/AGENTS.md#L169-L171)\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":198}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Stop treating side-effect imports as component mounts**\\n\\nWhen a route has a bare `import \\\"./banded-child\\\"` but its default component renders unrelated UI, this unconditionally follows the imported module. Executing a module that merely defines or exports a banded component does not render it, yet `routeReachesBand` will find the band JSX in that module and report adoption; a fixture with a bare import plus `export default () =>

` demonstrates the false green.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Trace JSX only from components that are actually mounted**\\n\\nWhen a reached module imports the banded component only for an exported helper that the route never renders, this whole-program traversal still sees the helper's JSX and marks the import as mounted. Removing `` from the rendered component while leaving `export function Helper() { return ; }` therefore keeps the adoption gate green; traversal should start from the module's mounted/default binding and follow only components reachable from it.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_📐 Maintainability & Code Quality_ | _🟠 Major_ | _⚡ Quick win_\\n\\n**Guard-behavior description is stale relative to the `guard-push.mjs` changes in this same PR.**\\n\\nLine 170 states: *\\\"guard-push.mjs runs prettier --check against working-tree paths, so it reports clean while the pushed commit is still unformatted.\\\"* But the `scripts/guard-push.mjs` changes reviewed alongside this file have already fixed exactly that gap — `checkPushedCommit` now checks out the pushed SHA into a temporary git worktree and runs Prettier there, not against working-tree paths. Leaving this claim in place after the fix lands will mislead readers into distrusting a guard that no longer has this flaw (or into thinking the fix is still pending when it isn't).\\n\\n\\n\\nPlease update this bullet to describe the current (worktree-based) verification, or clarify explicitly if this wording intentionally predates the guard fix and will be corrected in a follow-up commit within the same PR.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against current code. Fix only still-valid issues, skip the\\nrest with a brief reason, keep changes minimal, and validate.\\n\\nIn `@AGENTS.md` around lines 169 - 174, Update the guard-push.mjs behavior\\ndescription in AGENTS.md to reflect that checkPushedCommit verifies the pushed\\nSHA in a temporary git worktree with Prettier, rather than checking working-tree\\npaths. Remove the stale claim that the guard can pass while the pushed commit\\nremains unformatted.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n\\n\\n\\n\\n✅ Addressed in commits f4093e0 to 0ce9f5e\",\"path\":\"AGENTS.md\",\"side\":\"RIGHT\",\"line\":174}{\"type\":\"pull_request_comment\",\"body\":\"_🗄️ Data Integrity & Integration_ | _🟡 Minor_ | _⚡ Quick win_\\n\\n**Scope duplicate-ID validation per table.**\\n\\nIDs such as `#059` intentionally appear in both the execution queue and the open-items table, so requiring every ID to occur exactly once “across both tables” would reject valid ledger state. Validate uniqueness within the records table, then separately validate queue references and marker ordering.\\n\\nAs per coding guidelines, `docs/outstanding-issues.md` is the single durable ledger for outstanding tasks, recommendations, and issues.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against current code. Fix only still-valid issues, skip the\\nrest with a brief reason, keep changes minimal, and validate.\\n\\nIn `@docs/outstanding-issues.md` at line 152, Update the verification gate for\\ndocs/outstanding-issues.md to enforce duplicate-ID uniqueness within the records\\ntable only, allowing intentional IDs shared with the execution queue. Separately\\nvalidate that queue references correspond to valid records and that the marker\\nis greater than the maximum record ID; keep the document as the single durable\\nledger.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n\\n\\n_Source: Coding guidelines_\\n\\n\",\"path\":\"docs/outstanding-issues.md\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"_🎯 Functional Correctness_ | _🟡 Minor_ | _⚡ Quick win_\\n\\n**Make the `#115` reachability description consistent.**\\n\\nThe summary says named re-exports are followed, while the detail says named and star re-exports are deliberately not followed. Align the summary with the tested behavior so this record does not direct future reviews toward conflicting conclusions.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against current code. Fix only still-valid issues, skip the\\nrest with a brief reason, keep changes minimal, and validate.\\n\\nIn `@docs/outstanding-issues.md` at line 155, The `#115` summary and detail\\ncontradict each other about named re-export reachability. Update the summary\\ntext in the issue record to match the tested behavior described in the detail:\\ndo not follow named or star re-exports, while retaining default re-exports and\\nlazy import behavior.\\n```\\n\\n

\\n\\n\\n\\n\\n\\n\\n\\n---\\n\\n_🗄️ Data Integrity & Integration_ | _🟠 Major_ | _⚡ Quick win_\\n\\n**Restore the seven-column ledger row.**\\n\\nThe `#115` row has only six cells: `2026-07-30` is parsed as `Source`, leaving `Added` empty. Add the missing authoritative source cell before the final date.\\n\\nAs per coding guidelines, `docs/outstanding-issues.md` is the single durable ledger for outstanding tasks, recommendations, and issues.\\n\\n

\\n

🤖 Prompt for AI Agents

\\n\\n```\\nVerify each finding against current code. Fix only still-valid issues, skip the\\nrest with a brief reason, keep changes minimal, and validate.\\n\\nIn `@docs/outstanding-issues.md` at line 155, Restore the seven-column Markdown\\ntable structure for the `#115` row in the outstanding-issues ledger by inserting\\nthe authoritative source value between the detailed status text and the final\\n2026-07-30 date. Preserve the existing issue number, priority, status,\\ndescriptions, and date.\\n```\\n\\n

\\\\n

🧹 Nitpick comments (1)

\\\\n\\\\n
\\\\n
scripts/guard-push.mjs (1)
\\\\n\\\\n`201-214`: _🚀 Performance & Scalability_ | _🔵 Trivial_\\\\n\\\\n**Any `package.json` edit anywhere in the tree triggers a full-repo prettier check.**\\\\n\\\\nMatching purely on basename means a dependency bump in an unrelated `package.json` (with no `\\\"prettier\\\"` field) escalates to `[[\\\".\\\"]]` — a repository-wide `prettier --check .` — even though it can't actually change any other file's formatting verdict. This adds latency to the common case of routine dependency edits.\\\\n\\\\n\\\\n
\\\\n
♻️ Only escalate when the package.json actually carries prettier config
\\\\n\\\\n```diff\\\\n-function isPrettierPolicyFile(file) {\\\\n- return /^(?:\\\\.prettierrc(?:\\\\..+)?|prettier\\\\.config\\\\.(?:js|cjs|mjs|ts)|\\\\.prettierignore|\\\\.editorconfig|package\\\\.json)$/.test(\\\\n- path.basename(file),\\\\n- );\\\\n-}\\\\n+function isPrettierPolicyFile(file, dir) {\\\\n+ const base = path.basename(file);\\\\n+ if (/^(?:\\\\.prettierrc(?:\\\\..+)?|prettier\\\\.config\\\\.(?:js|cjs|mjs|ts)|\\\\.prettierignore|\\\\.editorconfig)$/.test(base)) {\\\\n+ return true;\\\\n+ }\\\\n+ if (base !== \\\"package.json\\\") return false;\\\\n+ try {\\\\n+ const contents = readFileSync(path.join(dir, file), \\\"utf8\\\");\\\\n+ return JSON.parse(contents).prettier !== undefined;\\\\n+ } catch {\\\\n+ return true; // fail closed if it can't be read/parsed\\\\n+ }\\\\n+}\\\\n```\\\\n
\\\\n\\\\n
\\\\n
🤖 Prompt for AI Agents
\\\\n\\\\n```\\\\nVerify each finding against current code. Fix only still-valid issues, skip the\\\\nrest with a brief reason, keep changes minimal, and validate.\\\\n\\\\nIn `@scripts/guard-push.mjs` around lines 201 - 214, Update isPrettierPolicyFile\\\\nso package.json matches only when that file contains a Prettier configuration\\\\nfield; retain unconditional matching for the dedicated Prettier and editor\\\\nconfiguration filenames. Ensure unrelated package.json edits no longer trigger\\\\nwhole-tree formatting checks.\\\\n```\\\\n\\\\n
\\\\n\\\\n\\\\n\\\\n
\\\\n\\\\n

\\\\n\\\\n

\\\\n

🤖 Prompt for all review comments with AI agents

\\\\n\\\\n```\\\\nVerify each finding against current code. Fix only still-valid issues, skip the\\\\nrest with a brief reason, keep changes minimal, and validate.\\\\n\\\\nInline comments:\\\\nIn `@AGENTS.md`:\\\\n- Around line 169-174: Update the guard-push.mjs behavior description in\\\\nAGENTS.md to reflect that checkPushedCommit verifies the pushed SHA in a\\\\ntemporary git worktree with Prettier, rather than checking working-tree paths.\\\\nRemove the stale claim that the guard can pass while the pushed commit remains\\\\nunformatted.\\\\n\\\\nIn `@docs/outstanding-issues.md`:\\\\n- Line 155: The `#115` summary and detail contradict each other about named\\\\nre-export reachability. Update the summary text in the issue record to match the\\\\ntested behavior described in the detail: do not follow named or star re-exports,\\\\nwhile retaining default re-exports and lazy import behavior.\\\\n- Line 155: Restore the seven-column Markdown table structure for the `#115` row\\\\nin the outstanding-issues ledger by inserting the authoritative source value\\\\nbetween the detailed status text and the final 2026-07-30 date. Preserve the\\\\nexisting issue number, priority, status, descriptions, and date.\\\\n- Line 152: Update the verification gate for docs/outstanding-issues.md to\\\\nenforce duplicate-ID uniqueness within the records table only, allowing\\\\nintentional IDs shared with the execution queue. Separately validate that queue\\\\nreferences correspond to valid records and that the marker is greater than the\\\\nmaximum record ID; keep the document as the single durable ledger.\\\\n\\\\n---\\\\n\\\\nNitpick comments:\\\\nIn `@scripts/guard-push.mjs`:\\\\n- Around line 201-214: Update isPrettierPolicyFile so package.json matches only\\\\nwhen that file contains a Prettier configuration field; retain unconditional\\\\nmatching for the dedicated Prettier and editor configuration filenames. Ensure\\\\nunrelated package.json edits no longer trigger whole-tree formatting checks.\\\\n```\\\\n\\\\n

\\\\n\\\\n

\\n

🪄 Autofix (Beta)

\\n\\n🔄 Running autofix...\\n\\n

\\\\n\\\\n---\\\\n\\\\n

\\\\n

ℹ️ Review info

\\\\n\\\\n

\\\\n

⚙️ Run configuration

\\\\n\\\\n**Configuration used**: Path: .coderabbit.yaml\\\\n\\\\n**Review profile**: CHILL\\\\n\\\\n**Plan**: Pro\\\\n\\\\n**Run ID**: `f2f78c14-fbcd-4a9b-abb9-480a32b53424`\\\\n\\\\n

\\\\n\\\\n

\\\\n

📥 Commits

\\\\n\\\\nReviewing files that changed from the base of the PR and between f937493d104fdd205410c59acddd047b4e41b4a6 and 20235ccba1413c54f3e34208adf5ffbd6144f511.\\\\n\\\\n

\\\\n\\\\n

\\\\n

📒 Files selected for processing (5)

\\\\n\\\\n* `AGENTS.md`\\\\n* `docs/branch-review-ledger.md`\\\\n* `docs/outstanding-issues.md`\\\\n* `scripts/guard-push.mjs`\\\\n* `tests/search-results-band-adoption.test.ts`\\\\n\\\\n

\\\\n\\\\n

\\\\n\\\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n> [!NOTE]\\n> Autofix is a beta feature. Expect some limitations and changes as we gather feedback and continue to improve it.\\n\\nFixing 2 unresolved review comments...\\n\\nThis may take a few minutes as the agent edits the relevant files.\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":198}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"tests/search-results-band-adoption.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"scripts/guard-push.mjs\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex fix this issue with smallest required logical and intuitive fix please ensuring no regression. \",\"path\":\"AGENTS.md\",\"side\":\"RIGHT\",\"line\":null}","text_elements",[],{"_472":1155,"_451":452,"_474":458},{"_475":1156,"_477":-5,"_45":-5,"_479":1157,"_481":-5,"_100":338,"_96":483},[1158],{"_484":458},{"_49":1151,"_96":529},{"_472":1160,"_451":452,"_474":458},{"_475":1161,"_477":-5,"_45":-5,"_479":1162,"_481":-5,"_100":338,"_96":483},[1163,1164],{"_484":458},{"_49":1166,"_96":529},{"_49":1165,"_96":529},"\n /workspace/Database\n bash\n 2026-07-30\n Etc/UTC\n /workspace/Database\n","# AGENTS.md instructions for /workspace/Database\n\n\n\n\n# This is NOT the Next.js you know\n\nThis version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in `node_modules/next/dist/docs/` before writing any code. Heed deprecation notices.\n\n\n\n\n\n## Dependency shortcut\n\nWhen the user types exactly `dependency` as the entire task message, after trimming surrounding whitespace, treat it as a shortcut for safe dependency maintenance. This is a Codex chat shortcut, not an app feature, script, automation, or CI workflow.\n\nGoal:\nUpdate direct project dependencies to the newest stable compatible versions, regenerate the existing lockfile, identify source/config/test code that relies on old dependency behavior, make the smallest safe compatibility changes, and verify the result. Do not rewrite the project, switch package managers, discard user work, commit, push, deploy, or run destructive cleanup without explicit confirmation.\n\nStart with read-only inspection:\n\n- Check branch, upstream, worktrees, recent relevant history, and `git status`.\n- If on `main`, `master`, `develop`, `release/*`, or another protected/base branch, create/switch to `codex/dependency-maintenance` before editing, if safe.\n- Inspect manifests, lockfiles, package-manager config, runtime/toolchain files, workspace layout, CI config, scripts, and documented checks.\n- Detect repo-local install/dev/test/build/watch/server processes that could race dependency updates.\n- Preserve all existing staged, unstaged, and untracked user work.\n\nPackage-manager rules:\n\n- Use the package manager already used by the repo: npm, pnpm, yarn, bun, pip, poetry, uv, cargo, go, bundler, gradle, maven, dotnet, or equivalent.\n- Do not switch package managers or create a new lockfile type.\n- Respect engines, runtime versions, lockfiles, workspaces, wrappers, and repo conventions.\n- In monorepos or polyglot repos, update each ecosystem through its native workspace-aware workflow.\n\nDependency update rules:\n\n- Identify outdated direct production and development dependencies.\n- Compare both manifest ranges and locked/installed versions against latest stable compatible releases.\n- Treat “outdated packages found” exit codes as normal where applicable.\n- Avoid prerelease, alpha, beta, canary, rc, next, nightly, and experimental versions unless the stable channel points there and explain why.\n- Do not use force or legacy flags that bypass peer, engine, resolver, or lockfile integrity checks unless explicitly approved.\n- Do not run forced audit fixes or broad destructive codemods.\n- If latest is incompatible, use the newest compatible version and document why.\n- Group risky updates coherently, such as framework plus plugins, test runner plus coverage, lint core plus plugins, or runtime plus adapter packages.\n\nCompatibility audit:\n\n- For every major update and every core framework/runtime/build/test/lint/UI/database update, inspect release notes, migration guides, peer ranges, engines, and changelogs when available.\n- Search source, tests, scripts, config, and CI for imports, APIs, CLI flags, config keys, environment variables, plugin names, generated types, or file paths tied to changed dependencies.\n- If old dependency behavior is used, make the smallest safe migration that preserves behavior.\n- If migration is large, risky, architectural, or product-affecting, stop after discovery and provide a concrete fix plan with affected files, package versions, sequence, and verification commands.\n- Add or adjust focused tests only when needed to prove migrated behavior.\n\nGenerated and sensitive files:\n\n- Do not intentionally keep dependency directories, build outputs, caches, logs, local state, test artifacts, browser artifacts, `.env*`, secrets, keys, tokens, credentials, or machine-local config.\n- Manifest and existing lockfile changes are allowed.\n\nVerification:\n\n- Run a cheap baseline first when useful to distinguish pre-existing failures.\n- After updates, run install/dependency validation, then relevant lint, type check, tests, build, smoke/UI/a11y, codegen, integration checks, or equivalent.\n- For frontend/browser-facing changes, run browser/UI verification when framework, bundler, router, styling, test runner, or browser automation changed.\n- If a check fails, fix dependency-related breakage and rerun the smallest failing check before broader checks.\n- Run non-mutating audit/vulnerability checks when available.\n- Confirm no repo-owned dev server, watcher, or temporary process was left running unless requested.\n\nFinal response for `dependency` must include:\n\n- Branch and worktree state.\n- Package manager, runtime, manifests, and lockfiles detected.\n- Outdated dependencies found.\n- Dependencies updated, old version -> new version.\n- Dependencies not updated and why.\n- Files changed.\n- Compatibility migrations and old APIs found/fixed.\n- Checks run and results.\n- Checks not run and why.\n- Audit/vulnerability summary.\n- Generated/untracked files left behind.\n- Branch movement, external repo changes, or process cleanup observed.\n- Risks or follow-up work.\n- Confirmation that no commit or push was made unless explicitly requested.\n\nAfter setup:\n\n- Verify root `AGENTS.md` contains exactly one `## Dependency shortcut` section.\n- Show the final diff for `AGENTS.md`.\n- Summarize what changed.\n- Confirm no dependency update, install, test, build, audit, commit, or push was performed.\n\n\n\n\n\n## Bug-hunter shortcut\n\nWhen the user types exactly `bug-hunter` as the entire task message, after trimming surrounding whitespace, treat it as a shortcut for targeted defect discovery.\n\nExecution rules:\n\n- Invoke the `bug-hunter` skill first.\n- Prioritize reproducible defects over code style, naming, or formatting feedback.\n- Trace realistic failure paths: invalid input, empty states, retries, race/concurrency issues, stale state/cache, network/auth failures, permissions, and boundary values.\n- For each finding, include trigger, expected behavior, actual risk, and the smallest proof (or targeted test/check) that would catch it.\n- If no high-confidence defect is found, explicitly state that and list the most likely residual risk area.\n\nScope and safety:\n\n- Keep the hunt scoped to code touched by the user request unless the defect clearly crosses module boundaries.\n- Do not make broad refactors while hunting; propose minimal fixes for confirmed issues.\n- Run the smallest focused verification for each confirmed defect, then expand only if needed.\n\n\n\n\n\n## Codex review throttling and routing\n\nDo not review branches opportunistically. Review the current changed diff, PR, or branch only when the user explicitly asks for review/audit/hunter/cleanup/upload work, when CI/check failures are the task, or when the current change touches high-risk areas that require a targeted review before handoff.\n\nUse `docs/codex-review-protocol.md` as the shared review protocol for every repo-local review skill, branch/PR review, audit, bug hunt, release-readiness check, and PR/CI review.\n\nBefore reviewing a branch or PR:\n\n- Run `npm run ledger:lookup -- --scope \"\"`. It resolves the HEAD, matches the abbreviated SHAs older records used, and prints an explicit verdict. Do not read `docs/branch-review-ledger.md` by eye — it is over a thousand rows, and eyeballing it is how repeat reviews slipped through.\n- On `ALREADY REVIEWED`, summarize the prior ledger outcome and skip the repeat review unless the user explicitly requests a fresh pass.\n- On `NOT REVIEWED at this HEAD`, review only the changed scope and append a record after the review.\n\nBefore reviewing multiple branches:\n\n- Build a short branch inventory first: branch, upstream, ahead/behind, last commit, and merged status.\n- Skip branches already merged into `main`.\n- Skip unchanged branches already recorded in `docs/branch-review-ledger.md`.\n- Do not re-review every branch after ordinary coding tasks.\n- If a repeated request targets unchanged reviewed branches, summarize the prior result and ask before doing another full pass.\n\nReview routing:\n\n- `diff-review`: Use for explicit review of the current diff, PR, or named branch. Findings first, ordered by severity, with file/line evidence.\n- `bug-hunter`: Use only for the exact `bug-hunter` shortcut or an explicit defect-hunt request. Prioritize reproducible bugs and smallest proof.\n- `repo-auditor`: Use for explicit repo-wide audit/refactor/dead-code/import/dependency-structure requests. Treat outputs as triage, not automatic delete lists.\n- `release-readiness`: Use for explicit release, merge, PR readiness, or handoff confidence requests. Do not run provider-backed gates without confirmation.\n- `branch-cleanup`: Use only when the prompt explicitly asks for branch cleanup/hygiene or branch deletion candidates. Apply `docs/branch-cleanup-guide.md` and the review ledger before inspecting branch diffs.\n- `pr-ci-fix`: Confirmation-required for this repo. GitHub/GitLab API calls, PR comments, CI reruns, commits, and pushes require explicit user approval and must respect the upload/handoff rules. Exception: an explicit `Run PR` sweep carries this approval (see \"## Run PR shortcut\").\n\nWhen a branch or PR review completes, record it with `npm run ledger:append -- --ref --head --scope --outcome --checks `. Never hand-write the markdown row: hand-written rows produced the mojibake, wrong-width, and duplicate records that the 2026-07-28 hygiene pass had to repair, and `see PR head` or abbreviated HEADs make a record unmatchable so the review runs again. The ledger is append-only: never edit or delete an existing record; append a correction or superseding record (`--supersede`) instead. Its `merge=union` attribute preserves concurrent appends, and `npm run check:branch-review-ledger` blocks conflict markers, duplicate records, mojibake, wrong-width or heading-style records, unresolvable HEADs, or loss of that merge protection.\n\n\n\n\n\n# Local server safety\n\n- If the user says `run`, execute `npm run ensure` and return the printed URL.\n- If the user asks for UI/frontend changes, browser QA, screenshots, mobile checks, or a local app link, run `npm run ensure` before opening or testing the app, even if the user did not say `run`.\n- Never assume `localhost:3000`, `localhost:3001`, or `localhost:3002`.\n- Never attach to a local server unless `/api/local-project-id` confirms it is this project.\n- Do not kill or modify other projects' local servers. If the stable project port is busy, let `npm run ensure` choose the next safe project URL.\n- Do not run a permanent watcher. Only start or verify the server when the current chat task needs the app or the user asks to run it.\n\n\n\n\n\n# Process hardening phases\n\n- For non-trivial source/config/test changes, prefer `npm run verify:cheap` as the first broad gate and `npm run verify:pr-local` before PR handoff when the change is ready. The PR-local gate runs the full unit suite once, then conditionally adds the production build/client-bundle scan and RAG fixture/manifest validation. Browser, dependency-audit, Docker/Supabase replay, and provider-backed checks remain separate gates. Use `npm run verify:pr-local -- --dry-run --files ` to inspect selection without running commands. The broader `--extended` plan is dry-run only unless explicit approval is reflected by `ALLOW_EXTENDED_PR_LOCAL=true`.\n- Let the repository run coordinator control cross-worktree verification. It permits at most two focused Vitest/read-only typecheck leases from different worktrees; full Vitest, coverage, lint, build, Playwright, and live-provider tests remain exclusive. Do not install while a repository test, build, lint, typecheck, or server command is active. Avoid aggressive short-interval polling, and do not repeat an unchanged full gate after it passes.\n- For UI, frontend, browser, routing, styling, reduced-motion, or forced-colors changes, run `npm run ensure` before browser work and use `npm run verify:ui` as the Chromium UI gate. For phone-chrome changes, run `npm run verify:phone-chrome` first: it checks installed-lock parity, selects the affected browser/PWA owners and exact journeys, and adds `verify:ui` last only when shared chrome foundations make the broad gate necessary. Inspect uncertain scope with `-- --dry-run`.\n- **Run `npm run format` and commit the result before every push.** `format:check` is in neither `npm run test`, `npm run typecheck`, nor `npm run lint`, so the ordinary loop reports green while `Static PR checks` and `ci/circleci: verify` both fail on `prettier --check .`. Three CI failures on 2026-07-30 came from exactly this. Two traps beyond simply running it:\n - **Formatting without committing does nothing for the push.** A push sends commits, not your working tree, so formatting after committing leaves the unformatted blob on the branch. Amend or add a follow-up commit.\n - **A per-file check is not the repository-wide check.** `prettier --check ` on the source file you edited passes while a doc or ledger edit in the same push fails; that was the missed file twice out of three.\n\n `.githooks/pre-push` carries the guard, and since 2026-07-30 it checks the pushed commit where CI checks it: `guard-push.mjs` puts the pushed SHA in a temporary `git worktree` with `node_modules` linked in and runs Prettier there, so neither the working tree's contents nor its prettier config can vouch for the commit, and a dynamic `prettier.config.*` still loads. A push that changes prettier policy (`.prettierrc*`, `.prettierignore`, `.editorconfig`, or a `package.json` carrying a `prettier` field) escalates to a whole-tree `prettier --check .`, because a policy change alters the verdict for files the push never touched. But `core.hooksPath` is set by this checkout's `npm install`, so an agent pushing from its own environment bypasses the hook entirely and only CI catches the break — which is why the rule above is still a rule.\n\n- For release or handoff confidence, use `npm run verify:release`; this includes the full Playwright project set.\n- For clinical ingestion, answer generation, source governance, privacy, production-readiness, or environment changes, run the smallest relevant domain check plus `npm run check:production-readiness`.\n- For pull requests that touch ingestion, answer generation, search/ranking, source rendering, document access, privacy, production env, or clinical output, complete the clinical governance preflight in `.github/pull_request_template.md`.\n- Track known verification debts and staged process improvements in `docs/process-hardening.md` instead of relying on chat-only memory.\n\n\n\n\n\n# Page and button wiring\n\nInteractive controls and routes follow conventions the codebase already holds to. Before adding\nor moving a button, link, or route, read `docs/wiring-conventions.md`. A control that advertises an\naction must perform one; a page that ships must be reachable.\n\n- **Buttons.** Every interactive `