@bongos/core 1.21.175 → 1.21.177

package/docs/handoff-template.md

@@ -1,6 +1,6 @@
 # Session-end handoff — template
 
-> **Use this at the end of every working session.** Write your entry as its own dated file `docs/session-logs/YYYY-MM-DD-<slug>.md`. Soft cap: ~400 words per entry. The next Claude session — or the next human — should be able to pick up cold from this. **You never touch an index by hand:** the CLAUDE.md §13 recent-sessions snippet and the full `docs/session-log-index.md` are generated from the files and regenerate at ship (`scripts/gds/gen-session-index.js`).
+> **Use this at the end of every working session.** Write your entry as its own dated file `docs/session-logs/YYYY-MM-DD-<slug>.md`. Soft cap: ~400 words per entry. The next Claude session — or the next human — should be able to pick up cold from this. **You never touch an index by hand:** the CLAUDE.md §13 recent-sessions snippet and the full `docs/session-log-index.md` are generated from the files and regenerate at ship (`scripts/bongos/gen-session-index.js`).
 
 ---
 
@@ -26,12 +26,12 @@
 
 **New limitations / risks / blockers introduced this session:**
 - {new V1 architecture limitation → added to limitations/current-version.md}
-- {new ops gotcha → long-form recipe under docs/recipes/, OR short rule via `node scripts/gds/learning-capture.js`}
+- {new ops gotcha → long-form recipe under docs/recipes/, OR short rule via `node scripts/bongos/learning-capture.js`}
 - {new blocker for Lars → POST /api/bongos/blockers (the markdown file is frozen archive only)}
 - {(or "none")}
 
 **Generative ideas captured this session:**
-- {captured via `node scripts/gds/capture.js` (B2 idea_inbox), or "none". The markdown file is frozen archive only.}
+- {captured via `node scripts/bongos/capture.js` (B2 idea_inbox), or "none". The markdown file is frozen archive only.}
 
 **Decisions made (linked to ADRs):**
 - {NNNN — title} (or "none — no architectural decisions this session")
