feat(knowledge): map the CRM surface, and find a P0 the red check was reporting

[njrini99-code]

Tasks 11, 12 and 14. They turned out to be one thread: the permanently-red Supabase Preview check was telling the truth.

1. A committed P0 migration is not applied to production

supabase/migrations/20260819200000_preserve_golf_history_on_account_deletion.sql carries the owner decision of 2026-08-18 — "There should be no deletion of golf shot history". Verified read-only against production today:

Migration does	Production, today
golf_players.user_id nullable	still NOT NULL
FK becomes ON DELETE SET NULL	still ON DELETE CASCADE
adds golf_player_anonymize_on_unlink()	does not exist

And the consequence was verified against the route as it stands today, not quoted from that migration's header — eleven days and many merges separate them, and a stopgap could have landed:

• route.ts:150 — USER_BLOCKING_TABLES is still exactly the three attribution tables; nothing blocks on golf_rounds/golf_shots
• route.ts:308 — still ends in admin.from('users').delete().eq('id', user.id)
• the file names golf_rounds / golf_shots / golf_players nowhere

So the cascade still destroys the player's rounds, holes, shots, reviews and stats cache. The "93 of 94 players" figure is re-attributed as 2026-08-18's measurement, explicitly not re-measured here.

Not fixed here. Applying a production migration needs explicit owner authorization; supabase db push / migration up are denied by permissions.deny, correctly.

Task 14's answer is A, not B. The check reports a real condition; decommissioning it would silence a true alarm. The wider divergence (846 ledger versions vs 337 tracked files) is registered as MIGRATIONS_REPO_PRODUCTION_LEDGER_DIVERGENCE with honest arithmetic: most of the gap is explainable — 240 versions predate the squashed baseline, and applying via dashboard/MCP stamps its own timestamp, so 46 of 54 "missing" August versions are the same migration under a different version. Two of my own first guesses were wrong for that reason, and the incident records them rather than hiding them.

2. The CRM surface is mapped

memory/features/crm_outreach.md, written from verified code. Owns crm_recruiting_pipeline, closing the last feature_awareness_gap.

Knowledge routing only — checked, not assumed. feature-registry.ts carries an owner directive that CRM is never wrapped, tagged, or shown on the Bridge board. That row is untouched (excluded: 'crm', actions: {}). Verified memory/registry.yml is read only by scripts/knowledge/**, scripts/repo-doctor and the drift gates, and that src/lib/reliability/collect.ts uses a hardcoded route table because it "cannot read a build-time artifact".

Recorded rather than silently fixed: sending is human-triggered by omission — process-sequences is wired but deliberately absent from vercel.json, so adding it to "fix a missing schedule" starts sending cold email.

3. Two stale claims corrected forward

DATABASE_STATUS.md's "NOT FIXED — needs a product decision" heading sat above a section that had grown an "✅ APPLIED" block. Re-verified against live pg_policies, not the migration file: already fixed. And the convergence report said "two items" — there was one, plus one declared deliberate gap.

4. The gate caught the incident, correctly

docs:schema-drift failed on the incident: it names four identifiers not in the schema. That is the incident's subject. Baselining them would be wrong twice — the baseline is for known-bad references that should shrink. So a document may now declare, per identifier:

<!-- schema-drift-absent: name_one, name_two -->

Exempt only those names, only in that file, printed every run. Injection: making the declaration file-global turns that test red; script restored byte-identical.

One thing CI caught that local runs could not

The document inventory enumerates git ls-files, i.e. the index. Running it before git add of a new doc counts the tree without that doc, and the local --check then agrees with itself because both halves read the same stale index. Regenerate after staging.

Verification

preflight 0 · helm-os:check 0 · control-plane:verify VERIFIED (6 gaps) · 223 tests in src/test/scripts · ratchet 30514 unchanged. All production reads were read-only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NbDxyygyXRUEERuGocpZZH

[qodo-code-review]

ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
helmv3	Ignored	Preview	Aug 30, 2026 7:40pm

[supabase]

This pull request has been ignored for the connected project qmnssrrolpinvwjjnufo because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: addd5008-150f-4ed0-8657-394c8fc40e15

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}