\\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**: `01cb0d7b-2e9a-4219-b2cc-cf289f69d0ef`\\n> \\n>

\\n> \\n>

\\n>

📥 Commits

\\n> \\n> Reviewing files that changed from the base of the PR and between 2a8881afad230880166de60a533e17588d9920ec and 5680310c4b2f72e1c231557a1ea6fed97521e87c.\\n> \\n>

\\n> \\n>

\\n>

📒 Files selected for processing (2)

\\n> \\n> * `supabase/migrations/20260804110240_restore_rag_search_health_indexes.sql`\\n> * `tests/supabase-schema.test.ts`\\n> \\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]:bsqrhnrqgpfoyiegjxmi\\n**Updates to [Preview Branch (codex/restore-rag-indexes-20260804) ↗︎](https://supabase.com/dashboard/project/bsqrhnrqgpfoyiegjxmi)**\\n\\n| Deployments | Status | Updated |\\n| ----------- | --------------------------- | ------------------------- |\\n| Database | ✅ | Wed, 05 Aug 2026 05:48:30 UTC |\\n| Services | ✅ | Wed, 05 Aug 2026 05:48:30 UTC |\\n| APIs | ✅ | Wed, 05 Aug 2026 05:48:30 UTC |\\n\\nTasks are run on every commit but only new migration files are pushed.\\nClose and reopen this PR if you want to apply changes from existing seed or migration files.\\n\\n| Tasks | Status | Updated |\\n| -------------- | ---------------------------- | -------------------------- |\\n| Configurations | ✅ | Wed, 05 Aug 2026 05:48:32 UTC |\\n| Migrations | ✅ | Wed, 05 Aug 2026 05:48:34 UTC |\\n| Seeding | ✅ | Wed, 05 Aug 2026 05:48:36 UTC |\\n| Edge Functions | ✅ | Wed, 05 Aug 2026 05:48:37 UTC |\\n\\n

\\n\\n\\n\\n\\nView logs for this [Workflow Run ↗︎](https://supabase.com/dashboard/project/bsqrhnrqgpfoyiegjxmi/branches).\\nLearn more about [Supabase for Git ↗︎](https://supabase.com/docs/guides/platform/branching).\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"## ✅ Devin Review: No Issues Found\\n\\nDevin Review analyzed this PR and found no potential bugs to report.\\n\\nView in Devin Review to see 1 additional finding.\\n\\n\\n\\n

\\n\\n\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex review the exact current head. Focus on migration safety, idempotency, index definitions, rollback implications, and whether the tests actually pin the repository-to-production repair. Do not modify files or provider data.\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Avoid blocking writes while restoring live RAG indexes**\\n\\nIf this repair is replayed against a live-sized project where any of these indexes is still absent, this plain `CREATE INDEX` runs inside the migration transaction and holds write-blocking locks on `document_labels` (and the following RAG/index tables) until the build completes; the 5s `lock_timeout` only limits initial lock acquisition, not the subsequent build window up to the 15min statement timeout. Since ingestion and search telemetry write these tables, use the repo's operator prebuild/repair pattern with `CREATE INDEX CONCURRENTLY` outside the transaction, or make the migration a mark-applied-only artifact after validated live creation.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"supabase/migrations/20260804110240_restore_rag_search_health_indexes.sql\",\"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:** `f932897760`\\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\":\"**_{_{![P2 Badge](https://img.shields.io/badge/P2-yellow?style=flat)}} Pin restored index definitions, not just names**\\n\\nThis loop only checks that the migration and schema contain each index name. In the repair scenario this is meant to guard, both `CREATE INDEX IF NOT EXISTS` and `search_schema_health()` are name-driven, so the test would still pass if a restored index used the wrong table/expression/opclass/predicate while production and the canonical schema/drift definitions diverged. Assert normalized full `CREATE INDEX` definitions for the repair migration against `schema.sql` (and the drift manifest if that is the production snapshot).\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"tests/supabase-schema.test.ts\",\"side\":\"RIGHT\",\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n\\n\\n\\n\\n\\n\\n\\n@codex resolve actionable Codex review findings for this pull request and current head using the repository instructions. This is the pull request's single automatic repair pass: do not perform a fresh review, create new standalone findings, or request another review. Work only the existing unresolved Codex threads on the current head. The only repository destination is BigSimmo/Database, and the only branch destination is the pull request head branch codex/restore-rag-indexes-20260804 at starting commit f932897760ff667ddecd5d5db405303761a1b82a; never publish fixes to a detached or synthetic work branch and never create a stacked pull request. Use the authenticated GitHub connector to commit each approved fix to BigSimmo/Database:codex/restore-rag-indexes-20260804, then verify that the pull request head contains the published commit before reporting success. Always fix P0 and P1 findings. For P2 and lower findings, fix only clear, scoped, low-risk issues; otherwise disposition them with a concise reason. For a fixed thread, reply with as the first line and as the second line. For a no-code disposition, use followed by . These result markers authorize the workflow to close that exact thread only after it verifies a fixed commit is the pull request head; a local-only commit is not a fix. If publication or verification fails, do not use either result marker, do not claim success, and leave the thread open with the blocker. If human input or new authorization is required, do the same. Finish only after every actionable thread is fixed or dispositioned and closed, or explicitly left open for a human decision. Do not update the branch from main, address unrelated reviews, broaden scope, or create more than one scoped fix commit. Do not use external APIs, paid services, credentials, dependency changes, or broad refactors unless explicitly authorized. Add targeted tests where behavior changes and run the narrowest relevant validation.\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"Codex Review: Didn't find any major issues. You're on a roll.\\n\\n**Reviewed commit:** `f932897760`\\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"\\n### CI triage\\nCI failed on this PR. Automated classification of the 2 failed job(s):\\n\\n- `Unit coverage` — **needs investigation**: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.\\n- `PR required` — **needs investigation**: inspect the failing step and uploaded diagnostics; rerun only after classifying the cause.\\n\\nCompared with main CI run [#8028](https://github.com/BigSimmo/Database/actions/runs/30928144172) (cancelled).\\n\\n_Classification is evidence routing, not permission to ignore a failure. Exact quarantined Playwright identities remain governed by the flake ledger._\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"@codex review the exact current head `46533a9a1b6a524fa2d56f9c2cb3cfb54aa78542` read-only. Verify that the repair migration cannot start a write-blocking index build, fails fast when operator prebuild evidence is absent, remains safe on fresh replay, and that the test compares complete normalized index definitions across the canonical migration, schema, and drift manifest. Do not modify files or provider data.\",\"path\":null,\"side\":null,\"line\":null}{\"type\":\"pull_request_comment\",\"body\":\"**_{_{![P1 Badge](https://img.shields.io/badge/P1-orange?style=flat)}} Normalize pg_get_indexdef spacing before comparing indexes**\\n\\nWhen this runs against the current drift manifest, the pg_get_indexdef-style btree definition includes a space between the table name and column list (`public.document_index_units (...)`) while the schema/canonical SQL omits it (`public.document_index_units(...)`). The focused check `npm run test -- tests/supabase-schema.test.ts` fails at line 1117 for `document_index_units_owner_chunk_type_idx`, so this repair does not yet provide a passing guard for complete normalized definitions until the normalizer canonicalizes that spacing or both sides are generated consistently.\\n\\nUseful? React with 👍 / 👎.\",\"path\":\"tests/supabase-schema.test.ts\",\"side\":\"RIGHT\",\"line\":194}{\"type\":\"pull_request_comment\",\"body\":\"\\n### 💡 Codex Review\\n\\nHere are some automated review suggestions for this pull request.\\n\\n**Reviewed commit:** `46533a9a1b`\\n \\n\\n

ℹ️ About Codex in GitHub

\",\"path\":null,\"side\":null,\"line\":null}","text_elements",[],{"_470":939,"_449":450,"_472":456},{"_473":940,"_475":-5,"_45":-5,"_477":941,"_479":-5,"_100":360,"_96":481},[942],{"_482":456},{"_49":935,"_96":943},"input_text",{"_470":945,"_449":450,"_472":456},{"_473":946,"_475":-5,"_45":-5,"_477":947,"_479":-5,"_100":360,"_96":481},[948,949],{"_482":456},{"_49":951,"_96":943},{"_49":950,"_96":943},"\n /workspace/Database\n bash\n 2026-08-05\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 — live + archive rows are many, and eyeballing is how repeat reviews slipped through. `ledger:lookup` reads archives under `docs/archive/branch-review-ledger-*.md` too.\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=ledger` driver preserves concurrent appends and drops exact duplicate rows; after a main sync without that driver installed, run `npm run ledger:dedupe`. `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\nBabysit / Run PR ledger policy: do not push a tip whose sole delta is a babysit ledger append (that marks every other open PR behind). One Run PR row per PR per sweep; on a later sweep of the same PR, pass `--supersede` rather than stacking another \"main sync\" row. After `git merge origin/main`, run `npm run ledger:dedupe` before committing when the ledger changed.\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# Codex Desktop worktree setup\n\n- The Windows Codex Desktop environment setup command is `node scripts/setup-codex-worktree.mjs`.\n It must work before `node_modules` exists, validate Node 24/npm 11, reuse only a complete\n byte-identical local installation, and otherwise run the locked npm install.\n- Never configure Windows Desktop worktrees to run `bash scripts/setup-codex-cloud.sh`. That script\n is Linux/Cloud-only; Windows launches it through WSL outside the worktree and cannot provision the\n repository.\n- `.codex/environments/environment.toml` is autogenerated and ignored. Change the Database\n environment through Codex settings, then verify the effective command with the generated file and\n `node scripts/setup-codex-worktree.mjs --dry-run`.\n\n\n\n\n\n# Process hardening phases\n\n- **Verification principle:** run the smallest check capable of detecting a plausible regression introduced by the current diff. Before starting a check, identify the failure class it covers, whether a successful check already covered that class, whether a cheaper focused check offers comparable detection, and whether the incremental confidence justifies the runtime, resource use, and repository-lock contention. If there is no plausible changed failure path, do not run the check.\n\n| Tier | Use when | Default evidence |\n| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |\n| 0 — No test command | Explanation, planning, prompt writing, read-only inspection, or no repository change | No test, build, server, or baseline command |\n| 1 — Static/focused | Documentation, comments, metadata, or narrow non-behavioural configuration | Relevant format, docs, syntax, generated-file, or diff check only |\n| 2 — Focused behavioural | A localized helper, component, contract, or test change | Directly affected unit/DOM/contract test; add typecheck only when the edit can affect compilation or a type contract |\n| 3 — Domain gate | Shared UI/routing, dependencies, security, privacy, RAG, clinical output, production configuration, or another cross-cutting domain | The smallest applicable repository/domain selector, focused journey, or contract gate |\n| 4 — Broad handoff | The diff crosses multiple subsystems, cannot be bounded reliably, or the task explicitly requires PR/release confidence | One appropriate broad gate, selected rather than stacked by default |\n\n- Do not run a broad baseline routinely before localized work, and do not select `verify:cheap` merely because a change is described as “non-trivial.” Use `npm run verify:cheap` once when cross-module risk warrants a broad offline gate. Use `npm run verify:pr-local` when a change is ready for PR handoff: it now classifies the changed paths, runs focused documentation/workflow contracts for recognised low-risk scopes, and fails closed to lint, typecheck, the full unit suite, RAG fixture validation, and relevant build/domain gates for executable or unknown scope. If the diff has not changed, do not run `verify:cheap` first merely to repeat the same coverage.\n- Do not stack focused tests, full tests, typecheck, lint, build, and browser checks unless each catches a distinct plausible regression. Do not rerun an unchanged successful gate. A deliberately skipped low-yield broad gate is not automatically verification debt; report the skipped check and its risk-based reason concisely.\n- Use dry-run selectors before expensive gates when scope is uncertain. `npm run verify:pr-local -- --dry-run --files ` inspects PR-local selection without running commands. The broader `--extended` plan is dry-run only unless explicit approval is reflected by `ALLOW_EXTENDED_PR_LOCAL=true`.\n- CI uses the same fail-closed scope model: recognised docs and workflow/policy-only changes run focused contracts; executable product/test/config, dependency, database, container, RAG, security-sensitive, mixed, or unknown paths retain the applicable heavy jobs. Do not broaden a path trigger or restore an always-on heavy job without evidence that the focused route misses a realistic failure class. Scheduled drift/release checks and the always-reporting `PR required` aggregate remain safety backstops.\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 behaviour changes, run `npm run ensure` before browser work and prove the changed owner or journey first. Use `npm run verify:ui` when shared UI foundations changed or PR/handoff policy requires the complete Chromium gate, not as an automatic addition after focused proof. 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`. Chromium evidence does not close physical Safari or installed-PWA acceptance gaps.\n- **Run `npm run format` and commit the result before every push.** Formatting is in neither `npm run test`, `npm run typecheck`, nor `npm run lint`, so the ordinary loop can report green while the changed-file CI check or exact-commit pre-push guard fails. Three CI failures on 2026-07-30 came from exactly this (two of them on `ci/circleci: verify`, since removed from the repo by PR #1412). 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 an exact-lock `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. An isolated worktree without local dependencies may reuse Prettier only from a registered worktree with a byte-identical lockfile and matching installed Prettier version; if none exists, the guard blocks with the explicit `npm ci --include=dev` remediation instead of skipping formatting. 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 explicit release confidence, use `npm run verify:release` once; this includes the full Playwright project set and retains all provider-approval requirements. Ordinary local completion or PR handoff does not by itself authorize or require this release gate.\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 `