@@ -67,10 +67,10 @@ If even one of these is false, the claim is `[verified-smoke]` or `[implemented-
 
 If your change touched anything the onboarding diagrams describe — the **rank enum or which ranks are wired** (`requireRank`, `builders.rank` default, exit/assign paths), the **task-status set**, the **versions** (id/track/status), or the **complete-architecture** (the ADR 0024 memory chain + the machine → production ship flow) **/ example-karma** models (which now flip per the **shipped** status of their backing tasks) — then before shipping:
 
-- **All five diagrams are auto-generated** by `scripts/gds/gen-diagrams.js` — run it (`node scripts/gds/gen-diagrams.js`) and confirm the result looks right; **do not hand-edit any `.mmd`**. The mechanical three (`01-task-lifecycle`, `02-rank-ladder`, `05-versioning`) regenerate from migrations + the public version API. The conceptual two (`03-example-karma`, `04-architecture`) regenerate from the **authenticated** `/tasks/:id` status of their backing tasks (and 03's seeded-achievement count); if no session is present the generator skips them cleanly. Rendering produces both `.svg` (the pannable viewer asset) and `.png` (fallback).
+- **All five diagrams are auto-generated** by `scripts/bongos/gen-diagrams.js` — run it (`node scripts/bongos/gen-diagrams.js`) and confirm the result looks right; **do not hand-edit any `.mmd`**. The mechanical three (`01-task-lifecycle`, `02-rank-ladder`, `05-versioning`) regenerate from migrations + the public version API. The conceptual two (`03-example-karma`, `04-architecture`) regenerate from the **authenticated** `/tasks/:id` status of their backing tasks (and 03's seeded-achievement count); if no session is present the generator skips them cleanly. Rendering produces both `.svg` (the pannable viewer asset) and `.png` (fallback).
 - To change a diagram's **layout or wording**, edit the matching template function in `gen-diagrams.js` — not the `.mmd`. `assertions.json` is rebuilt by the generator in lockstep, so you don't hand-maintain it.
 
-The `diagram-drift` routine is a belt-and-braces backstop (it should find nothing once the generator has run), but the point is not to rely on it — running `gen-diagrams.js` is part of the change.
+There is no drift backstop (the `diagram-drift` routine was retired in task 1004878) — running `gen-diagrams.js` is part of the change.
 
 ---
 

package/docs/module-api-changelog.md

@@ -20,7 +20,7 @@ gating the repo again.
 or removing one. A MINOR or MAJOR is a deliberate human in-task edit — CI only ever
 bumps PATCH (ADR 0161 §2).
 
-**How the carrier writes here.** `scripts/gds/bump-version.js` inserts each new entry
+**How the carrier writes here.** `scripts/bongos/bump-version.js` inserts each new entry
 immediately **above the divider that closes the ledger** below — the same insertion
 contract the comment block used, so the ordering convention is unchanged. That divider
 is load-bearing: the script throws rather than guess if it is missing, and
@@ -303,7 +303,7 @@ is load-bearing: the script throws rather than guess if it is missing, and
   1.18.12 — docs-surface correctness: GDS→Bongos rename + standalone architecture redraw
         (task 1002374). Docs/prose + diagram generator only, no schema/doorway change → PATCH.
   1.18.13 — `bongos dev`: one-command LOCAL launcher for a standalone instance (task 1002397,
-        ADR 0149). New CLI verb + scripts/gds/dev.js + dev-lib.js so a freshly-created,
+        ADR 0149). New CLI verb + scripts/bongos/dev.js + dev-lib.js so a freshly-created,
         localhost-configured project stands up locally in one step. No schema/doorway change → PATCH.
   1.18.14 — module pollers actually start on a standalone instance (task 1002419). The loader's
         startModulePollers had ZERO callers once the game entrypoint server.js was retired, so
@@ -3186,6 +3186,10 @@ is load-bearing: the script throws rather than guess if it is missing, and
   1.21.174 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.21.173 with no explicit bump. run 40003024305. (task 1002620)
   1.21.175 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
-        landed since 1.21.174 with no explicit bump. run 40005506119. (task 1002620)
+        landed since 1.21.174 with no explicit bump. run 40234506483. (task 1002620)
+  1.21.176 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.21.175 with no explicit bump. run 40235567383. (task 1002620)
+  1.21.177 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.21.176 with no explicit bump. run 40241825861. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/docs/modules-contract.md

@@ -178,7 +178,7 @@ closed on every unknown, including a ledger read it cannot complete.
 
 **`bongos module list [--catalog] [--search <text>] [--json]`** ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §2/§3, [ADR 0167](adr/0167-module-catalog-source-vs-provenance.md)) is the browsable catalog from the terminal: every module on disk with its enabled state, its author + origin credit, and its upkeep posture. `--catalog` narrows to the **core-shipped** modules — the shared catalog an instance opts into (§6, default-off). Two axes travel on each row and they are *not* the same question: **`source`** (which tree ships it — the core package or this instance's own repo, read structurally from the loader's discovery root, [ADR 0108](adr/0108-instance-composition-configurable-root.md) §1) and **`provenance`** (who built it, derived from the declared `origin`). A core module that declares no attribution is credited to the platform and the credit is **marked inferred** (`*`) rather than left blank or silently invented. The hall's Modules tab renders the same model (`src/module-loader/catalog.js`) via `GET /modules`, so the two surfaces cannot drift.
 
-**`bongos module check <key> [--sign-off "Name <email>"]`** ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §4) is the submit-time pre-check a module must clear before it can be upstreamed. It reuses (never re-types) the public-mirror publish denylist (`scripts/gds/publish-manifest.js`'s `matchesDeny`) to reject content that cannot ship under AGPL (game content, pixel art, copyrighted reference material) — deliberately the DENY half only, since a brand-new module is never on the publish ALLOWLIST until it's accepted into core (§6). It also requires `module.json`'s `license` to be AGPL-3.0 (inbound = outbound) and a declared `maintenance` posture — acceptance is a commitment to upkeep, so a module with no `maintenance.status`, or one already `deprecated`/`orphaned`, is refused ([ADR 0166](adr/0166-module-maintenance-and-deprecation-policy.md); see below). On a pass, `--sign-off` records a lightweight DCO-style affirmation (own work, licensed AGPL-3.0 — never a copyright-assignment CLA) to `modules/<key>/.upstream-signoff.json`.
+**`bongos module check <key> [--sign-off "Name <email>"]`** ([ADR 0107](adr/0107-module-upstreaming-contribution-to-core-catalog.md) §4) is the submit-time pre-check a module must clear before it can be upstreamed. It reuses (never re-types) the public-mirror publish denylist (`scripts/bongos/publish-manifest.js`'s `matchesDeny`) to reject content that cannot ship under AGPL (game content, pixel art, copyrighted reference material) — deliberately the DENY half only, since a brand-new module is never on the publish ALLOWLIST until it's accepted into core (§6). It also requires `module.json`'s `license` to be AGPL-3.0 (inbound = outbound) and a declared `maintenance` posture — acceptance is a commitment to upkeep, so a module with no `maintenance.status`, or one already `deprecated`/`orphaned`, is refused ([ADR 0166](adr/0166-module-maintenance-and-deprecation-policy.md); see below). On a pass, `--sign-off` records a lightweight DCO-style affirmation (own work, licensed AGPL-3.0 — never a copyright-assignment CLA) to `modules/<key>/.upstream-signoff.json`.
 
 ### `maintenance` — who keeps this module true as the core advances ([ADR 0166](adr/0166-module-maintenance-and-deprecation-policy.md))
 
@@ -284,7 +284,7 @@ A module puts its SQL files under `modules/<key>/migrations/NNN_description.sql`
 
 Rules (enforced by the `BV1.R45` fitness check):
 - **Own your namespace** — every table must be prefixed `<key>_*`.
-- **Additive only** — `DROP TABLE`, `DROP COLUMN`, and destructive `ALTER` are rejected by the fitness check. **One acknowledged exception** (task 1003092): the *contract phase* of an expand-then-contract rename ([ADR 0177](adr/0177-goal-membership-kind.md)) may carry exactly `ALTER TABLE <own_table> DROP COLUMN <legacy>` when the file bears the same `-- forward-unsafe: <reason>` pragma core migrations use — one statement, one column, your own table; `DROP TABLE`, `TRUNCATE` and a bare `DROP CONSTRAINT` stay rejected even under the pragma (`scripts/gds/fitness-migration-contraction.js`).
+- **Additive only** — `DROP TABLE`, `DROP COLUMN`, and destructive `ALTER` are rejected by the fitness check. **One acknowledged exception** (task 1003092): the *contract phase* of an expand-then-contract rename ([ADR 0177](adr/0177-goal-membership-kind.md)) may carry exactly `ALTER TABLE <own_table> DROP COLUMN <legacy>` when the file bears the same `-- forward-unsafe: <reason>` pragma core migrations use — one statement, one column, your own table; `DROP TABLE`, `TRUNCATE` and a bare `DROP CONSTRAINT` stay rejected even under the pragma (`scripts/bongos/fitness-migration-contraction.js`).
 - **Disable preserves data** — there is no down-migration; a disabled module's tables simply are never created (or are left untouched).
 
 ---
@@ -380,11 +380,11 @@ Or via env: `<PREFIX>_MODULE_<KEY>=1`. The loader discovers and mounts it on nex
 
 ### 5. Verify
 
-Run `bongos upgrade` to confirm coreVersion compatibility, then `node scripts/gds/fitness.js` to confirm the boundary checks pass. The `unit` CI job runs fitness on every PR.
+Run `bongos upgrade` to confirm coreVersion compatibility, then `node scripts/bongos/fitness.js` to confirm the boundary checks pass. The `unit` CI job runs fitness on every PR.
 
 ### 6. Publish to the store (optional)
 
-`bongos module publish <key>` packs `modules/<key>/` as one version for the Bongos-hosted module store ([ADR 0338](adr/0338-modules-travel-through-a-bongos-hosted-store.md)): a tarball plus hash manifest in the core release's own format (`scripts/gds/module-artifact.js` over `artifact-format.js`), then uploads it to `POST /store/modules/:key/versions`. `--dry-run` packs without uploading; `--out <dir>` also writes the tarball and its manifest.
+`bongos module publish <key>` packs `modules/<key>/` as one version for the Bongos-hosted module store ([ADR 0338](adr/0338-modules-travel-through-a-bongos-hosted-store.md)): a tarball plus hash manifest in the core release's own format (`scripts/bongos/module-artifact.js` over `artifact-format.js`), then uploads it to `POST /store/modules/:key/versions`. `--dry-run` packs without uploading; `--out <dir>` also writes the tarball and its manifest.
 
 - The version is `module.json`'s `version`. Each version is published **once** and must be newer than the last — bump it to publish a fix.
 - Your first publish of a key makes you its author; only the author can publish later versions, and a delisted key takes none.
@@ -392,12 +392,13 @@ Run `bongos upgrade` to confirm coreVersion compatibility, then `node scripts/gd
 - **When a tester version reaches everyone** (task 1003804, [ADR 0344](adr/0344-a-tester-is-a-project-that-opts-in-once.md) D3; owner, 2026-10-23). A version on `tester` moves to `general` after **7 days**, or **from day 2** once **5 or more** testers report a clean install, as long as its Security gate has passed and its own tests pass (every test file, or no tests declared; ADR 0343). Any failed tester install or runtime error **holds** it on `tester` (reason `held_tester_errors`); a held version does not move at day 7, and only a Metic+ person releases it, with `POST /store/modules/:key/versions/:version/release { reason }` (the `module.delist` permission). A version is only ever held on evidence, so one nobody tests still moves at day 7. Each move is a new channel row: reason `promoted_after_7_days`, `promoted_early_clean_installs` or `released_by_person`, and `set_by` empty when the system moved it. An hourly sweep in the server applies the rule (`MODULE_PROMOTION_DISABLED=1` switches it off). `GET /store/modules/:key/versions/:version/channel` shows any signed-in builder a version's channel, who moved it and why, the rule in plain words and, on `tester`, the counts it is waiting on and the day it goes to everyone. The rule is `decidePromotion` in `src/bongos/module-promotion.js`.
 - The publish denylist applies (ADR 0098), plus a refusal of credential-named files (`.env*`, `*.pem`, `*.key`, `id_rsa`, …) anywhere in the module. The store re-checks every hash and the denylist itself.
 - Gate: Metic+ (`module.submit`) for now. This is not `bongos module submit`, which proposes a module *into* core.
