@bongos/core 1.19.587 → 1.19.589

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.587",
-  "core_contract": "1.19.587",
-  "source_commit": "cd407ba54d0bdbe3638949084ba731c21179c811",
+  "core_version": "1.19.589",
+  "core_contract": "1.19.589",
+  "source_commit": "29fe6277ac47bc629f56c68e20dca829ed9370f2",
   "source_ref": "HEAD",
-  "built_at": "2026-09-08T00:16:55.401Z",
+  "built_at": "2026-09-08T02:16:53.692Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 455,
+    "docs_redacted": 457,
     "agent_docs_stubbed": 24,
     "functional_verbatim": 2060,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2539,
-  "tree_sha256": "20c7a1a223a182078ca9a6e5dc0b6ca8d715a6e8b0a47b08a9c4dcb8dac2c74a",
+  "file_count": 2541,
+  "tree_sha256": "d96aab84f10a639efe4d035824854aed5cb9bf2fcc7723f62a69f4b1a8074591",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -1829,10 +1829,20 @@
       "mode": "0000644",
       "sha256": "cc30ad9de02409b6e3db26517bef2966133b3362903a984b65d94ea289fd0d88"
     },
+    {
+      "path": "docs/adr/0263-how-a-version-closes.md",
+      "mode": "0000644",
+      "sha256": "07a3561c7bc7f55bb2077925df4df6a24b68a1f0c8d4052ac50278edd9d4eba1"
+    },
+    {
+      "path": "docs/adr/0264-the-ten-working-areas.md",
+      "mode": "0000644",
+      "sha256": "03f1cf19a181d6726066ba6fb72156add0cb8ede004ebc7ddf8ac3859a335596"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "9d58f1a823a763141df272149e58b2182aa2289dd94d69ba0b3999789d8fc743"
+      "sha256": "b38a32c8557012f9e5e761c5e219901ad628af9b63d2cb190d32e783dbf9aaa9"
     },
     {
       "path": "docs/api-reference.md",
@@ -2717,7 +2727,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "3e6075bb21834fc14b6201155cac3f4b51e262d86d6ccbed2505f593831f59f9"
+      "sha256": "0ca6c49c46b3bc4621613099885595eb387c784e86f9fb83d5600912c1ea4c38"
     },
     {
       "path": "docs/modules-contract.md",
@@ -7592,12 +7602,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "2b1a6ffdd207887a187f1574571de67e3f8ba851e80e433d463e932316b36e16"
+      "sha256": "57bf21d2c0b7e235c4628f7f1d7e52c8b65b30375d96adcce8558a5e1cce1b5a"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "0caa3d71c5b02c8a41cebc7e59a6af2d68b50eb419311c7d444b0daa30df8430"
+      "sha256": "fc682e53b7902f41fb4a455c9f61d70a5b154159df150b6e7e6c696c596df4e4"
     },
     {
       "path": "public-docs/index.html",
@@ -9307,7 +9317,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "6a4b0d97d9bc67728886e879359cf1f657dd81f865d141d8a1c6cd6e41877012"
+      "sha256": "9264831ff874468719e9a6f73a3dfa39507f6ce033f25cdfc9d08e840d1a58fe"
     },
     {
       "path": "src/module-loader/catalog.js",

package/docs/adr/0263-how-a-version-closes.md

@@ -0,0 +1,275 @@
+# 0263 — How a version closes: auto, early, roll-forward, and the maintenance exemption
+
+- **Status:** Accepted
+- **Date:** 2026-09-07
+- **Tasks:** [#1003593](https://cloudbongos.com/builders#/task/1003593) (this design pass, BV1.R06). Implemented by BV1.R12 ([#1003599](https://cloudbongos.com/builders#/task/1003599)), R16 ([#1003603](https://cloudbongos.com/builders#/task/1003603)), R17 ([#1003604](https://cloudbongos.com/builders#/task/1003604)), R18 ([#1003605](https://cloudbongos.com/builders#/task/1003605)), R20 ([#1003607](https://cloudbongos.com/builders#/task/1003607)) and R23 ([#1003610](https://cloudbongos.com/builders#/task/1003610)).
+- **Goal:** [#1000086](https://cloudbongos.com/builders#/goal/1000086) — Strict versioning.
+- **Implements:** [ADR 0250](<redacted>.md) D5. That decision says a version *can* close; this one says *how*, so the five build tasks under it are mechanical.
+
+## 1. Why a second ADR
+
+[ADR 0250](<redacted>.md) is the
+decision: the version boundary is the scope gate, and a version must be able to
+reach done. It deliberately stops at the rule. Closing a version is the widest
+write in the system — it flips a version, dispositions every goal still standing,
+promotes the next version into `building`, and carries a bug queue across the
+boundary — and *four* separate tasks build pieces of it. Left undesigned, each
+would pick its own refusal codes, its own payload shape, and its own answer to
+"what happens to the maintenance goal", and the seams would only meet in
+production.
+
+So this ADR pins the mechanics. It adds no rule ADR 0250 did not already decide.
+
+## 2. The state machine
+
+`versions.status` has four values (migration 003): `planning`, `building`,
+`shipped`, `frozen`. Only two transitions are in scope here:
+
+```
+planning ──promote──> building ──close──> shipped
+```
+
+`frozen` is archival bookkeeping and no business of this design. Nothing
+un-closes a version: reopening is not a move, and a version closed in error is
+corrected the way any other bad row is.
+
+**Only a `building` version may close.** Closing a `planning` version is
+meaningless (nothing was built), and closing an already-`shipped` one is a
+double-close. Both are `version_not_building` (409).
+
+## 3. Two doors, and the asymmetry that makes the design simple
+
+The single most useful thing to notice about D5 is that **auto-close, by
+construction, has nothing to disposition.**
+
+Auto-close fires when the last non-maintenance goal achieves. If that goal was
+the last one, then every non-maintenance goal on the version is already
+`achieved` or `archived` — so the set of open goals needing a decision is *empty
+by definition*. The disposition machinery is not merely unnecessary on that path;
+it can never have input.
+
+That splits the feature cleanly in two:
+
+| | **Auto-close** (R16) | **Early close** (R12) |
+|---|---|---|
+| Trigger | the last non-maintenance goal achieves | an Archon calls `POST /versions/:id/close` |
+| Open goals at close | zero, by construction | any number |
+| Disposition required | none — there is nothing to disposition | one per open non-maintenance goal |
+| Actor | the system, on a ship or a satisfy | an Archon, deliberately |
+| Roll-forward | the maintenance goal only | the maintenance goal, plus every goal dispositioned `roll_forward` |
+
+Every complication in this feature — the disposition map, the refusal that
+returns the open goals, the successor lineage — belongs to **early close only**.
+R16 is a much smaller task than the ADR 0250 sentence makes it sound, and R12 is
+where the weight is.
+
+## 4. Auto-close: where it fires, and why it cannot fail a ship
+
+Goal achievement has **two writers**, and [ADR 0250](<redacted>.md) D2 already made them a deliberate,
+documented duplicate rather than one helper, because collapsing them creates a
+require cycle (`db-goals` → `done-when` → `db-goals`):
+
+- [`db-goals.js` `achieveGoalIfComplete`](../../modules/lifecycle/db-goals.js) — the manual `POST /done-when/:id/satisfy` path.
+- [`done-when.js` `autoSatisfyShippedCriteria`](../../modules/lifecycle/done-when.js) — the cascade that fires on **every ship** and every reconciler tick, on the ship transaction's own `exec`.
+
+**Auto-close hangs off both, on the same exec, exactly as R08/R09's closure check
+did.** The rule is written twice on purpose, and the two copies move together or
+a version closes correctly through one door and wrongly through the other. That
+sentence is already load-bearing in both files; this feature adds a second clause
+governed by it, so it is repeated here rather than left to be rediscovered.
+
+**Auto-close must never fail a ship.** This is not a preference — it is the
+established posture of the surrounding code:
+[`closeCompletedWorkForShip`](../../modules/lifecycle/done-when.js) already
+swallows its own failure and reports it in a summary line, on the argument that a
+criterion close must never fail a ship and the reconciler's unscoped sweep
+retries every tick. Version close is a strictly wider write than a criterion
+close, so it inherits the posture *a fortiori*:
+
+- it runs inside the ship transaction so it sees the uncommitted `shipped` flip (the same reason R09's clause needs `exec`);
+- it is wrapped so a throw is caught, logged, and reported — never propagated into the ship;
+- it is **idempotent** (`WHERE status = 'building'` guards the flip), so the reconciler sweep retrying it is a no-op once it has run.
+
+The consequence, stated plainly: **a version can be left un-closed by a failure,
+and never half-closed.** Un-closed self-heals on the next sweep. That is the
+correct trade — the opposite choice makes a bug in version-close able to block
+every builder's ship.
+
+### The archive doc is not part of the transaction
+
+`limitations/<version>-shipped.md` is a **repo file**, and a route cannot write
+one. Auto-close therefore flips the database and nothing else; the scope archive
+stays a human/agent follow-up driven by
+[`scripts/gds/version-close.js`](../../scripts/gds/version-close.js) (R23). This is
+worth saying because ADR 0250 §7 speaks of a version "reaching done", and a
+reader could reasonably assume the archive rides along. It does not, and pretending
+otherwise would put file I/O inside a ship transaction.
+
+## 5. Early close: the two-step, mirroring the archive refusal
+
+`POST /versions/:id/close` is Archon-only, behind the **already-defined**
+`version.close` permission ([`government/catalog.js`](../../modules/government/catalog.js)) that nothing has referenced until now.
+
+The shape is **the R10 archive two-step, verbatim in spirit** — that precedent is
+shipped, agents already know it, and inventing a second idiom for the same
+interaction is how two surfaces drift:
+
+**Step 1 — refuse, and return the work.** Called with open non-maintenance goals
+and no disposition, the route refuses with `version_holds_open_goals` (409) and
+**returns the goals**, not merely a count. R10's reasoning applies unchanged: the
+caller's next move is to decide what happens to each, and an agent that has to go
+fetch the list first will guess instead.
+
+```
+409 { error: "version_holds_open_goals",
+      message: "Version 'BONGOS-V1' still holds 12 open goal(s). …",
+      details: { total: 12, shown: 12,
+                 goals: [ { id, title, open_tasks } … ] } }
+```
+
+**Step 2 — proceed with a disposition map.** One entry per open non-maintenance
+goal, keyed by goal id:
+
+```json
+{ "reason": "V1 is done; the rest is V2 scope.",
+  "dispositions": {
+    "1000044": { "verb": "roll_forward" },
+    "1000065": { "verb": "abandon" }
+  } }
+```
+
+Two verbs, and only two:
+
+- **`roll_forward`** — a successor goal is created in the planning version (§6).
+- **`abandon`** — the goal is archived, and its open tasks are abandoned with the close's `reason`, through the same path R14 gives the archive flow. It is deliberately **not** possible to abandon a goal without a reason: `reason` is required on the close call, and it is what lands in each abandoned task's record.
+
+**A version holding zero open goals stays a single call**, exactly as a goal
+holding zero open tasks does. That is the auto-close path's shape too, so both
+doors agree.
+
+### Refusal codes
+
+Every one is **named**, per ADR 0250 §7 — the callers are agents, and an unnamed
+409 is an agent stopping to ask a human.
+
+| Code | Status | When |
+|---|---|---|
+| `version_not_found` | 404 | no such version |
+| `version_not_building` | 409 | the version is `planning`, `shipped` or `frozen` |
+| `version_holds_open_goals` | 409 | open non-maintenance goals and no/partial disposition map; returns the goals |
+| `bad_disposition` | 400 | a disposition names an unknown goal, a goal not on this version, or a verb outside `roll_forward`/`abandon` |
+| `no_planning_version` | 409 | a `roll_forward` was asked for and no `planning` version exists to receive it |
+| `close_reason_required` | 400 | `reason` missing on a close that dispositions anything |
+
+`no_planning_version` is the one that will actually be hit in practice, and it is
+a **refusal rather than an auto-create on purpose**: cutting the successor version
+is a scope decision with its own criteria, and doing it implicitly inside a close
+is precisely the "fake hotfix version" failure ADR 0250 §3 built the override
+counter to prevent.
+
+## 6. Roll-forward: the lineage column already exists, pointing the other way
+
+Migration 160 gave `goals` a **`succeeded_by_goal_id`** column — on the *old*
+goal, pointing at the *new* one. Both ADR 0250 and task 1003604's brief say
+`succeeds_goal_id`, which does **not** exist. The column that exists wins; there
+is no migration here, and R17 must write:
+
+```sql
+UPDATE goals SET succeeded_by_goal_id = <new.id> WHERE id = <old.id>
+```
+
+Naming this explicitly is the whole reason this section exists — R17's brief would
+otherwise send a builder to reserve a migration number for a column that has been
+in the schema since the goal tier landed.
+
+A rolled-forward goal is created on the planning version carrying the original's
+`title`, `description`, `scope_modules`, `category_id` and **membership**; its
+open tasks are re-pointed at it. The predecessor is then `archived` with zero
+open tasks — so it passes R10's own check on the way out, rather than being
+special-cased around it.
+
+## 7. The maintenance goal: the flag R18 owes, and the exemption
+
+The maintenance goal is currently **matched by title** —
+`ensureMaintenanceGoal` (task 1003691) looks up `"<version> — maintenance"`, and
+its own comment flags this as R18's debt:
+
+> MATCHED BY TITLE, because there is no column that says "this is the maintenance goal" … task 1003605 (BV1.R18) is where a real flag belongs when the feature gets its own column.
+
+**R18 adds the column**: `goals.is_maintenance boolean NOT NULL DEFAULT false`,
+backfilled by title for the rows that already exist, after which the title lookup
+becomes a flag read. This is not cosmetic. The close count asks "are there any
+open non-maintenance goals?", and answering it with a `title NOT LIKE` would make
+a hand-titled goal silently exempt from the gate that decides when a **version**
+closes — a much worse blast radius than the provenance wrinkle the title match
+carries today.
+
+The exemption is then one predicate, used identically by auto-close and early
+close:
+
+```sql
+WHERE version_id = $1 AND status = 'open' AND NOT is_maintenance
+```
+
+**The maintenance goal always rolls forward, and never needs a disposition.** It
+is exempt from the close count, so it cannot hold a version open; and its open
+bugs move to the successor version's maintenance goal (`ensureMaintenanceGoal` on
+the newly-promoted version — the find-or-create already exists and is
+advisory-locked). Bugs arrive on their own schedule and must not need an override
+to be filed; that is the pressure valve ADR 0250 §3 describes, and it only works
+if the queue survives the boundary.
+
+## 8. Promotion: the close's last act
+
+On a successful close, the single `planning` version is promoted to `building`
+(R20), so the project is never without a live train.
+
+- It runs **in the close's transaction** — a project with zero building versions is a broken state, not an intermediate one, and `currentBuildingVersionId` returns `null` there, which fails every routing path closed over it.
+- **Zero planning versions is not an error.** The close succeeds and the project sits with no building version until someone cuts one. Refusing the close would trap a finished version open because nobody had scoped the next one yet.
+- Exactly one can be promoted, because R04 already refuses a second `planning` version.
+- The promoted version gets its maintenance goal via `ensureMaintenanceGoal`, which is what receives the carried-forward bugs in §7.
+
+**Ordering inside the transaction is load-bearing:** promote *before* roll-forward
+and before the bug carry-over, because both need a destination version that is
+already `building` — `ensureMaintenanceGoal` returns `null` for a version whose
+status is not `building`, so a carry-over run before the promotion silently
+carries nothing.
+
+## 9. The race, and where the index belongs
+
+[`versions.js`](../../modules/lifecycle/routes/versions.js) already documents R04's
+unmitigated check-then-insert race and names R19 as the place to fix both halves
+with one partial unique index. That still stands, and this design adds the close
+side of the same exposure: two concurrent closes could both promote.
+
+The single migration R19 reserves should therefore carry **both** guards:
+
+```sql
+CREATE UNIQUE INDEX ON versions ((status)) WHERE status = 'planning';
+CREATE UNIQUE INDEX ON versions ((status)) WHERE status = 'building';
+```
+
+With those in place the promotion race resolves the way the version-id collision
+already does — the loser gets a `23505` and the route translates it into the same
+clean refusal, rather than the check-then-act prayer both rules rely on today.
+
+## 10. What this design does not do
+
+- **It does not gate shipping.** Consistent with ADR 0250 §4. Auto-close rides the ship transaction and is swallowed on failure; nothing here can refuse a ship, a claim, or a grade.
+- **It does not write the scope archive.** §4. The route closes the version; the doc is R23's CLI work.
+- **It does not auto-create the successor version.** §5. That is a scope decision with criteria, and doing it implicitly is the escape hatch ADR 0250 exists to close.
+- **It does not add a reopen.** A version does not un-close.
+
+## 11. The sub-tasks this implies
+
+All five were already filed by the planning session; this ADR is what makes them
+mechanical. Two briefs are **corrected** by it:
+
+| Task | What this ADR pins |
+|---|---|
+| R12 [#1003599](https://cloudbongos.com/builders#/task/1003599) | the route, the six refusal codes, the two-step + disposition payload (§5) |
+| R16 [#1003603](https://cloudbongos.com/builders#/task/1003603) | **corrected** — auto-close needs no disposition machinery (§3); it hangs off *both* achievement writers on the caller exec and may never fail a ship (§4) |
+| R17 [#1003604](https://cloudbongos.com/builders#/task/1003604) | **corrected** — the column is `succeeded_by_goal_id` and already exists; no migration (§6) |
+| R18 [#1003605](https://cloudbongos.com/builders#/task/1003605) | the `is_maintenance` flag, the backfill, the exemption predicate, the bug carry-over (§7) |
+| R20 [#1003607](https://cloudbongos.com/builders#/task/1003607) | promotion runs in the close txn, before roll-forward; zero planning versions is not an error (§8) |
+| R19 [#1003606](https://cloudbongos.com/builders#/task/1003606) | its migration carries the `building` partial index **and** R04's `planning` one (§9) |

package/docs/adr/0264-the-ten-working-areas.md

@@ -0,0 +1,144 @@
+# 0264 — The ten working areas: one goal per area, held until 5,000 builders
+
+- **Status:** Accepted
+- **Date:** 2026-09-07
+- **Tasks:** [#1003696](https://cloudbongos.com/builders#/task/1003696) (this record). Executed by BV1.R25 ([#1003612](https://cloudbongos.com/builders#/task/1003612)), R26 ([#1003613](https://cloudbongos.com/builders#/task/1003613)), R27 ([#1003614](https://cloudbongos.com/builders#/task/1003614)), R28 ([#1003615](https://cloudbongos.com/builders#/task/1003615)) and R29 ([#1003617](https://cloudbongos.com/builders#/task/1003617)).
+- **Goal:** [#1000086](https://cloudbongos.com/builders#/goal/1000086) — Strict versioning, criterion `sv-cutover-proven-live`.
+- **Decided by:** the owner and the full team, in a manual goal review on 2026-09-07.
+- **Builds on:** [ADR 0250](<redacted>.md) (the version boundary is the scope gate — this is the scope that boundary will hold), [ADR 0086](<redacted>.md) (the goal tier).
+
+## 1. The decision
+
+**The platform runs on exactly ten goals — one per working area — until it has
+5,000 builders.** Each area has a named owner and a description of what "done"
+looks like at that scale. Thirty-eight goals are open today; they collapse into
+these ten.
+
+| # | Working area | Owner | The 5,000-builder state |
+|---|---|---|---|
+| 1 | **Project creation** | Rini | Any new user, developer or not, can create a project from an existing folder or code repository whatever it already contains. |
+| 2 | **Account creation, management & community** | Rini | — |
+| 3 | **Human project management** | Scott | A project-management system with scalable levels of hierarchy — not infinitely configurable. Users edit, scope and manage work without ever prompting Claude. |
+| 4 | **Bongos Core distribution** (staging of updates) | Lars / Will | Core updates are offered in every project's UI, and via the update CLI or skill. Approved users decide whether to take an update. A changelog is visible inside the update. |
+| 5 | **Module distribution & economy** | Will | Modules are bought with money or credits and update the same way. Bongos assesses and ranks module quality; willing users test before mass deployment; only the best modules are listed, on price and assessed quality. |
+| 6 | **Governor / Builder / Artist / Ideator experience** (incl. agents) | Masterqua / Rini | Each role gets a tailored experience that cannot break into the others. Noise is limited at every human interface. Agents are designed to aid all these roles. |
+| 7 | **Government** | Will / Masterqua | Fully customizable creation of ranks and what each entails for project access. Recommended base ranks and governments ship for different project types and sizes. |
+| 8 | **Platform credit economy** | Scott | Real money reaches users for completed work, without fail. Users hold platform balances, fund projects and pay each other with no fees. Bongos banks project funds and delivers them on cash-out. |
+| 9 | **Platform analytics** | Lars | Bongos gathers as much user data as it can to improve itself — session transcripts as an efficiency signal, plus every user action and work delivery across the ecosystem through the Bongos API. |
+| 10 | **Security** | all except Nils and Scott | Ranks are enforced. The Bongos server is not hackable by Claude's latest model. Red-teaming is consistent. |
+
+## 2. Why ten, and why now
+
+Thirty-eight open goals is not a plan; it is a list of everything anyone has ever
+wanted. [ADR 0250](<redacted>.md) measured what that costs — 523 open tasks, fourteen goals
+reporting done while holding thirty-five unfinished tasks — and built the
+machinery to stop the drift. But **enforcement alone cannot shrink a scope that
+is already too large**: D1 closes the goal set of a *building* version, which
+freezes thirty-eight goals in place just as effectively as it would freeze ten.
+
+So the rules and the cut are two halves of one move. This ADR is the cut. Ten is
+chosen to be small enough that every area has a single owner who can hold its
+whole shape in their head, and the horizon is **5,000 builders** rather than a
+date, because the point at which this set stops being the right set is a scale
+question, not a calendar one.
+
+## 3. The disposition of all 38 open goals
+
+Nothing on this list is a guess. Every row below the horizontal rule was named in
+the review; the three rows above it were not, and are marked as such.
+
+### Not covered by the review — open questions
+
+| Goal | Note |
+|---|---|
+| [#1000003](https://cloudbongos.com/builders#/goal/1000003) — Work with no goal yet | The per-version catch-all. Already R25's target: drained and archived there. No separate decision needed. |
+| [#1000065](https://cloudbongos.com/builders#/goal/1000065) — Community surface | Reads as the community half of area 2 and is treated as such below, but the review did not say so. **Confirm before executing R25.** |
+| [#1000088](https://cloudbongos.com/builders#/goal/1000088) — Repo cleanup: everything justifies itself | Genuinely unmentioned, and maps to no area. **Needs an owner decision: fold, keep as an eleventh, or close.** |
+
+### Becomes an area, or folds into one
+
+| Goal | Disposition | Area |
+|---|---|---|
+| [#1000046](https://cloudbongos.com/builders#/goal/1000046) — Project creation | **becomes the area** (active; Rini building, Lars on the npm package) | 1 |
+| [#1000065](https://cloudbongos.com/builders#/goal/1000065) — Community surface | becomes the area *(assumed — see above)* | 2 |
+| [#1000045](https://cloudbongos.com/builders#/goal/1000045) — Public builder profiles | fold — relevant, active | 2 |
+| [#1000075](https://cloudbongos.com/builders#/goal/1000075) — Collaboration & the social hall | fold — Niels almost done; builder collaboration is refined under community | 2 |
+| [#1000085](https://cloudbongos.com/builders#/goal/1000085) — The operable hall | fold | 3 |
+| [#1000054](https://cloudbongos.com/builders#/goal/1000054) — Public distribution | fold — Rini and Lars, relevant | 4 |
+| [#1000029](https://cloudbongos.com/builders#/goal/1000029) — Module upstreaming & catalog | fold — looped into the module goal | 5 |
+| [#1000066](https://cloudbongos.com/builders#/goal/1000066) — Role-composed context | fold — this is the working-area goal | 6 |
+| [#1000038](https://cloudbongos.com/builders#/goal/1000038) — Agent framework & registry | fold — stays, needs cleanup from Rini; dedicated agents for specific tasks | 6 |
+| [#1000039](https://cloudbongos.com/builders#/goal/1000039) — Agent authoring & first roster | fold into the agents one | 6 |
+| [#1000040](https://cloudbongos.com/builders#/goal/1000040) — Agent scheduling & spend limits | fold into the agents one | 6 |
+| [#1000025](https://cloudbongos.com/builders#/goal/1000025) — Builder experience | review first, close out solid tasks, then fold | 6 |
+| [#1000068](https://cloudbongos.com/builders#/goal/1000068) — Government, not governance | **becomes the area** — Lars blitzes it; bugs and a rename | 7 |
+| [#1000057](https://cloudbongos.com/builders#/goal/1000057) — Rank blocker matrix | fold into government | 7 |
+| [#1000078](https://cloudbongos.com/builders#/goal/1000078) — Project money out | merge into builder compensation | 8 |
+| [#1000067](https://cloudbongos.com/builders#/goal/1000067) — Ideator compensation | merge into builder payout | 8 |
+| [#1000084](https://cloudbongos.com/builders#/goal/1000084) — Execution integrity & tenant isolation | bring into the security goal | 10 |
+| [#1000070](https://cloudbongos.com/builders#/goal/1000070) — Scan-before-install | fold — Rini does the bug task | 10 |
+
+Areas **3** (human project management), **4** (core distribution), **5** (module
+distribution & economy), **8** (credit economy), **9** (platform analytics) and
+**10** (security) have no single existing goal to promote and are **created** by
+R29, taking the folds listed against them.
+
+### Finish, then close
+
+| Goal | Disposition |
+|---|---|
+| [#1000086](https://cloudbongos.com/builders#/goal/1000086) — Strict versioning | *"EVERYONE DO THIS NOW."* Finish, then close — it is the enabling work for the cut itself. |
+| [#1000073](https://cloudbongos.com/builders#/goal/1000073) — Finish the GDS→Bongos rename | Niels finishes; small. |
+| [#1000082](https://cloudbongos.com/builders#/goal/1000082) — Status ledger in the world | Lars deletes the status page, then closes it out. |
+| [#1000024](https://cloudbongos.com/builders#/goal/1000024) — Build-pipeline integrity | A pile of bugs — check relevance, then fold or close. |
+| [#1000032](https://cloudbongos.com/builders#/goal/1000032) — Instance hosting + domains | Clean out, then close. |
+| [#1000058](https://cloudbongos.com/builders#/goal/1000058) — Non-cloudbongos project lifecycle | All bugs — fold into another goal. |
+
+### Deleted
+
+Twelve goals are cut outright:
+
+[#1000037](https://cloudbongos.com/builders#/goal/1000037) Pay-on-land incentive alignment ·
+[#1000043](https://cloudbongos.com/builders#/goal/1000043) Platform security: safe multi-tenant hosting ·
+[#1000044](https://cloudbongos.com/builders#/goal/1000044) Living project sky ·
+[#1000047](https://cloudbongos.com/builders#/goal/1000047) Project pricing & hosting revenue ·
+[#1000048](https://cloudbongos.com/builders#/goal/1000048) SEO & public discoverability ·
+[#1000049](https://cloudbongos.com/builders#/goal/1000049) Orb Physics ·
+[#1000050](https://cloudbongos.com/builders#/goal/1000050) Self-hosted project analytics ·
+[#1000052](https://cloudbongos.com/builders#/goal/1000052) First-run onboarding ·
+[#1000053](https://cloudbongos.com/builders#/goal/1000053) Sessions start knowing ·
+[#1000063](https://cloudbongos.com/builders#/goal/1000063) The front door ·
+[#1000064](https://cloudbongos.com/builders#/goal/1000064) The hall as the room ·
+[#4](https://cloudbongos.com/builders#/goal/4) CB-V1 — general (the old general bucket).
+
+**"Delete" means `archived`, not a row removal.** `goals.status` is
+`open|achieved|archived` (migration 160) and nothing deletes a goal — archiving is
+the disposition, and it is reversible via `POST /goals/:id/reopen`. Preserving the
+rows is deliberate: shipped tasks under a cut goal keep their attribution and
+credit history, which a delete would strand.
+
+## 4. The consequence that reorders the goal: R14 is the keystone
+
+**None of section 3 can be executed today, and the reason is a rule this goal
+shipped four tasks ago.**
+
+R10 ([task #1003597](https://cloudbongos.com/builders#/task/1003597)) made
+`POST /goals/:id/archive` refuse a goal that still holds unfinished tasks, returning
+the tasks and demanding a disposition. That was correct and is exactly ADR 0250 D3.
+But **the vector that supplies a disposition is R14** ([task #1003601](https://cloudbongos.com/builders#/task/1003601)), which has not shipped. So right now the
+archive door is closed and the key has not been cut.
+
+Every one of the twelve deletes and every fold in section 3 goes through that
+door. That makes R14 the **keystone of the entire cut**, not one feature among
+thirteen, and it should be built before the rest of the version-close chain
+rather than in rank order.
+
+This is worth stating plainly because it looks like a bug and is not: the refusal
+is the system working as designed, one task ahead of its own remedy.
+
+## 5. What this does not decide
+
+- **It does not renumber or re-rank the ten areas.** The order in §1 is the review's order, not a priority.
+- **It does not set criteria for the six new goals.** R29 scopes them; an area without done-when criteria cannot close, and inventing criteria for someone else's area is how a goal acquires scope its owner never agreed to.
+- **It does not move any task.** Rehoming is R25 (the catch-alls) and R26 (the closed goals holding open work).
+- **It does not decide the three open questions in §3.** They are surfaced, not guessed.

package/docs/adr/README.md

@@ -354,3 +354,5 @@ This keeps the decision history honest and traceable.
 | 0260 | [**An application IS the consent, and the hub’s own echo is the gate** ([task 1002972](https://cloudbongos.com/builders#/task/1002972) · goal 1000045, criterion C4). Privacy spec **D7** asks that a reviewer see what the applicant’s OWN profile rules would already show, evaluated LIVE at review time. The rule is ONE port composing the two EXISTING views — `getPublicProfileExtras` for a public account, `recruiter-sliver`’s own `sliverShapeFor` for a private one — because a third five-key lookalike **is** the new disclosure class D7 forbids. **The one deliberate difference from the D3 sliver:** `getRecruiterSliver` floors on recruiting REACH, and reusing it verbatim would be wrong in the direction that looks safe — `recruiter_discoverable` defaults to FALSE for a private account, so a private builder who deliberately applied would show their reviewer NOTHING and C4 would be satisfied by an empty box. D7 settles it: *“applying is an explicit act”*. The swap relaxes REACH only; `accountActiveSql` (active **and** terms accepted) and `hide_stats` still floor it, and the proof asserts both directions on the same account so the tempting refactor cannot pass quietly. **The federated route’s gate is the whole security story** ([ADR 0205](<redacted>.md) / security report 1000027): client credentials name a PROJECT and never a person, so `POST /sso/applicant-profile` authenticated alone is a bulk disclosure oracle over every account on the platform, private ones included. `applicationBacksProfileRead` demands a HUB-WRITTEN echo for exactly (this account, this client) inside the same 30-day window — a row only the hub’s own join relay creates — refusing **404, never 403**, and BEFORE any account is read (asserted on the statement log, because a gate that refuses after reading has already done the disclosure work). LIVE means nothing is stored at either end; the queue keys on the VOUCH and never on `github_login` (the one PUBLIC unauthenticated write makes an unvouched login an impersonation surface); and the hub client secret stays in core behind a narrow doorway port. **The path is complete but DORMANT until R09 ([task 1002285](https://cloudbongos.com/builders#/task/1002285)) ships the vouch writer** — nothing writes `applicant_github_id` today, and that dependency was missing from 1002972’s graph. Rejected: routing the port through `getRecruiterSliver`, a snapshot at apply time, resolving by `github_login`, and putting `loadIdpConfig` on the doorway.](<redacted>.md) | platform identity / privacy |
 | 0261 | [**A preselect always carries a reason; the bundle’s summary is the floor** ([task 1003684](https://cloudbongos.com/builders#/task/1003684) · goal 1000046 — *Project creation*). Resolves a collision between two rules that were each right alone. [ADR 0243](<redacted>.md) made `adjustments` a **delta** — a team-shape rule that fires without moving anything claims nothing, because a sentence explaining a change that did not happen is a claim the owner cannot check. [ADR 0237](<redacted>.md) says a preselect the owner cannot see a reason for is one they must audit, which is worse than no preselect at all. The two collide whenever a type’s bundle **already contains** what a rule would add: `game` is `[dev-box, discord]` and the `small-team` rule adds `dev-box`, so the rule fires, moves nothing, and correctly reports `adjustments: []`. Confirmed on live core 1.19.580 — `byTeamShape[small-team]` = `{"bundle":["dev-box","discord"],"adjustments":[]}`. The owner then reached step 4 and saw **two extras switched on with no reason beside them**, `#modWhy` an empty hidden div: exactly what 0237 exists to prevent, produced by 0243 behaving correctly. Filed as a dropped adjustment; it was not — the engine is right, and the panel simply had ONE voice and fell silent when the rule had nothing to say. **Decision: the why-line has two voices and the type’s is the floor.** A real adjustment still speaks for itself and is never displaced; when none moved, the type’s own curated `summary` explains the preselect; when the owner has answered the picker themselves the panel stays silent (unchanged — a reason handed back for a toggle they just flipped reads as the panel arguing with them); a bundle with no summary still says nothing, because a floor is not an invention. **No new copy, endpoint or field** — the summary was authored for this job in `starter-bundles.js`, served on every row of `GET /provisioning/starter-bundles`, and rendered NOWHERE in the product until now. 0243 is not weakened: the delta stays a delta and no rule is credited with a change it did not make. The pin `tests/projects_hub_module_picker.mjs` carried a fixture with **no `summary` field**, which made four “no adjustment, no sentence” cases pass for the wrong reason; the fixture now carries the real summaries and those cases assert the new contract, including explicitly that no RULE sentence is invented for a change that did not happen. Rejected: making the rule claim a no-op change (re-introduces the unverifiable claim 0243 removed); widening the bundles so no rule is ever redundant (contorts curated presets for a rendering concern, and the redundancy returns on the next edit); and leaving it silent, declined by the owner once the trade-off was put to them directly.](<redacted>.md) | provisioning / starter bundles / owner-facing copy |
 | 0262 | [**A bug never lands in the inbox: the system names the home the reporter didn't** ([task 1003691](https://cloudbongos.com/builders#/task/1003691) · goal 1000086 — *Strict versioning*). `routing.js` returned early on a goal-less filing, so its own `kind='bug'` hard-land branch was UNREACHABLE without a goal — `kind` only ever chose a routed task's STATUS, never whether it routed — and a reported defect sat in `idea_inbox` awaiting the triage pass criterion C1 exists to remove. The premise that [ADR 0250](<redacted>.md) D4 and [ADR 0235](<redacted>.md) contradict each other is FALSE: 0235's exemption is an advisory silence in `goal-advisory.adviseGoal`, and its actual decision already requires a real `goal_id`. So nothing is amended; this is the explicit decision 0235 §6 said would be needed. **D1** a homeless bug gets the version's MAINTENANCE goal (R18's design), find-or-created under an advisory lock inside the route's own transaction — not the catch-all R11 is deleting, and adding no `allowCatchAll` caller. **D2** the gate is the VECTOR (`api`, `discord-bugs`), not the kind: `#ideas` passes no kind, so the classifier guesses one from keywords, and gating on kind alone would silently overturn [ADR 0234](<redacted>.md)'s owner-interview decision. Rejected: goal-less bug tasks (breaks D4 a day after it landed); rejecting the filing (Discord cannot retry, so the report is lost); the catch-all (repopulates the bucket being drained); building R18 whole first.](<redacted>.md) | work intake / idea routing / the version-goal invariant |
+| 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 |

package/docs/module-api-changelog.md

@@ -1623,5 +1623,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.585 with no explicit bump. run 34167072966. (task 1002620)
   1.19.587 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.586 with no explicit bump. run 34172785860. (task 1002620)
+  1.19.588 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.587 with no explicit bump. run 34178696372. (task 1002620)
+  1.19.589 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.588 with no explicit bump. run 34179479729. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.587",
+  "version": "1.19.589",
   "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/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.587'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.589'; // 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');