ci: trigger required checks on merge_group (merge-queue prep) - #183
Merged
Conversation
Adds the merge_group event to the CI and Secret Scan workflows so verify, ui-smoke, and Gitleaks run on merge-queue entries. This must land on main BEFORE a merge_queue ruleset rule is enabled — otherwise enqueued PRs would never receive their required checks and hang. Main-only steps (deployment boot smoke, release-browser-matrix) stay gated on github.ref == refs/heads/main, so they do not run for queue branches (gh-readonly-queue/*), keeping queue builds fast and free of the secrets-gated / flaky matrix jobs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dcd991882e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
gitleaks-action@v3's supportedEvents excludes merge_group and it exits with "ERROR: The [merge_group] event is not yet supported" — which would make the required Gitleaks check fail for every merge-queue entry and block all merges once the queue is enabled (caught in review). Run the action for push/pull_request/dispatch (the real scan, which happens before a PR can enter the queue) and satisfy the required check on merge_group with a documented no-op: merging already-scanned commits cannot introduce new secret material, so PR-time scanning is sufficient. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3 tasks
BigSimmo
added a commit
that referenced
this pull request
Jul 2, 2026
Merge queue can't be enabled on this repo (private + user-owned; GitHub gates the feature to public repos and org-owned repos on Team/Enterprise), so the merge_group triggers added in #183 are dead config that no queue will ever fire. Restore ci.yml and secret-scan.yml to their pre-#183 state, which also drops the now-unnecessary gitleaks merge_group guard. The strict up-to-date ruleset policy has been reverted to OFF separately, returning to the velocity-friendly setup that suits this high-churn repo. Required checks (verify, Gitleaks, ui-smoke) remain enforced. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
10 tasks
BigSimmo
added a commit
that referenced
this pull request
Jul 31, 2026
BigSimmo
added a commit
that referenced
this pull request
Aug 1, 2026
Resolve docs/error-tracking.md by keeping both the ingestion-worker section and main's Agent Monitoring wizard mapping. Resolve docs/outstanding-issues.md by keeping main's open rows, removing the blank line that orphaned #183/#186 outside the open table, renumbering this PR's npm lockfile issue to #204, and bumping issues:next-id to 205. Co-authored-by: Cursor <cursoragent@cursor.com>
BigSimmo
added a commit
that referenced
this pull request
Aug 1, 2026
…1569) * Start Therapy Compass teardown: shared layer off tc-* one-offs First slice of #183. ui.tsx is now completely free of tc-* classes, and nav.tsx, workspace.tsx and therapy-card.tsx no longer use any numbered one-off class. Sizes map to the nearest scale rung so the mode does not visibly change, per the agreed constraint. The audit corrected the scope: therapy-compass.css defines 459 selectors across 3286 lines, not the 81 base classes #183 recorded. 353 of those are auto-extracted numbered one-offs (.tc-screens-search-screen-009 and friends), which are per-element and carry no cross-file coupling. That makes them the safe independent unit, so this slice migrates only those plus the primitive kit. Three ordering constraints the audit surfaced, recorded for the rest of the teardown: - tc-root must be removed LAST. Every numbered rule is scoped `.tc-root .tc-*`, so dropping it early unstyles every un-migrated screen. workspace.tsx keeps it with a comment saying so. - controls.ts and its call sites must move together. State modifiers are two-class selectors (.tc-control-outline.tc-is-selected), so retiring the base class without the call sites silently drops the selected state. - Some rules are irreducible to utilities and need a home in globals.css rather than deletion: the print isolation block (body:has(.tc-root) * visibility plus the named @page), the #phone-header-collapse-addon-slot contextual override, and the tc-scroll scrollbar styling. Tone handling reuses the shared recipes where they are provably identical: --success is an alias of --success-text and --success-soft of --success-bg, so toneSuccess/toneInfo/toneWarning render exactly as the tc classes did. Therapy keeps local neutral/purple/accent, which the shared kit lacks, and keeps its centred loading/empty states rather than the left-aligned shared EmptyState, so the CSS retires without the mode changing. Two gates had to move with the code, both preserving their intent: - check-design-system-contract.mjs allowed only the --tc-meter-width inline style in ui.tsx. That variable existed solely to hand a data-driven percentage to the stylesheet being retired, so the exemption now covers setting the width directly. - therapy-compass-responsive-contract.test.ts counted phone reflow only as tc-stack-sm / tc-mobile-stack. It now also counts the Tailwind grid-cols-1 + sm:grid-cols-* expression of the same guarantee, and checks the disabled Favourite button by its cursor-not-allowed utility rather than a class name that is going away. Note for the endgame: check-design-system-contract.mjs asserts on therapy-compass.css contents (--tc-paper-muted, the .tc-paper focus rule, .tc-btn hover/disabled, and the paper rule boundaries). Deleting the file fails that gate until those assertions are rewritten against the migrated markup. Gate: check:design-system-contract, check:type-scale, check:icon-scale, lint, prettier all pass; therapy-compass-responsive-contract 10/10 passed. Co-authored-by: Cursor <cursoragent@cursor.com> * Retire Therapy Compass parallel CSS into Clinical Sky tokens. Delete therapy-compass.css after migrating screens and control recipes to token-backed Tailwind, keep only print/paper/compare residuals in globals.css, and close ledger #183 once verify:cheap is green. Co-authored-by: Cursor <cursoragent@cursor.com> * Format therapy teardown after Prettier pass Follow-up to the CSS retirement commit so the push blob matches format:check. Co-authored-by: Cursor <cursoragent@cursor.com> * docs: record therapy-compass CSS teardown as issue #205 (resolved in PR-T) The diverged therapy branch had locally reused #183 for this teardown, but #183 on main is the Sentry metric-alert task. Allocate a fresh id via the issues writer instead and close it in the same PR. Co-authored-by: Cursor <cursoragent@cursor.com> * fix(therapy): define local focusRing after ui-primitives rename Co-authored-by: Cursor <cursoragent@cursor.com> * docs: append branch-review-ledger row for PR-T therapy teardown Co-authored-by: Cursor <cursoragent@cursor.com> * docs: supersede PR-T ledger row for post-append tip Co-authored-by: Cursor <cursoragent@cursor.com> * Update recommend-screen.tsx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> * Update sheets-screen.tsx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> * Update brief-screen.tsx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> * Update brief-screen.tsx Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: devin-ai-integration[bot] <158243242+devin-ai-integration[bot]@users.noreply.github.com>
BigSimmo
added a commit
that referenced
this pull request
Aug 5, 2026
Add #237–#239 from the fastest-wins planning session, repair mislabeled queue rows (#201/#202 vs #183/#185), remove archived #182 from the queue, and enqueue every previously open-but-unqueued item including P1s #207, #226, and #231. Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
BigSimmo
added a commit
that referenced
this pull request
Aug 5, 2026
* issues: clarify #250 waves do not outrank A1 acuity Orphaned follow-up from PR #1624 auto-merge race. Wave packaging is the engineering track only; recommended-queue A1 rows stay acuity-first, and Wave 0 queue repair is marked landed with the #249–#251 capture. Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com> * ledger: record prlanded for merged PR #1624 Squash b03b51d landed the 1:1 queue repair; note orphaned #250 clarify fix-forwarded on this branch. Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com> * fix(issues): clarify #250 A1 track vs engineering waves Separate approval-gated A1 work from Wave 4, keep #22/#183 as A2 operator track, and restore append-only ledger order for the #1624 prlanded row. Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: BigSimmo <BigSimmo@users.noreply.github.com>
BigSimmo
added a commit
that referenced
this pull request
Aug 18, 2026
…e chain does not reproduce schema.sql (Phase 2, #56) (#2093) * feat(db): replay the full migration chain onto staging to parity (Phase 2, #56) Phase 2 of docs/database-remediation-plan.md, run in an owner-authorized staging window. Target was Clinical KB Staging (ikoiolksxqxfxgiyqpnu) via the Supabase MCP connector, with the ref re-verified on every call; production (sjrfecxgysukkwxsowpy) was never a mutation target. The gap re-measured as 28 versions at the start of the window, not the 26 recorded on 2026-08-17 — ten earlier history holes plus eighteen versions after 20260719055623. The whole chain was replayed in version order. Staging now holds 194 rows in supabase_migrations.schema_migrations, latest 20260814151000, zero statements IS NULL, and a two-way version diff against supabase/migrations is empty. Every replayed row was read back and its md5 compared against md5sum of the repository file: all 28 match byte-for-byte. supabase db push was unavailable (SUPABASE_ACCESS_TOKEN absent per #183, staging DB password operator-only) and MCP apply_migration was rejected because it stamps connector-generated versions, which docs/staging-setup.md forbids. Each migration was executed verbatim via execute_sql with an explicit schema_migrations row carrying the repository's own version and name. check:drift against staging is not yet proven. scripts/check-drift.ts forwarded only three of the five identity keys to checkSupabaseProjectConfig, so any staging URL was rejected as a production mismatch; that narrowing is fixed here, mirroring scripts/check-supabase-project.ts. The remaining blocker is the staging service-role key, which is not in this environment and which the MCP connector cannot supply. The gate was deliberately not run rather than risk pointing it at production via the only local .env.local. Six findings from the clean replay are recorded, none patched — notably that the 20260804110240 guard passed with no prebuild because staging never lost the indexes production lost, that four migrations exist as duplicate earlier/later version pairs which a plain --include-all push would apply in the wrong effective order, and that 20260724120000 silently drops the work_mem setting 20260724000000 applies. No schema file, migration, or drift manifest was changed. No production clinical document was copied to staging and no ingestion worker was started. * docs(db): record the staging drift result — the chain does not reproduce schema.sql check:drift now runs against staging and is red with 19 findings. Because staging carries the complete, byte-verified migration chain, this is not staging staleness: it is the committed chain and supabase/schema.sql disagreeing, and check:drift builds its expected side from schema.sql. Seven match_* def_hash mismatches are SET work_mem, which pg_get_functiondef renders and def_hash does not strip. grep -c work_mem supabase/schema.sql returns 0 and only 20260724000000 sets it, so schema.sql is the stale side and the fix is repo-side, not a production deploy. The eighth work_mem target, match_document_table_facts_text, is absent from the drift list precisely because 20260724120000 re-created it without restating work_mem — the exception confirms the mechanism. Eight further objects are declared in schema.sql that no migration creates or drops: five document_embedding_fields indexes, documents_status_idx, and the documents_updated_at and ingestion_jobs_updated_at set_updated_at triggers. Three table column-set mismatches and one index def mismatch remain unclassified. This bears on #316's recorded work_mem hypothesis, now measured on staging for seven of production's ten mismatched RPCs with no production call. It does not close Phase 1.2 and #316 was deliberately not updated from this session. The superseded #56 inbox request is cancelled and replaced rather than edited, per the immutable-request rule. Measurement base: ed43a64. origin/main has since advanced to 6b72b3a (195 migrations, including a schema_drift_snapshot history probe); re-measuring against that manifest is recorded as follow-up. * docs(ledger): record the Phase 2 staging-parity review
7 tasks
BigSimmo
added a commit
that referenced
this pull request
Aug 18, 2026
… schema-only objects, and three chain-stale columns (#316) (#2106) * feat(db): codify live SET work_mem on the ten match_* RPCs, the eight schema-only objects, and three chain-stale columns (#316) Database remediation Phase 3, reframed as repo-side codification (owner decisions D1 codify-as-live, D2 work_mem canary exemption). No function body changed; no hosted value changed; no production access. - supabase/schema.sql: `set work_mem = '<live value>'` on all ten match_* definitions (128MB on chunks_hybrid, embedding_fields_hybrid, index_units_hybrid, index_units_hybrid_v2; 64MB on the other six), including the effective uppercase blocks for chunks_hybrid and table_facts_text. - 20260818110000_codify_live_rpc_work_mem: ALTER FUNCTION ... SET work_mem per function, versioned after every recreate. Regenerated drift-manifest def_hash for all ten equals the live production def_hash (issue #1963, run 32051068106) byte-for-byte. - 20260818111000_codify_schema_only_indexes_and_triggers: the five document_embedding_fields indexes, documents_status_idx, and the documents_updated_at / ingestion_jobs_updated_at triggers, verbatim from schema.sql (forensics 2.3 b); unmonitored-list reasons refreshed. - 20260818112000_reconcile_chain_stale_table_columns: document_chunks .token_estimate (never in any migration) and the rag_visual_eval_cases/runs id defaults (20260705230000 bound extensions.gen_random_uuid via search_path order) - all idempotent on production. - forensics section Phase 3 written; #316 update + #183 rider queued as inbox requests. Staging proof deliberately not run: Phase 2 re-measure absent on main. RAG impact: no retrieval behaviour change - codifying already-live SET work_mem attributes and mirror-only objects; no function body changed Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(ledger): review record for PR #2106 (Phase 3 codification) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(issues): queue two Phase 3 follow-ups — check:drift column-diff clip, PR template RAG impact guidance Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(db): close guard-migration loophole and add lock timeouts for PR #2106 Review of the Phase 3 codification migrations found the forensics runbook offered mark-applied-by-CLI as an equal alternative to db push for the three new migrations, which would violate the guard-migration contract in AGENTS.md since none of them ships a validation guard. Narrow the runbook to require db push (real execution) and forbid migration repair for these versions. Also add SET LOCAL lock_timeout / statement_timeout to the two migrations that take ACCESS EXCLUSIVE locks on hot tables (documents, ingestion_jobs, document_chunks), matching the existing 20260804110240 guard pattern, so a production window fails fast instead of queueing behind a long transaction. No schema.sql change, no function body change, no live Supabase access. RAG impact: no retrieval behaviour change — same scope as the parent PR (SET work_mem attribute codification only; this commit only tightens the production-application runbook and adds lock timeouts to unrelated schema codification migrations). * docs(ledger): review record for PR #2106 fix commit Records the supabase-schema-guardian review of the Phase 3 codification migrations and the follow-up fix commit at the correct HEAD. --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
BigSimmo
pushed a commit
that referenced
this pull request
Aug 18, 2026
Cancels 88868df4-c310-4ac2-9e83-cd3ad7702a1d, another false "done" claim from this branch's original batch (same pattern as #222/#318/#309/#336): #183 asks for a live Sentry production metric alert, blocked on missing credentials and unreachable via a code diff. This branch's actual final diff contains no Sentry or alerting changes. Also resolves a collision with a separate, legitimate concurrent update request on the same row from an unrelated branch.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds the
merge_group:event to the CI and Secret Scan workflows so the three required checks —verify,ui-smoke,Gitleaks— run on merge-queue entries.This is step 1 of 2 for enabling a GitHub merge queue on
main(the frictionless pairing for the strict up-to-date policy enabled in #180's follow-up). It must land onmainbefore themerge_queueruleset rule is turned on — otherwise PRs entering the queue would never receive their required checks and would hang indefinitely. Once this is merged, the queue rule gets enabled as step 2.Main-only jobs (
Deployment boot smoke,release-browser-matrix) stay gated ongithub.ref == 'refs/heads/main', so they do not run on queue branches (gh-readonly-queue/*) — queue builds stay fast and avoid the secrets-gated smoke and the flaky browser matrix.Verification
onnow includesmerge_groupverify:ui— N/A: CI-config only, no app behavior changeClinical Governance Preflight
N/A — CI workflow triggers only; no ingestion, answer-generation, search, source, access, privacy, or clinical-output change.
🤖 Generated with Claude Code