@bongos/core 1.21.175 → 1.21.176

package/docs/recipes/packaging-the-core.md

@@ -2,13 +2,13 @@
 
 > **This is one leg of three.** For how a change to Cloud Bongos actually reaches a live instance — and why merging to `main` ships nothing on its own — start at [the core release pipeline](core-release-pipeline.md).
 >
-> Implements [ADR 0100 §1](../adr/0100-two-repo-instance-model.md) (the two-repo instance model). This is **R84**, the first step of the `R84 → R85 → R86` spine: package the core → stand a downstream instance up on a pinned core → make `bongos upgrade` a real update channel. Tooling: [`scripts/gds/package-core.js`](../../scripts/gds/package-core.js) (`bongos package-core`).
+> Implements [ADR 0100 §1](../adr/0100-two-repo-instance-model.md) (the two-repo instance model). This is **R84**, the first step of the `R84 → R85 → R86` spine: package the core → stand a downstream instance up on a pinned core → make `bongos upgrade` a real update channel. Tooling: [`scripts/bongos/package-core.js`](../../scripts/bongos/package-core.js) (`bongos package-core`).
 >
 > **Real installable npm package ([ADR 0108](../adr/0108-instance-composition-configurable-root.md) §2, task 1882/W2, shipped):** the artifact is `package/`-rooted (the npm convention `npm install ./x.tgz` requires) and carries a synthesized `package.json` — `name: "@bongos/core"`, `version` = `CORE_VERSION`, `main: "src/platform-server.js"`, `exports` for the default entry (`buildPlatformApp`) plus `./serve-internal` (`mountInternalSurfaces`) and `./module-api`, `bin: "bongos"` — and a **pruned** `package-lock.json` (express + pg's own transitive closure only, resolved offline from the source lockfile — no colyseus/phaser/sharp/discord.js). Both files are synthesized fresh, never copied verbatim from the source repo's game-heavy `package.json`. `resolveCoreRoot()`/`resolveInstanceRoot()` ([`src/instance-config.js`](../../src/instance-config.js), W1/task 1881) are what a consumer's own code routes through once installed.
 
 ## What the artifact is
 
-A Cloud Bongos *instance* can be its **own repository** that installs a **pinned version** of the Cloud Bongos **core** — the portable methodology + platform + neutral branding — and layers its own content, branding, and modules on top. "The core" is not re-defined here: it is exactly the subtree [`isPublishable()`](../../scripts/gds/publish-manifest.js) already defines ([ADR 0098](../adr/0098-public-mirror-publish-manifest.md)).
+A Cloud Bongos *instance* can be its **own repository** that installs a **pinned version** of the Cloud Bongos **core** — the portable methodology + platform + neutral branding — and layers its own content, branding, and modules on top. "The core" is not re-defined here: it is exactly the subtree [`isPublishable()`](../../scripts/bongos/publish-manifest.js) already defines ([ADR 0098](../adr/0098-public-mirror-publish-manifest.md)).
 
 `bongos package-core` produces three things in `dist/` (git-ignored — the artifact is a build product, not committed):
 
@@ -27,7 +27,7 @@ Every file is **redacted** through the same fail-closed pipeline the public mirr
 ```sh
 bongos package-core                 # from HEAD, version = platform CORE_VERSION
 bongos package-core --ref origin/main --version 1.13.0
-node scripts/gds/package-core.js --droplet-ip <ip>   # add the prod IP as an exact gate literal
+node scripts/bongos/package-core.js --droplet-ip <ip>   # add the prod IP as an exact gate literal
 bongos package-core --self-verify   # after building, prove the artifact reproduces its pin
 bongos package-core --self-verify --self-verify-boot   # ALSO npm-install the .tgz + boot /healthz
 ```
@@ -36,17 +36,17 @@ bongos package-core --self-verify --self-verify-boot   # ALSO npm-install the .t
 
 `--self-verify` (task [#1002218](https://example.com/builders#/task/1002218), audit H3) closes the produce-side of the integrity loop: after writing the artifact it **unpacks the built `.tgz` and recomputes `tree_sha256`, asserting it equals the manifest** (+ the on-disk `.tgz` bytes vs `tarball.sha256`) — proving the packager's own output reproduces its pin before it is trusted or published (a mismatch exits non-zero, ahead of the `--publish` leg). It is deterministic and network-free. Add `--self-verify-boot` to *also* `npm install` the tarball into a throwaway consumer and boot `/healthz` (reuses [`tests/consumer_layout_boot.mjs`](../../tests/consumer_layout_boot.mjs); needs npm/registry access — the deeper standing CI gate is task [#1002221](https://example.com/builders#/task/1002221)).
 
-If the no-leak gate fails, it names the file + the residual literal. Fix the redaction rules ([`scripts/gds/mirror-redact.js`](../../scripts/gds/mirror-redact.js)) or the manifest exclusions ([`scripts/gds/publish-manifest.js`](../../scripts/gds/publish-manifest.js)) and re-run — do not weaken the gate to force a pass.
+If the no-leak gate fails, it names the file + the residual literal. Fix the redaction rules ([`scripts/bongos/mirror-redact.js`](../../scripts/bongos/mirror-redact.js)) or the manifest exclusions ([`scripts/bongos/publish-manifest.js`](../../scripts/bongos/publish-manifest.js)) and re-run — do not weaken the gate to force a pass.
 
 **The neutral floor** (task [#1002217](https://example.com/builders#/task/1002217), audit H4). Because the trunk carries no `config/branding.json`, the *branding-derived* redaction would strip nothing — so `package-core.js` always injects a fixed **`PRIOR_INSTANCE_FLOOR`** (prior-instance tokens/owners) into the doc-redaction + no-leak gate. Published **docs** are de-branded against it and the gate **fails closed** if a floor literal survives, even with no branding.json. **Functional** files still ship verbatim (the R88 fix) and are instead surfaced by the non-fatal `[leak-scan]` (task 1002220). To retire a new prior-instance token, add it to `PRIOR_INSTANCE_FLOOR` (kept in `package-core.js`, never in `mirror-redact.js` — that file's self-leak invariant forbids hardcoded literals).
 
-**The release notes** (task 1004218). The tarball also carries `release-notes.json` at its root — what each release brought in, as the merge summaries its ships wrote — so the Deploy page on any project can say what an upgrade brings in without a core git checkout (no tenant box has one). It is the one file derived from the ref's **history** rather than from a committed file, built by [`scripts/gds/release-notes.js`](../../scripts/gds/release-notes.js): pinned in the manifest like every other file (so `--self-verify` reproduces it), its prose **redacted exactly like a doc** (the neutral floor applies — real summaries in the history name prior instances, and shipping them verbatim would fail the leak scan on every pack), and bounded at 1 MiB by dropping the oldest releases. **A shallow clone or a `--from-worktree` build ships without it**, printing `! release-notes.json not generated — <why>`; an upgrade onto such a version then says its notes are unavailable. CI packs at `fetch-depth: 0`, so every release it publishes carries them.
+**The release notes** (task 1004218). The tarball also carries `release-notes.json` at its root — what each release brought in, as the merge summaries its ships wrote — so the Deploy page on any project can say what an upgrade brings in without a core git checkout (no tenant box has one). It is the one file derived from the ref's **history** rather than from a committed file, built by [`scripts/bongos/release-notes.js`](../../scripts/bongos/release-notes.js): pinned in the manifest like every other file (so `--self-verify` reproduces it), its prose **redacted exactly like a doc** (the neutral floor applies — real summaries in the history name prior instances, and shipping them verbatim would fail the leak scan on every pack), and bounded at 1 MiB by dropping the oldest releases. **A shallow clone or a `--from-worktree` build ships without it**, printing `! release-notes.json not generated — <why>`; an upgrade onto such a version then says its notes are unavailable. CI packs at `fetch-depth: 0`, so every release it publishes carries them.
 
 ## Prove it boots (the standing PROVE-PUBLISH gates)
 
 Two standing gates keep "a published core boots clean from a bare install" honest (task [#1002221](https://example.com/builders#/task/1002221), audit H1/H2):
 
-- **`node scripts/gds/run-unit-tests.js --integration`** — the integration-smoke gate. Runs the heavier integration set (longer per-test budget), including [`tests/consumer_layout_boot.mjs`](../../tests/consumer_layout_boot.mjs), which packages the core, `npm install`s the `.tgz`, and boots `/healthz` from the real consumer layout. Since task 1002863 it also carries the database half: it installs the unpacked package from its **own shipped lockfile** with `npm ci`, runs `npm run migrate` from the consumer onto a brand-new **empty** database (and onto a second one with every optional module switched on), then boots the installed server against the first and reads a sentinel row back through `GET /api/bongos/public/versions`. It creates and drops those databases itself, so it needs a Postgres whose role may `CREATE DATABASE`; without one it prints SKIP lines, except under `CI=true`, where a missing Postgres fails the run. The `integration` job of [`.github/workflows/integration.yml`](../../.github/workflows/integration.yml) runs this set on every push to `main` (not per PR — a cost decision recorded in that file). The default `run-unit-tests.js` (no flag) stays the fast DB-free unit gate and *excludes* this set.
+- **`node scripts/bongos/run-unit-tests.js --integration`** — the integration-smoke gate. Runs the heavier integration set (longer per-test budget), including [`tests/consumer_layout_boot.mjs`](../../tests/consumer_layout_boot.mjs), which packages the core, `npm install`s the `.tgz`, and boots `/healthz` from the real consumer layout. Since task 1002863 it also carries the database half: it installs the unpacked package from its **own shipped lockfile** with `npm ci`, runs `npm run migrate` from the consumer onto a brand-new **empty** database (and onto a second one with every optional module switched on), then boots the installed server against the first and reads a sentinel row back through `GET /api/bongos/public/versions`. It creates and drops those databases itself, so it needs a Postgres whose role may `CREATE DATABASE`; without one it prints SKIP lines, except under `CI=true`, where a missing Postgres fails the run. The `integration` job of [`.github/workflows/integration.yml`](../../.github/workflows/integration.yml) runs this set on every push to `main` (not per PR — a cost decision recorded in that file). The default `run-unit-tests.js` (no flag) stays the fast DB-free unit gate and *excludes* this set.
 - **[`tests/pruned_lockfile_integrity.mjs`](../../tests/pruned_lockfile_integrity.mjs)** — a network-free unit guard (runs in the default gate every PR) that rebuilds the shipped pruned lockfile and asserts every registry package keeps a **well-formed, verbatim `integrity` hash**. This is the exact R88 regression (redaction once blanked those base64 hashes → `npm ci` could no longer verify) caught before a consumer's install ever fails.
 
 ## Consume + pin it (the R85 side)

package/docs/recipes/parallel-goal-waves.md

@@ -17,8 +17,8 @@ Dependencies tell you what must **ship** first. They tell you nothing about what
 Start by pulling the real graph — status, `dependencies[]`, `dependents[]`, and `requires_rank` for every task on the goal:
 
 ```
-node scripts/gds/api.js GET "/api/bongos/tasks?goal_id=<goal>&limit=100"
-node scripts/gds/api.js GET "/api/bongos/tasks/<id>"     # includes dependencies + dependents
+node scripts/bongos/api.js GET "/api/bongos/tasks?goal_id=<goal>&limit=100"
+node scripts/bongos/api.js GET "/api/bongos/tasks/<id>"     # includes dependencies + dependents
 ```
 
 > **Gotcha (cost us ~40 minutes).** The generated API client wraps responses as `{status, ok, data:{...}}`. Reading `res.tasks` gives `undefined` and every dependency array silently looks empty — which reads as "this goal has no dependencies at all". Unwrap `.data` first. An empty dependency graph should make you suspicious, not relieved.
@@ -64,7 +64,7 @@ Concurrent bound claims from one machine **used to be impossible**: the app-laye
 **Use the batch endpoint**, which was built for exactly this:
 
 ```
-node scripts/gds/api.js POST /api/bongos/claims/batch \
+node scripts/bongos/api.js POST /api/bongos/claims/batch \
   --body-file batch.json     # {"task_ids":[111,222,333],"bind_session":false}
 ```
 
@@ -111,7 +111,7 @@ One file will become the contention point. Here it was the module's nested `CLAU
 # took is discarded. --ours works identically here. This is the one place the "never
 # pick a side" rule above does not apply, because nothing is being picked.
 git checkout --theirs <file>
-node scripts/gds/gen-repo-map.js      # or gen-api-docs.js, gen-diagrams.js
+node scripts/bongos/gen-repo-map.js      # or gen-api-docs.js, gen-diagrams.js
 git add <file> && git commit --no-edit
 ```
 

package/docs/recipes/private-npm-distribution.md

@@ -12,11 +12,11 @@
 
 | Package | What it is | Built by |
 |---|---|---|
-| `@bongos/core` | the platform an instance installs + the `bongos` CLI (`bin`) | `bongos package-core` (`scripts/gds/package-core.js`) — synthesizes the package.json + a pruned lockfile, redacts, and packs a `.tgz` |
+| `@bongos/core` | the platform an instance installs + the `bongos` CLI (`bin`) | `bongos package-core` (`scripts/bongos/package-core.js`) — synthesizes the package.json + a pruned lockfile, redacts, and packs a `.tgz` |
 
 `@bongos/core` carries `publishConfig: { access: "public" }`, and `publishArgs` passes `--access public` as well — both, so neither drifting alone can silently take the package back to restricted ([ADR 0283](../adr/0283-the-core-publishes-publicly-because-access-was-never-the-thing-protecting-it.md)). It read `restricted` until 2026-09-13; what protects the artifact is the no-leak gate on the build, not who may fetch it.
 
-The generated typed client (`node scripts/gds/gen-api-client.js` → `clients/bongos-client/`) is deliberately **not** in this table: it is not published, carries no `publishConfig`, and is consumed by vendoring. See its own README.
+The generated typed client (`node scripts/bongos/gen-api-client.js` → `clients/bongos-client/`) is deliberately **not** in this table: it is not published, carries no `publishConfig`, and is consumed by vendoring. See its own README.
 
 ## One-time owner setup (only the owner can do these)
 
@@ -35,20 +35,20 @@ Always preview with a dry-run first (no upload, no login needed):
 
 ```sh
 # Core — build the tarball and DRY-RUN the publish:
-node scripts/gds/package-core.js --publish
+node scripts/bongos/package-core.js --publish
 ```
 
 Look for `public access` and the `@bongos/core@<version>` line. When it looks right, publish for real (this is **permanent and public** — npm can't delete a name after 72h, and the version is never reusable):
 
 ```sh
 npm login                                         # once per machine (+ 2FA)
-node scripts/gds/package-core.js --publish --live # actually publishes, PUBLIC
+node scripts/bongos/package-core.js --publish --live # actually publishes, PUBLIC
 ```
 
 For the client (note the `./` — without it, npm reads the path as a git package spec, not a folder):
 
 ```sh
-node scripts/gds/gen-api-client.js                # ensure it's fresh
+node scripts/bongos/gen-api-client.js                # ensure it's fresh
 npm pack ./clients/bongos-client --dry-run        # token-free content preview
 npm publish ./clients/bongos-client               # real (publishConfig makes it restricted; needs npm login)
 ```
@@ -64,9 +64,9 @@ The steps below remain as the **manual fallback** (lane disarmed, npm outage, or
 1. **Bump `CORE_VERSION`** in [`src/module-api.js`](../../src/module-api.js) (semver; a **patch** for a fix, **minor** for additive surface — a **major** is a deliberate, human-only event) and append an entry to the release ledger [`docs/module-api-changelog.md`](../module-api-changelog.md) in the same commit ([ADR 0203](../adr/0203-doorway-changelog-out-of-module-api.md) moved that ledger out of `module-api.js`). This bump is a normal claimed task, not a release-tool side effect — the version's provenance stays in the git history + ledger.
 2. **Publish** (owner, from a clean checkout of the released commit):
    ```sh
-   node scripts/gds/package-core.js --publish        # DRY-RUN: runs the fail-closed no-leak gate, previews @bongos/core@<version>
+   node scripts/bongos/package-core.js --publish        # DRY-RUN: runs the fail-closed no-leak gate, previews @bongos/core@<version>
    npm login                                          # once per machine (+ 2FA), or use a granular token with 2FA bypass
-   node scripts/gds/package-core.js --publish --live  # permanent; the no-leak gate must pass or nothing is built/uploaded
+   node scripts/bongos/package-core.js --publish --live  # permanent; the no-leak gate must pass or nothing is built/uploaded
    ```
    The no-leak / mirror-redact gate is **built into the build** — a leaking artifact is never produced, so `--publish` cannot upload one.
 3. **Tag the release** (optional but recommended — the deliberate, auditable marker): `git tag core-v<version> && git push origin core-v<version>`. The tag documents intent; it triggers no CI.
@@ -92,9 +92,9 @@ npm pack @bongos/core --userconfig /dev/null      # no credential is read at all
 
 ## Provisioning: how a new instance gets its core
 
-Provisioning vendors a **tarball** into each new instance repo, and the instance pins it as `file:vendor/bongos-core-<v>.tgz`. `resolveVendorTarball` in [`provision-repo.js`](../../scripts/gds/provision-repo.js) walks a ladder for the freshest correct one: reuse the control plane's own `file:`-pinned tarball → `npm pack` the control plane's registry-installed core ([ADR 0168](../adr/0168-scaffold-packs-installed-core.md)) → rebuild from source. A child is therefore born on the same core its parent is actually running.
+Provisioning vendors a **tarball** into each new instance repo, and the instance pins it as `file:vendor/bongos-core-<v>.tgz`. `resolveVendorTarball` in [`provision-repo.js`](../../scripts/bongos/provision-repo.js) walks a ladder for the freshest correct one: reuse the control plane's own `file:`-pinned tarball → `npm pack` the control plane's registry-installed core ([ADR 0168](../adr/0168-scaffold-packs-installed-core.md)) → rebuild from source. A child is therefore born on the same core its parent is actually running.
 
-**There is no token in any of this, and no opt-in fork either.** An earlier design gated a registry pull behind `PROVISION_CORE_FROM_REGISTRY=1` plus a read-only `NPM_TOKEN`, fail-soft to vendoring when the credential was absent. [`fcea51ca`](https://github.com/example-owner/cloud-bongos/commit/fcea51ca) deleted that whole path along with `scripts/gds/npmrc.js`: two install modes diverging on an environment variable is a defect shape, and the credential they diverged on stopped being necessary the moment the package went public. `bongos init --registry-core` and the env-fed `.npmrc` it used to write are gone with it.
+**There is no token in any of this, and no opt-in fork either.** An earlier design gated a registry pull behind `PROVISION_CORE_FROM_REGISTRY=1` plus a read-only `NPM_TOKEN`, fail-soft to vendoring when the credential was absent. [`fcea51ca`](https://github.com/example-owner/cloud-bongos/commit/fcea51ca) deleted that whole path along with `scripts/bongos/npmrc.js`: two install modes diverging on an environment variable is a defect shape, and the credential they diverged on stopped being necessary the moment the package went public. `bongos init --registry-core` and the env-fed `.npmrc` it used to write are gone with it.
 
 > **Vendoring is not a stale-by-design choice.** It is what keeps twenty co-tenant instances pinned to a local path with no registry channel to follow — going public was necessary to fix that, and is not sufficient ([ADR 0283](../adr/0283-the-core-publishes-publicly-because-access-was-never-the-thing-protecting-it.md)). Moving a co-tenant forward is still the `package-core` → scp → `bongos upgrade` path.
 

package/docs/recipes/redteam-patrol.md

@@ -10,10 +10,10 @@ metadata), and **slow sweeps**.
 ## Running it
 
 ```bash
-node scripts/gds/redteam-patrol.js            # dry run — print, file nothing
-node scripts/gds/redteam-patrol.js --file     # the weekly cron form — files reports
-node scripts/gds/redteam-patrol.js --canary          # self-test detection only
-node scripts/gds/redteam-patrol.js --canary --file   # prove the full pipe (files + dispute-closes)
+node scripts/bongos/redteam-patrol.js            # dry run — print, file nothing
+node scripts/bongos/redteam-patrol.js --file     # the weekly cron form — files reports
+node scripts/bongos/redteam-patrol.js --canary          # self-test detection only
+node scripts/bongos/redteam-patrol.js --canary --file   # prove the full pipe (files + dispute-closes)
 ```
 
 ## What actually fires it
@@ -32,7 +32,7 @@ watch drift measured in days (release-age, new advisories), not minutes.
 
 **The cadence and the cron are checked against each other.** `cadence: weekly` in
 the SKILL.md and `cron: '17 6 * * 1'` in the workflow must agree, or
-`scripts/gds/routine-schedule.js` (fitness Check 25) fails the merge gate — as it
+`scripts/bongos/routine-schedule.js` (fitness Check 25) fails the merge gate — as it
 does if the workflow stops firing the routine, or fires one that no longer
 exists. Change one and change the other in the same commit. The odd minute is
 deliberate: GitHub queues scheduled workflows and top-of-hour is its worst

package/docs/recipes/render-pilot.md

@@ -8,7 +8,7 @@ The executable half of [task 1004142](https://cloudbongos.com/builders#/task/100
 
 > **Corrections, checked against mercury's vendored core (1.19.305) on 2026-09-28 (task 1004142).** Six things in §4–§6 below would have failed on the real repo; §4's payload now carries all of them, and the list says why. Where the prose below still disagrees with this box, this box wins:
 >
-> 1. **There is no `npm start`.** An adopted instance's `package.json` has only the `@bongos/core` dependency, no scripts. The start command is `node node_modules/@bongos/core/src/platform-server.js`, the same thing the box's unit runs (`serviceUnit` in `scripts/gds/provision-units.js`). Set it explicitly, because the repo's `Procfile` starts the owner's Python app.
+> 1. **There is no `npm start`.** An adopted instance's `package.json` has only the `@bongos/core` dependency, no scripts. The start command is `node node_modules/@bongos/core/src/platform-server.js`, the same thing the box's unit runs (`serviceUnit` in `scripts/bongos/provision-units.js`). Set it explicitly, because the repo's `Procfile` starts the owner's Python app.
 > 2. **The env prefix is the instance's own pack, not the neutral one.** mercury's `config/branding.json` pins `envPrefix: "CLOUDBONGOS"`, so every `BONGOS_*` in §4 and §5 is `CLOUDBONGOS_*` for this repo. A wrong prefix is silently ignored and the hall never loads.
 > 3. **Set `BUILDER_SECRET_KEY`.** Without it `src/bongos/secret-box.js` falls back to a key file in the config home, and Render wipes the disk on every deploy. Each deploy would mint a new key and orphan every stored per-builder secret. A random 32-byte hex value held in Render's env is enough.
 > 4. **Migrations run as Render's pre-deploy command**, as `bash node_modules/@bongos/core/scripts/migrate.sh`. `migrate.sh` addresses the database as `psql -d "$PGDATABASE"`, so set `PGDATABASE` to the same connection URL as `DATABASE_URL`. Whether Render's Node runtime ships `psql` is one of the things the pilot measures.
@@ -117,7 +117,7 @@ Returns `password`, `internalConnectionString`, `externalConnectionString`, `psq
 
 Bongos reads `DATABASE_URL` first and falls back to the `PG*` family (`src/bongos/pool.js:56`), so Render's connection string wires in directly — **none of the `PGHOST`/`PGDATABASE`/`PGUSER`/`PGPASSWORD` lines `webEnvBody` writes on the box are needed here.** That is the single biggest simplification Render buys, and it is worth stating in the standup leg's comments.
 
-The env prefix is **`BONGOS`** (`config/branding.neutral.json` → `envPrefix`). The variables below are the Render translation of `webEnvBody` in `scripts/gds/provision-units.js:192` — read that function, not this list, if the two ever disagree.
+The env prefix is **`BONGOS`** (`config/branding.neutral.json` → `envPrefix`). The variables below are the Render translation of `webEnvBody` in `scripts/bongos/provision-units.js:192` — read that function, not this list, if the two ever disagree.
 
 ```bash
 curl -sS -X POST -H "Authorization: Bearer $RENDER_TOKEN" -H 'Content-Type: application/json' \

package/docs/recipes/reranking-a-goals-board.md

@@ -35,7 +35,7 @@ Three rules that did the most work in practice:
 
 ```bash
 echo '{"priority":2}' > /tmp/p.json
-node scripts/gds/api.js PATCH /api/bongos/tasks/1002884 --body-file /tmp/p.json
+node scripts/bongos/api.js PATCH /api/bongos/tasks/1002884 --body-file /tmp/p.json
 ```
 
 Two things to know before you batch this:
@@ -54,7 +54,7 @@ Core reaches a live instance only through a release plus a pin move (gate 3, [`c
 Generate the statements from a checked map rather than typing ids, keep it in one transaction, and **write the revert first** — the prior values are only recoverable if you captured them before the write:
 
 ```bash
-node scripts/gds/api.js GET '/api/bongos/tasks?goal_id=<goal>&limit=200' --quiet > before.json
+node scripts/bongos/api.js GET '/api/bongos/tasks?goal_id=<goal>&limit=200' --quiet > before.json
 ```
 
 Then group the ids by target tier and emit one `UPDATE` per tier, guarded to the goal and to open statuses so a concurrent ship cannot be clobbered:

package/docs/recipes/search-index-ingestion.md

@@ -1,12 +1,12 @@
 # Recipe — Bongos search-index ingestion (repo markdown)
 
-How the `search_chunks` index (the recall layer, [ADR 0060](../adr/0060-gds-retrieval-layer.md)) gets populated from repo markdown, and how to operate it. Read before touching `scripts/gds/search-ingest-md.js` or the deploy hook.
+How the `search_chunks` index (the recall layer, [ADR 0060](../adr/0060-gds-retrieval-layer.md)) gets populated from repo markdown, and how to operate it. Read before touching `scripts/bongos/search-ingest-md.js` or the deploy hook.
 
 > The query side is [`modules/memory/search.js`](../../modules/memory/search.js) + [`POST /api/bongos/search`](../../modules/memory/routes/search.js) ([#949](https://example.com/builders#/task/949)); rank/owner scoping + its isolation suite are [#950](https://example.com/builders#/task/950). Ingestion has two halves: **repo markdown** (this recipe's first sections — [#947](https://example.com/builders#/task/947), the deploy hook) and **DB prose** (the [DB-prose nightly](#db-prose-nightly-timer) section below — [#948](https://example.com/builders#/task/948), a systemd timer).
 
 ## What it does
 
-`node scripts/gds/search-ingest-md.js` walks the repo's markdown (~226 files), chunks each file via the heading-aware chunker ([`modules/memory/search-chunker.js`](../../modules/memory/search-chunker.js)), and upserts the chunks into `search_chunks`:
+`node scripts/bongos/search-ingest-md.js` walks the repo's markdown (~226 files), chunks each file via the heading-aware chunker ([`modules/memory/search-chunker.js`](../../modules/memory/search-chunker.js)), and upserts the chunks into `search_chunks`:
 
 - **Delta-driven.** Each chunk's `content_hash` (sha256 of its body) is the change key. The upsert's `ON CONFLICT … DO UPDATE … WHERE content_hash IS DISTINCT FROM EXCLUDED.content_hash` makes an unchanged chunk a **no-op** (no row rewrite). A re-run over an unchanged tree writes nothing.
 - **Prunes shrinkage.** If a file loses sections, chunks beyond the new count are deleted; if a file is removed from the tree entirely, all its chunks are deleted (`source_kind='doc' AND source_ref NOT IN (present)`).
@@ -22,12 +22,12 @@ A **non-blocking step in the prod deploy** (`scripts/deploy/deploy-prod.sh` (ins
 
 ```bash
 # Dry-run: report file/chunk counts + which sources are metic-tagged. No DB, no writes.
-node scripts/gds/search-ingest-md.js --dry-run
+node scripts/bongos/search-ingest-md.js --dry-run
 
 # Full ingest (writes to search_chunks). Idempotent — safe to re-run; unchanged
 # chunks are skipped. Run on the droplet (DB on the local socket) or anywhere the
 # Bongos Postgres env (PGHOST/PGDATABASE) resolves.
-node scripts/gds/search-ingest-md.js
+node scripts/bongos/search-ingest-md.js
 
 # Initial backfill after first deploy of the recall layer: just run the full
 # ingest once on the droplet — it indexes the whole corpus from empty.
@@ -37,7 +37,7 @@ Output reports `inserted / updated / unchanged / pruned / deleted_sources_chunks
 
 ## DB prose (nightly timer)
 
-`node scripts/gds/search-ingest-db.js` indexes the prose that lives in the DB, not in git, as `source_kind='db'`: task descriptions + value summaries (`task:<id>`), learnings (`learning:<id>`), idea inbox (`idea:<id>`), done-when criteria (`criterion:<id>`), blockers (`blocker:<id>`), session-log notes (`session_log:<id>`), grade notes (`grade:<id>`), per-builder memory (`memory:<builder>:<path>`), and recent git commit subjects (`commit:<sha>`). Same delta-by-content_hash + prune-vanished behavior as the repo-md ingester.
+`node scripts/bongos/search-ingest-db.js` indexes the prose that lives in the DB, not in git, as `source_kind='db'`: task descriptions + value summaries (`task:<id>`), learnings (`learning:<id>`), idea inbox (`idea:<id>`), done-when criteria (`criterion:<id>`), blockers (`blocker:<id>`), session-log notes (`session_log:<id>`), grade notes (`grade:<id>`), per-builder memory (`memory:<builder>:<path>`), and recent git commit subjects (`commit:<sha>`). Same delta-by-content_hash + prune-vanished behavior as the repo-md ingester.
 
 Security ([ADR 0060](../adr/0060-gds-retrieval-layer.md) §6 / [ADR 0016](../adr/0016-trust-boundary-server-enforced-permissions.md) / [ADR 0022](../adr/0022-secrets-policy.md)):
 

package/docs/recipes/self-host.md

@@ -39,7 +39,7 @@ Author `config/branding.json` from the neutral starter — see [the branding con
 
 **Or scaffold it with `bongos init`** ([task #1204](https://example.com/builders#/task/1204)): a short interview (or `bongos init --from spec.json` for a hands-free / CI run) that writes both config files, **seeds your first version + its done-when goal**, and **files the human-only kickoff steps** (register a GitHub OAuth app, first owner sign-in, repo binding, admission) as real tracked tasks — so a fresh instance has a claimable queue on day one instead of an empty hall. It never invents your branding (it points you at the fill prompt for that). Preview the whole plan with `bongos init --dry-run`.
 
-**Production hosting, optional (the `provisioning` module — [ADR 0111](../adr/0111-instance-hosting-provisioning-module.md) §3).** If you enable the `provisioning` module and answer the interview's hosting questions (shape — co-tenant `$0` or a dedicated droplet — bring-your-own domain, credential ref, tier), init turns those answers into a real **provisioning request** (a queued `provision` intent the control-plane runner drains) instead of only filing a manual "production topology" task. **A queued request does nothing until a runner drains it:** on the control plane that is a systemd timer running `node scripts/gds/provision.js run-intents --apply`. This Docker image now carries the tools the scaffold needs — git, and a core it can package out of its own `.git`-less checkout (task 1003995) — and supervision is no longer systemd-only: the runner picks a process manager, falling back to supervisord where systemd is not running (task 1003997, [ADR 0306](../adr/0306-instance-supervision-is-a-seam-with-systemd-as-the-default.md)). Three standup legs assumed a systemd box, and on a compose self-host a new project still cannot stand up: the container has no reverse proxy for a child instance's front door, cannot create the per-instance unix account that isolates one instance from another, and installed its backup dir as a hardcoded founder user. **That third leg is fixed** (task 1002719): the backup dir's owner is `PROVISION_APP_USER`, else the account the runner runs as (root is refused), so the standup no longer dies `invalid user` on a host without the founder's account. **The other two now refuse instead of failing opaquely, each for its own reason** — so fixing one cannot silently re-open the other. **The ingress leg now refuses instead of failing opaquely** (task 1004017, [ADR 0315](../adr/0315-a-plane-with-no-proxy-is-refused-not-given-a-no-op-ingress.md)): provisioning probes the plane with `caddy version` and returns `Ingress preflight failed: …` naming the missing proxy, before it writes a Caddy snippet or reloads anything. Previously a domained child was told to edit an `/etc/caddy/Caddyfile` the container does not have, and a domainless one crashed on the snippet write. Giving the container a real front door is still unbuilt — the refusal closes the failure mode, not the capability. **The identity leg refuses too** (task 1004018, [ADR 0317](../adr/0317-a-plane-that-cannot-give-an-instance-its-own-account-is-refused.md)): provisioning probes whether the runner can reach root on this plane and returns `Account preflight failed: …` before any mutation, because `useradd` cannot run under `USER node` and every child there would otherwise share one uid — the sibling-secret vector [ADR 0281](../adr/0281-an-instance-identity-is-its-own-unix-account-and-pg-role.md) exists to close. It is a capability question, not a knob: there is no setting that accepts a shared uid. Note supervisord has no timer concept either, so a container-hosted instance gets no automatic DB backup — the standup log prints the `crontab` line to add instead. The two irreducibly-human legs — the GitHub OAuth app and the first owner sign-in — stay guided/manual. If the module isn't enabled on the target instance, init falls back to the manual production-topology task, so nothing is silently skipped.
+**Production hosting, optional (the `provisioning` module — [ADR 0111](../adr/0111-instance-hosting-provisioning-module.md) §3).** If you enable the `provisioning` module and answer the interview's hosting questions (shape — co-tenant `$0` or a dedicated droplet — bring-your-own domain, credential ref, tier), init turns those answers into a real **provisioning request** (a queued `provision` intent the control-plane runner drains) instead of only filing a manual "production topology" task. **A queued request does nothing until a runner drains it:** on the control plane that is a systemd timer running `node scripts/bongos/provision.js run-intents --apply`. This Docker image now carries the tools the scaffold needs — git, and a core it can package out of its own `.git`-less checkout (task 1003995) — and supervision is no longer systemd-only: the runner picks a process manager, falling back to supervisord where systemd is not running (task 1003997, [ADR 0306](../adr/0306-instance-supervision-is-a-seam-with-systemd-as-the-default.md)). Three standup legs assumed a systemd box, and on a compose self-host a new project still cannot stand up: the container has no reverse proxy for a child instance's front door, cannot create the per-instance unix account that isolates one instance from another, and installed its backup dir as a hardcoded founder user. **That third leg is fixed** (task 1002719): the backup dir's owner is `PROVISION_APP_USER`, else the account the runner runs as (root is refused), so the standup no longer dies `invalid user` on a host without the founder's account. **The other two now refuse instead of failing opaquely, each for its own reason** — so fixing one cannot silently re-open the other. **The ingress leg now refuses instead of failing opaquely** (task 1004017, [ADR 0315](../adr/0315-a-plane-with-no-proxy-is-refused-not-given-a-no-op-ingress.md)): provisioning probes the plane with `caddy version` and returns `Ingress preflight failed: …` naming the missing proxy, before it writes a Caddy snippet or reloads anything. Previously a domained child was told to edit an `/etc/caddy/Caddyfile` the container does not have, and a domainless one crashed on the snippet write. Giving the container a real front door is still unbuilt — the refusal closes the failure mode, not the capability. **The identity leg refuses too** (task 1004018, [ADR 0317](../adr/0317-a-plane-that-cannot-give-an-instance-its-own-account-is-refused.md)): provisioning probes whether the runner can reach root on this plane and returns `Account preflight failed: …` before any mutation, because `useradd` cannot run under `USER node` and every child there would otherwise share one uid — the sibling-secret vector [ADR 0281](../adr/0281-an-instance-identity-is-its-own-unix-account-and-pg-role.md) exists to close. It is a capability question, not a knob: there is no setting that accepts a shared uid. Note supervisord has no timer concept either, so a container-hosted instance gets no automatic DB backup — the standup log prints the `crontab` line to add instead. The two irreducibly-human legs — the GitHub OAuth app and the first owner sign-in — stay guided/manual. If the module isn't enabled on the target instance, init falls back to the manual production-topology task, so nothing is silently skipped.
 
 ## Configuration surface
 

package/docs/recipes/ship-and-regrade.md

@@ -20,7 +20,7 @@ The grader reads **committed history** (`merge-base origin/main HEAD`…`HEAD`),
 
 If the grade at step 2 **fails**, the task stays at `completed` but the claim is already gone (resolved at step 1). Historically there was no clean way back in — this was the **task-595-regrade-gap**, re-hit on [#600](https://example.com/builders#/task/600) and [#671](https://example.com/builders#/task/671)/[#673](https://example.com/builders#/task/673):
 
-- `node scripts/gds/claim.js <id>` → refuses, "not ready (current status: completed)".
+- `node scripts/bongos/claim.js <id>` → refuses, "not ready (current status: completed)".
 - `PATCH /tasks/:id {status:ready}` → refuses, `status_not_patchable`.
 - `POST /tasks/:id/promote` → refuses, `cannot_promote` (only works from backlog).
 - Re-running `ship.js` → "You don't have an active claim".
@@ -30,7 +30,7 @@ The only escapes were the Archon `/confirm` override (which *bypasses* the grade
 ## The fix: `--regrade` ([#678](https://example.com/builders#/task/678))
 
 ```bash
-node scripts/gds/ship.js <task-id> --regrade
+node scripts/bongos/ship.js <task-id> --regrade
 ```
 
 This re-runs **ONLY the grade step** against the committed diff, with **no claim required**:
@@ -46,9 +46,9 @@ Flags: `--summary "…"` (defaults to the task's stored value_summary), `--no-me
 ### Typical recovery loop
 
 ```bash
-node scripts/gds/ship.js 600            # grade FAILS → task at completed, claim gone
+node scripts/bongos/ship.js 600            # grade FAILS → task at completed, claim gone
 # … read the issues, fix them, commit on the same branch …
-node scripts/gds/ship.js 600 --regrade  # re-grades the committed diff; on pass → confirmed → shipped
+node scripts/bongos/ship.js 600 --regrade  # re-grades the committed diff; on pass → confirmed → shipped
 ```
 
 ## Why `/grade` is rank-open (and the ownership check is a UX guard)

package/docs/recipes/staging-environment.md

@@ -189,7 +189,7 @@ done
 # Expect three 200s.
 ```
 
-The same shape as `scripts/gds/smoke-gds.js` but pointed at staging. A future task could parameterize `smoke-gds.js` to accept a host arg — filed as a follow-up.
+The same shape as `scripts/bongos/smoke-gds.js` but pointed at staging. A future task could parameterize `smoke-gds.js` to accept a host arg — filed as a follow-up.
 
 ## Freezing staging again (when you stop using it actively)
 

package/docs/recipes/standalone-live-docs.md

@@ -22,7 +22,7 @@ Only `session-log-index.md` is regenerated **on deploy** — it's the one whole-
 The one-liner every standalone deploy script must run **after** `git reset --hard origin/main` + migrate:
 
 ```bash
-node node_modules/@bongos/core/scripts/gds/regen-instance-docs.js
+node node_modules/@bongos/core/scripts/bongos/regen-instance-docs.js
 ```
 
 Run it with `cwd` = the instance repo root (or set `BONGOS_INSTANCE_ROOT=<instance-dir>`). It resolves the instance root, regenerates `docs/session-log-index.md` there, is **best-effort** (always exits 0), and is **LOUD** on failure (`::ERROR::` → journald). A stale nav doc is tolerable; a failed deploy is not (ADR 0110 §2 "accepted staleness").

package/docs/recipes/ui-look-before-you-ship.md

@@ -24,7 +24,7 @@ FAIL=featured,progress node modules/ui-design/kit/serve.js   # those feeds answe
 STYLE=grove node modules/ui-design/kit/serve.js              # under a look from the style library (modules/ui-design/styles/; task 1003323)
 ```
 
-The stub runs the page through the **instance's real transforms** — the apex-only strip, the brand-token stamp, the pack's theme injection, run by the core-side command `scripts/gds/ui-kit-transform.js` (a module may not require core, so the stub spawns the command and memoises the page) — then the content-hash `?v=` stamp, with the instance's own branding pack, and answers the public feeds from `kit/fixtures/`. It also serves `docs/` raw, so a mock under `docs/design/mocks/` renders with its relative links: `http://127.0.0.1:3412/docs/design/mocks/hub/v2.html`.
+The stub runs the page through the **instance's real transforms** — the apex-only strip, the brand-token stamp, the pack's theme injection, run by the core-side command `scripts/bongos/ui-kit-transform.js` (a module may not require core, so the stub spawns the command and memoises the page) — then the content-hash `?v=` stamp, with the instance's own branding pack, and answers the public feeds from `kit/fixtures/`. It also serves `docs/` raw, so a mock under `docs/design/mocks/` renders with its relative links: `http://127.0.0.1:3412/docs/design/mocks/hub/v2.html`.
 
 `SURFACE` is a checkout directory (`modules/hall-ui/public`) or a module key whose manifest declares a `webSurfaces` dir (`public-landing`, `hall-ui`). `PREFIX` is the URL prefix the surface's pages and assets live under (the hall's is `/builders/`).
 
@@ -54,7 +54,7 @@ node modules/ui-design/kit/render.js --page / --style expedition        # the sa
 
 Then a state's own `expect` (a band open, a dialog present, a field's value, a class, a query param). Shots and `report.json` land in `%TMP%/ui-design-kit/<surface>/<page>/` (or `--out`). Exit 0 is `ALL CLEAN`; 1 lists the problems; 2 is a broken states file, named line by line.
 
-**The fit floors run on their own before you ship.** `/ship-check` renders the pages your branch changed (`node scripts/gds/render-check.js`: a page or its script reaches its own states file, a shared script or sheet reaches every page whose HTML names it) at 1280 + 390 and lists any `text-fit` / `sibling-overlap` finding by element and page — an advisory row, never a gate ([ADR 0329](../adr/0329-the-rendered-fit-check-is-a-kit-floor-and-an-advisory-ship-check-row.md)). `--files a,b` checks named paths instead of the branch diff.
+**The fit floors run on their own before you ship.** `/ship-check` renders the pages your branch changed (`node scripts/bongos/render-check.js`: a page or its script reaches its own states file, a shared script or sheet reaches every page whose HTML names it) at 1280 + 390 and lists any `text-fit` / `sibling-overlap` finding by element and page — an advisory row, never a gate ([ADR 0329](../adr/0329-the-rendered-fit-check-is-a-kit-floor-and-an-advisory-ship-check-row.md)). `--files a,b` checks named paths instead of the branch diff.
 
 ### The states file — `<surface>/<page>.states.json`
 

package/docs/recipes/upgrading-the-core.md

@@ -2,7 +2,7 @@
 
 > **This is one leg of three.** For the whole path from a change on core `main` to a live instance — including how to tell whether *this* instance takes a vendored tarball or a registry version — start at [the core release pipeline](core-release-pipeline.md).
 >
-> The R86 update-consumption channel ([ADR 0100](../adr/0100-two-repo-instance-model.md) §2, [ADR 0103](../adr/0103-core-first-extraction-cloud-bongos-trunk.md) §4, task [#1690](https://example.com/builders#/task/1690)). How a **two-repo consumer instance** — one that installs `@bongos/core` as a vendored-tarball dependency — pulls the core from version N → N+1. Tooling: [`scripts/gds/upgrade.js`](../../scripts/gds/upgrade.js) (`bongos upgrade`). First proven live on emersonian-circles 1.15.0 → 1.16.0 (task [#1976](https://example.com/builders#/task/1976)).
+> The R86 update-consumption channel ([ADR 0100](../adr/0100-two-repo-instance-model.md) §2, [ADR 0103](../adr/0103-core-first-extraction-cloud-bongos-trunk.md) §4, task [#1690](https://example.com/builders#/task/1690)). How a **two-repo consumer instance** — one that installs `@bongos/core` as a vendored-tarball dependency — pulls the core from version N → N+1. Tooling: [`scripts/bongos/upgrade.js`](../../scripts/bongos/upgrade.js) (`bongos upgrade`). First proven live on emersonian-circles 1.15.0 → 1.16.0 (task [#1976](https://example.com/builders#/task/1976)).
 
 > **Not for a hosted project's builders.** Everything here runs on the server where the project lives. On a project its operator runs, `bongos upgrade` from your own computer says so and stops; ask for the upgrade through **Settings → Software update** or `bongos feedback "…"` instead — never write server steps or guess its names (task 1004596; [the release pipeline](core-release-pipeline.md) has the detail).
 
@@ -30,7 +30,7 @@ The channel ships *in* the core. On the FIRST bump, the consumer's installed cor
 
 ```bash
 cd /tmp && rm -rf pkg && mkdir pkg && tar xzf bongos-core-<version>.tgz -C pkg
-node /tmp/pkg/package/scripts/gds/upgrade.js --to <version> --from /tmp/bongos-core-<version>.tgz --instance <consumer-root> …
+node /tmp/pkg/package/scripts/bongos/upgrade.js --to <version> --from /tmp/bongos-core-<version>.tgz --instance <consumer-root> …
 ```
 
 Once a consumer is on a core that carries the channel, its own `bongos upgrade` drives later bumps.
@@ -41,7 +41,7 @@ The instance runs on the droplet (co-tenant): systemd `emersonian-circles.servic
 
 1. **Cut the canonical tarball from `main`** (after the core change has merged, so the pin is a real release):
    ```bash
-   node scripts/gds/package-core.js --version <version>   # → dist/bongos-core-<version>.tgz (+ manifest)
+   node scripts/bongos/package-core.js --version <version>   # → dist/bongos-core-<version>.tgz (+ manifest)
    ```
    `package-core` archives committed `HEAD`, **not the working tree** — commit + merge first, then verify the artifact (`ls dist/bongos-core-<version>/…`).
 2. **Back up the instance DB** — `pg_dump emersonian_circles | gzip > /tmp/…sql.gz`.
@@ -49,7 +49,7 @@ The instance runs on the droplet (co-tenant): systemd `emersonian-circles.servic
 4. **`--dry-run` first**, then the real run — extracted-package bootstrap, with the instance DB pinned:
    ```bash
    PGDATABASE=emersonian_circles BONGOS_INSTANCE_ROOT=/home/lars/emersonian-circles \
-     node /tmp/pkg/package/scripts/gds/upgrade.js --to <version> --from /tmp/bongos-core-<version>.tgz \
+     node /tmp/pkg/package/scripts/bongos/upgrade.js --to <version> --from /tmp/bongos-core-<version>.tgz \
        --instance /home/lars/emersonian-circles \
        --restart-cmd "sudo systemctl restart emersonian-circles.service" \
        --health-url http://127.0.0.1:3004/healthz
@@ -74,7 +74,7 @@ By default (`--rollback-on-failure`, ON unless `--no-rollback-on-failure`) the c
 
 **The DB is NOT rolled back — only the code pin.** Core migrations are additive + forward-safe (the core migration rule), so an already-applied migration is left in place; a *failed* migration is never recorded in `schema_migrations`, so a retry re-runs it cleanly. The reversal is recorded via the always-present `note` column (not a new `outcome` column) so it lands even in the failed-migrate path — where a newer column wouldn't yet exist on that instance.
 
-> **The forward-safe rule is now enforced, not just documented** (task [#1002223](https://example.com/builders#/task/1002223), audit H10). A core migration that DROPs/RENAMEs/retypes existing state (which would strand the rolled-back old code on the new schema) fails the [`tests/migrations_forward_safe.mjs`](../../tests/migrations_forward_safe.mjs) unit gate unless it carries an explicit `-- forward-unsafe: <reason>` acknowledgement pragma. `migrate.sh` also prints a non-fatal notice at apply time (via [`scripts/gds/lint-migrations.js`](../../scripts/gds/lint-migrations.js)). Additive migrations (the norm) need no annotation.
+> **The forward-safe rule is now enforced, not just documented** (task [#1002223](https://example.com/builders#/task/1002223), audit H10). A core migration that DROPs/RENAMEs/retypes existing state (which would strand the rolled-back old code on the new schema) fails the [`tests/migrations_forward_safe.mjs`](../../tests/migrations_forward_safe.mjs) unit gate unless it carries an explicit `-- forward-unsafe: <reason>` acknowledgement pragma. `migrate.sh` also prints a non-fatal notice at apply time (via [`scripts/bongos/lint-migrations.js`](../../scripts/bongos/lint-migrations.js)). Additive migrations (the norm) need no annotation.
 
 **Proven live on demo.cloudbongos.com** (task [#2157](https://example.com/builders#/task/2157)): demo, on rollback-capable 1.17.3, was upgraded to a canary carrying a deliberately-failing migration. Migrate raised → the channel auto-reverted the pin to 1.17.3, reinstalled + restarted it, `/healthz` stayed 200 (**zero downtime** — the failure was at migrate, before the restart), and a `rolled_back` ledger row was written. This is the safety gate the unattended patch-only auto-upgrade subscription (task [#2150](https://example.com/builders#/task/2150)) depends on.
 
@@ -135,7 +135,7 @@ Each subscribed instance: read its installed core → ask the registry (`npm vie
 
 #### Run the sweep from the installed core (task 1004307)
 
-The sweep's body is `scripts/gds/update-sweep.js`, which ships in every core release.
+The sweep's body is `scripts/bongos/update-sweep.js`, which ships in every core release.
 `.claude/scheduled-tasks/core-update-subscription/subscribe.js` is only a shim. A control plane
 should run the body **straight from the core it installs**, so each upgrade brings the next sweep
 current code. A sweep run from a checkout is only as new as that checkout, and on cloudbongos.com
@@ -146,7 +146,7 @@ one sat frozen for a month while every fix to the lane went inert. The roster st
 # /etc/systemd/system/<instance>-core-update-subscription.service.d/run-from-core.conf
 [Service]
 ExecStart=
-ExecStart=/usr/bin/node <served-root>/node_modules/@bongos/core/scripts/gds/update-sweep.js --apply --instance <roster-root>
+ExecStart=/usr/bin/node <served-root>/node_modules/@bongos/core/scripts/bongos/update-sweep.js --apply --instance <roster-root>
 Environment=UPDATE_CHANNEL_DB=<control-plane-db>
 ```
 
@@ -156,7 +156,7 @@ unit's user before restarting anything. Its first line names the core doing the
 entry's line names its channel and source:
 
 ```bash
-sudo -u <user> env UPDATE_CHANNEL_DB=<control-plane-db> node <served-root>/node_modules/@bongos/core/scripts/gds/update-sweep.js --instance <roster-root>
+sudo -u <user> env UPDATE_CHANNEL_DB=<control-plane-db> node <served-root>/node_modules/@bongos/core/scripts/bongos/update-sweep.js --instance <roster-root>
 ```
 
 Every run prints `update-sweep · running from <core dir> (core <version>) · roster <root>`, so
@@ -225,9 +225,9 @@ running a go-live.
 
 ## Gotchas
 
-- **The Deploy door fixes four known snags by itself, once** (task 1004448, `scripts/gds/wedge-remedy.js`). When a core move through `/deploy` fails on a **dirty tree** (it commits the tracked changes inside the project), a **full disk** (it prunes that project's own nightly dumps down to the newest 7) a **database behind its code** (it migrates that database with its own `PGDATABASE` before the code moves) or a migration refused with **`must be owner of`** (a project with its own database account whose tables postgres made at provisioning — it hands that project's schema to its account as postgres, task 1004735; projects provisioned since get this at setup), the runner applies the fix, records a `core-upgrade-remedy` event on the project, and tries the move once more on the next tick. If the retry fails for the same reason, or the fix itself fails, the move is retired as `unknown` (`remedy_did_not_hold` / `remedy_failed`) for a person — never a second fix. The manual fixes below still apply to the unattended nightly sweep, which does not go through the door.
-- **A core move uses TWO unix accounts, and which one does what is not interchangeable** (task 1004512, `resolveRunAs` in `scripts/gds/provision-core-upgrade.js`). The move runs as the account that owns the checkout — the app user, on every hosting shape — because everything it writes lives there: the pin, `node_modules`, `.claude/`, the pin commit, and the `git status` it starts with. Only the **database** steps (identity pre-check, migrate, the ledger insert) run as the project's own `bongos-<slug>` account, handed over with `--migrate-as`; that account owns the database and `PUBLIC` has no `CONNECT`, so nothing else can reach it. The flag is emitted only when the two differ, so a control plane and a project older than ADR 0281 run the command they always did. *The symptom when this is wrong:* every move on a project with its own account fails with `fatal: detected dubious ownership in repository`, which the clean-tree pre-flight used to report as a dirty tree — the remedy below then commits a tree nobody touched and the retry fails identically. A `git status` that could not answer is now its own reason (`git_unreadable`, class `unknown`), so it goes to a person instead of to that fix. **Do not "fix" a recurrence with `safe.directory`** — git would then read the tree and the next write step would fail instead.
-- **A Deploy-door move nobody can fix files a blocker and posts to Discord — once** (task 1004449, `scripts/gds/move-escalation.js`). A move retired as `unknown` (including `remedy_did_not_hold`, `remedy_failed` and a failed rollback) files one blocker (`source=provisioning`, `source_ref=core-move:<instance id>:<intent id>`) with the reason and what the move reported, and posts one notice to `#ship-news` that names the project only if it is public. The next core move on that project that lands closes the blocker by itself and posts an all-clear. Refusals the owner can act on (`needs_decision`) are shown on the deploy page instead, not filed.
+- **The Deploy door fixes four known snags by itself, once** (task 1004448, `scripts/bongos/wedge-remedy.js`). When a core move through `/deploy` fails on a **dirty tree** (it commits the tracked changes inside the project), a **full disk** (it prunes that project's own nightly dumps down to the newest 7) a **database behind its code** (it migrates that database with its own `PGDATABASE` before the code moves) or a migration refused with **`must be owner of`** (a project with its own database account whose tables postgres made at provisioning — it hands that project's schema to its account as postgres, task 1004735; projects provisioned since get this at setup), the runner applies the fix, records a `core-upgrade-remedy` event on the project, and tries the move once more on the next tick. If the retry fails for the same reason, or the fix itself fails, the move is retired as `unknown` (`remedy_did_not_hold` / `remedy_failed`) for a person — never a second fix. The manual fixes below still apply to the unattended nightly sweep, which does not go through the door.
+- **A core move uses TWO unix accounts, and which one does what is not interchangeable** (task 1004512, `resolveRunAs` in `scripts/bongos/provision-core-upgrade.js`). The move runs as the account that owns the checkout — the app user, on every hosting shape — because everything it writes lives there: the pin, `node_modules`, `.claude/`, the pin commit, and the `git status` it starts with. Only the **database** steps (identity pre-check, migrate, the ledger insert) run as the project's own `bongos-<slug>` account, handed over with `--migrate-as`; that account owns the database and `PUBLIC` has no `CONNECT`, so nothing else can reach it. The flag is emitted only when the two differ, so a control plane and a project older than ADR 0281 run the command they always did. *The symptom when this is wrong:* every move on a project with its own account fails with `fatal: detected dubious ownership in repository`, which the clean-tree pre-flight used to report as a dirty tree — the remedy below then commits a tree nobody touched and the retry fails identically. A `git status` that could not answer is now its own reason (`git_unreadable`, class `unknown`), so it goes to a person instead of to that fix. **Do not "fix" a recurrence with `safe.directory`** — git would then read the tree and the next write step would fail instead.
+- **A Deploy-door move nobody can fix files a blocker and posts to Discord — once** (task 1004449, `scripts/bongos/move-escalation.js`). A move retired as `unknown` (including `remedy_did_not_hold`, `remedy_failed` and a failed rollback) files one blocker (`source=provisioning`, `source_ref=core-move:<instance id>:<intent id>`) with the reason and what the move reported, and posts one notice to `#ship-news` that names the project only if it is public. The next core move on that project that lands closes the blocker by itself and posts an all-clear. Refusals the owner can act on (`needs_decision`) are shown on the deploy page instead, not filed.
 - **`--registry` needs no credential at all** (task 1003878). `@bongos/core` is **public** on npm (task 1003872), so `bongos upgrade --registry` resolves it from the default registry like any other dependency — no token, no login, and no instance `.npmrc`. An install failure on this path is therefore a *real* failure (network, registry outage, or a version that was never published), never a missing credential.
   *History, so the symptom is recognisable on an old instance:* the core used to publish private, and the instance `.npmrc` read `_authToken=<redacted> npm gives that per-project key precedence, so with the env var unset it expanded EMPTY and **masked a perfectly valid literal token in `~/.npmrc`** — npm went anonymous, the private core 404'd, and the error blamed a credential the box actually held. Task 1002754 worked around it by resolving the token in-process; task 1003878 deleted the whole mechanism along with the `.npmrc` that caused it. An instance still carrying a committed `.npmrc` from a pre-1003878 scaffold can safely delete it.
 - **A green `publish` run is not evidence of a publish.** The publish-on-merge lane succeeds on its no-op paths too (cascade terminator, armed-gate). Read the run's **job summary**, which now states the verdict explicitly: `PUBLISHED @bongos/core@<v>` vs `NO-OP — nothing was published this run`.