@bongos/core 1.19.374 → 1.19.376

package/docs/adr/0194-joinability-one-door-decision.md

@@ -0,0 +1,42 @@
+# ADR 0194 — A project's membership door is one decision, answered the same way everywhere a stranger meets it
+
+- **Status:** accepted
+- **Date:** 2026-08-25
+- **Task:** [task 1003044](https://cloudbongos.com/builders#/task/1003044) (goal 1000058 — the non-cloudbongos project lifecycle)
+- **Relates to:** ADR 0050 (invite-gated by default; the `OPEN_XENOS_ENROLLMENT` escape hatch), ADR 0190 (the settings channel: `brand.project` as the read-back), ADR 0192 (the platform-visibility member door — this setting's sibling), ADR 0116 (the error envelope), ADR 0083 (the module doorway), ADR 0161 (a MINOR is a human edit), task 1003040 (the settings row), task 1003043 (the manage-page section shape)
+
+## Context
+
+The owner decided on 2026-08-16 that a project chooses how people join it — **open** (whoever signs in is in), **apply** (a stranger files an access request, an Archon invites; today's behaviour), or **invite only** (no applications; only an Archon's invite admits). Task 1003040 stored the choice on the platform's settings row, 1003139/1003140 pushed it into the instance's environment, and `branding().project.joinability` resolved it — enforced by nothing, and the manage page said so.
+
+Admission on an instance is decided in one place already: `firstTimeAdmissionBlocked` (SR-19 — one pure decision both sign-in flows call, so they cannot drift), fed by `openEnrollmentEnabled()`, which read only the legacy env flag. Four sign-in paths call it (the GitHub web and device flows, and their federated twins). Beside it sit the onboarding module's public `POST /access-requests` (the one unauthenticated write), the Archon's `PATCH … invited`, the hall's landing page with its request form, the web sign-in's 403 page, the CLI's stranger path, and the hub's join relay — each of which tells a stranger what to do next.
+
+## Decision
+
+1. **One reader, and open enrolment follows it.** `joinabilityMode()` (`src/bongos/auth-admission.js`) is the project's effective door: `branding().project.joinability` when it says `open` or `invite_only`; otherwise `apply` — **unless** the legacy `OPEN_XENOS_ENROLLMENT` flag is set, which still turns an *apply* project into an open one. `openEnrollmentEnabled()` becomes `joinabilityMode() === 'open'`, so the four sign-in call sites, `webAdmissionStatus`, and the manifest's `admission.policy` follow without being touched. Why the flag keeps its power on `apply` only: a self-hosted instance that set it (ADR 0050) must keep its open door across the upgrade — the neutral pack defaults to `apply`, so "flag ignored" would have silently closed those doors; and an explicit `invite_only` is the stricter, newer choice, which the flag must not reopen. Why the flag is not folded into `branding()`: the pack is memoized for the process while the flag is read per call (and toggled by the existing tests), and the manifest's `brand.project.joinability` must stay the *pushed* value the hub reads back. The one case where the two disagree — a self-hosted instance carrying the flag — is never platform-managed: its hall landing offers the request form (the injected pack says `apply`), and the form collapses into "no request needed — sign in" on the door's own 409; an owner who wants the hall to say so up front sets `<PREFIX>_JOINABILITY=open`. The flag is kept only so nothing changes on upgrade.
+
+2. **An unreadable pack, or a value this core cannot read, fails closed: `invite_only`.** When the door's policy is unknown — the pack will not load, or it says `invite-only` with a hyphen, or a truncated write — the widest door is never the fallback, the same rule the visibility gate applies (ADR 0192 §2). Only an absent value or `apply` reaches the legacy-flag branch. Logged through the kernel logger, an unknown value once per process.
+
+3. **The public `POST /access-requests` answers the door first** — before validating the body and before any lookup. On `invite_only` it refuses `403 invite_only`; on `open` it refuses `409 open_enrollment` ("no request needed — sign in"). Both are plain sentences in the ADR 0116 envelope. Answering first costs no query, reveals nothing about who already exists (the account-existence oracle ADR 0192 §3 deferred does not widen), and keeps the refusal DB-free — which is what lets the real booted app prove it. A non-2xx for `open` rather than a friendly 200: an older `bongos login` would otherwise print "✓ Requested access" and wait thirty minutes for an approval that never comes; a refusal it does not recognise prints its status and stops, which is honest.
+
+4. **An Archon's invite is the same row the gate already reads.** `POST /access-requests/invite { github_login }` (rank archon — the gate that resolves a request) writes an `access_requests` row at `'invited'` — resolving a pending one in place, or inserting one. `hasInvitedAccessRequest` admits it at sign-in with nothing new consulted. No second table, no token, no expiry: an invite here is exactly what the `PATCH … invited` has meant since ADR 0050, created before the request instead of after. It reaches the hall as an "Invite by GitHub username" form in the Watch page's Access-requests section, whose one-line explanation names the door the project runs.
+
+5. **The door is said in every place a stranger meets it, in the project's own words.** The hall landing renders one door per mode from the pack the server injects (`window.__BRANDING__.project` — no fetch, no flash); its request form collapses into "sign in" on the door's own refusal codes. The web sign-in's 403 page names the invite-only door and the one way in instead of sending a stranger to a form the project refuses. The CLI says invite-only and stops instead of collecting a username. The hub's join relay names the door in the hub's own words (`joinRelayOutcome`, pure) — a registered project is trusted to build, not to write prose into the platform's UI — rather than painting a refusal as "requested", or as "could not be reached", which a 403 used to become; a 401 (the project's member-only door, ADR 0192, refusing the ask itself) is said as such, and the hub's join box keeps the typed address and does not repaint as if a request went out. Someone who applied before a project switched to invite-only stays in the queue — the Archon can still invite or dismiss them from the Watch page, and the manage fold says so.
+
+6. **The manifest's `admission.policy` stays binary.** It is a pinned public field derived from `openEnrollmentEnabled()`, so it agrees with the new decision for free (`open` → `open`, else `invite-only`, which is true of both `apply` and `invite_only`: you need an invite). The three-valued truth is `brand.project.joinability`, which the hub's "runs as" line already reads.
+
+7. **`joinabilityMode` joins the doorway — and rides the next CI patch, not a hand-bumped 1.20.0.** The onboarding module must refuse with the *same* decision the sign-in gate makes; re-deriving it from `api.branding()` would copy the flag rule and the fail-closed default into a second place — the drift SR-19 exists to prevent. An added export is a statement about the doorway surface, which ADR 0161 §2 reserves as a human MINOR (the 1.19.0 precedent). This task tried exactly that, and the publish lane refused it: `tests/bump_version.mjs`'s LIVE test asserts HEAD's version is one the lane's own carrier commits announced, so a branch declaring `1.20.0` fails the `unit` check by construction (1.19.0 was "bumped and never packaged" for the same reason). Landing hands-free on CI (ADR 0162) outranks expressing the MINOR in the number: the version stays the carrier's, the changelog says why, `modules/onboarding/module.json` floors at `^1.19.374`, and the contradiction between ADR 0161 §2's promise and the lane's test is filed as an idea for the owner.
+
+8. **The hub's section clones `#mVisibility`'s shape rather than extracting a factory.** Task 1003043's tests pin that block's text function by function; two settings sharing `visPushOpen()` is tolerable duplication. A third setting is the point at which a factory — and one manifest read serving every key — pays for itself.
+
+## What was deliberately not built
+
+- No change to the Discord `#member-approvals` broadcast (an invite-only project simply never posts one, because nothing is filed).
+- No widening of `admission.policy`; no projection of the manifest (idea 1000845); no throttling of the admission-status lookup (ADR 0192 §3).
+- No invite expiry, revocation, or token. An Archon can dismiss nothing they created here — the row is the audit trail, as it is for a resolved request.
+
+## Consequences
+
+- A project's door is enforced server-side wherever admission is decided, from one reader, and every surface that speaks to a stranger says which door it is.
+- The hall's `postJSON` now reads the envelope (`error.code` / `error.message`); its already-a-member branch had silently never fired since the envelope landed, and the new refusal codes needed the same read.
+- A self-hosted instance on the legacy flag is unchanged. A platform project defaults to `apply`, unchanged. Only a pushed `open` or `invite_only` changes behaviour, and only after the restart the runner performs (ADR 0190).

package/docs/adr/README.md

@@ -271,5 +271,6 @@ This keeps the decision history honest and traceable.
 | 0192 | [**A gated project refuses strangers at the app's front door, and the hub reads what the project runs from the project itself** ([task 1003043](https://cloudbongos.com/builders#/task/1003043), goal 1000058). Task 1003040 gave every project a `platform_visibility` setting and 1003139/1003140 carried it into the instance's `branding().project.platformVisibility` — resolved, enforced by nothing. Decision: ONE app-level middleware (`src/bongos/platform-visibility-gate.js`), mounted beside the pre-launch gate ahead of every human and public-read surface — the landing, the hub pages, the status host, the hall shell, `/public/*` and every module's `rank: public` route — rather than per-surface wiring, which misses the next surface nobody told it about. "Member" is a live, non-deactivated session on this instance, the same `resolveSession` lookup `requireBuilder` uses, per request, no cache; a lookup that throws fails CLOSED. The exempt list is the door, the manifest and the probes and nothing wider: `/api/*/auth/*` (a door that cannot be opened locks the members out too), `/api/*/instance` (what a stranger reads to learn how to sign in AND what the runner reads after a settings restart to learn whether the value was consumed — including the push that turns this gate on), `/healthz`, `/version`, `/metrics`; the pre-launch gate's blanket `/api/` exemption is deliberately not copied. A refused page gets a self-contained 401 door (no stylesheet, no branding bundle, no script) with one control — Sign in, returning (relatively) to the page knocked on; a refused API call gets `res.fail('unauthenticated', 401)`, exactly requireBuilder's envelope, which is why it mounts after `attachFail`. A member's answer leaves marked `private, no-store` whatever the route said — the public read API sends `public, max-age`, and a CDN edge would otherwise serve a member's copy to the next stranger. The exempt list covers every API prefix (the versioned contract too), `/downloads/*` and Caddy's TLS ask; a request's session is resolved once (`resolveSession` memoizes per request). The hub's manage page shows the CHOICE from the platform's row and what the project RUNS from the project's own public manifest (`brand.project`), and never confuses the two: `push.message` is rendered verbatim, `saved` moves only the radio, the "runs" line is written only from the manifest and says "doesn't report this setting yet" for a core that predates the channel. Rejected: per-surface wiring; a 302 into OAuth for a refused page (sends assets and crawlers to GitHub); copying the `/api/` exemption; painting the radio from the manifest or the runs line from `saved`; reusing the pre-launch gate.](<redacted>.md) | instance / project visibility |
 | 0192 | [**A work category orients a human and authorises nothing** ([task 1003275](https://cloudbongos.com/builders#/task/1003275), goal 1000072, criterion `legibility-categories`). A goal gains a human CATEGORY from an owner-named set of eight (Builders Hall, Context Management, Government (Decision Making), Modules, Security, Economics, Legal, User/ABI Experience) so a person scanning the board can tell at a glance which goals are about money, which about the walls, which about the hall — today each goal's own words say so, but only if you read all thirty-eight. The DECISION is the constraint, not the feature: the owner said twice that this organisation has no hierarchical purpose and no effect on the agentic management of the work, and the system ALREADY has a load-bearing hierarchy (ADR 0086 — the scope_modules wall, rank floors, goal membership). The goal's own prose predicts the failure: a second thing that looks like a hierarchy gets mistaken for one within a release, and the mistake arrives as ONE plausible line in a gate ('skip Legal goals in the feed'), after which work is refused because of a label nobody meant as a permission. So: no authority, claim-eligibility, feed or dependency surface may read a category — enforced by the `scripts/gds/category-advisory-guard.js` fitness check, which scans every decision surface with comments stripped (a gate may CITE the rule, never branch on it) AND asserts the feature still exists, so a renamed-away subject fails loudly instead of passing vacuously (the ADR 0022 assurance-of-assurance finding). Uncategorised is LEGAL — nullable, no default, required by no write — because the criterion is explicit that Claude failing to place a goal is a designed prompt, not an error. A task stores no category and INHERITS its goal's through `tasks.goal_id`; a stored copy would be a second answer to one question. The set is a table, not an enum (runtime-extensible without a migration per addition) and retiring is `active = false`, never a DELETE, so a goal keeps rendering a label someone tidied away. The three route-rank pins are a tripwire: if one ever needs a WIDER gate than its neighbours, the label has grown into a permission. Deliberately NOT built: a per-category page or filtered navigation view — a chip is a label, a drill-down destination is a tier. Making a category gate anything is an owner decision and needs its own ADR first.](<redacted>.md) | GDS / goals |
 | 0193 | [**Pause task-scoped box slices: a box serves its rank scope (the full repo for Metic+)** ([task 1003285](https://cloudbongos.com/builders#/task/1003285), owner decision from the 2026-08-25 dev-box efficiency review). Pauses, does not repeal, ADR 0148 / goal 1000051: `routes/box.js` skips the lifecycle-port `scopeKeys` resolution unless `BOX_TASK_SCOPE=on`, so `decideSourceAccess` takes its documented rank fallback — full repo for Metic+, starter surface below. WHY: the slice was defense-in-depth git cannot hard-enforce (ADR 0031 §6's honest limit) while its costs were real on the live fleet — sessions on a box that cannot see a module (or its nested CLAUDE.md) misdiagnose themselves as stuck, the scope machinery kept failing in the field (task 1002729's base-slice collapse), and every live box user is Metic+ anyway, so the slice narrowed trusted builders while newcomers were already gated by rank. UNCHANGED: live-rank allow/deny per request (ADR 0016), the provision floor and demotion clawback, the read-only per-request credential (ADR 0055 — push still 403s, re-verified on hardware in task 1003253), and sub-Metic starter boxes. `GET /box/scope` now reports `task_scoping_paused` so the hall/app can say why `task_scope` is false; the app task-picker's "scoped to `<modules>` and nothing else" copy overstates while paused (cosmetic). Revert = set the env flag; make-permanent = delete the resolution + a follow-up ADR.](<redacted>.md) | dev-box |
+| 0194 | [**A project's membership door is one decision, answered the same way everywhere a stranger meets it** ([task 1003044](https://cloudbongos.com/builders#/task/1003044), goal 1000058). The owner's 2026-08-16 joinability setting — open / apply / invite_only — was stored (1003040), pushed (1003139/1003140) and resolved into `branding().project.joinability`, enforced by nothing. Decision: ONE reader, `joinabilityMode()` in `auth-admission.js`, and `openEnrollmentEnabled()` becomes `mode === 'open'`, so the four sign-in call sites, `webAdmissionStatus` and the manifest's `admission.policy` follow untouched (SR-19: one gate, no drift). The legacy `OPEN_XENOS_ENROLLMENT` flag still opens an APPLY project — a self-hosted instance that set it keeps its door across the upgrade — but never reopens an explicit invite_only; an unreadable pack or a value this core cannot read fails CLOSED (invite_only), the ADR 0192 rule. The public `POST /access-requests` answers the door FIRST — before validation, before any lookup — `403 invite_only` / `409 open_enrollment` with plain sentences: no query, nothing revealed about who exists, and DB-free enough for the real booted app to prove. An Archon's invite is the row the gate already reads: `POST /access-requests/invite` writes `access_requests` at 'invited' (resolving a pending one in place), so sign-in consults nothing new — surfaced as "Invite by GitHub username" on the Watch page. The door is SAID wherever a stranger meets it, in the project's words: the hall landing renders one door per mode from the injected pack, the web 403 names the invite-only door and the way in, the CLI stops instead of filing, the hub's join relay names the door in the hub's own words (a project is trusted to build, not to write prose into the platform's UI) instead of painting a refusal as "requested" or "unreachable". `admission.policy` stays binary (pinned; agrees for free); `joinabilityMode` joins the doorway — a human MINOR by ADR 0161 §2, which the publish lane's LIVE test refused (HEAD's version must be a CI carrier's), so it rides the next CI patch and the contradiction is filed as an idea. The hub's `#mJoinability` clones `#mVisibility` rather than a factory — a third setting is where a factory pays. Rejected: folding the flag into `branding()` (memoized vs per-call; the manifest must stay the pushed value); a 200 for the open door (an older CLI would wait thirty minutes for an approval); re-deriving the mode inside the module; a second invite table.](<redacted>.md) | instance / project joinability |
 
 > ⚠️ **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

@@ -309,6 +309,58 @@
         "security": []
       }
     },
+    "/access-requests/invite": {
+      "post": {
+        "operationId": "post_access_requests_invite",
+        "tags": [
+          "access-requests"
+        ],
+        "summary": "POST /access-requests/invite",
+        "description": "POST /access-requests/invite — an Archon admits a GitHub username BEFORE any request exists (task 1003044): the only way in on an invite-only project, where the public POST refuses, and a shortcut on an apply one. It writes the same access_request row the sign-in gate reads (status 'invited' — hasInvitedAccessRequest), so nothing new is consulted at sign-in; a pending request for that login is resolved in place rather than duplicated. Two Archons inviting the same login at once can each insert a row (the unique index covers pending only): harmless — the gate reads \"any invited row\" — and it shows as two lines in the invited history, so no lock is taken. body: { github_login }. 201 with a new row; 200 with the row when a pending request was resolved; 200 already_invited when an invite already stands; 409 already_member when they have an account. rank: archon — the same gate as resolving a request.\n\n**Rank:** `archon` — Archon only (rank and identity management + the escalation keys — the trust boundary).\n\n**Permissions:** `access_request.review` (all required).",
+        "x-rank": "archon",
+        "x-source": "modules/onboarding/routes/access-requests.js",
+        "x-permissions": [
+          "access_request.review"
+        ],
+        "requestBody": {
+          "required": true,
+          "content": {
+            "application/json": {
+              "schema": {
+                "$ref": "#/components/schemas/PostAccessRequestsInviteRequest"
+              }
+            }
+          },
+          "x-validated": true
+        },
+        "responses": {
+          "200": {
+            "description": "Success.",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "$ref": "#/components/schemas/PostAccessRequestsInviteResponse"
+                }
+              }
+            }
+          },
+          "400": {
+            "$ref": "#/components/responses/ValidationFailed"
+          },
+          "401": {
+            "$ref": "#/components/responses/Unauthorized"
+          },
+          "403": {
+            "$ref": "#/components/responses/Forbidden"
+          }
+        },
+        "security": [
+          {
+            "builderSession": []
+          }
+        ]
+      }
+    },
     "/access-requests/status": {
       "get": {
         "operationId": "get_access_requests_status",
@@ -4376,6 +4428,44 @@
         ]
       }
     },
+    "/goals/rollups": {
+      "get": {
+        "operationId": "get_goals_rollups",
+        "tags": [
+          "goals"
+        ],
+        "summary": "GET /goals/rollups",
+        "description": "GET /goals/rollups?version= — one small row per goal: readiness counters, the last-activity timestamp, the craft set, and the next claimable task (task 1003278). It replaces the Goals page's whole-version task fetch, which measured 5,229,455 bytes for ~1,400 tasks on 2026-08-25 to produce ~40 counter objects. Registered BEFORE /goals/:id or Express routes 'rollups' to the param. rank: any-builder — the same read as the goal board it feeds.\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",
+        "responses": {
+          "200": {
+            "description": "Success.",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "$ref": "#/components/schemas/GetGoalsRollupsResponse"
+                }
+              }
+            }
+          },
+          "400": {
+            "$ref": "#/components/responses/BadRequest"
+          },
+          "401": {
+            "$ref": "#/components/responses/Unauthorized"
+          },
+          "403": {
+            "$ref": "#/components/responses/Forbidden"
+          }
+        },
+        "security": [
+          {
+            "builderSession": []
+          }
+        ]
+      }
+    },
     "/goals/suggestions": {
       "get": {
         "operationId": "get_goals_suggestions",
@@ -12580,7 +12670,7 @@
           "tasks"
         ],
         "summary": "GET /tasks",
-        "description": "reads (filtered task list); preserved per CRITICAL §4.\n\n**Rank:** `any-builder` — Any authenticated builder (row-level ownership enforced in-handler).",
+        "description": "**Rank:** `any-builder` — Any authenticated builder (row-level ownership enforced in-handler).",
         "x-rank": "any-builder",
         "x-source": "modules/lifecycle/routes/tasks.js",
         "responses": {
@@ -12635,7 +12725,14 @@
         },
         "responses": {
           "200": {
-            "description": "Success."
+            "description": "Success.",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "$ref": "#/components/schemas/PostTasksResponse"
+                }
+              }
+            }
           },
           "400": {
             "$ref": "#/components/responses/ValidationFailed"
@@ -15078,6 +15175,15 @@
           "goals"
         ]
       },
