@bongos/core 1.19.241 → 1.19.242

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.242",
+  "core_contract": "1.19.242",
+  "source_commit": "900c5fe4161d60490d52cd4dfa2e0857a2748042",
   "source_ref": "HEAD",
-  "built_at": "2026-08-18T20:51:17.253Z",
+  "built_at": "2026-08-18T20:58:51.212Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
     "docs_redacted": 312,
@@ -17,7 +17,7 @@
     "gate": "passed"
   },
   "file_count": 1660,
-  "tree_sha256": "d8e9cb0898ebdea8fca5a8bc8e94fd925e4725473943002abf4cbbc68e4ae963",
+  "tree_sha256": "367c3937d0fd713cbda6b0e1ea8a32ea5f0be72b756ba5440760d6ff8a07b5d4",
   "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": "026bf4799e0c4eab9e946c1f9d1668f5ee3f47ad487ef5abbfe9de063867cc0f"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "ac7bd7958b32f4eee03a29fab16260eb489d49c0e40907691bdd9c3e447d6a5d"
+      "sha256": "343d7a6a0e9c8123a4f5cf336dfb8bdaf59c735227371c8fe8b632b6a17706a5"
     },
     {
       "path": "public-docs/index.html",
@@ -5967,7 +5967,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "d2dd5e30bb7f44cd8a37cbf559bbcdf76aec973043f3db5deec8988b62a59eb6"
+      "sha256": "c78192a54a2578a22420c02ac2da5397bccc6fa582540d8184d792dac9b13df3"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -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.242",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@bongos/core",
-      "version": "1.19.241",
+      "version": "1.19.242",
       "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.242",
   "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

@@ -909,8 +909,10 @@ 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)
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.241'; // CI auto-patch carrier (ADR 0161); see changelog above
+const CORE_VERSION = '1.19.242'; // 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/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',