-- **A how-to is required** ([ADR 0347](adr/0347-every-store-module-ships-a-how-to.md)). `modules/<key>/HOWTO.md` is what a buyer reads — the store shows it as the module's page — so it is written for the person who installs the module, not for an AI working inside it (that is `CLAUDE.md`). It is plain Markdown: any AI or person can write it. Publish refuses the version unless it has these five level-2 headings, in any order and any case, each with some text under it: `## What it does`, `## Install and enable`, `## How to use it` (with one worked example), `## Configuration` ("None." is fine) and `## Limits and known issues` ("None known." is fine). HTML comments don't count as text, so the scaffold's prompts must be replaced. The refusal names each failing section. The check is one function, `checkHowto` in `scripts/gds/module-artifact.js`; the CLI runs it before uploading and the store runs it again on upload, so a hand-built upload can't skip it. `bongos module check` reports it as advice only — an upstream submit is not gated by it. Install and update don't re-check it, so a version published before the gate still installs. The file travels in the tarball, so its hash pins it to the version. An optional `howto.artifactUrl` in `module.json` (an `https://` link on `claude.ai`) is shown as an extra, never graded.
+- **A how-to is required** ([ADR 0347](adr/0347-every-store-module-ships-a-how-to.md)). `modules/<key>/HOWTO.md` is what a buyer reads — the store shows it as the module's page — so it is written for the person who installs the module, not for an AI working inside it (that is `CLAUDE.md`). It is plain Markdown: any AI or person can write it. Publish refuses the version unless it has these five level-2 headings, in any order and any case, each with some text under it: `## What it does`, `## Install and enable`, `## How to use it` (with one worked example), `## Configuration` ("None." is fine) and `## Limits and known issues` ("None known." is fine). HTML comments don't count as text, so the scaffold's prompts must be replaced. The refusal names each failing section. The check is one function, `checkHowto` in `scripts/bongos/module-artifact.js`; the CLI runs it before uploading and the store runs it again on upload, so a hand-built upload can't skip it. `bongos module check` reports it as advice only — an upstream submit is not gated by it. Install and update don't re-check it, so a version published before the gate still installs. The file travels in the tarball, so its hash pins it to the version. An optional `howto.artifactUrl` in `module.json` (an `https://` link on `claude.ai`) is shown as an extra, never graded.
 - **Getting listed** (task 1003807, [ADR 0343](adr/0343-a-module-score-is-a-security-gate-then-an-average-of-visible-parts.md)). Publishing a version does not by itself put it in the store's catalog, `GET /store/modules`. The catalog shows each module's newest version, judged by its current score. It must pass the Security gate first; a version that failed it, or has not been checked yet, is not listed. A new version with no install or reliability data yet is listed with a **New** label and is not ranked; the floor does not apply to it until it has a real score. Every other version is listed only if its overall score is **at least 50 out of 100**. Below that it is not listed at all. The floor is fixed in Bongos itself (`QUALITY_FLOOR` in `src/bongos/module-listing.js`) and returned in the catalog response; no author or instance setting moves it, and changing it is an owner-approved, reviewed task.
-- **Tester feedback** (task 1003806, ADR 0344 D5). While a version is on the tester channel, what tester projects report about it becomes its Tester feedback part: the share of testers whose install worked and who hit no runtime errors, blended with ten neutral testers so a small sample cannot score high — `round(100 × (went well + 5) / (testers + 10))`. Reports from after the version left the tester channel, and the author's own, never count; under 3 testers it is not scored yet. The rule is `assessTesterFeedback` in `scripts/gds/module-assess-installs.js`.
+- **Tester feedback** (task 1003806, ADR 0344 D5). While a version is on the tester channel, what tester projects report about it becomes its Tester feedback part: the share of testers whose install worked and who hit no runtime errors, blended with ten neutral testers so a small sample cannot score high — `round(100 × (went well + 5) / (testers + 10))`. Reports from after the version left the tester channel, and the author's own, never count; under 3 testers it is not scored yet. The rule is `assessTesterFeedback` in `scripts/bongos/module-assess-installs.js`.
 - **What a module is strong and weak at** (task 1003799, ADR 0343 D4). Each catalog entry also carries `parts` (the current result of Tests, Clean installs, Reliability, Tester feedback and How-to) and a reading of them: `strengths` (a part scored **80 or more**), `weaknesses` (a part scored **below the floor**) and `unmeasured` (a part with no score yet, which is never counted as weak). Each strength and weakness has a one-sentence `detail` saying what the number rests on. Security is not among them: every listed version has passed it. The reading is `readParts` in `src/bongos/module-listing.js`; the hall's Modules tab shows it in its "In the store" group, so two modules with the same overall score can be told apart.
 - **Sorting by a part** (task 1003800). `GET /store/modules?sort=<part>` orders the listed modules by one part a buyer cares about: `tests`, `install`, `reliability`, `tester_feedback` or `docs` (the response lists them as `sort_parts`, and says which one it applied as `sort`). Modules with a score for that part come first, highest first; a tie goes to the higher overall score, then the module key. A module with no score for that part goes last, so missing data never wins or loses a place on its own. New modules are not sorted: they are never ranked. Any other `sort` value is refused with a 400. Without `sort`, the listed modules are in the ranking below; New stays in key order. The rule is `sortByPart` in `src/bongos/module-listing.js`.
 - **The ranking, and a maximum price** (task 1003808, owner decision 2026-10-23). Without `sort`, listed modules are ranked **quality first**: highest overall score first; between equal scores, free modules first, then the lowest cash price, then the lowest credit price, then the module key. Price never buys a better place, it only orders modules the score could not tell apart (and it is never an input to the score, ADR 0343 D6). The response states the rule as `ranking`, and each entry carries its current `price` (`cents`, `credits`, `free`). A buyer may add `?max_cents=` and/or `?max_credits=` (whole numbers, 0 or more): modules that cost more are left out of both lists, free modules always stay, and a priced module stays when it is offered at or under a cap the buyer set. The applied caps come back as `max_price`. The rules are `rankListed` and `withinMaxPrice` in `src/bongos/module-listing.js`.
