@bongos/core 1.19.890 → 1.19.892

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.890",
-  "core_contract": "1.19.890",
-  "source_commit": "fb73c80a33c2f4e3aaf8d9ae3bb0295b6ec73e3b",
+  "core_version": "1.19.892",
+  "core_contract": "1.19.892",
+  "source_commit": "10a12417f89994d74e98a3d69ffb32e6c923fcc1",
   "source_ref": "HEAD",
-  "built_at": "2026-09-19T21:31:12.716Z",
+  "built_at": "2026-09-19T21:54:33.560Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 497,
+    "docs_redacted": 498,
     "agent_docs_stubbed": 26,
-    "functional_verbatim": 2271,
+    "functional_verbatim": 2272,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2794,
-  "tree_sha256": "8e1cc8300c4c29b876e8dc18b16384db7ade73e5948c7e009c0b69f9dadea8a7",
+  "file_count": 2796,
+  "tree_sha256": "3a0ce12eaade900074c0776354d30caac78be604f0107b72a537da133fbfc114",
   "files": [
     {
       "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -1972,7 +1972,7 @@
     {
       "path": "docs/adr/0296-a-role-speciality-is-data-over-three-existing-surfaces.md",
       "mode": "0000644",
-      "sha256": "440116d384964c06055b1c7c07c30a962b164f519c9bbf3ce910570d186f1308"
+      "sha256": "894a648aef61f34914e8ec9040fd241d012ce089f9a32c9fbc9e302c297e8912"
     },
     {
       "path": "docs/adr/0297-a-tasks-creator-may-retire-it.md",
@@ -2039,10 +2039,15 @@
       "mode": "0000644",
       "sha256": "2aabad9f28113f3e6087b4e850d46a232aaa03c68ce9e793d04b2263e06998f5"
     },
+    {
+      "path": "docs/adr/0310-a-speciality-offers-skills-and-the-adopter-chooses-them.md",
+      "mode": "0000644",
+      "sha256": "9c8eff827f7c676cb8fb73475383812746d31c9ca35e2ec4ccb3845c48d2cd63"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "22f4f461a476d43d15a9f77626bdce552736d1a5d96210b5dbd638eb758fbec5"
+      "sha256": "ca64ff12d272ebf2a1b7f6752193ad464c6b7c03118c6f9555a58d8b4a0f6e0c"
     },
     {
       "path": "docs/api-reference.md",
@@ -2607,7 +2612,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "7fb640ef029a52e521d43e2828ca0201a7e53c7a94f23fcebd58aefd6f6820fe"
+      "sha256": "9f273320150c23f11a8fae0c8f807ea57a78e35fcee9dde0bd945881fadd6889"
     },
     {
       "path": "docs/modules-contract.md",
@@ -7212,7 +7217,7 @@
     {
       "path": "modules/specialities/migrations/specialities_001_specialities.sql",
       "mode": "0000644",
-      "sha256": "055210da2726c1d17457900a9b44566c58f371b3206365c5352474114be57251"
+      "sha256": "21532391b179024f92eee8589576f612ed786b93e8ba69b817069c3ecc1fa393"
     },
     {
       "path": "modules/specialities/migrations/specialities_002_offered.sql",
@@ -7232,7 +7237,7 @@
     {
       "path": "modules/specialities/specialities.js",
       "mode": "0000644",
-      "sha256": "413477a716f3a60abc0763bccfb10a593c4eb19301131de0230eb3d72ffee299"
+      "sha256": "4d6d29e4391ab1dcc6659e88ec858dc0276aa9f2b0e6d84eafa1b9f65c04d9be"
     },
     {
       "path": "modules/status-ui/CLAUDE.md",
@@ -7707,12 +7712,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "f9267b40d96aa3395f93b456da92cb8ff99f579340e1e9ac57e2264764e7b293"
+      "sha256": "3ef1a7c4eafee4e9e92df1e0c1389acf252ff0d0f32689718cf81ee4c46ec04b"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "4185cf704dd2b4d4dddd72ad802fbc6861c66181b69bbc66eaafdec7e603da35"
+      "sha256": "52b00c86bbde5eb29b9637f15988898313b2e5318ba50d83c30fff24a699021d"
     },
     {
       "path": "public-docs/index.html",
@@ -8017,7 +8022,7 @@
     {
       "path": "scripts/gds/build-cli-package.js",
       "mode": "0000644",
-      "sha256": "630bdedb252e6d77a3427d962fca94094c747c377679ec1157644d76f142b6e8"
+      "sha256": "ca0566c509fb1ea81e7c874e2676bbcb965803509c0289c577bc8f15791e6f5c"
     },
     {
       "path": "scripts/gds/bump-version.js",
@@ -9207,7 +9212,7 @@
     {
       "path": "scripts/gds/status.js",
       "mode": "0000644",
-      "sha256": "4a1efefdb099512b31538d279b8be36cc19549fb9601d48ab47dbf43437ea1a2"
+      "sha256": "191b49e9ccbcfc7b855d834535ad5e9de0970d6e91126c7a0591e7790d196a89"
     },
     {
       "path": "scripts/gds/strand-watch.js",
@@ -9282,7 +9287,7 @@
     {
       "path": "scripts/gds/version-literal-guard.js",
       "mode": "0000644",
-      "sha256": "7e27012820d6e2fb43c84140ae6f90d4ca9345658937aa75cc9f2c28cfdaf41e"
+      "sha256": "2c0e605876762f8c6607af49374f56bc0717a1aad08c3ffdbbae383ffaf1d9dd"
     },
     {
       "path": "scripts/gds/version-select.js",
@@ -9717,7 +9722,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "7b2ddf6ecca1f92f1ae2ba7a70e0e6aeb9726ec0fa9c4a5375f075755b036796"
+      "sha256": "c0c018df9a35a17f31c17c566ded5bb5878c5c1189f62cd20ad1ea3e3e43d612"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -13589,6 +13594,11 @@
       "mode": "0000644",
       "sha256": "4b92c96ae496736b0f44182e64d42a24f108cb51fbeb5cf7cd5814ad336b14f6"
     },
+    {
+      "path": "tests/status_default_version.mjs",
+      "mode": "0000644",
+      "sha256": "9a80ed43b685ea537944886a1a4a02d35580c109bd777373e30b63afd9aa73df"
+    },
     {
       "path": "tests/status_mirror_sync.mjs",
       "mode": "0000644",
@@ -13877,7 +13887,7 @@
     {
       "path": "tests/version_literals.mjs",
       "mode": "0000644",
-      "sha256": "17e872131c17bae7a061debc1fd3ee354ab704678b475edd6a8b1dfdd63ceb2f"
+      "sha256": "3b706518920bc48e1bcd5a0185a5829a179fa0e73a6ed491320327d2cb7c8c68"
     },
     {
       "path": "tests/version_override_visibility.mjs",

package/docs/adr/0296-a-role-speciality-is-data-over-three-existing-surfaces.md

@@ -27,7 +27,7 @@ The owner's phrasing is that specialities "are more or less MODULES", and the pu
 |---|---|
 | craft → playbook | `discipline-modes.json` |
 | the per-session interaction contract | `behavior_prefs.interaction` → `GET /me` → the Conductor hook |
-| declared skills | the ADR 0083 manifest contribution seam |
+| declared skills | **not built by this ADR** — see [ADR 0310](0310-a-speciality-offers-skills-and-the-adopter-chooses-them.md), which decides the shape (a speciality OFFERS skills; the adopter enables them one at a time, walked through each) and leaves the build to its own tasks |
 | **the knowledge bundle** | **new — `speciality_documents` + `speciality_learnings`** |
 
 Only the fourth is new machinery. In particular **a speciality contract rides the existing injection path rather than adding a second one**: `GET /me` gains a slice, the Conductor relays it, and the composition stays server-side exactly as it does for the interaction profile.

package/docs/adr/0310-a-speciality-offers-skills-and-the-adopter-chooses-them.md

@@ -0,0 +1,81 @@
+# ADR 0310 — A speciality OFFERS skills; the adopter turns them on, one at a time, having been shown what each does
+
+**Status:** accepted · **Date:** 2026-09-19 · **Task:** [#1003978](https://cloudbongos.com/builders#/task/1003978) · **Goal:** 1000095 · **Supersedes nothing; completes [ADR 0296](0296-a-role-speciality-is-data-over-three-existing-surfaces.md)**
+
+## Context
+
+[ADR 0296](0296-a-role-speciality-is-data-over-three-existing-surfaces.md) defines a speciality as *"a named bundle of knowledge, skills and an interaction contract that sits UNDER a craft"*, and names three ingredients over three existing surfaces. **Two of the three shipped.** `contract_md` is the interaction contract; `specialities_documents` + `specialities_learnings` are the knowledge.
+
+The third never existed. There is no skills column, no skills field on the draft, nothing in `validateDraft`, nothing in the routes, nothing in the injected contract. `grep -i skill` across the module's schema, domain and routes returns only the header sentences describing a thing that is not there — in the ADR, in the migration header, in `specialities.js`, and in the module's `CLAUDE.md` table.
+
+That is prose asserting behaviour the code does not have, and it is worse here than usual because it is the feature's own definition. Task 1003978 filed it, and deliberately withheld an implementation: *"Do NOT start by adding a `skills` column. Decide (2) first"* — (2) being whether naming a skill grants anything.
+
+**Why it matters rather than being a doc typo.** The point of a speciality is that an expert's way of working arrives in a session. Two-thirds of that is context and tone; the third is *what the session can DO*. An economics speciality that brings a costing skill is materially different from one that only changes how Claude talks. Without it, a speciality changes framing and never capability.
+
+## The owner's ruling (2026-09-19)
+
+Asked whether specialities should carry skills at all, and if so how:
+
+> *"Specialities should carry skills but these should be user based, giving people edges in the beginning and then eventually being able to share these specialities with others. But also, if say two people are economist ideator specialists, then they decide which skills they want to use and which are relevant to them. It does not become super blanketed."*
+
+Asked whether an adopted speciality's skills should arrive switched on or off:
+
+> *"They should be off, and you should walk through what comes with each, people need to learn the system and understand things instead of preventing learning."*
+
+Two rulings, and the second is the sharper one. It is not a safe default chosen to avoid surprise — it is a **position about learning**. The moment of adoption is the moment a person is most willing to find out what a tool does, and handing them a working toolkit silently spends that moment. Being walked through each skill and choosing it is how the system gets understood.
+
+## Decision
+
+### 1. A speciality DECLARES candidate skills. It grants nothing.
+
+This answers task 1003978's question (2), and the answer is the strong one: **naming a skill can never confer it.** Skills are materialised into a checkout by other machinery (`claude-materialize.js`), and permission is rank-gated server-side with no caching ([ADR 0016](<redacted>.md)). A speciality may say *"in this speciality, reach for `/recall` and `/status` first"*; it may not hand anyone a capability they did not already have.
+
+The task warned that a column *"would imply an authority it must not have"*. It does not, given point 2 — because the declaration is a menu, and a menu is not an entitlement. What makes that safe is not the storage shape but the fact that enabling a skill still passes every existing gate, unchanged.
+
+### 2. The adopter chooses, per person, and starts with nothing on
+
+Two layers, because one layer is the blanket the owner ruled against:
+
+| Layer | Holds | Why there |
+|---|---|---|
+| `specialities_catalog` | the skills this speciality OFFERS | the speciality is the thing being shared |
+| `specialities_adoptions` | the skills THIS builder turned on | already per-builder, already the row an adoption creates |
+
+Two people holding the same economist ideator speciality share its knowledge and its contract, and need not share a single enabled skill. That is the ruling, and the second table is where it becomes true rather than documented.
+
+**Default: nothing enabled.** An adoption begins with an empty set.
+
+### 3. Adoption is a walkthrough, not a toggle list
+
+The consequence of the default that carries the actual intent. Adopting a speciality must **present each offered skill in turn — what it does, when its author reaches for it, what it costs** — and let the person enable it there, then. A settings page with eleven unchecked boxes satisfies the letter of "off by default" and defeats the ruling entirely.
+
+The bar: **a person who has finished adopting a speciality can say what each skill in it does.** If the flow does not produce that, it is not built yet, whatever the schema says.
+
+### 4. Sharing needs no new mechanism
+
+Already shipped in `specialities_catalog`: `owner_kind` (`builder` | `project`), `visibility` (`private` → `project` → `public`), `offered`, `sellable`. The owner's *"edges in the beginning and then eventually being able to share"* is exactly that ladder, and it exists. Skills ride it for free: a speciality shared with its offered set intact is shared whole, and each new adopter still starts from nothing enabled and walks through.
+
+## What this is NOT
+
+- **Not a grant of authority.** Repeated because it is the invariant most likely to erode.
+- **Not a way to declare a skill that does not exist.** A speciality may name only skills the instance actually has, or adoption offers a walkthrough of something that will 404 at the moment a person most needs it.
+- **Not blanketed by craft.** A speciality's skills belong to the speciality, never to the craft above it.
+- **Not authored by us.** [ADR 0296](0296-a-role-speciality-is-data-over-three-existing-surfaces.md): the deliverable is the mechanism, not a catalogue of specialities.
+
+## Consequences
+
+**The four documentation sites stop lying today, and do not start lying differently.** They currently claim a shipped ingredient. Until the build lands they must say *declared, decided, not yet built*, pointing here — the ADR, the migration header, `specialities.js`, and the module `CLAUDE.md`.
+
+**A skill's own description becomes load-bearing.** The walkthrough is only as good as the text it shows, and skill descriptions were written to be *matched* by a model, not *read* by a newcomer. Whoever builds the walkthrough will find this.
+
+**Adoption gets slower, on purpose.** That is the cost the ruling accepts.
+
+## Build order
+
+Deliberately separate tasks, because the middle one is where the ruling lives and it should not be a sub-bullet of a schema change:
+
+1. **Schema + validation** — the offered set on the catalog, the enabled set on the adoption, `validateDraft`, the routes. Refuses a skill the instance does not have.
+2. **The walkthrough** — the adoption flow that presents each skill and takes a decision. The ruling's real deliverable.
+3. **Injection** — the enabled set reaches the session through the contract the Conductor already injects; a line naming the skills this builder leans on, per [ADR 0296](0296-a-role-speciality-is-data-over-three-existing-surfaces.md)'s pattern of using surfaces that exist.
+
+Nothing is built by this ADR. It is the decision task 1003978 asked to be made first.

package/docs/adr/README.md

@@ -401,3 +401,4 @@ This keeps the decision history honest and traceable.
 | 0307 | [**Autobongos: a deterministic supervisor, agentic workers** ([task 1003900](https://cloudbongos.com/builders#/task/1003900), goal 1000119). An always-on machine works the queue unattended inside owner-allowlisted goals. Most of the loop already existed wired to the wrong trigger — `sequence.js`'s ten-reason halt matrix (ADR 0153), an open blocker as the hold state, the Windows-aware headless spawn seam, `overnight-builder` — but the trigger was cron rather than capacity, and the **supervisor was itself a Claude session**. Decided: the supervisor is a **program**, only the worker is a session; the gauge is the statusLine's `rate_limits.five_hour`/`seven_day`, which per Anthropic's own note is absent until a session's first API response and so **cannot be read cold** (a statusline script persists it, a stale file is *unknown*, never *headroom*); **one session per task, metering not estimating** (a successor cannot be claimed until its predecessor ships, so a batch produces the same order while risking a half-done window, and a fresh session avoids a checkout going stale behind main); **completion is read from the ledger, never the session** (a worker that stopped needing a decision returns `subtype: success`, identical to one that finished); **no terminal stop, only speeds** (three failures → a probing state that self-heals; the only true stop is the server-side kill switch); the machine holds **no push credential**, so a grader outage stops the run rather than shipping unreviewed. The load-bearing finding was **tested before it was decided**: a worker told plainly to stop and ask instead settled four judgement calls and wrote them to disk — competent, and fatal to any design that waits for raised hands. Hence **gate before, record after, nothing in between**: the halt matrix refuses ambiguous work at pick time, and the worker's verdict must declare what the spec did not determine. Rejected: per-call `--permission-prompt-tool` (a thousand weak gates, and one slow supervisor stalls every worker), `--max-budget-usd` (caps dollars; on a subscription the constraint is capacity, so the bound is wall-clock), extending `overnight-builder`, and a terminal stop. Deliberately not built: mid-flight question answering, portability, per-task estimation.](0307-autobongos-a-deterministic-supervisor-and-agentic-workers.md) | autonomy / sessions |
 | 0308 | [**An eleventh working area: Autobongos** ([task 1003900](https://cloudbongos.com/builders#/task/1003900), goal 1000119). Amends [ADR 0264](0264-the-ten-working-areas.md), which nine days earlier collapsed 38 goals into **ten** areas held until 5,000 builders. Area 11 is Autobongos ([goal 1000119](https://cloudbongos.com/builders#/goal/1000119), owner Lars). **Area 6 was the obvious home and was rejected**: area 6 is about a human's experience of the platform, and this area has no human in it — which limits to spend, which fences hold unsupervised, how it recovers with nobody at the keyboard. Those get less attention next to work with a user in front of it, not better answers. It **reopens** goal 1000028 (*Autonomy groundwork*), archived in the 38→10 cut with no successor and carried as `succeeds_goal_id`, so the lineage is in the ledger rather than the prose — and ADR 0264 §3 had already left "fold, keep as an eleventh, or close" as a live owner question. Admitting it cost something recorded: BONGOS-V2 is `building`, so its goal set is closed (ADR 0250) and `POST /goals` refuses `version_not_planning` — an Archon reopened it with a stored `admit_reason`, which is the cut holding well enough that adding to it left evidence. Does not decide: the ten-area discipline stands (one exception, written reason, 5,000-builder horizon unchanged), 0264 §3's other two open rows, or a second goal for the area.](0308-an-eleventh-working-area.md) | methodology / goals |
 | 0309 | [**Module enablement is a database row, above the committed pack and below env** ([task 1002857](https://cloudbongos.com/builders#/task/1002857), goal 1000091). The hall Modules-tab toggle ([ADR 0107](0107-module-upstreaming-contribution-to-core-catalog.md) §9) wrote `config/modules.json` and reloaded the cache, so it looked like it worked — but that file is the committed instance pack and the pull-deploy runs `git reset --hard origin/main`, so the toggle reverted on the next deploy, **silently**. Enablement moves to `module_enablement_overrides` (migration `core_248`), read as one precedence layer: neutral pack → instance pack → **DB override** → env → default. **Above the pack** because the pack is what a deploy restores, so an override below it would be erased by the event it exists to survive; **below env** because `<PREFIX>_MODULE_<KEY>` is the incident knob and must not need a reachable database. **Auto-committing to `main` stays rejected** ([ADR 0016](<redacted>.md)): durability belongs in the DB, not in an HTTP handler that writes to the default branch. Two open design points settled: the **scope key** is the resolved instance pack path (the only axis two instances sharing one database differ on, so one sibling's toggle cannot flip the other's module), and the DB is read into a **snapshot** refreshed at boot and on write rather than inline, because `loadModules()` is synchronous and making it async would ripple into every consumer of a module flag. An unreachable database is a **no-op** — no row means "no opinion", not "off". Does not decide: whether a toggle should also restart the process so remounting is immediate.](0309-durable-module-enablement-db-override.md) | modules / ops |
+| 0310 | [**A speciality OFFERS skills; the adopter turns them on, one at a time, having been shown what each does** ([task 1003978](https://cloudbongos.com/builders#/task/1003978), goal 1000095). Completes [ADR 0296](0296-a-role-speciality-is-data-over-three-existing-surfaces.md), which defined a speciality as knowledge + skills + an interaction contract and shipped two of the three: `grep -i skill` across the module's schema, domain and routes returns only the header sentences describing a thing that is not there — prose asserting behaviour the code does not have, and the feature's own definition at that. Task 1003978 withheld an implementation until the authority question was answered, and the answer is the strong one: **naming a skill GRANTS NOTHING**. Skills are materialised by `claude-materialize.js` and permission is rank-gated server-side with no caching ([ADR 0016](<redacted>.md)); a speciality offers a menu, and a menu is not an entitlement. **Two layers, because one layer is the blanket the owner ruled against**: the catalog holds what a speciality OFFERS, the already-per-builder `specialities_adoptions` row holds what THIS builder turned on — so two economist ideators share a speciality's knowledge and contract and need not share one enabled skill. **The default is nothing enabled, and that is a position about LEARNING rather than a safe default**: the owner's ruling is that adoption must *walk through what comes with each* because *people need to learn the system*. A settings page of unchecked boxes satisfies the letter and defeats the intent, so the bar is a user test — a person who has finished adopting can say what each skill does. Sharing needs no new mechanism: `owner_kind` / `visibility` / `offered` / `sellable` already ship the private→project→public ladder, and skills ride it. Builds nothing; the three-task order (schema, walkthrough, injection) is filed, and the four documentation sites that claimed a shipped ingredient now say decided-not-built.](0310-a-speciality-offers-skills-and-the-adopter-chooses-them.md) | specialities / methodology |

package/docs/module-api-changelog.md

@@ -2254,5 +2254,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.888 with no explicit bump. run 35470239834. (task 1002620)
   1.19.890 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.889 with no explicit bump. run 35470624284. (task 1002620)
+  1.19.891 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.890 with no explicit bump. run 35471575521. (task 1002620)
+  1.19.892 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.891 with no explicit bump. run 35471773244. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/modules/specialities/migrations/specialities_001_specialities.sql

@@ -1,5 +1,5 @@
 -- specialities_001_specialities.sql — role sub-specialities: a named bundle of
--- context, skills and an interaction contract that sits UNDER a craft
+-- context, skills (ADR 0310 — decided 2026-09-19, NOT built: no column here holds them) and an interaction contract that sits UNDER a craft
 -- (task 1003855, goal 1000095; ADR 0296).
 --
 -- WHAT A SPECIALITY IS, AND WHY IT IS DATA RATHER THAN CODE. The owner's framing

package/modules/specialities/specialities.js

@@ -1,5 +1,5 @@
 // modules/specialities/specialities.js — role SUB-SPECIALITIES: a named bundle of
-// knowledge, skills and an interaction contract that sits UNDER a craft
+// knowledge, skills (ADR 0310 — decided, NOT yet built) and an interaction contract that sits UNDER a craft
 // (task 1003855, goal 1000095; ADR 0296).
 //
 // WHAT THIS IS FOR. A craft says how you work (engineer / ideator / artist / ui).
@@ -14,7 +14,12 @@
 //                                  resolved into GET /me and injected by the
 //                                  Conductor hook — a speciality contract rides
 //                                  that SAME path, it does not add a second one
-//   • declared skills              the ADR 0083 manifest contribution seam
+//   • declared skills              NOT BUILT. Decided in ADR 0310 (task 1003978)
+//                                  and deliberately not implemented there: a speciality
+//                                  will OFFER skills, and each adopter enables them one
+//                                  at a time after being shown what each does. Nothing
+//                                  in this file, the schema or the routes carries it yet —
+//                                  `grep -i skill` here finds only prose.
 // The genuinely new part is the knowledge bundle, which is why the migration adds
 // tables for it and this file carries the rules over them.
 //

package/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.890",
+  "version": "1.19.892",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.890",
+      "version": "1.19.892",
       "license": "AGPL-3.0-or-later",
       "dependencies": {
         "express": "^4.21.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.890",
+  "version": "1.19.892",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",

package/scripts/gds/build-cli-package.js

@@ -67,6 +67,10 @@ const FILES = [
   'scripts/gds/start.js',
   'scripts/gds/context-pack.js', // start.js renders through this
   'scripts/gds/status.js',
+  // status.js resolves its default version at runtime instead of naming one
+  // (task 1004071) -- so the packaged CLI needs this too, or `bongos status`
+  // dies on a missing module. tests/cli_package.mjs caught exactly that.
+  'scripts/gds/version-select.js',
   'scripts/gds/task.js',
   'scripts/gds/recall.js',
   'scripts/gds/cost.js',

package/scripts/gds/status.js

@@ -19,14 +19,24 @@
 //
 // Exit codes: 0 ok · 1 network/api error · 2 bad invocation · 3 not found.
 
-const { API_BASE, cliClient, assertInstanceMatch } = require('./cli-lib');
+const { API_BASE, cliClient, assertInstanceMatch, cliExit } = require('./cli-lib');
 const { resolveEnv } = require('../../src/instance-config');
+const { resolveDefaultVersion } = require('./version-select.js');
 
-// The active internal version; override with <PREFIX>_STATUS_DEFAULT_VERSION (or pass
-// --version). Bumped GDS-V4 → BONGOS-V1 (task 1709, ADR 0103): GDS-V4 was
-// consolidated into BONGOS-V1 (the Cloud Bongos platform version) and frozen, so
-// the bare `/status` card should default to the live version, not a sealed one.
-const DEFAULT_VERSION = resolveEnv('STATUS_DEFAULT_VERSION') || 'BONGOS-V1';
+// The active internal version is RESOLVED, never named here. Override with
+// <PREFIX>_STATUS_DEFAULT_VERSION or --version.
+//
+// WHY THERE IS NO LITERAL (task 1004071). This line used to read
+//   const DEFAULT_VERSION = resolveEnv('STATUS_DEFAULT_VERSION') || 'BONGOS-V1';
+// under a comment promising "the bare /status card should default to the live
+// version, not a sealed one" — the same fix task 1709 had already applied once,
+// for GDS-V4 → BONGOS-V1. BONGOS-V1 then sealed, nobody bumped the literal, and
+// /status served a shipped version's closing scoreboard (140/203 satisfied) as
+// the project's current status. It reads as a healthy project, which is why it
+// sat: nothing in the output says `shipped`, and /status is what a session runs
+// precisely when it does NOT already know. Bumping the literal again would only
+// re-arm the same bomb for whoever seals BONGOS-V2, so the rule is derived from
+// `versions.status` instead — the selection capture.js has always used.
 
 // Compact, status-first ordering for the "remaining: …" summaries.
 const STATUS_ORDER = ['shipped', 'confirmed', 'completed', 'claimed', 'ready', 'blocked', 'backlog'];
@@ -53,7 +63,36 @@ function parseArgs(argv) {
     else if (!criterion) criterion = a.toUpperCase();
     else return { error: `unexpected argument: ${a}` };
   }
-  return { version: version || DEFAULT_VERSION, criterion, json, widget, hook };
+  // No `versionExplicit` companion flag: `version !== null` already IS that
+  // fact, and resolveVersion returns `defaulted`/`source` for anyone who needs
+  // to act on it. A second field carrying the same truth is one that can drift.
+  return { version: version || null, criterion, json, widget, hook };
+}
+
+// Resolve which version this invocation is about. Precedence: an explicit
+// --version (or bare token) > the env override > the live BUILDING version.
+// Returns { version, defaulted, source }; version is NULL when nothing is
+// building, which the caller must treat as "stop and say so", never as a guess.
+// Deps are injectable so the precedence is unit-tested without a session.
+async function resolveVersion(opts, deps = {}) {
+  if (opts.version) return { version: opts.version, defaulted: false, source: 'flag' };
+  const env = (deps.resolveEnv || resolveEnv)('STATUS_DEFAULT_VERSION');
+  if (env) return { version: env, defaulted: true, source: 'env' };
+  const resolve = deps.resolveDefaultVersion || resolveDefaultVersion;
+  const building = await resolve();
+  if (building) return { version: building, defaulted: true, source: 'building' };
+  return { version: null, defaulted: true, source: 'none' };
+}
+
+// One line naming a version the USER did not, so a cross-version answer cannot
+// pass unnoticed. `Cn` is version-scoped and the versions number independently
+// — BONGOS-V1 C8 is `money-one-unit`, BONGOS-V2 C8 is `wa6-kernel-and-packs` —
+// so a silently-defaulted version answers a different question than the one
+// asked. Empty when the user named the version: they already know.
+function defaultedVersionNote(r) {
+  if (!r || !r.defaulted || !r.version) return '';
+  const why = r.source === 'env' ? 'from STATUS_DEFAULT_VERSION' : 'the version currently building';
+  return `(no version given — showing ${r.version}, ${why}. Pass --version to pick another.)`;
 }
 
 async function fetchProgress(version) {
@@ -325,7 +364,38 @@ async function main() {
   // apiCall/cliClient guard, so without this `bongos status` would silently print another
   // instance's progress. Skip only in --hook mode (the automated card path stays fail-open).
   if (!opts.hook) await assertInstanceMatch();
-  const data = await fetchProgress(opts.version);
+
+  // Resolve the version before anything fetches. --hook stays FAIL-OPEN like the
+  // instance check above: the automated card path must degrade, not throw, so a
+  // lookup that cannot answer emits an empty envelope rather than killing the hook.
+  //
+  // COST: one extra sequential GET /versions before the progress fetch, and it
+  // cannot be parallelised — the id IS the second call's path. It is paid only
+  // when no version was named: --version and STATUS_DEFAULT_VERSION both
+  // short-circuit it, so an instance that minds the round trip on the
+  // session-start card path sets the env var once and pays nothing. That is the
+  // deliberate trade against the alternative, which is the literal that spent
+  // months reporting a sealed version as current.
+  const picked = await resolveVersion(opts).catch(() => ({ version: null, defaulted: true, source: 'none' }));
+  if (!picked.version) {
+    if (opts.hook) {
+      process.stdout.write(JSON.stringify({
+        widgets_enabled: false, html: '', markdown: '',
+        warnings: ['status: no version is currently `building` — nothing to report.'],
+      }) + '\n');
+      return;
+    }
+    console.error('status: no version is currently `building` — cannot resolve a default.');
+    console.error('  Open one, or pass --version explicitly (e.g. --version BONGOS-V2).');
+    // cliExit, NOT process.exit: resolveVersion above just made a network round
+    // trip, and a hard exit while the request machinery is tearing down aborts
+    // natively on Windows + Node 24 (UV_HANDLE_CLOSING) — exit 127 AFTER the
+    // message prints, so a caller reads "tooling broken" instead of "no building
+    // version". The other exits in this file are pre-request or have substantial
+    // rendering between; this branch has neither. See scripts/gds/CLAUDE.md.
+    return cliExit(3);
+  }
+  const data = await fetchProgress(picked.version);
 
   // Resolve the requested criterion (if any) once — every output mode needs it.
   let c = null;
@@ -333,7 +403,10 @@ async function main() {
     const n = Number(opts.criterion.slice(1));
     c = data.criteria.find((x) => x.cnum === n);
     if (!c) {
-      console.error(`status: ${opts.version} has no criterion ${opts.criterion} (it has C1–C${data.criteria.length}).`);
+      // Name the version, not just the criterion: on a DEFAULTED version this is
+      // the reader's only clue that C13 was looked up somewhere they didn't pick.
+      console.error(`status: ${picked.version} has no criterion ${opts.criterion} (it has C1–C${data.criteria.length}).`);
+      if (picked.defaulted) console.error(`  ${defaultedVersionNote(picked)}`);
       process.exit(3);
     }
   }
@@ -356,9 +429,12 @@ async function main() {
   // else the whole version rollup).
   if (opts.json) { console.log(JSON.stringify(c || data, null, 2)); return; }
 
-  // Default human output — the existing plain-text rollup, unchanged.
-  if (c) { printOne(data, c); return; }
-  printAll(data);
+  // Default human output — the existing plain-text rollup, plus one line when
+  // the version was resolved rather than chosen (--json/--widget/--hook are
+  // machine interfaces and stay byte-identical).
+  if (c) printOne(data, c); else printAll(data);
+  const note = defaultedVersionNote(picked);
+  if (note) console.log(`  ${note}\n`);
 }
 
 if (require.main === module) {
@@ -368,4 +444,4 @@ if (require.main === module) {
   });
 }
 
-module.exports = { parseArgs, renderStatusWidget, renderStatusMarkdown };
+module.exports = { parseArgs, resolveVersion, defaultedVersionNote, renderStatusWidget, renderStatusMarkdown };

package/scripts/gds/version-literal-guard.js

@@ -35,13 +35,31 @@ const VERSION_LITERAL = String.raw`['"][A-Z][A-Z0-9]*-V\d+['"]`;
 const VERSION_FIELD = String.raw`version_id|versionId|suggested_version|target_version|DEFAULT_VERSION|VERSION_ID`;
 const ASSIGNED = new RegExp(`(?:${VERSION_FIELD})\\s*['"]?\\s*[:=][^,;)]*${VERSION_LITERAL}`);
 const DEFAULTED = new RegExp(`--version[^\\n]*?\\|\\|\\s*${VERSION_LITERAL}`);
+// A version field FALLING BACK to a literal through `||`. ASSIGNED cannot see
+// this shape: its `[^,;)]*` stops at the first `)`, so any call between the `=`
+// and the literal hides it — `DEFAULT_VERSION = resolveEnv('X') || 'BONGOS-V1'`
+// scanned CLEAN while `DEFAULT_VERSION = 'BONGOS-V1'` was caught (task 1004071).
+// That is the exact line that served a sealed version as /status's default for
+// months. Kept as its own narrow pattern rather than loosening ASSIGNED to
+// `[^;]*`, which would fire on any line merely mentioning a field and a literal
+// — the over-broad source assertion this repo keeps relearning (learning 1000196).
+const FALLBACK = new RegExp(`(?:${VERSION_FIELD})\\s*['"]?\\s*[:=][^;]*?\\|\\|\\s*${VERSION_LITERAL}`);
 
 // path::reason. A justified entry, one line, like every other guard here.
+//
+// A REASON MAY CITE THE CODE'S SHAPE, NEVER THE DATABASE'S CONTENTS (task
+// 1004071). status.js was exempted because "TWO versions are currently building
+// — so 'most recent building' is not a derivable answer here." True the day it
+// was written; false once CB-V1 sealed. Nothing re-checks prose, so the entry
+// outlived its justification in silence and /status went on serving a SHIPPED
+// version's closing scoreboard as the project's current status. An entry whose
+// truth depends on rows is a timer nobody set. `version_literals.mjs` now fails
+// CI on an entry that is outright DEAD; it cannot police one that is merely
+// stale, which is why that judgement has to be made here, when the entry is
+// written.
 const VERSION_LITERAL_ALLOW = new Map([
   ['scripts/gds/grade-smoke.js',
     'GOOD_TASK / BAD_TASK are in-memory fixtures handed to grader.gradeSubagent; they are never POSTed, so no version_closed can refuse them and the literal cannot rot into a failure.'],
-  ['scripts/gds/status.js',
-    'DEFAULT_VERSION is an owner-facing dashboard default with an env override, and TWO versions are currently building — so "most recent building" is not a derivable answer here. Retargeting what /status shows by default is an owner decision, not a refactor.'],
 ]);
 
 function isExempt(rel) {
@@ -67,7 +85,7 @@ function scanScripts(files, read) {
     scanned += 1;
     if (VERSION_LITERAL_ALLOW.has(rel)) continue;
     stripComments(src, rel).forEach((line, i) => {
-      if (ASSIGNED.test(line) || DEFAULTED.test(line)) {
+      if (ASSIGNED.test(line) || DEFAULTED.test(line) || FALLBACK.test(line)) {
         violations.push(
           `${rel}:${i + 1} names a version id where one should be RESOLVED: ${line.trim().slice(0, 90)}`
           + ' — a literal works until that version ships, then version_closed refuses every write and the'
@@ -119,4 +137,4 @@ function main() {
 
 if (require.main === module) main();
 
-module.exports = { checkNoVersionLiterals, scanScripts, stripComments, isExempt, VERSION_LITERAL_ALLOW, ASSIGNED, DEFAULTED };
+module.exports = { checkNoVersionLiterals, scanScripts, stripComments, isExempt, VERSION_LITERAL_ALLOW, ASSIGNED, DEFAULTED, FALLBACK };

package/src/module-api.js

@@ -71,7 +71,7 @@ const { responsibilityFor, ROLE_RESPONSIBILITIES } = require('./role-responsibil
 // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
 // the entry to that file. Look for a version's history there, not here.
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.890'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.892'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');

package/tests/status_default_version.mjs

@@ -0,0 +1,136 @@
+// tests/status_default_version.mjs — /status resolves its default version at
+// RUNTIME and never falls back to a sealed one (task 1004071).
+//
+// THE INCIDENT. `scripts/gds/status.js:29` read
+//   const DEFAULT_VERSION = resolveEnv('STATUS_DEFAULT_VERSION') || 'BONGOS-V1';
+// while the comment three lines above stated the rule it was meant to keep:
+// "the bare /status card should default to the live version, not a sealed one."
+// BONGOS-V1 was later sealed and the literal was never bumped, so bare `/status`
+// served a shipped version's closing scoreboard — 140/203 satisfied — as the
+// project's CURRENT status. The output looks perfectly healthy, which is why it
+// sat: nothing in the header says `shipped`, and /status is exactly what a
+// session runs when it does NOT already know the answer and so cannot tell.
+//
+// WHY THE GUARD DID NOT CATCH IT. version-literal-guard.js already hunts this
+// shape and already owns the remedy (version-select.js). status.js was on its
+// allowlist, justified by "TWO versions are currently building — so 'most recent
+// building' is not a derivable answer here." That was TRUE when written
+// (BONGOS-V1 + CB-V1). It is false now: one version is building. The entry did
+// not become wrong through anyone's error — the world moved under a justification
+// that was a claim about live state, with nothing re-checking it. That staleness
+// is the class defect, and `version_literals.mjs` now pins it.
+//
+// The rule these tests hold: an EXPLICIT choice always wins (flag, then env),
+// a default is RESOLVED, and when nothing is building we stop rather than guess.
+import { strict as assert } from 'node:assert';
+import { test } from 'node:test';
+import { createRequire } from 'node:module';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+const require = createRequire(import.meta.url);
+const ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..');
+const status = require(path.join(ROOT, 'scripts', 'gds', 'status.js'));
+const { parseArgs, resolveVersion } = status;
+
+// A deps bundle with nothing configured: no env override, nothing building.
+const deps = (over = {}) => ({
+  resolveEnv: () => null,
+  resolveDefaultVersion: async () => null,
+  ...over,
+});
+
+// ---- parseArgs no longer bakes the default in -----------------------------
+test('parseArgs leaves version NULL when none is given, so main can resolve it', () => {
+  const o = parseArgs(['node', 'status.js']);
+  assert.equal(o.version, null, 'a literal default here is the bug this task fixes');
+  assert.equal(o.criterion, null, 'and nothing was mistaken for a criterion');
+});
+
+test('an explicit --version is still carried through', () => {
+  const o = parseArgs(['node', 'status.js', '--version', 'BONGOS-V2']);
+  assert.equal(o.version, 'BONGOS-V2');
+
+});
+
+test('a bare version token is carried through too', () => {
+  const o = parseArgs(['node', 'status.js', 'BONGOS-V2']);
+  assert.equal(o.version, 'BONGOS-V2');
+
+});
+
+test('a bare Cn token is a criterion, not a version', () => {
+  const o = parseArgs(['node', 'status.js', 'C8']);
+  assert.equal(o.criterion, 'C8');
+  assert.equal(o.version, null, 'C8 must not be mistaken for a version id');
+});
+
+// ---- the resolution order -------------------------------------------------
+test('an explicit flag beats both the env override and the building lookup', async () => {
+  const r = await resolveVersion({ version: 'GDS-V3' }, deps({
+    resolveEnv: () => 'ENV-V9',
+    resolveDefaultVersion: async () => 'BONGOS-V2',
+  }));
+  assert.equal(r.version, 'GDS-V3');
+  assert.equal(r.defaulted, false, 'the user chose it, so nothing was defaulted');
+  assert.equal(r.source, 'flag');
+});
+
+test('the env override beats the building lookup, and still counts as defaulted', async () => {
+  const r = await resolveVersion({ version: null }, deps({
+    resolveEnv: () => 'ENV-V9',
+    resolveDefaultVersion: async () => 'BONGOS-V2',
+  }));
+  assert.equal(r.version, 'ENV-V9');
+  assert.equal(r.source, 'env');
+  assert.equal(r.defaulted, true, 'the user did not name it on this invocation');
+});
+
+test('with no flag and no env, the BUILDING version is resolved at runtime', async () => {
+  const r = await resolveVersion({ version: null }, deps({
+    resolveDefaultVersion: async () => 'BONGOS-V2',
+  }));
+  assert.equal(r.version, 'BONGOS-V2');
+  assert.equal(r.source, 'building');
+  assert.equal(r.defaulted, true);
+});
+
+test('THE INCIDENT: when nothing is building we return null, never a sealed guess', async () => {
+  // version-select.js already refuses to guess here, and status must not
+  // reintroduce the guess downstream of it. A sealed version's final scoreboard
+  // presented as current status is worse than an error, because it looks fine.
+  const r = await resolveVersion({ version: null }, deps());
+  assert.equal(r.version, null);
+  assert.equal(r.source, 'none');
+});
+
+test('a resolved default never returns a SHIPPED version', async () => {
+  // Wired through the real selection rule rather than a stub, so this test fails
+  // if pickDefaultVersion is ever loosened to fall back to the newest-any-status.
+  const { pickDefaultVersion } = require(path.join(ROOT, 'scripts', 'gds', 'version-select.js'));
+  const versions = [
+    { id: 'BONGOS-V1', status: 'shipped', started_at: '2026-06-20' },
+    { id: 'CB-V1', status: 'shipped', started_at: '2026-06-21' },
+    { id: 'BONGOS-V2', status: 'building', started_at: '2026-06-22' },
+  ];
+  const r = await resolveVersion({ version: null }, deps({
+    resolveDefaultVersion: async () => pickDefaultVersion(versions),
+  }));
+  assert.equal(r.version, 'BONGOS-V2', 'the only building row wins over two newer-looking sealed ones');
+});
+
+// ---- the drill-in must say which version it answered about ----------------
+test('a DEFAULTED version is announced, so a cross-version answer cannot pass unnoticed', () => {
+  // Cn is version-scoped and the versions number independently: BONGOS-V1 C8 is
+  // `money-one-unit`, BONGOS-V2 C8 is `wa6-kernel-and-packs`. Asking for "C8"
+  // against a silently-defaulted version answers a different question than the
+  // one asked, and the old output gave the reader nothing to notice it by.
+  const note = status.defaultedVersionNote({ version: 'BONGOS-V2', defaulted: true, source: 'building' });
+  assert.match(note, /BONGOS-V2/, 'it names the version it resolved');
+  assert.match(note, /building/, 'and why that one');
+});
+
+test('an explicitly chosen version is NOT announced — no noise when the user said it', () => {
+  const note = status.defaultedVersionNote({ version: 'BONGOS-V2', defaulted: false, source: 'flag' });
+  assert.equal(note, '', 'the user already knows which version they asked for');
+});

package/tests/version_literals.mjs

@@ -199,3 +199,95 @@ test('ship-flow.js imports every cross-module function it calls', () => {
     }
   }
 });
+
+// ---- an exemption must not outlive its justification ----------------------
+// Task 1004071. scripts/gds/status.js sat on VERSION_LITERAL_ALLOW justified by
+// "TWO versions are currently building — so 'most recent building' is not a
+// derivable answer here." That was true the day it was written (BONGOS-V1 and
+// CB-V1). It is false now: one version builds. Nothing noticed, because the
+// reason is a claim about LIVE STATE and an allowlist holds prose, which no CI
+// step can re-check. The entry did not become wrong through anyone's error —
+// the world moved under it. Hence the rule now written beside the Map: a reason
+// may cite the CODE's shape, never the database's contents.
+//
+// SCANNING AN ALLOWLISTED PATH PROVES NOTHING. scanScripts applies the allowlist
+// itself (`if (VERSION_LITERAL_ALLOW.has(rel)) continue`), so handing it an
+// exempt path returns zero violations whatever the file says — the first draft
+// of this test read that vacuous [] as "no literal" and reported every entry as
+// dead, including grade-smoke.js, which plainly still carries two. The source is
+// therefore re-scanned under a synthetic path that is on neither the allowlist
+// nor isExempt's patterns, which is the only way to see what the guard WOULD say.
+const PROBE = 'scripts/gds/__allowlist_probe__.js';
+const scanUnexempt = (src) => g.scanScripts([PROBE], () => src);
+
+test('the probe path really is unexempt — otherwise every check below is vacuous', () => {
+  assert.ok(!g.VERSION_LITERAL_ALLOW.has(PROBE), 'probe must not be allowlisted');
+  assert.ok(!g.isExempt(PROBE), 'probe must not match an isExempt pattern');
+  // And it must actually fire on a known-bad line, or a silent-empty scanner
+  // would let every assertion below pass for the wrong reason (learning: a
+  // static scan breaks by finding nothing, and green looks identical to working).
+  assert.equal(scanUnexempt("  version_id: 'PMS-V1',").violations.length, 1);
+});
+
+test('no allowlist entry is DEAD — each exempt file still contains the shape it is exempt for', () => {
+  for (const [rel] of g.VERSION_LITERAL_ALLOW) {
+    let src = null;
+    try { src = read(...rel.split('/')); } catch { /* handled below */ }
+    assert.ok(src !== null, `${rel} is allowlisted but does not exist — drop the entry`);
+    assert.ok(
+      scanUnexempt(src).violations.length > 0,
+      `${rel} is on VERSION_LITERAL_ALLOW but no longer names a version literal — `
+      + 'the exemption is dead and must be removed, or it will silently cover a '
+      + 'literal someone reintroduces later.'
+    );
+  }
+});
+
+test('THE INCIDENT: status.js is no longer exempt, and names no version literal', () => {
+  // Both halves must hold. Dropping the entry while leaving the literal reds the
+  // guard; fixing the literal while leaving the entry leaves status.js covered by
+  // nothing for good. Scanned under the probe path so this stays honest even if
+  // someone re-adds the allowlist entry.
+  assert.ok(
+    !g.VERSION_LITERAL_ALLOW.has('scripts/gds/status.js'),
+    'status.js resolves its default at runtime now — it must not stay exempt'
+  );
+  assert.deepEqual(scanUnexempt(read('scripts', 'gds', 'status.js')).violations, []);
+});
+
+// ---- the fallback shape ASSIGNED could not see ----------------------------
+test('THE BLIND SPOT: a version field falling back to a literal through || is caught', () => {
+  // The literal line that shipped, verbatim. ASSIGNED misses it because its
+  // `[^,;)]*` stops at the `)` of resolveEnv(...) — so wrapping a literal in any
+  // call defeated the guard, while the bare assignment was caught.
+  const bad = "const DEFAULT_VERSION = resolveEnv('STATUS_DEFAULT_VERSION') || 'BONGOS-V1';";
+  assert.equal(g.ASSIGNED.test(bad), false, 'documents WHY a third pattern was needed');
+  assert.equal(g.FALLBACK.test(bad), true);
+  assert.equal(scanUnexempt(bad).violations.length, 1, 'and the scanner reports it');
+});
+
+test('the bare assignment ASSIGNED already caught still fails', () => {
+  assert.equal(scanUnexempt("const DEFAULT_VERSION = 'BONGOS-V1';").violations.length, 1);
+});
+
+test('FALLBACK stays narrow — it does not fire on a version field alone', () => {
+  // The over-broad source assertion this repo keeps relearning (learning 1000196).
+  // Loosening ASSIGNED to `[^;]*` would have flagged all of these.
+  for (const ok of [
+    "  const v = versions.find((x) => x.version_id === id) || null;",
+    "  if (!version_id) throw new Error('need a version');",
+    "  console.log(`resolved ${version_id}`);",
+    "  const label = version_id || 'unknown';",
+  ]) {
+    assert.deepEqual(scanUnexempt(ok).violations, [], `must not flag: ${ok.trim()}`);
+  }
+});
+
+test('a comment showing the old bad line does not re-trip the guard', () => {
+  // status.js now quotes its own former literal in the explanatory comment. If
+  // comment-stripping regressed, the file it documents would red the guard.
+  assert.deepEqual(
+    scanUnexempt("// const DEFAULT_VERSION = resolveEnv('X') || 'BONGOS-V1';").violations,
+    []
+  );
+});