fix(lokee): revert only against the current database, snapshot first, and say it in the reader's words

[huyplb]

Four commits taking schema history from "works" to "shippable". Two are correctness bugs; the rest is the launch-readiness pass.

1. What you review is not what runs

The diff came from compareLokeeVersions(original, target) while the plan and the execute call went to planLokeeRevert(original) — which reverses from the live head and ignores Target entirely. With an older version on Target you reviewed one script and Execute applied a different, usually larger one.

Reproduced in the UI: a dialog headed "Original Version 10 → Target Version 13" above a button that would have applied v15 → v10.

A revert restores the live database, so it is only coherent when Target is the newest version. Anything else is refused, with a one-click Use current database to fix it. An open dialog now follows the picker instead of holding the pair it opened with — otherwise that button changed the bar behind the modal and appeared to do nothing.

2. Snapshot before touching anything

The revert route now captures the live schema first. The restore point matters, but the correctness win matters more: planRevert reverses from the newest captured version, not from what is in the database, so a schema edited by hand since the last capture was being reversed against a picture that no longer existed.

When the snapshot finds drift the request is refused (schema_drifted), not applied — the caller reviewed a plan built on the old head. Verified against the live API:

	result
No drift → revert v2 → v1	ok=true, column dropped
Hand-add a column, retry	schema_drifted, nothing applied, drift kept as its own version

3. The loudest warning was on the safest operation

ReversalRisk defines lossy as "succeeds but destroys or truncates data". Re-creating a dropped column does neither — it adds one back, empty, because the rows went when it was dropped. Classifying it lossy meant a plan of nothing but ADD COLUMN came back risk: lossy, displayed "This revert destroys data", and demanded a data-loss acknowledgement — on the single most common thing anyone does with version history: bringing a database that has fallen behind back up to date.

Verified on a database three versions behind: risk: lossy, lossyCount: 2 → risk: safe, lossyCount: 0, executes without confirmation, both columns restored. The note explaining the column comes back empty stays; the gate does not.

This is also what makes migrate any version → latest usable — the mechanism was already there, buried under a false alarm.

4. Launch-readiness pass

• A deleted column was typed table. objectType: row.object_type ?? 'table', and the delta row carries no type — so a deleted column drew with a table's icon and slipped through the table filter as a phantom table. The key already says what it is.
• Compare keys off the cards. ORDERS.NOTE is an uppercased match key that exists nowhere in the user's database (CLAUDE.md is explicit about this). Cards read NOTE, with deleted from orders beneath.
• Filters that can change what you see. The type list was the union of all dialects, so SQLite users saw MQT — a Db2-only term — beside Procedure and Function boxes that could never match. Now offers only types the history contains: 8 checkboxes down to 2 on the SQLite demo.
• Words, not internals. "reused" → "unchanged" throughout; "Content-addressed schema history (Lokee)" → what the feature does; header reads "Schema history" everywhere.
• A first run you can act on. The empty state was a paragraph pointing at a button on another bar. It now holds the database picker and Take first snapshot.
• The run button names its destination — "Update to v2" when nothing is destroyed, "Revert to v2" when something is, instead of "Execute migration (3)".
• The author line earns its place — shown only when versions actually have different authors, rather than the same address down the whole column.
• [sqlite] /tmp/app.db.main → sqlite · /tmp/app.db · main; the dotted suffix read as a file extension.

5. Licensing

The React Flow attribution badge is hidden. @xyflow/react is plain MIT (node_modules/@xyflow/react/LICENSE) and its only condition is that the notice accompany the software — the badge is not a licence term. xyflow asks that you subscribe to Pro when hiding it; the project has chosen not to.

That surfaced the condition that was unmet: the client bundles 38 third-party packages under MIT/BSD/ISC, all requiring their notice to travel with the code, and NOTICE carried only Fox Schema's own Apache-2.0 terms. Added THIRD-PARTY-NOTICES.md (generated by scripts/generate-third-party-notices.mjs), un-ignored it — .gitignore blanket-ignores *.md and would have kept it out of the repo — and the Dockerfile now copies LICENSE, NOTICE and it into the image.

Only gap: @google-cloud/secret-manager ships no licence file of its own; its entry names the licence and links upstream.

Reviewer notes

• The e2e type-filter assertion was updated deliberately: it asserted Procedure and Function filters are visible on a SQLite seed that has neither. It now asserts the types the seed actually has, and that MQT/Procedure are absent.
• Reclassifying re-create as safe removes a confirmation gate. That is the intended effect — the operation destroys nothing — but it is the change most worth a second opinion.

Gates

npx tsc --noEmit clean · npx vitest run 1955 pass / 2 expected-fail · eslint 0 errors.

🤖 Generated with Claude Code

---

Note

Medium Risk
Revert and snapshot logic on the live schema path can block or apply DDL incorrectly if drift or version targeting is wrong; reclassifying re-create as safe removes a confirmation gate on catch-up plans. Licensing and Docker copy changes are low operational risk but affect compliance artifacts.

Overview
Revert correctness ties the compare modal to what actually runs: execute only when Target is the newest captured version (otherwise block with Use current database), keep an open compare dialog synced with the bar’s pair, and label runs as Update to vN vs Revert to vN based on whether the plan destroys data. The revert API now snapshots the live schema first and returns schema_drifted when drift is found so reviewed plans are not applied against a stale head.

Reversal risk reclassifies re-creating dropped tables/columns as safe (not lossy) so catch-up ADD COLUMN plans skip false data-loss confirmation; explanatory notes about empty re-created objects remain.

History graph and labels infer object type from delta keys (fixes deleted columns showing as tables), split compare keys on cards via objectDisplayName, offer only object-type filters present in the history (offeredObjectTypes), and refresh copy (unchanged vs reused, schema history subtitle formatting, empty-state Take first snapshot, compare-only version labels).

Distribution adds THIRD-PARTY-NOTICES.md and scripts/generate-third-party-notices.mjs, tracks the file in .gitignore, extends NOTICE, copies LICENSE/NOTICE/notices into the Docker image, and hides React Flow’s on-canvas attribution (hideAttribution: true) with MIT notice in third-party file.

Tests update e2e SQLite credential helpers and schema-history type-filter expectations; vitest covers revert targeting, run-button labels, and graph display helpers.

^{Reviewed by Cursor Bugbot for commit 8299992. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_d64947dc-7207-491d-b503-230b343264ca)

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_d76ad6ce-12b7-4a98-95c5-22fa2a7997d0)

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_debeb405-a541-4a76-adbb-3ce454689fcc)