@heychunky/core 0.13.0 → 0.15.0

package/register/0001-baseline/21-app-chunks.sql

@@ -0,0 +1,7 @@
+create table app_chunks (
+  app_id uuid not null,
+  chunk text not null,
+  added_at timestamptz default now() not null,
+  constraint app_chunks_pkey PRIMARY KEY (app_id, chunk),
+  constraint app_chunks_app_id_fkey FOREIGN KEY (app_id) REFERENCES apps(id) ON DELETE CASCADE
+);

package/register/0001-baseline/22-context-members.sql

@@ -0,0 +1,10 @@
+create table context_members (
+  context text not null,
+  user_id uuid not null,
+  role text default 'publisher'::text not null,
+  added_at timestamptz default now() not null,
+  constraint context_members_pkey PRIMARY KEY (context, user_id),
+  constraint context_members_context_fkey FOREIGN KEY (context) REFERENCES contexts(name) ON DELETE CASCADE,
+  constraint context_members_user_id_fkey FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
+  constraint context_members_role_check CHECK ((role = ANY (ARRAY['owner'::text, 'publisher'::text])))
+);

package/register/0002-orgs/01-orgs.sql

@@ -0,0 +1,14 @@
+create table orgs (
+  id uuid default gen_random_uuid() not null,
+  name text not null,
+  kind text default 'personal'::text not null,
+  plan text default 'free'::text not null,
+  github_org text,
+  vercel_team text,
+  vault_folder text,
+  created_at timestamptz default now() not null,
+  constraint orgs_pkey PRIMARY KEY (id),
+  constraint orgs_kind_check CHECK ((kind = ANY (ARRAY['personal'::text, 'team'::text]))),
+  constraint orgs_plan_check CHECK ((plan = ANY (ARRAY['free'::text, 'pro'::text, 'team'::text, 'enterprise'::text, 'super'::text]))),
+  constraint orgs_name_check CHECK ((name ~ '^[a-z0-9][a-z0-9-]*$'))
+);

package/register/0002-orgs/02-orgs-name-key.sql

@@ -0,0 +1 @@
+CREATE UNIQUE INDEX orgs_name_key ON public.orgs USING btree (lower(name));

package/register/0002-orgs/03-org-members.sql

@@ -0,0 +1,10 @@
+create table org_members (
+  org_id uuid not null,
+  user_id uuid not null,
+  role text default 'publisher'::text not null,
+  added_at timestamptz default now() not null,
+  constraint org_members_pkey PRIMARY KEY (org_id, user_id),
+  constraint org_members_org_id_fkey FOREIGN KEY (org_id) REFERENCES orgs(id) ON DELETE CASCADE,
+  constraint org_members_user_id_fkey FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
+  constraint org_members_role_check CHECK ((role = ANY (ARRAY['admin'::text, 'publisher'::text])))
+);

package/register/0002-orgs/04-org-members-user-idx.sql

@@ -0,0 +1 @@
+CREATE INDEX org_members_user_idx ON public.org_members USING btree (user_id);

package/register/0002-orgs/05-apps-org-id.sql

@@ -0,0 +1 @@
+alter table apps add column org_id uuid references orgs(id) on delete restrict;

package/register/0002-orgs/06-apps-org-idx.sql

@@ -0,0 +1 @@
+CREATE INDEX apps_org_idx ON public.apps USING btree (org_id);

package/register/0002-orgs/07-apps-org-name-key.sql

@@ -0,0 +1 @@
+CREATE UNIQUE INDEX apps_org_name_key ON public.apps USING btree (org_id, lower(name));

package/register/0002-orgs/08-credit-ledger-org-id.sql

@@ -0,0 +1 @@
+alter table credit_ledger add column org_id uuid references orgs(id) on delete cascade;

package/register/0002-orgs/09-credit-ledger-org-idx.sql

@@ -0,0 +1 @@
+CREATE INDEX credit_ledger_org ON public.credit_ledger USING btree (org_id, created_at DESC);

package/register/0002-orgs/10-api-tokens-org-id.sql

@@ -0,0 +1 @@
+alter table api_tokens add column org_id uuid references orgs(id) on delete cascade;

package/register/0002-orgs/11-api-tokens-created-by.sql

@@ -0,0 +1 @@
+alter table api_tokens add column created_by uuid references users(id) on delete set null;

package/register/0002-orgs/12-backfill-personal-orgs.sql

@@ -0,0 +1,15 @@
+-- Everyone who has claimed a username gets the personal organisation of that
+-- name, carrying the plan they are on today.
+--
+-- The username is the scope: `@dan/auth` was already going to mean Dan, and an
+-- organisation is what that scope now names. A user who has not claimed one
+-- yet gets no organisation here — `claimUsername` makes it in the same breath
+-- as the name, so the two can never disagree about who owns `dan`.
+--
+-- Guarded by `not exists` rather than `on conflict`, because the unique index
+-- is on `lower(name)` and a conflict target has to name the index expression.
+insert into orgs (name, kind, plan)
+select u.username, 'personal', u.plan
+  from users u
+ where u.username is not null
+   and not exists (select 1 from orgs o where lower(o.name) = lower(u.username));

package/register/0002-orgs/13-backfill-org-members.sql

