@bongos/core 1.19.527 → 1.19.529

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.527",
-  "core_contract": "1.19.527",
-  "source_commit": "2ba9b8a5084d24406c9f56813939dd3abd17aac3",
+  "core_version": "1.19.529",
+  "core_contract": "1.19.529",
+  "source_commit": "80d814daa7174fe0e760966095ee9339a29d7d1d",
   "source_ref": "HEAD",
-  "built_at": "2026-09-04T01:56:03.997Z",
+  "built_at": "2026-09-04T13:17:35.687Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 434,
+    "docs_redacted": 435,
     "agent_docs_stubbed": 24,
-    "functional_verbatim": 1975,
+    "functional_verbatim": 1976,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2433,
-  "tree_sha256": "8864a6693cfc3aef15a04ae8938af1ff50dca2d6714eedc418c494739f486b57",
+  "file_count": 2435,
+  "tree_sha256": "a029bcb3e7adddef9f33b68cd23f96158ebb345a0b1a60e28dc8f2553809d595",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -387,7 +387,7 @@
     {
       "path": "clients/bongos-client/index.d.ts",
       "mode": "0000644",
-      "sha256": "80c6b676d869ddfe36311794a88028687eecb5dc5fbdb4789d64212894f38397"
+      "sha256": "ae23995907a851acd2b2dbae901280926e3041ce64e16407d47ed5ba998d7c74"
     },
     {
       "path": "clients/bongos-client/index.mjs",
@@ -1724,10 +1724,15 @@
       "mode": "0000644",
       "sha256": "4c6f98c2362a5b61e294f1b3b9b055d44a9e47743ef8a71e5cb0f40ddd187e98"
     },