+- **Why a module is not listed** (task 1003810). `GET /store/modules/:key/listing` says where one module stands, judging the same newest version the catalog does: `listed` (true or false), a `reason` (`not_assessed`, `security_not_passed`, `no_score`, `below_floor`, `delisted`, `no_version`, `new` or `at_or_above_floor`), `why` in a sentence and `next_step` saying what would change it. A failed Security gate is told apart from one that has not finished, and names what it found to the module's author only (to anyone else it would point at a weakness not fixed yet); below the floor names the score, the floor and the weakest parts. It carries the same `parts`, `strengths`, `weaknesses` and `unmeasured` as the catalog, plus `security`. Any signed-in builder can read it. Being past the cap of ten per category will be a reason of its own once the cap exists (task 1003809). The rule is `explainPlacement` in `src/bongos/module-listing.js`.
 - **Testing new versions first** (task 1003802, [ADR 0344](adr/0344-a-tester-is-a-project-that-opts-in-once.md) D1). A project can choose to get each new version of its modules before everyone else. It is the project that opts in, never one builder for someone else's project, and never by default. `GET /modules/testing` returns `{ tester, general_only, updated_at, updated_by }` to anyone signed in. `POST /modules/testing { tester: true|false }` switches it, and `POST /modules/:key/general-only { general_only: true|false }` keeps one module on the versions everyone gets while the rest are tested. Both writes take the `module.enable` permission, the same one that turns modules on and off. Both are reversible: switching testing off puts the project back on general versions from its next update, and a module's "general only" mark is kept if testing is switched off and on again. The choice is stored in the project's own settings (`modules.tester`, `modules.general_only`); anything that cannot be read counts as not testing. `testsVersionsOf` in `src/bongos/module-testing.js` is the one answer to "does this project get the tester version of this module", which installs and updates use (task 1003805). The hall's Modules tab has the switch in its "Testing new versions" group, and the general-only control in each module's details.
 
 ### 7. Install from the store
@@ -428,4 +429,4 @@ Most BONGOS-V1 module work is not scaffolding a *new* module — it's **carving
 3. **Delete from core.** Remove the moved functions from `src/bongos/db.js` so the monolith shrinks. If a function genuinely lives in the kernel (identity/audit/rank/tx), it goes to `src/bongos/db-kernel.js` and `db.js` re-exports it (so the 23 importers stay byte-identical) — that is the db-kernel reference carve, not a module carve.
 4. **Vendored twin when core still needs it.** If a core file *also* calls a moved query (e.g. `routes/me.js` reading a builder's art key), core keeps its own copy reading the same table and the module vendors its own — a module can never import core, and core can never import the module (the discord `getDiscordLink` precedent). Note the twin in the module's `CLAUDE.md`.
 5. **Capabilities the lifecycle invokes go behind a kernel PORT,** never a direct import: the providing module `registerProvider('<cap>', fn)` at boot; the lifecycle `resolve('<cap>')(…)` at call time (R73 does this for `grade`).
-6. **Verify byte-identical.** `node --check` each file; run the domain's `tests/*.mjs` + `tests/module_api.mjs` (the doorway surface contract) + `node scripts/gds/fitness.js`; regenerate the repo-map (`node scripts/gds/gen-repo-map.js`) since `db.js` exports changed.
+6. **Verify byte-identical.** `node --check` each file; run the domain's `tests/*.mjs` + `tests/module_api.mjs` (the doorway surface contract) + `node scripts/bongos/fitness.js`; regenerate the repo-map (`node scripts/bongos/gen-repo-map.js`) since `db.js` exports changed.

package/docs/onboarding/diagrams/01-task-lifecycle.mmd

@@ -1,5 +1,5 @@
 ---
-title: Task lifecycle — from backlog to shipped  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/gds/gen-diagrams.js)
+title: Task lifecycle — from backlog to shipped  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/bongos/gen-diagrams.js)
 ---
 stateDiagram-v2
     [*] --> backlog: task created

package/docs/onboarding/diagrams/02-rank-ladder.mmd

@@ -1,5 +1,5 @@
 ---
-title: Builder rank ladder — live vs reserved  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/gds/gen-diagrams.js)
+title: Builder rank ladder — live vs reserved  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/bongos/gen-diagrams.js)
 ---
 flowchart TB
     LEGEND["● LIVE (enforced by builders.rank)   ○ reserved (enum value, no wiring yet)"]

package/docs/onboarding/diagrams/03-drachmae-karma.mmd

@@ -1,5 +1,5 @@
 ---
-title: Credits & karma — where each comes from, where each goes  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/gds/gen-diagrams.js)
+title: Credits & karma — where each comes from, where each goes  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/bongos/gen-diagrams.js)
 ---
 flowchart LR
     subgraph CURRENCY["CREDITS  (the builder reward — equity / reputation, a stake, not a spendable currency)"]

package/docs/onboarding/diagrams/04-architecture.mmd

@@ -1,5 +1,5 @@
 ---
-title: The complete architecture — where your work runs and how it reaches production  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/gds/gen-diagrams.js)
+title: The complete architecture — where your work runs and how it reaches production  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/bongos/gen-diagrams.js)
 config:
   layout: elk
 ---

package/docs/onboarding/diagrams/05-versioning.mmd

@@ -1,5 +1,5 @@
 ---
-title: Versioning + planning sessions  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/gds/gen-diagrams.js)
+title: Versioning + planning sessions  (AUTO-GENERATED from live facts — do not hand-edit; see scripts/bongos/gen-diagrams.js)
 ---
 flowchart TB
     PS["/planning-session → done_when_criteria + tasks (with dependencies) + rank → seed the work pool"]

package/docs/onboarding/diagrams/README.md

@@ -6,7 +6,7 @@ Five flowcharts that explain Bongos to a new builder at a glance. Each diagram i
 
 ### Auto-generated vs hand-authored (important)
 
-**All five diagrams are now AUTO-GENERATED** from live facts by [`scripts/gds/gen-diagrams.js`](../../../scripts/gds/gen-diagrams.js). **Do not hand-edit any `.mmd`** — to change *layout/wording*, edit the matching template in `gen-diagrams.js`; to change *state*, change the underlying system and it regenerates.
+**All five diagrams are now AUTO-GENERATED** from live facts by [`scripts/bongos/gen-diagrams.js`](../../../scripts/bongos/gen-diagrams.js). **Do not hand-edit any `.mmd`** — to change *layout/wording*, edit the matching template in `gen-diagrams.js`; to change *state*, change the underlying system and it regenerates.
 
 | Diagram | What drives its state |
 |---|---|
@@ -69,16 +69,12 @@ The diagrams are surfaced inside the authenticated **builders' hall** at
 
 ## Staying current (auto-update)
 
