@bongos/core 1.19.536 → 1.19.538

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.536",
-  "core_contract": "1.19.536",
-  "source_commit": "91d912719b37497561bd71e9aff21b0d07128ce7",
+  "core_version": "1.19.538",
+  "core_contract": "1.19.538",
+  "source_commit": "27d5678834bfd261666f02a704b7840851b767e0",
   "source_ref": "HEAD",
-  "built_at": "2026-09-04T15:11:58.158Z",
+  "built_at": "2026-09-04T15:34:15.511Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 439,
+    "docs_redacted": 440,
     "agent_docs_stubbed": 24,
-    "functional_verbatim": 1995,
+    "functional_verbatim": 1997,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2458,
-  "tree_sha256": "d97db0f024e5887d1e765ab22ac86d124015c3a97cf3f44989b82c2d0f1493ac",
+  "file_count": 2461,
+  "tree_sha256": "4707649225bfa5206e00215584d7af14215d63884dea6d8e45213d98dda405af",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -1749,20 +1749,25 @@
       "mode": "0000644",
       "sha256": "f46ee74d7b83ad4422e1832fdba68a8b9ea0deccb425ab3083d4c8fbfd06eb02"
     },
+    {
+      "path": "docs/adr/0248-a-hub-project-s-owner-is-the-provisioning-row-carried-on-a-port.md",
+      "mode": "0000644",
+      "sha256": "cbcac548fc3b683fd7219e312ab1542768c973aca5112d8cbc9ad0b2d09da650"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "d1bb4772b43b56cf1efa16fa99f255535bd736910c4c0ead94249f19862c7152"
+      "sha256": "d5043a4e032d28341a3619a0cf6a6ce54b01ba83af24f2a7b28298da73ff769c"
     },
     {
       "path": "docs/api-reference.md",
       "mode": "0000644",
-      "sha256": "88fb38cb095713380c1c70187816c33c930cf962d9e4641ec4bb740da56ba90b"
+      "sha256": "aef38c3ecd8942f0a38c56cbb390fd3590e785634d24e95660900a5140636b5f"
     },
     {
       "path": "docs/api/openapi.json",
       "mode": "0000644",
-      "sha256": "b2ce137944f23684f4ba805d4bda73ba1ab7477279e2a24fbcd5c068f7a25bad"
+      "sha256": "923202b89890cc048769c8b05087181fa06ff126aa80aeaa4d9f669f4d96c27e"
     },
     {
       "path": "docs/architecture.md",
@@ -2637,7 +2642,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "1107b8275d73b7e9e3410a6153bee4107718272c3bc7c2471241ea9f5c076fc0"
+      "sha256": "a5362e7ae082e4377ed2bf228a99d7ad0df0e1d059488a819595ef646dd1f1ae"
     },
     {
       "path": "docs/modules-contract.md",
@@ -5824,6 +5829,11 @@
       "mode": "0000644",
       "sha256": "01d30570d828a1f06ccac693cc5c268d00fb091a13412a3f3890f10828a05203"
     },
