@bongos/core 1.19.239 → 1.19.241

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.239",
-  "core_contract": "1.19.239",
-  "source_commit": "92f85bc3527c85038cc818e47b4d503a340c8abb",
+  "core_version": "1.19.241",
+  "core_contract": "1.19.241",
+  "source_commit": "3be9d3e72426f99e05a9842dcb5cc9c85cfc75a0",
   "source_ref": "HEAD",
-  "built_at": "2026-08-18T19:09:51.272Z",
+  "built_at": "2026-08-18T20:51:17.253Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
     "docs_redacted": 312,
     "agent_docs_stubbed": 21,
-    "functional_verbatim": 1324,
+    "functional_verbatim": 1327,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 1657,
-  "tree_sha256": "ba99d83f49d20d229d51e1ca9cbb5232f744888d91ab1dbf43d5c092eade4cf9",
+  "file_count": 1660,
+  "tree_sha256": "d8e9cb0898ebdea8fca5a8bc8e94fd925e4725473943002abf4cbbc68e4ae963",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -367,7 +367,7 @@
     {
       "path": "clients/bongos-client/index.d.ts",
       "mode": "0000644",
-      "sha256": "2006b6d2f061c266c79390839bca228df59753db2e3919f49946db07682ee207"
+      "sha256": "dee98bb9b25e4cf7b2f4644298caa77b1bb9f7ef29560228333131b107be01dd"
     },
     {
       "path": "clients/bongos-client/index.mjs",
@@ -1367,7 +1367,7 @@
     {
       "path": "docs/adr/0177-goal-membership-kind.md",
       "mode": "0000644",
-      "sha256": "0c81340c845250107cd195dadce2740b8324b7777a44011b02b488827193a4de"
+      "sha256": "1bc4a0df32f8267b5fb3b274974fbcd15d680a161de4c502334dff62da494b17"
     },
     {
       "path": "docs/adr/README.md",
@@ -1377,12 +1377,12 @@
     {
       "path": "docs/api-reference.md",
       "mode": "0000644",
-      "sha256": "791e8f83d023e77d3faa2e3abf3ec9099f3ffa9236183aad5092ef0792e510cc"
+      "sha256": "c0f20beba35a91ba5f06a1accf3b5df15832d719f14af729824295da60d33e30"
     },
     {
       "path": "docs/api/openapi.json",
       "mode": "0000644",
-      "sha256": "901748f25425af336637858b48ec06ad0461d5d3dc2a6beaad8b2a6af0eb6161"
+      "sha256": "50e9b99155cd83e625f1e0289a4e8ab6a2817b2701dc3d62cfb3d902c3acf3bd"
     },
     {
       "path": "docs/architecture.md",
@@ -3362,7 +3362,7 @@
     {
       "path": "modules/hall-ui/public/my-projects.js",
       "mode": "0000644",
-      "sha256": "30d22956e21c9ac371d989d8b295631e7bd5df89647457e81a71e0dfffe07cce"
+      "sha256": "9b5604fd1d071bcb61c1ce77a8356fbce8060db09440ba5621646aa18b6f5b5f"
     },
     {
       "path": "modules/hall-ui/public/not-ready.html",
@@ -3904,6 +3904,11 @@
       "mode": "0000644",
       "sha256": "00e2e9feccc56bdb30a5e4f0c6abbe610382fe425222419963a04ae022d3c58a"
     },
+    {
+      "path": "modules/platform-identity/migrations/platform_identity_010_membership_kind.sql",
+      "mode": "0000644",
+      "sha256": "8f03dc84d8fe3864aa5f933512df71259c266e8a16214a926cf89eaf01cc5668"
+    },
     {
       "path": "modules/platform-identity/module.json",
       "mode": "0000644",
@@ -3912,7 +3917,7 @@
     {
       "path": "modules/platform-identity/platform-identity.js",
       "mode": "0000644",
-      "sha256": "423afc175f0e1024d39fc20b561e24b423e2d9b6e5c16ddcd8e4a3329bcfa97b"
+      "sha256": "a563fb701e62d665d10baf25761f9341678264fa2c6c73f1efeb9eb20ba6a439"
     },
     {
       "path": "modules/platform-identity/pollers/code-sweep.js",
@@ -3927,7 +3932,7 @@
     {
       "path": "modules/platform-identity/routes/my-projects.js",
       "mode": "0000644",
-      "sha256": "7fdb5a107e1ad84214c0d07507a7fd14b9234c9907224fddc0f6a70c850f460a"
+      "sha256": "de5aa85aedf31834009ec0e1a3b4a7ceea2ff60bbb6586a3f231b59eb9549aaf"
     },
     {
       "path": "modules/platform-identity/routes/profile.js",
@@ -3952,12 +3957,12 @@
     {
       "path": "modules/platform-identity/routes/sso.js",
       "mode": "0000644",
-      "sha256": "72796558274b45faec2b1a63e332100061a6ab0c690dadc42a54f1f39cb0c68e"
+      "sha256": "e4cd3084c44b6ff3e3fdad141e530b098b330a25d609fd08f5ae2290fd251db0"
     },
     {
       "path": "modules/platform-identity/tests/platform-identity.mjs",
       "mode": "0000644",
-      "sha256": "514adcaae952190d418888ffb778d541a632e3040664ce53f7a55ba9a297292b"
+      "sha256": "6f442cd4ae9ebb770e3537ae82da30e555f7e6ce3a293a60fbd154eff6c1eaf1"
     },
     {
       "path": "modules/platform-identity/ui/.gitkeep",
@@ -4342,12 +4347,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "16010eb616ec78eb915efe81ecf81ad7b20339180ec495e40eb50b71bbac8b93"
+      "sha256": "8f961bb896bdf312ad73752daa2342ce9ccf7db02b21ac9d2480694db28857d8"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "8cf3937acd1926b71f0e9ee112fce2b1d23adfd5b58cb2a2e36926f90b2e714f"
+      "sha256": "ac7bd7958b32f4eee03a29fab16260eb489d49c0e40907691bdd9c3e447d6a5d"
     },
     {
       "path": "public-docs/index.html",
@@ -4972,7 +4977,7 @@
     {
       "path": "scripts/gds/fitness.js",
       "mode": "0000644",
-      "sha256": "f5059d035746d8ea967e127e8421213efede43c9ae50c50403fc8772c487db76"
+      "sha256": "add1ee5439ef3ddff171e7eb9a695c63a41b8323c5e8cc6c415b620b812bdfa8"
     },
     {
       "path": "scripts/gds/gate-review.js",
@@ -5332,7 +5337,7 @@
     {
       "path": "scripts/gds/run-unit-tests.js",
       "mode": "0000644",
-      "sha256": "21bcaeaa9d8b2048b9c3f9ff9b251a9203a9259c991a536636c0ec3c8745bbd5"
+      "sha256": "192350d9d65934a1af724d0f285cc74a89a842e75d0fdec37037d34ded5db546"
     },
     {
       "path": "scripts/gds/sandbox-stage.js",
@@ -5722,7 +5727,7 @@
     {
       "path": "src/bongos/auth.js",
       "mode": "0000644",
-      "sha256": "8fd6f6ce798ebcde76cd2ac0ccf7129a60555506ce3d2fed818deb1eb331d42b"
+      "sha256": "803d4cc68847dda227c8581be493c2b4e799d1bf81acd40794efbf7b2b625a24"
     },
     {
       "path": "src/bongos/cascade-dispatch.js",
@@ -5962,7 +5967,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "3995623cfa7376dbf8cbcf14b238c1fa1c919ad9d8da5af781b0f78dcb0bb8cc"
+      "sha256": "d2dd5e30bb7f44cd8a37cbf559bbcdf76aec973043f3db5deec8988b62a59eb6"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -6967,7 +6972,12 @@
     {
       "path": "tests/government_live_proof.mjs",
       "mode": "0000644",
-      "sha256": "af6423ac87819ff344c8a7804c0eda903a3e8c7633d1e4182e7d4f446d30cec0"
+      "sha256": "6d829af6ef71bfa744a4ff457a4766b5cce021f317661579b06ecfc14298a523"
+    },
+    {
+      "path": "tests/government_live_proof_shape.mjs",
+      "mode": "0000644",
+      "sha256": "75160048aba7b8c2264478c29aa2fc19636c67f66cd63842a83851574b722469"
     },
     {
       "path": "tests/government_ownership_scope.mjs",
@@ -7212,7 +7222,7 @@
     {
       "path": "tests/idp_federation.mjs",
       "mode": "0000644",
-      "sha256": "09a9ae4a726cec8d0e31bc50dc08db102745c6451fb64f105c2be1b623062986"
+      "sha256": "5130936408829e4e45742eda0124aac9df50865ece1812274354384f9da498fd"
     },
     {
       "path": "tests/infra_exec_paths.mjs",
@@ -7334,6 +7344,11 @@
       "mode": "0000644",
       "sha256": "9a1813d6036886ea07d1563e71a466e66c28554b75b22605464c795fd9fa2ebb"
     },
+    {
+      "path": "tests/membership_kind_lockstep.mjs",
+      "mode": "0000644",
+      "sha256": "7ebca67bf07f723f47a861eb530a0feee25967fe3c0f4a9e7d76703351dc8d84"
+    },
     {
       "path": "tests/memory_isolation.mjs",
       "mode": "0000644",

package/clients/bongos-client/index.d.ts

@@ -294,7 +294,7 @@ export interface PostSsoActivityRollupRequest { client_id: string; client_secret
 export interface PostSsoActivityRollupResponse { ok: boolean }
 export interface PostSsoDevicePollRequest { device_code: string }
 export interface PostSsoDeviceStartRequest { origin: string }
-export interface PostSsoMembershipCheckInRequest { client_id: string; client_secret: string; github_id: StringifiableId; github_login: string; display_name?: string; avatar_url?: string; role?: string }
+export interface PostSsoMembershipCheckInRequest { client_id: string; client_secret: string; github_id: StringifiableId; github_login: string; display_name?: string; avatar_url?: string; membership_kind?: string; role?: string }
 export interface PostSsoMembershipCheckInResponse { ok: boolean }
 export interface PostSsoTokenRequest { client_id: string; client_secret: string; code: string; redirect_uri: string }
 export interface PostSsoTokenResponse { github_id: unknown; github_login: unknown; display_name: unknown; avatar_url: unknown }

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

@@ -2,7 +2,7 @@
 
 - **Status:** Accepted
 - **Date:** 2026-08-18
-- **Task:** [#1003013](https://cloudbongos.com/builders#/task/1003013) (goal 1000068 — government terminology; unlinked from the goal's criteria on 2026-08-18 because it is a live-column migration, not a naming pass)
+- **Tasks:** [#1003013](https://cloudbongos.com/builders#/task/1003013) (goal 1000068 — government terminology; unlinked from the goal's criteria on 2026-08-18 because it is a live-column migration, not a naming pass)
 - **Extends:** [ADR 0174](<redacted>.md) — the reserved-word rule, applied to the fourth use it did not cover
 - **Related:** ADR 0016 (authority resolved server-side, per request, uncached), 0086 (goals + scope walls), 0154 (goal owner/manager authors criteria), 0137/0161 (land → release → deploy are three gates)
 
@@ -83,6 +83,62 @@ regression available — a membership query reaching for the old column — with
 only exemption is a line that CITES the rule (ADR 0174 / ADR 0177 / task 1003013); naming a ban has to
 be legal or the code cannot explain itself. R07 stays scoped to the government surface, unchanged.
 
+## Amendment, same day — the FIFTH use: project membership (task [#1003090](https://cloudbongos.com/builders#/task/1003090))
+
+The sweep for the fourth use turned up a fifth, and it is worse: the hub's
+`<redacted>.role` (`'owner' | 'builder' | 'visitor' |
+'pending'`, ADR 0141 §3) collides with the reserved word **twice** — the column is named
+`role`, and one of its VALUES is `'builder'`, a craft name pressed into meaning "a
+non-owner member of this project". The migration's own comment ("a COARSE role ONLY …
+the role is owner|builder|visitor, NEVER a rank") is the same qualifier tell ADR 0174
+diagnosed in "rank-role".
+
+Decisions 1, 2 and 4 above carry over unchanged: the column becomes `membership_kind`,
+the value becomes `'member'` (`owner` / `visitor` / `pending` untouched), the migration
+is expand-then-contract with a lockstep trigger (`<redacted>`), and the
+fitness wall's file list grows rather than the rule widening. **Decision 3 is the one
+that does NOT carry over.**
+
+**Decision 3′ — this rename keeps a compatibility window, and the sender writes BOTH
+spellings.** This is a deliberate, named divergence from decision 3 above *and* from the
+sequence task #1003090 itself prescribed ("the API field renamed with no alias"); the
+task wrote that sequence before anyone had looked at who calls the endpoint. Decision 3
+holds wherever every caller ships in one release, which is why it stays the default — and
+it does not hold here. The goal-membership rename could ship without an alias because every
+caller lived in the same release. This table's writer is `POST
+/sso/membership/check-in` — a **server-to-server call from other instances**, each on
+its own upgrade schedule (ADR 0137/0161: land, release and deploy are three separate
+gates *per instance*). So:
+
+- the **hub accepts both** fields, `membership_kind` winning when both arrive, and maps
+  a legacy `'builder'` to `'member'` on the way in;
+- the **sender sends both** (`src/bongos/auth.js`). This is the part worth writing down:
+  sending only the new field would make an un-upgraded hub silently default every
+  membership to non-owner — *dropping the owner flag* — while sending only the legacy
+  field would make an upgraded hub translate forever. Sending both is what makes the two
+  ends independent;
+- the trigger therefore maps **values as well as columns**, in both directions, which
+  `core_220`'s did not have to.
+
+**And a trap both triggers share, found by the grader on #1003090.** The INSERT branch has
+to tell "the caller wrote the new column" from "the column's DEFAULT filled it" — and it
+cannot, if the new column has a DEFAULT: **Postgres materializes a column default into
+`NEW` before any BEFORE ROW trigger fires.** With a default in place, an old-release
+`INSERT … (client_id, github_id, role) VALUES (…, 'pending')` — `inviteToProject`'s exact
+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
+pinned statically by `tests/membership_kind_lockstep.mjs`, since the trigger only
+misbehaves against a live Postgres and CI has none.
+
+The window's removal is a filed task, and its condition is explicit: every federated
+instance past the window, not merely "one release later". A time-boxed shim still ships
+with the test of its absence (ADR 0174's Lineage lesson) — that test lands with the
+removal, because until then the legacy field is load-bearing, not vestigial.
+
 ## Consequences
 
 - The word `role` no longer names a goal membership in the API, the hall, or the docs, and in the DB it
@@ -93,4 +149,5 @@ be legal or the code cannot explain itself. R07 stays scoped to the government s
   the only new moving part on the write path, and it is the thing step 2 removes.
 - `docs/canonical-permissions.md` (the goal-management wall) now names `membership_kind`; the
   `authorizeGoalManagement` behaviour is untouched — this ADR changes no authority, floor, or grant.
-- The fifth use (`project_memberships.role`) is now catalogued and claimable, with this as its pattern.
+- The fifth use (`project_memberships.role`) shipped the same day under the amendment above — same shape, plus a cross-version window because its writer is another instance.
+- **No sixth use is known.** The remaining `role` spellings in the repo are the three legitimate ones ADR 0174 named: the crafts, `builders.system_role` (machine identity), and Discord's own noun — plus HTML's ARIA attribute, which every wall strips before matching.

package/docs/api/openapi.json

@@ -11117,7 +11117,7 @@
           "sso"
         ],
         "summary": "POST /sso/membership/check-in",
-        "description": "POST /sso/membership/check-in — a federated instance reports, on every sign-in, that a builder builds on its project (ADR 0141 §3). Server-to-server, authed by client_id + client_secret (same constant-time check as /sso/token). Upserts the account (so a CLI-only builder still appears in My Projects) + the membership with a COARSE role. The client_id is taken from the AUTHENTICATED client — the caller cannot report membership for a project it doesn't hold the secret for. rank: public — authenticated by client_id + client_secret, not a builder rank.\n\n**Rank:** `public` — No authentication — any caller.",
+        "description": "POST /sso/membership/check-in — a federated instance reports, on every sign-in, that a builder builds on its project (ADR 0141 §3). Server-to-server, authed by client_id + client_secret (same constant-time check as /sso/token). Upserts the account (so a CLI-only builder still appears in My Projects) + the membership with a COARSE membership_kind. The client_id is taken from the AUTHENTICATED client — the caller cannot report membership for a project it doesn't hold the secret for. THE FIELD IS `membership_kind`; `role` IS ACCEPTED FOR THE WINDOW (task 1003090, ADR 0177 §\"the fifth use\"). ADR 0174 reserves `role` for the three crafts, and the old value 'builder' was a craft name meaning \"non-owner member\" — so both the field and that value are renamed. Unlike the goal-membership rename, this is a CROSS-VERSION wire contract: the callers are other instances on their own upgrade schedule, so an un-upgraded instance still sends `role: 'builder'` and the hub must keep understanding it. `membership_kind` WINS when both arrive (a sender in the window sends both deliberately). rank: public — authenticated by client_id + client_secret, not a builder rank.\n\n**Rank:** `public` — No authentication — any caller.",
         "x-rank": "public",
         "x-source": "modules/platform-identity/routes/sso.js",
         "requestBody": {
@@ -17333,6 +17333,10 @@
             "type": "string",
             "maxLength": 2048
           },
+          "membership_kind": {
+            "type": "string",
+            "maxLength": 16
+          },
           "role": {
             "type": "string",
             "maxLength": 16

package/docs/api-reference.md

@@ -474,7 +474,7 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/<redacted>
 | GET | `/api/bongos/sso/authorize` | `public` | — | GET /sso/authorize?client_id=&redirect_uri=&state= — the browser authorize leg. |
 | POST | `/api/bongos/sso/device/poll` | `public` | `device_code` | POST /sso/device/poll — poll the hub device flow. |
 | POST | `/api/bongos/sso/device/start` | `public` | `origin` | POST /sso/device/start — begin CLI federation. |
-| POST | `/api/bongos/sso/membership/check-in` | `public` | `client_id`, `client_secret`, `github_id`, `github_login`, `display_name`, `avatar_url`, `role` | POST /sso/membership/check-in — a federated instance reports, on every sign-in, that a builder builds on its project (ADR 0141 §3). |
+| POST | `/api/bongos/sso/membership/check-in` | `public` | `client_id`, `client_secret`, `github_id`, `github_login`, `display_name`, `avatar_url`, `membership_kind`, `role` | POST /sso/membership/check-in — a federated instance reports, on every sign-in, that a builder builds on its project (ADR 0141 §3). |
 | GET | `/api/bongos/sso/pubkey` | `public` | — | GET /sso/pubkey — the hub's Ed25519 assertion-verification key (public). |
 | POST | `/api/bongos/sso/token` | `public` | `client_id`, `client_secret`, `code`, `redirect_uri` | POST /sso/token — server-to-server code redemption. |
 

package/modules/hall-ui/public/my-projects.js

@@ -40,7 +40,7 @@
         meta.appendChild(o);
       }
       row.appendChild(meta);
-      if (m.role === 'owner') {
+      if (m.membership_kind === 'owner') {
         var pill = el('span', 'owner-pill');
         pill.textContent = 'owner';
         row.appendChild(pill);

package/modules/platform-identity/migrations/platform_identity_010_membership_kind.sql

@@ -0,0 +1,106 @@
+-- platform_identity_010_membership_kind.sql — the FIFTH "role" leaves the schema
+-- (task 1003090; ADR 0174 reserves the word for the three crafts, ADR 0177 §"the
+-- fifth use" records this two-step).
+--
+-- `platform_identity_project_memberships.role` holds the hub's COARSE project
+-- membership — and it collided with the reserved word TWICE over:
+--   • the COLUMN is named `role`, which ADR 0174 reserves for Artist / Ideator /
+--     Builder;
+--   • one of its VALUES is literally 'builder', used to mean "a non-owner member
+--     of this project" — a craft name doing membership work.
+-- The column becomes `membership_kind` and that value becomes 'member'. 'owner',
+-- 'visitor' and 'pending' are unchanged.
+--
+-- ── EXPAND-THEN-CONTRACT, AND WHY THE WINDOW IS LONGER HERE ─────────────────
+-- Same reasoning as core_220 (ADR 0177): `bongos upgrade` auto-rollback reverts the
+-- code pin and NOT the DB, so a bare RENAME COLUMN plus a rolled-back deploy
+-- strands the previous release on a missing column. But this table has a second,
+-- stronger reason: it is written by POST /sso/membership/check-in, a
+-- SERVER-TO-SERVER call from OTHER INSTANCES (ADR 0141 §3) that upgrade on their
+-- own schedule. The legacy `role` column and the legacy request field therefore
+-- outlive one release by design — until every federated instance is past the
+-- window. The removal task carries that condition.
+--
+-- Idempotent, additive, platform_identity_-namespaced (ADR 0083 §5). Forward-safe:
+-- old code writing `role` still lands a complete row (the trigger below), and no
+-- NOT NULL is added to the new column while the old one is still written.
+
+BEGIN;
+
+ALTER TABLE platform_identity_project_memberships
+  ADD COLUMN IF NOT EXISTS membership_kind text;
+
+-- Backfill WITH the value rename: 'builder' → 'member', everything else verbatim.
+UPDATE platform_identity_project_memberships
+   SET membership_kind = CASE WHEN role = 'builder' THEN 'member' ELSE role END
+ WHERE membership_kind IS NULL;
+
+-- NO DEFAULT ON THE NEW COLUMN WHILE THE LEGACY ONE IS STILL WRITTEN. This is
+-- load-bearing, and it is subtle: 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` (inviteToProject's `role = 'pending'`, or an owner
+-- check-in) would then be silently rewritten to the default's mapping — turning a
+-- pending INVITE into an active membership. Leaving the column DEFAULT-less makes
+-- NULL mean exactly "not written", which is what the trigger branches on. The
+-- default (and NOT NULL) arrive in step 2, when `role` is dropped and nothing
+-- writes the old name any more.
+
+DO $$
+BEGIN
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint
+     WHERE conrelid = 'platform_identity_project_memberships'::regclass
+       AND conname = 'platform_identity_project_memberships_membership_kind_check'
+  ) THEN
+    ALTER TABLE platform_identity_project_memberships
+      ADD CONSTRAINT platform_identity_project_memberships_membership_kind_check
+      CHECK (membership_kind IN ('owner', 'member', 'visitor', 'pending'));
+  END IF;
+END $$;
+
+-- The lockstep, with the value MAPPING in both directions — the difference from
+-- core_220's trigger, which only had to copy a value. Direction is decided by
+-- which side changed, so a check-in from an un-upgraded instance (writing `role`
+-- = 'builder') lands membership_kind = 'member', and new code writing
+-- membership_kind = 'member' keeps `role` = 'builder' readable by an old release.
+CREATE OR REPLACE FUNCTION platform_identity_membership_kind_lockstep() RETURNS trigger AS $$
+DECLARE
+  kind_from_role text;
+  role_from_kind text;
+BEGIN
+  kind_from_role := CASE WHEN NEW.role = 'builder' THEN 'member' ELSE NEW.role END;
+  role_from_kind := CASE WHEN NEW.membership_kind = 'member' THEN 'builder' ELSE NEW.membership_kind END;
+  IF TG_OP = 'INSERT' THEN
+    -- NULL means the caller did not write the new column (see the no-DEFAULT note
+    -- above): that is an old-release INSERT, so `role` is the source of truth and
+    -- the new column follows it. Otherwise the caller is new code and `role`
+    -- follows, mapped, so an older release can still read the row.
+    IF NEW.membership_kind IS NULL THEN
+      NEW.membership_kind := COALESCE(kind_from_role, 'member');
+      NEW.role := COALESCE(NEW.role, 'builder');
+    ELSE
+      NEW.role := role_from_kind;
+    END IF;
+  ELSE
+    IF NEW.membership_kind IS DISTINCT FROM OLD.membership_kind THEN
+      NEW.role := role_from_kind;
+    ELSIF NEW.role IS DISTINCT FROM OLD.role THEN
+      NEW.membership_kind := kind_from_role;
+    END IF;
+  END IF;
+  RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+DROP TRIGGER IF EXISTS platform_identity_membership_kind_lockstep
+  ON platform_identity_project_memberships;
+CREATE TRIGGER platform_identity_membership_kind_lockstep
+  BEFORE INSERT OR UPDATE ON platform_identity_project_memberships
+  FOR EACH ROW EXECUTE FUNCTION platform_identity_membership_kind_lockstep();
+
+INSERT INTO schema_migrations (version) VALUES ('platform_identity_010_membership_kind')
+  ON CONFLICT DO NOTHING;
+
+COMMIT;

package/modules/platform-identity/platform-identity.js

@@ -307,31 +307,53 @@ async function setProjectFeatured(id, featured, { pool = defaultPool } = {}) {
 // Project memberships (the cross-project directory — ADR 0141 §3)
 // -------------------------------------------------------------------------
 
-const MEMBERSHIP_ROLES = ['owner', 'builder', 'visitor', 'pending'];
+// THE COARSE PROJECT MEMBERSHIP — 'membership_kind', never 'role' (task 1003090,
+// ADR 0177 §"the fifth use"; ADR 0174 reserves that word for the three crafts). The
+// old value 'builder' is now 'member': it meant "a non-owner member of this
+// project", which is membership work done by a craft name.
+//
+// THE LEGACY COLUMN AND FIELD SURVIVE THIS RELEASE ON PURPOSE. This table is
+// written by POST /sso/membership/check-in — a server-to-server call from OTHER
+// INSTANCES (ADR 0141 §3) that upgrade on their own schedule — so both spellings
+// are read on the way in and platform_identity_010's trigger keeps both columns
+// (and both value vocabularies) in lockstep. Write `membership_kind` here; the
+// removal task drops the pair once every federated instance is past the window.
+const MEMBERSHIP_KINDS = ['owner', 'member', 'visitor', 'pending'];
+
+// Map the legacy wire/column vocabulary onto the current one and back: the craft
+// name 'builder' ⇄ 'member'; every other value was already right. Exported so the
+// route, the sender and the migration's trigger all agree on one mapping. (task
+// 1003090 — the legacy spelling is named here by necessity: this IS the translator.)
+function membershipKindFromLegacy(legacyValue) {
+  return legacyValue === 'builder' ? 'member' : legacyValue;
+}
+function legacyRoleFromKind(kind) {
+  return kind === 'member' ? 'builder' : kind;
+}
 
 // Upsert a builder's membership in a project (keyed by the reporting client + the
-// builder's github_id). COARSE role only — never a rank. Refreshes last_active on
-// every check-in. Returns the row.
-async function upsertMembership({ clientId, githubId, role = 'builder' }, { pool = defaultPool } = {}) {
-  const r = MEMBERSHIP_ROLES.includes(role) ? role : 'builder';
+// builder's github_id). COARSE membership only — never a rank. Refreshes
+// last_active on every check-in. Returns the row.
+async function upsertMembership({ clientId, githubId, membershipKind = 'member' }, { pool = defaultPool } = {}) {
+  const k = MEMBERSHIP_KINDS.includes(membershipKind) ? membershipKind : 'member';
   const { rows } = await pool.query(
-    `INSERT INTO platform_identity_project_memberships (client_id, github_id, role)
+    `INSERT INTO platform_identity_project_memberships (client_id, github_id, membership_kind)
      VALUES ($1, $2, $3)
      ON CONFLICT (client_id, github_id) DO UPDATE SET
-       role        = EXCLUDED.role,
+       membership_kind = EXCLUDED.membership_kind,
        last_active = now()
-     RETURNING id, client_id, github_id, role, joined_at, last_active`,
-    [clientId, githubId, r],
+     RETURNING id, client_id, github_id, membership_kind, joined_at, last_active`,
+    [clientId, githubId, k],
   );
   return rows[0];
 }
 
-// One membership row for (project, builder), any role — or null. Backs the
+// One membership row for (project, builder), any membership_kind — or null. Backs the
 // activity-rollup membership requirement (ADR 0171 D7): a client may only report
 // activity for a builder who actually has a membership on that project.
 async function getMembership(clientId, githubId, { pool = defaultPool } = {}) {
   const { rows } = await pool.query(
-    `SELECT id, client_id, github_id, role, joined_at, last_active
+    `SELECT id, client_id, github_id, membership_kind, joined_at, last_active
        FROM platform_identity_project_memberships
       WHERE client_id = $1 AND github_id = $2`,
     [clientId, githubId],
@@ -343,11 +365,11 @@ async function getMembership(clientId, githubId, { pool = defaultPool } = {}) {
 // display fields (name/origin from sso_clients). Powers "My Projects" (task #1002112).
 async function listMembershipsForAccount(githubId, { pool = defaultPool } = {}) {
   const { rows } = await pool.query(
-    `SELECT m.client_id, m.role, m.joined_at, m.last_active,
+    `SELECT m.client_id, m.membership_kind, m.joined_at, m.last_active,
             c.name AS project_name, c.origin AS project_origin, c.owner_github_id
        FROM platform_identity_project_memberships m
        LEFT JOIN platform_identity_sso_clients c ON c.client_id = m.client_id
-      WHERE m.github_id = $1 AND m.role <> 'pending'
+      WHERE m.github_id = $1 AND m.membership_kind <> 'pending'
       ORDER BY m.last_active DESC`,
     [githubId],
   );
@@ -364,10 +386,10 @@ async function listMembershipsForAccount(githubId, { pool = defaultPool } = {})
 // created, or { invited:false, alreadyMember:true } when a membership already existed.
 async function inviteToProject({ clientId, githubId }, { pool = defaultPool } = {}) {
   const { rows } = await pool.query(
-    `INSERT INTO platform_identity_project_memberships (client_id, github_id, role)
+    `INSERT INTO platform_identity_project_memberships (client_id, github_id, membership_kind)
      VALUES ($1, $2, 'pending')
      ON CONFLICT (client_id, github_id) DO NOTHING
-     RETURNING id, client_id, github_id, role`,
+     RETURNING id, client_id, github_id, membership_kind`,
     [clientId, githubId],
   );
   if (rows[0]) return { invited: true, row: rows[0] };
@@ -381,22 +403,22 @@ async function listPendingInvitesForAccount(githubId, { pool = defaultPool } = {
             c.name AS project_name, c.origin AS project_origin
        FROM platform_identity_project_memberships m
        LEFT JOIN platform_identity_sso_clients c ON c.client_id = m.client_id
-      WHERE m.github_id = $1 AND m.role = 'pending'
+      WHERE m.github_id = $1 AND m.membership_kind = 'pending'
       ORDER BY m.joined_at DESC`,
     [githubId],
   );
   return rows;
 }
 
-// Resolve a pending invite for (client, builder): accept → flip to 'builder' (the
+// Resolve a pending invite for (client, builder): accept → flip to 'member' (the
 // membership becomes real; the builder then signs into the project, whose own gate
 // still applies + whose check-in keeps it fresh); decline → delete the pending row.
 // Only ever touches a 'pending' row, so it can't downgrade or remove a real member.
 async function resolveInvite({ clientId, githubId, accept }, { pool = defaultPool } = {}) {
   if (accept) {
     const { rows } = await pool.query(
-      `UPDATE platform_identity_project_memberships SET role = 'builder', last_active = now()
-        WHERE client_id = $1 AND github_id = $2 AND role = 'pending'
+      `UPDATE platform_identity_project_memberships SET membership_kind = 'member', last_active = now()
+        WHERE client_id = $1 AND github_id = $2 AND membership_kind = 'pending'
         RETURNING id`,
       [clientId, githubId],
     );
@@ -404,7 +426,7 @@ async function resolveInvite({ clientId, githubId, accept }, { pool = defaultPoo
   }
   const { rowCount } = await pool.query(
     `DELETE FROM platform_identity_project_memberships
-      WHERE client_id = $1 AND github_id = $2 AND role = 'pending'`,
+      WHERE client_id = $1 AND github_id = $2 AND membership_kind = 'pending'`,
     [clientId, githubId],
   );
   return { resolved: rowCount > 0, accepted: false };
@@ -1072,7 +1094,9 @@ module.exports = {
   listAllProjects,
   setProjectFeatured,
   // memberships
-  MEMBERSHIP_ROLES,
+  MEMBERSHIP_KINDS,
+  membershipKindFromLegacy,
+  legacyRoleFromKind,
   upsertMembership,
   getMembership,
   listMembershipsForAccount,

package/modules/platform-identity/routes/my-projects.js

@@ -26,11 +26,11 @@ module.exports = function myProjectsRoutes() {
       const owned = [];
       const building = [];
       for (const m of rows) {
-        (m.role === 'owner' ? owned : building).push({
+        (m.membership_kind === 'owner' ? owned : building).push({
           client_id: m.client_id,
           name: m.project_name || m.project_origin || m.client_id,
           origin: m.project_origin || null,
-          role: m.role,
+          membership_kind: m.membership_kind,
           joined_at: m.joined_at,
           last_active: m.last_active,
         });