@bongos/core 1.19.238 → 1.19.239

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.238",
-  "core_contract": "1.19.238",
-  "source_commit": "f9cb966629cf3f3b846fac291d0a8d3c80ff190c",
+  "core_version": "1.19.239",
+  "core_contract": "1.19.239",
+  "source_commit": "92f85bc3527c85038cc818e47b4d503a340c8abb",
   "source_ref": "HEAD",
-  "built_at": "2026-08-18T18:46:41.252Z",
+  "built_at": "2026-08-18T19:09:51.272Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 311,
+    "docs_redacted": 312,
     "agent_docs_stubbed": 21,
-    "functional_verbatim": 1323,
+    "functional_verbatim": 1324,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 1655,
-  "tree_sha256": "0d58a08417103e42620b35bd5880c6abdd9770d6e0b0f2222c3f4161724649b8",
+  "file_count": 1657,
+  "tree_sha256": "ba99d83f49d20d229d51e1ca9cbb5232f744888d91ab1dbf43d5c092eade4cf9",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -367,7 +367,7 @@
     {
       "path": "clients/bongos-client/index.d.ts",
       "mode": "0000644",
-      "sha256": "14c4cc02b3965badc021489bb7dd0f80bb71c3cc57b2e1dc4dafa76d86128088"
+      "sha256": "2006b6d2f061c266c79390839bca228df59753db2e3919f49946db07682ee207"
     },
     {
       "path": "clients/bongos-client/index.mjs",
@@ -1364,20 +1364,25 @@
       "mode": "0000644",
       "sha256": "eb560b832629f708ad458f64c6a282bf55ae86c24626431d48d258e9ca0ac6d6"
     },
