@bongos/core 1.19.891 → 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.891",
-  "core_contract": "1.19.891",
-  "source_commit": "e306e6ce6ad80a4e9259cea5c81326a60ff5e7ab",
+  "core_version": "1.19.892",
+  "core_contract": "1.19.892",
+  "source_commit": "10a12417f89994d74e98a3d69ffb32e6c923fcc1",
   "source_ref": "HEAD",
-  "built_at": "2026-09-19T21:50:27.729Z",
+  "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": 2272,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2795,
-  "tree_sha256": "7d4974b5899a8d6ee86520b56479fb42f5256e4596ff21d29df8fd6925518fec",
+  "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": "d6bb312d40e0a4532550ea1faa19b5ae80e09a4dab01035513f8967aecb88f2e"
+      "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": "17d7b0573d81b759182725bbb1be90a3bf1da889cdef0ef97510e3bb0e263932"
+      "sha256": "3ef1a7c4eafee4e9e92df1e0c1389acf252ff0d0f32689718cf81ee4c46ec04b"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "90befa8ce40948a6ce667f2690343e2489b3ea33c08b4d6d1e2daee5227e9c9a"
+      "sha256": "52b00c86bbde5eb29b9637f15988898313b2e5318ba50d83c30fff24a699021d"
     },
     {
       "path": "public-docs/index.html",
@@ -9717,7 +9722,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "4dd8bdfcb69d7c1f7a1443175bea5379ed60daec5d19ec846a14732db59559fc"
+      "sha256": "c0c018df9a35a17f31c17c566ded5bb5878c5c1189f62cd20ad1ea3e3e43d612"
     },
     {
       "path": "src/module-loader/catalog.js",

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,7 @@ 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)
 ---------------------------------------------------------------------------
 ```

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.892",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.891",
+      "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.891",
+  "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/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.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');