/import-supabase

name: blueprint-from-collection-import
description: "Move the copied collection's records into Postgres and the files they point at into Storage, proven on a freshly reset local database."

Move the records in

Read `.blueprint/source/source.json` first. If `records` is `false`, only the shape was copied: there is nothing to move. Add a `yarn import-source` script that says so and exits 0, and stop.

Otherwise the records are in `.blueprint/source/collections/<slug>/records.jsonl` (one JSON object per line, as the collection stored them), and the files they point at are under `.blueprint/source/files/`, at the path the record names.

1. Add `yarn import-source <where> [--owner <email>]`, where `<where>` is `--local` or `--linked`, passed to every Supabase CLI call it makes (`yarn supabase …`). It never takes or reads a secret key, and it does not reset or migrate the database: the check has already done that. 2. It turns the records into SQL — every collection in `source.json`, the ones linked to first so references have something to point at — writes that to a temporary `.sql` file, and runs `yarn supabase db query <where> --file <it>`. That command runs ONE statement only (more are refused as "multiple commands"), so wrap the whole import in one `do $$ begin … end $$;` block. Keep the part that turns records into statements a module of its own, so a test can run it. 3. Names and types follow the spec and the pack's `spec/conversion.md` ("表と列の名前" and "Supabase（Postgres と Storage）"): the table is the collection's slug with `-` as `_`; a stored field's column is its key, unchanged; a boolean is a boolean, a date a `date` or `timestamptz`, a `ref` keeps the referenced primary key, a `table` field's rows go to its child table. A key with a capital letter (`startedOn`) is double-quoted everywhere it appears in SQL — the migration and the import — or Postgres lowercases it and the check cannot find the column. 4. Running it twice leaves the same rows: insert with an upsert on the primary key (`insert … on conflict (<key>) do update set …`), and replace a record's child rows with it. 5. Who owns the imported rows is the spec's decision. By default: `--owner <email>` names the account, looked up with `yarn supabase db query <where> "select id from auth.users where email = '…'"`; without it, locally, the first seeded user. Refuse, with the reason, when the owner cannot be found. 6. Files: when a record points at an `image` / `file`, create the bucket in a migration (`insert into storage.buckets (id, name, public) values ('<bucket>', '<bucket>', false) on conflict do nothing;`) with Storage policies (`storage.objects`) that follow the spec's read and write rules. An object the CLI uploads has no `owner`, so a read policy on `owner = auth.uid()` locks its owner out: read through the row that points at it instead, `bucket_id = '<bucket>' and exists (select 1 from public.<table> t where t.<column> = storage.objects.name)`, which the table's own RLS then decides (write `storage.objects.name` in full: a bare `name` means the table's column when it has one). Write the bucket's name to `.blueprint/supabase-bucket`, and upload each file the source has with `yarn supabase storage cp .blueprint/source/files/<path> ss:///<bucket>/<path> <where> --experimental`, the key being the path the record names. `storage cp` does not overwrite (a second run is refused as a duplicate), so remove the object first with `yarn supabase storage rm ss:///<bucket>/<path> <where> --experimental --yes`, which succeeds when there is none. A file the source did not have is left out and reported. 7. A record that does not fit (a value the column refuses, a reference to nothing) is not dropped silently: the script stops and names the collection, the record's primary key and the field. 8. `test/import.test.ts`: against the local stack, run the statements the module builds and read a record of each collection back. 9. Run `yarn import-source --local` once, so `yarn start` shows the records. Say in the README how the records were moved: `yarn import-source --local` fills the local stack, and `--linked --owner <email>` is what moves them to production.

Done when the check passes: into a database reset to the migrations and the seed, run twice, every collection has as many rows as it had records, every stored field reads back equal to the source, every pointed-at file is in the Storage bucket with the source's bytes, and `yarn test` passes.

Always

• Read `.blueprint/spec.md` first. It is the agreed specification; do not widen it.
• When you need a decision, ask it through the blueprint question tool and stop. Do not guess.
• Do not run `git init`: a new repository loses the folder's trust and the next unattended step stops at Claude

Code's trust prompt. The user adds git themselves after the build if they want it.

• Never use `--linked` in this step: it writes to the person's Supabase project, which only the publish steps are

approved to do.

• Say you are done by stopping; the executor runs the check. Do not claim success yourself.