+    {
+      "path": "docs/adr/0177-goal-membership-kind.md",
+      "mode": "0000644",
+      "sha256": "0c81340c845250107cd195dadce2740b8324b7777a44011b02b488827193a4de"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "23c4e663f175ea1d6ee4ccbe041905c29814c50612af921c8b836f187e8d8355"
+      "sha256": "a8a408b4f15d3d4aca0d0e864bd14984a73e1801b74e36962a7cb8f4db04233d"
     },
     {
       "path": "docs/api-reference.md",
       "mode": "0000644",
-      "sha256": "c0a604b304ff9936d08998b2b4206e7ecad8ff668ec704b08161c5d79d0bc04c"
+      "sha256": "791e8f83d023e77d3faa2e3abf3ec9099f3ffa9236183aad5092ef0792e510cc"
     },
     {
       "path": "docs/api/openapi.json",
       "mode": "0000644",
-      "sha256": "be4bc7b6dd627fa7ea85e4a90a908588b81d6d5a5d4eb5a6f2c1858f155538f7"
+      "sha256": "901748f25425af336637858b48ec06ad0461d5d3dc2a6beaad8b2a6af0eb6161"
     },
     {
       "path": "docs/architecture.md",
@@ -1397,7 +1402,7 @@
     {
       "path": "docs/canonical-permissions.md",
       "mode": "0000644",
-      "sha256": "9cd97486edfff51a2175c2e758ce99cd217658caec857fddaca366db338822ad"
+      "sha256": "f566ac3244920461753cf01454b986a6b669fced8c87a440e3ce99298b0cddf5"
     },
     {
       "path": "docs/design-contract.md",
@@ -2369,6 +2374,11 @@
       "mode": "0000644",
       "sha256": "80ff025953285762f9fdfc8de813db3471ade4d02cb6db5a65f72fa13797a0fc"
     },
+    {
+      "path": "migrations/core_220_goal_members_membership_kind.sql",
+      "mode": "0000644",
+      "sha256": "e466f4222fdbfa04386003990efabe38f97f3b3c23ff174a622642daea5c096b"
+    },
     {
       "path": "modules/autonomy/CLAUDE.md",
       "mode": "0000644",
@@ -3257,12 +3267,12 @@
     {
       "path": "modules/hall-ui/public/goals-page.js",
       "mode": "0000644",
-      "sha256": "7e67230de060927c37ab8680e397c994896250c9e027e920ac997a61edbd14aa"
+      "sha256": "7ba31240f79d6c0b1a1db236af1b80ccbcef03ef826e48f8e07c7e55863b713a"
     },
     {
       "path": "modules/hall-ui/public/goals.css",
       "mode": "0000644",
-      "sha256": "407e8f21b95faa725d37c5336986d00af734db351bdaaf58aac350114c58f172"
+      "sha256": "615caa61dafdf77295d8e98d7e8c826b5e8b2e352f322c4486b4da5437629f07"
     },
     {
       "path": "modules/hall-ui/public/goals.html",
@@ -3607,7 +3617,7 @@
     {
       "path": "modules/lifecycle/db.js",
       "mode": "0000644",
-      "sha256": "3d88ff6be3d8378f0cf2826af92437dfafbeb589a677aa8928d9f325124eac5b"
+      "sha256": "ed948712d57d984684313afd0160b1838c8cde061f82bd62f31226e39b8df122"
     },
     {
       "path": "modules/lifecycle/done-when.js",
@@ -3627,7 +3637,7 @@
     {
       "path": "modules/lifecycle/goal-authz.js",
       "mode": "0000644",
-      "sha256": "0b01dc34fe88403fc111d484bb46438c9976a0a156603ae514ac565ddc6fda7f"
+      "sha256": "6280028c33fd0770514e753962e3a83ee2e3d47d6c9efdb67b9905b868c6db72"
     },
     {
       "path": "modules/lifecycle/goal-conflicts.js",
@@ -3692,7 +3702,7 @@
     {
       "path": "modules/lifecycle/routes/done-when.js",
       "mode": "0000644",
-      "sha256": "cec4dce0ab8d11b16de73dbee8adb782f47c12a32d203dd1ff726afd23caadf3"
+      "sha256": "c81e1474e237dfa2e3be5f80df56344cf7f9ca50dc7b84e45b2fec64509b900f"
     },
     {
       "path": "modules/lifecycle/routes/gate-approvals.js",
@@ -3702,7 +3712,7 @@
     {
       "path": "modules/lifecycle/routes/goals.js",
       "mode": "0000644",
-      "sha256": "8763c40223e27e9d6fc65ea76442e479301407ba70e77b9582c5ffcd09f17a11"
+      "sha256": "a986f861d919aec81e58683782ceae902e8590cb581710842113a04439984c16"
     },
     {
       "path": "modules/lifecycle/routes/lifecycle.js",
@@ -4332,12 +4342,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "365922d9572fec6980fdb2806b48d83fc6e0892d63d63e909b733c748af6b51c"
+      "sha256": "16010eb616ec78eb915efe81ecf81ad7b20339180ec495e40eb50b71bbac8b93"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "d3c6422211a2678deb380518daf5639b83b527f9b1935e3a1f5427589aa1e9c1"
+      "sha256": "8cf3937acd1926b71f0e9ee112fce2b1d23adfd5b58cb2a2e36926f90b2e714f"
     },
     {
       "path": "public-docs/index.html",
@@ -4962,7 +4972,7 @@
     {
       "path": "scripts/gds/fitness.js",
       "mode": "0000644",
-      "sha256": "00eacd557419ebdba21347e215ef0f197de8cd839f6af778bf90ff2901823a0e"
+      "sha256": "f5059d035746d8ea967e127e8421213efede43c9ae50c50403fc8772c487db76"
     },
     {
       "path": "scripts/gds/gate-review.js",
@@ -5952,7 +5962,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "d303e5511fe7ea46cd1b77a24f27406b59d3a393bfc7bf32b133bff2f85b5b24"
+      "sha256": "3995623cfa7376dbf8cbcf14b238c1fa1c919ad9d8da5af781b0f78dcb0bb8cc"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -6507,7 +6517,7 @@
     {
       "path": "tests/criterion_authoring_gate.mjs",
       "mode": "0000644",
-      "sha256": "dc3319f053701521a822a559879f14b5dbcb2a7fdaa0d403579d2bb66639e708"
+      "sha256": "970db80cf43dba855bf9bd331434add458ab16e719f06710487094a3a578ec53"
     },
     {
       "path": "tests/criterion_progress.mjs",
@@ -6832,7 +6842,7 @@
     {
       "path": "tests/goal_conflicts.mjs",
       "mode": "0000644",
-      "sha256": "91f169259abcec159195f24262e5772f5b5a1e5f157dc1b7c358c848ae83dac8"
+      "sha256": "1dd92e13f21ed2b029c64d07dcdd6c47aa4f59ce25e288786c4fa7245ba707c5"
     },
     {
       "path": "tests/goal_criterion_confirm_ui.mjs",
@@ -6845,19 +6855,19 @@
       "sha256": "27e5e881185511e0562dcfe36b8d6926b3222a9443893456c5f3a04089e40db6"
     },
     {
-      "path": "tests/goal_member_roles.mjs",
+      "path": "tests/goal_member_kinds.mjs",
       "mode": "0000644",
-      "sha256": "aabbcd18a3a911db04900609041145cd8170b88953733b4a7859ab210562970e"
+      "sha256": "3bb40fceeeeaa835db715b724ac73475be2a9ae166c740e9daa78eafc6957b03"
     },
     {
       "path": "tests/goal_membership_requests.mjs",
       "mode": "0000644",
-      "sha256": "59253dac0064ae1a9c7dd67ef87c1d32ff924d3c3dadf7cdb9553dbc76f88eb0"
+      "sha256": "bd29e6910bc741ddf18b4592eeeaeac02b45fb1dd321527a8f44203cd78bff18"
     },
     {
       "path": "tests/goal_routes.mjs",
       "mode": "0000644",
-      "sha256": "4fd3ec8ef855b0131e17931908e9aebf16238d45febdf0b8306e2908152e2655"
+      "sha256": "d7b40066dc12921fccb43e0176d5bf1a5d2797b2be64928719c2a598afee2773"
     },
     {
       "path": "tests/goal_scope_check.mjs",
@@ -6867,7 +6877,7 @@
     {
       "path": "tests/goal_tier.mjs",
       "mode": "0000644",
-      "sha256": "c2e37bb797c1e9af23970bfee7587b16cd13f1fac23c0e334a5ea0d362174491"
+      "sha256": "00539cd1b188def53c67aab06301971132fbbe0bcd47818c19763ed760aaccda"
     },
     {
       "path": "tests/goal_wall_proof.mjs",

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

@@ -122,7 +122,7 @@ export interface PatchBuildersIdBudgetResponse { builder: unknown }
 export interface PatchBuildersIdRankRequest { rank: string }
 export interface PatchBuildersIdRankResponse { builder: unknown; previous_rank: unknown; direction: unknown; credit_delta: unknown; broadcast: unknown }
 export interface PatchBuildersIdStatusRequest { status: "active" | "inactive"; reason?: string }
-export interface PatchGoalsIdMembersBuilderIdRequest { role: string }
+export interface PatchGoalsIdMembersBuilderIdRequest { membership_kind: string }
 export interface PatchGoalsIdMembersBuilderIdResponse { ok: boolean; member: unknown; changed: boolean }
 export interface PatchGoalsIdVisibilityRequest { visibility: string }
 export interface PatchGoalsIdVisibilityResponse { ok: boolean; goal: unknown }
@@ -213,7 +213,7 @@ export interface PostGoalsIdInvitationsRequest { note?: string; builder_id?: Str
 export interface PostGoalsIdInvitationsResponse { ok: boolean; request: unknown }
 export interface PostGoalsIdJoinResponse { ok: boolean; member: unknown }
 export interface PostGoalsIdLeaveResponse { ok: boolean }
-export interface PostGoalsIdMembersRequest { role?: string; builder_id?: StringifiableId }
+export interface PostGoalsIdMembersRequest { membership_kind?: string; builder_id?: StringifiableId }
 export interface PostGoalsIdMembersResponse { ok: boolean; member: unknown }
 export interface PostGoalsIdReopenResponse { ok: boolean; goal: unknown }
 export interface PostGoalsIdRequestsReqIdRespondRequest { action: string }

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

@@ -0,0 +1,96 @@
+# 0177 — A goal membership is a `membership_kind`, and the rename ships expand-then-contract
+
+- **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)
+- **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)
+
+## Context
+
+ADR 0174 reserved the word **role** for the three crafts — Artist, Ideator, Builder — and renamed the
+government's use of it to **rank**. Its fitness rule (goal 1000068 R07) enforces the reservation on the
+**government surface only**, and that scoping is deliberate: `builders.system_role` is a core
+machine-identity column, and Discord's API owns its own "role" noun. A repo-wide ban would be wrong.
+
+Sweeping the docs for R08 turned up a **fourth, independent use** that nobody had catalogued:
+**goal membership**. `goal_members.role` holds `'lead' | 'member'` — created by `160_goal_tier.sql`,
+read as `actorMembership.role === 'lead'` in `modules/lifecycle/goal-authz.js` and in the PATCH
+`/goals/:id/members/:builderId` gate, rendered by the hall's Goals page as "Manager"/"Member". It sits
+outside R07's surface, so the rule is silent on it — the rule working as designed, and also the reason
+this use would have sat there indefinitely.
+
+Four meanings, for the record: (1) government ranks — renamed by ADR 0174; (2) the three crafts — the
+reserved meaning; (3) Discord server roles — out of scope, Discord's word; (4) goal membership — this.
+A **fifth** turned up while doing the work and is deliberately NOT in scope here:
+`project_memberships.role` (`'owner' | 'builder' | 'visitor' | 'pending'` — whose `builder` value
+collides with a craft name as well). It is filed as its own task; this ADR is the worked example for it.
+
+Two things make this small change need a decision record. The value is on the **authorization** path
+(the MANAGER predicate), and the column is **live**.
+
+## Decision
+
+**1. The noun is `membership_kind`; the values are unchanged.** `goal_members.membership_kind` holds
+`'lead' | 'member'`. The values were never the problem — the noun was. `rank` would be wrong (a
+membership is not a position on the ladder), and `position` would be worse: ADR 0174 uses "position"
+as the *prose* word for what a rank is, so borrowing it here recreates exactly the qualifier collision
+("rank-role") that ADR 0174 diagnosed.
+
+**A boolean `is_lead` was seriously considered and rejected.** It removes the word rather than trading
+it, and there are exactly two values with one default — the task itself argued for it. Two things
+decided against: a text rename preserves the copied `CHECK` and stays a *reversible* schema change on a
+live authz column, whereas `ADD boolean; UPDATE; DROP text` is data-destructive; and the values are how
+every consumer already reads (`'lead'` renders "Manager"), so the boolean would have changed the shape
+of every call site instead of one identifier. The extensibility argument is secondary but real: a third
+membership (reviewer, observer) is a row-value under this shape and a migration under a boolean.
+
+**2. The migration is EXPAND-THEN-CONTRACT, not `RENAME COLUMN`.** `bongos upgrade` auto-rollback
+reverts the **code pin** and not the DB. A bare rename plus a rolled-back deploy would leave the
+previous release querying a column that no longer exists — every goal-membership check erroring, on the
+authz path. `tests/migrations_forward_safe.mjs` exists to catch precisely this, and it would have caught
+it here. So:
+
+- **Step 1 (`<redacted>.sql`, this task)** — ADD `membership_kind`, backfill
+  it from `role`, copy the `CHECK`, and keep the two columns in lockstep with a **BEFORE INSERT OR
+  UPDATE trigger** whose direction is decided by which side changed. Both names therefore work for one
+  release: new code writes `membership_kind`; the historical `lifecycle_001` seed and any older release
+  (including the one a rollback restores) write `role` and the new column follows. Forward-safe, no
+  pragma, nothing to remember in application code.
+- **No `SET NOT NULL` in step 1.** The trigger fills the column on every write (a BEFORE ROW trigger
+  runs ahead of constraint checks), but a static NOT NULL on a column the previous release has never
+  heard of is the shape the forward-safety gate flags, and it would flag it rightly. NOT NULL arrives
+  with step 2.
+- **Step 2 (its own task)** — DROP `role` and the trigger, once the release carrying step 1 is behind
+  the live pin. That step IS forward-unsafe, ships with the `-- forward-unsafe:` pragma, a fresh
+  backup, and its own deploy window — the `government_001` precedent.
+
+**3. The API field renames with the column, with NO alias.** `POST /goals/:id/members` and `PATCH
+/goals/:id/members/:builderId` take `membership_kind`; the refusals become `bad_membership_kind`,
+`owner_membership_fixed`, `membership_change_conflict`, `membership_change_failed`. ADR 0174's own
+Lineage records the lesson that a time-boxed shim outlives its release, so there is no `role` alias to
+outlive: the rename is a contract change, and `tests/goal_member_kinds.mjs` pins that the old field name
+buys nothing. Every known consumer (the hall's Goals page, the generated typed client) ships in the same
+release; the generated API docs regenerate with it.
+
+**4. The reservation gets a SECOND narrow wall, not a widened first one.**
+`<redacted>` (`scripts/gds/fitness.js`) scans the goal-membership surface — the
+routes and pure gate that decide it, the hall page that renders it — plus, line-scoped, the lines of
+`modules/lifecycle/db.js` that name `goal_members`. The line scoping is the point: that file is 5k+
+lines and legitimately says "role" about ranks and `builders.system_role`, so scanning it whole would
+need an allowlist longer than the rule, while scanning the lines that name the table catches the only
+regression available — a membership query reaching for the old column — with no false positives. The
+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.
+
+## Consequences
+
+- The word `role` no longer names a goal membership in the API, the hall, or the docs, and in the DB it
+  survives only as the step-1 compatibility column, on a trigger, for one release.
+- **The two halves must ship in one release** — they do: the column, the trigger, and every reader land
+  in one commit, so no deploy sees new code against an old schema.
+- A rollback of that deploy is safe by construction, which is the whole reason for the trigger. It is
+  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.

package/docs/adr/README.md

@@ -250,5 +250,6 @@ This keeps the decision history honest and traceable.
 | 0174 | [**Governance is renamed government, its positions are ranks, and "role" is reserved for the three crafts** ([task 1003002](https://cloudbongos.com/builders#/task/1003002), R01 of goal 1000068). Owner directive, 2026-08-16. The word **role** named two unrelated things: the permission system's ladder tiers (`governance_roles`, the "rank-roles") and the three crafts (`tasks.discipline` = engineer/artist/ideator) — and goal 1000066 was actively claiming it for the crafts (`three-roles-only`, `users-hold-roles`), putting the two on a collision course. Resolved at full depth rather than as a label pass, because a labels-only fix leaves the UI and the code disagreeing, which is the condition that produced the collision. `modules/governance/` → `modules/government/`; the kernel module key, the config files, `/api/bongos/governance/*` → `/government/*`, and the permission keys `governance.manage` → `government.manage` (~50 sites) + `page.view.governance` → `page.view.government`. **The entity IS the rank — no second noun**: `governance_roles` → `government_ranks`, `role_key` → `rank_key`, `rank-roles.js` → `ranks.js`; "position" stays prose-only, since introducing it as a code term would recreate the qualifier problem "rank-role" already demonstrates. The cross-module kernel port `governance.roleSync` → `government.rankSync` must land atomically across its provider and both consumers (`modules/lifecycle/db.js`, `src/bongos/db.js`) because it is a transaction participant on the rank-write path. Hand-composed bundles stay in the one table as **custom ranks** — the owner's call over splitting them into a separate "appointments" concept, with the objection recorded (a custom bundle is not a ladder position, and ADR 0172 §4 already treats the two kinds as different). Enforced by a `fitness.js` rule, allowlist shipped with reasons. **Discord's server roles keep the word** — that noun belongs to Discord's API. Amends ADR 0151 + ADR 0172 (the editable-rank-roles one) in **vocabulary only**; ladder slugs, `builders.rank`, `requireRank`, and every floor/grant/assignment semantic are untouched. Rejected: renaming the ladder slugs (turns a bounded rename into a trust-boundary migration), a permanent compat shim (both vocabularies stay correct forever).](<redacted>.md) | government / permissions |
 | 0175 | [**The Board Room: Full Idea ratification is the first upward-pointing gate** ([task 1003014](https://cloudbongos.com/builders#/task/1003014), R01 of goal 1000069). Every existing gate points DOWN the rank ladder; the owner asked for one that could slow THEM down — *"otherwise I can just ship and build as I want, finding loopholes."* The board's subjects are exactly **two**, both rare by construction: a **Full Idea** and a **change to the constitution itself** (`subject_type` from day one). Because the vote gates no build path, the **ADR 0162 tension dissolves rather than being compromised** — nothing self-executes because there is nothing downstream to execute; ratification confers legitimacy and does NOT auto-create the goal. A vote is a **timed sitting, not a quorum**: absent members are *nulled* (dropped from the denominator, never counted as a no), so the clock is the deadlock exit and no shotgun/fork-with-treasury clause is needed at this scale — default 90 minutes, closing early on full turnout, and yes, a short window means whoever is awake governs (the owner's explicit intent). **Consent, not majority**: silence is consent, one reasoned objection returns the idea, and a zero-vote close PASSES. A rejection must carry free text **plus one of the five Full Idea sections** — which is what **forces the hall to be the voting surface**, since a Discord reaction could only ever be feedback-free; Discord is therefore an outbound notification mirror that casts nothing, and its own mobile app is the mobile push (no mobile surface is built). The completeness grade is the **floor** (a window opens automatically on pass), the vote is the **merit**; concurrent windows are normal. Who governs is **configuration** — day one is monarchy expressed as config on the real machinery, never a separate code path — and **amendments are decided under whatever rule is currently in force**, so flipping out of monarchy is a legal monarchy act and no bootstrap exception is needed. Open ballot; an author may never vote on their own item. Franchise derives from **rank, not role**, and that is forced: `PATCH /me/disciplines` is deliberately ungated, so a craft-scoped chamber would be one-request privilege escalation. Unblocks goal 1000067 / IC5, which consumes the pass event and *"invents no parallel vote"*. Rejected: quadratic vote weighting and the attribution-economy knobs (γ, τ, the 30% stack cap — v1's franchise is not credit-weighted at all), eternity clauses, and any legal-entity integration.](<redacted>.md) | government / ideas / governance |
 | 0176 | [**Private-repo standup: a per-repo read-only deploy key, minted with the owner's token** ([task 1002735](https://cloudbongos.com/builders#/task/1002735), goal 1000032; walk finding N4, seen live on `mercury` 2026-08-17). A standalone instance's repo is cloned/pushed once with the owner's `repo`-scoped token (ADR 0155), but the durable `origin` rides the shared SSH deploy alias — which GitHub answers "Repository not found" for a private repo it isn't registered on, so every private standup failed at the recurring `git pull --ff-only origin main`, **token or not**. Fix: when the target repo answers *private* to the owner's stored token, provisioning mints the instance its OWN ed25519 deploy key beside the checkout (`.git/cloudbongos-deploy-key` — untracked, survives `git reset --hard`, dies with the checkout), registers it on the repo **read-only** as `cloudbongos-deploy-<slug>` (idempotent by title; a stale same-title key is replaced, never duplicated), then wires the CHECKOUT: `origin` re-pointed at plain `git@github.com` and `core.sshCommand` pinned to the key with `-F /dev/null` so no `~/.ssh/config` identity can shadow it. Public repos take the unchanged shared-alias path; pushes keep preferring the owner-token HTTPS URL (task 1002317), which is why read-only suffices; teardown best-effort revokes by title. Rejected: **GitHub App installation tokens** (hourly expiry means every unattended pull needs a minting sidecar or a hub round-trip) and **registering the shared platform key on the repo** (one shared secret granting the whole platform durable access to private code; per-repo keys keep the blast radius to one repo and are visible to the owner in their own repo settings). Follow-ups: the manage page's flip-to-private stays refused until already-provisioned instances get the same wiring, and builder dev boxes of a private-repo project need their own leg.](<redacted>.md) | provisioning / security |
+| 0177 | [**A goal membership is a `membership_kind`, and the rename ships expand-then-contract** ([task 1003013](https://cloudbongos.com/builders#/task/1003013), goal 1000068). ADR 0174 reserved `role` for the three crafts and enforced it on the GOVERNMENT surface only — by design, since `builders.system_role` and Discord's own noun are legitimate. That left a **fourth** use uncatalogued: `goal_members.role` (`'lead' | 'member'`), the MANAGER predicate behind goal authorization. Renamed to **`membership_kind`** — values unchanged, because the noun was the problem; `rank` is wrong (not a ladder position) and `position` is worse (ADR 0174 uses it as the prose word for a rank, recreating the "rank-role" qualifier collision). A boolean `is_lead` was seriously considered and rejected: the text rename keeps the copied CHECK and stays a reversible change on a live authz column, where `ADD boolean; UPDATE; DROP text` is data-destructive. The migration is **expand-then-contract, never `RENAME COLUMN`** — auto-rollback reverts the code pin and NOT the DB, so `core_220` ADDs the column and keeps the pair in lockstep with a BEFORE trigger (direction decided by which side changed), and a later task DROPs the old column with the `-- forward-unsafe` pragma, a backup, and its own window; no `SET NOT NULL` in step 1, because a static NOT NULL on a column the previous release never heard of is what the forward-safety gate rightly flags. The API field renames with it and carries **no `role` alias** (ADR 0174's Lineage lesson: a time-boxed shim outlives its release), pinned by the test of its absence. The reservation gains a **second narrow wall** rather than a widened first one — line-scoped inside the 5k-line `db.js` to the lines that name `goal_members`, so no allowlist is needed. A **fifth** use (`project_memberships.role`) is catalogued and filed, with this as its pattern.](<redacted>.md) | naming / lifecycle |
 
 > ⚠️ **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/docs/api/openapi.json

@@ -4515,7 +4515,7 @@
           "goals"
         ],
         "summary": "PATCH /goals/:id/members/:builderId",
-        "description": "PATCH /goals/:id/members/:builderId — role management by the goal's own authority (task 1735): the owner, a manager, or an Archon promotes member→lead(manager); ONLY the owner (or an Archon) demotes; the owner's row is never demotable. The decision is the pure ordered gate above (authorizeMemberRoleChange); the DB write re-asserts the owner-demotion guard atomically (setGoalMemberRole), so a race cannot demote an owner. rank: any-builder (requireBuilder) + the in-handler (owner | manager | Archon) gate — like the authoring keystone, the wall is in-handler, NOT a rank middleware. Pinned in route-rank-check.MODULE_EXPECTED_RANKS['lifecycle'].\n\n**Rank:** `any-builder` — Any authenticated builder (row-level ownership enforced in-handler).",
+        "description": "PATCH /goals/:id/members/:builderId — membership management by the goal's own authority (task 1735): the owner, a manager, or an Archon promotes member→lead(manager); ONLY the owner (or an Archon) demotes; the owner's row is never demotable. The body field is `membership_kind` (task 1003013 — ADR 0174 reserves `role` for the three crafts). The decision is the pure ordered gate above (authorizeMembershipKindChange); the DB write re-asserts the owner-demotion guard atomically (setGoalMembershipKind), so a race cannot demote an owner. rank: any-builder (requireBuilder) + the in-handler (owner | manager | Archon) gate — like the authoring keystone, the wall is in-handler, NOT a rank middleware. Pinned in route-rank-check.MODULE_EXPECTED_RANKS['lifecycle'].\n\n**Rank:** `any-builder` — Any authenticated builder (row-level ownership enforced in-handler).",
         "x-rank": "any-builder",
         "x-source": "modules/lifecycle/routes/goals.js",
         "parameters": [
@@ -12819,7 +12819,7 @@
           "versions"
         ],
         "summary": "POST /versions/:id/done-when",
-        "description": "Auth (Metic+, then the goal's own authority): create a done-when criterion at RUNTIME. ADR 0105 moved scope-truth seeds (versions/goals/criteria) out of the normal migration path, so a brand-new criterion on a RUNNING instance can no longer be added by a plain migration (migrations/instance/ applies only under the owner opt-in GDS_APPLY_INSTANCE_SEEDS=1, a DR step). This is the vector a planning session uses to add a criterion to a live version WITHOUT a droplet migrate. ADR 0154 — authority over a GOAL's criteria follows GOAL OWNERSHIP, not global rank. A Metic who may create the goal (POST /goals) and author the tasks under it (POST /tasks, ADR 0090) may now write the criteria those tasks gate — but only inside a goal they own or manage. Deliberately NOT a flat re-rank: - An unsatisfied criterion permanently blocks version close (version-close.js counts satisfied === total per VERSION, regardless of goal) and goal auto-achieve (db.achieveGoalIfComplete). There is NO delete route, so it cannot be undone via the API — the same backward ratchet as unsatisfy, which stays Archon. - So a non-Archon must name a goal_id (version-level criteria stay Archon), must be that goal's OWNER or MANAGER (isGoalOwnerOrManager — the same predicate behind visibility/invite/role management), and the goal must be open on a planning/building version. That bounds the blast radius to a workspace they already hold. An unauthorized caller gets an honest 403 goal_not_yours (task 1002614 — goal reads are open to any builder, so there is no existence oracle for a mask to protect). Pinned in route-rank-check.MODULE_EXPECTED_RANKS. rank: metic+archon — criterion create, walled by goal ownership (ADR 0154).\n\n**Rank:** `metic+archon` — Metic or Archon rank (review/triage powers).\n\n**Permissions:** `criterion.create` (all required).",
+        "description": "Auth (Metic+, then the goal's own authority): create a done-when criterion at RUNTIME. ADR 0105 moved scope-truth seeds (versions/goals/criteria) out of the normal migration path, so a brand-new criterion on a RUNNING instance can no longer be added by a plain migration (migrations/instance/ applies only under the owner opt-in GDS_APPLY_INSTANCE_SEEDS=1, a DR step). This is the vector a planning session uses to add a criterion to a live version WITHOUT a droplet migrate. ADR 0154 — authority over a GOAL's criteria follows GOAL OWNERSHIP, not global rank. A Metic who may create the goal (POST /goals) and author the tasks under it (POST /tasks, ADR 0090) may now write the criteria those tasks gate — but only inside a goal they own or manage. Deliberately NOT a flat re-rank: - An unsatisfied criterion permanently blocks version close (version-close.js counts satisfied === total per VERSION, regardless of goal) and goal auto-achieve (db.achieveGoalIfComplete). There is NO delete route, so it cannot be undone via the API — the same backward ratchet as unsatisfy, which stays Archon. - So a non-Archon must name a goal_id (version-level criteria stay Archon), must be that goal's OWNER or MANAGER (isGoalOwnerOrManager — the same predicate behind visibility/invite/membership management), and the goal must be open on a planning/building version. That bounds the blast radius to a workspace they already hold. An unauthorized caller gets an honest 403 goal_not_yours (task 1002614 — goal reads are open to any builder, so there is no existence oracle for a mask to protect). Pinned in route-rank-check.MODULE_EXPECTED_RANKS. rank: metic+archon — criterion create, walled by goal ownership (ADR 0154).\n\n**Rank:** `metic+archon` — Metic or Archon rank (review/triage powers).\n\n**Permissions:** `criterion.create` (all required).",
         "x-rank": "metic+archon",
         "x-source": "modules/lifecycle/routes/done-when.js",
         "x-permissions": [
@@ -14447,12 +14447,12 @@
       "PatchGoalsIdMembersBuilderIdRequest": {
         "type": "object",
         "properties": {
-          "role": {
+          "membership_kind": {
             "type": "string"
           }
         },
         "required": [
-          "role"
+          "membership_kind"
         ],
         "additionalProperties": false
       },
@@ -15866,7 +15866,7 @@
       "PostGoalsIdMembersRequest": {
         "type": "object",
         "properties": {
-          "role": {
+          "membership_kind": {
             "type": "string"
           },
           "builder_id": {

package/docs/api-reference.md

@@ -201,8 +201,8 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/<redacted>
 | POST | `/api/bongos/goals/:id/invitations/:reqId/respond` | `any-builder` | `action` | POST /goals/:id/invitations/:reqId/respond { action: accept\|decline } — ONLY the invited builder resolves their OWN pending invite (task … |
 | POST | `/api/bongos/goals/:id/join` | `any-builder` | — | POST /goals/:id/join — join an open goal. |
 | POST | `/api/bongos/goals/:id/leave` | `any-builder` | — | POST /goals/:id/leave — leave a goal you're in. |
-| POST | `/api/bongos/goals/:id/members` | `any-builder` | `role`, `builder_id` | POST /goals/:id/members — the goal's own authority (owner \| manager \| Archon) invites a builder to the goal (task 1762: widened from Arch… |
-| PATCH | `/api/bongos/goals/:id/members/:builderId` | `any-builder` | `role` | PATCH /goals/:id/members/:builderId — role management by the goal's own authority (task 1735): the owner, a manager, or an Archon promote… |
+| POST | `/api/bongos/goals/:id/members` | `any-builder` | `membership_kind`, `builder_id` | POST /goals/:id/members — the goal's own authority (owner \| manager \| Archon) invites a builder to the goal (task 1762: widened from Arch… |
+| PATCH | `/api/bongos/goals/:id/members/:builderId` | `any-builder` | `membership_kind` | PATCH /goals/:id/members/:builderId — membership management by the goal's own authority (task 1735): the owner, a manager, or an Archon p… |
 | POST | `/api/bongos/goals/:id/reopen` | `metic+archon` | — | POST /goals/:id/reopen — bring an archived goal back to open (ADR 0086 §6 / BV1.R64). |
 | GET | `/api/bongos/goals/:id/requests` | `any-builder` | — | GET /goals/:id/requests — the goal's own pending invite/join-request queue (task 1953): every pending row on THIS goal, both kinds — outs… |
 | POST | `/api/bongos/goals/:id/requests` | `any-builder` | `note` | POST /goals/:id/requests — a builder asks to join a (private or protected) goal (task 1952 / ADR 0112). |

package/docs/canonical-permissions.md

@@ -185,7 +185,9 @@ or missing ranks fail closed.
   [ADR 0154](adr/<redacted>.md), also `POST /api/gds/versions/:id/done-when`
   (criterion **create**) — but walled by goal ownership, not by rank alone: a non-Archon must name a
   `goal_id`, on an open (`planning`/`building`) version, in an `open` goal they **own or manage** (the same
-  `authorizeGoalManagement` wall as goal visibility/invites/roles). Version-level criteria stay Archon;
+  `authorizeGoalManagement` wall as goal visibility/invites/memberships — the membership column is
+  `goal_members.membership_kind` ('lead' | 'member') since task 1003013, never `role`, which
+  [ADR 0174](adr/<redacted>.md) reserves for the three crafts). Version-level criteria stay Archon;
   `done-when/:id/unsatisfy` moved here in [ADR 0157](adr/<redacted>.md). The floor here is
   `metic`, so **`thetes` does NOT pass these** — it sits below `metic` on the ladder and inherits none
   of its grants (ADR 0034); `archon` and the divine tiers above it do.

package/migrations/core_220_goal_members_membership_kind.sql

@@ -0,0 +1,100 @@
+-- core_220_goal_members_membership_kind.sql — the FOURTH "role" leaves the schema
+-- (task 1003013; ADR 0174 reserves `role` for the three crafts, ADR 0177 records
+-- this two-step).
+--
+-- `goal_members.role` holds 'lead' | 'member' — a per-goal position, unrelated to
+-- the rank ladder and unrelated to the three crafts. ADR 0174 reserves the word
+-- `role` for Artist / Ideator / Builder, so this column is renamed to
+-- `membership_kind` ('lead' | 'member' unchanged: the values were never the
+-- problem, the noun was).
+--
+-- ── WHY EXPAND-THEN-CONTRACT AND NOT `RENAME COLUMN` ────────────────────────
+-- This column gates goal-membership AUTHORIZATION (goal-authz.js's MANAGER
+-- predicate). `bongos upgrade` auto-rollback reverts the CODE PIN BUT NOT THE DB,
+-- so a bare RENAME plus a rolled-back deploy would leave the previous release
+-- querying a column that no longer exists — every membership check erroring on a
+-- live authz path. That is exactly what tests/migrations_forward_safe.mjs exists
+-- to prevent, and it is why this migration is forward-SAFE with no pragma:
+--
+--   STEP 1 (here)  ADD the new column, backfill it, and keep the two in lockstep
+--                  with a trigger. BOTH names work: new code writes
+--                  membership_kind, any older code still writing `role` stays
+--                  correct, and a rollback lands on a schema it fully understands.
+--   STEP 2 (later) DROP `role` + the trigger, once every released version that
+--                  reads it is behind the live pin. That step IS forward-unsafe
+--                  and ships with the pragma, a backup, and its own deploy window.
+--
+-- Idempotent: safe to re-run.
+
+BEGIN;
+
+-- 1. The new noun.
+--
+--    NO `SET NOT NULL` HERE, DELIBERATELY. The trigger below fills the column on
+--    every write (a BEFORE ROW trigger runs ahead of constraint checks, so even an
+--    older release inserting only `role` lands a complete row) — but a static
+--    NOT NULL on a column the previous release has never heard of is exactly the
+--    shape tests/migrations_forward_safe.mjs flags, and it would be flagged
+--    RIGHTLY: the guarantee would then rest on the trigger surviving. The trigger
+--    IS the enforcement for one release; NOT NULL arrives in step 2, when `role`
+--    is dropped and nothing writes the old name any more.
+ALTER TABLE goal_members
+  ADD COLUMN IF NOT EXISTS membership_kind text;
+
+UPDATE goal_members SET membership_kind = role WHERE membership_kind IS NULL;
+
+ALTER TABLE goal_members
+  ALTER COLUMN membership_kind SET DEFAULT 'member';
+
+DO $$
+BEGIN
+  -- The same two values, the same CHECK — a copied constraint, not a widened one.
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint
+     WHERE conrelid = 'goal_members'::regclass AND conname = 'goal_members_membership_kind_check'
+  ) THEN
+    ALTER TABLE goal_members
+      ADD CONSTRAINT goal_members_membership_kind_check
+      CHECK (membership_kind IN ('lead', 'member'));
+  END IF;
+END $$;
+
+-- 2. The lockstep. A BEFORE trigger, so both columns are written by the same
+--    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
+--    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.
+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
+      NEW.membership_kind := COALESCE(NEW.role, 'member');
+    END IF;
+  ELSE
+    IF NEW.membership_kind IS DISTINCT FROM OLD.membership_kind THEN
+      NEW.role := NEW.membership_kind;
+    ELSIF NEW.role IS DISTINCT FROM OLD.role THEN
+      NEW.membership_kind := NEW.role;
+    END IF;
+  END IF;
+  RETURN NEW;
+END;
+$$ LANGUAGE plpgsql;
+
+DROP TRIGGER IF EXISTS goal_members_membership_kind_lockstep ON goal_members;
+CREATE TRIGGER goal_members_membership_kind_lockstep
+  BEFORE INSERT OR UPDATE ON goal_members
+  FOR EACH ROW EXECUTE FUNCTION goal_members_membership_kind_lockstep();
+
+INSERT INTO schema_migrations (version) VALUES ('core_220_goal_members_membership_kind')
+  ON CONFLICT DO NOTHING;
+
+COMMIT;