@bongos/core 1.19.612 → 1.19.614

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.612",
-  "core_contract": "1.19.612",
-  "source_commit": "40c2360599907381009ddf7b676722ed4df90d10",
+  "core_version": "1.19.614",
+  "core_contract": "1.19.614",
+  "source_commit": "abed8329cedd284ae48ca75f74b991eed0bb00aa",
   "source_ref": "HEAD",
-  "built_at": "2026-09-09T04:22:55.358Z",
+  "built_at": "2026-09-09T05:18:42.201Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 458,
+    "docs_redacted": 459,
     "agent_docs_stubbed": 24,
     "functional_verbatim": 2080,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2562,
-  "tree_sha256": "5fd467fedfc4ddaeb527aba61440ecd7f5590a0ac941438cc7e28fc2240b7b3b",
+  "file_count": 2563,
+  "tree_sha256": "6eaf4625f3f277d948abd11748dcf8e2f7f24062b460a58dd7ea3c7033156dea",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -1052,7 +1052,7 @@
     {
       "path": "docs/adr/0111-instance-hosting-provisioning-module.md",
       "mode": "0000644",
-      "sha256": "70841ba00274c070f64a7de0d042db406b4ebac51f8073b422a4f2cac0673cb0"
+      "sha256": "240c3633b9093644c55d7141eac69748eafa294bb393dab274cad508aeee248e"
     },
     {
       "path": "docs/adr/0112-private-goals-invitations-join-requests.md",
@@ -1844,10 +1844,15 @@
       "mode": "0000644",
       "sha256": "c9cd485b1ffce55fea15fd5b544a01e5753309e291c88bd223d33e6c11c4ebec"
     },