+    {
+      "path": "docs/adr/0243-a-bundle-adjustment-belongs-to-the-bundle-not-the-advice-about-it.md",
+      "mode": "0000644",
+      "sha256": "17a0018cfa4f42364a1567bee6bc98f8cf84311ce8344b218d4de9eab870b496"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "b03da1a3085e208b68ab5728e97b0e06b7cfb399e74d776ecc32c29074cd2a79"
+      "sha256": "fb28cbf7bb03cc69deb895b5e25956a440449c11f1fd977ee09655116e3fc3b0"
     },
     {
       "path": "docs/api-reference.md",
@@ -1737,7 +1742,7 @@
     {
       "path": "docs/api/openapi.json",
       "mode": "0000644",
-      "sha256": "b1792ba4828a887a1bbd1ba14b13eba4dc428d1e3e1528cc23ddd6577e15b646"
+      "sha256": "46e8c08e1e7b5bfa6fe2e709308a466f3764ed320702c93dbe74d5523bb1d74b"
     },
     {
       "path": "docs/architecture.md",
@@ -1762,12 +1767,12 @@
     {
       "path": "docs/copy-inventory.md",
       "mode": "0000644",
-      "sha256": "e848eaf9b035df899cc6f6d80f98cb8b01c2e9079fc5f32db0dd7b3a73d107ef"
+      "sha256": "42f1210b3c422d2b05b719c38eabfb3ed25ed31988a757394dfc2caed045ee36"
     },
     {
       "path": "docs/copy-registry.json",
       "mode": "0000644",
-      "sha256": "d4fefb8fce99e3903eec6f0796c9e61b81732a9784fb95fa4a3299fa9da3278a"
+      "sha256": "0d9a040a9bac5670b2034e98479d86706070853dbb65b799d770b76e488534a6"
     },
     {
       "path": "docs/design/apex-pass-2-direction.md",
@@ -2612,7 +2617,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "3fc93c649eb03183fdb896888121536f092f896aa26d203371968340ea2d8149"
+      "sha256": "8a6ba922b7918d974e9374510472ce2a67c28790e60875b36efe7ceccda84e2f"
     },
     {
       "path": "docs/modules-contract.md",
@@ -4417,7 +4422,7 @@
     {
       "path": "modules/grading/grader-subagent.js",
       "mode": "0000644",
-      "sha256": "2f8d48c2eace701ef6e4c256be74a0893e45476eb46b20763a442e9dc6c21214"
+      "sha256": "8a100cca2391e018cf257e178c253cb21f514a07abda1a8f07da754b76aa83ad"
     },
     {
       "path": "modules/grading/grader-workers/efficiency.js",
@@ -4472,7 +4477,7 @@
     {
       "path": "modules/grading/grader.js",
       "mode": "0000644",
-      "sha256": "53001adcb058742f39bdb475fca023809c239f50bf9dddc61ccef966d5d01d6a"
+      "sha256": "4c664f5080513169c35369e5406f32efa64ce24259fefc47f527a94ff8001b1f"
     },
     {
       "path": "modules/grading/module.json",
@@ -5257,7 +5262,7 @@
     {
       "path": "modules/lifecycle/cascade.js",
       "mode": "0000644",
-      "sha256": "dcfbe3bf4cb7fc2731991d94cfac509ccd25f56f3c14c81aada1680c907bb0fb"
+      "sha256": "2192c61c606a37b4782db0646242ac969bcd318d4305b1247adf028b14f2e484"
     },
     {
       "path": "modules/lifecycle/claim-eligibility.js",
@@ -5627,7 +5632,7 @@
     {
       "path": "modules/lifecycle/tests/cascade.mjs",
       "mode": "0000644",
-      "sha256": "e932d203a4306a7d8dfe16301a6481a31f34b431a6eaa44c055c3d1a2a67c4b0"
+      "sha256": "af00ee4629002c8df2448e2146a24108407a36b062859ee1afee293aa60cb209"
     },
     {
       "path": "modules/lifecycle/version-close.js",
@@ -6057,17 +6062,17 @@
     {
       "path": "modules/provisioning/recommendations.js",
       "mode": "0000644",
-      "sha256": "8c4b2d8d17b80229c371b82ac9a5a2cf2fa979683ac586e8b833ca0a309a92fc"
+      "sha256": "4c933aad1307378496d47960e24c9d797a1f122f28aefa27b769f336e4cf2e75"
     },
     {
       "path": "modules/provisioning/routes/provisioning.js",
       "mode": "0000644",
-      "sha256": "6e78e87a2112974db6db804280c346daa7c38684adace638e3c5734fe6d1ca72"
+      "sha256": "69ec9994c833b54466fa0e83a3aa2c09eada6b0aefadf73e6eb50b085996aaa6"
     },
     {
       "path": "modules/provisioning/starter-bundles.js",
       "mode": "0000644",
-      "sha256": "9dd1fe5bd16d22245d62dae05aefb0c74c82772a937da155f1e8d2403f911886"
+      "sha256": "78cdbb14f2dc911d78d1dd7e1ae73027734e94a3bbd8826b2f27e343a2daba1d"
     },
     {
       "path": "modules/provisioning/tests/liveness.mjs",
@@ -6577,7 +6582,7 @@
     {
       "path": "modules/public-landing/public/projects.html",
       "mode": "0000644",
-      "sha256": "a93dbf381a39bde8d4424bd3f241d24a72d9ed915e7da48bdb125d15085f6fef"
+      "sha256": "7147ff51b2eaa3487557fff35f4fc7c3e4f6164fd8054e41c76064bcfe932e08"
     },
     {
       "path": "modules/public-landing/public/projects.probes.json",
@@ -7322,12 +7327,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "dc5f5840b004b4b41aad0c07fdc120a887bad3dce2824cea30e5e54da61400d6"
+      "sha256": "43ac8c190119cd19cbd7884c854dd616d4dce8947f9435367acbf04c3058d7b1"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "4b3a6ce000af625608a1cd4362413e7a57f409ab5cac66b05e7fafa98759e09c"
+      "sha256": "9baba915b700faa5eda5733b68bffd4aaeaa54b5a3076502440c39a944944f3d"
     },
     {
       "path": "public-docs/index.html",
@@ -9007,7 +9012,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "b1507f297c0f31d4df05c3826028c841d188eb75a824db8ed7ef1d53a4472b58"
+      "sha256": "532e7d3dc98b5ff136f1cb7484232b17f2f3c750dad15315493224b2619ef78f"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -10389,6 +10394,11 @@
       "mode": "0000644",
       "sha256": "50a785eb6e2c71d5a043c2ec2c37a835777da6397dac3ffc2542acdde14b57a8"
     },
+    {
+      "path": "tests/grader_root_outage.mjs",
+      "mode": "0000644",
+      "sha256": "409b21de4ac729cf90c792be28fcc358349e80dca67e47255a0105377d2cfcf8"
+    },
     {
       "path": "tests/grader_severity_gate.mjs",
       "mode": "0000644",
@@ -11232,7 +11242,7 @@
     {
       "path": "tests/projects_hub_module_picker.mjs",
       "mode": "0000644",
-      "sha256": "5eaa61295f2a22f5b10cb365cee58e485390ccb763a14be15fec00f23aa23087"
+      "sha256": "55b7912d1985ea1e02874b479c9d0453c25df48bfad6287ba9402df50326d6ed"
     },
     {
       "path": "tests/projects_hub_pre_uat.mjs",
@@ -11322,7 +11332,7 @@
     {
       "path": "tests/provisioning_starter_bundles.mjs",
       "mode": "0000644",
-      "sha256": "9ecf7cda8e47a6e17bbc73afdb0c30c867ab967cea66943082cbe15502fd63bc"
+      "sha256": "b63751ddf17d58ec3fdfdbd19c9f9a7569eed1ca9ff157a2a37f7034151eead7"
     },
     {
       "path": "tests/provisioning_teardown_intent.mjs",

package/clients/bongos-client/index.d.ts

@@ -172,7 +172,7 @@ export interface PatchMeSoundPrefsResponse { prefs: unknown; effective: unknown;
 export interface PatchProjectsIdFeaturedRequest { featured: boolean }
 export interface PatchProjectsIdFeaturedResponse { project: unknown }
 export interface PatchProvisioningInstancesIdDetailRequest { description?: string; detail?: Record<string, unknown> }
-export interface PatchProvisioningInstancesIdDetailResponse { ok: boolean; description: unknown; detail: unknown; options: unknown; publish: unknown }
+export interface PatchProvisioningInstancesIdDetailResponse { ok: boolean; description: unknown; detail: unknown; options: unknown; publish: unknown; modules: unknown }
 export interface PatchProvisioningInstancesIdSettingsResponse { ok: boolean; saved: unknown; planet: unknown; push: unknown }
 export interface PatchTaskRecommendationsIdRequest { status: "declined" | "withdrawn" }
 export interface PatchTaskRecommendationsIdResponse { ok: boolean; recommendation: unknown }

package/docs/adr/0243-a-bundle-adjustment-belongs-to-the-bundle-not-the-advice-about-it.md

@@ -0,0 +1,159 @@
+# 0243 — A bundle adjustment belongs to the bundle, not to the advice about it
+
+- **Status:** Accepted
+- **Date:** 2026-09-03
+- **Tasks:** [#1002341](https://cloudbongos.com/builders#/task/1002341) (this decision — BV1.R22)
+- **Goal:** [#1000046](https://cloudbongos.com/builders#/goal/1000046) — Project creation, criterion
+  `proj-module-select` ("during setup a default set of modules is pre-selected…")
+- **Related:** [ADR 0237](<redacted>.md)
+  (R19 — the per-type presets, and the file that said the bundle layer "is a declaration and not a rule
+  engine"), [ADR 0239](<redacted>.md) (R17 — the rule
+  engine, and the `TEAM_SHAPE_RULES` table this moves), [ADR 0240](<redacted>.md)
+  (R20 — the picker, the nullable `modules` column, and §2's "one function, called twice" property this
+  is written to preserve), [ADR 0083](<redacted>.md) (the one-way
+  import rule)
+
+## 1. The problem
+
+R17 built a rule engine and R20 built a picker, and nothing connected them. The
+picker preselected `bundleForProjectType(type).bundle` — the type's raw preset —
+while `GET /provisioning/recommendations` separately applied `TEAM_SHAPE_RULES`
+to that same preset and returned a different, better answer that no surface
+rendered. R22 is the join: **surface the recommended modules inside the picker.**
+
+Doing it the obvious way breaks the property R20 was built on. ADR 0240 §2:
+
+> Skipping is safe because the preselect and the fallback are the same
+> declaration. […] Not two lists kept in agreement — one function, called twice.
+
+If the picker applies the team-shape rules and `effectiveModules` does not, then
+an owner who answers the interview, sees the panel preselect `discord`, and skips
+the picker gets a project **without** `discord`. The panel's promise — "skip it
+and you get the suggested set below" — stops being true at exactly the moment the
+interview is answered, which is the moment it starts mattering.
+
+## 2. The rules move to the bundle layer
+
+`TEAM_SHAPE_RULES` leaves `recommendations.js` for `starter-bundles.js`.
+`recommendations.js` re-exports it, so its public surface is unchanged.
+
+The reasoning is a distinction, not a preference. **A bundle adjustment is not
+advice about the bundle — it IS the bundle, once the owner has answered.** The
+three tables R17 shipped together are not the same kind of thing:
+
+| table | what it produces | applied? | home |
+|---|---|---|---|
+| `TEAM_SHAPE_RULES` | the modules a project actually ends up with | **yes**, on read | `starter-bundles.js` |
+| `GOVERNANCE_RULES` | a preset name + one sentence, `applied: false` | never | `recommendations.js` |
+| `INVITE_RULES` | a `seeking` seam for R28 to fill | never | `recommendations.js` |
+
+Governance and invites are genuinely advice: nothing in the system silently ends
+up living under a governance preset. A module set is the opposite — it is what a
+project *has*, resolved at read time for every row that never answered the
+picker. A rule that decides that belongs where the resolution happens.
+
+So: `adjustBundle` and the new `bundleForAnswers(type, teamShape)` sit at the
+bundle layer, `effectiveModules` calls `bundleForAnswers` instead of
+`bundleForProjectType`, and `recommendationsForDetails` calls the same resolver.
+One function, still called twice — now with the interview's answer inside it.
+
+## 3. `effectiveModules` reads `detail.team_shape` off the row
+
+The fallback needs the interview's answer, and the answer already lives on the
+row (`detail`, `provisioning_013`). It is read **straight off the row**, not
+through `provisioning.js`'s `normalizeProjectDetail`, for two reasons:
+
+- Importing it would point `starter-bundles.js` **up** at the module that
+  requires it — `recommendations.js` already imports `PROJECT_DETAIL_VOCAB` from
+  `provisioning.js`, and the bundle layer sits below both.
+- It would buy nothing. An off-vocabulary shape matches no rule and adjusts
+  nothing, which is precisely the answer the normalizer would have produced.
+
+`RULED_TEAM_SHAPES` is derived from the rule table itself for the same reason.
+`tests/provisioning_recommendations.mjs` pins it against `PROJECT_DETAIL_VOCAB`
+so a fourth interview answer cannot arrive unhandled.
+
+`effectiveModules` also gains `adjustments` — why the unanswered set is what it
+is, in the owner's own words. It is `[]` for a `chosen` set: an owner's own
+toggle needs no reason given back to them.
+
+## 4. The whole answer table arrives in one read
+
+`GET /provisioning/starter-bundles` already served `core`, `bundles` and
+`optional` together, because (ADR 0240 §4) a picker that fetched its preselect
+and its catalog separately could preselect a key it has no row for. Each bundle
+now also carries `byTeamShape` — the same bundle re-resolved for every answer the
+rules can fire on, each with the `adjustments` that got it there.
+
+It rides this payload rather than a second read of `/provisioning/recommendations`
+for the reason `optional` does. The owner flips the type question and the
+team-shape question freely on two **earlier** panels; re-preselecting must not
+cost a round trip, and a round trip it did pay could land after they had moved
+on, or paint a module the panel has no row for. Five types by three ruled shapes,
+plus each type's no-answer resolution, is twenty small rows — the whole preselect
+table in one read of one declaration, computed purely.
+
+## 5. The effect comes back with the cause
+
+`PATCH /provisioning/instances/:id/detail` now returns `modules:
+effectiveModules(updated)` alongside the `publish` verdict it already returned,
+and for the same reason. Changing `team_shape` **moves the modules** of any
+project whose owner never answered the picker (`source: 'bundle'`). An owner who
+edits one answer and is told nothing about the other thing it changed would have
+to go looking. A project with `source: 'chosen'` is unmoved and says so.
+
+## 6. The panel says why
+
+The picker renders one line per adjustment that actually fired, above the
+always-on clause. ADR 0239 already made every rule carry its own `reason`
+sentence; this is the first surface that shows one.
+
+Two rules on when it appears, both from ADR 0239's delta principle:
+
+- **Only rules that changed something.** A rule whose module the bundle already
+  carried records nothing — "we switched discord on because you said community"
+  over a module a game would have had anyway is a claim the owner can check and
+  find false.
+- **Only before the owner has answered.** Once `state.modules` is set, the
+  reasons go away: a reason given back for a toggle they flipped themselves reads
+  as the panel arguing with them.
+
+The block wears `.reassure`'s weight deliberately. This is the panel explaining
+itself, never a thing to act on, so it must not compete with the toggles it is
+explaining. A preselect an owner cannot see the reason for is one they have to
+audit, which ADR 0237 calls worse than no preselect at all.
+
+## 7. Consequences
+
+- **An adjusted bundle is returned in CATALOG order**, not append order.
+  `normalizeModuleSelection` stores a chosen set that way and the picker
+  re-derives its toggles that way, so an adjusted bundle that appended would make
+  the same set of modules read as a different list depending on whether the owner
+  answered the picker or skipped it.
+- **A stale client degrades to the R20 answer.** A payload without `byTeamShape`,
+  or a team shape no rule fires on, falls through to the unadjusted bundle — the
+  answer this panel gave before R22, which is never wrong, only untailored.
+- **The rules now run on every read of a bundle-sourced row**, not just on the
+  recommendations route. They are pure, frozen and three rows long, so this costs
+  nothing; it is noted because the blast radius genuinely grew.
+- **Still no new storage.** ADR 0240's three-valued column is untouched, and a
+  skipped picker still stores nothing. The adjustment is resolved, never written.
+
+## 8. Rejected
+
+- **Leaving the rules in `recommendations.js` and having the picker call
+  `/recommendations`** — the two-lists-by-hand failure ADR 0240 §2 exists to make
+  impossible, plus a round trip on every keystroke of two earlier panels that
+  could land after the owner moved on.
+- **Teaching `effectiveModules` to import `normalizeProjectDetail`** — points the
+  bundle layer up at the module that requires it (ADR 0083's one-way rule), to
+  buy an answer it already has.
+- **Storing the adjusted bundle when the owner skips** — ADR 0240 §7 rejected
+  this for the raw preset and every word still applies: it writes down an answer
+  nobody gave, and freezes today's rules onto a project whose owner never
+  expressed a view.
+- **Moving governance and invites down with the bundle rules** — they are never
+  applied, so there is no resolution for them to stay in agreement with. Moving
+  them would be tidiness at the cost of the distinction that makes §2 true.
+- **A reason line per matched condition rather than per actual change** — ADR
+  0239's delta rule, restated at the surface that renders it.

package/docs/adr/README.md

@@ -330,5 +330,6 @@ This keeps the decision history honest and traceable.
 | 0240 | [**A skipped module picker stores nothing, and the bundle is resolved on read** ([task 1002339](https://cloudbongos.com/builders#/task/1002339) · goal 1000046, criterion `proj-module-select`). [ADR 0237](<redacted>.md) declared the starter bundles and closed with "where a chosen selection lands is R20's decision". It lands in a new **nullable** `modules jsonb` column on `provisioning_instances` (`provisioning_014`), read through `starter-bundles.effectiveModules(row)` and **three-valued**: `NULL` = nobody answered (the picker was skipped, or the caller does not ask) and the declared type's bundle is resolved AT READ TIME; `[]` = the owner switched them all off, a real answer; `["dev-box",…]` = what they picked. `NOT NULL DEFAULT '[]'` was rejected because it collapses the first two forever — the `PROJECT_DETAIL_VOCAB` rule ("absent stays absent, skipped stays skipped") applied to a list. **Skipping is safe because the preselect and the fallback are the same function**, `bundleForProjectType`, called twice — not two lists kept in agreement — so `bongos onboard` and any API caller inherit the bundle by omitting the field, and the canonical sequence in `onboard-plan.js` grows **no new step** (the picker refines `type`, an answer already in it). NOT `detail` (its vocabulary is closed + scalar by construction, and [ADR 0237](<redacted>.md) §2 ruled the interview must not ask this) and NOT `settings` (a setting is a policy the RUNNING instance obeys — web.env, a settings-apply intent, a restart). The picker's catalog copy (`OPTIONAL_MODULES`) is **declared beside the bundles**, because `module.json` descriptions are written for builders, `GET /modules` needs a session the signed-out wizard has not got, and `GET /public/modules` serves booleans — pinned the ADR 0237 way, so a new `default: false` module cannot ship without owner-facing copy. `GET /provisioning/starter-bundles` gains `optional` so the preselect and the catalog arrive in **one** read. The route **refuses** an unknown / always-on / hub-only key (`400 bad_modules`) rather than dropping it silently (`badProjectDetail`'s rule), and a re-request reports `modules_ignored`. The column is a DECLARATION, not yet an input to the control-plane runner. Rejected: storing the preselect on a skip (it writes down an answer nobody gave), a new `onboardPlan` step, and rendering the always-on core as sixteen disabled toggles (a disabled control reads as a choice the owner failed to make).](<redacted>.md) | provisioning / project creation |
 | 0241 | [**The artist gate holds the DEPLOY, not the ship, and it reads a state rather than a judgement** ([task 1003116](https://cloudbongos.com/builders#/task/1003116) · goal 1000074, criterion `artist-blocking-is-per-project` — R05, the DECISION task the goal placed before R04 so no code would be wired to an unsettled gate). Goal 1000074 carries two rules on a collision course: the owner's "blocking strictness is PER PROJECT, not global", and [ADR 0162](<redacted>.md), which retired review gates on `main` after a code-owner requirement stranded two graded-PASS ships in a day. **0162 is usually cited by a paraphrase — "a verdict is advisory, never self-executing" — and the paraphrase is wrong as a blanket claim:** 0162's own table of compensating controls marks three of four as *fails closed*, the subagent grader among them. What it actually retired was a gate GitHub could only express as ACCOUNTS — identity-pinned against [ADR 0016](<redacted>.md), and stranding with no escape hatch. So the surviving test is: **a gate is admissible when it is evaluated automatically from readable state, consistently for every builder, with a named escape hatch; inadmissible when a particular person must act and it stalls when they do not.** Decision: (1) the gate reads a **STATE** — "is there an unresolved artist review task?" — never an opinion, so the artist's judgement is what they write INTO the task and stays advisory in exactly 0162's sense, while what the system reads is ordinary GDS status; (2) strictness is a project setting `artist_gate ∈ off | advisory | strict` and at `strict` it holds the **DEPLOY, not the ship** (owner ruling) — the builder's work is graded, merged, credited and landed on CI alone exactly as today, so 0162's strand class cannot recur, and the gate attaches to the boundary the artist's ABI mandate is actually about (users see the deployed instance, not `main`; [ADR 0137](<redacted>.md) already splits land/release/deploy); (3) the escape hatch is the **project OWNER only** — not the builder, not any Metic+, not the artist — via the existing `POST /tasks/:id/override-request`, because a person can be both artist and builder and could pass their own work; a self-release is permitted but never quiet (required rationale, audit-logged as a self-override) so a solo instance cannot deadlock; (4) the default is **`strict`** (owner ruling, against the author's `advisory` recommendation), which is safe only because §2 holds the deploy — the worst case is a pin that waits, and this instance is included once R04 ships; a project with no artist must still be able to deploy, and the refusal must name what holds it and which control releases it; (5) tightening is **not retroactive** — re-gating history would strand the next deploy behind reviews for work nobody remembers and make the setting frightening to raise; R02's flag queue is the right tool for already-shipped copy. Rejected: blocking the ship (recreates 0162's incident exactly, with credits unpaid — [ADR 0120](<redacted>.md)); advisory at every level (configures nothing); any Metic+ as the hatch (makes `strict` indistinguishable from `advisory`); making the artist's VERDICT the gate (the one thing 0162 genuinely forbids); retroactive tightening; a global constant (ruled out by the owner's constraint by name).](<redacted>.md) | goal 1000074 / the artist's loop |
 | 0242 | [**A cross-role cascade is a declaration table on the event that already exists** ([task 1003549](https://cloudbongos.com/builders#/task/1003549) · goal 1000074, criterion `artist-review-task-on-ship` — the split R04 invited in its own brief and [ADR 0241](<redacted>.md)'s dependency). R04 needs "every ship with copy or visuals GENERATES one", and its brief said the infrastructure did not exist, naming the spark queue as the prototype. Reading both surfaces shows the prototype is the wrong half: the spark queue ([task 1002921](https://cloudbongos.com/builders#/task/1002921)) and the copy-desk flag queue ([task 1003113](https://cloudbongos.com/builders#/task/1003113)) are both **PULL** — filtered listings of rows another role already created — and nothing anywhere generated work on a state transition, which is the **PUSH** R04 asks for. (`cascade-dispatch.js` is model-cost routing; named only because its name has misled more than one reader.) **Decision: no new bus.** The kernel seam registry's own header uses this exact scenario as its worked example, `task.shipped` is already emitted post-commit by both ship paths and already has two consumers (discord's broadcast, sessions' deferred reward) — so a cascade is ONE MORE LISTENER on it, registered in `routes/lifecycle.js` beside the port because that mount is the one boot hook tests also run. A cascade is a frozen entry `{ key, discipline, when(task), title(task), body(task) }` — **a declaration table, not a rules engine**: no condition language, no stored rules, no per-project config, no priority ordering; adding one appends an entry and the runner does not change (the [ADR 0237](<redacted>.md)/[0239](<redacted>.md) shape, for their reason — the generalisations worth building are the ones two or three real entries have shown they share). **`CASCADES` ships EMPTY and R04 writes the first rule**, asserted so the emptiness is a decision on the record; the mechanism is proved against the tests' own declarations rather than against its first consumer's shape. Four load-bearing properties, all pinned: (1) **it can never fail the ship it reacts to** — post-commit event, isolated listeners, and a runner that catches everything and returns a report, because ADR 0241 settled that an artist may hold a DEPLOY and never a builder's SHIP and a generator that could fail a ship would smuggle that gate back in; verified against a real failure (no database reachable → one log line, resolves); (2) **idempotent on machinery that already exists** — `source: 'cascade'` + `source_ref: cascade-<key>-<taskId>` through `createTask`'s `(source, source_ref)` read, the same one a copy proposal uses ([ADR 0233](<redacted>.md)), so a reconciler re-sweep or a double emit is a no-op; (3) **it says where it came from** — inherits `goal_id`/`version_id`, carries the origin id in the ref and the prose, but NOT `parent_task_id`, which models a SUBTASK, and cascaded work is not part of the ship that triggered it; (4) **files at `backlog`, never `ready`** — generated work is a request, and auto-filing claimable work would let a rule nobody re-read mint claims. A rule key is PERMANENT (half the source_ref; renaming re-files everything it ever generated), pinned by a duplicate-key check. The mechanism is discipline-agnostic — an ideator or engineer cascade is the same entry with a different `discipline`, which is the generalisation that made this its own task. Accepted limit: cascades are declared in code, not configured per project. Rejected: extending the spark queue (a read-side filter that generates nothing), a new event or poller, a rules engine or per-project config, filing at `ready`, `parent_task_id` as the link, and running the cascade inside the ship transaction (which would make a generation failure a ship failure — the exact coupling ADR 0241 rules out).](<redacted>.md) | goal 1000074 / the artist's loop |
+| 0243 | [**A bundle adjustment belongs to the bundle, not to the advice about it** ([task 1002341](https://cloudbongos.com/builders#/task/1002341) · goal 1000046, criterion `proj-module-select`). R17 ([ADR 0239](<redacted>.md)) built a rule engine and R20 ([ADR 0240](<redacted>.md)) built a picker, and nothing connected them: the picker preselected the type's RAW preset while `GET /provisioning/recommendations` separately applied `TEAM_SHAPE_RULES` to that same preset and returned a better answer no surface rendered. Joining them the obvious way — let the picker apply the rules — breaks the property R20 was built on ([ADR 0240](<redacted>.md) §2: the preselect and the fallback are "one function, called twice"), because an owner who answers the interview, watches the panel preselect `discord`, and then SKIPS the picker would get a project without it. **Decision: `TEAM_SHAPE_RULES` moves from `recommendations.js` down to `starter-bundles.js`** (re-exported, so the public surface is unchanged), `effectiveModules` resolves through the new `bundleForAnswers(type, teamShape)`, and the picker reads the same table the fallback does. The distinction is not a preference: a bundle adjustment is not advice ABOUT the bundle — it IS the bundle once the owner has answered, and it is the only one of R17's three tables that is ever APPLIED (governance is a preview carrying `applied: false`, invites are a seam for R28), so it is the only one that has to live where the resolution happens. `effectiveModules` reads `detail.team_shape` straight off the row rather than through `normalizeProjectDetail` — importing it would point the bundle layer UP at the module that requires it ([ADR 0083](<redacted>.md)) to buy an answer it already has, since an off-vocabulary shape fires no rule and adjusts nothing. `GET /provisioning/starter-bundles` gains `byTeamShape`: every bundle re-resolved for every ruled answer, with the `adjustments` that got it there — twenty small rows, the whole preselect table in ONE read, for the reason `optional` rides the same payload (the owner flips type and team-shape on two EARLIER panels, and a refetch could land after they moved on or paint a key the panel has no row for). `PATCH /provisioning/instances/:id/detail` returns `modules: effectiveModules(updated)` beside its `publish` verdict and for the same reason — changing `team_shape` MOVES the modules of a `source: 'bundle'` project, so the effect comes back with the cause. The panel renders one reason line per adjustment that ACTUALLY fired, and only while the owner has not answered for themselves (a reason handed back for a toggle they flipped reads as the panel arguing with them). An adjusted bundle returns in CATALOG order, never append order, or the same set of modules would read as a different list depending on whether the picker was answered or skipped; a payload without `byTeamShape` degrades to the R20 answer, which is never wrong, only untailored. No new storage — the adjustment is resolved, never written. Rejected: leaving the rules up in `recommendations.js` and having the picker call `/recommendations` (two lists kept in agreement by hand, plus a round trip per keystroke); importing `normalizeProjectDetail`; storing the adjusted bundle on a skip (it writes down an answer nobody gave); moving governance and invites down too (they are never applied, so there is nothing for them to stay in agreement with); and a reason line per matched condition rather than per actual change.](<redacted>.md) | provisioning / project creation |
 
 > ⚠️ **Numbering collisions are now machine-enforced, not narrated.** Twenty numbers are shared by two ADRs each — assigned in parallel sessions before anything checked. The files keep their filenames (renumbering would break every existing citation, and a number once assigned is never reused), and this table disambiguates each pair as `NNNN-a` / `NNNN-b`. The authoritative list is `LEGACY_DUPLICATE_ADRS` in [`scripts/gds/adr-namespace.js`](../../scripts/gds/adr-namespace.js), frozen by exact filename: a **new** collision — or a third file joining a legacy number, or a rename of either half — hard-fails the `unit` CI gate, as does an index row that points at no file or an ADR with no row. The list may only shrink. This paragraph used to narrate the collisions one by one and had fallen eight behind reality; see [ADR 0195](<redacted>.md) for why the check exists and why the pairs are grandfathered rather than renumbered.

package/docs/api/openapi.json

@@ -12014,7 +12014,7 @@
           "provisioning"
         ],
         "summary": "GET /provisioning/starter-bundles",
-        "description": "GET /provisioning/starter-bundles — the curated module preset for each declared project type (BV1.R19, task 1002338; goal 1000046 criterion `proj-module-select`). Returns the always-on core once, then one resolved bundle per type: `{ type, label, summary, core, bundle, modules }`. The whole table in one read, because the creation picker (R20, task 1002339) re-preselects as the owner flips the type question and must not refetch to do it; R17's rule engine reads the same shape so a recommendation and a preselect can never name different modules. A DECLARATION, not a query — modules/provisioning/starter-bundles.js is pure, so this route touches no database and no per-request state. rank: public — the signed-out hub wizard (/projects?view=new) reads it while choosing a type, exactly like onboard-plan above; no write, no secret, and the module catalog it names is already public at GET /public/modules. `optional` joined the payload for R20's picker (task 1002339): the opt-in catalog with the owner-facing label + one-line summary each row renders. It lives here rather than at a module-catalog route because the two things a picker needs — what is preselected and what may be chosen — have to arrive in ONE read of ONE declaration, or the panel can preselect a key it has no row for. The alternatives were both worse: `GET /modules` needs a session (this wizard is read signed-out) and `GET /public/modules` serves booleans, not copy. Additive — `core` and `bundles` keep their shape.\n\n**Rank:** `public` — No authentication — any caller.",
+        "description": "GET /provisioning/starter-bundles — the curated module preset for each declared project type (BV1.R19, task 1002338; goal 1000046 criterion `proj-module-select`). Returns the always-on core once, then one resolved bundle per type: `{ type, label, summary, core, bundle, modules }`. The whole table in one read, because the creation picker (R20, task 1002339) re-preselects as the owner flips the type question and must not refetch to do it; R17's rule engine reads the same shape so a recommendation and a preselect can never name different modules. A DECLARATION, not a query — modules/provisioning/starter-bundles.js is pure, so this route touches no database and no per-request state. rank: public — the signed-out hub wizard (/projects?view=new) reads it while choosing a type, exactly like onboard-plan above; no write, no secret, and the module catalog it names is already public at GET /public/modules. `optional` joined the payload for R20's picker (task 1002339): the opt-in catalog with the owner-facing label + one-line summary each row renders. It lives here rather than at a module-catalog route because the two things a picker needs — what is preselected and what may be chosen — have to arrive in ONE read of ONE declaration, or the panel can preselect a key it has no row for. The alternatives were both worse: `GET /modules` needs a session (this wizard is read signed-out) and `GET /public/modules` serves booleans, not copy. Additive — `core` and `bundles` keep their shape. `byTeamShape` re-resolves each bundle for every answer the About step can give, riding THIS payload rather than a second read (task 1002341; ADR 0243 §4).\n\n**Rank:** `public` — No authentication — any caller.",
         "x-rank": "public",
         "x-source": "modules/provisioning/routes/provisioning.js",
         "responses": {
@@ -18250,14 +18250,16 @@
           "description": {},
           "detail": {},
           "options": {},
-          "publish": {}
+          "publish": {},
+          "modules": {}
         },
         "required": [
           "ok",
           "description",
           "detail",
           "options",
-          "publish"
+          "publish",
+          "modules"
         ]
       },
       "PatchProvisioningInstancesIdSettingsResponse": {