§3: re-measure the multi-user premise, and say why it is not mine to fix tonight

2026-08-07 14:43:48 +00:00
parent 6eac14a2b7
commit 90c546c098
1 changed files with 24 additions and 0 deletions
@@ -177,6 +177,30 @@ and the rename sequence leaves `workspaces` with no zombie.
 to single-user — that predates the capability permission model and should not be used to deprioritise
 these.
 > **Re-measured 2026-08-07.** The premise above has moved and the section is no longer hypothetical.
 > `users` holds **five rows** (`pastilhas@`, three outside addresses, one `captest@`) and `dashboards`
 > holds **one** (`agent-mvp`, the coordination demo). So the collision needs one member to name a
 > dashboard something the owner already used — it is reachable today, by a person, with no code change.
 >
 > It also puts this section in **direct contradiction with `CLAUDE.md`**, which opens by calling
 > single-user "a hard invariant, not a stage" — no roles, no per-user isolation, and "if a change seems
 > to need *which user is this*, the answer is always the owner." Five rows in `users` says otherwise.
 > One of the two documents is wrong about what this platform is, and that is a **product question, not a
 > defect**: the answer decides whether the item below is urgent or should be deleted along with the rest
 > of the section.
 >
 > **Deliberately not fixed unattended**, and the reasons are worth stating so the next pass doesn't
 > re-litigate them. It is a schema change, so it needs `bun db:push` — which would also apply another
 > agent's uncommitted schema files sitting in the same tree tonight. It has a real fork (composite PK vs
 > uuid ids) with different blast radii for anything storing a dashboard id as an address, and
 > `agent_panels.dashboard_id` is exactly that. And composite PKs carry the drizzle re-diff quirk that
 > `databases/CLAUDE.md` warns about. Small change, several ways to be sorry.
 >
 > **Recommendation, for the owner to accept or reject in one line:** composite PK `(user_id, id)`. It
 > matches the `uq_dashboards_user_id` index that is already there — the evidence the item cites that
 > per-user ids were the original intent — and it leaves every stored `ws-layout-<id>` address valid,
 > which uuid ids would not.
 - [ ] **`dashboards.id` is a global primary key but ids are `slugify(name)`.**
      `databases/officer_db/src/schema/dashboards.ts` declares `id: text('id').primaryKey()`. Live:
      `"dashboards_pkey" PRIMARY KEY, btree (id)` plus a redundant