-Two mechanisms keep these honest as the system changes (added under [#356](https://example.com/builders#/task/356)):
+One mechanism keeps these honest as the system changes (added under [#356](https://example.com/builders#/task/356)):
 
-1. **Render-on-deploy** — all five diagrams auto-regenerate on deploy: `scripts/gds/gen-diagrams.js` re-renders every `.mmd` to its `.svg` + `.png` and rebuilds `assertions.json` in lockstep, so the committed images never drift from their source. (Do **not** hand-edit the `.mmd`/`.svg`/`.png`/`assertions.json` — edit the template in `gen-diagrams.js` and re-run it.)
-2. **Drift detection** — the `diagram-drift` scheduled task (`.claude/scheduled-tasks/diagram-drift/`) runs a deterministic checker that compares `assertions.json` (below) against the live DB/code. Since all five diagrams auto-regenerate on deploy, this is a **belt-and-braces backstop** (it should find nothing in normal operation); on divergence it files an `idea_inbox` entry. Run it manually any time:
-   ```bash
-   node .claude/scheduled-tasks/diagram-drift/check.js          # report only
-   node .claude/scheduled-tasks/diagram-drift/check.js --file-idea
-   ```
+1. **Render-on-deploy** — all five diagrams auto-regenerate on deploy: `scripts/bongos/gen-diagrams.js` re-renders every `.mmd` to its `.svg` + `.png` and rebuilds `assertions.json` in lockstep, so the committed images never drift from their source. (Do **not** hand-edit the `.mmd`/`.svg`/`.png`/`assertions.json` — edit the template in `gen-diagrams.js` and re-run it.)
+(A second, the `diagram-drift` scheduled check, was retired in task 1004878: it was never scheduled, could not run on the packaged server, and duplicated the regeneration above.)
 
-`assertions.json` is the machine-readable record of what these diagrams claim about the live system (rank enum + wired ranks, task-status set, live versions, and the conceptual `architecture` + `example_karma` piece→task slices). It is **rebuilt by `gen-diagrams.js` in lockstep with the diagrams**, so you no longer hand-maintain it; it stays as the drift checker's reference.
+`assertions.json` is the machine-readable record of what these diagrams claim about the live system (rank enum + wired ranks, task-status set, live versions, and the conceptual `architecture` + `example_karma` piece→task slices). It is **rebuilt by `gen-diagrams.js` in lockstep with the diagrams**, so you no longer hand-maintain it.
 
 ## Regenerating the diagrams by hand
 

package/docs/onboarding/diagrams/assertions.json

@@ -1,5 +1,5 @@
 {
-  "_comment": "Machine-readable facts the onboarding diagrams assert about the LIVE system. The diagram-drift scheduled task (.claude/scheduled-tasks/diagram-drift/) compares these against the live DB/code and files an idea_inbox entry when they diverge, so the diagrams stay an honest snapshot. When a diagram is intentionally updated, update the matching values here in the same commit. Baselined 2026-05-26 under task #356.",
+  "_comment": "Machine-readable facts the onboarding diagrams assert about the LIVE system. gen-diagrams.js rebuilds them from the live DB/code in lockstep with the diagrams. When a diagram is intentionally updated, update the matching values here in the same commit. Baselined 2026-05-26 under task #356.",
   "rank_ladder": {
     "diagram": "02-rank-ladder",
     "rank_enum": [
@@ -82,7 +82,7 @@
   },
   "drachmae_karma": {
     "diagram": "03-drachmae-karma",
-    "_comment": "Pieces of 03-drachmae-karma that are gated on a backing Bongos task. A piece is LIVE iff its task is 'shipped'. live_tasks must ALL be shipped live; pending_tasks must NOT yet be shipped. Rebuilt automatically by scripts/gds/gen-diagrams.js from the authenticated /tasks/:id status; the diagram is regenerated in lockstep, so this slice is a redundant backstop the drift checker verifies. D_SHIP (credit_log trigger) and D_ACH (achievement bonuses) have no task gate and are always LIVE. achievements_seeded mirrors 03's 'N seeded' label, counted from the achievements seed INSERTs in migrations/.",
+    "_comment": "Pieces of 03-drachmae-karma that are gated on a backing Bongos task. A piece is LIVE iff its task is 'shipped'. live_tasks must ALL be shipped live; pending_tasks must NOT yet be shipped. Rebuilt automatically by scripts/bongos/gen-diagrams.js from the authenticated /tasks/:id status; the diagram is regenerated in lockstep. D_SHIP (credit_log trigger) and D_ACH (achievement bonuses) have no task gate and are always LIVE. achievements_seeded mirrors 03's 'N seeded' label, counted from the achievements seed INSERTs in migrations/.",
     "live_tasks": [
       {
         "id": 284,
@@ -115,7 +115,7 @@
   },
   "architecture": {
     "diagram": "04-architecture",
-    "_comment": "Pieces of 04-architecture gated on a backing Bongos task. A piece is LIVE iff its task is 'shipped'; live_tasks must ALL be shipped, pending_tasks must NOT yet be. Rebuilt by scripts/gds/gen-diagrams.js in lockstep with the diagram, so this is the drift checker's backstop. The machine/server/GitHub topology is structural (not task-gated); these are the LIVE/PLANNED markers. MEMORY layer (ADR 0024): 273 schema / 274 sync-on-ship / 275 pull-on-start / 276 isolation. Ship flow: 1025 (server-mediated publish, for a checkout with no push credential), 1028 (GitHub App push credential). The deploy leg is the standalone AUTO-PULL (ADR 0108/0129), not a task-gated GitHub-Actions CI job, so 859 is intentionally absent.",
+    "_comment": "Pieces of 04-architecture gated on a backing Bongos task. A piece is LIVE iff its task is 'shipped'; live_tasks must ALL be shipped, pending_tasks must NOT yet be. Rebuilt by scripts/bongos/gen-diagrams.js in lockstep with the diagram. The machine/server/GitHub topology is structural (not task-gated); these are the LIVE/PLANNED markers. MEMORY layer (ADR 0024): 273 schema / 274 sync-on-ship / 275 pull-on-start / 276 isolation. Ship flow: 1025 (server-mediated publish, for a checkout with no push credential), 1028 (GitHub App push credential). The deploy leg is the standalone AUTO-PULL (ADR 0108/0129), not a task-gated GitHub-Actions CI job, so 859 is intentionally absent.",
     "live_tasks": [
       {
         "id": 273,

package/docs/onboarding/slash-commands.md

@@ -61,13 +61,13 @@ These work in **any** repository — they have nothing to do with this project.
 
 These are the ones that actually cause confusion.
 
-**`/status` — the genuine collision.** Both sides define it. Claude Code's `/status` shows your session and auth state; this project's shows version and criterion progress. Which one wins depends on your Claude Code version and how it resolves the name. If you get the wrong one, say *"what's left for C8"* in plain English, or run `node scripts/gds/status.js` directly.
+**`/status` — the genuine collision.** Both sides define it. Claude Code's `/status` shows your session and auth state; this project's shows version and criterion progress. Which one wins depends on your Claude Code version and how it resolves the name. If you get the wrong one, say *"what's left for C8"* in plain English, or run `node scripts/bongos/status.js` directly.
 
 **`/login` is Anthropic, not us.** It signs you into your Claude account. To sign into a Cloud Bongos instance, use `bongos login <instance-url>`, or `/builder-setup` for a first-time enrolment.
 
 **`/init` writes a `CLAUDE.md`.** It does *not* scaffold a new instance — that's `bongos init`, wrapped by `/new-project`. Running `/init` in this repo would overwrite the project's own `CLAUDE.md`.
 
-**`/doctor` checks Claude Code.** For the build system's health — your session, toolchain, git plumbing, environment — run `node scripts/gds/doctor.js`.
+**`/doctor` checks Claude Code.** For the build system's health — your session, toolchain, git plumbing, environment — run `node scripts/bongos/doctor.js`.
 
 **`/cost` is Claude's token spend.** To record a project cost against your claim, that's `/builder-cost`.
 

package/docs/packs/artist.md

@@ -1,6 +1,6 @@
 # Artist pack
 
-> **The role pack for `discipline = artist`.** The kernel ([`CLAUDE.md`](../../CLAUDE.md)) is what every session reads whatever its craft; this file is the half that is only true for artists. Read the whole thing before acting — it changes how you *communicate* for the rest of the session. Registered in [`scripts/gds/discipline-modes.json`](../../scripts/gds/discipline-modes.json); the Conductor injects this pointer into a session holding a claim of this craft (task 1002992).
+> **The role pack for `discipline = artist`.** The kernel ([`CLAUDE.md`](../../CLAUDE.md)) is what every session reads whatever its craft; this file is the half that is only true for artists. Read the whole thing before acting — it changes how you *communicate* for the rest of the session. Registered in [`scripts/bongos/discipline-modes.json`](../../scripts/bongos/discipline-modes.json); the Conductor injects this pointer into a session holding a claim of this craft (task 1002992).
 
 An art session is not the engineer's text-heavy build loop. The artist's subject is how the project **looks and reads** — its visuals, its copy, its voice, the feeling of the thing. A craft is an identity, not a toolchain ([ADR 0272](../adr/0272-a-craft-is-an-identity-not-a-toolchain.md)): an instance has artists whether or not it ships an art pipeline.
 
@@ -36,7 +36,7 @@ Only the holder writes. A page someone else holds is read-only and names them. A
 
 **Gone from the artist's loop:** the per-ship "Artist review" task (a ship that changes a page's words now marks it "changed since last tweak", and the Flow raises it) and flagging single strings on the copy desk (archived; a page is the unit now). Reviews filed before Tweak Mode are still answered behind the studio's quiet door under the actions ("1 review from before Tweak Mode still waits"), shown only while one does.
 
-**When the artist is at the terminal instead.** You are their hands. The same routes the pages use are on `node scripts/gds/api.js` under `/api/bongos/copy-desk/`: `GET next`, `POST pages/<id>/claim`, `GET pages/<id>/draft`, `PUT pages/<id>/draft` (the whole draft, `{ reading_hash, lines: [{ key, after }] }`), `POST pages/<id>/submit`, `GET approvals`, `POST pages/<id>/approve`, `POST pages/<id>/send-back` (`{ note }`). Put *their* words in, then open the editor or the queue so they see the result. Never approve on their behalf.
+**When the artist is at the terminal instead.** You are their hands. The same routes the pages use are on `node scripts/bongos/api.js` under `/api/bongos/copy-desk/`: `GET next`, `POST pages/<id>/claim`, `GET pages/<id>/draft`, `PUT pages/<id>/draft` (the whole draft, `{ reading_hash, lines: [{ key, after }] }`), `POST pages/<id>/submit`, `GET approvals`, `POST pages/<id>/approve`, `POST pages/<id>/send-back` (`{ note }`). Put *their* words in, then open the editor or the queue so they see the result. Never approve on their behalf.
 
 ---
 
@@ -49,7 +49,7 @@ In every other craft Claude narrates — diffs, logs, paragraphs about what it i
 - **End every step with something visual.** After a generation, display the image. After a copy change, show the rendered text in place (the studio, the editor, the Approval queue), not a diff. After a check, show the scorecard, not a prose summary.
 - **Collapse the plumbing to one-liners.** "Saved, 12 of 38 lines rewritten" beats three paragraphs.
 - **Verification is looking, not reading.** Surface the rendered page, not console logs. Logs are for when something breaks.
-- **Nothing that changes a page ships until they have seen it** (owner, 2026-09-23). In Tweak Mode the Approval queue is that look. For other work, show the before and after in both modes at desktop and phone width with `node scripts/gds/review-sheet.js` (a terminal shows no images), and ship on their OK.
+- **Nothing that changes a page ships until they have seen it** (owner, 2026-09-23). In Tweak Mode the Approval queue is that look. For other work, show the before and after in both modes at desktop and phone width with `node scripts/bongos/review-sheet.js` (a terminal shows no images), and ship on their OK.
 
 ## The second rule: as little interpretation as possible
 
@@ -98,7 +98,7 @@ When the artist reacts — "too saturated", "that reads as modern" — don't jus
 
 ---
 
-<!-- BEGIN GENERATED ROLE RESPONSIBILITY (scripts/gds/gen-role-responsibilities.js — do not hand-edit) -->
+<!-- BEGIN GENERATED ROLE RESPONSIBILITY (scripts/bongos/gen-role-responsibilities.js — do not hand-edit) -->
 ## What this craft is answerable for
 
 > No slop in the appearance and text of the project; the story, emotion and ideology of the project are communicated effectively; project purpose and gravitas are upheld.

package/docs/packs/engineer.md

@@ -1,6 +1,6 @@
 # Engineer pack
 
-> **The role pack for `discipline = engineer`.** The kernel ([`CLAUDE.md`](../../CLAUDE.md)) is what every session reads whatever its craft; this file is the half that is only true for engineers. Read it once at the top of an engineering session. Registered in [`scripts/gds/discipline-modes.json`](../../scripts/gds/discipline-modes.json); the Conductor injects this pointer into a session holding a claim of this craft (task 1002992).
+> **The role pack for `discipline = engineer`.** The kernel ([`CLAUDE.md`](../../CLAUDE.md)) is what every session reads whatever its craft; this file is the half that is only true for engineers. Read it once at the top of an engineering session. Registered in [`scripts/bongos/discipline-modes.json`](../../scripts/bongos/discipline-modes.json); the Conductor injects this pointer into a session holding a claim of this craft (task 1002992).
 
 Engineering is the project's **default loop**, so this pack introduces no new dynamic — its job is to make the standard explicit and keep you on it. Lean on it hardest when you are new here or running autonomously. (The Ideator pack flips *who drives*; the Artist pack flips *the medium*. This one is the baseline they invert from.)
 
@@ -8,11 +8,11 @@ Engineering is the project's **default loop**, so this pack introduces no new dy
 
 ## The loop: understand → scoped change → verify → ship
 
-1. **You hold a claim — keep the work inside it.** Everything you change should serve the claimed task. An out-of-scope fix you spot along the way is a *separate* task or an idea (`node scripts/gds/capture.js`), not a quiet addition to this diff. Scope creep is the most common way an engineering session goes wrong.
+1. **You hold a claim — keep the work inside it.** Everything you change should serve the claimed task. An out-of-scope fix you spot along the way is a *separate* task or an idea (`node scripts/bongos/capture.js`), not a quiet addition to this diff. Scope creep is the most common way an engineering session goes wrong.
 
 2. **Understand before you edit.**
    - The nested `CLAUDE.md` in the directory you are working in (loads on demand — it has the gotchas).
-   - `docs/repo-map.md` (the symbol skeleton) to navigate without reading every file. It is gitignored + regenerated at deploy/box-fetch (ADR 0110), so if it is absent run `node scripts/gds/gen-repo-map.js`.
+   - `docs/repo-map.md` (the symbol skeleton) to navigate without reading every file. It is gitignored + regenerated at deploy/box-fetch (ADR 0110), so if it is absent run `node scripts/bongos/gen-repo-map.js`.
    - `/recall <topic>` to find what is already known or decided, so you do not re-solve it.
    - Match the surrounding code: its naming, its idioms, its comment density.
 
@@ -21,7 +21,7 @@ Engineering is the project's **default loop**, so this pack introduces no new dy
 4. **Verify it — never report done on faith.** The step engineers most often skip.
    - Run the smoke tests yourself while iterating (`/builder-ship` runs them too, but later is not the same as sooner).
    - If the change is observable in the running app, use the preview/verification workflow (preview → reload → console + page check → screenshot proof) yourself first. Verify, then share the proof.
-   - **A change to a page people see is reviewed by your human before it ships — the project default for every builder (owner, 2026-09-23).** Render it before and after, in both modes, at desktop and phone width; open the shots for them with `node scripts/gds/review-sheet.js` (a terminal shows no images — this opens one page in their browser); wait for their OK, then ship. With nobody to ask, list the shots in the ship notes and ship: the change also files a visual review on the board that holds the deploy (ADR 0241), never the ship.
+   - **A change to a page people see is reviewed by your human before it ships — the project default for every builder (owner, 2026-09-23).** Render it before and after, in both modes, at desktop and phone width; open the shots for them with `node scripts/bongos/review-sheet.js` (a terminal shows no images — this opens one page in their browser); wait for their OK, then ship. With nobody to ask, list the shots in the ship notes and ship: the change also files a visual review on the board that holds the deploy (ADR 0241), never the ship.
    - If it is not browser-observable (a different runtime, types, tooling), say so and verify the way that *does* exercise it.
    - `/ship-check` runs every freshness and fitness gate `ship.js` will run, and prints the healing command for each stale generated file. When your branch changed a page, it also renders it at 1280 + 390 and names any text past its box or overlapping siblings — an advisory row, never a gate (ADR 0329).
 
@@ -34,15 +34,16 @@ Engineering is the project's **default loop**, so this pack introduces no new dy
 - **Every change is backed by a claimed Bongos task. No exceptions.** This is the methodology's hard rule and the engineer's form of the kernel's ledger rule. If you are about to commit code, edit a doc, run a migration, change a config, move a task between versions, or otherwise alter state — and you do not hold an active claim covering that work — stop. Create or find the task, claim it, *then* make the change. There is no "admin work" loophole, no "meta-work" loophole, no "tiny fix" loophole, no "just a doc tweak" loophole, no "scaffolding" loophole, and no "I'm setting up to do the real work" loophole. Bongos is the complete ledger of what happened to this project; if a change isn't in it, the ledger lies.
 - **Direct DB writes are work too.** Updating `tasks`, `versions`, `blockers` via `psql` is a change to project state and needs a claim just like a `git commit` does. The API not yet exposing an endpoint does not make it admin work — it just means the operation runs under a claim via SQL. Capture the SQL in the claim's session-log notes so the audit trail is complete.
 - **Start every session with `/builder-start`.** The API computes parallel-safety against currently-active claims so you don't have to.
-- **Claim before working, from a dedicated worktree** — never the main checkout; `claim.js` refuses there (task 1002579; `--here` overrides), because branching in the primary worktree strands the ship at `confirmed`. `/builder-claim N` locks the task to your session. If the claim fails (already claimed, not ready, **dependencies not shipped**), pick another. If nothing exists for the work you are about to do, create the task first via `POST /api/bongos/tasks` or `node scripts/gds/capture.js`, then claim it.
+- **Claim before working, from a dedicated worktree** — never the main checkout; `claim.js` refuses there (task 1002579; `--here` overrides), because branching in the primary worktree strands the ship at `confirmed`. `/builder-claim N` locks the task to your session. If the claim fails (already claimed, not ready, **dependencies not shipped**), pick another. If nothing exists for the work you are about to do, create the task first via `POST /api/bongos/tasks` or `node scripts/bongos/capture.js`, then claim it.
 - **Dependencies gate everything.** A task declares `dependencies[]` (task ids that must be `shipped` first); shipping a task auto-promotes its now-unblocked dependents `backlog`→`ready`, and `POST /claims` refuses with 409 `DEPS_NOT_SHIPPED` otherwise. The `V##.R##` rank prefix is decorative; deps are load-bearing. Full mechanics + CRUD endpoints in ADR 0015.
 - **Ship or release at session end.** A deliberate no-artifact ship (`--db-only` / `--allow-empty`) lands itself at ship time, even from the main checkout (task 1002723); anything else left at `confirmed` is landed by the server reconciler within ~5 min, which probes every real branch convention and logs a per-task disposition line each sweep. `/merge-mode` is only the manual fallback for a strand that survives that sweep. `/builder-release` returns the task with no credits.
 - **Code you write or touch carries a doc-comment** — each module a header, each public function or class a line or two, saying *what* it does and *why* it exists (never how), in the words someone would search for. Agents navigate by grep, so meaning written into the source is what makes code findable (ADR 0095). Convention + examples: [`docs/code-conventions.md`](../code-conventions.md). Advisory — `fitness.js` warns, never blocks.
+- **A new test must exercise behaviour** — call the function, run the CLI, hit the route — never only read a source file's text and match its wording (that breaks on rewording and misses real bugs). When you edit a test file that only does that, convert at least the tests you touch. `fitness.js` fails if the count of such files rises; `node scripts/bongos/source-text-test-scan.js --files` lists them (task 1004868).
 - **Non-obvious decision → an ADR** in [`docs/adr/`](../adr/), linked from the shipping task's notes.
-- **A discovery that took more than ~10 minutes to diagnose → a learning** (`node scripts/gds/learning-capture.js`, DB-backed). A multi-page how-to → a recipe under [`docs/recipes/`](../recipes/).
+- **A discovery that took more than ~10 minutes to diagnose → a learning** (`node scripts/bongos/learning-capture.js`, DB-backed). A multi-page how-to → a recipe under [`docs/recipes/`](../recipes/).
 - **Stuck on something only the owner can decide or provide → a blocker** (`POST /api/bongos/blockers`), with the `blocker_ref` attached to the task.
-- **Anything you put to a person is an ask, not prose** — a blocker, a "please confirm" at the end of a run, a review or help request. One question of at most twelve words, two or three tap answers each with a one-line result, your pick and why, who it waits on, what happens if nobody answers; the long text goes in `detail`. `node scripts/gds/ask.js template` gives a blank card, `check <file>` gives the server's verdict and prints the card to paste. A blocker filed from your session without one is refused (400 `ask_required`); send it as `ask` beside `title`/`body_md` (ADR 0373).
-- **Never hand-edit a generated artifact.** The onboarding diagrams (ranks, task statuses, versions, credits/karma, architecture) are generated by `scripts/gds/gen-diagrams.js` on deploy — `.svg`/`.png` + `assertions.json` in lockstep. Edit the template in the generator, run it, commit. Same for `gen-repo-map.js`, `gen-file-map.js`, `gen-session-index.js`.
+- **Anything you put to a person is an ask, not prose** — a blocker, a "please confirm" at the end of a run, a review or help request. One question of at most twelve words, two or three tap answers each with a one-line result, your pick and why, who it waits on, what happens if nobody answers; the long text goes in `detail`. `node scripts/bongos/ask.js template` gives a blank card, `check <file>` gives the server's verdict and prints the card to paste. A blocker filed from your session without one is refused (400 `ask_required`); send it as `ask` beside `title`/`body_md` (ADR 0373).
+- **Never hand-edit a generated artifact.** The onboarding diagrams (ranks, task statuses, versions, credits/karma, architecture) are generated by `scripts/bongos/gen-diagrams.js` on deploy — `.svg`/`.png` + `assertions.json` in lockstep. Edit the template in the generator, run it, commit. Same for `gen-repo-map.js`, `gen-file-map.js`, `gen-session-index.js`.
 
 ### Where an idea goes when it isn't this task
 
@@ -50,7 +51,7 @@ Engineering is the project's **default loop**, so this pack introduces no new dy
 
 - Fits inside the existing claim → just ship it under that claim.
 - Does not fit the claim, but is small and in the current version → finish the claim first, then claim a new task for it.
-- Bigger or out of scope → create a task via `POST /api/bongos/tasks` (status `backlog`), or capture it with `node scripts/gds/capture.js` for `idea_inbox` triage.
+- Bigger or out of scope → create a task via `POST /api/bongos/tasks` (status `backlog`), or capture it with `node scripts/bongos/capture.js` for `idea_inbox` triage.
 
 ---
 
@@ -111,7 +112,7 @@ Subagent spawns via the `Agent` tool MUST set the `model` parameter explicitly
 
 ---
 
-<!-- BEGIN GENERATED ROLE RESPONSIBILITY (scripts/gds/gen-role-responsibilities.js — do not hand-edit) -->
+<!-- BEGIN GENERATED ROLE RESPONSIBILITY (scripts/bongos/gen-role-responsibilities.js — do not hand-edit) -->
 ## What this craft is answerable for
 
 > Running and optimizing the running of Claude nonstop, and ensuring Ideators and Artists can continue to interface with that system effectively.

package/docs/packs/ideator.md

@@ -1,6 +1,6 @@
 # Ideator pack
 
-> **The role pack for `discipline = ideator`.** The kernel ([`CLAUDE.md`](../../CLAUDE.md)) is what every session reads whatever its craft; this file is the half that is only true for ideators. Read the whole thing before acting — it changes how you behave for the rest of the session. Registered in [`scripts/gds/discipline-modes.json`](../../scripts/gds/discipline-modes.json); the Conductor injects this pointer into a session holding a claim of this craft (task 1002992).
+> **The role pack for `discipline = ideator`.** The kernel ([`CLAUDE.md`](../../CLAUDE.md)) is what every session reads whatever its craft; this file is the half that is only true for ideators. Read the whole thing before acting — it changes how you behave for the rest of the session. Registered in [`scripts/bongos/discipline-modes.json`](../../scripts/bongos/discipline-modes.json); the Conductor injects this pointer into a session holding a claim of this craft (task 1002992).
 
 An ideation session is not the build-and-ship loop, and **it needs no claim**. "I'm just exploring" is a first-class state: an ideator should never need a chore checked out to start thinking.
 
@@ -39,7 +39,7 @@ If unsure, ask once: *"Are you here to ideate with me, or should I run this auto
 
 So that every idea lands against reality rather than in a vacuum:
 
-1. **What's already filed** — `node scripts/gds/api.js GET /api/bongos/inbox`. You will not propose near-duplicates of open ideas; if a thread overlaps one, say so and build *on* it.
+1. **What's already filed** — `node scripts/bongos/api.js GET /api/bongos/inbox`. You will not propose near-duplicates of open ideas; if a thread overlaps one, say so and build *on* it.
 2. **What we already know** — `/recall <theme>` for any theme you are about to explore, so you are not re-suggesting something already decided or shipped.
 3. **The project's own voice** — the instance's identity lives in [`docs/project-context.template.md`](../project-context.template.md) (the scaffold `cloudbongos init` fills) and [`config/branding.neutral.json`](../../config/branding.neutral.json). For product ideas, hold them to that voice. For builder-experience or internal ideas the voice doesn't apply — judge them on the rough edge they smooth.
 
@@ -62,7 +62,7 @@ A **Full Idea** is the ideator craft's real output: a baseline scope of work som
 **Get the questions from the template, never from memory** — they are declared once, as data, and a project can define its own:
 
 ```
-node scripts/gds/spark.js --template
+node scripts/bongos/spark.js --template
 ```
 
 That prints each field, its label, and the substance floor the scorer expects. Ask them **as questions, in that order** — one at a time, in the ideator's own thread of thought, not as a form read aloud. Drawing five answers out of a conversation is exactly this pack's dynamic, and it is the path for someone who thinks by talking rather than by filling in boxes.
@@ -86,7 +86,7 @@ Read the answers back before filing and let them correct you. They bless it; you
 A quick idea, with the one line of substance in the body:
 
 ```
-node scripts/gds/capture.js "<title>" --body-file <path>
+node scripts/bongos/capture.js "<title>" --body-file <path>
 ```
 
 Body conventions (no schema change): one line of substance; then, when you have it, `surfaces:`, `risks:`, `open questions:`.
@@ -94,7 +94,7 @@ Body conventions (no schema change): one line of substance; then, when you have
 A Full Idea, from their answers written to a JSON file keyed by the template's field keys:
 
 ```
-node scripts/gds/capture.js "<their title>" --full --fields-file <path>
+node scripts/bongos/capture.js "<their title>" --full --fields-file <path>
 ```
 
 That is the **same route** the hall form uses, so the record is identical — same validation against the template, same score, same ideator-credit lane. There is deliberately no second write path for conversational authoring: a second one would drift.
@@ -109,7 +109,7 @@ File the idea first either way, and treat the handoff as an offer rather than a
 
 ### Developing someone else's spark
 
-The same conversation works on a **Big Idea Spark** — a quick idea whose author marked it as needing development. `node scripts/gds/spark.js --list` shows what is waiting; develop one with `spark.js --develop <id> --fields-file <path>`. The author keeps the credit for having had the thought and the payout splits with them (ADR 0185), so the never-invent rule applies with *more* force, not less: those five answers go out under two people's names.
+The same conversation works on a **Big Idea Spark** — a quick idea whose author marked it as needing development. `node scripts/bongos/spark.js --list` shows what is waiting; develop one with `spark.js --develop <id> --fields-file <path>`. The author keeps the credit for having had the thought and the payout splits with them (ADR 0185), so the never-invent rule applies with *more* force, not less: those five answers go out under two people's names.
 
 ---
 
@@ -132,7 +132,7 @@ Filing into the inbox is open to **any** authenticated builder, Xenos included.
 
 ---
 
-<!-- BEGIN GENERATED ROLE RESPONSIBILITY (scripts/gds/gen-role-responsibilities.js — do not hand-edit) -->
+<!-- BEGIN GENERATED ROLE RESPONSIBILITY (scripts/bongos/gen-role-responsibilities.js — do not hand-edit) -->
 ## What this craft is answerable for
 
 > Make good ideas; be a philosopher / thought leader for the project; enable Engineers to scope and Artists to create with maximum efficiency — a baseline for creating scopes of work.