+    {
+      "path": "modules/platform-identity/invite-authz.js",
+      "mode": "0000644",
+      "sha256": "2eb5577450d3bc1d67b7eab9a13256889aca945c6ac6a6a0ca919e195952b7a1"
+    },
     {
       "path": "modules/platform-identity/migrations/platform_identity_001_tables.sql",
       "mode": "0000644",
@@ -5977,7 +5987,7 @@
     {
       "path": "modules/platform-identity/routes/projects.js",
       "mode": "0000644",
-      "sha256": "f90fbe23065310a09769bc46fdb0703e460f402d5a4e0cc490eba70cf67965ea"
+      "sha256": "dac39b920025d696ba34e20aa4a9fbfb70d1cbc9ffe8f3b0da823f333d6a8d7a"
     },
     {
       "path": "modules/platform-identity/routes/public-profile.js",
@@ -6097,7 +6107,7 @@
     {
       "path": "modules/provisioning/module.json",
       "mode": "0000644",
-      "sha256": "26a6d752e610ac46f8306aa707f0229bf83ec9b0cb6c128ec723b7cc55b2b977"
+      "sha256": "c451d94736219198d10d1bb8837ff9aecd6d4f90f8bf46790deba38f0d2168ec"
     },
     {
       "path": "modules/provisioning/onboard-plan.js",
@@ -6112,7 +6122,7 @@
     {
       "path": "modules/provisioning/provisioning.js",
       "mode": "0000644",
-      "sha256": "d3d376a0aafc52dda55d9d2f2dcdc3d5baf9370a766cd4328cd00b314e897c99"
+      "sha256": "39635718015b8fcb0cf5d21f3769e292e129bfe312b5802d073ef63b0d8b7b1e"
     },
     {
       "path": "modules/provisioning/rate-limit.js",
@@ -6132,7 +6142,7 @@
     {
       "path": "modules/provisioning/routes/provisioning.js",
       "mode": "0000644",
-      "sha256": "3528d699cb9c0f396eeda2e9fc26eb9b89c02e0b0ca34beeb20fd84c832f5241"
+      "sha256": "00585a2de10a05c814fb0c1ad3cd6b564096b70b7729695b54953ab98c75601b"
     },
     {
       "path": "modules/provisioning/starter-bundles.js",
@@ -6147,7 +6157,7 @@
     {
       "path": "modules/provisioning/tests/provisioning.mjs",
       "mode": "0000644",
-      "sha256": "4dceb82f4dbeb39128c66d666df0642aacb38988f7c6d01c55f6515bcd8ad798"
+      "sha256": "aac930ed566f9b6fb7ec9fa4e240f42025e854369a94f6a8c63aa20b5d1995a8"
     },
     {
       "path": "modules/provisioning/ui/.gitkeep",
@@ -7392,12 +7402,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "76834cd1d1173b36db4f414f60b9457e8eeb1682ca54f25f662e29254ea22bd9"
+      "sha256": "8043c81f64ede9c38cdae0f527ba8fc6d3ce04f9c3ca99846dbb1b88e5b67aa6"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "c1ecc7233b18bd5b058b6af3757d7e2ae3a64fcef67ef6de2d743a72013c8602"
+      "sha256": "9845a25af2217c1713641a4ae22c09c5686af460ee7e55ec269a733dbc573ca7"
     },
     {
       "path": "public-docs/index.html",
@@ -9082,7 +9092,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "aff15cb73c3ed3851d94ded69d4a75f9cf1e38dbe28146e51d6cd25c320f630e"
+      "sha256": "2327888e4ad6a89296b1e8aab4237bd90d301debb313576c109850b450903eb0"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -11307,13 +11317,18 @@
     {
       "path": "tests/project_catalog_routes.mjs",
       "mode": "0000644",
-      "sha256": "5918d1ce7c106e5d7baa9cb989d52f3e82ac2aaf45a89f9a9bb154066106dccc"
+      "sha256": "afef4620252bc212b4326863abb021e8cd6033e258345e44cf78e97fc3b28b63"
     },
     {
       "path": "tests/project_door_ui.mjs",
       "mode": "0000644",
       "sha256": "29f59ab64b231a7ec5d17a3e784d451f75d80c19efd4cb6a523d263e8f88b581"
     },
+    {
+      "path": "tests/project_invite_ownership.mjs",
+      "mode": "0000644",
+      "sha256": "743436b1191353bf687d8fb553d423a6003707a25a548367644928478569f171"
+    },
     {
       "path": "tests/project_join_door.mjs",
       "mode": "0000644",
@@ -11407,7 +11422,7 @@
     {
       "path": "tests/provisioning_module_selection.mjs",
       "mode": "0000644",
-      "sha256": "a8cb68c1f21a7c6547ef382b4641b80c1c9e46a2aad415f75dbfde36224079fd"
+      "sha256": "92db65b8da5b849379bab03e70287239deab8b9a2b2e47b4574f12b8acac013e"
     },
     {
       "path": "tests/provisioning_onboard_mode.mjs",

package/docs/adr/0248-a-hub-project-s-owner-is-the-provisioning-row-carried-on-a-port.md

@@ -0,0 +1,144 @@
+# ADR 0248 — A hub project's owner is the provisioning row, carried on a port and bound to both halves of the catalog projection
+
+- **Status:** accepted
+- **Date:** 2026-09-04
+- **Task:** [task 1003580](https://cloudbongos.com/builders#/task/1003580) (BONGOS-V1, goal 1000046 — *Project creation*, criterion `proj-invite-builders` / C6), GAP 2
+- **Deciders:** Claude, under the Archon's standing scope
+- **Implements:** [ADR 0246](<redacted>.md)'s named remainder — *"what remains there is purely the ownership branch… the ownership proof it should carry is `provisioning_instances.owner_builder_id`"*
+- **Related:** [ADR 0210](<redacted>.md) (owner-or-rank as one middleware; the atom stays spelled in the route's own list) · [ADR 0238](<redacted>.md) (the hub's `owner_github_id` columns are attribution, never authority) · [ADR 0083](<redacted>.md) (the one-way module rule — why this travels on a port) · [ADR 0182](<redacted>.md) D2a (a stealth project is anonymous, so a refusal may not identify it) · [ADR 0016](<redacted>.md) (fail-closed authority)
+
+---
+
+## Context
+
+`POST /projects/invite` is gated `requirePermission('project.curate')`, floor `metic`
+([ADR 0157](<redacted>.md)). It is a **curation** gate:
+`requirePermission` is purely grant/rank-based and has no own-scope branch. The creation
+wizard's audience is any signed-in GitHub user — on the hub, typically a `xenos` holding
+nothing at all. So the person who created a project got **403 on inviting anyone into their
+own project**, and BV1.R27 ([task 1002346](https://cloudbongos.com/builders#/task/1002346)),
+R28, R29 and the C6 proof all sat behind it.
+
+ADR 0246 closed the other half (the project is now a resolvable catalog row) and named this
+one as its own decision, with the constraint it has to answer to: **ADR 0238 says the hub's
+ownership columns are attribution, not authority.** Lowering `project.curate`'s floor is not
+available either — the same reason ADR 0210 gives: a floor is a rank, ownership is a
+relationship, and no floor low enough to reach a project's registrant excludes anybody.
+
+## Decision
+
+**Admit a `project.curate` holder OR the project's own owner, where "owner" means
+`provisioning_instances.owner_builder_id` — asked of provisioning through a kernel port, and
+bound to BOTH halves of the ADR 0246 projection.** Three parts:
+
+1. **The proof is the provisioning row.** That column is the authority `instanceAccessDenied`
+   already enforces on every owner-facing provisioning route (the manage page, both settings
+   routes, the detail answers). The hub's `sso_clients.owner_github_id` and
+   `platform_identity_projects.owner_github_id` stay what their migration comment and ADR 0238
+   say they are: attribution. Nothing here promotes them.
+
+2. **It travels on a NEW port, in the direction ADR 0246 did not open.** `project.catalog`
+   carries a write hub-ward (provisioning → platform-identity); this question runs the other
+   way, so provisioning provides **`provisioning.projectOwnedBy` ({ slug, host, builderId }) →
+   boolean**, registered beside `provisioning.instanceState`. platform-identity resolves it
+   with `resolveOptional` and does **not** declare it in `consumes` (the
+   `provisioning.projectPlanets` precedent): provisioning is `default: false`, and a hub
+   without it simply has no control-plane project to own. **A boolean, not the owner's id** —
+   the comparison is authority and belongs on the plane holding the row, so no consumer ever
+   handles an ownership fact it could mis-compare.
+
+3. **The question names both halves of the projection.** ADR 0246 puts a project on the map as
+   `client_id = slug` at `origin = https://<domain>`, and the port answers only when the
+   caller owns the instance carrying **both**, in one statement. Matching the slug alone would
+   let whoever registers an instance *named after* a client the control plane never created —
+   a hand-seeded row, whose origin the catalog's own claim rule (ADR 0246 rule 1) already
+   refuses to overwrite — speak for that project. The invite arm answers to the same binding
+   the catalog write does.
+
+### The OR is one middleware, and the atom stays spelled in the route
+
+`modules/platform-identity/invite-authz.js` is `scouting-authz.js`'s shape, and it is that
+shape for ADR 0210's reasons, restated because they are load-bearing rather than stylistic:
+
+- **`requirePermission('project.curate')` is built in the route's own middleware list** and
+  handed to the helper. A gate hidden inside a helper is invisible to `route-rank-check.js`
+  and `gen-api-docs.js`, which classify a route from its middleware — this route would have
+  been recorded `any-builder`, wrong in the dangerous direction, and the published API
+  reference would have said so. It still classifies `metic+archon` with
+  `x-permissions: ["project.curate"]`; the "or owner" lives in the description, which is the
+  same over-strict-but-safe answer ADR 0210 accepted.
+- **Ownership is asked FIRST, and a refusal falls through to the UNMODIFIED gate.** Asking the
+  permission gate first is not available: a middleware that has denied has already *sent* its
+  response, so there is nothing to fall through from. Paying one extra lookup on the curator
+  path is what makes the 403 byte-identical — same code, same `required`/`held`, same floors
+  map. **The widening can only ever ADMIT; it cannot change, soften, or swallow a refusal.**
+
+### The refusal is not an existence oracle — in body OR in latency
+
+This is why the gate runs **before** the target is resolved rather than after. Resolving first
+and then authorizing would split the answer into 404-for-absent and 403-for-present, handing
+any signed-in stranger a membership oracle over every private project on the platform —
+exactly what ADR 0182 D2a's server-side anonymisation exists to prevent. Because the gate
+delegates to the untouched permission middleware, a stranger's refusal is identical for a real
+project, a stealth project, a project that does not exist, and a malformed body; the gate runs
+before the body validator, exactly as `requirePermission` always did.
+
+**A body-identical refusal that is measurably faster is still an oracle**, so every path does
+the same two reads. An unknown `client_id` is asked about anyway, with the empty host, and
+`projectOwnedBy` **queries** it rather than short-circuiting: an empty host names no address
+and matches nothing (`domain` is a hostname or NULL, and `lower(NULL) = ''` is NULL), so it is
+a real round-trip with a guaranteed-empty result rather than a dummy delay. That is the one
+place in this design where the cheap-looking early return is the wrong call, and it is written
+into the function's own doc-comment so a later "optimisation" cannot quietly reopen the
+channel. Equalising the lookup must not DUPLICATE it, so the resolved row rides forward on
+`req.inviteTargetClient` (the `req.builder` / `req.rawPermissionKeys` precedent) and the
+handler reads it instead of fetching the same row again.
+
+## Consequences
+
+- **[task 1002346](https://cloudbongos.com/builders#/task/1002346) (BV1.R27) is unblocked**, and
+  is the pure wizard-step task it was scoped as. The route path, body and responses are
+  unchanged: `POST /api/bongos/projects/invite` with `{ client_id, github_login }` → `201
+  { invited: true, row }` on a fresh invite, `200 { invited: false, alreadyMember: true }` when
+  the membership already exists.
+- **Owning a project buys exactly one act on the hub** — pre-seeding a `pending` membership on
+  your own project. No rank, no curation, no read of anyone else's project, and nothing else
+  consults it. The reverse also holds: this reads ownership and grants none.
+- **Fail-closed in three directions.** No provisioning module → the old door, unchanged. A
+  throwing ownership check → the old door, unchanged (never a 500, never an admit). A
+  non-string `client_id` → not a claim, and neither the port nor the client registry is asked.
+- **Every caller now costs two indexed reads before the permission gate runs**, including one
+  who will be refused. That is the deliberate price of equal latency on a cold, authenticated
+  route; it is bounded (two primary-key/`LIMIT 1` lookups) and it is why the equalisation is
+  affordable here and would not be on a hot public path.
+- **A re-pointed co-tenant project can lose the own arm.** The catalog's claim rule 1 refuses
+  to rewrite a *credentialed* client's origin, so a federated project that moves address keeps
+  a stale `origin` while its provisioning row carries the new domain, and the binding stops
+  matching. That degrades to curator-only — the safe direction — and is named here so the next
+  reader recognises it rather than rediscovering it as a bug.
+- **The port is a general capability with one consumer.** Any future hub surface that wants to
+  own-scope a control-plane project asks the same question rather than inventing a second
+  answer — which is what keeps a hub ownership column from being promoted to authority the
+  next time this comes up.
+
+## Alternatives rejected
+
+- **Read `sso_clients.owner_github_id` (candidate B as originally scouted).** Rejected: it is
+  the exact thing its own migration comment and ADR 0238 forbid — a hub catalog column with no
+  instance behind it, writable by hub curation, and NULL on the hand-seeded rows.
+- **Lower `project.curate`'s floor to `xenos`.** Rejected on ADR 0210's grounds: it would admit
+  every stranger who ever signed in, to every project on the platform.
+- **Mint a `project.invite.own` ownership-scoped atom** and use `authorizeOwnedOrAny`.
+  Rejected: the ownership-scoped axis resolves the *rank* fact from a catalog floor and the
+  *owner* fact from a row the handler loaded, and here the owner fact lives on another module's
+  plane entirely — so the atom would still need this port, plus a catalog-floor change this
+  task is not authorised to make. The recruiting wave's `project.recruit`
+  ([spike 1002786](https://cloudbongos.com/builders#/task/1002786) R3) is where a new atom is
+  defined; when it lands it replaces the `project.curate` half of this OR and the ownership
+  half is unaffected — the same seam ADR 0210 left.
+- **Key the ownership question on the slug alone.** Rejected: see decision 3 — it makes a
+  hand-seeded catalog row's name a squattable claim on that project's membership directory.
+- **Reuse the `membership_kind = 'owner'` proof `scouting-authz.js` uses.** Rejected: that row
+  is written by a federated instance's `POST /sso/membership/check-in`, which a standalone
+  wizard-made project never calls — it would be empty for exactly the audience this task
+  exists to admit.

package/docs/adr/README.md

@@ -334,6 +334,7 @@ This keeps the decision history honest and traceable.
 | 0245 | [**The way back into an optional step is that step’s own answer route** ([task 1002342](https://cloudbongos.com/builders#/task/1002342) · goal 1000046, criterion `proj-module-select`). R20 ([ADR 0240](<redacted>.md)) made the create wizard’s module picker skippable and left a project’s module set write-once — the route file said so out loud (“there is no mutation route yet”). R23 closes it WITHOUT a new endpoint: `modules` joins `description` and `detail` on `PATCH /provisioning/instances/:id/detail`, because the wizard’s two optional steps are the same kind of thing — asked optionally at creation, stored on the platform row, reaching no running instance — and that route already carried the ownership gate, the `api:self`/`api:archon:<id>` actor rule, the 404-no-existence-leak shape, and (since [ADR 0243](<redacted>.md)) an `effectiveModules` answer it could report but not set. Deliberately NOT the settings channel: a setting is a policy the running instance obeys and would queue a restart to deliver a value the instance does not read. Only an ARRAY is a change — an omitted or null key leaves the column alone — so the three-valued contract’s `NULL` (“never asked”) stays unreachable by a later edit, and `modules` REPLACES where `detail` merges, because a merging write would make removal impossible. The surface is the manage view’s extras band (`/projects?view=manage&id=N`), where a toggle IS the save and the band repaints from the platform’s answer rather than from what was sent.](<redacted>.md) | provisioning / project creation |
 | 0244 | [**A catalog search is a view over the rows, never an edit to the selection** ([task 1002340](https://cloudbongos.com/builders#/task/1002340) · goal 1000046, criterion `proj-module-select`). The creation picker ([ADR 0240](<redacted>.md)) paints one toggle per optional module, and the catalog is meant to grow — so R21 adds a keyword search over it. A search over a list of links is trivial; a search over a list of TOGGLES is not, because the list is also an answer. Two failure modes follow from letting a row be hidden: the filter **edits** the answer (narrow the rendered array and the read-back array together, and typing `discord` then pressing Next files one module instead of three — silently, with every screen looking right), or the filter **lies** about it (a switched-on module off screen reads as switched off, which is [ADR 0237](<redacted>.md)’s "a preselect they have to audit" in its harsher form — one they cannot see at all). **Decision: the search is a VIEW and `state.modules` is the answer; the view may not write to it.** `moduleQuery` is a plain variable, never part of the draft, so `saveDraft` is not called from the input handler and a search can never turn an untouched picker into an answered one (ADR 0240’s `null` survives); `visibleModules()` derives the shown rows per render while `pickedModules()`, `modulesForCreate()` and `extrasRow()` keep reading the whole catalog; and the panel STATES what the filter is hiding — one line under the field counting what is **on**, not what is visible. Matching is `moduleMatches(mod, terms)`, a pure function: lower-cased **label + summary + key** as one haystack, every whitespace-separated term an AND’d substring. AND because adding a word means the list is still too long; substring because a filter that shows nothing until you finish typing reads as broken; the key because that is what a returning owner names a module by. No ranking (reordering toggles under a typing hand is worse than not), and deliberately **not semantic** — by-meaning search is deferred with the rest of the creation AI layer (idea 1000552). Rejected: filtering the read-back array (failure mode 1), CSS-hiding non-matches (leaves invisible `aria-pressed` toggles in the a11y tree), pinning switched-on rows above the query (a filter that lies the other way), persisting the query in the draft, and debouncing a pass over already-loaded rows.](<redacted>.md) |
 | 0247 | [**The join door is ONE composed answer, and dark matter has no live verdict to compose with yet** ([task 1002331](https://cloudbongos.com/builders#/task/1002331) · goal 1000046, criterion `proj-join-policy`). [ADR 0182](<redacted>.md) D6 wrote the rule — visibility is the ceiling, join policy may only narrow it — and nothing implemented it: the public `POST /access-requests` read `joinability` alone, so an owner could set their project private or stealth on the map and the application endpoint behaved exactly as before. R12 adds the third knob (`join_grant` = view | apply | full, one line of settings vocabulary, default `full` so nothing existing changes) and composes all three in one pure kernel file, `src/bongos/project-door.js`, published through the doorway so no module can re-open a door the others closed. Three things worth carrying: the door vocabulary is a list ordered widest→strictest, so “the stricter wins” is the data structure rather than a branch; the refusal never names WHICH knob closed the door, because a stealth project that could be identified by its 403 gives back exactly what R06’s server-side redaction protects; and `locked` (dark matter) is specified, tested and deliberately UNWIRED — the instance cannot derive publishability (no description in its pack, and a pushed verdict goes stale the moment the owner writes one), while the hub’s cached copy says every live project is dark matter today, so enforcing off it would refuse every join on the platform.](<redacted>.md) | onboarding / provisioning / project creation |
+| 0248 | [**A hub project’s owner is the provisioning row, carried on a port and bound to both halves of the catalog projection** ([task 1003580](https://cloudbongos.com/builders#/task/1003580) · goal 1000046, criterion `proj-invite-builders`). [ADR 0246](<redacted>.md) made a wizard-made project resolvable by `POST /projects/invite` and named the remainder: the route is gated `project.curate` (floor metic) with no own-scope arm, so the project’s own owner — a `xenos` on the hub — got 403 on their own project, blocking BV1.R27–R29 and the C6 proof. The arm admits a `project.curate` holder **OR** the owner, where owner means `provisioning_instances.owner_builder_id` — never the hub’s `owner_github_id` columns, which [ADR 0238](<redacted>.md) fixes as attribution. Three things worth carrying: the fact travels on a NEW port `provisioning.projectOwnedBy` answering a **boolean**, so the comparison stays on the plane that holds the row and no consumer handles an ownership id it could mis-compare; the port is asked about **both halves of the ADR 0246 projection** (slug AND origin), because a hand-seeded catalog row’s name is otherwise a squattable claim on that project’s membership directory; and ownership is asked BEFORE the target is resolved, so the refusal stays the untouched `requirePermission` 403 and cannot become an existence oracle over stealth projects ([ADR 0182](<redacted>.md) D2a). The atom stays spelled in the route’s own middleware list ([ADR 0210](<redacted>.md)’s rule), so the route still classifies `metic+archon`.](<redacted>.md) | onboarding / provisioning / project creation |
 
 | 0246 | [**Catalog membership is a projection of the provisioning row, not a side effect of federation** ([task 1003576](https://cloudbongos.com/builders#/task/1003576) · goal 1000046, criterion `proj-detail-interview` / C3). The BV1.R18 proof ([task 1002337](https://cloudbongos.com/builders#/task/1002337)) demonstrated C3 against live and found its last clause — “then it publishes” — structurally false: the owner’s verdict reads `provisioning_instances` while the public map reads `platform_identity_projects`, and the ONLY bridge was `federateInstance → registerClient → upsertProject`, which `shouldFederate` refuses for anything but `co-tenant` (the wizard hard-codes `standalone`) and which runs ONCE, at provision time, through a COALESCE. So a wizard-made project was never catalogued at all and a co-tenant one that answered later never updated — `publishable: true`, `{"projects": []}`, forever. The same missing row is [task 1003580](https://cloudbongos.com/builders#/task/1003580)’s GAP 1: `POST /projects/invite` resolves against `platform_identity_sso_clients`, whose only writer is that same `registerClient`. Underneath is one conflation — federation mints CREDENTIALS and was incidentally the only thing that minted MEMBERSHIP, while [ADR 0182](<redacted>.md) D4 already fixed the map’s gate at IDENTITY, which has nothing to do with hosting topology. **Decision: the catalog row is a PROJECTION of the provisioning row, re-derived at every write that can change its inputs** — two halves, neither sufficient alone. (1) THE ROW SHAPE: every control-plane project gets both rows whatever its hosting shape, and the client row carries NO credential (`secret_hash = ''`, `redirect_uris = '{}'`), so **the shape is the enforcement** rather than a flag a caller could forget — `redirectUriAllowed` refuses `/sso/authorize`, `clientSecretValid` refuses `/sso/token`, `/sso/membership/check-in` and `/sso/activity/rollup`, and the one leg that checked NEITHER (`/sso/device/start`, which resolves a client from a user-typed origin) grew an explicit `clientIsCredentialed` guard. (2) THE TIMING: re-taken on create, on `PATCH …/detail`, on `PATCH …/settings` when the door changes, and on `POST …/domain` (which re-keys the row, retiring the abandoned origin — [ADR 0181](0181-teardown-state-gate-and-address-retention.md) §2’s leak, in the catalog instead of DNS). **NO MIGRATION** — `secret_hash` is `NOT NULL` and `''` satisfies it while hashing to nothing. `description` and `visibility` are ASSIGNED, not COALESCEd (clearing a description must UN-publish); `featured`/`tagline`/`art_url`/`template` are curation and stay untouched, so [ADR 0182](<redacted>.md) D3 holds. It grants nothing — the row is attribution per [ADR 0238](<redacted>.md), ownership stays `provisioning_instances.owner_builder_id` — and because it writes rows keyed on owner-supplied values (a slug, a BYO domain) each write carries its **claim rule in the ON CONFLICT action’s own WHERE**: the client is refreshed only `WHERE secret_hash = ''` (a real client’s origin, which binds the CLI mint audience, can never be rewritten) and the project only `WHERE owner_github_id = EXCLUDED.owner_github_id` (`NULL = anything` is not true, so the hand-seeded rows cannot be claimed). Writing `visibility` does not contradict [ADR 0182](<redacted>.md) D5: the hub authorizes nothing — the authority already ran on the provisioning plane ([ADR 0238](<redacted>.md)’s own-scoped, audited PATCH), and a project the control plane does NOT own has no provisioning row, so D5’s instance report (R08) stays the only channel for those. `tearing_down`/`torn_down` project `hidden`; a `no_address` instance is not catalogued at all. Travels on the kernel port `project.catalog`, the `project.publishGate` seam in the other direction ([ADR 0083](<redacted>.md) forbids the import). Rejected: extending `shouldFederate` to every shape (hands a real secret to instances whose web.env the platform does not write, and keeps the once-at-standup bug); bridging only at the publish moment (leaves the invite with nothing to resolve); registering only at standup (the bug itself); a `catalog_only` boolean column (needs a migration and is weaker than the shape); letting the bridge write `featured`; and backfilling the three existing catalog rows from code.](<redacted>.md) | provisioning / project creation |
 

package/docs/api/openapi.json

@@ -11162,7 +11162,7 @@
           "projects"
         ],
         "summary": "POST /projects/invite",
-        "description": "invite a builder into a project (ADR 0141 §5, task #1002115). Pre-seeds a 'pending' membership the invitee accepts from My Projects. V1 invites by github_login and requires the invitee to already have a platform account (they build on some project); inviting someone entirely new to the platform (GitHub-id resolution) is a follow-up.\n\n**Rank:** `metic+archon` — Metic or Archon rank (review/triage powers).\n\n**Permissions:** `project.curate` (all required).",
+        "description": "own-or-metic in effect: invite a builder into a project (ADR 0141 §5, task #1002115), called by a `project.curate` holder OR the project's OWN OWNER (task 1003580; the ownership proof is `provisioning_instances.owner_builder_id`, reached through a port — see invite-authz.js). The wizard's audience is any signed-in GitHub user, typically a xenos who used to get 403 on their own project. A caller who is neither gets the unchanged permission refusal, identical whether or not the project exists. Pre-seeds a 'pending' membership the invitee accepts from My Projects. V1 invites by github_login and requires the invitee to already have a platform account (they build on some project); inviting someone entirely new to the platform (GitHub-id resolution) is a follow-up.\n\n**Rank:** `metic+archon` — Metic or Archon rank (review/triage powers).\n\n**Permissions:** `project.curate` (all required).",
         "x-rank": "metic+archon",
         "x-source": "modules/platform-identity/routes/projects.js",
         "x-permissions": [
@@ -11555,7 +11555,7 @@
           "provisioning"
         ],
         "summary": "PATCH /provisioning/instances/:id/detail",
-        "description": "── The optional project detail (task 1002334, goal 1000046) ────────────── PATCH /provisioning/instances/:id/detail — answer (or re-answer) the wizard's OPTIONAL creation steps after creation. Body: any subset of { description, detail, modules }. rank: any authenticated builder (own resource; archon may change any — same gate as settings). THIS ROUTE IS WHAT MAKES THE STEP SKIPPABLE. Skipping at creation leaves the project dark-matter — off the map and un-joinable (ADR 0182 D4) — and that is a supported default only because there is a way back. Without this route \"optional\" would mean \"permanently unpublishable\", i.e. a dead end, which is precisely what criterion `proj-detail-interview` refuses. Deliberately NOT a settings-apply: nothing here is a policy the running instance obeys, so there is no web.env to patch and no restart to queue. The answers live on the platform row until a catalog row materializes (the provisioning_007 `type` precedent), and R16 (task 1002335) is the surface that reads `description` to compute publishability and name what is still missing. `modules` rides the SAME route for the same reason (BV1.R23, task 1002342, ADR 0245): step 4 of the wizard is skippable exactly as step 3 is, so it needs the same way back, and it lands on the same platform row under the same ownership gate. Only an ARRAY is a change — an omitted or null key leaves the column alone, so the \"never asked\" NULL (ADR 0240 §2) can never be written by a later edit. The always-on core stays unremovable by construction: badModuleSelection refuses its keys and `effectiveModules` re-adds it on read.\n\n**Rank:** `any-builder` — Any authenticated builder (row-level ownership enforced in-handler).",
+        "description": "── The optional project detail (task 1002334, goal 1000046) ────────────── PATCH /provisioning/instances/:id/detail — answer (or re-answer) the wizard's OPTIONAL creation steps after creation. Body: any subset of { description, detail, modules }. rank: any authenticated builder (own resource; archon may change any — same gate as settings). THIS ROUTE IS WHAT MAKES THE STEP SKIPPABLE. Skipping at creation leaves the project dark-matter — off the map and un-joinable (ADR 0182 D4) — and that is a supported default only because there is a way back. Without this route \"optional\" would mean \"permanently unpublishable\", i.e. a dead end, which is precisely what criterion `proj-detail-interview` refuses. Deliberately NOT a settings-apply: nothing here is a policy the running instance obeys, so there is no web.env to patch and no restart to queue. The answers live on the platform row until a catalog row materializes (the provisioning_007 `type` precedent), and R16 (task 1002335) is the surface that reads `description` to compute publishability and name what is still missing. `modules` rides the SAME route for the same reason (BV1.R23, task 1002342, ADR 0245): step 4 of the wizard is skippable exactly as step 3 is, so it needs the same way back, and it lands on the same platform row under the same ownership gate. Only an ARRAY is a change — an omitted or null key leaves the column alone, so the \"never asked\" NULL (ADR 0240 §2) can never be written by a later edit. The always-on core stays unremovable by construction: badModuleSelection refuses its keys and `effectiveModules` re-adds it on read. AN ANSWER CAN BE TAKEN BACK (task 1003577). `detail` merges, so before this the first `team_shape` an owner sent was permanent — and \"never answered\" is a state `effectiveModules` reads (ADR 0240), not merely the absence of one. Sending `detail: { <key>: null }` UN-ANSWERS that question: the key is dropped from the jsonb, so the row reads back exactly as one that was never asked and the bundle the answer moved moves back. Only null does it — an empty string or any other value is still refused as off-vocabulary, and `detail: {}` still changes nothing, because a form that collected no answers is not asking for any to be erased.\n\n**Rank:** `any-builder` — Any authenticated builder (row-level ownership enforced in-handler).",
         "x-rank": "any-builder",
         "x-source": "modules/provisioning/routes/provisioning.js",
         "parameters": [

package/docs/api-reference.md

@@ -457,7 +457,7 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/<redacted>
 | POST | `/api/bongos/projects` | `metic+archon` | `origin`, `name`, `tagline`, `description`, `art_url`, `type`, `template` | create / update a catalog entry (manual seed for hand-wired instances; federated projects auto-catalogue at registration). |
 | PATCH | `/api/bongos/projects/:id/featured` | `metic+archon` | `featured` | the feature / unfeature control (the ADR 0141 §5 curation gate), BOUNDED BY THE PUBLISH GATE (ADR 0182 D3, task 1002335). |
 | GET | `/api/bongos/projects/featured` | `public` | — | the public map of projects; no auth by design. |
-| POST | `/api/bongos/projects/invite` | `metic+archon` | `client_id`, `github_login` | invite a builder into a project (ADR 0141 §5, task #1002115). |
+| POST | `/api/bongos/projects/invite` | `metic+archon` | `client_id`, `github_login` | own-or-metic in effect: invite a builder into a project (ADR 0141 §5, task #1002115), called by a `project.curate` holder OR the project'… |
 
 ## `provisioning` (21)
 

package/docs/module-api-changelog.md

@@ -1521,5 +1521,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.534 with no explicit bump. run 33886686350. (task 1002620)
   1.19.536 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.535 with no explicit bump. run 33888048777. (task 1002620)
+  1.19.537 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.536 with no explicit bump. run 33888812605. (task 1002620)
+  1.19.538 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.537 with no explicit bump. run 33890191596. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/modules/platform-identity/invite-authz.js

@@ -0,0 +1,117 @@
+// modules/platform-identity/invite-authz.js — WHO may invite a builder into a project
+// (POST /projects/invite). Task 1003580 GAP 2, goal 1000046 criterion C6, unblocking the
+// wizard's invite step (BV1.R27, task 1002346).
+//
+// TWO DOORS, DELIBERATELY DIFFERENT KINDS — the scouting-authz.js shape (ADR 0210), which is
+// this codebase's design of record for owner-or-rank:
+//
+//   RANK      — `project.curate`, floor metic (ADR 0157). The hub CURATOR's door, unchanged:
+//               the atom, the 403 body, the floors map. Nothing about it moves here.
+//   OWNERSHIP — the project's own owner, for their own project. The whole of what this adds.
+//
+// WHY THE RANK DOOR ALONE WAS A DEAD END. The creation wizard's audience is any signed-in
+// GitHub user — typically a `xenos` on the hub — and `requirePermission` is purely
+// grant/rank-based with no own-scope branch. So the person who created a project got 403 on
+// inviting anyone to it, and no floor low enough to admit them excludes anybody at all.
+//
+// WHERE THE OWNERSHIP PROOF COMES FROM, AND WHERE IT MUST NOT. `platform_identity_sso_clients
+// .owner_github_id` and `platform_identity_projects.owner_github_id` are ATTRIBUTION, not
+// authority — their own migration says so and ADR 0238 restates it. The authority is
+// `provisioning_instances.owner_builder_id`, the fact the manage view already trusts and
+// `instanceAccessDenied` already enforces. This module may not import provisioning (ADR 0083's
+// one-way rule), so the fact travels on the kernel port `provisioning.projectOwnedBy` —
+// resolveOptional and NOT declared in `consumes` (the `provisioning.projectPlanets`
+// precedent): provisioning is default-off, and a hub running without it simply has no
+// control-plane project to own.
+//
+// THE REFUSAL IS NOT AN ORACLE, IN BODY OR IN LATENCY. Ownership is asked before the target is
+// resolved and before the body validator, and every path does the same two reads, so a
+// stranger's 403 is identical — and identically slow — for a real project, a stealth one
+// (ADR 0182 D2a), one that does not exist, and a malformed body.
+//
+// THE PORT IS ASKED ABOUT BOTH HALVES OF THE PROJECTION. ADR 0246 puts a control-plane project
+// on the map as `client_id = slug` at `origin = https://<domain>`, so the question is "do you
+// own the instance carrying BOTH", never "do you own the slug". A hand-seeded catalog row's
+// name is squattable in `provisioning_instances` — the catalog's own claim rule already
+// refuses to overwrite such a row, and this arm answers to the same binding rather than
+// handing its owner's name to whoever registers an instance called that.
+//
+// IT GRANTS NOTHING ELSE (ADR 0016). Owning a project buys exactly one act on the hub:
+// pre-seeding a `pending` membership on your own project. It confers no rank, no curation, no
+// read of anyone else's project, and nothing else consults it.
+// Proof: ../../tests/project_invite_ownership.mjs
+'use strict';
+
+const api = require('../../src/module-api');
+const pi = require('./platform-identity');
+
+// The kernel port the ownership fact travels on. Resolved BY NAME at call time through the
+// doorway, never imported — provisioning is a sibling module (ADR 0083).
+const OWNERSHIP_PORT = 'provisioning.projectOwnedBy';
+
+// The host a catalog origin names, which is the `provisioning_instances.domain` the projection
+// was keyed on. An unparseable origin has no host and therefore no owner. PURE.
+function hostOfOrigin(origin) {
+  try { return new URL(String(origin)).hostname.toLowerCase(); } catch { return ''; }
+}
+
+// callerOwnsProject(req, { pool }) — is this caller the owner of the control-plane project the
+// requested catalog row was projected from? Fail-closed on every unhappy path: a non-string
+// key (only a string names a project — `String(['x'])` must not become a claim), an
+// unauthenticated caller, no provisioning module.
+//
+// SAME WORK ON EVERY PATH, which is the timing half of "the refusal is not an oracle". An
+// unknown client is asked about anyway — `hostOfOrigin(null)` is the empty host, which
+// `projectOwnedBy` still queries and which matches nothing — so a stranger cannot separate
+// "this project exists" from "it does not" by measuring how long the identical 403 took to
+// arrive. A body-identical refusal that is measurably faster is still an oracle.
+//
+// The resolved row rides forward on `req.inviteTargetClient` (the `req.builder` /
+// `req.rawPermissionKeys` precedent) so equalising the lookup does not duplicate it: the
+// handler needs this same row, and re-reading it would be pure waste on every admitted call.
+async function callerOwnsProject(req, { pool }) {
+  const clientId = req.body && req.body.client_id;
+  if (typeof clientId !== 'string' || clientId === '') return false;
+  const builderId = req.builder && req.builder.id;
+  if (!builderId) return false;
+  const ownedBy = api.resolveOptional(OWNERSHIP_PORT);
+  if (typeof ownedBy !== 'function') return false;
+  const client = await pi.getClient(clientId, { pool });
+  if (client) req.inviteTargetClient = client;
+  return (await ownedBy({ slug: clientId, host: hostOfOrigin(client && client.origin), builderId })) === true;
+}
+
+// requireProjectInviter({ curateGate, pool, log }) — the OR gate as one middleware, mounted
+// after requireBuilder. `curateGate` is the ALREADY-BUILT `requirePermission('project.curate')`
+// middleware: the atom stays spelled in the route's own middleware list, where
+// route-rank-check.js and gen-api-docs.js can see it, so widening the door cannot make the
+// route's recorded rank read looser than it is.
+//
+// ORDER IS THE DESIGN, and it is what keeps the refusal from becoming an existence oracle.
+// Ownership is asked FIRST; when it answers yes the request proceeds and the permission gate
+// never runs. When it answers no — for ANY reason, including "no such project" — the request
+// falls through to the UNMODIFIED permission gate, so a caller who is neither owner nor
+// curator gets exactly the 403 this route has always produced: same code, same required/held,
+// same floors map. A stranger therefore cannot tell a stealth project (ADR 0182 D2a) from one
+// that does not exist, and cannot tell either from a malformed body — the gate still runs
+// before the body validator, exactly as `requirePermission` always did. The widening can only
+// ever ADMIT; it cannot change, soften, or swallow a refusal.
+//
+// FAIL-CLOSED ON THE OWNERSHIP QUESTION ITSELF. A database blip while asking "is this your
+// project" must not admit, and must not 500 either: it falls to the permission gate, which
+// denies unless the caller holds the atom. The failure mode of the new door is the old door.
+function requireProjectInviter({ curateGate, pool, log }) {
+  return async function projectInviterGate(req, res, next) {
+    try {
+      if (await callerOwnsProject(req, { pool })) return next();
+    } catch (err) {
+      // Message only — a query error can carry row data (the requirePermission precedent).
+      log.error({ err: err && err.message }, 'project invite owner check failed — falling back to the permission gate');
+    }
+    return curateGate(req, res, next);
+  };
+}
+
+module.exports = {
+  requireProjectInviter,
+};

package/modules/platform-identity/routes/projects.js

@@ -12,6 +12,8 @@
 //   GET   /projects            — Archon: full curation list (+ featured flags, the stored
 //                                join door, and the DERIVED publish verdict — ADR 0182)
 //   POST  /projects            — Archon: create / update a catalog entry
+//   POST  /projects/invite     — a `project.curate` holder OR the project's OWN owner:
+//                                pre-seed a 'pending' membership (invite-authz.js)
 //   PATCH /projects/:id/featured — Archon: the feature / unfeature control
 //
 // Reaches core only through the doorway (ADR 0083). Archon routes declared first so
@@ -23,6 +25,7 @@ const api = require('../../../src/module-api');
 const pi = require('../platform-identity');
 const projectCatalog = require('../project-catalog');
 const projectStats = require('../project-stats');
+const inviteAuthz = require('../invite-authz');
 
 const { pool, requireBuilder, requirePermission, validateOrRespond, parseId, corsPublicGet } = api;
 const log = api.logger('platform-identity');
@@ -105,28 +108,52 @@ module.exports = function projectsRoutes() {
     }
   });
 
-  // rank: archon — invite a builder into a project (ADR 0141 §5, task #1002115).
-  // Pre-seeds a 'pending' membership the invitee accepts from My Projects. V1 invites
-  // by github_login and requires the invitee to already have a platform account (they
-  // build on some project); inviting someone entirely new to the platform (GitHub-id
-  // resolution) is a follow-up.
-  router.post('/projects/invite', requireBuilder, requirePermission('project.curate'), async (req, res) => {
-    if (validateOrRespond(req, res, {
-      client_id: { required: true, type: 'string', maxLength: 200 },
-      github_login: { required: true, type: 'string', maxLength: 200 },
-    })) return;
-    try {
-      const client = await pi.getClient(req.body.client_id, { pool });
-      if (!client || client.status !== 'active') return res.fail('unknown_project', 404);
-      const account = await pi.getAccountByLogin(req.body.github_login, { pool });
-      if (!account) return res.fail('account_not_found', { status: 404, message: 'That builder has no platform account yet — they must sign in somewhere once before they can be invited.' });
-      const out = await pi.inviteToProject({ clientId: req.body.client_id, githubId: account.github_id }, { pool });
-      res.status(out.invited ? 201 : 200).json(out);
-    } catch (err) {
-      console.error('[platform-identity] POST /projects/invite', err);
-      res.fail('invite_failed', { status: 500, message: 'internal error' });
-    }
-  });
+  // The atom is spelled in the middleware list below, not hidden inside
+  // requireProjectInviter, so route-rank-check.js and gen-api-docs.js classify this
+  // route from its real gate. A helper-hidden gate would record a privileged route
+  // as any-builder — wrong in the dangerous direction (the ADR 0210 rule).
+
+  // rank: metic+archon — own-or-metic in effect: invite a builder into a project
+  // (ADR 0141 §5, task #1002115), called by a `project.curate` holder OR the project's OWN
+  // OWNER (task 1003580; the ownership proof is `provisioning_instances.owner_builder_id`,
+  // reached through a port — see invite-authz.js). The wizard's audience is any signed-in
+  // GitHub user, typically a xenos who used to get 403 on their own project. A caller who is
+  // neither gets the unchanged permission refusal, identical whether or not the project
+  // exists. Pre-seeds a 'pending' membership the invitee accepts from My Projects. V1 invites
+  // by github_login and requires the invitee to already have a platform account (they build
+  // on some project); inviting someone entirely new to the platform (GitHub-id resolution) is
+  // a follow-up.
+  router.post(
+    '/projects/invite',
+    requireBuilder,
+    // Ownership is asked FIRST — one client read plus one indexed LIMIT-1 lookup, the SAME two
+    // on every path so the refusal is identical in latency as well as in body. Asking the
+    // permission gate first is not available: a middleware that has denied has already SENT
+    // its response, so there is nothing to fall through from. Paying the round-trip is what
+    // keeps the 403 byte-identical to the one this route has always produced (ADR 0210 D2).
+    // The gate leaves the resolved client on `req.inviteTargetClient` for the handler below.
+    inviteAuthz.requireProjectInviter({ curateGate: api.requirePermission('project.curate'), pool, log }),
+    async (req, res) => {
+      if (validateOrRespond(req, res, {
+        client_id: { required: true, type: 'string', maxLength: 200 },
+        github_login: { required: true, type: 'string', maxLength: 200 },
+      })) return;
+      try {
+        // The gate already resolved this exact row (it must, to answer the ownership
+        // question); reusing it keeps the equalised lookup from becoming a duplicated one.
+        // It is only ever absent when the gate found nothing, so the fallback still reads.
+        const client = req.inviteTargetClient || await pi.getClient(req.body.client_id, { pool });
+        if (!client || client.status !== 'active') return res.fail('unknown_project', 404);
+        const account = await pi.getAccountByLogin(req.body.github_login, { pool });
+        if (!account) return res.fail('account_not_found', { status: 404, message: 'That builder has no platform account yet — they must sign in somewhere once before they can be invited.' });
+        const out = await pi.inviteToProject({ clientId: req.body.client_id, githubId: account.github_id }, { pool });
+        res.status(out.invited ? 201 : 200).json(out);
+      } catch (err) {
+        console.error('[platform-identity] POST /projects/invite', err);
+        res.fail('invite_failed', { status: 500, message: 'internal error' });
+      }
+    },
+  );
 
   // rank: archon — the feature / unfeature control (the ADR 0141 §5 curation gate),
   // BOUNDED BY THE PUBLISH GATE (ADR 0182 D3, task 1002335). Featuring ranks among

package/modules/provisioning/module.json

@@ -14,6 +14,6 @@
     "migrations": true,
     "pollers": ["liveness-sweep"]
   },
-  "provides": ["provisioning.instanceState", "provisioning.projectPlanets"],
+  "provides": ["provisioning.instanceState", "provisioning.projectPlanets", "provisioning.projectOwnedBy"],
   "consumes": []
 }