@bongos/core 1.21.174 → 1.21.176

package/docs/recipes/README.md

@@ -4,7 +4,7 @@
 
 This folder holds **things we have already discovered the hard way and need to write up at length**. Read the relevant file before you do similar work, and you will not repeat the discovery.
 
-A "recipe" is not a limitation (something the project cannot do). It is a multi-page operational guide for a workflow that's known to be tricky — the pixel-art pipeline, ops gotchas, deployment runbooks. For a one-paragraph rule like "TextEdit defaults to RTF — pass via `textutil -convert txt`," capture it via `node scripts/gds/learning-capture.js` instead; it goes into the DB and surfaces automatically on `/builder-claim` for relevant tasks.
+A "recipe" is not a limitation (something the project cannot do). It is a multi-page operational guide for a workflow that's known to be tricky — the pixel-art pipeline, ops gotchas, deployment runbooks. For a one-paragraph rule like "TextEdit defaults to RTF — pass via `textutil -convert txt`," capture it via `node scripts/bongos/learning-capture.js` instead; it goes into the DB and surfaces automatically on `/builder-claim` for relevant tasks.
 
 ## What goes here
 

package/docs/recipes/audit-replay.md

@@ -29,7 +29,7 @@ Notably absent — and worth knowing about so you can ask follow-up questions if
 ## Running the script
 
 ```bash
-bash scripts/gds/audit-replay.sh <builder_id> <start_iso> <end_iso>
+bash scripts/bongos/audit-replay.sh <builder_id> <start_iso> <end_iso>
 ```
 
 The builder_id is the integer from the `builders` table. Look it up with:
@@ -47,7 +47,7 @@ The script auto-detects whether it's running on the droplet (Postgres reachable
 
 ```bash
 # laptop
-bash scripts/gds/audit-replay.sh 1 2026-05-28T00:00:00Z 2026-05-28T23:59:59Z
+bash scripts/bongos/audit-replay.sh 1 2026-05-28T00:00:00Z 2026-05-28T23:59:59Z
 # (silently SSHes to the droplet, runs psql there)
 ```
 
@@ -57,12 +57,12 @@ TSV, three columns: `when_utc`, `kind`, `detail`. Already sorted chronologically
 
 ```bash
 # Pretty-print
-bash scripts/gds/audit-replay.sh 1 2026-05-28T00:00:00Z 2026-05-28T23:59:59Z \
+bash scripts/bongos/audit-replay.sh 1 2026-05-28T00:00:00Z 2026-05-28T23:59:59Z \
   | column -t -s $'\t' \
   | less -S
 
 # Histogram of event kinds for the day
-bash scripts/gds/audit-replay.sh 1 2026-05-28T00:00:00Z 2026-05-28T23:59:59Z \
+bash scripts/bongos/audit-replay.sh 1 2026-05-28T00:00:00Z 2026-05-28T23:59:59Z \
   | awk -F'\t' '{print $2}' | sort | uniq -c | sort -rn
 ```
 

package/docs/recipes/autobongos-windows-host.md

@@ -58,8 +58,8 @@ PowerShell, choose **Run as administrator**, and sign in to the prompt as the
 **same user** you checked the prerequisites with — then, from the checkout:
 
 ```powershell
-powershell -ExecutionPolicy Bypass -File scripts\gds\autobongos-service.ps1 install
-powershell -ExecutionPolicy Bypass -File scripts\gds\autobongos-service.ps1 start
+powershell -ExecutionPolicy Bypass -File scripts\bongos\autobongos-service.ps1 install
+powershell -ExecutionPolicy Bypass -File scripts\bongos\autobongos-service.ps1 start
 ```
 
 Why admin, when the runner deliberately is not: two different things happen
@@ -96,7 +96,7 @@ panel.
 If it does not, sign in on the box and run:
 
 ```powershell
-powershell -ExecutionPolicy Bypass -File scripts\gds\autobongos-service.ps1 status
+powershell -ExecutionPolicy Bypass -File scripts\bongos\autobongos-service.ps1 status
 ```
 
 which prints the task state, the last result, and the tail of the log.
@@ -124,10 +124,10 @@ whole premise is that you are not at the keyboard. One command gives you the
 night in five answers instead:
 
 ```powershell
-powershell -ExecutionPolicy Bypass -File scripts\gds\autobongos-service.ps1 digest
+powershell -ExecutionPolicy Bypass -File scripts\bongos\autobongos-service.ps1 digest
 ```
 