+      "GetGoalsRollupsResponse": {
+        "type": "object",
+        "properties": {
+          "rollups": {}
+        },
+        "required": [
+          "rollups"
+        ]
+      },
       "GetGovernmentAssignmentsResponse": {
         "type": "object",
         "properties": {
@@ -16635,6 +16741,36 @@
         },
         "additionalProperties": false
       },
+      "PostAccessRequestsInviteRequest": {
+        "type": "object",
+        "properties": {
+          "github_login": {
+            "type": "string",
+            "minLength": 1,
+            "maxLength": 60
+          }
+        },
+        "required": [
+          "github_login"
+        ],
+        "additionalProperties": false
+      },
+      "PostAccessRequestsInviteResponse": {
+        "type": "object",
+        "properties": {
+          "ok": {
+            "type": "boolean"
+          },
+          "already_invited": {
+            "type": "boolean"
+          },
+          "github_login": {},
+          "request": {}
+        },
+        "required": [
+          "ok"
+        ]
+      },
       "PostAccessRequestsRequest": {
         "type": "object",
         "properties": {
@@ -19892,6 +20028,23 @@
         ],
         "additionalProperties": false
       },
+      "PostTasksResponse": {
+        "type": "object",
+        "properties": {
+          "task": {},
+          "needs_migration": {},
+          "criteria": {},
+          "idempotent": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "task",
+          "needs_migration",
+          "criteria",
+          "idempotent"
+        ]
+      },
       "PostVersionsIdDoneWhenRequest": {
         "type": "object",
         "properties": {
@@ -20152,9 +20305,9 @@
       "description": "A required dependency/feature is not configured or is temporarily down."
     }
   },
