@bongos/core 1.19.321 → 1.19.322

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.321",
-  "core_contract": "1.19.321",
-  "source_commit": "242735e2b39608c5500b8c5bd231832a90c5fae7",
+  "core_version": "1.19.322",
+  "core_contract": "1.19.322",
+  "source_commit": "2fd56f3db9adacbb215ffdc56bba734266ef8e89",
   "source_ref": "HEAD",
-  "built_at": "2026-08-24T01:17:55.486Z",
+  "built_at": "2026-08-24T01:23:28.434Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 323,
+    "docs_redacted": 324,
     "agent_docs_stubbed": 22,
     "functional_verbatim": 1455,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 1800,
-  "tree_sha256": "5d80f6db5c26850188eb0c3f5ace7c42ff85561d277dc525e24f46cdcf52dee8",
+  "file_count": 1801,
+  "tree_sha256": "6cd259fb90abf1a7df74cc5e7dffead0cfa9c5d0f636032c51b94e715d21b31d",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -1409,10 +1409,15 @@
       "mode": "0000644",
       "sha256": "51931fe5ae89b14b6c8955e6d6cd43d88a7a6ed05f8c862cdfe56a14302cc990"
     },
+    {
+      "path": "docs/adr/0186-per-project-idea-templates.md",
+      "mode": "0000644",
+      "sha256": "749040f16b59cc1cd1c49ca40453fed838f31b36af8c8eed2b5de7db00ddb0d0"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "96f12718ea595a8fff3d3aeafc27013b4ef251724e80d077607addc167533639"
+      "sha256": "c5af7723dbcc0e4a62a897153b1fa1cf34962a1f8ed72fc7bf9681ba074dab6a"
     },
     {
       "path": "docs/api-reference.md",
@@ -4642,12 +4647,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "6f62185348f89cc7ae1c8998a25d4bdccb2e204ad81581555686f37057db1511"
+      "sha256": "c9390686abc47c1954f212e7e4ebbce0320cfd21d9acc1fd2fe79d4f9667ab79"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "3ba87e851af1bf1ad2a08cb62d4c875be12d7ec6d86ffda9e5b26e24fee313ae"
+      "sha256": "290a425b20d5c5f87bc9a1eaeb154d02f8ca95e8147dd7a6f5835ea443d25ec4"
     },
     {
       "path": "public-docs/index.html",
@@ -6417,7 +6422,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "31c5e453080859713ed00c327a6b1fb1a022d2509438523979bad2e0e8feb7bf"
+      "sha256": "d808c8f826309876d6ce3bf99e47ca874b5afa0efe108fcbda629328c45d9b00"
     },
     {
       "path": "src/module-loader/catalog.js",

package/docs/adr/0186-per-project-idea-templates.md

@@ -0,0 +1,146 @@
+# 0186 — Per-project idea templates: the seam is already built; the economics are the open problem
+
+- **Status:** Accepted (spike outcome — decisions below; no implementation in this task)
+- **Date:** 2026-08-23
+- **Tasks:** [#1002932](https://cloudbongos.com/builders#/task/1002932) (BV1.R156, goal 1000062 — three grades of idea). Spike output: this ADR plus the downstream task list in §7. Gates criterion `abi-full-idea-base-template`.
+- **Builds on:** [ADR 0172](<redacted>.md) (the ideator credit lane), [ADR 0185](<redacted>.md) (the 70/30 split), [ADR 0083](<redacted>.md) (module boundary + module-owned migrations)
+- **Related:** R141 (`modules/ideas/templates.js` — the template declaration), R142 (`modules/ideas/completeness.js` — the deterministic scorer)
+
+## 1. Context
+
+The owner's philosophy for this platform, recorded on goal 1000062: **the best
+possible simple base, already designed to be altered.** R141 shipped `base-v1` —
+five fields, declared as data — and R142 shipped a scorer that walks that
+declaration rather than hard-coding five names. This spike asks the question those
+two deliberately deferred: *how does a project founder define their own idea
+shape — different fields, different weights — without a schema change and without
+forking the scorer?*
+
+## 2. The finding that matters: the seam is already there
+
+The answer to the literal question is short, because R141 built for it:
+
+- **Every template function already takes an optional `registry`**
+  (`templateFor`, `validateFieldValues`, `fieldOrder`, `scoreFieldValues`),
+  defaulting to `BUILTIN_TEMPLATES`. Validation and scoring both read the
+  declaration as data. Swapping the registry changes what both accept with no
+  code change in either consumer, and `tests/idea_templates.mjs` already proves
+  it by injecting a different registry.
+- **The store is already project-ready.** `ideas_grades.template_key` is per-row
+  with `CHECK (template_key ~ '^[a-z][a-z0-9-]*$' AND length <= 64)` — its own
+  migration comment says a project-defined key "stays addressable".
+- **A per-project settings home already exists**: `provisioning_instances.settings
+  jsonb NOT NULL DEFAULT '{}'` (provisioning_009).
+
+So: **no schema change is required, and the scorer does not need forking.** That
+part of the task's question is answered by work already shipped. What the spike
+actually found is a different problem, in §4.
+
+## 3. Decision A — where a project template comes from
+
+A new **`project-settings` kernel port**, the sibling of the existing
+`builder-settings` port, reading `provisioning_instances.settings` under a
+namespaced key (`settings.ideas.templates`).
+
+- The `ideas` module resolves it with `resolveOptional`, so a vanilla instance
+  with no `provisioning` module **degrades to the built-in registry** rather than
+  failing — the same graceful posture `lifecycle` takes toward `reward` and
+  `onboarding` (ADR 0093 §2).
+- `base-v1` remains the default and the **fallback for any row whose
+  `template_key` does not resolve**. An unresolvable key already renders raw
+  rather than throwing (`templateFor` returns null by design, after the R143
+  prototype-pollution fix); that behaviour is kept.
+
+**Rejected:** a new `ideas_templates` table (a second home for a thing that
+already has one, and a module-owned table for data the project owner edits in
+project settings); a config file (`config/idea-templates.json` is per-*instance*,
+and one instance hosts many projects — wrong granularity).
+
+**Boundary note, load-bearing for whoever implements it:** goal 1000062's
+`scope_modules` is `['ideas','hall-ui']`. The port lives in `provisioning` +
+kernel, which is **outside this goal's scope wall**. The port task therefore
+cannot be claimed under goal 1000062 — see §7 T1.
+
+## 4. Decision B — the economic lever (the real finding)
+
+Completeness is normalised **0–100 within its own template**: the scorer takes the
+mean of per-field ratios and multiplies by 100. Karma reads that relative number
+against an absolute bar — `IDEA_FULL_PASS_BAR = 60`, `IDEA_FULL_PASS_CREDIT = 5`.
+
+Those two facts together mean **template choice becomes a credit-minting lever**:
+
+| Template | Required text for a passing score | Credits |
+|---|---|---|
+| `base-v1` (5 fields × substanceMin 40) | ~200 characters of real content | 5 |
+| a project template: 1 field, substanceMin 10 | ~10 characters | 5 |
+
+A ~20× arbitrage, available to any project that can define its own shape — and
+per-project templates are exactly what this ADR enables. Shipping Decision A
+without addressing this would make the feature a way to print credits.
+
+**Decision:** separate the two questions the single number is currently answering.
+
+- **Completeness stays relative** and keeps its present meaning: *did you fill in
+  YOUR project's form.* That is the right signal for triage ordering (R148) and
+  the hall's live meter (R152), and it must stay comparable within a project.
+- **Karma stops reading it.** Credit eligibility reads an **absolute substance
+  total** instead — which the scorer already computes per field (`fields[].substance`)
+  and currently discards after averaging. No new measurement is needed; the number
+  is there.
+
+**Rejected:** making completeness itself absolute (it would break the meter and
+the ordering, which want "how complete is this form"); leaving karma relative and
+policing templates by review (unenforceable, and the platform should not depend on
+someone noticing).
+
+**Interim guard**, cheap and shippable before the karma change: a project template
+is karma-eligible only if it declares **≥3 required fields and ≥120 total
+`substanceMin`**. This does not fix the arbitrage, it bounds it — and it is worth
+having on day one because it is a data check, not an economics change.
+
+## 5. Decision C — per-field weights
+
+The task asks for "different fields, different weights". Today the scorer is an
+**unweighted** mean (`fields.reduce((s,f) => s + f.ratio, 0) / fields.length`).
+
+**Decision:** an optional `weight` on the field declaration, default `1`, and a
+weighted mean in the scorer. Today's behaviour is the special case where every
+weight is 1, so this is a pure data addition with one arithmetic line changed and
+no migration. Weights are declared alongside `substanceMin`, which keeps the whole
+shape of a template in one declaration.
+
+## 6. Decision D — do the five base fields stay mandatory?
+
+**No.** A project may define any shape; forcing the five would make "define your
+own" cosmetic, and the base fields are the owner's wording for *this* project's
+concerns, not universal truths.
+
+Two constraints stand in their place:
+
+1. **A template must declare at least one required field.** A template with none
+   makes completeness vacuous (an empty submission scores 100).
+2. **A stored template is validated at write time**, so a malformed registry is
+   refused when the project saves it — not discovered later inside the capture
+   path, which must never throw (R142's hard requirement).
+
+## 7. Downstream tasks (the spike's other output)
+
+| # | Task | Scope / goal note |
+|---|---|---|
+| T1 | `project-settings` kernel port, sibling of `builder-settings`, reading `provisioning_instances.settings` | `provisioning` + kernel — **outside goal 1000062's wall**; needs a goal whose scope covers it |
+| T2 | `ideas` resolves that port and merges the project registry over the built-in; `resolveOptional`, degrading to built-in | `ideas` — in this goal's wall |
+| T3 | Optional per-field `weight` (default 1) + weighted mean in the scorer | `ideas` |
+| T4 | Karma eligibility reads an absolute substance total, not the relative completeness score | `economy` — outside this goal's wall |
+| T5 | Interim guard: a project template is karma-eligible only at ≥3 required fields and ≥120 total `substanceMin` | `ideas` |
+| T6 | Write-time validation of a stored project template | `ideas` (+ wherever project settings are saved) |
+
+T1 → T2 is the ordering dependency; T3, T5, T6 are independent. **T4 is the one
+that must not be skipped** — T5 bounds the arbitrage, only T4 removes it.
+
+## 8. What this ADR deliberately does not do
+
+No customization UI, per the task's own instruction ("Do not build the
+customization UI from this task"). No implementation of any row above. The spike's
+deliverable is this decision record plus §7, and the reason the platform builds
+the seam before the surface is ADR 0062 §7's core↔host split: the core ships the
+mechanism, the host supplies the content.

package/docs/adr/README.md

@@ -259,5 +259,6 @@ This keeps the decision history honest and traceable.
 | 0183 | [**A done-when criterion closes itself; the review queue becomes a place to look** ([task 1002069](https://cloudbongos.com/builders#/task/1002069), goal 1000072, owner request 2026-07-05). ADR 0086 §6 made `satisfied` reachable exactly one way — a Metic+ calling `POST /done-when/:id/satisfy` — even though the signal it gated on is unambiguous (**every** gating task shipped) and a human confirming it adds no information. When nobody runs `/goal-review` the result is not a careful pause but a **lying board**: this session measured goal 1000072 at `6/9 shipped, 0/5 criteria`. Now one helper, `doneWhen.autoSatisfyShippedCriteria(exec, {taskId})`, runs from **two** places for two different reasons — inside `shipTask`'s txn (scoped, **immediate**, on the txn client so a rolled-back ship cannot leave a goal achieved) and unscoped on every `publish-reconciler` tick (**backlog drain** for criteria whose tasks shipped before this existed, since nothing will ship against them again, plus **self-heal**). Idempotent by construction — it reads only `satisfied=false` rows — which is what makes an every-tick sweep safe. **The load-bearing subtlety is the delivery guard.** Auto-close needs BOTH "nothing still pending" AND **≥ 1 task actually `shipped`**; the second is not redundant, because since [task 1002651](https://cloudbongos.com/builders#/task/1002651) made `abandoned` terminal-not-pending, a criterion whose tasks were **all cut** satisfies the first clause *vacuously* and would auto-close on ZERO delivered work, cascading its goal to `achieved` (measured: `buildCriterionProgress` returns `pending_review:true` for exactly that shape). Yet `pending_review` **keeps** that wider meaning on purpose — it asks "should a human LOOK at this", and 1002651 chose that an all-abandoned criterion surfaces so someone decides whether it still means anything. So: everything that auto-closes was flagged; not everything flagged auto-closes. An earlier draft "aligned" the two predicates and broke that intent — `tests/criterion_progress.mjs` caught it; **do not re-align them**, the gap is the design. `/goal-review` is kept, demoted from gate to viewing surface; manual `POST /satisfy` stays for what automation cannot judge (a criterion with no linked tasks never auto-closes). Honest limits recorded: auto-satisfy cannot help a criterion nothing is LINKED to, and the in-txn close logs before commit (accepted — threading the summary out through `withTx` would cost ~5 lines in the over-threshold `db.js` under shrink-only ratchet policy). Rejected: sweep-only (up to 5 min to see your own goal close), hook-only (never drains the backlog), a stored `pending_review` column (second source of truth), deleting `/goal-review`.](<redacted>.md) | lifecycle / goal tier |
 | 0184 | [**A ship must account for itself: `shipTask` requires a land proof or a declared no-artifact** ([task 1002483](https://cloudbongos.com/builders#/task/1002483), goal 1000024). `db.shipTask` is the confirmed→shipped flip and, since [ADR 0120](<redacted>.md), where the CREDIT is booked — yet its only precondition was `WHERE status = 'confirmed'`, nothing about whether code reached main. The two AUTOMATED paths each proved the land first; the MANUAL route passed nothing, so a task confirmed with no pushed code could be shipped by its claim holder **or by any Metic+ sweeping `/merge-mode`**, booking its `task.shipped` credit. It stayed untracked for two months because its tracking task was closed in June asserting task 1001547 had delivered the gate — it had not, blocker 1000047's own final update says so, and the code agreed with the blocker rather than the closure note: **a hole hidden by a record nobody checked**, which is the same failure the gate is about. Decision: the gate lives at the WRITE, not the route (a route gate leaves the invariant unenforced at the layer that moves the ledger, so the next caller reopens it silently), and `shipTask` is FAIL-CLOSED on a required `landAssurance`. TWO kinds, and the second is why this does not make things worse: `proof` (this task's commit is on main) and **`no_artifact`** — a deliberate DB-only ship, an explicitly supported shape (CLAUDE.md "Direct DB writes are work too") that [task 1002478](https://cloudbongos.com/builders#/task/1002478) documents as a dead end below Archon. A naive proof-only gate would have made 1002478 strictly worse; naming no-artifact as a KIND turns it from an absence the gate must be talked out of into a recorded answer. Both carry a reason, audited post-commit and best-effort (an audit miss must never roll back a landed ship). `ship.js` now declares its own `--db-only`/`--allow-empty` lands, without which this fix would have regressed the very flow CLAUDE.md calls supported. Rejected: (b) gate only the route — leaves the write unguarded; (c) record the residual as tolerable — defensible on blast radius and genuinely close, but it would have been the FOURTH record asserting this was handled with nothing checkable behind it. Does NOT gate confirm: a codeless confirm is still accepted, it simply cannot reach `shipped` or pay.](<redacted>.md) | lifecycle / integrity |
 | 0185 | [**The spark-handoff credit split: 70% developer, 30% spark author** ([task 1002923](https://cloudbongos.com/builders#/task/1002923), BV1.R147, goal 1000062 — completing the chain [task 1002920](https://cloudbongos.com/builders#/task/1002920) mark → [task 1002921](https://cloudbongos.com/builders#/task/1002921) queue → [task 1002922](https://cloudbongos.com/builders#/task/1002922) pickup). [ADR 0172](<redacted>.md) built the ideator streams and paid `captured_by`, the only person an idea then had. The spark handoff created a second: R146 develops a spark IN PLACE, preserving the author while recording a `developed_by`. **R146 therefore shipped paying NOTHING on purpose** — not an oversight but a refusal to guess, because `awardIdeaFullPassCredit`'s idempotency predicate is `(builder_id, reason)`, so paying the DEVELOPER would not have blocked a later payment to the AUTHOR and one idea would have paid twice; the cost of that caution was that a developed Full Idea received stream 2 **never** unless its author resubmitted. Owner decision (2026-08-22): **70/30 favouring the developer**, on BOTH existing streams, one ratio so there is one rule to explain. The reasoning is behavioural, not sentimental — developing someone else's spark is the scarce act the queue depends on, and at an even split it pays HALF what authoring your own Full Idea pays for the same writing work, so the rational move is always to write your own and the R145 queue stays a list nobody reads. The author keeps 30% plus their share of stream 1 on every task shipped under the idea, forever. `IDEA_DEVELOPER_SHARE = 0.70` is a **policy constant in `credits.js`** beside the pass bar and quick factor (ADR 0172's own consequence, the ADR 0023 precedent): a share of someone's earnings deserves a review and a commit, not a runtime edit. **The structural half is what retires R146's caution:** the economy module now derives the payees itself (`ideaCreditParties` reads `captured_by` + `developed_by`), so the caller can no longer choose a recipient — the develop route hands over an idea and a score, never a payee, and books the split like any other path (fail-open; the development has already committed). Three arithmetic properties, each a real bug if missed: the total is **conserved** (developer rounded, author gets the REMAINDER — rounding both pays 6 out of a 5-credit payout); a **self-developed** idea collapses to ONE payee, because two rows for one builder would silently UNDER-pay under the per-builder idempotency predicate, not double-pay (the comparison normalises via `String()` since `bigint` arrives as a string, so a type mismatch cannot become a phantom payee); and **zero-value rows are dropped**. Ids otherwise pass through unconverted — `Number()`-ing a `bigint` risks precision. `builder_id` in the idempotency predicate, which entered as an index optimisation (the R143/IC2 grader finding), is now **load-bearing for correctness**: two payees share one `reason`, so a reason-only predicate would refuse the second, and a partially-booked split completes on the next call. **Not decided here:** stream 3's split (ships with the Board Room, task 1002999), and whether `origin='develop'` in `ideas_task_lineage` belongs to whoever promotes a DEVELOPED idea into a task — ADR 0172 §5 says the row is "set at promotion and at develop (R146)", but R146 creates no task, so that origin stays deliberately unwired rather than invented; it changes who stream 1 pays.](<redacted>.md) | economy / ideator lane |
+| 0186 | [**Per-project idea templates: the seam is already built; the economics are the open problem** ([task 1002932](https://cloudbongos.com/builders#/task/1002932), BV1.R156, goal 1000062 — a SPIKE, output is this ADR plus a task list, no implementation). The literal question — how does a founder define their own idea shape without a schema change or forking the scorer — is **already answered by shipped work**: R141 gave every template function an optional `registry` defaulting to the built-in one, so validation and scoring both read the declaration as data; `ideas_grades.template_key` is per-row with a format CHECK whose own comment says a project key "stays addressable"; and `provisioning_instances.settings jsonb` is an existing per-project home. **No schema change, no fork.** Decision A: a **`project-settings` kernel port**, sibling of `builder-settings`, read via `resolveOptional` so a vanilla instance with no provisioning module degrades to the built-in registry; `base-v1` stays the default and the fallback for an unresolvable key. Rejected a new `ideas_templates` table (second home for data that has one) and a config file (per-instance, but one instance hosts many projects). **Decision B is the finding that matters.** Completeness is normalised 0–100 WITHIN its template (mean of per-field ratios), while karma reads it against an absolute bar (`IDEA_FULL_PASS_BAR = 60`, `IDEA_FULL_PASS_CREDIT = 5`) — so template choice becomes a credit-minting lever: `base-v1` needs ~200 characters for 5 credits, a 1-field template with `substanceMin` 10 needs ~10, a ~20× arbitrage handed to exactly the projects this ADR empowers. Shipping A without B would make the feature a way to print credits. The fix separates the two questions one number is answering: **completeness stays relative** (it is the right signal for triage ordering and the hall meter) and **karma stops reading it**, switching to an absolute substance total the scorer already computes per field and currently discards after averaging. An interim guard (≥3 required fields, ≥120 total `substanceMin`) bounds the arbitrage without fixing it. Decision C: an optional per-field `weight` (default 1) turning the unweighted mean into a weighted one — today's behaviour is the all-weights-1 case, so it is a data addition and one arithmetic line. Decision D: the five base fields are **not** mandatory (forcing them would make "define your own" cosmetic), replaced by two constraints — a template must declare ≥1 required field, and a stored template is validated at WRITE time so a malformed one is refused there rather than discovered inside the capture path, which must never throw. **Boundary note:** goal 1000062's wall is `[ideas, hall-ui]`, so the port task (provisioning + kernel) and the karma task (economy) cannot be claimed under it.](<redacted>.md) | ideas / templates |
 
 > ⚠️ **Numbering collision (known):** two ADRs share `0008`. The numbers were assigned in parallel sessions before the lock could be enforced. The files are kept under their existing filenames to preserve git history, but the table disambiguates them as `0008-a` / `0008-b`. New ADRs should resume at `0040` to avoid further collisions. (`0024` is also a real on-disk duplicate: the cloneable-repo/local-first-memory ADR and the multi-agent-system-architecture ADR were both numbered `0024` in parallel; both keep their filenames, disambiguated as `0024-a` / `0024-b` like `0008`. Likewise `0025` ended up with two on-disk files — the offsite-backup ADR and the structured-criterion↔task-link ADR — both kept under their existing filenames and disambiguated as `0025-a` / `0025-b`; separately, the BFG ADR had also claimed `0025` on 2026-05-30 and yielded to `0026`. A third happened 2026-06-06: `0036` was claimed in parallel by the builders-subdomain ADR ([#726](https://example.com/builders#/task/726)) and this Discord-channels ADR ([#727](https://example.com/builders#/task/727)); the Discord-channels ADR yielded to `0037`. A fourth landed 2026-06-10: `0044` was claimed in parallel by the palette-replacement ADR and the per-box game-preview ADR ([#897](https://example.com/builders#/task/897)); both keep their filenames, disambiguated as `0044-a` / `0044-b` like `0008`. A fifth was caught pre-land 2026-06-13: `0050` was claimed in parallel by the device-flow-admission ADR ([#1000](https://example.com/builders#/task/1000)) and the sandbox-for-everyone ADR ([#1001](https://example.com/builders#/task/1001)); the latter yielded to `0052` before merging, so there is no `0050` duplicate. A sixth was caught pre-land 2026-06-21: the tool-agnostic-design-layer ADR ([#1375](https://example.com/builders#/task/1375)) first collided at `0079` with the value-gated-autonomous-engagement ADR, then at `0080` with the llm-cache-api-transport ADR (both part of the 0075–0080 LLM-cost-reduction series, landed on `main` in parallel); it yielded to `0081` before merging, so there is no `0079`/`0080` design-layer duplicate. A seventh landed 2026-06-23: `0084` was claimed in parallel by the auto-derived-per-task-rank-floor ADR and the remove-default-spend-cap ADR (task 1499); the rank-floor ADR landed on `main` first, so the spend-cap ADR yielded to `0085`, leaving no `0084` duplicate. An eighth landed 2026-06-27: `0095` was claimed in parallel by the borrowed-memory-and-retrieval-concepts ADR (PR #459, landed first) and the cross-agent-context-management ADR ([#1651](https://example.com/builders#/task/1651), PR #460); both keep their filenames, disambiguated as `0095-a` / `0095-b` like `0008`. These two are companions — `0095-a` adopts the memory/retrieval concepts and explicitly defers the grep-vs-semantic question to `0095-b`.)

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.321",
+  "version": "1.19.322",
   "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

@@ -1069,8 +1069,10 @@ const { validateOrRespond, LIMITS, parseId, asyncHandler, corsPublicGet, parsePa
 //         landed since 1.19.319 with no explicit bump. run 32678147546. (task 1002620)
 //   1.19.321 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
 //         landed since 1.19.320 with no explicit bump. run 32679324013. (task 1002620)
+//   1.19.322 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+//         landed since 1.19.321 with no explicit bump. run 32679604360. (task 1002620)
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.321'; // CI auto-patch carrier (ADR 0161); see changelog above
+const CORE_VERSION = '1.19.322'; // CI auto-patch carrier (ADR 0161); see changelog above
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');