docs(db): ledger — assist_ladder apply + folded chat-log record (#887)

[thomgabriel]

Gate ops record: assist_ladder MCP-applied 2026-07-30 (version 20260730203300) per #887's adversarial apply checklist, all post-invariants green. Also records the #708-class discovery: 20260715160000_ai_partner_chat_log.sql was never applied to prod (feature silently dead) — folded into assist_ladder §0 and now live. Docs-only.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
superteam-academy-web	Ready	Preview	Jul 30, 2026 8:36pm

[claude]

Claude finished @thomgabriel's task in 2m 36s —— View job

---

Claude finished the code review

• Read CLAUDE.md, docs/TASK-CODES.md
• Read the changed file (docs/DB-MIGRATION-LEDGER.md) and diff vs origin/main
• Cross-checked ledger claims against the actual repo state
• Posted findings

---

BLOCKING

The new assist_ladder ledger row names a migration file that does not exist anywhere in the repo. (docs/DB-MIGRATION-LEDGER.md:70)

The added row claims:

| `20260730120000_assist_ladder.sql` | `20260730203300` | `assist_ladder` | applied 2026-07-30 ... post-verified (5/5 fns conformant, RLS on/0 policies, baseline 11/19/9 untouched, new cols zeroed, read smoke OK) |

supabase/migrations/20260730120000_assist_ladder.sql is not in the working tree, and git log --all --diff-filter=A -- "supabase/migrations/*assist_ladder*" returns nothing — this filename has never existed in this repo's history. Every other row in the table (billed_assists_counter, add_xp_transactions_source, email_subscriptions, etc.) corresponds to a real file under supabase/migrations/; assist_ladder is the sole exception.

This is exactly the failure mode this ledger doc exists to prevent (#708: "the database is correct; the record of it is not") — except worse: for every other row the SQL is at least in the repo and auditable even if the ledger version diverges. Here there is no SQL artifact in the repo at all, so:

• The "repo filename (version)" column names a file that isn't a repo filename.
• None of the asserted post-verification claims (5/5 fns conformant, RLS on/0 policies, cols zeroed) can be checked by anyone reading this repo — they're asserted as fact with zero backing artifact.
• The row for 20260715160000_ai_partner_chat_log.sql (docs/DB-MIGRATION-LEDGER.md:71) says its objects were "folded idempotently into 20260730120000_assist_ladder.sql §0" — unverifiable, since that file/§0 doesn't exist to inspect.

Compounding this: supabase/migrations/20260715160000_ai_partner_chat_log.sql is still present in the repo, untouched, while the ledger now claims its functionality is "live" via the (non-existent, in-repo) assist_ladder migration. A future supabase db push would still see this original file as unapplied (per this doc's own §"Consequences" #1) and attempt to run it — with no way to know if that collides with whatever was actually applied to prod via MCP.

This PR should not merge as-is. Either:

1. The 20260730120000_assist_ladder.sql file needs to be added to supabase/migrations/ in this PR (or a preceding one) so the ledger's claims have a real artifact to point at, or
2. If the SQL genuinely only exists as an ad-hoc MCP apply with no committed file, that needs to be stated explicitly in the row (not implied to be a normal repo-tracked migration) and marked PENDING-GATE-VERIFY per this doc's own convention (lines 16–20), not asserted as verified fact.

Fix this →

Non-blocking

• The ai_partner_chat_log row (docs/DB-MIGRATION-LEDGER.md:71) and the assist_ladder row both state specific facts (ledger version, "5/5 fns conformant", "folded idempotently") without the PENDING-GATE-VERIFY marker this doc's own preamble (lines 16–20) says should apply when a claim isn't independently gate-reported/verifiable from the repo. Given the finding above, at minimum the assist_ladder row should carry that marker until its SQL is committed.
• Table-formatting-only changes (column padding) elsewhere in the diff are cosmetic and fine.

Everything else in the diff (existing rows, prose, reconciliation instructions) is unchanged content, just re-padded — no other issues found. This is a docs-only PR; no RLS/on-chain/secrets code paths are touched directly, but the row it adds makes unverifiable claims about live RLS/policy state on prod tables, which is why I'm treating this as blocking rather than a nit.
· branch