-or from any checkout: `node scripts/gds/autobongos-digest.js` (add `--since 24h`
+or from any checkout: `node scripts/bongos/autobongos-digest.js` (add `--since 24h`
 for a rolling window, `--all` for everything, `--json` for the structured shape).
 
 It answers: **what shipped**, **what is on hold and why**, **what each worker
@@ -176,7 +176,7 @@ It is the machine's working copy, not a place to edit.
 | Symptom | Where to look |
 |---|---|
 | Runner line says **Not checking in** | is the PC on? `...\autobongos-service.ps1 status` on the box |
-| **Checking in** but nothing ever ships | first the Gate page — is a goal allowlisted, and is the switch on? If both are on, the **gauge**: `autobongos-service.ps1 digest`, or `node scripts/gds/autonomy-gauge.js`. A `hold` with `unknown: true` means it cannot read your remaining capacity, and it will wait forever rather than guess |
+| **Checking in** but nothing ever ships | first the Gate page — is a goal allowlisted, and is the switch on? If both are on, the **gauge**: `autobongos-service.ps1 digest`, or `node scripts/bongos/autonomy-gauge.js`. A `hold` with `unknown: true` means it cannot read your remaining capacity, and it will wait forever rather than guess |
 | The log repeats `hold ... unknown: true` | the gauge has no reading it can vouch for. Open a **terminal** `claude` session on the box once — that writes it. A desktop-app session does not: the writer is a statusLine command, and only a terminal renders one |
 | `hold` naming the **usage limit** | working as designed. A worker was cut off by the subscription limit, so the runner sleeps until the reset time and then resumes by itself. There is no fixed task cap (task 1004454) |
 | Shipping stopped after a while | the log: the runner backs off after three failures and probes; the reason is in the log |

package/docs/recipes/bongos-cli-release.md

@@ -10,7 +10,7 @@ deliberate operator step.
 
 | Piece | Where | Role |
 |---|---|---|
-| Build wrapper | [`scripts/gds/build-bongos.js`](../../scripts/gds/build-bongos.js) | `bun build --compile` → per-platform binaries in `dist/` |
+| Build wrapper | [`scripts/bongos/build-bongos.js`](../../scripts/bongos/build-bongos.js) | `bun build --compile` → per-platform binaries in `dist/` |
 | CI | `.github/workflows/build-bongos-cli.yml` (instance-side) | runs the wrapper, uploads `bongos-cli-binaries` artifacts (no publish) |
 | Release pointer | `config/bongos-cli.json` (instance-side) | `releases_repo` + `version` + per-target asset filenames |
 | Redirects | [`src/bongos-downloads.js`](../../src/bongos-downloads.js) → `/downloads/bongos/*` in [`serve-internal.js`](../../src/bongos/serve-internal.js) | `/downloads/bongos/<target>` 302s to the release asset; `/version` + `/latest.json` for update-checks |
@@ -60,7 +60,7 @@ Verify: `curl -fsSL https://example.com/downloads/bongos/version` shows the new
 
 `bin/bongos.js` is one dispatcher with two runtimes ([task 1248](https://example.com/builders#/task/1248)):
 
-- **repo / `npm i -g`** → runs under `node`; spawns each sibling `scripts/gds/*.js` (unchanged).
+- **repo / `npm i -g`** → runs under `node`; spawns each sibling `scripts/bongos/*.js` (unchanged).
 - **compiled binary** → `process.execPath` is the `bongos` binary (no `node`, no scripts on disk), so it dispatches the **bundled on-ramp verbs in-process**: `login`/`setup`, `reauth`, `paste-token`, `api`, `init`, `onboard`. The heavy work verbs (`ship`/`claim`/`start`/`status`/`recall`/`cost`/`release`/`module`/`package-core`) and `doctor` are **not** bundled — they need a full repo + git to run, and pulling their dependency trees in would bloat the binary. Run those in a clone, where `npm i -g` gives the full CLI. A bare-binary user who invokes one gets a clear "get onto a real environment first" message.
 
 Follow-ups (not blocking the first release): SHA-pin `oven-sh/setup-bun`, code-sign the mac/win binaries, and expand the bundled verb set if a self-host workflow needs more offline.

package/docs/recipes/claude-design-loop.md

@@ -3,7 +3,7 @@
 > End-to-end guide for the repo ↔ Claude Design sync cycle.
 > ADR: [ADR 0081](../adr/0081-tool-agnostic-design-layer.md).
 > Adapter: `modules/ui-design/adapters/claude-design/index.js` (the `ui-design` module — ADR 0197).
-> CLI: `modules/ui-design/scripts/design-sync.js` (`scripts/gds/design-sync.js` is a thin shim over it).
+> CLI: `modules/ui-design/scripts/design-sync.js` (`scripts/bongos/design-sync.js` is a thin shim over it).
 > Skill: `.claude/skills/design-sync/SKILL.md`.
 
 ---
@@ -27,7 +27,7 @@
 ## 1. Build the token bundle
 
 ```bash
-node scripts/gds/design-sync.js
+node scripts/bongos/design-sync.js
 ```
 
 Output (JSON on stdout):
@@ -51,7 +51,7 @@ Output (JSON on stdout):
 
 **To scope to one surface:**
 ```bash
-node scripts/gds/design-sync.js --surface hall-ui
+node scripts/bongos/design-sync.js --surface hall-ui
 ```
 
 ---
@@ -113,14 +113,14 @@ The adapter writes files to `src/ui/<surfaceId>/` and updates `config/design-sou
 ```bash
 git add src/ui/hall-ui/ config/design-sources.json
 git commit -m "ui(hall-ui): Claude Design export (task 1234)"
-node scripts/gds/ship.js 1234 --notes-file notes.md --summary-file summary.txt
+node scripts/bongos/ship.js 1234 --notes-file notes.md --summary-file summary.txt
 ```
 
 ---
 
 ## Iterating
 
-- Re-run `node scripts/gds/design-sync.js` + re-push whenever tokens change.
+- Re-run `node scripts/bongos/design-sync.js` + re-push whenever tokens change.
 - The `export()` call is **idempotent** — files with identical content are skipped.
 - `config/design-sources.json` tracks which surface was last synced, by which tool, and when.
 
@@ -136,8 +136,8 @@ If a surface is Figma-canonical, its `config/design-sources.json` entry will hav
 
 | Symptom | Fix |
 |---|---|
-| `design-sync: repoRoot is required` | Run from the repo root: `node scripts/gds/design-sync.js` |
+| `design-sync: repoRoot is required` | Run from the repo root: `node scripts/bongos/design-sync.js` |
 | `design-tokens.neutral.json` missing | Run from a checkout that includes `config/`. |
 | `path-escape` error from `export()` | Claude Design sent a path with `../` — reject that output and re-prompt. |
-| Bundle is stale after token edit | Re-run `node scripts/gds/design-sync.js` and re-push. |
+| Bundle is stale after token edit | Re-run `node scripts/bongos/design-sync.js` and re-push. |
 | DesignSync MCP not available | The MCP tool is session-specific — check your Claude Code session config. |

package/docs/recipes/core-release-pipeline.md

@@ -4,10 +4,10 @@
 
 | Who | Gets a merged change | How to check |
 |---|---|---|
-| **cloudbongos.com** — the projects hub and the builders hall | on **every merge**, within minutes: it redeploys from `main` | its `/version`; the ship card's **Deploy** row reads it: *"live at `<sha>` (includes this merge \| not yet)"* |
+| **cloudbongos.com** — the projects hub and the builders hall | only when a **published core release** carries it **and the hub's pin moves** — owner-gated, never automatic on merge | its `/version`; the ship card's **Deploy** row reads it: *"live at `<sha>` (includes this merge \| not yet)"* |
 | **Projects hosted on the platform** | only when a **published core release** carries it (auto-published per merge, [ADR 0161](../adr/0161-publish-on-merge.md)) **and that project's pin moves** — a patch-channel subscription or a core-upgrade | that project's `/version` `coreVersion`; the ship card's **Projects** row states the rule |
 
-So a shipped task is live on the hub minutes after its merge, and on a hosted project only once that project's pin has moved — say which one you mean. The wording has one source, [`modules/lifecycle/merge-reach.js`](../../modules/lifecycle/merge-reach.js); the ship card, `deploy-divergence.js` and the SessionStart line all print it (task 1004682). `/recall who sees a merge` finds the same rule as learning 1000291.
+So a shipped task is live nowhere until a release carries it, and then only on an instance whose pin has moved — the hub included. The release itself waits on a green integration lane: the publish lane's integration gate refuses while `integration` on `main` is red. Never call work live until that instance's `/version` shows it. (This table used to say the hub redeploys from `main` on every merge, within minutes. It never did; on 2026-10-25 the hub had served one build through 200+ merges — task 1004873.) The wording has one source, [`modules/lifecycle/merge-reach.js`](../../modules/lifecycle/merge-reach.js); the ship card, `deploy-divergence.js` and the SessionStart line all print it (task 1004682). `/recall who sees a merge` finds the same rule as learning 1000292, which corrects learning 1000291 (that one still says the hub redeploys on every merge; the API has no way to edit a learning).
 
 > **The map.** Three sibling recipes each cover one leg — [packaging-the-core](packaging-the-core.md) (build the artifact), [private-npm-distribution](private-npm-distribution.md) (publish it), [upgrading-the-core](upgrading-the-core.md) (consume it). This file is the thing that connects them.
 >
@@ -46,7 +46,7 @@ Bongos vocabulary collides with gate 1 in a way worth naming: **task status `shi
 
 ## Gate 0 — does your change ship at all?
 
-The core is not "this repo." It is exactly the subtree [`isPublishable()`](../../scripts/gds/publish-manifest.js) selects ([ADR 0098](../adr/0098-public-mirror-publish-manifest.md)) — a **default-deny, two-layer** gate:
+The core is not "this repo." It is exactly the subtree [`isPublishable()`](../../scripts/bongos/publish-manifest.js) selects ([ADR 0098](../adr/0098-public-mirror-publish-manifest.md)) — a **default-deny, two-layer** gate:
 
 ```
 isPublishable(p)  ==  matchesDeny(p) ? false : matchesAllow(p)
@@ -68,16 +68,16 @@ Note the deliberate non-exclusion: the rank / trust-boundary / ship-grade machin
 Check a path before you assume:
 
 ```bash
-node -e "console.log(require('./scripts/gds/publish-manifest').isPublishable('docs/recipes/core-release-pipeline.md'))"
+node -e "console.log(require('./scripts/bongos/publish-manifest').isPublishable('docs/recipes/core-release-pipeline.md'))"
 ```
 
 ## Gate 1 — land it on `main`
 
 The ordinary claim→ship loop: `/builder-claim N` → build → `/builder-ship`. That chains `completed` → `confirmed` → `shipped`, and credits land at `shipped` ([ADR 0120](../adr/0120-pay-on-land-and-builder-owned-rebase-gate.md)).
 
-Landing is CI-gated (tasks 1002610/1002611/1002619, ADR 0159): every PR runs the **`unit`** check — the DB-free suite plus the fitness gates, via `npm test` — and branch protection **requires** it, so a red suite blocks the merge. PRs touching the hard-floor safety surfaces (`CODEOWNERS` (instance-side)) additionally need the owner's review. The owner kill-switch is `node scripts/gds/gating.js on|off|status` — reversible by construction, snapshot-restored.
+Landing is CI-gated (tasks 1002610/1002611/1002619, ADR 0159): every PR runs the **`unit`** check — the DB-free suite plus the fitness gates, via `npm test` — and branch protection **requires** it, so a red suite blocks the merge. PRs touching the hard-floor safety surfaces (`CODEOWNERS` (instance-side)) additionally need the owner's review. The owner kill-switch is `node scripts/bongos/gating.js on|off|status` — reversible by construction, snapshot-restored.
 
-**Stop here and the hub has it within minutes; no hosted project does.** This is the gate that feels like the finish line for every project, and is one only for the hub (see [Who sees a merge](#who-sees-a-merge-and-when)).
+**Stop here and no instance has it — the hub included.** This is the gate that feels like the finish line, and is one for no project (see [Who sees a merge](#who-sees-a-merge-and-when)).
 
 ## Gate 2 — cut a release
 
@@ -102,8 +102,8 @@ The practical trap: a **MINOR is silently withheld from every patch-only instanc
 ### 2b. Build the artifact
 
 ```bash
-node scripts/gds/package-core.js --ref main            # → dist/bongos-core-<v>.tgz + .manifest.json
-node scripts/gds/package-core.js --ref main --self-verify
+node scripts/bongos/package-core.js --ref main            # → dist/bongos-core-<v>.tgz + .manifest.json
+node scripts/bongos/package-core.js --ref main --self-verify
 ```
 
 `package-core` archives the **committed** tree at `--ref`, never your working tree, and stamps the version from `CORE_VERSION` *at that ref*. Full mechanics — the fail-closed no-leak gate, the `tree_sha256` integrity pin, the pruned lockfile — in [packaging-the-core](packaging-the-core.md).
@@ -112,13 +112,13 @@ node scripts/gds/package-core.js --ref main --self-verify
 
 ### 2c. Publish — automatic on merge
 
-**Every merge to `main` publishes** ([ADR 0161](../adr/0161-publish-on-merge.md), superseding ADR 0137's manual gate): once the required `unit` check succeeds on a main push — and the `integration` lane is green on the commit being released, which carries the packaged-core empty-database proof (task 1002863; the wait is task 1004290) — the `publish` workflow auto-bumps a **patch** if nobody bumped (via `scripts/gds/bump-version.js`, which writes the literal AND appends the ledger entry to [`docs/module-api-changelog.md`](../module-api-changelog.md) — ADR 0203; the carrier commit stages both), builds through the fail-closed no-leak gate with `--self-verify`, publishes, and tags `core-v<version>`. A **minor/major is still a human in-task bump** — CI never makes that call, because it decides what patch-channel subscribers receive unattended.
+**Every merge to `main` publishes** ([ADR 0161](../adr/0161-publish-on-merge.md), superseding ADR 0137's manual gate): once the required `unit` check succeeds on a main push — and the `integration` lane is green on the commit being released, which carries the packaged-core empty-database proof (task 1002863; the wait is task 1004290) — the `publish` workflow auto-bumps a **patch** if nobody bumped (via `scripts/bongos/bump-version.js`, which writes the literal AND appends the ledger entry to [`docs/module-api-changelog.md`](../module-api-changelog.md) — ADR 0203; the carrier commit stages both), builds through the fail-closed no-leak gate with `--self-verify`, publishes, and tags `core-v<version>`. A **minor/major is still a human in-task bump** — CI never makes that call, because it decides what patch-channel subscribers receive unattended.
 
 The lane is armed by the owner via the `PUBLISH_ON_MERGE=1` repo variable + two secrets (`NPM_TOKEN`, `RELEASE_PUSH_TOKEN`); while disarmed it no-ops loudly. Manual fallback, same command CI runs:
 
 ```bash
-node scripts/gds/package-core.js --publish          # DRY-RUN — runs the no-leak gate, previews
-node scripts/gds/package-core.js --publish --live   # permanent
+node scripts/bongos/package-core.js --publish          # DRY-RUN — runs the no-leak gate, previews
+node scripts/bongos/package-core.js --publish --live   # permanent
 ```
 
 **A publish is not what moves a vendored-tarball instance** — see gate 3. Chasing an npm publish to move a `file:`-pinned instance is a documented dead end.
@@ -132,7 +132,7 @@ node scripts/gds/package-core.js --publish --live   # permanent
 > **One install-time step enables it.** The door needs a `provisioning_instances` row to point at, and the control plane has never had one:
 >
 > ```bash
-> node scripts/gds/enroll-control-plane.js --owner <builderId> --apply
+> node scripts/bongos/enroll-control-plane.js --owner <builderId> --apply
 > ```
 >
 > Until that is run, `/deploy` says so and names this command. The self row carries `hosting_shape='control-plane'`, which every destructive intent action refuses by name — a teardown aimed at it would destroy the platform from inside its own UI, so the guard is an allow-list (`core-upgrade`, `restart`) enforced at `enqueueIntent`, the one place every intent passes.
@@ -169,7 +169,7 @@ release exists, and `bongos upgrade --registry --commit-pin` for the bump itself
 once instead of forty times:
 
 ```bash
-node scripts/gds/go-live.js
+node scripts/bongos/go-live.js
 ```
 
 That is **plan-only and read-only**: it prints live-vs-target, checks the registry actually
@@ -255,7 +255,7 @@ answerable without going and looking. Two different unknowns, two different verd
 4. **Bump, restart, read back**, as before.
 
 Host topology (ssh alias, box paths, service names, health URL) lives in a host-owned
-`config/go-live.json`, never in the core — run `node scripts/gds/go-live.js --help` for the
+`config/go-live.json`, never in the core — run `node scripts/bongos/go-live.js --help` for the
 schema. A core that named one instance's box would not be a core.
 
 **Upgrading a provisioned co-tenant** (task 1003521). A co-tenant under `/srv/<host>/<slug>` is
@@ -305,7 +305,7 @@ What each piece is for — each guards a failure that actually happened:
   ```
   Passing "by reference" in the script text is NOT enough; what matters is what argv looks like after expansion. **The command above is the compliant form of exactly this advice** — it uses `--preserve-env=NPM_TOKEN`, so the token travels in the environment and never reaches any argv.
 - **`--to <VER>` is required** — `bongos upgrade` refuses to guess a target.
-- **Use `--restart-cmd`, NOT `--service` — and `--health-url` is what buys the automatic rollback.** The two restart flags are not interchangeable here. `restartService()` ([`scripts/gds/upgrade.js`](../../scripts/gds/upgrade.js)) runs a **bare** `systemctl restart <svc>` for `--service`, with no `sudo`; the upgrade runs as unprivileged `lars`, who has NOPASSWD sudo for the restart but cannot restart a unit directly — so `--service` fails at the last step, after the core is already swapped in. `--restart-cmd` lets you spell the `sudo` (it overrides `--service` when both are passed). Point the health URL at `http://127.0.0.1:3002/healthz` — **not** `:3000` (that is the port named in CLAUDE.md, not this instance's; read the truth from `systemctl cat cloudbongos.service`) and **not** the public URL, where a pre-launch `basic_auth` on the apex makes a healthy boot look failed and triggers a needless rollback that then misreports "health STILL failing after rollback". The service is fine; the probe was wrong. Health polls ~30s, so an immediate `fetch failed` is not a failure.
+- **Use `--restart-cmd`, NOT `--service` — and `--health-url` is what buys the automatic rollback.** The two restart flags are not interchangeable here. `restartService()` ([`scripts/bongos/upgrade.js`](../../scripts/bongos/upgrade.js)) runs a **bare** `systemctl restart <svc>` for `--service`, with no `sudo`; the upgrade runs as unprivileged `lars`, who has NOPASSWD sudo for the restart but cannot restart a unit directly — so `--service` fails at the last step, after the core is already swapped in. `--restart-cmd` lets you spell the `sudo` (it overrides `--service` when both are passed). Point the health URL at `http://127.0.0.1:3002/healthz` — **not** `:3000` (that is the port named in CLAUDE.md, not this instance's; read the truth from `systemctl cat cloudbongos.service`) and **not** the public URL, where a pre-launch `basic_auth` on the apex makes a healthy boot look failed and triggers a needless rollback that then misreports "health STILL failing after rollback". The service is fine; the probe was wrong. Health polls ~30s, so an immediate `fetch failed` is not a failure.
 - **`--commit-pin` commits AND pushes the pin.** The instance is a pull-deploy repo: the next sync runs `git reset --hard origin/main`, which reverts an uncommitted pin, and `npm ci` then reinstalls the old core. Nothing errors. This is exactly how live sat 13 releases behind (task 1002712). The same applies to any tracked instance-config edit (`config/branding.json`): commit + push or the next deploy tick undoes it. A commit that fails to *push* saves nothing — deploy.sh resets to the remote.
 - **`PGDATABASE=cloudbongos` is inline above, and that is what records the `core_upgrades` ledger row.** The migrate step resolves the instance DB itself, but the ledger write reads only the env; a form that omits it still upgrades successfully and just logs `ledger skipped (no DATABASE_URL or PGDATABASE)`. It is also **load-bearing beyond the ledger** — `migrate.sh` defaults to a *different* production DB (`example`), so name it explicitly rather than letting it default.
 
@@ -333,16 +333,16 @@ If `coreVersion` regressed: the pin didn't reach `origin/main` — re-run the bu
 
 ## Detecting divergence
 
-[`scripts/gds/deploy-divergence.js`](../../scripts/gds/deploy-divergence.js) is the comparison that was missing during the ten-day incident. It runs **warn-only at the end of every ship** and can be run by hand any time:
+[`scripts/bongos/deploy-divergence.js`](../../scripts/bongos/deploy-divergence.js) is the comparison that was missing during the ten-day incident. It runs **warn-only at the end of every ship** and can be run by hand any time:
 
 ```bash
-node scripts/gds/deploy-divergence.js --url https://<instance-host>
+node scripts/bongos/deploy-divergence.js --url https://<instance-host>
 ```
 
 It reports the two gaps **separately**, because they have different fixes:
 
-- **UNRELEASED** — commits on `main` past the last `CORE_VERSION` bump. *No hosted project can take these at any pin* — no published version contains them yet. The publish lane (ADR 0161) normally carries a merge within minutes; a gap that stays means the lane is disarmed or red.
-- **UNDEPLOYED** — the live instance's `coreVersion` is behind `main`'s. A release exists it has not picked up: on the hub, its redeploy is late or stuck; on a hosted project, its pin has not moved (gate 3).
+- **UNRELEASED** — commits on `main` past the last `CORE_VERSION` bump. *No instance, the hub included, can take these at any pin* — no published version contains them yet. The publish lane (ADR 0161) normally carries a merge within minutes; a gap that stays means the lane is disarmed, red, or refused by its integration gate. The SessionStart line also says whether `main`'s latest merge is in a release yet.
+- **UNDEPLOYED** — the live instance's `coreVersion` is behind `main`'s. A release exists it has not picked up: its pin has not moved (gate 3). On the hub that move is owner-gated.
 
 Exit codes: `0` aligned, `1` diverged, `2` undetermined.
 

package/docs/recipes/failed-ship-recovery-proof.md

@@ -21,7 +21,7 @@ $ echo "# draft" >> docs/architecture.md
 $ git status --short
  M docs/architecture.md
 
-$ node scripts/gds/ship.js 1666 --no-surprise
+$ node scripts/bongos/ship.js 1666 --no-surprise
 Verifying claim #1397 on task #1666: V4.R38 staging — throwaway proof task
 Preflight (working tree + branch freshness)...
   preflight: working tree has uncommitted tracked changes:
@@ -56,7 +56,7 @@ At this point: task at `completed`, claim `#1397` consumed, no active claim on 1
 ### Recovery — the ≤1-command proof
 
 ```
-$ node scripts/gds/ship.js 1666 --no-surprise
+$ node scripts/bongos/ship.js 1666 --no-surprise
 Task #1666 is at 'completed' (grade stalled) and you last held the claim
 — resuming the grade (no re-claim needed).
 Re-grading task #1666: V4.R38 staging — throwaway proof task (ship after test)

package/docs/recipes/figma-design-loop.md

@@ -3,7 +3,7 @@
 > End-to-end guide for the repo ↔ Figma sync cycle — the human escape hatch in ADR 0081.
 > ADR: [ADR 0081](../adr/0081-tool-agnostic-design-layer.md).
 > Adapter: `modules/ui-design/adapters/figma/index.js` (the `ui-design` module — ADR 0197).
-> CLI: `modules/ui-design/scripts/figma-design-sync.js` (`scripts/gds/figma-design-sync.js` is a thin shim over it).
+> CLI: `modules/ui-design/scripts/figma-design-sync.js` (`scripts/bongos/figma-design-sync.js` is a thin shim over it).
 > Skill: `.claude/skills/figma-design-sync/SKILL.md`.
 >
 > Not to be confused with `otb-figma-sync` (pixel-art tile review, a separate Figma file, a separate concern).
@@ -29,7 +29,7 @@
 ## 1. Build the push plan
 
 ```bash
-node scripts/gds/figma-design-sync.js
+node scripts/bongos/figma-design-sync.js
 ```
 
 Output (JSON on stdout):
@@ -45,7 +45,7 @@ Output (JSON on stdout):
 
 **To scope to one surface:**
 ```bash
-node scripts/gds/figma-design-sync.js --surface hall-ui
+node scripts/bongos/figma-design-sync.js --surface hall-ui
 ```
 
 `figma-plan.json` describes the frames to create — a color-swatch frame, a typography-specimen frame, and one reference frame per surface (naming its current tool + source URL).
@@ -98,14 +98,14 @@ The adapter translates frames/text/solid-fill rectangles into `.js` + `.css` fil
 ```bash
 git add src/ui/hall-ui/ config/design-sources.json
 git commit -m "ui(hall-ui): Figma export (task 1234)"
-node scripts/gds/ship.js 1234 --notes-file notes.md --summary-file summary.txt
+node scripts/bongos/ship.js 1234 --notes-file notes.md --summary-file summary.txt
 ```
 
 ---
 
 ## Iterating
 
-- Re-run `node scripts/gds/figma-design-sync.js` + re-push whenever tokens change, so the designer never opens a stale file.
+- Re-run `node scripts/bongos/figma-design-sync.js` + re-push whenever tokens change, so the designer never opens a stale file.
 - The `export()` call is **idempotent** — files with identical content are skipped.
 - `config/design-sources.json` tracks which surface was last synced, by which tool, and when.
 
@@ -126,4 +126,4 @@ Code-canonical is the default: the repo is authoritative, the Figma file is a sy
 | Warning: "not code-representable" | Expected for icons/illustrations/freeform canvas art — export it as an asset under `assets/ui/<surfaceId>/` instead of forcing it into code. |
 | Warning: "no matching design token" | The designer used a color outside the token palette — either add it to `config/design-tokens.json` or accept the raw hex. |
 | Figma MCP write tool not available | Session-specific — stop and surface the gap rather than faking the sync (see `otb-figma-sync`'s capability check for the same pattern). |
-| Plan is stale after a token edit | Re-run `node scripts/gds/figma-design-sync.js` and re-push. |
+| Plan is stale after a token edit | Re-run `node scripts/bongos/figma-design-sync.js` and re-push. |

package/docs/recipes/gds-db-backup.md

@@ -2,7 +2,7 @@
 
 > **Filed by:** task [#412](https://example.com/builders#/task/412) (V3.R62-precondition, local nightly) + [#415](https://example.com/builders#/task/415) (V3.R62-offsite, weekly offsite archive) — both under [ADR 0024](../adr/0024-cloneable-repo-local-first-memory.md) §5 (backup cadence). Vendor choice for the offsite copy: [ADR 0025](../adr/0025-offsite-backup-vendor-digitalocean-spaces.md) (DigitalOcean Spaces).
 > **Two layers:** a **local daily** `pg_dump` to `/var/backups/gds/` (protects against corruption / bad migration / accidental delete) **plus** a **weekly offsite copy** of the latest local dump to a DigitalOcean Space (protects against whole-droplet loss).
-> **Reads:** `/etc/systemd/system/gds-db-backup.{service,timer}` (copies of [`scripts/gds/gds-db-backup.service`](../../scripts/gds/gds-db-backup.service) / [`.timer`](../../scripts/gds/gds-db-backup.timer)) + [`scripts/gds/db-backup-nightly.sh`](../../scripts/gds/db-backup-nightly.sh); `/etc/systemd/system/gds-db-offsite.{service,timer}` (copies of [`scripts/gds/gds-db-offsite.service`](../../scripts/gds/gds-db-offsite.service) / [`.timer`](../../scripts/gds/gds-db-offsite.timer)) + [`scripts/gds/db-backup-offsite.sh`](../../scripts/gds/db-backup-offsite.sh).
+> **Reads:** `/etc/systemd/system/gds-db-backup.{service,timer}` (copies of [`scripts/bongos/gds-db-backup.service`](../../scripts/bongos/gds-db-backup.service) / [`.timer`](../../scripts/bongos/gds-db-backup.timer)) + [`scripts/bongos/db-backup-nightly.sh`](../../scripts/bongos/db-backup-nightly.sh); `/etc/systemd/system/gds-db-offsite.{service,timer}` (copies of [`scripts/bongos/gds-db-offsite.service`](../../scripts/bongos/gds-db-offsite.service) / [`.timer`](../../scripts/bongos/gds-db-offsite.timer)) + [`scripts/bongos/db-backup-offsite.sh`](../../scripts/bongos/db-backup-offsite.sh).
 
 ## What this gives us
 
@@ -101,10 +101,10 @@ python3 -c "import boto3" 2>/dev/null || sudo apt-get install -y python3-boto3
 
 # 3. Install the systemd units (canonical text is in the repo).
 sudo install -o root -g root -m 0644 \
-  /home/lars/example/scripts/gds/gds-db-offsite.service \
+  /home/lars/example/scripts/bongos/gds-db-offsite.service \
   /etc/systemd/system/gds-db-offsite.service
 sudo install -o root -g root -m 0644 \
-  /home/lars/example/scripts/gds/gds-db-offsite.timer \
+  /home/lars/example/scripts/bongos/gds-db-offsite.timer \
   /etc/systemd/system/gds-db-offsite.timer
 
 # 4. Reload, enable + start the timer, verify, and do a one-shot test upload.
@@ -122,15 +122,15 @@ sudo install -d -o lars -g lars -m 0750 /var/backups/gds
 
 # 2. Drop the systemd units into place (canonical text is in the repo).
 sudo install -o root -g root -m 0644 \
-  /home/lars/example/scripts/gds/gds-db-backup.service \
+  /home/lars/example/scripts/bongos/gds-db-backup.service \
   /etc/systemd/system/gds-db-backup.service
 sudo install -o root -g root -m 0644 \
-  /home/lars/example/scripts/gds/gds-db-backup.timer \
+  /home/lars/example/scripts/bongos/gds-db-backup.timer \
   /etc/systemd/system/gds-db-backup.timer
 
 # 3. Make sure the script is executable (it is in the repo, but a fresh
 # install on a different machine sometimes loses the bit).
-chmod +x /home/lars/example/scripts/gds/db-backup-nightly.sh
+chmod +x /home/lars/example/scripts/bongos/db-backup-nightly.sh
 
 # 4. Reload systemd, enable + start the timer.
 sudo systemctl daemon-reload
@@ -153,7 +153,7 @@ journalctl -u gds-db-backup.service -f
 Or directly:
 
 ```bash
-/home/lars/example/scripts/gds/db-backup-nightly.sh
+/home/lars/example/scripts/bongos/db-backup-nightly.sh
 ```
 
 ### See when the next run is scheduled
@@ -213,7 +213,7 @@ sudo -u postgres dropdb example_restore_test
 
 > **Expected after restore: `search_chunks` is empty.** The dump excludes its data by design (see the Size note above), so `SELECT count(*) FROM search_chunks` returns 0 on a fresh restore — that is correct, not a truncated dump. `/recall` rebuilds the index from source once the app is back: `search-ingest-md.js` runs on the next deploy (repo-doc chunks) and `search-ingest-db.js` runs nightly (DB-prose chunks). For a real (not drill) restore where you want recall working immediately, run both by hand against the restored DB:
 > ```bash
-> node scripts/gds/search-ingest-md.js && node scripts/gds/search-ingest-db.js
+> node scripts/bongos/search-ingest-md.js && node scripts/bongos/search-ingest-db.js
 > ```
 
 A run-through of this drill is what shipped task [#281](https://example.com/builders#/task/281) (R62) once. Cadence going forward: quarterly.
@@ -302,7 +302,7 @@ Two things changed, and one thing is still on you:
 ### Checking
 
 ```bash
-node scripts/gds/bug-attachment-audit.js
+node scripts/bongos/bug-attachment-audit.js
 ```
 
 Reads every bug task's description, extracts the attachment links it promises a reader,

package/docs/recipes/instance-deploy.md

@@ -15,7 +15,7 @@
 
 1. **`git pull --ff-only origin main`** the *instance* repo — host content only: `config/`, `migrations/instance/`, and the pinned core version in `package.json`.
 2. **`npm ci --omit=dev`** — installs the pinned `@bongos/core` + instance deps. This is what replaces `git reset --hard`: the core is a dependency, so an upgrade is a pin bump + `npm ci`, not a source merge.
-3. **`sh <core>/scripts/gds/deploy-main-audit-gate.sh`** — the SEC #863 gate (ADR 0043). Refuses the deploy if a below-Metic author touched a permission-sensitive path in the delta being deployed, and on refusal **restores the checkout** to the previously-deployed SHA. See below; it is not optional and it is not last.
+3. **`sh <core>/scripts/bongos/deploy-main-audit-gate.sh`** — the SEC #863 gate (ADR 0043). Refuses the deploy if a below-Metic author touched a permission-sensitive path in the delta being deployed, and on refusal **restores the checkout** to the previously-deployed SHA. See below; it is not optional and it is not last.
 4. **`bash <core>/scripts/migrate.sh`** — the core's **three-root** migrate (W5 / ADR 0108 §5) merges `<core>/migrations` + `<instance>/migrations/instance` + each enabled module's migrations, keyed by namespaced filename stems (`core_NNN_`, `<key>_NNN_`, bare instance) so the two repos never collide. It resolves core-root vs instance-root via `src/instance-config.js`.
 5. **restart the platform** — a systemd unit runs `node <core>/src/platform-server.js` (Bongos-only) with `WorkingDirectory` = the instance root (so `resolveInstanceRoot()` resolves to the instance) + `PORT`/`HOST` env; then poll `/healthz`.
 
@@ -37,7 +37,7 @@ PREV_SHA="$(git rev-parse HEAD)"          # BEFORE git reset/pull
 git reset --hard origin/main
 npm ci --omit=dev
 export OTB_DEPLOY_PREV_SHA="$PREV_SHA"
-sh node_modules/@bongos/core/scripts/gds/deploy-main-audit-gate.sh || exit 1
+sh node_modules/@bongos/core/scripts/bongos/deploy-main-audit-gate.sh || exit 1
 ```
 
 **`OTB_AUDIT_STRICT` stays off.** Ranks resolve on `github_login` only — deliberately, since `display_name` is builder-controlled and keying it let one builder alias another's rank. A deploy lane whose commits are authored under a human display name (`Firstname Lastname`) rather than the builder's `github_login` therefore resolves to nothing, and strict would refuse every deploy forever. Non-strict still hard-blocks the incident class this exists for: a *resolved* below-Metic author on a protected path. Turn strict on once the lane commits under logins.
@@ -53,7 +53,7 @@ sh node_modules/@bongos/core/scripts/gds/deploy-main-audit-gate.sh || exit 1
 
 `ship.js` needs no change: its deploy **trigger** SSHes `~/deploy.sh` (or fires the CI workflow) and is agnostic to what that script does internally — a consumer instance installs `deploy-instance.sh` as its `~/deploy.sh`.
 
-**The audit gate is the exception, and it is live.** Do not read the paragraph above as covering it: the deferred thing is the `deploy-instance.sh` *model*, not the gate. The gate was wired into `cloudbongos.com`'s existing `~/deploy.sh` under task 1001426 — between its `npm ci` and its `migrate`, with the previous SHA captured before the pull — and verified both ways against that real script on a throwaway clone. That host's `~/deploy.sh` is host state and lives in no repository, so **this diff is not where you can see it**; the wiring, its backup path and its one loose end are recorded on the task. The loose end: until a core carrying `scripts/gds/deploy-main-audit-gate.sh` is published and pinned there, the host runs a byte-identical transitional copy beside `~/deploy.sh`, and `deploy.sh` prefers the core's copy the moment it appears.
+**The audit gate is the exception, and it is live.** Do not read the paragraph above as covering it: the deferred thing is the `deploy-instance.sh` *model*, not the gate. The gate was wired into `cloudbongos.com`'s existing `~/deploy.sh` under task 1001426 — between its `npm ci` and its `migrate`, with the previous SHA captured before the pull — and verified both ways against that real script on a throwaway clone. That host's `~/deploy.sh` is host state and lives in no repository, so **this diff is not where you can see it**; the wiring, its backup path and its one loose end are recorded on the task. The loose end: until a core carrying `scripts/bongos/deploy-main-audit-gate.sh` is published and pinned there, the host runs a byte-identical transitional copy beside `~/deploy.sh`, and `deploy.sh` prefers the core's copy the moment it appears.
 
 ## Wiring it on a consumer host (R85/R89)
 

package/docs/recipes/instance-first-run.md

@@ -9,7 +9,7 @@
 
 A cloned instance repo ships `config/` + `package.json` + a vendored core tarball, but
 **not** the installed engine. Until you install it there is no `bongos` binary and no
-`scripts/gds/…`, so every `/builder-*` skill fails. An agent that presses on in that
+`scripts/bongos/…`, so every `/builder-*` skill fails. An agent that presses on in that
 state has no tools of its own and can fall back on whatever *other* Cloud Bongos instance
 the machine is signed in to — which is how a `demo` clone once offered to write a task
 into the wrong live backlog (2026-07-08). The session-start hook now prints these same

package/docs/recipes/multi-builder-merge.md

@@ -14,7 +14,7 @@ This recipe is the audit deliverable for [#269](https://example.com/builders#/ta
 - **Claim side is already deterministic.** `claimTask()` runs in a single transaction with `SELECT … FOR UPDATE` on the task row, a touches-overlap check, and the `uniq_active_claim_per_task` partial unique index. A lost race surfaces as `ALREADY_CLAIMED` (Postgres `23505`), never as corruption. No change needed.
 - **Merge side is the risk, and it has ONE shared resource:** the single `main` worktree (`REPO_ROOT`) on the build machine. Every ship's auto-merge and every `/merge-mode` run checks out `main`, fetches, merges, pushes, and deploys *there*.
 - **[#462](https://example.com/builders#/task/462) (criterion C4)** added a lockfile so two concurrent **ships** couldn't collide — but the lock lived *inside* `ship.js`, so `/merge-mode` (which mutates the same tree by hand) never took it. That left two races open: **ship-vs-merge-mode** and **merge-mode-vs-merge-mode**.
-- **[#269](https://example.com/builders#/task/269) (this task)** extracts the lock into [`modules/lifecycle/merge-lock.js`](../../modules/lifecycle/merge-lock.js) and has **both** surfaces acquire the **same** mutex. `/merge-mode` takes it via the [`scripts/gds/merge-lock.js`](../../scripts/gds/merge-lock.js) CLI before it touches `main`, and releases it after deploy.
+- **[#269](https://example.com/builders#/task/269) (this task)** extracts the lock into [`modules/lifecycle/merge-lock.js`](../../modules/lifecycle/merge-lock.js) and has **both** surfaces acquire the **same** mutex. `/merge-mode` takes it via the [`scripts/bongos/merge-lock.js`](../../scripts/bongos/merge-lock.js) CLI before it touches `main`, and releases it after deploy.
 
 ---
 
@@ -39,7 +39,7 @@ This recipe is the audit deliverable for [#269](https://example.com/builders#/ta
    If another session left `main` mid-merge or moved it, this failed and bailed with the misleading *"main is ahead of origin somehow."* — **Fixed in [#462](https://example.com/builders#/task/462)** with the in-`ship.js` lock + `mainWorktreeBusy()` guard (refuses to mutate `REPO_ROOT` when `MERGE_HEAD` exists or the tree is dirty).
 
 2. **`/merge-mode` — `git checkout main; git pull; git merge …` on `REPO_ROOT`, with no lock.** ← **the gap [#269](https://example.com/builders#/task/269) closes.**
-   `/merge-mode` mutated the exact same worktree `ship.js` does, but never acquired [#462](https://example.com/builders#/task/462)'s lock (the lock was a private function inside `ship.js`). A ship auto-merging while an operator ran `/merge-mode` could interleave checkouts/merges on one HEAD. **Fixed in [#269](https://example.com/builders#/task/269):** `/merge-mode` now runs `node scripts/gds/merge-lock.js acquire` before Step 2 and `release` in Step 5c.
+   `/merge-mode` mutated the exact same worktree `ship.js` does, but never acquired [#462](https://example.com/builders#/task/462)'s lock (the lock was a private function inside `ship.js`). A ship auto-merging while an operator ran `/merge-mode` could interleave checkouts/merges on one HEAD. **Fixed in [#269](https://example.com/builders#/task/269):** `/merge-mode` now runs `node scripts/bongos/merge-lock.js acquire` before Step 2 and `release` in Step 5c.
 
 3. **macOS Finder/iCloud `* 2` duplicate refs.**
    Both surfaces clean these before fetching (`cleanupMacFinderDupRefs` / `find .git -name "* 2" -delete`). Not a concurrency bug, but a shared-filesystem hazard worth listing — it broke every auto-merge on 2026-05-10.

package/docs/recipes/ops-gotchas.md

@@ -91,7 +91,7 @@ Organized by topic, not chronology. New entries go in the matching section; crea
 
 ### The web tier is blocked from the cloud tokens by a drop-in — don't "tidy" it away
 
-`/etc/systemd/system/cloudbongos.service.d/<redacted>.conf` carries `InaccessiblePaths=/etc/cloudbongos/box.env`, so the internet-facing process cannot read the DigitalOcean and Cloudflare tokens (ADR 0327 §5, task 1004176). The repo copy is `scripts/gds/cloudbongos-token-isolation.conf`.
+`/etc/systemd/system/cloudbongos.service.d/<redacted>.conf` carries `InaccessiblePaths=/etc/cloudbongos/box.env`, so the internet-facing process cannot read the DigitalOcean and Cloudflare tokens (ADR 0327 §5, task 1004176). The repo copy is `scripts/bongos/cloudbongos-token-isolation.conf`.
 
 Without it the file is plain mode 600 owned by `lars` and the web tier runs as `lars`, so it *could* read them — ADR 0111 §2's boundary is real in the code but was not enforced by the kernel. Deleting the drop-in silently restores that exposure.
 
@@ -198,18 +198,18 @@ Inside the namespace the file lists as `---------- 1 root root 0`. The runner un
 
 > Git Bash builder-loop gotchas (worktree junctions, api.js path mangling, local test baseline) live in their own recipe: [windows-builders.md](windows-builders.md).
 
-### PowerShell 5.1 turns a clean `node scripts/gds/*.js` exit into a false failure
+### PowerShell 5.1 turns a clean `node scripts/bongos/*.js` exit into a false failure
 
-- **Symptom:** Running `node scripts/gds/api.js GET /api/bongos/me 2>&1` (or the same on `claim.js`/`ship.js`) inside a PowerShell 5.1 session reports failure — `$?` is `$false` and the stderr line surfaces as a `NativeCommandError` — even though node exited 0 and the JSON on stdout is exactly right.
+- **Symptom:** Running `node scripts/bongos/api.js GET /api/bongos/me 2>&1` (or the same on `claim.js`/`ship.js`) inside a PowerShell 5.1 session reports failure — `$?` is `$false` and the stderr line surfaces as a `NativeCommandError` — even though node exited 0 and the JSON on stdout is exactly right.
 - **Root cause:** `api.js` prints its status banner to stderr unconditionally, by design (stdout stays clean JSON for piping); `claim.js`/`ship.js` also write diagnostics to stderr during a normal run. PS 5.1 wraps any stderr output from a native command into an `ErrorRecord` once the two streams are merged with `2>&1`, and sets `$?` false regardless of the actual exit code.
-- **Fix:** Never merge streams on these calls. Prefer `scripts/gds/api.ps1` (a thin wrapper that discards stderr and writes clean JSON to stdout, safe to pipe into `ConvertFrom-Json`), or call `node scripts/gds/api.js ...` plain, with no `2>&1`.
+- **Fix:** Never merge streams on these calls. Prefer `scripts/bongos/api.ps1` (a thin wrapper that discards stderr and writes clean JSON to stdout, safe to pipe into `ConvertFrom-Json`), or call `node scripts/bongos/api.js ...` plain, with no `2>&1`.
 - **Why it bites:** The exit code and JSON body are both fine — only the redirection is wrong — so the failure looks like a real API error and wastes time chasing a phantom bug in the call itself.
 
 ### `Out-File`/`>` writes a UTF-8 BOM that breaks `JSON.parse` on re-read
 
 - **Symptom:** A JSON body file written from PowerShell (`... | Out-File body.json` or `... > body.json`) and then read back with `--body-file` fails to parse, or parses with an invisible extra character before the first key.
 - **Root cause:** PowerShell's `Out-File`/`>` redirection default to UTF-8 **with a byte-order-mark**. `JSON.parse` does not strip a leading BOM, so the file's first byte is invisible garbage as far as the parser is concerned.
-- **Fix:** Don't write CLI JSON body files with `Out-File`/`>`. Use the Write tool, or `[IO.File]::WriteAllText($path, $json, (New-Object Text.UTF8Encoding($false)))` (explicit no-BOM encoding). `scripts/gds/api.js`'s `--body-file` reader now also strips a leading BOM defensively, but the safest fix is to never write one.
+- **Fix:** Don't write CLI JSON body files with `Out-File`/`>`. Use the Write tool, or `[IO.File]::WriteAllText($path, $json, (New-Object Text.UTF8Encoding($false)))` (explicit no-BOM encoding). `scripts/bongos/api.js`'s `--body-file` reader now also strips a leading BOM defensively, but the safest fix is to never write one.
 - **Why it bites:** The file looks completely normal in an editor — the BOM is invisible — so the parse failure looks like a JSON syntax problem, not an encoding one.
 
 ---
@@ -220,7 +220,7 @@ Inside the namespace the file lists as `---------- 1 root root 0`. The runner un
 
 - **What:** `peer-vote-tally` (weekly) runs inside the always-on Node process via the autonomy module's poller `modules/autonomy/pollers/routine-timers.js` (ADR 0078 amendment, task 1382; carved into `modules/autonomy/` at BV1.R83) — no `claude -p`, no external cron, no token. The loader's `startModulePollers` starts it from `src/platform-server.js` at boot (task 1002419 — before that fix the call site had been lost with the retired `server.js` and no module poller started at all); it reaches `tallyPeerVotes` through the doorway. It's a no-op anywhere the DB is unreachable (builder machines), so it only does work on the prod droplet.
 - **Disable / move it out-of-process:** set `ROUTINE_TIMERS_DISABLED=1` in `/etc/example/web-source.env` and restart. Also set it on any **second** always-on instance that shares the `example` DB so the tally can't double-fold (the `FOR UPDATE OF pv` row lock is the hard guard if you forget).
-- **Run it manually now:** `node scripts/gds/run-routine.js peer-vote-tally` (the dispatcher front door still works). The cadence is boot-anchored ("~90s after boot, then weekly"), not a wall-clock Monday job — frequent deploys re-anchor it, which is harmless (the tally is idempotent).
+- **Run it manually now:** `node scripts/bongos/run-routine.js peer-vote-tally` (the dispatcher front door still works). The cadence is boot-anchored ("~90s after boot, then weekly"), not a wall-clock Monday job — frequent deploys re-anchor it, which is harmless (the tally is idempotent).
 
 ### A ship was graded FAIL but the work is genuinely good (grader false-negative)
 
@@ -266,9 +266,10 @@ Inside the namespace the file lists as `---------- 1 root root 0`. The runner un
 
 ### Your status page must not share fate with the product (and cannot measure itself)
 
-- **Symptom:** the site is down for hours, but The Watch still shows 100% / "standing".
-- **Root cause:** `status.example.com` is served by the same Node process on the same droplet as the game, and the in-process poller (`src/bongos/uptime-poller.js`) probes `127.0.0.1`. When the droplet dies, the page dies with it and the poller writes **zero rows** — the gap renders as green. A monitor that lives inside the monitored thing cannot witness its own death.
-- **Fix:** measure availability from **outside** (the external GitHub-Actions prober — `.github/workflows/status-probe.yml`, task [#565](https://example.com/builders#/task/565)) and host the status page **off-box** (follow-up [#566](https://example.com/builders#/task/566)). See [ADR 0029](../adr/0029-status-page-outage-resilience.md) + Bongos learning `#35`.
+- **Symptom:** the site is down for hours, but an uptime panel on the status page still shows 100% / "standing".
+- **Root cause (2026-06-03):** `status.example.com` was served by the same Node process on the same droplet as the game, and the uptime numbers came from an in-process poller probing `127.0.0.1`. When the droplet dies, the page dies with it and the poller writes **zero rows** — the gap renders as green. A monitor that lives inside the monitored thing cannot witness its own death.
+- **Fix:** measure availability from **outside** the box, never from the process being measured, and host the status page **off-box** (follow-up [#566](https://example.com/builders#/task/566)). See [ADR 0029](../adr/0029-status-page-outage-resilience.md) + Bongos learning `#35`.
+- **Current state (task 1004858, 2026-10-25):** the in-process poller, the in-repo prober script (its workflow was already gone) and the `/public/uptime` feed have all been removed, and the status page no longer shows uptime. The core ships **no** availability monitor and no outage alert today; the only prober left is the off-box mirror's data-only one (its banner, no alert — see `modules/status-ui/public/README.md`). Alerting on an outage needs an external monitor, set up deliberately.
 - **Why it bites:** a status page that lies is worse than none — it actively reassures you while the product is on fire.
 
 ### The live status page is NOT served by the droplet — editing the status surface + deploying does nothing