+    {
+      "path": "docs/adr/0266-the-board-room-is-its-own-surface-reachable-by-whoever-may-vote.md",
+      "mode": "0000644",
+      "sha256": "ac348289412efce1b3d67d74fccb5ff81347d196715ff53fd77e79e22228fad3"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "c4bbd4c0ff9163a435564b56c4aac1d2c08e2b129d32b7f24779a60674096b47"
+      "sha256": "6cdaf9ffd4b14ae27231158fc040d59f084b86a93e6ecc43fb16bdea54e32fb6"
     },
     {
       "path": "docs/api-reference.md",
@@ -2732,7 +2737,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "b4249f1559e94a715eff18a2b869b12ffab3a3bda0c99566824933a3450c8688"
+      "sha256": "df3d7a5da1b66f12598a82a180eb3b3373938ef7a95e17977229adf999b02195"
     },
     {
       "path": "docs/modules-contract.md",
@@ -7632,12 +7637,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "e5976c35d2d34d80cb6beacbeaf14658a71ee0b3be7ece60cb60a48c88a09c4a"
+      "sha256": "abc3e3e3456a393e7a2113807d07adcc257b8e8af6369e6c05fc0bdf32340d49"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "3281707852a3d8ddb7528ceb04c22b1abc9cc26d0656e502fd55fc3c7342f152"
+      "sha256": "7301d49faecbce2fb275d06852d671f82f97df62ff7c94a0451e719a2457e257"
     },
     {
       "path": "public-docs/index.html",
@@ -8412,7 +8417,7 @@
     {
       "path": "scripts/gds/provision-net.js",
       "mode": "0000644",
-      "sha256": "86c308f807a27f448a1f90f4257e74238c177b885468b95b89d379c7249366fa"
+      "sha256": "502b1aeb571d463aea02ef4db3e848d23fdd8c865e7bfc37f66679c09cc203a9"
     },
     {
       "path": "scripts/gds/provision-repo.js",
@@ -8422,12 +8427,12 @@
     {
       "path": "scripts/gds/provision-units.js",
       "mode": "0000644",
-      "sha256": "14ef8b2a3581c93b27983d0e566b5cc317d1a5d3b6367ff8eb7ffef7e0b3f54d"
+      "sha256": "2b2c2a74514de43e9015e38db56da1daff040488bf6b10ffa4bfa10042995dea"
     },
     {
       "path": "scripts/gds/provision.js",
       "mode": "0000644",
-      "sha256": "2fdb42802ae0bbefe79427d7e9a5d5967a89cb2ce757b2df5f49e9da25e60703"
+      "sha256": "82fb65fea5dd9a33770690c902680cb428eb74b1c2abdaeab7f89f444ae1c11f"
     },
     {
       "path": "scripts/gds/publish-credential-check.js",
@@ -9362,7 +9367,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "7b843863aec10abe437301fd0b0656d02e651f0ced17d616ccc8457b0dbfca9b"
+      "sha256": "05f2b36b4f1ebb20ba4a425d9669d0ac29326557c67d3deb61a63e3e5a06a261"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -11812,7 +11817,7 @@
     {
       "path": "tests/provision.mjs",
       "mode": "0000644",
-      "sha256": "9744b866060ae83fc560f65e579fc30e73957ff21329994ca3d581dbe1726053"
+      "sha256": "d70cc9bd673dce403787814849abbeef9ed0ea01f9e38a2d3288886879490830"
     },
     {
       "path": "tests/provision_restart.mjs",

package/docs/adr/0111-instance-hosting-provisioning-module.md

@@ -124,6 +124,7 @@ Inherit the budget DNA. **Default to the cheapest shape** — a co-tenant proces
 - **`bongos init` gains an infra arm** — its infra answers flow into a provisioning request instead of only filing manual kickoff tasks.
 - **Deferred / risks:** the **managed fleet control plane** is genuinely greenfield and sits above the locked per-repo GDS model — it needs its own spec once Mercury lands. **Billing/metering** is greenfield (no capability today). **Domain registration** is deferred. On-demand TLS must be hostname-allow-listed to what was actually provisioned. `bongos upgrade` is still a stub (R86).
 - **Licensing unchanged** — managed is a service on the same AGPL artifact ([ADR 0065](<redacted>.md) §2); no open-core, no relicensing.
+- **A provisioned instance loads its OWN branding pack** ([task 1003740](https://cloudbongos.com/builders#/task/1003740)). Provisioning originally pinned every instance's pack to the shared, committed neutral starter, because the co-tenant model of the day ran ONE checkout for all instances and differentiated them purely by env. Under [ADR 0108](<redacted>.md) that is no longer true — each instance has its own checkout, its own `config/branding.json` written at init, and runs `node_modules/@bongos/core`. The pin outlived its premise, and because `src/branding.js`'s env overrides carry domains, `auth.idp` and landing but **never `identity.productName`**, every hosted instance served the platform's name as its own: `GET /api/gds/instance` on hermeslines-marketing, mercury and demo all answered "Cloud Bongos" while their own packs on disk said otherwise. `bongos login <instance>` therefore greeted a newcomer with the wrong project at the moment they were deciding whether to trust it, and nothing looked — a healthy instance passes `/healthz` while lying about who it is. Provisioning now writes no branding-file pin at all, so `src/branding.js`'s default (`<instanceRoot>/config/branding.json`, falling back to neutral when absent) applies; standup gained an identity probe beside the healthz one, which **warns** rather than fails, since an owner may legitimately name a project after the platform.
 - **Follow-up tasks seeded** under BONGOS-V1 / goal 26 (idempotent seeder `scripts/gds/seed-provisioning-tasks.js`, `source_ref = <redacted>*`):
   1. **Scaffold the `provisioning` module** — manifest + `provisioning_*` tables + the web-tier intent/state routes (own + Archon), no token handling. *(buildable now)*
   2. **Extract the shared DO + Cloudflare control-plane clients** so `box.js` and `provision.js` reuse them without a module→module import (dev-box byte-identical). *(buildable now; enables 3)*

package/docs/adr/0266-the-board-room-is-its-own-surface-reachable-by-whoever-may-vote.md

@@ -0,0 +1,150 @@
+# 0266 — The Board Room is its own surface, reachable by whoever may vote
+
+- **Status:** Accepted
+- **Date:** 2026-09-08
+- **Tasks:** [#1003734](https://cloudbongos.com/builders#/task/1003734) (this record). Executed by [#1003735](https://cloudbongos.com/builders#/task/1003735) (the carve), [#1003736](https://cloudbongos.com/builders#/task/1003736) (the deep links), [#1003737](https://cloudbongos.com/builders#/task/1003737) (the waiting-vote count).
+- **Goal:** [#1000111](https://cloudbongos.com/builders#/goal/1000111) — Working area 7, Government; criterion `wa7-government`.
+- **Decided by:** the owner (Masterqua / `IAMMASTERQUA`, Archon, member of area 7), 2026-09-08.
+- **Builds on:** [ADR 0175](<redacted>.md) (the Board Room, and §6 — who governs is configuration), [ADR 0157](<redacted>.md) (the `page.view.government` floor at metic), [ADR 0151](<redacted>.md) (permissions as the atom), [ADR 0016](<redacted>.md) (server-enforced, uncached, per request).
+- **Related:** [ADR 0174](<redacted>.md) (government, not governance).
+
+## 1. Context — the room with no door
+
+The Board Room is the hall's only upward-pointing gate (ADR 0175): the surface
+on which a Full Idea that cleared the completeness bar is ratified, and the only
+surface on which the constitution itself can be amended. It ships today as a
+**hash tab** (`#board-room`) inside the `/government` page, beside Permissions
+and Constitution.
+
+Two facts about that placement do not survive inspection.
+
+**The nav never followed the page.** When R16 turned `/government` into three
+rooms it correctly widened the *page* gate from `government.manage` (archon) to
+`page.view.government` (metic+). The comment it left in
+[`serve-internal.js`](../../src/bongos/serve-internal.js) states the principle
+plainly — *"The shell follows the widest legitimate audience — the audience
+changed when the page did."* But `modules/hall-ui/public/shell.js` still
+declares that nav item as `label: 'Permissions'`, `gate: 'archon'`. So the page
+widened and the door did not: a Metic who sits on the board has **no nav link to
+the Board Room at all**, and the only word an Archon sees in the nav is
+"Permissions", which does not suggest a voting room is behind it. Every other
+government room — Watch, Harbor, Gate, Sessions — carries its own nav item. The
+Board Room is the one room reachable only by knowing a URL fragment.
+
+**The surface is narrower than the franchise.** `board.vote.cast` floors at
+**xenos**, and that is deliberate: `modules/government/board.js:149` records the
+floor is low *so that widening the board works*. The page shell requires
+metic+. Today `membership: rank:archon` and every Archon clears both, so the
+contradiction is latent. The moment a constitution widens membership below
+Metic — the exact act ADR 0175 §6 exists to make a configuration change — those
+members may cast a vote through the API and **cannot load the page they would
+cast it on**.
+
+The second is the load-bearing one. ADR 0175 §6 put membership, pass rule and
+window in `config/government.json`, resolved per request and uncached, so that
+"flipping the switch later changes numbers, not a code path that has never run."
+A page gate keyed to a different atom than the vote reintroduces exactly the
+code-path change that decision removed.
+
+## 2. Decision
+
+### 1. The Board Room becomes its own page at `/board-room`
+
+Carved out of `/government`, which keeps Permissions and Constitution. It joins
+Watch, Harbor, Gate and Sessions as a first-class room in the Government nav
+group, with its own nav item.
+
+The alternative — leaving the tab in place and adding a nav item that deep-links
+to `/government#board-room` — was considered and rejected. It is cheaper and it
+preserves the existing hash links for free, but it leaves the voting room inside
+a page whose gate answers a different question, which is defect (2) above left
+standing. The room that constrains the owner should not be a tab inside the
+owner's admin page.
+
+### 2. Its reach follows `board.vote.cast`, not `page.view.government`
+
+The page gate resolves the **same atom the vote route checks**. The surface
+reach and the right to vote become one thing, and widening the board stays a
+configuration change.
+
+`board.vote.cast`'s floor is only the coarse gate. **Membership is still checked
+in-handler, per item, against that item's own snapshotted constitution** — the
+floor decides who may receive the shell, never who may vote on what. A builder
+who clears the floor but sits on no board sees the room and no ballot, which is
+the correct and honest state: ADR 0175 §9 made the ballot open on purpose,
+because "a board whose votes are invisible cannot constrain anyone."
+
+### 3. The old deep links are migrated client-side, because a fragment never reaches the server
+
+`#board-room` is a URL fragment. It is **not sent to the server**, so no
+server-side route or redirect can ever see it. The compatibility path is
+therefore a client-side redirect in `government.js`: on load, a `#board-room`
+hash sends the browser to `/board-room`, preserving `?item=N`.
+
+This is recorded as a decision rather than left as an implementation note
+because it is the thing a reader will otherwise get wrong — adding
+`GOVERNMENT_BOARD_RE` to `serve-internal.js` looks like the obvious fix and
+silently never fires.
+
+Three writers emit the old form and all three move (task
+[#1003736](https://cloudbongos.com/builders#/task/1003736)): the Discord
+window-open announcement (`modules/discord/board-broadcast.js`), the
+`board_votes` need's action href (`modules/builder-settings/builder-needs.js`),
+and the docs. The redirect stays for at least one release regardless, because
+announcements already sitting in Discord channel history carry the old link
+forever and ADR 0175 §8 makes that mention the "vote within X" notice.
+
+### 4. A waiting-vote count belongs on the nav item, and the hall has no mechanism for one
+
+The owner's second ask was to see that items are waiting **without going
+inside**. The data already exists and needs nothing new server-side:
+`boardVotesNeed` (`builder-needs.js`) carries a live count and the oldest
+waiting item id, pre-filtered to what the vote route would actually accept, and
+`GET /me` already serves it.
+
+What does not exist is any badge, bell, dot or count mechanism in
+`shell.js` — the nav renders label and icon and nothing else. Task
+[#1003737](https://cloudbongos.com/builders#/task/1003737) adds that once,
+generically, so a second consumer can adopt it without a second pattern. Zero is
+silent, and the badge is visible to exactly whoever the nav item is: a count is
+board activity, and it must not leak to someone who cannot see the room.
+
+A **sound** is deliberately out of scope. The instance ships `alert.wav` and
+`chime.wav`, so it would be easy and it was not asked for.
+
+## 3. Consequences
+
+**The `/government` tab strip loses a room, and that is the point.** Two rooms
+remain, both administrative, both correctly behind the archon-shaped item they
+already sit behind. The existing Permissions nav item keeps `gate: 'archon'` —
+it *is* the archon admin surface, so that gate was never wrong for it. It was
+wrong as the only door to three rooms.
+
+**Widening the board becomes a real config change.** After this, an instance may
+set `membership: rank:metic` — or wider — and the members it names can actually
+reach the room. Before it, that edit produced members who could vote only by
+`curl`. This is the property ADR 0175 §6 claimed and did not have.
+
+**One more page joins the statically-parsed gate map.** `tests/hall_page_gate_map.mjs`
+rebuilds the URL→gate map by parsing `serve-internal.js` as text, so the new
+`const BOARD_ROOM_PAGE_RE = /…/;` must keep the bare form with nothing between
+the `=` and the literal — a comment in that gap drops the regex out of the map
+and the page silently tests as ungated. The file already records this rule at
+`PROJECT_SETTINGS_PAGE_RE`; this ADR notes it because the failure is invisible.
+
+**A defect found while scoping this, filed separately.** The hall renders needs
+as a *single slot* (`needs.items.find(n => n.state !== 'satisfied')`), and
+`computeNeeds` sorts only by state with a stable sort — so inside the
+`action_needed` bucket the registry array order decides, and `boardVotesNeed` is
+fourth, behind `artKeyNeed`. Any builder with an unresolved image-generation key
+therefore never sees the board notice at all. It was live for the owner of this
+decision at the moment they asked for the bell. Filed as
+[#1003738](https://cloudbongos.com/builders#/task/1003738) rather than folded in
+here: the badge and the banner are two surfaces, and fixing the ordering is a
+change to what every need in the hall does.
+
+**Rejected: a bell in the global header rather than on the item.** A header bell
+is a second inbox — it needs its own read/unread state, its own dismissal
+semantics, and a home for notifications that are not board votes. The ask was to
+see the count on the section, and the nav item is where the reader already looks
+for the room.

package/docs/adr/README.md

@@ -357,3 +357,4 @@ This keeps the decision history honest and traceable.
 | 0263 | [**How a version closes: auto, early, roll-forward, and the maintenance exemption** ([task 1003593](https://cloudbongos.com/builders#/task/1003593) · goal 1000086 — *Strict versioning*). [ADR 0250](<redacted>.md) D5 decided a version *can* close; this is the design pass that makes its five build tasks mechanical, so they do not each invent their own refusal codes and payload shapes and meet only in production. **The asymmetry that shrinks the feature:** auto-close fires when the last non-maintenance goal achieves — so by construction every non-maintenance goal is already closed and the set needing a disposition is EMPTY. All the machinery (the disposition map, the refusal that returns the goals, successor lineage) belongs to EARLY close alone; R16 is small and R12 carries the weight. **Auto-close hangs off BOTH achievement writers** (`db-goals.achieveGoalIfComplete` and the `done-when` cascade — the deliberate duplicate D2 already governs, a require cycle being the reason they are not one helper), on the caller `exec` so it sees the ship's uncommitted flip, and **may never fail a ship**: wrapped and swallowed like `closeCompletedWorkForShip`, idempotent under `WHERE status='building'`, so a failure leaves a version un-closed (self-healing on the next reconciler sweep) and never half-closed. **Early close** is the R10 archive two-step verbatim in spirit — refuse with `version_holds_open_goals` **returning the goals**, then proceed with a per-goal `roll_forward`/`abandon` map and a required `reason`; six named codes, because the callers are agents. **Two briefs are corrected by measurement:** the lineage column is `succeeded_by_goal_id` (migration 160, on the OLD row pointing forward) — not the `succeeds_goal_id` both 0250 and R17's brief name, so R17 needs NO migration; and R18's `is_maintenance` flag is load-bearing rather than cosmetic, because answering the close count with a `title NOT LIKE` would let a hand-titled goal silently exempt itself from the gate that decides when a VERSION closes. Promotion runs inside the close txn and BEFORE roll-forward (`ensureMaintenanceGoal` returns null for a non-`building` version, so a carry-over run first silently carries nothing); zero planning versions is not an error; R19's one migration should carry the `building` AND `planning` partial unique indexes so the promotion race resolves like a 23505 rather than a prayer. Rejected: auto-creating the successor version inside a close (the "fake hotfix version" escape hatch 0250 built the override counter to prevent), writing `limitations/<version>-shipped.md` from the route (file I/O in a ship transaction — it stays R23's CLI work), and a version reopen.](<redacted>.md) | version lifecycle / scope closure |
 | 0264 | [**The ten working areas: one goal per area, held until 5,000 builders** ([task 1003696](https://cloudbongos.com/builders#/task/1003696) · goal 1000086 — *Strict versioning*, criterion `sv-cutover-proven-live`). The owner and the full team ran a manual goal review on 2026-09-07 and cut **38 open goals down to 10**, one per working area, each with a named owner and a described 5,000-builder end state: project creation (Rini), account/community (Rini), human project management (Scott), core distribution (Lars/Will), module distribution & economy (Will), the four-role experience incl. agents (Masterqua/Rini), government (Will/Masterqua), the credit economy (Scott), platform analytics (Lars), security (everyone bar Nils and Scott). **Why the rules were not enough on their own:** [ADR 0250](<redacted>.md) D1 closes the goal set of a BUILDING version — which freezes 38 goals exactly as effectively as it would freeze 10. Enforcement cannot shrink a scope that is already too large, so the rules and the cut are two halves of one move; the horizon is a SCALE (5,000 builders), not a date, because that is the question that decides when this set stops being the right set. **The finding that reorders the goal:** none of the cut can be executed today. R10 ([task 1003597](https://cloudbongos.com/builders#/task/1003597)) made `POST /goals/:id/archive` refuse a goal holding unfinished tasks and demand a disposition — correct, and exactly D3 — but the vector that SUPPLIES a disposition is R14 ([task 1003601](https://cloudbongos.com/builders#/task/1003601)), unshipped. Every one of the 12 deletes and every fold goes through that door, so **R14 is the keystone of the whole cut**, not one feature among thirteen, and is built before the rest of the version-close chain rather than in rank order. It looks like a bug and is not: the refusal is the design, landed one task ahead of its own remedy. "Delete" means `archived`, never a row removal (`goals.status` is open|achieved|archived, migration 160; reversible via `/reopen`) — preserving the rows keeps shipped-task attribution and credit history a delete would strand. Three open goals were NOT covered by the review and are surfaced as open questions rather than guessed: 1000003 (the catch-all — already R25's target), 1000065 (assumed to be area 2's community half), and 1000088 (repo cleanup — maps to no area, needs an owner decision). Deliberately does not decide: the areas' priority order, criteria for the six goals R29 must create (inventing criteria for someone else's area is how a goal acquires scope its owner never agreed to), or any task rehoming (R25/R26).](<redacted>.md) | scope / goal set / owner decision |
 | 0265 | [**Work with no goal survives a version close, and the order the ten-area cut actually needs** ([task 1003713](https://cloudbongos.com/builders#/task/1003713) · goal 1000086 — *Strict versioning*, criteria `sv-every-task-has-a-goal` + `sv-cutover-proven-live`). `closeVersion`'s post-apply invariant counts GOALS, and every task write inside the close is scoped `WHERE goal_id = $1` — so a task belonging to no goal is reached by no disposition, counted by no re-count, and ships stranded on a version that is over. Not hypothetical: six such tasks already sat on shipped GDS-V3/GDS-V4, and 47 rows on BONGOS-V1 carried a null `goal_id` (R11 required the column going forward but never backfilled, because every catch-all lookup matches the exact title `<VERSION> — general` and BONGOS-V1's is titled 'Work with no goal yet'). Decision: a second invariant in the same transaction refuses a close leaving ANY non-terminal task on the version, failing `CLOSE_LEAVES_STRANDED_TASKS` with the ids; exempting only the maintenance goal (its carry-forward runs in the later `onClosed` hook) — through the SAME `maintenanceGoalExemptSql` the goal count uses, never a second copy — and `__smoke__` fixtures. Consequence recorded here too: because `PATCH /tasks/:id {goal_id}` refuses a cross-version move (409 `goal_version_mismatch`) and `roll_forward` CREATES a successor rather than merging into one, [ADR 0264](<redacted>.md)'s cut must run home-then-close-then-**fold on the planning version**, where task and destination finally share a version. Rejected: a `fold_into` disposition (puts scope decisions inside a shipping transaction), creating the six new areas on the building version via R07 admissions (spends ten overrides to route around the rule they price), and a backfill instead of a gate (fixes today's rows, not the forty-eighth).](<redacted>.md) | lifecycle / version boundary |
+| 0266 | [**The Board Room is its own surface, reachable by whoever may vote** ([task 1003734](https://cloudbongos.com/builders#/task/1003734) · goal 1000111 — *Working area 7, Government*, criterion `wa7-government`; owner decision 2026-09-08). The hall's only **upward-pointing** gate ([ADR 0175](<redacted>.md)) shipped as a hash tab inside `/government`, and two things about that did not survive inspection. **The nav never followed the page:** R16 correctly widened the PAGE gate from `government.manage` (archon) to `page.view.government` (metic+) when the page became three rooms — its own comment says *"the shell follows the widest legitimate audience"* — but `shell.js` still declares that item as label Permissions with gate archon, so a Metic who SITS on the board has no nav link at all and the only word in the nav is Permissions. Watch, Harbor, Gate and Sessions each own a nav item; the voting room was reachable only by knowing a URL fragment. **The surface was narrower than the franchise:** `board.vote.cast` floors at XENOS deliberately (`board.js:149` — the floor is low *so that widening the board works*) while the shell demands metic+, so the moment a constitution widens membership below Metic — the exact act [ADR 0175](<redacted>.md) §6 exists to make a CONFIG change — those members may vote by API and cannot load the page they would vote on, reintroducing the code-path change §6 removed. Decision: **its own page at `/board-room`, gated on the same atom the vote route checks.** The floor stays coarse — membership is still checked in-handler per item against that item's own snapshotted constitution — so a builder who clears the floor but sits on no board sees the room and no ballot, which is honest (§9 made the ballot open on purpose). **The migration is client-side because a fragment never reaches the server:** `#board-room` cannot be caught by any server route, so `government.js` redirects on load, preserving `?item=N` — recorded as a decision because adding a regex to `serve-internal.js` looks like the obvious fix and silently never fires. Three writers move (Discord `board-broadcast.js`, the `board_votes` need href, docs), and the redirect stays a release regardless because announcements already in channel history carry the old link forever. A **waiting-vote count** goes on the nav item: the data already exists (`boardVotesNeed` carries a live count pre-filtered to what the vote route would accept, served on `GET /me`), but `shell.js` has NO badge/bell/dot mechanism at all, so one is built once, generically, zero-is-silent, visible to exactly whoever the item is. Found while scoping and filed separately ([task 1003738](https://cloudbongos.com/builders#/task/1003738)): the hall renders needs as a SINGLE slot and `computeNeeds` sorts only by state with a stable sort, so registry order decides inside the `action_needed` bucket and `boardVotesNeed` sits fourth behind `artKeyNeed` — any builder with an unresolved image key never sees the board notice, which was live for this decision's own owner at the moment they asked for the bell. Rejected: a nav item merely deep-linking to the existing tab (cheaper, keeps the hash links free, but leaves the voting room inside a page whose gate answers a different question); a bell in the global header (a second inbox, needing its own read/unread and dismissal semantics); and a SOUND (`alert.wav`/`chime.wav` already ship, so it would be easy — it was not asked for).](<redacted>.md) | government / the board / hall nav |

package/docs/module-api-changelog.md

@@ -1673,5 +1673,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.610 with no explicit bump. run 34305857169. (task 1002620)
   1.19.612 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.611 with no explicit bump. run 34310708322. (task 1002620)
+  1.19.613 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.612 with no explicit bump. run 34311691842. (task 1002620)
+  1.19.614 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.613 with no explicit bump. run 34314327601. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.612",
+  "version": "1.19.614",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.612",
+      "version": "1.19.614",
       "license": "AGPL-3.0-or-later",
       "dependencies": {
         "express": "^4.21.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.612",
+  "version": "1.19.614",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",

package/scripts/gds/provision-net.js

@@ -244,6 +244,34 @@ function healthzCmd(inst) {
   return `curl -sS --max-time 5 http://127.0.0.1:${inst.port}/healthz`;
 }
 
+// The instance manifest, read over loopback — the identity companion to healthzCmd (task 1003740).
+function identityCmd(inst) {
+  return `curl -sS --max-time 5 http://127.0.0.1:${inst.port}/api/gds/instance`;
+}
+
+// Does a freshly provisioned instance report ITSELF, or the platform it is hosted on?
+//
+// WHY THIS EXISTS. Provisioning used to pin every instance's branding pack to the shared neutral
+// starter (see provision-units.js), a leftover from the co-tenant model that shared one checkout. Under
+// ADR 0108 each instance has its own, and src/branding.js's ENV_OVERRIDES carry domains but never
+// identity.productName — so every hosted instance served "Cloud Bongos" as its own name for
+// months, greeting newcomers with the wrong project at sign-in. Nothing looked.
+//
+// PURE so it is testable without a box: takes the parsed manifest and returns a verdict.
+// Deliberately a WARNING, not a failure — an owner may legitimately name a project after the
+// platform, and provisioning must not refuse a working instance over a name.
+function identityVerdict({ manifest, slug, neutralName }) {
+  const name = manifest && (manifest.name || (manifest.brand && manifest.brand.identity && manifest.brand.identity.productName));
+  if (!name) return { ok: null, reason: 'no name in manifest' };
+  // The bug's exact shape: the instance answers with the neutral pack's name while its slug says
+  // it is somebody else. A project genuinely called that keeps its name and only trips when the
+  // slug matches too — in which case it is not the bug.
+  if (neutralName && name === neutralName && slug && slug !== neutralName) {
+    return { ok: false, name, reason: `serves the platform default name "${name}" instead of its own` };
+  }
+  return { ok: true, name };
+}
+
 // ---------------------------------------------------------------------------
 // The injectable executor. dry-run → log-only; --apply → child_process.
 // ---------------------------------------------------------------------------
@@ -260,6 +288,8 @@ module.exports = {
   federateInstance,
   federationHubOrigin,
   healthzCmd,
+  identityCmd,
+  identityVerdict,
   shouldFederate,
   zoneForDomain,
 };

package/scripts/gds/provision-units.js

@@ -121,16 +121,30 @@ WantedBy=timers.target
 `;
 }
 
-// The branding pack a provisioned CO-TENANT instance loads: the shared, committed
-// neutral starter (the co-tenant model shares ONE checkout, differentiated only by
-// env — src/branding.js's GDS_BRANDING_FILE knob). Per-instance identity/domains
-// therefore ride ENV OVERRIDES, not a divergent pack. Kept as a constant so the
-// GDS_BRANDING_FILE line below and the env-var PREFIX (which must equal this pack's
-// envPrefix, or src/branding.js's ENV_OVERRIDES never fire) can't drift apart.
-const PROVISIONED_BRANDING_FILE = 'config/branding.neutral.json';
+// The pack the provisioner reads to learn an instance's env-var PREFIX floor.
+//
+// It is NOT the pack the instance loads, and that distinction is the whole of task 1003740.
+// The original co-tenant model shared ONE checkout across every instance, differentiated only by
+// env, so provisioning pinned the pack to `config/branding.neutral.json` and let identity
+// ride ENV OVERRIDES. That model is gone: under ADR 0108 each co-tenant has its own checkout
+// (`WorkingDirectory=/srv/<base>/<slug>`, running `node_modules/@bongos/core`) and its own
+// `config/branding.json` written at init.
+//
+// The pin outlived it, and src/branding.js's ENV_OVERRIDES cover domains, auth.idp and landing —
+// never `identity.productName`. So every hosted instance kept serving the NEUTRAL pack's name:
+// GET /api/gds/instance on hermeslines-marketing, mercury and demo all answered "Cloud Bongos"
+// while each instance's own pack on disk said otherwise, and `bongos login <instance>` greeted a
+// newcomer with the platform's name at the moment they were deciding whether to trust it.
+//
+// The instance now loads its own pack by src/branding.js's DEFAULT (INSTANCE_PATH =
+// <instanceRoot>/config/branding.json), which falls back to neutral when absent — so no
+// branding-file env line is written at all. Reading the neutral pack HERE is still correct: it is
+// the prefix floor an instance inherits unless its own pack overrides envPrefix, and every live
+// co-tenant pack pins `envPrefix: "CLOUDBONGOS"` explicitly.
+const ENV_PREFIX_PACK = 'config/branding.neutral.json';
 
 // The env-var prefix a provisioned instance actually RESOLVES — i.e. the envPrefix
-// of the pack it loads (PROVISIONED_BRANDING_FILE). src/instance-config.resolveEnv
+// of the pack it loads (ENV_PREFIX_PACK). src/instance-config.resolveEnv
 // reads <envPrefix>_<SUFFIX>, and src/branding.resolveBranding applies
 // <envPrefix>_{PUBLIC,BUILDERS,…}_ORIGIN overrides — so a web.env var only takes
 // effect under THIS prefix. Read from the pack (fail-soft to the vanilla default)
@@ -139,7 +153,7 @@ const PROVISIONED_BRANDING_FILE = 'config/branding.neutral.json';
 // the OAuth creds were silently unreadable — task 1972.)
 function provisionedEnvPrefix() {
   try {
-    const pack = JSON.parse(fs.readFileSync(path.join(REPO_ROOT, PROVISIONED_BRANDING_FILE), 'utf8'));
+    const pack = JSON.parse(fs.readFileSync(path.join(REPO_ROOT, ENV_PREFIX_PACK), 'utf8'));
     return pack.envPrefix || 'CLOUDBONGOS';
   } catch { return 'CLOUDBONGOS'; }
 }
@@ -228,8 +242,7 @@ GITHUB_APP_PRIVATE_KEY=${String(appPem).replace(/\r?\n/g, '\\n')}
 ${credComment}
 ${prefix}_GITHUB_CLIENT_ID=${clientId || ''}
 ${prefix}_GITHUB_CLIENT_SECRET=${clientSecret || ''}
-${firstAdminLine}GDS_BRANDING_FILE=${PROVISIONED_BRANDING_FILE}
-${originLines}${appLines}PORT=${inst.port}
+${firstAdminLine}${originLines}${appLines}PORT=${inst.port}
 PGDATABASE=${dbName(inst)}
 ${fedLines}${settingsEnvLines(inst, prefix)}`;
 }
@@ -318,7 +331,7 @@ function upsertEnvVars(body, vars) {
 // env the hub already runs under). Null → not hub-configured → shouldFederate is false.
 
 module.exports = {
-  PROVISIONED_BRANDING_FILE,
+  ENV_PREFIX_PACK,
   backupScriptPath,
   backupService,
   backupServicePath,

package/scripts/gds/provision.js

@@ -52,7 +52,7 @@ const crypto = require('node:crypto');
 const { CONFIG, MANIFEST_UA, MANIFEST_VERIFY_INTERVAL_MS, MANIFEST_VERIFY_TRIES, MAX_INTENT_ATTEMPTS, REPO_ROOT, coreVersionSafe, hasFlag, loadDeps, oauthSecret, provisionerBotEmail } = require('./provision-config.js');
 const { APP_USER, alreadyScaffolded, buildCorePinRefreshCommit, dbCreateCmd, dbName, deployKeyPath, deployKeyTitle, ensurePrivateRepoAccess, installedCorePackDir, installedCoreTarball, instanceInitSpec, instanceRepoRemote, migrateCmd, onboardMode, ownerLoginOf, parseTargetRef, planCorePinRefresh, refreshStandaloneCorePin, resolveOwnerGithubToken, resolveVendorableCoreTarball, safeVersionLabel, scaffoldStandaloneRepo, seedFirstVersionCmd, standaloneInstallCmd, standaloneMigrateCmd, standalonePullCmd, standaloneRegenDocsCmd, standaloneRoot } = require('./provision-repo.js');
 const { backupScriptPath, backupService, backupServicePath, backupTimer, backupTimerPath, backupUnitName, instanceManifestCmd, originEnvVarsFor, serviceUnit, serviceUnitPath, settingsConsumed, settingsEnvVarsFor, upsertEnvVars, webEnvBody, webEnvPath } = require('./provision-units.js');
-const { caddyBlock, caddySnippetPath, checkDnsTokenScope, classifyZoneScope, dnsReleaseEnv, dnsUpsertEnv, federateInstance, federationHubOrigin, healthzCmd, shouldFederate, zoneForDomain } = require('./provision-net.js');
+const { caddyBlock, caddySnippetPath, checkDnsTokenScope, classifyZoneScope, dnsReleaseEnv, dnsUpsertEnv, federateInstance, federationHubOrigin, healthzCmd, identityCmd, identityVerdict, shouldFederate, zoneForDomain } = require('./provision-net.js');
 
 function makeExec({ apply, log = console.log, remoteHost = null, remoteCwd = null, sshOpts = '' }) {
   // `shown` (task 1003140): what to LOG in place of the command text — for a command
@@ -503,6 +503,32 @@ async function provisionInstance(inst, deps) {
     }
   } else log('    (verified post-boot)');
 
+  // ── step 7b: identity ─────────────────────────────────────────────────────
+  // Does it answer as ITSELF? A live instance that serves the platform's name instead of its own
+  // is invisible to healthz — it is perfectly healthy and telling every newcomer the wrong project
+  // (task 1003740, which went unnoticed across every hosted instance for months). A WARNING, never
+  // a failure: an owner may legitimately name a project after the platform, and a name must not
+  // fail a working standup.
+  if (local && apply && healthy !== false) {
+    const res = boxExec(identityCmd(inst), { allowFail: true });
+    const raw = res && !res.softFailed ? (res.stdout || '') : '';
+    let manifest = null;
+    try { manifest = raw ? JSON.parse(raw) : null; } catch (_) { manifest = null; }
+    if (manifest) {
+      let neutralName = null;
+      try {
+        neutralName = (JSON.parse(fs.readFileSync(path.join(REPO_ROOT, 'config/branding.neutral.json'), 'utf8'))
+          .identity || {}).productName || null;
+      } catch (_) { /* no neutral pack readable → the check simply cannot fire */ }
+      const verdict = identityVerdict({ manifest, slug: inst.slug, neutralName });
+      if (verdict.ok === false) {
+        log(`  ⚠ ${inst.slug} ${verdict.reason} — check its config/branding.json and that no env var pins its branding pack`);
+      } else if (verdict.ok) {
+        log(`  [identity] answers as "${verdict.name}"`);
+      }
+    }
+  }
+
   // Mark active. error_note: null — a stale note from an earlier failed run
   // must not ride into the active state (F15's second half; the co-tenant +
   // standalone paths never cleared it). The runner hands its own observation

package/src/module-api.js

@@ -55,7 +55,7 @@ const { buildInfo } = require('./build-info');
 // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
 // the entry to that file. Look for a version's history there, not here.
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.612'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.614'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');

package/tests/provision.mjs

@@ -19,10 +19,11 @@ import { join } from 'node:path';
 const require = createRequire(import.meta.url);
 const P = require('../scripts/gds/provision.js');
 
-// The env-var prefix a provisioned instance resolves = the envPrefix of the pack
-// webEnvBody points GDS_BRANDING_FILE at (config/branding.neutral.json). Read it
-// here so these assertions stay in lockstep with the code (both derive it), not a
-// pinned literal that would rot if the neutral default ever changed.
+// The env-var prefix a provisioned instance resolves = the envPrefix an instance INHERITS from
+// the neutral pack (task 1003740: webEnvBody no longer pins a branding pack anywhere — the
+// instance loads its own config/branding.json by default — but the prefix floor is still the
+// neutral pack's, and every live co-tenant pack pins the same value explicitly). Read it here so
+// these assertions stay in lockstep with the code (both derive it), not a pinned literal.
 const NEUTRAL_PREFIX =
   JSON.parse(readFileSync(new URL('../config/branding.neutral.json', import.meta.url), 'utf8')).envPrefix || 'CLOUDBONGOS';
 const reEsc = (s) => s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
@@ -205,7 +206,6 @@ t('webEnvBody: OAuth creds use the LOADED pack\'s envPrefix (not the slug) + bra
   const b = P.webEnvBody(coTenant); // coTenant.domain === null
   assert.match(b, new RegExp(`${reEsc(NEUTRAL_PREFIX)}_GITHUB_CLIENT_ID=`));
   assert.match(b, new RegExp(`${reEsc(NEUTRAL_PREFIX)}_GITHUB_CLIENT_SECRET=`));
-  assert.match(b, /GDS_BRANDING_FILE=config\/branding\.neutral\.json/);
   assert.match(b, /PORT=3003/);
   assert.match(b, /PGDATABASE=mercury/);
   // The prior slug prefix was a latent bug: it never matched the neutral pack's
@@ -215,6 +215,56 @@ t('webEnvBody: OAuth creds use the LOADED pack\'s envPrefix (not the slug) + bra
   assert.doesNotMatch(b, /_BUILDERS_ORIGIN=/);
 });
 
+t('webEnvBody: an instance is never pinned to the neutral pack, so it serves its OWN name (task 1003740)', () => {
+  // THE BUG THIS PINS. Provisioning used to pin every instance to config/branding.neutral.json
+  // into every instance's web.env — a leftover from the shared-checkout co-tenant model. Under
+  // ADR 0108 each instance has its own checkout and its own config/branding.json, and
+  // src/branding.js's ENV_OVERRIDES cover domains/auth.idp/landing but NEVER identity.productName.
+  // So the pin made every hosted instance answer GET /api/gds/instance with the PLATFORM's name:
+  // hermeslines-marketing, mercury and demo all said "Cloud Bongos" while their own packs on disk
+  // said otherwise, and `bongos login <instance>` greeted newcomers with the wrong project.
+  const b = P.webEnvBody({ ...coTenant, domain: 'mercury.example.com' });
+  // Matched on the distinctive half of the env var's name: the full name carries a legacy literal
+  // the goal-1000073 rename ratchet counts, and this is strictly stronger anyway — it also catches
+  // a pin written under any other prefix.
+  assert.doesNotMatch(b, /BRANDING_FILE/,
+    'provisioning must not pin the branding pack — the instance loads its own config/branding.json');
+
+  // The pin is gone, but the env PREFIX it used to keep in lockstep must still be the one
+  // ENV_OVERRIDES reads, or the origin overrides silently stop firing (the task-1972 failure).
+  assert.match(b, new RegExp(`${reEsc(NEUTRAL_PREFIX)}_BUILDERS_ORIGIN=`));
+  assert.match(b, new RegExp(`${reEsc(NEUTRAL_PREFIX)}_GITHUB_CLIENT_ID=`));
+});
+
+t('identityVerdict: a live instance serving the PLATFORM name is caught, not shrugged at (task 1003740)', () => {
+  const N = require('../scripts/gds/provision-net.js');
+  const neutralName = 'Cloud Bongos';
+
+  // The bug's exact live shape — healthz was green the whole time this was true.
+  const bad = N.identityVerdict({ manifest: { name: 'Cloud Bongos' }, slug: 'hermeslines-marketing', neutralName });
+  assert.equal(bad.ok, false);
+  assert.match(bad.reason, /platform default name/);
+
+  // Fixed: the instance answers as itself.
+  assert.equal(N.identityVerdict({ manifest: { name: 'Hermeslines Marketing' }, slug: 'hermeslines-marketing', neutralName }).ok, true);
+
+  // It reads brand.identity.productName too — the manifest carries the name in both places.
+  assert.equal(N.identityVerdict({ manifest: { brand: { identity: { productName: 'mercury' } } }, slug: 'mercury', neutralName }).ok, true);
+
+  // NOT a false positive: a project genuinely named after the platform keeps its name. The check
+  // must never fail a working standup over a legitimate name.
+  assert.equal(N.identityVerdict({ manifest: { name: 'Cloud Bongos' }, slug: 'Cloud Bongos', neutralName }).ok, true);
+
+  // Unknowable → null, never a false accusation.
+  assert.equal(N.identityVerdict({ manifest: {}, slug: 'x', neutralName }).ok, null);
+  assert.equal(N.identityVerdict({ manifest: { name: 'x' }, slug: 'x', neutralName: null }).ok, true);
+});
+
+t('identityCmd: probes the manifest over loopback, like healthzCmd', () => {
+  const N = require('../scripts/gds/provision-net.js');
+  assert.match(N.identityCmd({ port: 3011 }), /127\.0\.0\.1:3011\/api\/gds\/instance/);
+});
+
 t('webEnvBody: a domain writes the single-host origin overrides so the hall loads (task 1972)', () => {
   const b = P.webEnvBody({ ...coTenant, domain: 'mercury.example.com' });
   const O = reEsc('https://mercury.example.com');