-  "x-endpoint-count": 320,
-  "x-schema-count": 353,
+  "x-endpoint-count": 322,
+  "x-schema-count": 357,
   "x-undocumented-bodies": 9,
-  "x-response-schemas": 237,
+  "x-response-schemas": 240,
   "x-generated-by": "scripts/gds/gen-api-docs.js"
 }

package/docs/api-reference.md

@@ -2,18 +2,19 @@
 
 # Bongos API reference
 
-> **Generated from the live route files** — the route file is authoritative. 320 endpoints across 52 route files.
+> **Generated from the live route files** — the route file is authoritative. 322 endpoints across 52 route files.
 > Machine-readable spec: [`docs/api/openapi.json`](api/openapi.json) (OpenAPI 3.1). Rendered docs site: **`/docs`** (e.g. `cloudbongos.com/docs`).
 
 Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/<redacted>.md)): `public` < `any-builder` < `metic+archon` < `archon`.
 
-## `access-requests` (4)
+## `access-requests` (5)
 
 | Method | Path | Rank | Body | Description |
 |---|---|---|---|---|
 | GET | `/api/bongos/access-requests` | `archon` | — | GET /access-requests?status=pending — Archon queue. |
 | POST | `/api/bongos/access-requests` | `public` | `github_login`, `display_name`, `note` | POST /access-requests — PUBLIC. |
 | PATCH | `/api/bongos/access-requests/:id` | `archon` | `status` | PATCH /access-requests/:id — Archon resolves a request. |
