CAP-680 · what is not covered

What CAP-680 Does Not Do

CAP-680 built the copier. It has not run it, and it does not reach everything the backfill converted. This page is the measured remainder — each item read out of the code or the database, not inferred from the commit messages.

Path columns

73The authoritative list in path-references.ts

Covered by CAP-680

13Plus qr_codes, which is not a column

Uncovered, holding paths

26Across 55,137 values in clone1

Excluded by decision

2documents.file_path, equipment_models.selected_image

Queue rows

0Never seeded, never run

Gate 3

Not runNo account copied or rolled back

The columns with no descriptor

Legacy values — a complete path whose first segment is neither img nor doc — in columns the backfill rewrote but the copier does not name. Counted in clone1 on 2026-09-08.

Every uncovered column

Every entry in PATH_COLUMNS that MIGRATION_DESCRIPTORS does not reach and that actually holds a file path — a value that starts with a known BucketFolder, not merely a column whose text mentions one. Each row carries a real value out of clone1 and the destination the upload table would give it; {CAP} is the owning account and {user} a user id, because the destination is per-row.

Where those objects live

Grouped by the legacy folder they sit in, the uncovered references reach folders no descriptor names at all. The largest are inventory/biomed-import, ezrfp-quote, document-manager, eula, ezrfp/attachments, ezrfp-warranty, service-agreement, pa-documents and profile — so the objects behind them are never copied, not merely left un-rewritten.

References are not objects

The table above counts rows, which is the right unit for the write-back — every one of them names a legacy path and would need rewriting. It is the wrong unit for the copy. The queue is keyed on the destination, so what the runner actually owes is one copy per (object, owning account) pair.

It has never been run

file_migration_queue and file_migration_batches both hold zero rows in clone1 — the database where every migration is applied. The copier has therefore never been seeded, never copied an object, and never written a path back. Everything on the previous page is built and reviewed; none of it is exercised.

Three consequences follow directly:

• Gate 3 has not been passed. The gate requires one account copied, verified and rolled back once for real. No account has been copied, so the rollback — the thing every later batch depends on — has never been run against live data.
• The rehearsal mode is untested in anger. FILE_MIGRATION_TARGET_PREFIX exists precisely so this can be exercised end to end against a scratch folder. That is the cheapest way to close Gate 3 and it has not been used.
• It cannot run against production as it stands. capClone is missing the two ledger tables, the run switch, and the PO-path migration — four migrations behind clone1.

Three descriptors that do nothing

These are declared rather than forgotten — the seeder records them so they appear in the report — but they move no files.

What CAP-680 was never meant to cover

Listed so the boundary is explicit rather than assumed. These belong to other steps, and CAP-680 not doing them is correct — but they all gate a real run.

What would close it

1. Assert the two lists against each other. A test that walks PATH_COLUMNS and fails on any entry with neither a descriptor nor a recorded exemption would have caught all 26 of these at authoring time. It is the fix that stops this class of gap returning, and it is cheap — both lists already exist.
2. Decide each of the 26 deliberately. Add a descriptor, or record why it does not need one — the way qr_codes already does with noWriteBack. Start with biomeds.extracted_data (20,052) and camp_inventory_items.additional_details (15,533, nearly all cad.cadUrl): neither table appears anywhere in the plan.
3. Record the two exclusions in code. documents.file_path and equipment_models.selected_image are out of scope by decision, but nothing in the repository says so — which is the same invisibility the other 30 have. A skipReason against each would make the choice legible to the next reader.
4. Run the rehearsal. Set FILE_MIGRATION_TARGET_PREFIX, seed, run one account, write back, roll back. That closes Gate 3 without touching a real destination.
5. Confirm the deployed thumbnail service keeps up with a batch run. It is live on the finalize event, so a copier batch will fire one invocation per object copied — worth knowing the concurrency ceiling before a large account goes through.
6. Bring capClone up to date — four migrations, or the copier has nothing to work through in production.