@bongos/core 1.19.891 → 1.19.893

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.891",
-  "core_contract": "1.19.891",
-  "source_commit": "e306e6ce6ad80a4e9259cea5c81326a60ff5e7ab",
+  "core_version": "1.19.893",
+  "core_contract": "1.19.893",
+  "source_commit": "99f7250a5cc9e39e16d1869281d1fd2660a466ad",
   "source_ref": "HEAD",
-  "built_at": "2026-09-19T21:50:27.729Z",
+  "built_at": "2026-09-19T22:26:15.995Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 497,
+    "docs_redacted": 498,
     "agent_docs_stubbed": 26,
     "functional_verbatim": 2272,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2795,
-  "tree_sha256": "7d4974b5899a8d6ee86520b56479fb42f5256e4596ff21d29df8fd6925518fec",
+  "file_count": 2796,
+  "tree_sha256": "1ffd95b16bdf5a9986639f6ea5452817996a270f6274f1195d3330fc915fe900",
   "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": "d6bb312d40e0a4532550ea1faa19b5ae80e09a4dab01035513f8967aecb88f2e"
+      "sha256": "adada9ba37f56cd06bbb497540a86710002658b4160a9c0e31f5a3ae36fb1ddb"
     },
     {
       "path": "docs/modules-contract.md",
@@ -4372,7 +4377,7 @@
     {
       "path": "modules/government/protected-surfaces.json",
       "mode": "0000644",
-      "sha256": "aba8a8b1ce22708f5a7c05a64cbb4d1a08db295339a09df3c50a91f2735c1d47"
+      "sha256": "3c70a4abe22d8720a57da14e1f6dbc659cc57b066c1c811c8130f20d6d586e20"
     },
     {
       "path": "modules/government/ranks.js",
@@ -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": "17d7b0573d81b759182725bbb1be90a3bf1da889cdef0ef97510e3bb0e263932"
+      "sha256": "4439b27f55c654d0758f704b1225fb25509949f048e9292b5c54af9c047c59a2"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "90befa8ce40948a6ce667f2690343e2489b3ea33c08b4d6d1e2daee5227e9c9a"
+      "sha256": "3c2e6c91f071304b4464dfa845786eb5037631d1dff4cdad6c9560201dfc9bb6"
     },
     {
       "path": "public-docs/index.html",
@@ -9717,7 +9722,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "4dd8bdfcb69d7c1f7a1443175bea5379ed60daec5d19ec846a14732db59559fc"
+      "sha256": "f5e01142842ee5a6d8c2cb8870eb8bd41e9de63d4e3621a07a69fc2c095597c7"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -9892,7 +9897,7 @@
     {
       "path": "tests/agents_sync.mjs",
       "mode": "0000644",
-      "sha256": "f7f6d88fd31a2eb1a81678d883706d2716e6a2ae20159599d3dbe7ed4c267f2e"
+      "sha256": "2e161bf9ef98425974d8295c8227688cd6fde55314fb3b9413df55542d5a109a"
     },
     {
       "path": "tests/agents_validate.mjs",
@@ -11397,7 +11402,7 @@
     {
       "path": "tests/government_protected_surfaces.mjs",
       "mode": "0000644",
-      "sha256": "c3c72c3a2cf970222c80051787df7fd7d155b5abd2f80b797a6a58bf5e95e0eb"
+      "sha256": "fd0cca1a62b8c2ab3bd556aabf4f6949bb6affb66c2fb1fd6258bccfffebc744"
     },
     {
       "path": "tests/government_rank_sync.mjs",
@@ -12197,7 +12202,7 @@
     {
       "path": "tests/module-scope-map.mjs",
       "mode": "0000644",
-      "sha256": "e277e0579dd6c8fea459cc5a3b4adf04dda12c95e69a415eeea5cfd2de52d760"
+      "sha256": "d55b193ee9dcba85a9d51f108352de17f453dfb413b9b391028c9d8f7ff7fab0"
     },
     {
       "path": "tests/module_api.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

@@ -2256,5 +2256,9 @@ is load-bearing: the script throws rather than guess if it is missing, and
         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)
+  1.19.893 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.892 with no explicit bump. run 35473299957. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/modules/government/protected-surfaces.json

@@ -90,6 +90,11 @@
     { "glob": "CLAUDE.md", "group": "docs", "why": "the methodology core" },
     { "glob": ".claude/hooks/", "group": "automation", "why": "local automation that could weaken a gate" },
     { "glob": ".claude/settings.json", "group": "automation", "why": "local automation that could weaken a gate" },
-    { "glob": "config/scheduled-routines.json", "group": "automation", "why": "task 1002500. The ROUTINE SWITCHBOARD: per routine it decides enabled, cadence and requiresAutonomy — so an edit here can arm overnight-builder (autonomous claim+ship) or silence main-audit, the post-merge trust-boundary backstop ADR 0043 relies on. Sibling of .claude/hooks/ and .claude/settings.json above: the routine BODIES under .claude/scheduled-tasks/ are the autonomy module's source surface and stay unprotected, because protectedness derives per module and walling them is a separate policy decision (the .claude/agents/ precedent recorded in tests/government_protected_surfaces.mjs). This file is kernel-owned territory (module-scope-map's kernel key carries 'config/'), which is already protected, so registering it widens no module wall. The set is computed, not listed: the routine-switch tripwire in tests/government_protected_surfaces.mjs re-detects every config/*.json declaring routine switches and reds if one is unregistered." }
+    { "glob": "config/scheduled-routines.json", "group": "automation", "why": "task 1002500. The ROUTINE SWITCHBOARD: per routine it decides enabled, cadence and requiresAutonomy — so an edit here can arm overnight-builder (autonomous claim+ship) or silence main-audit, the post-merge trust-boundary backstop ADR 0043 relies on. Sibling of .claude/hooks/ and .claude/settings.json above: the routine BODIES under .claude/scheduled-tasks/ are the autonomy module's source surface and stay unprotected, because protectedness derives per module and walling them is a separate policy decision (the .claude/agents/ precedent recorded in tests/government_protected_surfaces.mjs). This file is kernel-owned territory (module-scope-map's kernel key carries 'config/'), which is already protected, so registering it widens no module wall. The set is computed, not listed: the routine-switch tripwire in tests/government_protected_surfaces.mjs re-detects every config/*.json declaring routine switches and reds if one is unregistered." },
+  {
+      "glob": "modules/agents/",
+      "group": "automation",
+      "why": "task 1004006, owner decision 2026-09-19. Who may EDIT the agents module. This is the policy decision the note at the head of tests/government_protected_surfaces.mjs reserved when task 1002492 backed out '.claude/agents/' — not a scope fix and not a side effect. The module fires subagents unattended and SPENDS REAL MONEY doing it (~$0.90 a fire, a per-agent monthly ceiling in agents_004, folded into the global MTD autonomy brake), so editing what may fire and what it may cost is Metic work. The 1002492 note's stated cost was that it walls goals 1000038/39/40; all three are ARCHIVED and re-derived on 2026-09-19 there are ZERO live goals scoped to agents. Of the nine live tasks in the module six already require Metic; the three that did not are the agent secret-file permission rule, the run-ledger column allowlist and the model-provider port — security and spend surfaces that ADR 0043 already keeps sub-Metic builders out of in spirit. Protectedness is DERIVED PER MODULE (module-scope-map isProtected -> touchesOverlap), so this one glob is what flips the whole module, which is the intent here rather than the accident it was in 1002492."
+  }
   ]
 }

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.891",
+  "version": "1.19.893",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.891",
+      "version": "1.19.893",
       "license": "AGPL-3.0-or-later",
       "dependencies": {
         "express": "^4.21.2",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.891",
+  "version": "1.19.893",
   "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/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.891'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.893'; // 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/agents_sync.mjs

@@ -328,7 +328,20 @@ t('the wall is wired to the REAL protected-surface registry', () => {
   assert.equal(realMatcher('modules/government/catalog.js'), true, 'the authority surface');
   assert.equal(realMatcher('migrations/001_init.sql'), true, 'schema');
   assert.equal(realMatcher('.claude/hooks/pre-push.js'), true, 'local automation');
-  assert.equal(realMatcher('modules/agents/lib/validate.js'), false, "a module's own code is not protected");
+  // A module's own code is not protected BY DEFAULT — the contrast case that
+  // proves this wall discriminates rather than blanketing everything.
+  //
+  // This used to cite modules/agents/lib/validate.js, which stopped being a
+  // valid example on 2026-09-19 when task 1004006 walled the agents module at
+  // Metic on the owner's decision. The case still needs an unprotected module
+  // file; modules/ideas/ is one, and the assertion below re-states WHY it is the
+  // example rather than leaving the next reader to rediscover that the old one
+  // turned. (A fixture chosen because it is negative can become positive, and
+  // the test then looks untouched by the change that broke it.)
+  assert.equal(realMatcher('modules/ideas/routing.js'), false, "a module's own code is not protected by default");
+  assert.equal(realMatcher('modules/agents/lib/validate.js'), true,
+    'the agents module IS protected since task 1004006 — deliberately, and it is '
+    + 'no longer usable as the unprotected example above');
   // `.claude/agents/` itself is deliberately NOT in the registry — see the note
   // on ADDED_SINCE_R101 in tests/government_protected_surfaces.mjs. Protecting
   // it would rank-wall the whole agents module by derivation, which is a
@@ -358,8 +371,10 @@ t('a path scope onto the authority surface is withheld a rank AND flagged', () =
 t('an unprotected path scope still reconciles normally', () => {
   // The wall is a floor, not a ban — a tightening that refused every path scope
   // would pass the test above and break the feature.
+  // modules/ideas/ rather than modules/agents/lib/ — the latter became a
+  // PROTECTED path in task 1004006, so it can no longer stand for "unprotected".
   const d = sync.parseAgentFile(
-    '---\nname: reader\ntrigger: on-demand\nscope_paths: [modules/agents/lib/]\n---\nbody', {});
+    '---\nname: reader\ntrigger: on-demand\nscope_paths: [modules/ideas/]\n---\nbody', {});
   assert.equal(sync.declaresProtectedScope(d, [], realMatcher), false);
   const p = sync.planOne(d, {
     authorRank: 'metic', allowedModules: ['agents'], isProtectedPath: realMatcher,

package/tests/government_protected_surfaces.mjs

@@ -240,6 +240,29 @@ const ADDED_SINCE_R101 = [
        + 'edit which slipped past the pre-push hook and the grader — the one ADR 0043 '
        + 'layer that does not depend on the builder cooperating.',
   },
+  // task 1004006, owner decision 2026-09-19. THE POLICY DECISION the note at the head of
+  // this file reserved when task 1002492 backed out `.claude/agents/`: who may EDIT the
+  // agents module. Landed deliberately, as that note required — the entry here, the
+  // publish-manifest check (already satisfied: modules/agents/ is on PUBLISH_ALLOWLIST,
+  // verified rather than assumed), and the switchboard tripwire below re-aimed rather
+  // than deleted.
+  //
+  // The note's stated cost was that it walls goals 1000038/39/40. All three are ARCHIVED,
+  // and re-derived on 2026-09-19 there are ZERO live goals scoped to agents — so that
+  // specific cost is gone, which is exactly why the note said to re-derive rather than
+  // trust it. What replaced it: the module now spends real money unattended (~$0.90 a
+  // fire, per-agent monthly ceiling in agents_004, folded into the global MTD brake).
+  {
+    after: 'config/scheduled-routines.json',
+    glob: 'modules/agents/',
+    why: 'the module that fires subagents unattended and SPENDS to do it. Editing what '
+       + 'may fire, and what it may cost, is Metic work. Of the nine live tasks in the '
+       + 'module six already required Metic; the three that did not are the agent '
+       + 'secret-file permission rule, the run-ledger column allowlist and the '
+       + 'model-provider port — security and spend surfaces ADR 0043 already keeps '
+       + 'sub-Metic builders out of in spirit, so the real cost of this entry is three '
+       + 'tasks that arguably should not have been open.',
+  },
 ];
 
 // Surfaces RENAMED since R101 — still protected, under a new path. Distinct from
@@ -731,11 +754,34 @@ test('registering the switchboard widened no module wall', () => {
   assert.ok(protectedNow.includes('kernel'),
     'kernel owns config/ and was already protected before this entry; if it is not, the '
     + 'premise that registering a config/ file widens nothing has changed.');
-  assert.ok(!protectedNow.includes('agents'),
-    'the agents module derived protected:true — a routine entry reached modules/agents/ '
-    + 'or .claude/agents/, which rank-walls every goal scoped to it. Protect the '
-    + 'SWITCHBOARD, not the agent or routine sources; walling that module is the separate '
-    + 'policy decision recorded for .claude/agents/ at the head of this file.');
+  // task 1004006 RE-AIMED THIS, and did not delete it. The assertion used to be
+  // `!includes('agents')`, and its job was never "agents must stay open" — it was "the
+  // SWITCHBOARD entry must not have reached the agents module as a side effect". That job
+  // still exists; agents is now protected for its OWN declared reason (the owner's
+  // 2026-09-19 decision), which is the separate policy act the old message pointed at.
+  //
+  // So the check becomes: agents is protected, and it is protected BY ITS OWN GLOB. If
+  // the switchboard entry — or any future config/ entry — were what reached the module,
+  // surfaceFor would name that file instead, and this still fails.
+  assert.ok(protectedNow.includes('agents'),
+    'the agents module is no longer protected — task 1004006 registered modules/agents/ '
+    + 'on the owner\'s decision (the module fires subagents unattended and spends to do '
+    + 'it). If the entry was removed, that is a policy reversal and belongs in the note '
+    + 'at the head of this file, not a silent deletion.');
+  const agentsSurface = ppc.surfaceFor('modules/agents/lib/validate.js');
+  assert.equal(agentsSurface && agentsSurface.glob, 'modules/agents/',
+    'the agents module is protected by SOMETHING OTHER than its own glob — a config/ or '
+    + 'switchboard entry has widened into it, which is the second-order effect this test '
+    + 'exists to catch. The deliberate entry and an accidental one look identical in '
+    + 'protectedModules(); only the matching glob tells them apart.');
+  // 1002492's rejection still stands: the module SOURCE is walled, agent DEFINITION files
+  // are not. Walling those was a scope fix that the scope_paths wall in
+  // modules/agents/lib/validate.js already does properly, and it is not what 1004006
+  // decided.
+  assert.ok(!ppc.surfaceFor('.claude/agents/historian.md'),
+    '.claude/agents/ became protected — task 1002492 considered and rejected that, and '
+    + 'task 1004006 walled the module SOURCE without reopening it. An agent definition '
+    + 'is scoped by validate.js, not by a rank floor on the file.');
   assert.ok(ppc.surfaceFor('scripts/gds/conductor-dispatch.js'),
     'the autonomy module was protected through conductor-dispatch.js before this entry. '
     + 'If that glob is gone, re-derive which modules this registry walls before trusting '

package/tests/module-scope-map.mjs

@@ -145,8 +145,16 @@ test('agents joined the roster (task 1002736) — the territory goals 1000038/39
   const globs = scope.globsForModules(['agents']);
   assert.ok(globs.includes('modules/agents/'), 'agents owns its module directory');
   assert.ok(globs.includes('.claude/agents/'), 'the committed definitions are the module source surface');
-  // Derived, not hand-set: none of the agents globs appear in PROTECTED_GLOBS.
-  assert.equal(scope.isProtectedModule('agents'), false);
+  // Derived, not hand-set. This flipped to TRUE in task 1004006, when the owner
+  // walled the module at Metic (2026-09-19): modules/agents/ is now a registered
+  // protected surface because the module fires subagents unattended and spends
+  // real money doing it. The assertion below is the point of this pair and is
+  // UNCHANGED — `protected` must still be the faithful derivation rather than a
+  // literal, which is what would break if someone hand-set the flag to match.
+  assert.equal(scope.isProtectedModule('agents'), true,
+    'the agents module lost its Metic floor — task 1004006 registered modules/agents/ '
+    + 'on the owner\'s decision. A reversal is a policy act and belongs in the note at '
+    + 'the head of tests/government_protected_surfaces.mjs.');
   assert.equal(
     scope.scopeForModule('agents').protected,
     scope.isProtected(globs),