@bongos/core 1.21.174 → 1.21.176

package/docs/design/demonolith-plan.md

@@ -8,24 +8,24 @@
 
 ## The target
 
-Goal 1000079's `monoliths-eliminated` criterion (aggressive scope): **`oversized_file_count` → 0.** The ratchet ([`fitness-ratchets.js`](../../scripts/gds/fitness-ratchets.js)) counts tracked first-party `.js` files over **1,500 lines** (`OVERSIZE_LINES`), after excluding `node_modules/`, `public-docs/`, `*.min.js`, `redoc.standalone.js`, and `vendor/`. Baseline today: **12 files, `excess_lines_total` ≈ 12.3k.** Shrink-only — lower the baseline in [`config/fitness-baselines.json`](../../config/fitness-baselines.json) as each file drops under; never raise it.
+Goal 1000079's `monoliths-eliminated` criterion (aggressive scope): **`oversized_file_count` → 0.** The ratchet ([`fitness-ratchets.js`](../../scripts/bongos/fitness-ratchets.js)) counts tracked first-party `.js` files over **1,500 lines** (`OVERSIZE_LINES`), after excluding `node_modules/`, `public-docs/`, `*.min.js`, `redoc.standalone.js`, and `vendor/`. Baseline today: **12 files, `excess_lines_total` ≈ 12.3k.** Shrink-only — lower the baseline in [`config/fitness-baselines.json`](../../config/fitness-baselines.json) as each file drops under; never raise it.
 
 The 12 (current line counts on `main`):
 
 | # | File | Lines | Module | Decision | R-task |
 |---|---|---|---|---|---|
 | 1 | `modules/lifecycle/db.js` | 5,748 | lifecycle | **SPLIT** (7 seams) | 1003204 |
-| 2 | `scripts/gds/ship.js` | 4,613 | lifecycle | **SPLIT** (7 seams) | 1003205 |
+| 2 | `scripts/bongos/ship.js` | 4,613 | lifecycle | **SPLIT** (7 seams) | 1003205 |
 | 3 | `modules/hall-ui/public/builders.js` | 2,558 | hall-ui | **SPLIT** (3 seams) | 1003206 |
-| 4 | `scripts/gds/provision.js` | 2,498 | provisioning | **SPLIT** (4 seams) | 1003206 |
+| 4 | `scripts/bongos/provision.js` | 2,498 | provisioning | **SPLIT** (4 seams) | 1003206 |
 | 5 | `modules/grading/grader.js` | 2,083 | grading | **SPLIT** (5 seams) | 1003206 |
-| 6 | `scripts/gds/fitness.js` | 1,990 | devsecops | **SPLIT** (checks→modules) | 1003206 |
+| 6 | `scripts/bongos/fitness.js` | 1,990 | devsecops | **SPLIT** (checks→modules) | 1003206 |
 | 7 | `modules/hall-ui/public/goals-page.js` | 1,988 | hall-ui | **SPLIT** (extend existing carve) | 1003206 |
-| 8 | `scripts/gds/seed-v3-tasks.js` | 1,981 | (kernel) | **DELETE** (else allowlist) | 1003207 |
+| 8 | `scripts/bongos/seed-v3-tasks.js` | 1,981 | (kernel) | **DELETE** (else allowlist) | 1003207 |
 | 9 | `modules/lifecycle/routes/tasks.js` | 1,884 | lifecycle | **SPLIT** (sub-routers) | 1003206 |
 | 10 | `src/bongos/auth.js` | 1,866 | kernel | **SPLIT** (4 seams) — highest risk | 1003206 |
 | 11 | `modules/lifecycle/routes/goals.js` | 1,535 | lifecycle | **SPLIT** (extend existing carve) | 1003206 |
-| 12 | `scripts/gds/box.js` | 1,519 | dev-box | **SPLIT** (2 seams — only 19 over) | 1003206 |
+| 12 | `scripts/bongos/box.js` | 1,519 | dev-box | **SPLIT** (2 seams — only 19 over) | 1003206 |
 
 **One rule above all:** these are structural moves, not rewrites. Every split preserves behaviour, the module boundary (a module reaches core only via `src/module-api.js`, never a core internal or another module), and the public port surface. A split that changes a contract is out of scope — file it separately.
 

