Skip to content

chore: production readiness improvements and E2E fixes - #103

Merged
BigSimmo merged 1 commit into
mainfrom
feature/production-readiness-fixes
Jun 29, 2026
Merged

chore: production readiness improvements and E2E fixes#103
BigSimmo merged 1 commit into
mainfrom
feature/production-readiness-fixes

Conversation

@BigSimmo

Copy link
Copy Markdown
Owner

Resolves type/lint warnings, missing BadgeCluster/ClinicalBadge components in the medication workspace, and timing issues in E2E tests.

@BigSimmo
BigSimmo merged commit 74912df into main Jun 29, 2026
3 of 5 checks passed
@BigSimmo
BigSimmo deleted the feature/production-readiness-fixes branch June 29, 2026 04:59
BigSimmo added a commit that referenced this pull request Jun 29, 2026
BigSimmo pushed a commit that referenced this pull request Jul 29, 2026
…iew batch

Eight review findings (1 Codex P2, 7 CodeRabbit), each verified against the
code before acting.

MOST CONSEQUENTIAL — the L2-3 "recall is byte-identical" claim was wrong, and
it was load-bearing. fetchDocumentTitleAliasRows (rag-candidate-sources.ts:482)
applies .limit(12) with no ORDER BY, so which twelve documents return is
plan-dependent; a new index can change the title-alias set feeding candidate
assembly. "No query text changes" is true, but recall does not follow from it.
That claim was the argument for keeping L2-3 out of canary territory, so the
gating is revised: the documents-list and (status,id) uses stay ordering-safe,
the RAG-path index is canary-gated unless the unordered .limit(12) is made
deterministic first — the cheaper fix, since an unordered LIMIT is latent
nondeterminism regardless of this work.

Operator SQL alone never reaches staging, DR, or local replay: migrations/ is
the source of truth and schema.sql only a mirror, so hand-run statements hit
the live database and nothing else, and a required_indexes registration would
fail on every replayed environment. Authoring the migration is now a required
part of #102, following the 20260717170000 idempotent pattern. This PR still
ships no migration (the #1312 objection), but the runbook no longer implies
the operator sequence is sufficient.

Test guard hardened: the ordering case anchored on a fixed 5 ms sleep, which
can expire before the handler reaches the limiter. It now waits for
consumeSubjectApiRateLimit to be entered, then asserts scope is untouched — the
same guarantee without the timing fragility.

Ledger: the 78e2beb record still described the reverted scope-vs-ratelimit
overlap. The ledger is append-only, so this appends a superseding record via
ledger:append --supersede rather than editing the row, per the contract.

Status wording: #102 is "runbook prepared", not done, while the operator steps
are pending; #105 separates shipped implementation from pending browser
verification; #98/#99/#102/#103/#105 restored to the execution queue with
their remaining actions. Fixed the MD038 malformed RAG-impact code span.

Verification: verify:cheap exit 0 (427 files, 4386 passed / 4 skipped);
check:branch-review-ledger pass (1232 records, no duplicates).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01361jh3eYVjJCzXWjAhdZiF
BigSimmo pushed a commit that referenced this pull request Jul 29, 2026
#103's outcome is that the migration chain and schema.sql agree on
document_table_facts trigram indexes, but the row offered
drift-allowlist.json as an alternative to mirroring. It is not one.

The allowlist's own header scopes it to "Known live-vs-schema.sql
divergence" -- it suppresses a live drift finding and cannot make the two
schema sources agree. A fresh `supabase db reset` still runs
20260714190000 and creates document_table_facts_text_trgm_idx while
schema.sql still omits it, so the divergence survives the allowlist
entirely.

There are exactly two routes: mirror it into schema.sql and regenerate the
manifest if retained, or drop it via a forward migration if the live scan
evidence shows it redundant.

Also records that no offline gate catches this -- the migration/schema.sql
parity test only asserts one migration's schema_drift_snapshot function
definition, not an index inventory.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01361jh3eYVjJCzXWjAhdZiF
BigSimmo pushed a commit that referenced this pull request Jul 29, 2026
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01361jh3eYVjJCzXWjAhdZiF
BigSimmo added a commit that referenced this pull request Jul 31, 2026
…s fixed (#1529)

Several comprehensive-audit-* worktrees carry an uncommitted row archiving #149
as resolved, asserting check:installed-lock-parity now validates every concrete
package location including nested transitives. That fix exists nowhere: not on
main, not in any of the 42 worktrees, and not in any open PR. main still reads
criticalInstalledPackages = ["next","react","react-dom","eslint","playwright",
"typescript","vitest"].

Without this note the next session to sync those worktrees would archive a live
issue on a claim the code contradicts. The sibling #103 disposition from the
same worktrees was verified true and landed in #1528; this one was not.

Row edited with npm run issues:update, not by hand.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant