@bongos/core 1.19.1017 → 1.19.1018

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.1017",
-  "core_contract": "1.19.1017",
-  "source_commit": "9a573618264550e005f12355e27d3a7b181a3baf",
+  "core_version": "1.19.1018",
+  "core_contract": "1.19.1018",
+  "source_commit": "49eb795ed8e84657315241e6cfa652f3491e6edc",
   "source_ref": "HEAD",
-  "built_at": "2026-09-25T01:23:29.511Z",
+  "built_at": "2026-09-25T01:46:13.363Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 526,
+    "docs_redacted": 527,
     "agent_docs_stubbed": 26,
-    "functional_verbatim": 2439,
+    "functional_verbatim": 2440,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2991,
-  "tree_sha256": "0df28ef9d48e95b2b0701f4c132182d88e6e5e5995bf19569136cfedb92f1299",
+  "file_count": 2993,
+  "tree_sha256": "ed9091f7fa992b1a3cb4b1d473869986f200827a94ca69cc0a8c86770b571b71",
   "files": [
     {
       "path": ".claude/skills/ask-for-help/SKILL.md",
@@ -1542,7 +1542,7 @@
     {
       "path": "docs/adr/0208-application-lifecycle-the-handle-waits-and-the-vouch-has-no-minter.md",
       "mode": "0000644",
-      "sha256": "8164be7327574eb29b5c1bd76c6d2b8892cb26ed2c7d07cb59f08182ae6b4f42"
+      "sha256": "84f46e47b23542bf6d4fb78c7e1914f1ebbbf9548e40159814c41bb4003f827e"
     },
     {
       "path": "docs/adr/0209-one-budget-for-the-account-existence-oracle.md",
@@ -2154,6 +2154,11 @@
       "mode": "0000644",
       "sha256": "659b73c16da06bb150434de1eae1bcc1dfe4f6acf61ac0b2d787f3b52f617187"
     },
+    {
+      "path": "docs/adr/0333-the-application-vouch-is-a-third-token-spent-once-and-bound-to-its-login.md",
+      "mode": "0000644",
+      "sha256": "b89c4d4bd55e2fe48686cdeabe5bd7eb08c41d195e4d06ea422096d1b7466e0b"
+    },
     {
       "path": "docs/adr/0334-the-recruiting-directory-lists-a-hidden-builder-by-name.md",
       "mode": "0000644",
@@ -2172,7 +2177,7 @@
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "83fa5a319b2680beec179cf4f9dc5a1b630699aa2cfa7443300694b724215e8f"
+      "sha256": "8227e2293df9bc8364bc66ecd8890341e7a1410b9edc7906c38abae37ce7eccd"
     },
     {
       "path": "docs/api-reference.md",
@@ -2742,7 +2747,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "67d5afba0afa656dbf2f89d7591cc91af04a97492c85959ef6dd41ccc764e12a"
+      "sha256": "a0b015494e2c8eaf772b17de3bd6c38737a4ad939921a395021172271b445e3f"
     },
     {
       "path": "docs/modules-contract.md",
@@ -3864,6 +3869,11 @@
       "mode": "0000644",
       "sha256": "968b1f4b893c9368da682fae0845b69ec367aa465ae608f60644c266818b874e"
     },
+    {
+      "path": "migrations/core_254_access_requests_applicant_handle.sql",
+      "mode": "0000644",
+      "sha256": "040de8cddf1a8740ac7e97fb35572e56494a5a3b51ce8873887f71759f6a3b9d"
+    },
     {
       "path": "modules/agents/CLAUDE.md",
       "mode": "0000644",
@@ -6407,7 +6417,7 @@
     {
       "path": "modules/onboarding/routes/access-requests.js",
       "mode": "0000644",
-      "sha256": "3c66a404347ef1b93edcf5c63a902c9561b0a3f9bd9bc6c17e8a2a1f1b5f6707"
+      "sha256": "301c45e4f72024c7b1507245a9fccf4388224bb544ad747712c69155d41d1861"
     },
     {
       "path": "modules/onboarding/routes/onboarding.js",
@@ -6462,7 +6472,7 @@
     {
       "path": "modules/platform-identity/hub-keys.js",
       "mode": "0000644",
-      "sha256": "01d30570d828a1f06ccac693cc5c268d00fb091a13412a3f3890f10828a05203"
+      "sha256": "a8dcce2d4be3d041c349c59cfc0eab2171a08869225f3ccfdb525c70faffb8eb"
     },
     {
       "path": "modules/platform-identity/invite-authz.js",
@@ -6652,7 +6662,7 @@
     {
       "path": "modules/platform-identity/routes/my-projects.js",
       "mode": "0000644",
-      "sha256": "c920f13eea6bdfc2f361d7c23500d295bb87066205ee2f4792adc22fc5dfa715"
+      "sha256": "56700357273c03d412afce1ef9937ba811257d0c5110f08d757bbef3e517a416"
     },
     {
       "path": "modules/platform-identity/routes/profile.js",
@@ -8287,12 +8297,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "95953cc5ca598a00deaa5aeb7f508b6b80c161f90fa7d3fd801f3d86b23bad7d"
+      "sha256": "c5cc97b40c78fcf1e0eb46f141d801315cb7cdc9afb99ee7435707df4a067f04"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "3b1e756b16420ac260634273c6b00ab0e08e5c81ebe9df3496ec1b5b60bde3ae"
+      "sha256": "3f6fc02ebfabdea595b601e08e7bb9aa2004f576bc4497ecf1d36482889b8efb"
     },
     {
       "path": "public-docs/index.html",
@@ -10047,12 +10057,12 @@
     {
       "path": "src/bongos/auth-idp.js",
       "mode": "0000644",
-      "sha256": "836cf0862d14c753ef3f39117cb75cb4750e6078483ef1a708e32eb1af42930c"
+      "sha256": "fb4d7e17e113cdb41e118d3ecaefc6dc81676dcb780deb3f13532bd998b1412d"
     },
     {
       "path": "src/bongos/auth.js",
       "mode": "0000644",
-      "sha256": "799551a37691db4e4516d29a319d0e60d2dea88166b753ce55321e421a05ee3d"
+      "sha256": "f35226f4ab906fa8dbcd688e1c429ce9f161e616f6b5c4a96dee3cebdf33e4b1"
     },
     {
       "path": "src/bongos/cascade-dispatch.js",
@@ -10337,7 +10347,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "45613a020e18c5494e4b2664f97274a34f225e2d2c35ecd38b2926528b150a8a"
+      "sha256": "2bc85f866eb82befe5dd49e4e5b3c1ed1195f33eb2d00a8f5c8f952d82c99843"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -10607,12 +10617,12 @@
     {
       "path": "tests/application_echo.mjs",
       "mode": "0000644",
-      "sha256": "779f856c9433f8adc9c79ca988151a12158bcb97f746a9b29a8ca14b09499440"
+      "sha256": "eec3a0404674e2a02d3ba7f38ec9fee92e5f06870240161d98986d525cb03d3f"
     },
     {
       "path": "tests/application_lifecycle.mjs",
       "mode": "0000644",
-      "sha256": "249c97a172d0b77dae22dc561dc7c02dd48b636956df296647d62d7c6e213727"
+      "sha256": "975389846058a123344a6cd56d2355b606c86e2ce59a48981782f61204090096"
     },
     {
       "path": "tests/architect.mjs",
@@ -12677,7 +12687,7 @@
     {
       "path": "tests/idp_device_exchange.mjs",
       "mode": "0000644",
-      "sha256": "bbc81764a9a531afb15f58f925fb72a3f213e1a1c010c45325f741b41428923e"
+      "sha256": "3a57c5a71dae3b35d90fb360efc8ae39ca889f18dbc18d504a68cbc01f0c219c"
     },
     {
       "path": "tests/idp_federation.mjs",
@@ -13047,7 +13057,7 @@
     {
       "path": "tests/module_api.mjs",
       "mode": "0000644",
-      "sha256": "868942895e19730936594efb9f0fb69e4e511397ed738c05e0b27073c01846f7"
+      "sha256": "02f08f0c3449d0d3d7e3df4f2116aba31a01732b7f083dad0d1d11358c90ff53"
     },
     {
       "path": "tests/module_api_lazy.mjs",

package/docs/adr/0208-application-lifecycle-the-handle-waits-and-the-vouch-has-no-minter.md

@@ -3,6 +3,7 @@
 - **Status:** accepted
 - **Date:** 2026-08-29
 - **Task:** [task 1002284](https://cloudbongos.com/builders#/task/1002284) (R08, goal 1000045 — criteria C3/C4)
+- **Resolved by:** [ADR 0333](0333-the-application-vouch-is-a-third-token-spent-once-and-bound-to-its-login.md) (task 1002285) — D1's handle and D2's minter, verifier tightening and jti choice are built there.
 - **Relates to:** [ADR 0201](0201-cross-project-application-vouched-row-live-record.md) (the design this builds — D1, D3.2, D4), [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (descriptive analytics are never authority), [ADR 0141](<redacted>.md) (identity federated, authority local), [ADR 0171](0171-profile-rollup-join-and-consent.md) D2 (the non-numeric principal guard), [ADR 0116](0116-api-error-envelope-and-code-taxonomy.md) (a refusal names the action available), [ADR 0202](0202-connections-graph-and-bounded-degree.md) D4 (the `account-visibility.js` "its own small file" precedent this reuses)
 
 ## Context

package/docs/adr/0333-the-application-vouch-is-a-third-token-spent-once-and-bound-to-its-login.md

@@ -0,0 +1,86 @@
+# ADR 0333 — The application vouch is a third token kind, spent once, bound to the login it names, and carries a handle only past the consent floor
+
+- **Status:** accepted
+- **Date:** 2026-09-24
+- **Task:** [task 1002285](https://cloudbongos.com/builders#/task/1002285) (R09, goal 1000045 — criterion C4)
+- **Relates to:** [ADR 0201](0201-cross-project-application-vouched-row-live-record.md) D2 (the vouch, the header, the handle), [ADR 0208](0208-application-lifecycle-the-handle-waits-and-the-vouch-has-no-minter.md) D1 + D2 (the handle waits; the minter that cannot express it), [ADR 0260](0260-the-application-is-the-consent-and-the-echo-is-the-gate.md) (the live consumer, built dormant), [ADR 0141](<redacted>.md) §1 (the signed assertion), [ADR 0144](0144-federated-single-logout-backchannel.md) (the logout token), [ADR 0016](0016-trust-boundary-server-enforced-permissions.md) (a vouch is never authority), [ADR 0091](0091-bounding-the-kernel-and-db-carve.md) §2 (boundary-forced duplication)
+
+## Context
+
+ADR 0201 D2 decided that an application relayed by the hub carries a hub-signed vouch in a header, so a project's reviewer can safely see the applicant's cross-project record beside the name. ADR 0208 D2 then found that the vouch could not be built as D2.1 wrote it: `mintHubAssertion` has no `purpose`, and — worse — `verifyHubAssertion` accepted *any* identity payload, purpose or not, so a captured vouch would have verified as a device sign-in. ADR 0260 built everything downstream of the vouch (the D7 applicant view, the echo-gated `POST /sso/applicant-profile`, the queue's live read keyed on `applicant_github_id`) and left it dormant, because nothing wrote that column.
+
+This task writes it. Four choices in the writer are not obvious, and ADR 0208 D2 explicitly asked for one of them to be *chosen* rather than inherited.
+
+## Decision
+
+### D1 — A third mint/verify pair over one shared envelope, on both sides
+
+`mintHubApplicationVouch` (hub) and `<redacted>` (instance) carry `purpose: 'application'` **and** identity (`sub`, `applicant_login`, `handle`). The three token kinds now differ only in their claims, so each side mints and verifies them through one envelope — `signHubToken` in `hub-keys.js`, `verifyHubToken` in `auth-idp.js` (signature first, Ed25519 hardcoded, issuer, audience, expiry) — rather than three copies of the same twenty lines of crypto. Each verifier then demands exactly what the other two lack:
+
+| Kind | Identity | `purpose` |
+|---|---|---|
+| login assertion | required | **forbidden** |
+| logout token | absent | `backchannel-logout` |
+| application vouch | required, as `applicant_login` | `application` |
+
+The existing error messages are preserved byte-for-byte (the envelope takes the kind's name as a label).
+
+**The vouch's login rides as `applicant_login`, not `github_login`, and that is what makes it safe on cores that have not upgraded.** Every login verifier any core ever shipped demands `github_login`, so a vouch relayed to a project still on an older pin is refused there as a device sign-in too — the purpose refusal in D2 only exists on cores that run this release, and the hub cannot know which pin a project runs. Found by review before ship: with a shared `github_login` claim, an older project that ignored the header could have exchanged a captured vouch for a CLI session within its ~120s life. The two defences are independent, and `tests/idp_device_exchange.mjs` asserts each on its own.
+
+### D2 — `verifyHubAssertion` refuses ANY `purpose`, not a list of known ones
+
+ADR 0208 D2 named the window: the tightening is free only while no minter puts a purpose on an identity token, and this task is the one that starts doing so. The check is presence (`hasOwnProperty`), so `purpose: null`, `''` and any future marker are refused too. A list of forbidden purposes would reopen the device-login replay the day someone adds a fourth kind and forgets the list.
+
+### D3 — The jti is CHOSEN: a separate single-use store, and a vouch must carry one
+
+One vouch vouches one application. The store is its own register — not the CLI assertion map it could have inherited — for the reason the logout store gave: no two token kinds share dedupe state. All three registers now come from one `jtiStore()` factory, so they cannot drift apart. The vouch is spent when it is read, before the INSERT: a write that then fails answers 500, the hub reports the project unreachable, and the applicant's retry mints a fresh vouch — so a spent-but-unwritten vouch costs nothing. `<redacted>` also **requires** a `jti` (its siblings tolerate a missing one) and **requires an audience**: the shared envelope skips the audience check when no client id is given, and a vouch checked that way would accept one minted for any project on the platform.
+
+### D4 — The vouch must name the login the request names; otherwise the row is written unvouched
+
+The body's `github_login` is a string anyone may type. Without the match, any valid vouch could be stapled to a request naming someone else, and the reviewer would read "Identity vouched" beside a name the vouch never confirmed — the exact impersonation surface ADR 0201 exists to close. A mismatch, like every other failure (absent, forged, expired, foreign, replayed, no hub key), writes the unvouched row: **never a refusal** (ADR 0201 D2.3).
+
+### D4b — A vouched re-application takes over an UNVOUCHED pending row for its own login
+
+The one-open-row index means a later application for a login that already has a pending row cannot insert. Left alone, anyone who filed an unvouched request under a well-known builder's login first — off the landing page, no header needed — would pre-empt that builder's real, vouched application for as long as the row sat there: the reviewer would see "Name unvouched" beside the squatter's name and note. So when the INSERT hits the index and the request carried a verified vouch for that login, the route UPDATEs the pending row with the vouch **and replaces its display name and note** with the vouched request's own, so the words beside "Identity vouched" are the vouched applicant's. The UPDATE's own `WHERE applicant_github_id IS NULL` means a row that is already vouched is never re-stamped, and an unvouched re-application still changes nothing (D1.4). Found by review before ship; the first draft named it as a limit instead.
+
+### D5 — The handle is identity, not record; it rides only past the consent floor, and it is stored
+
+`applicant_handle` (`core_254`) is written in the same statement as `applicant_github_id` and `vouched_at`, so the three can never disagree. ADR 0260 D4 says nothing about the applicant is stored — that sentence is about the **record**, which is still resolved live on every render; the handle is in the class of `github_login` and `applicant_github_id`, which the row already holds.
+
+The hub puts a handle in the vouch only when the account clears `isAccountActive` (active **and** the platform terms accepted) — the same floor the applicant view applies — so the vouch never discloses a handle the reviewer's own queue would not show. A **private** account's handle does ride: applying is the consent (ADR 0260 D2), and its D3 sliver carries the handle anyway. The identity itself comes from the hub session, not the account row, so a provisional account is still vouched — just handle-less. The instance re-checks the handle against the hub's handle charset (a boundary-forced mirror of `normalizeHandle`, driven against it in `tests/idp_device_exchange.mjs`) and stores null for anything else.
+
+**Storing it does not outlive a withdrawal, because nothing withdraws a handle.** The floor it passed is write-once in both halves — `profile_state` never demotes from `active`, and `terms_accepted_at` is COALESCE-stamped once (ADR 0213) — and neither `hide_stats` nor going private withholds a handle on any surface (the sliver carries it; `hide_stats` suppresses numbers, never addressability). So the stored handle never shows a reviewer more than the live applicant view would, except after a rename (below).
+
+Since ADR 0260 moved the record read server-side and keyed it on `github_id`, the handle is no longer the lookup key ADR 0201 D2.5–6 needed. It is what the reviewer's queue can call the applicant when the hub is unreachable, and it is returned only by the archon-gated `GET /access-requests`.
+
+### D6 — On the hub the vouch is best-effort, never a gate
+
+A hub with no signing key sends no header and reads nothing — the project writes the unvouched row it always wrote. A failed account read still vouches the identity, handle-less. A mint failure sends no vouch. None of them delays or fails the application. The echo — which is what authorizes the project's later profile read — is written by the same relay on the same `requested` outcome, so a vouch never arrives without the echo it needs, except when the echo write itself fails (below).
+
+### D7 — The instance reaches it through a narrow doorway port
+
+`readApplicationVouch(token, { githubLogin })` joins the doorway beside `<redacted>`. Core supplies the hub public key and this instance's client id; the onboarding module passes a token and a login and can neither substitute a key nor re-address the audience.
+
+## Consequences
+
+- The ADR 0260 path lights up with no UI or route change: a vouched row's `applicant_github_id` drives the live profile read, and `watch.js` already renders the pill and the profile block.
+- It lights up only when **both** ends run this release: the hub mints, the project verifies and has `core_254`. Either alone is inert and safe — an old project ignores the header, an old hub sends none.
+- The approve path and `hasInvitedAccessRequest` are unchanged and still name no vouch column; `tests/application_lifecycle.mjs` now asserts that for a row written by the real writer, not only a seeded one.
+
+## Honest limits
+
+- **The vouch travels with every relay, including to a project whose door then refuses.** The header is minted before the project answers, so an invite-only or unpublished project's server receives the account id and (past the consent floor) the handle of someone who pressed Apply there. It learns no more than the body already tells it — the login and display name — plus the handle and the numeric GitHub id, both public-shaped identity, and it was the applicant who chose to knock.
+- **The jti store is per-process memory.** A restart inside the ~120s window forgets spent vouches; the audience binding stays the primary control, and a replay can only re-assert the identity it already carried at the project it was minted for.
+- **The handle is a snapshot.** A rename after applying is not followed; the hub's previous-handle 301 covers one, and the live profile block shows the current handle whenever the hub answers.
+- **A vouched row can still show no record** when the relay's best-effort echo write failed, since ADR 0260 D3 gates the profile read on the echo. That is the degrade the queue already renders.
+- **No Postgres executes the new INSERT in CI** — the ADR 0208 limit stands. The fake pool in `tests/application_lifecycle.mjs` matches the column list and `VALUES` exactly, so dropping or reordering a vouch column reds the suite; the migration is additive and idempotent.
+
+## Rejected
+
+- **A `purpose` argument on `mintHubAssertion`.** ADR 0208 D2's reason: it would look like D2.1 shipped while leaving the device-login replay open.
+- **Reusing the CLI assertion's jti map.** Shared dedupe state across token kinds is what the logout store already declined.
+- **Refusing an invalid or mismatched vouch.** Hands an attacker a way to make applications fail and locks out older hubs (ADR 0201 D2.3).
+- **Taking the row's login from the vouch instead of the body.** A mismatch means something is wrong; silently renaming the request to whoever the vouch names would hide it.
+- **Upgrading a squatted row but keeping its name and note.** It would stamp "Identity vouched" beside words someone else may have typed.
+- **Asking the project's version before minting, to skip older pins.** A second round-trip on every application to learn what a claim name (D1) already guarantees on every pin.
+- **Sending the handle regardless of consent.** A provisional or no-terms account discloses nothing on any other surface; the vouch would have been the one exception.

package/docs/adr/README.md

@@ -423,6 +423,7 @@ This keeps the decision history honest and traceable.
 | 0329 | [**The rendered fit check is a kit floor and an advisory ship-check row, not a grader worker** ([task 1004203](https://cloudbongos.com/builders#/task/1004203), goal 1000095 — UI quality). Nothing in the pipeline rendered a page, so titles clipped by character count ran past their cards (task 1003480, task 1004204) and a second `.mSec` child would have landed on the first (task 1003078), each found only in a browser. Two new kit floors, `text-fit` (text measured word by word past its box; SVG text past its card rect) and `sibling-overlap` (in-flow, block-level, text-bearing siblings), run in every `render.js` render; `scripts/gds/render-check.js` renders the pages a branch changed at 1280 + 390 and `/ship-check` shows them as an ADVISORY row that never flips its exit (ADR 0162). Not a grader worker: that would put a browser, fixtures and a harness on the grader host for signal the builder already saw; the artist gate (ADR 0241) stays the human look before deploy.](0329-the-rendered-fit-check-is-a-kit-floor-and-an-advisory-ship-check-row.md) | ui-design / kit + ship-check |
 | 0330 | [**An ask is answered where it was asked** ([task 1004216](https://cloudbongos.com/builders#/task/1004216), goal 1000095 — BONGOS-V2), amending [ADR 0187](0187-collab-four-decisions.md) §4a. `lifecycle_004` let a builder ASK for help and let the **asker** mark their own row answered; the person being **asked** had no write at all, so the answer happened somewhere Bongos cannot see and the row sat open until its author remembered it — six asks addressed to the owner had been open between four and thirteen days on 2026-09-23, every one of them answerable. That was not an oversight: §4a deferred conversation to the Agora and a test named *"there is deliberately NO reply thread"* enforced it. **The deferral lost its addressee** — task 1002946 is ABANDONED and goal 1000064 ARCHIVED (verified against the live DB), so the rule had stopped meaning "wait for the Agora" and started meaning "an ask stays unanswerable forever to keep a promise to something that does not exist". **Decisions:** (1) an ask carries a thread of replies, APPEND-ONLY in the SCHEMA rather than by convention — no `updated_at`, `edited_by`, `deleted_at` or `parent_reply_id`, no reactions, no mentions, and a trigger that refuses UPDATE and DELETE outright, because a thing you can edit, nest, react to and address at people is a chat and that is what §4a declined; any builder may reply, since the board read is already project-wide and the good case is somebody you did not ask knowing the answer; (2) the **ADDRESSEE** may close an ask (`answered`), widening an asker-only UPDATE that was coherent only while nothing could be said on the row — but `withdrawn` does NOT widen, since "I no longer need this" is the asker's sentence alone and widening it would be a way to make an ask vanish unanswered; `settled_by` records which of the two closed it, and ADR 0187 §3's consent posture is untouched — closing ends a question, it does not accept work; (3) `/collab-review` posts the reply and **leaves the ask open** (owner decision), since an answer the reader has not read is exactly what an unattended run must halt on. **Consequences:** a reply cannot be taken back, by design; the FK **RESTRICTS rather than cascades** — the first draft cascaded, which reads right and was wrong, because a cascade is a plain DELETE the trigger refuses, so deleting an answered ask failed outright (caught by applying the migration to a real Postgres, not by reading it); the old test was REPLACED, not deleted, so the record that the restraint was deliberate survives; and replies inherit the pull-not-push posture, so nothing still tells an asker they were answered. Rejected: a single `answer` column (cheapest and unambiguously not a chat, but a follow-up would have nowhere to go except a second ask, splitting one conversation across two rows); waiting for the Agora (abandoned — waiting means forever); letting anyone close any ask (an open question is somebody's, and a stranger ending it should not be one click away).](0330-an-ask-is-answered-where-it-was-asked.md) | collab / lifecycle / schema |
 | 0331 | [**The sky is the ideator's home, and the project sky takes the goal map's page** ([task 1004229](https://cloudbongos.com/builders#/task/1004229), goal 1000095 — BONGOS-V2), amending [ADR 0227](0227-a-task-network-map-is-refused-the-goal-graph-is-the-map.md) and decision 11 of `docs/specs/<redacted>.md`. The owner reviewed an interactive prototype of the ideator sky and the project sky over five rounds on 2026-09-24 and adopted it AS IS — copy, layout, colours, tour text, toggles, interactions — which contradicts two things already written down, so they are rewritten rather than leaving the build graded against a contract nobody means any more. **Decisions:** (1) the sky is the ideator's HOME surface — it replaces *Your thinking*, and the project sky replaces the goal map page — so "never load-bearing" and "arrives last" are DROPPED as a sequencing hedge from before there was a design to look at; the rule that survives at full force is the accessibility half, that the sky is never the ONLY path to anything it shows (the list drawer — the room — is one key away, and every drawn thing is a row in it); (2) ADR 0227 is AMENDED, not reversed — its measured refusal of a whole-corpus task map stands, and the project sky is §1's own prescription rather than its refusal: the goal graph is the entry point, tasks are drawn only INSIDE one goal past a zoom threshold (the per-goal drill-down §10.5 measured readable at 85.2px pitch worst case), below that they are dust density on the rings with NO identities, and the goal map's table survives as the sky's ledger drawer (§6's table equivalent kept); the nav slot the goal map was deliberately denied is GRANTED to the project sky, under Goals (owner, 2026-09-24), so part 4 changes the page and the test asserting no slot together; (3) the five states and the two channels are UNTOUCHED — criterion `ideator-sky-tells-the-truth` names a model, not a picture, and this amendment changes the picture's standing only; (4) the two HEURISTICS in the prototype — an idea's origin guessed from its text, and "born of a thought" found by scanning text for idea ids — must not ship as ledger facts: parts 3 and 4 hide both layers, part 5 replaces them with a `filed_via` column and a real born-of read. **Consequences:** `docs/design/mocks/sky/sky.template.html` is the PIXEL CONTRACT for parts 2–5, and every deviation a gate or the file ratchet forces is listed in that part's ship notes; no snapshot JSON or built page is ever committed (it carries real task and idea titles and this repo is public); ADR 0264's deleted goal "Living project sky" is superseded by this work under Working area 3. Rejected: shipping the sky as an extra and keeping "never load-bearing" (makes the adopted home surface unroutable); reversing ADR 0227 (its refusal is measured and still correct — the sky needs its drill-down shape, not its repeal); shipping the heuristics behind a disclaimer (a labelled guess is still a guess in a picture whose promise is that it cannot be faked).](0331-the-sky-is-the-ideators-home.md) | design / ideator / sky |
+| 0333 | [**The application vouch is a third token kind, spent once, bound to the login it names, and carries a handle only past the consent floor** ([task 1002285](https://cloudbongos.com/builders#/task/1002285), goal 1000045 — criterion C4), resolving [ADR 0208](0208-application-lifecycle-the-handle-waits-and-the-vouch-has-no-minter.md) D1 + D2. The hub's join relay now carries a signed application vouch in `<redacted>`, so the ADR 0260 live-record path is no longer dormant. `mintHubApplicationVouch` / `<redacted>` share one envelope with the login and logout tokens, and each verifier demands what the other two lack; `verifyHubAssertion` now refuses any `purpose`, closing the device-login replay. The jti is a chosen, separate single-use store; a vouch must carry a jti and an audience, and must name the login the request names, or the row is written unvouched (never refused); a vouched re-application takes over an unvouched pending row for its login. The vouch carries its login as `applicant_login`, so even an un-upgraded core refuses it as a login. `applicant_handle` (`core_254`) is identity, not record, and rides only past the consent floor.](0333-the-application-vouch-is-a-third-token-spent-once-and-bound-to-its-login.md) |
 | 0334 | [**The recruiting directory lists a hidden builder by name, and hide changes a row's shape, not whether it exists** ([task 1002291](https://cloudbongos.com/builders#/task/1002291), R15 — goal 1000110). Privacy spec D2 (owner-signed) lists an active, public, hidden account on the recruiter surface "name-only (if not opted out)"; the directory dropped it outright, making hide a second opt-out while Settings told that builder recruiters would see their name and picture. `GET /scouting` now answers two tiers: `builders` (ranked, `scoutingListableSql`, unchanged) and `name_only` (`scoutingNameOnlySql` = the same predicate with the hide term flipped, so the tiers partition the directory and only the opt-out removes anyone), projected to `github_login`, `display_name`, `avatar_url` by `scouting-name-only.js`. The existence floor stays (a private account is the archon-floor D3 sliver's, never the directory's); presence never depends on activity; the only order is the login; the predicate is pinned to that one reader and its three columns. The hall's `/people` renders the tier as its own panel, never ranked, found by name, never by a role filter. Rejected: fixing only the copy; trailing rows in the ranked ledger; listing private discoverable accounts by name.](0334-the-recruiting-directory-lists-a-hidden-builder-by-name.md) | privacy / recruiting / hall |
 | 0335 | [**An invite is a pre-approved row on the project's own instance, and `project.recruit` says who may send one** ([task 1002813](https://cloudbongos.com/builders#/task/1002813), R1 of the project admin console wave, goal 1000110 — BONGOS-V2). Supersedes ADR 0141 §5's "Invitations (deferred slice)" paragraph only. Formalises spike task 1002786's three decisions and reconciles them with six weeks of shipping: the instance invite route (task 1003044), the PATCH rescind (ADR 0201 D4.2) and the composed join door (ADR 0247) already exist, and the hub invite's dead end is now reachable from the creation wizard. **Decisions:** (D1) authority lives on the project's own instance, and the instance IS the project; the hub is identity, relay, echo, notification and links, and never writes a project's admission row; (D2) a recruit invite is an `access_requests` row with `status='invited'`, so signing in is the acceptance act and the gate is untouched; the row gains `kind ∈ (application, invite)` and `created_by` (the inviter, which a rescind would otherwise overwrite), reuses `note`, backfills exactly (`created_at = resolved_at`), and neither column ever enters an admission read; (D3) one new grantable atom, `project.recruit` (`system:false`, floor archon, widened per instance through the existing governance tab), guards the invite, the outstanding list, the invite rescind and the queue read, while `access_request.review` keeps the verdict; because inviting is admitting, a recruiter without the review atom may not approve or re-admit an APPLICANT through the invite route (409 to the queue); the hub sliver moves onto the atom, and the hub directory and hub invite KEEP `project.curate`, revising ADR 0210/0215/0248, since swapping the directory would raise a gate on a viewing surface (ADR 0217). **Task map:** R2 (task 1002814) = the migration, the invite writes and the sender list, still on `access_request.review`; R3 (task 1002815) = mint the atom, move the gates, the 409 clause, the sliver swap and the pins, and it lands after R2; R5 (task 1002817) is already delivered, so close it into task 1002331; task 1003362 folds into R3. Rejected: a new invitations table; the hub pending row as the invite; widening `access_request.review` instead of minting an atom; a per-project settings row for the floor; letting a recruiter's invite approve applications; `system:true`; swapping `project.curate` on the hub directory.](0335-an-invite-is-a-pre-approved-row-on-the-projects-own-instance.md) | governance / onboarding / platform-identity |
 | 0336 | [**A guild is a hub-side group whose members each consent twice, and its collective record is only ever the sum of what those members already show** ([task 1002299](https://cloudbongos.com/builders#/task/1002299), goal 1000110 — the R23 design spike for goal 1000045's C7/C8/C9). No platform guild existed (every "guild" in the tree is Discord's). Decisions: (1) three hub tables in `platform-identity`, in their own `guilds.js` (the 1,500-line ratchet), distinct from instance-local `goal_members`: guilds (slug, name, `visibility ∈ public|unlisted` with **no default**), members (`membership_kind ∈ owner|member`, never `role` per ADR 0174; a partial unique index holds exactly one owner; a per-member `shown_publicly`), and requests; (2) two consents to join, no self-join, through ADR 0202's connections lifecycle verbatim (silent decline, 90-day swallowed re-ask, 30-day read-time expiry); `accountActiveSql` floors the feature; an **unlisted guild 404s to everyone on the public read, members included**, and takes invites only, because a slug is guessable; (3) the public roster is `shown_publicly AND accountVisibleSql`, and widening a guild to public changes no member's flag but the flipping owner's, so consent given to a small audience is never reused for a large one; (4) **the privacy resolution, pending the owner's ratification:** a member is counted iff shown AND `rollupVisibleSql`, read-time, `no-store`, never stored, and N and M are both lengths of lists the reader can see. The guild record is therefore always a sum of numbers already on members' own public profiles, so nothing can be subtracted out. All-or-nothing is rejected (one member blanks everyone and hiding becomes costly), as is per-member consent to count hidden numbers (it breaks "hide_stats beats everything"). The trade-off: guilds of privacy-minded builders look smaller and rank lower. A union count of all members' projects is refused because it reveals shared private projects; (5) the namespace is `/g/<slug>`, `g` is reserved in the SEO spec's project-slug list, the slug is fixed in V1, and `tests/guild_namespace_reserved.mjs` pins the two documents together; (6) a guild engages a project only through the individual door: a guild application is each member's own vouched application, labelled through ADR 0260's live applicant-profile read (no new instance field); inviting a guild fans out ordinary individual invites to its public roster at that moment, **never a guild-level pre-approval** (that would let a guild owner decide admission to someone else's project); (7) the map ranks public guilds by size and counted works shipped, read-time, with a slug tiebreak, and R29 narrows to the visual. Scope changes for R24–R37 are tabled in the ADR, including R28's dependency on the abandoned R11 and R29/R31's archived orb goals.](0336-a-guilds-record-is-the-sum-of-what-its-members-already-show.md) | platform identity / privacy / social graph |

package/docs/module-api-changelog.md

@@ -2508,5 +2508,12 @@ is load-bearing: the script throws rather than guess if it is missing, and
         landed since 1.19.1015 with no explicit bump. run 36080388706. (task 1002620)
   1.19.1017 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
         landed since 1.19.1016 with no explicit bump. run 36081753087. (task 1002620)
+  (next carrier) — readApplicationVouch re-exported (task 1002285, goal 1000110;
+        ADR 0201 D2). The public POST /access-requests' check of the hub's signed
+        application vouch → { githubId, handle } or null. Core supplies the hub
+        public key and this instance's client_id, so the onboarding module passes
+        only a token and a login — the <redacted> precedent.
+  1.19.1018 — CI auto-patch (publish-on-merge, ADR 0161): carrier for merges
+        landed since 1.19.1017 with no explicit bump. run 36083406390. (task 1002620)
 ---------------------------------------------------------------------------
 ```

package/migrations/core_254_access_requests_applicant_handle.sql

@@ -0,0 +1,23 @@
+-- core_254_access_requests_applicant_handle.sql — the platform handle the hub's
+-- application vouch carried, beside the vouched github id (ADR 0333 D5; the column
+-- core_230 deferred to its writer, ADR 0208 D1).
+--
+-- Identity, not the record: the applicant's profile is still read live at review
+-- and never stored (ADR 0260 D4). NULL = unvouched, or the account had not cleared
+-- the consent floor, or the hub's account read failed. A snapshot — not re-synced
+-- on rename. The vouch MARK stays `applicant_github_id IS NOT NULL`; no admission
+-- path reads this column (ADR 0016).
+--
+-- Purely additive + idempotent; the previous release never names the column, so a
+-- replay or rollback is a no-op. access_requests is CORE-owned, so this is a core_
+-- migration (ADR 0108 §5); migrate.sh records the stem.
+
+BEGIN;
+
+ALTER TABLE access_requests
+  ADD COLUMN IF NOT EXISTS applicant_handle text;
+
+COMMENT ON COLUMN access_requests.applicant_handle IS
+  'The platform handle the hub application vouch carried at apply time (ADR 0201 D2.6, task 1002285): identity, never the record, which is read live at review. NULL on an unvouched row, or when the account had not cleared the consent floor. A snapshot — not re-synced on rename. DESCRIPTIVE ONLY — no admission path reads it (ADR 0016).';
+
+COMMIT;

package/modules/onboarding/routes/access-requests.js

@@ -80,6 +80,24 @@ function normalizeLogin(raw) {
   return String(raw || '').trim().replace(/^@/, '');
 }
 
+// The hub relay's signed application vouch rides in a HEADER, not the body: the
+// strict validator would 400 an unknown field on every older core (ADR 0201 D2.2).
+// Mirrored in modules/platform-identity/routes/my-projects.js (ADR 0091 §2).
+const APPLICATION_VOUCH_HEADER = 'X-Bongos-Platform-Assertion';
+
+// vouchPendingRow — a vouched re-application takes over an UNVOUCHED pending row
+// for its own login, name and note included, so a row someone else filed under
+// that login cannot pre-empt the real applicant's vouch (ADR 0333 D4). A row
+// already vouched is never re-stamped.
+function vouchPendingRow({ login, displayName, note, vouch }) {
+  return pool.query(
+    `UPDATE access_requests
+        SET display_name = $2, note = $3, applicant_github_id = $4, applicant_handle = $5, vouched_at = $6
+      WHERE lower(github_login) = lower($1) AND status = 'pending' AND applicant_github_id IS NULL`,
+    [login, displayName, note, vouch.githubId, vouch.handle, new Date()],
+  );
+}
+
 // How many applicant profiles one queue render may resolve from the hub (privacy
 // spec D7, task 1002972). The list itself returns up to 200 rows, and a render
 // that fired 200 cross-instance round-trips would make a reviewer wait on the
@@ -156,6 +174,10 @@ module.exports = function buildAccessRequestsRouter() {
     }
     const displayName = (req.body.display_name || '').trim() || null;
     const note = (req.body.note || '').trim() || null;
+    // A verified vouch that names this login → the account the hub confirmed; anything
+    // else → null, and the unvouched row this route always wrote (never a refusal,
+    // ADR 0201 D2.3). Descriptive only: no admission path reads it (ADR 0016).
+    const vouch = api.readApplicationVouch(req.get(APPLICATION_VOUCH_HEADER), { githubLogin: login });
 
     try {
       // Already a builder? They have an account — point them at sign-in instead
@@ -177,11 +199,12 @@ module.exports = function buildAccessRequestsRouter() {
         return res.fail('already_approved', { status: 409, message: "You're already approved — sign in with GitHub to enter." });
       }
 
+      // The three vouch columns are written in one statement, so they never disagree.
       const { rows } = await pool.query(
-        `INSERT INTO access_requests (github_login, display_name, note)
-         VALUES ($1, $2, $3)
+        `INSERT INTO access_requests (github_login, display_name, note, applicant_github_id, applicant_handle, vouched_at)
+         VALUES ($1, $2, $3, $4, $5, $6)
          RETURNING id, github_login, status, created_at`,
-        [login, displayName, note]
+        [login, displayName, note, vouch ? vouch.githubId : null, vouch ? vouch.handle : null, vouch ? new Date() : null]
       );
       // Post the request to #member-approvals so an Archon can 👍/👎 it from
       // Discord (task 1100). Fire-and-forget + best-effort — never blocks or
@@ -195,6 +218,10 @@ module.exports = function buildAccessRequestsRouter() {
       // Partial unique index → there's already an open request for this login.
       // Treat as success-ish: the Archon already has them in the queue.
       if (err.code === '23505') {
+        if (vouch) {
+          try { await vouchPendingRow({ login, displayName, note, vouch }); }
+          catch (e) { log.error({ err: e.message }, '[gds] POST /access-requests: vouching the open request failed (non-fatal)'); }
+        }
         return res.status(200).json({ ok: true, already_pending: true });
       }
       console.error('[gds] POST /access-requests', err);
@@ -276,7 +303,7 @@ module.exports = function buildAccessRequestsRouter() {
       const { rows } = await pool.query(
         `SELECT ar.id, ar.github_login, ar.display_name, ar.note, ar.status,
                 ar.created_at, ar.resolved_at,
-                ar.applicant_github_id, ar.vouched_at,
+                ar.applicant_github_id, ar.applicant_handle, ar.vouched_at,
                 (ar.applicant_github_id IS NOT NULL) AS vouched,
                 rb.github_login AS resolved_by_login
            FROM access_requests ar

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

@@ -14,14 +14,18 @@
 // no PKI service.
 //
 // The assertion is a compact JWT (alg=EdDSA). The wire format is mirrored, by
-// necessity, in the instance-side verifier (src/bongos/auth.js verifyHubAssertion)
-// — the two sides live across the core<->module boundary and cannot share code
-// (ADR 0091 §2 boundary-forced duplication). Keep them in lockstep:
+// necessity, in the instance-side verifiers (src/bongos/auth-idp.js) — the two
+// sides live across the core<->module boundary and cannot share code (ADR 0091
+// §2 boundary-forced duplication). Keep them in lockstep:
 //   token = base64url(JSON(header)) "." base64url(JSON(payload)) "." base64url(sig)
 //   header  = { alg: "EdDSA", typ: "JWT" }
-//   payload = { iss:"cloudbongos-hub", aud:<client_id>, sub:<github_id>,
-//               github_login, display_name, avatar_url, iat, exp, jti }
+//   payload = { iss:"cloudbongos-hub", aud:<client_id>, sub:<github_id>, …, iat, exp, jti }
 //   sig     = Ed25519(privkey, utf8(`${b64u(header)}.${b64u(payload)}`))
+// Three token kinds share that envelope, and each verifier demands exactly what
+// the other two lack, so none is ever accepted as another:
+//   login assertion   … = github_login, display_name, avatar_url   (no purpose)
+//   logout token      … = purpose:'backchannel-logout'             (no identity)
+//   application vouch … = applicant_login, handle, purpose:'application'
 'use strict';
 
 const crypto = require('node:crypto');
@@ -75,24 +79,17 @@ function hubPublicKeyB64() {
   return pub.export({ type: 'spki', format: 'der' }).toString('base64');
 }
 
-// Mint an audience-scoped, short-lived EdDSA assertion for a federated client. The
-// payload carries IDENTITY ONLY (never a rank). `nowMs`/`jti` are injectable for
-// deterministic tests. Returns the compact token string.
-function mintHubAssertion(
-  { clientId, githubId, githubLogin, displayName, avatarUrl },
-  { signingKey, nowMs, jti } = {},
-) {
+// signHubToken — the ONE envelope every hub token is minted in: issuer, the
+// caller's claims, then iat/exp (~120s) and a fresh jti. The three minters below
+// differ only in the claims they pass. Throws when no signing key is configured.
+function signHubToken(claims, { signingKey, nowMs, jti } = {}) {
   const key = signingKey || loadHubSigningKey();
   if (!key) throw new Error('hub signing key not configured');
   const iat = Math.floor((nowMs ?? Date.now()) / 1000);
   const header = { alg: 'EdDSA', typ: 'JWT' };
   const payload = {
     iss: ISSUER,
-    aud: String(clientId),
-    sub: String(githubId),
-    github_login: githubLogin,
-    display_name: displayName ?? null,
-    avatar_url: avatarUrl ?? null,
+    ...claims,
     iat,
     exp: iat + Math.floor(ASSERTION_TTL_MS / 1000),
     jti: jti || crypto.randomBytes(12).toString('base64url'),
@@ -102,6 +99,22 @@ function mintHubAssertion(
   return `${signingInput}.${sig}`;
 }
 
+// Mint an audience-scoped, short-lived EdDSA assertion for a federated client. The
+// payload carries IDENTITY ONLY (never a rank). `nowMs`/`jti` are injectable for
+// deterministic tests. Returns the compact token string.
+function mintHubAssertion(
+  { clientId, githubId, githubLogin, displayName, avatarUrl },
+  opts = {},
+) {
+  return signHubToken({
+    aud: String(clientId),
+    sub: String(githubId),
+    github_login: githubLogin,
+    display_name: displayName ?? null,
+    avatar_url: avatarUrl ?? null,
+  }, opts);
+}
+
 // The purpose marker that distinguishes a back-channel LOGOUT token from a login
 // assertion. Both are hub-signed EdDSA JWTs, but a logout token carries `purpose`
 // + NO identity fields, and a login assertion carries identity + NO `purpose` —
@@ -119,23 +132,28 @@ const LOGOUT_PURPOSE = 'backchannel-logout';
 // Same asymmetric signing + ~120s TTL + aud-binding as mintHubAssertion, so a
 // token minted for one instance can't be replayed against another. nowMs/jti
 // injectable for deterministic tests.
-function mintHubLogoutToken({ clientId, githubId }, { signingKey, nowMs, jti } = {}) {
-  const key = signingKey || loadHubSigningKey();
-  if (!key) throw new Error('hub signing key not configured');
-  const iat = Math.floor((nowMs ?? Date.now()) / 1000);
-  const header = { alg: 'EdDSA', typ: 'JWT' };
-  const payload = {
-    iss: ISSUER,
+function mintHubLogoutToken({ clientId, githubId }, opts = {}) {
+  return signHubToken({ aud: String(clientId), sub: String(githubId), purpose: LOGOUT_PURPOSE }, opts);
+}
+
+// The purpose marker on an APPLICATION VOUCH — kept in lockstep with the instance
+// verifier (src/bongos/auth-idp.js HUB_APPLICATION_PURPOSE).
+const APPLICATION_PURPOSE = 'application';
+
+// Mint the APPLICATION VOUCH the join relay sends a project (ADR 0201 D2, ADR 0333):
+// "this request comes from this account" — identity + handle, never a rank or record.
+// The login rides as `applicant_login`, NOT `github_login`: every login verifier any
+// core ever shipped demands `github_login`, so even a core that predates the purpose
+// refusal cannot accept a vouch as a device sign-in. `handle` is null unless the
+// caller cleared the consent floor.
+function mintHubApplicationVouch({ clientId, githubId, githubLogin, handle }, opts = {}) {
+  return signHubToken({
     aud: String(clientId),
     sub: String(githubId),
-    purpose: LOGOUT_PURPOSE,
-    iat,
-    exp: iat + Math.floor(ASSERTION_TTL_MS / 1000),
-    jti: jti || crypto.randomBytes(12).toString('base64url'),
-  };
-  const signingInput = `${b64uJson(header)}.${b64uJson(payload)}`;
-  const sig = crypto.sign(null, Buffer.from(signingInput, 'utf8'), key).toString('base64url');
-  return `${signingInput}.${sig}`;
+    applicant_login: githubLogin,
+    handle: handle ?? null,
+    purpose: APPLICATION_PURPOSE,
+  }, opts);
 }
 
 module.exports = {
@@ -146,6 +164,7 @@ module.exports = {
   loadHubSigningKey,
   hubSigningConfigured,
   hubPublicKeyB64,
+  mintHubApplicationVouch,
   mintHubAssertion,
   mintHubLogoutToken,
 };

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

@@ -25,6 +25,8 @@ const api = require('../../../src/module-api');
 const pi = require('../platform-identity');
 const projectStats = require('../project-stats');
 const applicationEcho = require('../application-echo');
+const hubKeys = require('../hub-keys');
+const { isAccountActive } = require('../account-visibility');
 const { projectPublishability } = require('../publish-gate');
 
 const { pool, requireBuilder, validateOrRespond, userAgent } = api;
@@ -116,6 +118,35 @@ function relayApplicantName(displayName) {
   return name || null;
 }
 
+// Where the relay carries the vouch — mirrored by the project's public POST
+// (modules/onboarding/routes/access-requests.js; boundary-forced, ADR 0091 §2).
+const APPLICATION_VOUCH_HEADER = 'X-Bongos-Platform-Assertion';
+
+// applicationVouchHeaders — the signed vouch for the HUB SESSION's own account
+// (never a body field), as headers to add, or {} (ADR 0333). Best-effort, never a
+// gate. The handle rides only past isAccountActive — the floor the applicant view
+// itself applies, so the vouch shows no handle the reviewer's queue would not.
+async function applicationVouchHeaders(client, builder) {
+  const signingKey = hubKeys.loadHubSigningKey();
+  if (!signingKey || !pi.isNumericGithubId(builder.github_id)) return {};
+  let handle = null;
+  try {
+    const account = await pi.getAccount(builder.github_id, { pool });
+    if (account && isAccountActive(account)) handle = account.handle || null;
+  } catch (e) {
+    api.logger('platform-identity').warn(`vouch handle read failed, vouching without one (non-fatal): ${e && e.message}`);
+  }
+  try {
+    const vouch = hubKeys.mintHubApplicationVouch({
+      clientId: client.client_id, githubId: builder.github_id, githubLogin: builder.github_login, handle,
+    }, { signingKey });
+    return { [APPLICATION_VOUCH_HEADER]: vouch };
+  } catch (e) {
+    api.logger('platform-identity').warn(`application vouch mint failed, relaying unvouched (non-fatal): ${e && e.message}`);
+    return {};
+  }
+}
+
 module.exports = function myProjectsRoutes() {
   const router = express.Router();
 
@@ -202,10 +233,11 @@ module.exports = function myProjectsRoutes() {
       // the project decides (open-join, or request/invite per ADR 0112). We post to
       // the registry-trusted origin, never the caller's raw input.
       let outcome = null;
+      const vouchHeaders = await applicationVouchHeaders(client, req.builder);
       try {
         const r = await fetch(`${client.origin}/api/bongos/access-requests`, {
           method: 'POST',
-          headers: { 'Content-Type': 'application/json', Accept: 'application/json', 'User-Agent': userAgent() },
+          headers: { 'Content-Type': 'application/json', Accept: 'application/json', 'User-Agent': userAgent(), ...vouchHeaders },
           body: JSON.stringify({
             github_login: req.builder.github_login,
             display_name: relayApplicantName(req.builder.display_name),

package/package-lock.json

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