package/docs/design/modular-architecture/00-research-report.md

@@ -39,7 +39,7 @@ The "boundary rots back together" problem is universal; the cure is **architectu
 - ✅ **`eslint-plugin-boundaries`** is a pure ESLint plugin — **no bundler** — defining elements by path pattern + type, with a default-disallow baseline and asymmetric allow rules ([repo](https://github.com/javierbrea/eslint-plugin-boundaries), ✅ 3-0).
 - 📄 Also: dependency-cruiser (JS/TS), import-linter (Python), ArchUnit / ts-arch.
 
-🔧 Cloud Bongos already does this with `scripts/gds/fitness.js` (ADR 0062 §9 / 0061) — ahead of most teams. ADR 0080's proposed Checks 7–10 are textbook fitness functions. The semver'd published-core-API (`module-api.js`) is the standard way to make the one-way arrow usable.
+🔧 Cloud Bongos already does this with `scripts/bongos/fitness.js` (ADR 0062 §9 / 0061) — ahead of most teams. ADR 0080's proposed Checks 7–10 are textbook fitness functions. The semver'd published-core-API (`module-api.js`) is the standard way to make the one-way arrow usable.
 
 ## 4. Thread 3 — Plugin & extensibility architectures
 

package/docs/design/project-startup-direction.md

@@ -57,8 +57,8 @@ This table replaces the blended flow's table below for every hub-side capability
 ### GitHub in one trip, as built (task 1004649)
 
 - **The trip.** "Connect GitHub ↗" posts the app manifest to GitHub. The manifest now carries a `setup_url` (the hub's `/provisioning/github-app/setup`). After the approval GitHub returns to the manifest callback, which waits until the runner has placed the app's keys and recorded its name, then sends the same tab straight to `github.com/apps/<app>/installations/new`. When GitHub will describe the repo to an anonymous caller (a public repo), the link is narrowed with `/permissions?suggested_target_id=<owner id>&repository_ids[]=<repo id>`, so the founder only has to confirm. After the install, GitHub sends them to the `setup_url` with the attempt's `state`, and that page hands them back to the checklist.
-- **The ticks are server facts, never clicks.** *Approve*: GitHub made the app and the runner placed its keys (the slug is recorded only after the placement write). *Install*: the runner asks GitHub `GET /repos/{owner}/{repo}/installation`, signed as the app with the app's own key. The `installation_id` GitHub appends to the `setup_url` is never trusted, because GitHub's docs warn it can be spoofed; it only makes the runner look again. *Builders can sign in*: the runner saw `auth_configured` on the project's `/api/bongos/healthz`. The root `/healthz` answers a plain "ok", and reading that one is why every setup used to be recorded as failed (task 1004577). *Command-line sign-in*: the runner starts a device sign-in with the app's client id, and GitHub does not refuse it with `device_flow_disabled`. The facts are rows in `provisioning_events`, so no new column was needed. The checklist is derived in `modules/provisioning/github-setup.js`; the runner's check is `scripts/gds/provision-github-setup.js`.
-- **Device flow cannot be switched on for the founder (spike, task 1004649).** GitHub's manifest parameters are `name`, `url`, `hook_attributes`, `redirect_url`, `callback_urls`, `setup_url`, `setup_on_update`, `request_oauth_on_install`, `public`, `default_permissions`, `default_events` and `description`, and none of them is device flow. The REST API for apps (`/app`, `/app/installations…`, `/app-manifests/{code}/conversions`) has no endpoint that changes an app's registration. GitHub's own guide says device flow has to be enabled in the app's settings first. So the fourth step is **optional**: it reads "Optional — turn it on later" with a link to the app's settings, ticks itself when the runner sees it on, and never holds back "connected" or "is alive". Web sign-in works without it, and the CLI falls back to a web token meanwhile (`scripts/gds/device-flow-help.js`).
+- **The ticks are server facts, never clicks.** *Approve*: GitHub made the app and the runner placed its keys (the slug is recorded only after the placement write). *Install*: the runner asks GitHub `GET /repos/{owner}/{repo}/installation`, signed as the app with the app's own key. The `installation_id` GitHub appends to the `setup_url` is never trusted, because GitHub's docs warn it can be spoofed; it only makes the runner look again. *Builders can sign in*: the runner saw `auth_configured` on the project's `/api/bongos/healthz`. The root `/healthz` answers a plain "ok", and reading that one is why every setup used to be recorded as failed (task 1004577). *Command-line sign-in*: the runner starts a device sign-in with the app's client id, and GitHub does not refuse it with `device_flow_disabled`. The facts are rows in `provisioning_events`, so no new column was needed. The checklist is derived in `modules/provisioning/github-setup.js`; the runner's check is `scripts/bongos/provision-github-setup.js`.
+- **Device flow cannot be switched on for the founder (spike, task 1004649).** GitHub's manifest parameters are `name`, `url`, `hook_attributes`, `redirect_url`, `callback_urls`, `setup_url`, `setup_on_update`, `request_oauth_on_install`, `public`, `default_permissions`, `default_events` and `description`, and none of them is device flow. The REST API for apps (`/app`, `/app/installations…`, `/app-manifests/{code}/conversions`) has no endpoint that changes an app's registration. GitHub's own guide says device flow has to be enabled in the app's settings first. So the fourth step is **optional**: it reads "Optional — turn it on later" with a link to the app's settings, ticks itself when the runner sees it on, and never holds back "connected" or "is alive". Web sign-in works without it, and the CLI falls back to a web token meanwhile (`scripts/bongos/device-flow-help.js`).
 - **Left as seams for the sibling tasks.** The hand-back from any tab or device, and checking while the page is hidden (task 1004650, built: see below). The page already re-learns the checklist from the owner's instance read (`github_setup`), and that read never carries the state token. A personal or an organisation account (task 1004651). Resuming a stopped step, and a fixing button for every failure, including "check again" after the runner's two-hour window (task 1004652).
 
 ### Coming back from any tab or device, as built (task 1004650)

package/docs/design/projects-hub-direction-v2.md

@@ -87,7 +87,7 @@ These were found by the test and page mappers and confirmed against the feeds; t
 - **No feed carries a per-project hall address.** `clientBranding()` deliberately withholds domains and `{{buildersOrigin}}` is one value per instance, so "hall entry only where the hall address differs from the site address" needs a new field on `/api/bongos/projects/featured` (or `/my-projects`), e.g. `hall_origin`, null where the hall is at `<site>/builders`. On the apex the hall is `builders.cloudbongos.com` (differs); on a child it is `<site>/builders` (same).
 - **No feed carries faces or a 30-day count.** The enrichment (`modules/platform-identity/project-stats.js`) returns `builders`, `tags`, `owner`, `owner_avatar`; the faces need the remote leaderboard's avatar rows kept (the count already comes from them), and `shipped_30d` needs the remote `/api/bongos/public/recent-shipped` (row-capped at 30, hence the `N+` rule). `art_url` is already on the feed and is read by nothing.
 - **Tests that pin the retired chrome and must be retargeted in the build** (from `tests/projects_hub.mjs`, `tests/projects_hub_pre_uat.mjs`, `tests/landing_page.mjs`): the `Home` link (`projects_hub.mjs:40, 46, 48`), the hall pill's `data-link-hall href="{{buildersOrigin}}"` (`landing_page.mjs:214-220`, `projects_hub.mjs:105`), the `.shell .navrow` rule in cosmos (`projects_hub_pre_uat.mjs:203`), the card's slice rule (`projects_hub.mjs:487`: the first adjacent `</div></div>` ends the slice, so every new card region must be a direct child and the banner a bare `<img>`), the `<td>` count across the header, `#selfRow` and the row template if the glyph becomes a cell (`projects_hub.mjs:531-535`), and the singular `querySelector('[data-nav="mine"]')` at `projects.html:5307` (a `My projects` item with `data-nav="mine"` would be a second node; hide by `querySelectorAll` or hook it differently). The dropdown items keep `href="?view=map" data-nav="map"` (etc.) as adjacent attributes so `projects_hub.mjs:42-43` holds unchanged. A new bar-ground token goes into cosmos with both dark twins and a `PAIRS` row in `tests/cosmos_token_contrast.mjs`.
-- **Copy.** Every string that changes on the built page re-runs `node scripts/gds/copy-inventory.js` (CI checks the registry).
+- **Copy.** Every string that changes on the built page re-runs `node scripts/bongos/copy-inventory.js` (CI checks the registry).
 
 ## 7. The owner's decision
 

package/docs/design/reviews/hall-v2/README.md

@@ -57,7 +57,7 @@ The `harbor` and `pair` sheets were deleted when those two pages were removed wi
 | kind | count | where | what it is |
 |---|---|---|---|
 | `failed-requests` on `/api/gds/auth/web/start?return=…` | 236 | diagrams, primer — all lanes | **harness limitation.** The sign-in redirect target has no fixture on the preview harness, so each signed-out render logs one failed request per navigation. Live answers that URL with the real sign-in door (see *Gates*). |
-| `dispatchClick: nothing matches #svg .ab-node` / `#ab-index-rows …` | 28 | atlas — all lanes, first run | **harness limitation.** The atlas reads a generated, gitignored `atlas.json`; `atlas.states.json` says to run `scripts/gds/gen-atlas.js` first. Re-run with it generated: **all three lanes clean** (the sheets here are that run). |
+| `dispatchClick: nothing matches #svg .ab-node` / `#ab-index-rows …` | 28 | atlas — all lanes, first run | **harness limitation.** The atlas reads a generated, gitignored `atlas.json`; `atlas.states.json` says to run `scripts/bongos/gen-atlas.js` first. Re-run with it generated: **all three lanes clean** (the sheets here are that run). |
 | `failed-requests` on `drachmae-and-karma.md` + `public/repo-info` (`127.0.0.1`) | 28 | drachmae — all lanes | **stub limitation.** The kit's own signed-out stub carries no hall feeds; `drachmae.states.json` does not list these two as expected 404s the way `atlas.states.json` does. States-file hygiene, not a page defect (the page renders its honest empty). |
 | `controls-24px: a "roster" 37x18 \| a "sign in" 40x18` | 14 | profile `out` — all lanes, both modes | **defect → task 1003497.** The signed-out empty state's two inline links are 18px tall. Never rendered before: the harness always answers `/me`, so this state only appears against the kit's stub. |
 | `horizontal-overflow: scrollWidth 358 > 320` | 2 | work `filters-open` @320 — archon, both modes | **defect → task 1003498.** The filter drawer's goal `<select>` (332px) will not shrink; measured on the harness, it and its label are the elements past the edge. |
@@ -110,7 +110,7 @@ The `harbor` and `pair` sheets were deleted when those two pages were removed wi
 
 ```bash
 # in a checkout at the verified tree
-node scripts/gds/gen-atlas.js                                   # the atlas's generated feed
+node scripts/bongos/gen-atlas.js                                   # the atlas's generated feed
 node scripts/hall-preview/server.js --port 4641 --fixture-me --rank xenos   # and 4642 metic, 4643 archon
 for s in modules/hall-ui/public/*.states.json; do
   node modules/ui-design/kit/render.js --states "$s" --base-in http://builders.localhost:4643 \

package/docs/design/vanilla-hall-ui-redesign-scope.md

@@ -267,7 +267,7 @@ Not layout, but it rides along. Most of this already flows through the brand pac
 
 The hall has hard architectural constraints (see `modules/hall-ui/CLAUDE.md`). Placement changes are cheap only if they respect these.
 
-- **Widget registry is the source of truth.** A fitness check (`scripts/gds/fitness.js checkHallSectionRegistry`) reds the build if a `<section class="scroll">` is hardcoded into `<main>`. Views must mount registered widgets, not inline them.
+- **Widget registry is the source of truth.** A fitness check (`scripts/bongos/fitness.js checkHallSectionRegistry`) reds the build if a `<section class="scroll">` is hardcoded into `<main>`. Views must mount registered widgets, not inline them.
 - **No framework, no build step.** Static HTML/CSS/JS polling `/api/bongos/*`. The shell is hand-rolled CSS + a small amount of JS — no framework may be introduced.
 - **Dedicated serving block.** `src/bongos/serve-internal.js` serves this from `BUILDERS_DIR` with the subdomain rewrite shim, canonical redirects, page gates, and asset-stamping. New assets must carry the content-hash `?v=` stamp.
 - **Server-side gates stay authoritative.** Hiding a sidebar item is cosmetic; `requireGovernancePage` and the sign-in redirects remain the real access control.