+| POST | `/api/bongos/access-requests/invite` | `archon` | `github_login` | POST /access-requests/invite — an Archon admits a GitHub username BEFORE any request exists (task 1003044): the only way in on an invite-… |
 | GET | `/api/bongos/access-requests/status` | `public` | — | GET /access-requests/status?github_login=X — PUBLIC. |
 
 ## `achievements` (1)
@@ -205,7 +206,7 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/<redacted>
 | GET | `/api/bongos/github/repos` | `any-builder` | — | acts only on the caller's OWN GitHub identity (the token they granted). |
 | POST | `/api/bongos/github/repos` | `any-builder` | `name` | creates a repo in the caller's OWN account. |
 
-## `goals` (27)
+## `goals` (28)
 
 | Method | Path | Rank | Body | Description |
 |---|---|---|---|---|
@@ -235,6 +236,7 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/<redacted>
 | PATCH | `/api/bongos/goals/:id/visibility` | `any-builder` | — | PATCH /goals/:id/visibility — make a goal public\|private (task 1952 / ADR 0112). |
 | GET | `/api/bongos/goals/inbox` | `any-builder` | — | GET /goals/inbox — the caller's private-goals inbox (task 1952 / ADR 0112): { invitations: invites addressed to me (accept/decline); join… |
 | POST | `/api/bongos/goals/reorder` | `metic+archon` | `version_id`, `ordered_ids` | POST /goals/reorder — Archon drag-to-reorder: set the priority order of every goal WITHIN one version (task 1760). |
