Stored files · per-account folders

Bucket Migration Plans

Moving every stored file into a folder of its own account. One plan is current, one page audits it against the database, and one reports what the branch has built against that audit. The rest are superseded, kept for the reasoning that led here.

Approach
Same bucketNo new bucket, no rename, nothing deleted
Shape
6 stepsThree gates, each a full stop
Legacy prefixes
73Across 46 top-level names
Database work
41 colsPlus 47 keys inside JSON
Repositories
4Two APIs, web app, mobile app

In play

4 pages

Current plan

Same-Bucket Running Order

What we are doing, step by step, and where each one stops.

  • The bucket we already have, under two folder names it has never used
  • Records hold the complete path; the migration table is the ledger
  • Uploads staged in a temp folder until saved
  • Six steps, three gates, nothing deleted or moved
/same-bucket

Checked against clone1

Same-Bucket Path Audit

Whether the plan matches what the database and the code actually contain.

  • Every file column: complete path, bare name, or both
  • The JSON keys that hold a filename, key path by key path
  • Column widths measured against the new prefixes
  • Five things the plan does not yet account for
/path-audit

Re-checked against capClone

Path Audit Re-Validated

The path audit re-run column by column against the live database, in both clones.

  • Bare names held as JSON object keys — 180,229 rows the plan never lists
  • Fifteen columns marked pending that are already migrated
  • Five still genuinely bare, and two that are bare by design
  • The five open items re-checked: one confirmed, one crossed
/db-validation

Built on CAP-2031

CAP-2031 Build Report

What the branch does about the audit’s findings, and what it deliberately leaves alone.

  • Seven root causes closed across 32 files in three repositories
  • A backfill that rewrote 6,438 values, narrowed to the 104 that are files
  • 627,763 image elements the plan’s backfills never reached
  • Both API roles boot; six items deferred, each with its reason
/cap-2031-audit

Applied to clone1

CAP-2031 Change Set

Everything the branch changed, and what the migrations did when they ran.

  • 12 commits across four repositories, one of them new
  • All eight migrations applied, with the row counts
  • The seven root causes the audit found, and their fixes
  • Two bugs the tests caught that reading did not
/change-set

Superseded

3 pages · kept for the reasoning

Superseded

CAP-2030 Change Ledger

What the branch changed, straight from the diff. Kept as the record of the earlier build.

  • Every file the branch touches, in three repositories
  • Exact paths and counts
  • What to look at in each, grouped by role
  • How it was verified, and what is deliberately unfinished
/ledger

Superseded

New Bucket Cutover

Copy into a fresh bucket instead. Dropped: two buckets to keep in step.

  • A new bucket, filled by copying
  • No changes to any existing database table
  • One new table, drained by a scheduled job
  • Nine steps, three gates
/new

Superseded

Migration Running Order

The first pass at the same idea. Dropped: a one-shot script with no way back.

  • The same bucket, re-organised in place
  • Existing columns widened to hold full paths
  • A one-shot script rather than a scheduled job
  • Six steps, three gates
/old