@@ -0,0 +1,12 @@
+-- A personal organisation has exactly one member, and they run it.
+--
+-- `admin` rather than `owner`: ownership of the organisation is not a role, it
+-- is what `kind = 'personal'` and the matching username already say. The two
+-- roles that exist are the two that describe what somebody may do — administer
+-- the organisation, or publish under it.
+insert into org_members (org_id, user_id, role)
+select o.id, u.id, 'admin'
+  from users u
+  join orgs o on lower(o.name) = lower(u.username) and o.kind = 'personal'
+ where u.username is not null
+on conflict (org_id, user_id) do nothing;

package/register/0002-orgs/14-backfill-apps-org.sql

@@ -0,0 +1,14 @@
+-- Every app moves into its owner's personal organisation.
+--
+-- Joined through the username rather than through `org_members`, so exactly one
+-- row can match: `orgs_name_key` is unique on `lower(name)`, and a user is a
+-- member of one personal organisation by construction but the join could not
+-- prove it. An `update ... from` that matches twice picks one arbitrarily and
+-- says nothing, which is precisely the silent wrong backfill to avoid.
+--
+-- `org_id is null` makes it repeatable, and leaves alone any app already placed.
+update apps a
+   set org_id = o.id
+  from users u
+  join orgs o on lower(o.name) = lower(u.username) and o.kind = 'personal'
+ where u.id = a.owner_id and a.org_id is null;

package/register/0002-orgs/15-backfill-credit-ledger-org.sql

@@ -0,0 +1,11 @@
+-- Credit is spent by an organisation, not by a person in it.
+--
+-- Empty on the factory's own register today. It is written anyway because the
+-- migration has to be correct for any register it meets — a staging factory, a
+-- test — and because a backfill written later, against rows that exist, is a
+-- backfill written under pressure.
+update credit_ledger l
+   set org_id = o.id
+  from users u
+  join orgs o on lower(o.name) = lower(u.username) and o.kind = 'personal'
+ where u.id = l.user_id and l.org_id is null;

package/register/0002-orgs/16-backfill-api-tokens-org.sql

@@ -0,0 +1,12 @@
+-- A token names its own organisation, which is what answers "whose data is
+-- this" for a request that arrives with no session behind it.
+--
+-- `created_by` keeps the person, because a token is minted by somebody and a
+-- revoked key is only findable if the register remembers who made it. The
+-- organisation is the tenancy; the user is the provenance — the same split
+-- `apps` makes between `org_id` and `owner_id`.
+update api_tokens t
+   set org_id = o.id, created_by = coalesce(t.created_by, t.user_id)
+  from users u
+  join orgs o on lower(o.name) = lower(u.username) and o.kind = 'personal'
+ where u.id = t.user_id and t.org_id is null;

package/register/README.md

@@ -0,0 +1,73 @@
+# The register's own schema
+
+`.heychunky/migrations` is how an *app's* database changes: files ride the
+branch, and `_heychunky_migrations` records what each database has applied. The
+register had no equivalent — it is not an app and has no repository of its own,
+so its schema lived only in the database and in whoever remembered typing it.
+
+It has one now. This directory is that repository, and the mechanism is the
+same one an app gets rather than a second one.
+
+```
+register/
+  0001-baseline/   the register as it stood on 2026-09-08, 22 statements
+  0002-orgs/       organisations, the tenancy boundary — 16 statements
+```
+
+**A change is a directory, its statements numbered inside it.** One statement
+per file, because the database client sends one query per request and answers a
+string holding two as though all was well. The ledger id is the path —
+`0002-orgs/05-apps-org-id.sql` — so what a database has applied reads as whole
+changes rather than as filenames somebody has to regroup mentally.
+
+Both numbers pad, because everything sorts lexically.
+
+## Applying it
+
+```
+heychunky register                        what it has, and what it owes
+heychunky register migrate --confirm      apply what it owes
+heychunky register verify                 what must be true of the rows
+```
+
+All four take `--app <app> --env <environment>` to reach a register other than
+the factory's own. There is more than one: heychunky-app runs in six
+environments and each has a database of this shape, which is how the schema
+reaches the one the tests and the dev deployment use.
+
+The files are read from the installed Core rather than from a repository at a
+ref, which is the one place this differs from an app's migrations. An app's
+files ride the branch, because "what does staging still owe" has to be
+answerable from the branch alone. The register has one database and no ladder,
+so the schema it can be brought to is the schema its CLI was built against —
+and no unreviewed local edit can reach it by accident.
+
+## Adopting, for a database that predates the ledger
+
+The baseline is a record before it is a script. The live register already held
+every statement in it, so running it would fail on the first `create table`:
+
+```
+heychunky register adopt 0001-baseline --confirm
+```
+
+That records the statements as applied having run none of them. It is **checked
+rather than trusted** — every statement's table or index is looked up in the
+catalog first, and a change that is not entirely true of the register is refused
+with the missing pieces named. The failure it guards is invisible otherwise: a
+false receipt, and then a schema change silently skipped forever after.
+
+It found real drift the first time it ran. The factory's dev register had no
+`runs` table where production did, so the honest sequence there was to apply
+that one statement and adopt the rest. A single statement id is accepted as well
+as a change name, which is how that is done.
+
+## What is deliberately not enforced
+
+**Deleting a user leaves their personal organisation behind.** `org_members`
+cascades; `orgs` does not, because an organisation outlives the people in it —
+and no foreign key can say "except the personal one". There is no delete-a-user
+path in the product today, so the invariant is left to `register verify`, which
+counts a personal organisation whose name is nobody's username. When deleting a
+user becomes a real operation it deletes the organisation too, and that check is
+what will catch anyone who forgets.