+| GET | `/api/bongos/goals/rollups` | `any-builder` | — | GET /goals/rollups?version= — one small row per goal: readiness counters, the last-activity timestamp, the craft set, and the next claima… |
 | GET | `/api/bongos/goals/suggestions` | `any-builder` | — | GET /goals/suggestions — "which goal should this draft live in?", answered before anything is created (task 1003062 / R07). |
 
 ## `government` (13)
@@ -537,7 +539,7 @@ Base path: `/api/bongos`. Ranks (enforced server-side, [ADR 0016](adr/<redacted>
 
 | Method | Path | Rank | Body | Description |
 |---|---|---|---|---|
-| GET | `/api/bongos/tasks` | `any-builder` | — | reads (filtered task list); preserved per CRITICAL §4. |
+| GET | `/api/bongos/tasks` | `any-builder` | — |  |
 | POST | `/api/bongos/tasks` | `metic+archon` | `version_id`, `title`, `description`, `status`, `touches`, `est_minutes`, `est_cost_usd`, `manual_degree`, `priority`, `automation_tag`, `credits_reward`, `source`, `source_ref`, `value_summary`, `kind`, `discipline`, `parallel_safe`, `newcomer_friendly`, `security_sensitive`, `requires_rank`, `auto_detect_touches`, `criterion_ids`, `module_key`, `goal_id` | Task create/promote/edit (plan/scope mutation) is Metic+ as of ADR 0090 (owner decision 2026-06-26): a Metic who can run idea-triage may … |
 | GET | `/api/bongos/tasks/:id` | `any-builder` | — | single-task read; preserved per CRITICAL §4 (supervisor hot path). |
 | PATCH | `/api/bongos/tasks/:id` | `metic+archon` | `kind`, `discipline`, `requires_rank`, `module_key`, `goal_id`, `parent_task_id`, `parallel_safe`, `newcomer_friendly`, `xenos_claimable`, `security_sensitive`, `automation_tag`, `needs_migration`, `description`, `status` | PATCH /tasks/:id — supports body.parent_task_id (V2 C2), body.kind (V2 B1), body.discipline (mig 014), body.parallel_safe (mig 028), and … |