@bongos/core 1.19.241 → 1.19.243

package/.bongos-core.json

@@ -2,11 +2,11 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.241",
-  "core_contract": "1.19.241",
-  "source_commit": "3be9d3e72426f99e05a9842dcb5cc9c85cfc75a0",
+  "core_version": "1.19.243",
+  "core_contract": "1.19.243",
+  "source_commit": "ac9bed6cf6412a5916b8b5f1c6c946f3c733cc96",
   "source_ref": "HEAD",
-  "built_at": "2026-08-18T20:51:17.253Z",
+  "built_at": "2026-08-18T22:39:28.983Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
     "docs_redacted": 312,
@@ -17,7 +17,7 @@
     "gate": "passed"
   },
   "file_count": 1660,
-  "tree_sha256": "d8e9cb0898ebdea8fca5a8bc8e94fd925e4725473943002abf4cbbc68e4ae963",
+  "tree_sha256": "28e71bece4c2803c63b8674af865cb7cfc74626f6e768d40e3742116571bb7d4",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -1367,7 +1367,7 @@
     {
       "path": "docs/adr/0177-goal-membership-kind.md",
       "mode": "0000644",
-      "sha256": "1bc4a0df32f8267b5fb3b274974fbcd15d680a161de4c502334dff62da494b17"
+      "sha256": "922dc12e699d3631907292e0a5550806ac88a160394c65c8223f65e58a46bc6f"
     },
     {
       "path": "docs/adr/README.md",
@@ -2377,7 +2377,7 @@
     {
       "path": "migrations/core_220_goal_members_membership_kind.sql",
       "mode": "0000644",
-      "sha256": "e466f4222fdbfa04386003990efabe38f97f3b3c23ff174a622642daea5c096b"
+      "sha256": "e0503f677b4b30eca07badd76ba9b177f603f3740da366c1be40cb67a5537690"
     },
     {
       "path": "modules/autonomy/CLAUDE.md",
@@ -4347,12 +4347,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "8f961bb896bdf312ad73752daa2342ce9ccf7db02b21ac9d2480694db28857d8"
+      "sha256": "c3f2be5aa7bbd5f5f40977d42f12485c3049df0ac811531d20bf3e7af51aed18"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "ac7bd7958b32f4eee03a29fab16260eb489d49c0e40907691bdd9c3e447d6a5d"
+      "sha256": "c0b9cdaf8ef1290a7c61fc7068390a6a14b9477a0b84c17e9018c4ab832e4d7c"
     },
     {
       "path": "public-docs/index.html",
@@ -5772,7 +5772,7 @@
     {
       "path": "src/bongos/llm-pricing.js",
       "mode": "0000644",
-      "sha256": "f7688e75a873f9c287f6559311877081830798cb1b5f1e548ceff3fcbed9e31d"
+      "sha256": "a932e617ee66dabc49b4087baf6606eeb2074f70ebb3efa0723b1d9c92add290"
     },
     {
       "path": "src/bongos/metrics.js",
@@ -5967,7 +5967,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "d2dd5e30bb7f44cd8a37cbf559bbcdf76aec973043f3db5deec8988b62a59eb6"
+      "sha256": "1f5ebdac8a94a258566b8d28fa14a3f47496e0f35e928e2d85ba85e19738134a"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -7332,7 +7332,7 @@
     {
       "path": "tests/llm-pricing.mjs",
       "mode": "0000644",
-      "sha256": "de3fabaeafb3eb3ad500becf565f3b6d7118a763f1e80d085f94b6ba990d5c58"
+      "sha256": "64f8bd94dc461ca9b4ef82fae929d49675231afa6a24d6d65ba2dbe8721efc89"
     },
     {
       "path": "tests/local_preview.mjs",
@@ -7347,7 +7347,7 @@
     {
       "path": "tests/membership_kind_lockstep.mjs",
       "mode": "0000644",
-      "sha256": "7ebca67bf07f723f47a861eb530a0feee25967fe3c0f4a9e7d76703351dc8d84"
+      "sha256": "e40df74d518a508417dbea2d8f39952bd8f666e866aff985a8ab72758ead873a"
     },
     {
       "path": "tests/memory_isolation.mjs",

package/docs/adr/0177-goal-membership-kind.md

@@ -128,9 +128,11 @@ cannot, if the new column has a DEFAULT: **Postgres materializes a column defaul
 statement — took the "new code wrote it" branch and overwrote `role`, turning a pending
 INVITE into an active membership. So the new column stays **DEFAULT-less** while the legacy
 one is still written (NULL then means exactly "not written"), and `DEFAULT` + `NOT NULL`
-arrive together in step 2. `core_220` shipped with the defective form and is corrected
-under task [#1003093](https://cloudbongos.com/builders#/task/1003093) — where the same
-statement demotes a goal's first lead to `member` on a fresh install; the invariant is
+arrive together in step 2. `core_220` shipped with the defective form and was corrected
+the same day under task [#1003093](https://cloudbongos.com/builders#/task/1003093) — there
+the same statement demoted a goal's first lead to `member` on a fresh install
+(`<redacted>.sql` runs after the core migrations), and no production
+row was ever affected because the pin still served 1.19.218; the invariant is
 pinned statically by `tests/membership_kind_lockstep.mjs`, since the trigger only
 misbehaves against a live Postgres and CI has none.
 

package/migrations/core_220_goal_members_membership_kind.sql

@@ -43,8 +43,15 @@ ALTER TABLE goal_members
 
 UPDATE goal_members SET membership_kind = role WHERE membership_kind IS NULL;
 
-ALTER TABLE goal_members
-  ALTER COLUMN membership_kind SET DEFAULT 'member';
+-- NO DEFAULT WHILE `role` IS STILL WRITTEN — and this is load-bearing, not tidiness
+-- (task 1003093, found by the grader on the sibling migration). Postgres materializes
+-- a column DEFAULT into NEW *before* any BEFORE ROW trigger fires, so a default here
+-- would make `NEW.membership_kind IS NULL` never true and the trigger could no longer
+-- tell "the caller wrote the new column" from "the default filled it". An old-release
+-- INSERT naming only `role` — lifecycle_001_goal_first_leads.sql's `'lead'`, or
+-- createGoal / transferGoalOwnership on a pre-1003013 pin — would then be silently
+-- rewritten to the default, DEMOTING the goal's own lead to a plain member. The
+-- DEFAULT (and NOT NULL) arrive in step 2, when `role` is dropped.
 
 DO $$
 BEGIN
@@ -63,20 +70,24 @@ END $$;
 --    statement that wrote either one — no second UPDATE, no window where the two
 --    disagree, and nothing for application code to remember.
 --
---    Direction is decided by WHICH SIDE CHANGED, not by a preferred column: new
---    code sets membership_kind and `role` follows; the historical
+--    Direction is decided by WHICH SIDE THE CALLER WROTE: new code sets
+--    membership_kind and `role` follows; the historical
 --    lifecycle_001_goal_first_leads.sql seed (and any pre-upgrade code, including
---    the release a rollback would restore) sets `role` and membership_kind
---    follows. On INSERT the new column wins when it was supplied, because `role`
---    carries a DEFAULT that makes "omitted" and "explicitly 'member'"
---    indistinguishable.
+--    the release a rollback would restore) sets `role` and membership_kind follows.
+--    On INSERT that question is answered by `NEW.membership_kind IS NULL`, which is
+--    only trustworthy because the new column has NO DEFAULT — see the note above it.
+--    On UPDATE, OLD is available and the comparison is direct.
 CREATE OR REPLACE FUNCTION goal_members_membership_kind_lockstep() RETURNS trigger AS $$
 BEGIN
   IF TG_OP = 'INSERT' THEN
-    IF NEW.membership_kind IS NOT NULL THEN
-      NEW.role := NEW.membership_kind;
-    ELSE
+    -- NULL means the caller did not write the new column (see the no-DEFAULT note
+    -- above): an old-release INSERT, so `role` is the source of truth. Otherwise the
+    -- caller is new code and `role` follows, so an older release can still read it.
+    IF NEW.membership_kind IS NULL THEN
       NEW.membership_kind := COALESCE(NEW.role, 'member');
+      NEW.role := COALESCE(NEW.role, 'member');
+    ELSE
+      NEW.role := NEW.membership_kind;
     END IF;
   ELSE
     IF NEW.membership_kind IS DISTINCT FROM OLD.membership_kind THEN

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.241",
+  "version": "1.19.243",
   "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/bongos/llm-pricing.js

@@ -49,15 +49,52 @@
 //   - opus   = Claude Opus 5 / 4.8 / 4.7  ($5 in / $25 out)  [re-verified]
 //   - sonnet = Claude Sonnet 4.6          ($3 in / $15 out)  [re-verified]
 //   - haiku  = Claude Haiku 4.5           ($1 in / $5 out)   [re-verified]
-// NOTE (deliberately NOT changed here — its own task, per the rule above):
-// Claude Sonnet 5 is now $2/$10, not the $3/$15 this `sonnet` row carries. The
-// grader's default worker model is claude-sonnet-5, so grade costs are currently
-// OVER-priced ~1.5×. That is a separate price-table decision; see task 1003001.
+// VERIFIED 2026-08-18 against the live models overview at platform.claude.com
+// (task 1003001 — the task the note this replaces pointed at):
+//   - sonnet = Claude Sonnet 5  ($2 in / $10 out)  [WAS $3/$15 = Sonnet 4.6's rate]
+//   - fable  = Claude Fable 5 / Mythos 5 ($10/$50) [re-verified, unchanged]
+//   - opus   = Claude Opus 5 / 4.8 / 4.7 ($5/$25)  [re-verified, unchanged]
+//   - haiku  = Claude Haiku 4.5 ($1/$5)            [re-verified, unchanged]
+// The live page states Sonnet 5 as $2/$10 flatly — NO introductory qualifier and
+// no scheduled increase. (An earlier launch note describing $2/$10 as
+// introductory through 2026-08-31 is superseded; a cached model table that still
+// carries the qualifier is stale, which is precisely why this file re-verifies
+// against the live page rather than a recalled figure.)
+//
+// WHY IT MATTERED, and why it was worth its own task: the grader's default worker
+// model is claude-sonnet-5 (modules/grading/grader-rubric.json), so the panel is
+// this platform's heaviest sonnet consumer, and ADR 0054 pays each shipped session
+// round(true_cost_usd × 1.20). An over-priced sonnet row therefore OVER-PAID real
+// credits — the mirror image of the fable bug recorded above, which under-paid.
+//
+// HISTORICAL ROWS ARE NOT RE-PRICED. cost_log rows written before today keep the
+// dollars we believed at the time: the ledger is a record of what was charged and
+// paid, and rewriting paid rows to a new rate would make the credit history
+// disagree with the credit_log it produced. Expect a visible step change in
+// cost-per-ship around 2026-08-18 for sonnet-heavy work; this note is its
+// explanation.
+//
+// THE FAMILY↔MODEL BINDING IS NOW DATA (FAMILY_CURRENT_MODEL below) and pinned by
+// tests/llm-pricing.mjs: a family whose current model is re-pinned cannot keep the
+// old model's rate silently, which is exactly the failure this task fixed.
+// The model each family's rate is quoted FROM. Data, not logic: nothing branches
+// on it, but it makes the claim "this row is <model>'s price" checkable — the test
+// asserts each family's rate against that model's published figures, so re-pinning
+// a family to a newer model without re-pricing it reds the build (task 1003001).
+// Legacy members of a family are knowingly mis-priced (the family-pricing trade-off
+// documented above): claude-sonnet-4-6 is really $3/$15 and prices here as Sonnet 5.
+const FAMILY_CURRENT_MODEL = Object.freeze({
+  fable:  'claude-fable-5',
+  opus:   'claude-opus-5',
+  sonnet: 'claude-sonnet-5',
+  haiku:  'claude-haiku-4-5',
+});
+
 const PRICES = {
   // family : { input, output, cache_write_5m, cache_write_1h, cache_read }  (USD / 1e6 tokens)
   fable:  { input: 10, output: 50, cache_write_5m: 12.5, cache_write_1h: 20, cache_read: 1   },
   opus:   { input: 5,  output: 25, cache_write_5m: 6.25, cache_write_1h: 10, cache_read: 0.5 },
-  sonnet: { input: 3,  output: 15, cache_write_5m: 3.75, cache_write_1h: 6,  cache_read: 0.3 },
+  sonnet: { input: 2,  output: 10, cache_write_5m: 2.5,  cache_write_1h: 4,  cache_read: 0.2 },
   haiku:  { input: 1,  output: 5,  cache_write_5m: 1.25, cache_write_1h: 2,  cache_read: 0.1 },
 };
 
@@ -246,4 +283,4 @@ function componentsFromModelUsage(modelUsage) {
   };
 }
 
-module.exports = { PRICES, familyFor, priceUsage, canonicalizeModelId, priceModelUsage, componentsFromModelUsage };
+module.exports = { PRICES, FAMILY_CURRENT_MODEL, familyFor, priceUsage, canonicalizeModelId, priceModelUsage, componentsFromModelUsage };

package/src/module-api.js

@@ -909,8 +909,12 @@ const { validateOrRespond, LIMITS, parseId, asyncHandler, corsPublicGet, parsePa
 //         landed since 1.19.239 with no explicit bump. run 32182178305. (task 1002620)
 //   1.19.241 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
 //         landed since 1.19.240 with no explicit bump. run 32184475745. (task 1002620)
+//   1.19.242 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+//         landed since 1.19.241 with no explicit bump. run 32185198139. (task 1002620)
+//   1.19.243 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+//         landed since 1.19.242 with no explicit bump. run 32193666731. (task 1002620)
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.241'; // CI auto-patch carrier (ADR 0161); see changelog above
+const CORE_VERSION = '1.19.243'; // 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');

package/tests/llm-pricing.mjs

@@ -5,12 +5,17 @@
 // Re-VERIFIED + extended 2026-08-16 (task 1002883): fable (Fable 5 / Mythos 5)
 // $10/$50 — the family familyFor() used to miss, so Fable sessions priced at the
 // opus fallback and cost-plus under-paid by half.
+// Re-VERIFIED 2026-08-18 (task 1003001): sonnet is CLAUDE SONNET 5 at $2/$10 —
+// the row had carried Sonnet 4.6's $3/$15, over-pricing the grader panel (whose
+// default worker IS claude-sonnet-5) and therefore over-paying cost-plus credits.
+// The family↔model binding is now data (FAMILY_CURRENT_MODEL) and is pinned below,
+// so a future re-pin cannot keep an old model's rate silently.
 // Run:  node tests/llm-pricing.mjs
 
 import { strict as assert } from 'node:assert';
 import { createRequire } from 'node:module';
 const require = createRequire(import.meta.url);
-const { priceUsage, familyFor, PRICES, canonicalizeModelId, priceModelUsage } = require('../src/bongos/llm-pricing.js');
+const { priceUsage, familyFor, PRICES, FAMILY_CURRENT_MODEL, canonicalizeModelId, priceModelUsage } = require('../src/bongos/llm-pricing.js');
 
 let passed = 0, failed = 0;
 function test(name, fn) {
@@ -101,11 +106,68 @@ test('opus 4.8: 1M input + 1M output = $5 + $25 = $30', () => {
   assert.equal(r.family, 'opus');
 });
 
-test('sonnet input ($3) vs haiku output ($5) use their own rates', () => {
-  assert.ok(near(priceUsage('claude-sonnet-4-6', { input_tokens: M }).usd, 3));
+test('sonnet input ($2 — Sonnet 5) vs haiku output ($5) use their own rates', () => {
+  assert.ok(near(priceUsage('claude-sonnet-5', { input_tokens: M }).usd, 2));
   assert.ok(near(priceUsage('claude-haiku-4-5', { output_tokens: M }).usd, 5));
 });
 
+test('the grader panel prices at Sonnet 5, not Sonnet 4.6 — 1M in + 1M out = $12', () => {
+  // The regression this task fixed, stated as money: the panel's default worker is
+  // claude-sonnet-5 (modules/grading/grader-rubric.json), and the row used to say
+  // $3/$15 = $18 for the same tokens. ADR 0054 pays round(true_cost × 1.20), so the
+  // extra $6 per million became real over-paid credits.
+  const r = priceUsage('claude-sonnet-5', { input_tokens: M, output_tokens: M });
+  assert.ok(near(r.usd, 12), `got ${r.usd}`);
+  assert.equal(r.family, 'sonnet');
+  assert.equal(r.unknown_model, false);
+});
+
+test('a LEGACY family member is knowingly mis-priced — sonnet 4.6 rides Sonnet 5 rates', () => {
+  // Family pricing assumes the CURRENT model in each family (the file says so).
+  // claude-sonnet-4-6 really costs $3/$15; here it prices at $2/$10. This test
+  // exists so that trade-off is a recorded decision rather than a surprise — if the
+  // platform ever runs a legacy model in earnest, this is the test that should fail
+  // first and force a per-model override.
+  assert.ok(near(priceUsage('claude-sonnet-4-6', { input_tokens: M }).usd, 2));
+});
+
+// ── the family↔model binding (task 1003001) ─────────────────────────────────
+// Each family's rate is quoted from ONE named model. These literals are the
+// published per-model figures, kept separate from PRICES on purpose: if someone
+// re-pins a family to a newer model, the two copies disagree and this test names
+// the model in its failure — the drift that shipped Sonnet 4.6's price under a
+// Sonnet 5 workload cannot recur silently.
+const PUBLISHED = {
+  'claude-fable-5':  { input: 10, output: 50 },
+  'claude-opus-5':   { input: 5,  output: 25 },
+  'claude-sonnet-5': { input: 2,  output: 10 },
+  'claude-haiku-4-5': { input: 1, output: 5  },
+};
+
+test('every family rate matches the published price of the model it names', () => {
+  for (const [family, modelId] of Object.entries(FAMILY_CURRENT_MODEL)) {
+    const published = PUBLISHED[modelId];
+    assert.ok(published, `FAMILY_CURRENT_MODEL.${family} names ${modelId}, which this test has no published price for — add it (verified against the live models page), do not guess`);
+    assert.equal(PRICES[family].input, published.input, `${family} input should be ${modelId}'s $${published.input}`);
+    assert.equal(PRICES[family].output, published.output, `${family} output should be ${modelId}'s $${published.output}`);
+  }
+});
+
+test('every family names a model familyFor() actually resolves back to it', () => {
+  for (const [family, modelId] of Object.entries(FAMILY_CURRENT_MODEL)) {
+    assert.equal(familyFor(modelId), family,
+      `FAMILY_CURRENT_MODEL.${family} names ${modelId}, but familyFor('${modelId}') says ${familyFor(modelId)} — the binding and the matcher disagree`);
+  }
+});
+
+test('cache rates ride the published multipliers off each family base (1.25× / 2× / 0.1×)', () => {
+  for (const [family, p] of Object.entries(PRICES)) {
+    assert.ok(near(p.cache_write_5m, p.input * 1.25), `${family} 5m write should be 1.25× input`);
+    assert.ok(near(p.cache_write_1h, p.input * 2),    `${family} 1h write should be 2× input`);
+    assert.ok(near(p.cache_read,     p.input * 0.1),  `${family} cache read should be 0.1× input`);
+  }
+});
+
 test('cache read is 0.1× input (opus $0.50 / 1M)', () => {
   const r = priceUsage('claude-opus-4-8', { cache_read_input_tokens: M });
   assert.ok(near(r.usd, 0.5), `got ${r.usd}`);

package/tests/membership_kind_lockstep.mjs

@@ -19,6 +19,12 @@
 //   A old-invite-pending | role=builder | membership_kind=member   ← WRONG (before)
 //   A old-invite-pending | role=pending | membership_kind=pending  ← after the fix
 //
+// core_220 carried the same defect (task 1003093): an old-release
+// `INSERT … (goal_id, builder_id, role) VALUES (…, 'lead')` — which is exactly what
+// lifecycle_001_goal_first_leads.sql issues on a FRESH install, after the core
+// migrations — landed `role=member, membership_kind=member`, silently demoting every
+// new goal's creator out of manager standing.
+//
 // The fix is the absence of a DEFAULT while the legacy column is still written, so
 // NULL means exactly "not written". The DEFAULT (and NOT NULL) belong to step 2,
 // when the legacy column is dropped. This file pins that invariant statically,
@@ -34,11 +40,17 @@ import { fileURLToPath } from 'node:url';
 const ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '..');
 const read = (rel) => fs.readFileSync(path.join(ROOT, rel), 'utf8');
 
-// core_220 (goal membership) carries the SAME defect and is fixed under task
-// 1003093 — filed, not forgotten. It is deliberately absent from this list rather
-// than silently passing: a class guard that quietly excludes a known-broken member
-// of the class is worse than no guard.
+// BOTH expand-phase migrations, since task 1003093 fixed core_220's identical
+// INSERT branch. core_220's version of the bug demoted a goal's own LEAD: on a fresh
+// install, lifecycle_001_goal_first_leads.sql inserts the creator with `role='lead'`
+// AFTER core migrations run, so every new goal's creator landed as a plain member and
+// lost manager standing. Verified against a real Postgres both ways round.
 const EXPAND_MIGRATIONS = [
+  {
+    rel: 'migrations/core_220_goal_members_membership_kind.sql',
+    table: 'goal_members',
+    legacy: 'role',
+  },
   {
     rel: 'modules/platform-identity/migrations/platform_identity_010_membership_kind.sql',
     table: 'platform_identity_project_memberships',