@bongos/core 1.19.579 → 1.19.580

package/.bongos-core.json

@@ -2,22 +2,22 @@
   "artifact": "bongos-core",
   "manifest_schema": 1,
   "generator": "scripts/gds/package-core.js",
-  "core_version": "1.19.579",
-  "core_contract": "1.19.579",
-  "source_commit": "8b206e9f473df316fc1981854a479d1ba509d76e",
+  "core_version": "1.19.580",
+  "core_contract": "1.19.580",
+  "source_commit": "23d256818bb7470aa5d203825abed34ab13f6fcf",
   "source_ref": "HEAD",
-  "built_at": "2026-09-07T17:52:17.407Z",
+  "built_at": "2026-09-07T18:50:35.452Z",
   "redaction": {
     "model": "docs-redacted+functional-verbatim",
-    "docs_redacted": 452,
+    "docs_redacted": 453,
     "agent_docs_stubbed": 24,
-    "functional_verbatim": 2047,
+    "functional_verbatim": 2051,
     "rules": 3,
     "gate_literals": 3,
     "gate": "passed"
   },
-  "file_count": 2523,
-  "tree_sha256": "bd13bef2ae141fa766ed5c8a67894be21c62263079037e763bc1533ff500afdc",
+  "file_count": 2528,
+  "tree_sha256": "293d3e0eb2f7b0d375fde65d1b6e75816035857c06a98f69f91d0e213a21f8ad",
   "files": [
     {
       "path": ".claude/skills/blocker-review/SKILL.md",
@@ -372,12 +372,12 @@
     {
       "path": "clients/bongos-client/README.md",
       "mode": "0000644",
-      "sha256": "f94a07e3c135a5d6c41a2d16f722e86b990362996042dc2a5e05b2020f8cf376"
+      "sha256": "48a76d533215b8c0885fa77f59fc0e8915262db6b57029f6850692882e6e7455"
     },
     {
       "path": "clients/bongos-client/bongos-client.global.js",
       "mode": "0000644",
-      "sha256": "06d1814637fe2898f0d93a3870726d53102d02feeae4611fcca80f195e2e26e4"
+      "sha256": "c7fe87ceb18e7e1c10e629d002fb6f322ee540606c3ec9f6d38741dac7a55e0f"
     },
     {
       "path": "clients/bongos-client/examples/hello-world.mjs",
@@ -387,17 +387,17 @@
     {
       "path": "clients/bongos-client/index.cjs",
       "mode": "0000644",
-      "sha256": "ee0e25848a938f675e7a2e6e0a48983308117ecafe93ca219f4f1df49cf7ea51"
+      "sha256": "d80b05be7a602fa825f5f45e5b7f2bc002473a4731e2530df19fa3043f0c07fc"
     },
     {
       "path": "clients/bongos-client/index.d.ts",
       "mode": "0000644",
-      "sha256": "adaa20c8ce6bee76dc289f10929014382aa89d7373f94ddafc84f4c87eeb0ed4"
+      "sha256": "e5cfa78c545e60771166ae4118e18f5c7bcf911db649c115c2831a028de3562b"
     },
     {
       "path": "clients/bongos-client/index.mjs",
       "mode": "0000644",
-      "sha256": "6a3e4df57180f3c182fbadabe94030d06f125373c9336a7a4160015f1df5b11e"
+      "sha256": "47ae66627693378c276031754aca717ecc01e8e5038c4cf98ed844e5c03ee524"
     },
     {
       "path": "clients/bongos-client/package.json",
@@ -1814,20 +1814,25 @@
       "mode": "0000644",
       "sha256": "772b9153d882f6bbd5000ee90b83e05d550ee4f04d4f5392db36e223d9a58c59"
     },
+    {
+      "path": "docs/adr/0260-the-application-is-the-consent-and-the-echo-is-the-gate.md",
+      "mode": "0000644",
+      "sha256": "fa04f8d71fff8186ae975a949c045ca7481bd0f22f395cb8c7397bbe03ddd449"
+    },
     {
       "path": "docs/adr/README.md",
       "mode": "0000644",
-      "sha256": "bf52fa642d9a576a88f961b46fbb68352e3fd8dd79004440f5e4182e549039ed"
+      "sha256": "1fa7dcf1456d26896e5cec77026ace0f08db8bed65527dee563cd7fdd2d07525"
     },
     {
       "path": "docs/api-reference.md",
       "mode": "0000644",
-      "sha256": "0a622847ab68980279beba2e1a54813b2393107144f88dd31228fe4dfd248b90"
+      "sha256": "450613589b6b480ba2d6789731003794749c0dd972fcd8636380fa5814d68807"
     },
     {
       "path": "docs/api/openapi.json",
       "mode": "0000644",
-      "sha256": "60ca0b131c661df16fb993182d2085d0b04ea15a4d91bec4318c3413fb8dc311"
+      "sha256": "c3a329219460b2508d51009ff8f77bdc4733f3a17ad2776553dc7bce483555c4"
     },
     {
       "path": "docs/architecture.md",
@@ -1852,12 +1857,12 @@
     {
       "path": "docs/copy-inventory.md",
       "mode": "0000644",
-      "sha256": "da770863626202ff2566de7f0a152eebc086662c74d86423794d378fca2d83e6"
+      "sha256": "c4b6557f79a876b18cfc020ea4d45b8dfa419c9c37cab3fb2c629d85939bd75d"
     },
     {
       "path": "docs/copy-registry.json",
       "mode": "0000644",
-      "sha256": "423614f0519d1e94e605e439b53a2bac7a63c2ae8005b0021c71e6c81f38edfc"
+      "sha256": "867399ce0002d6a1f509969544ad9589db6769352597471b495c66749271bb3c"
     },
     {
       "path": "docs/design/apex-pass-2-direction.md",
@@ -2692,7 +2697,7 @@
     {
       "path": "docs/file-map.md",
       "mode": "0000644",
-      "sha256": "f43e8946ecb5c96dc7af0bcee49010245df577eee62381701d2aef1c67455662"
+      "sha256": "dd0684364a3ccd656f8201367e23775d578a84b385f49a901f7fc4205312b344"
     },
     {
       "path": "docs/handoff-template.md",
@@ -2702,7 +2707,7 @@
     {
       "path": "docs/module-api-changelog.md",
       "mode": "0000644",
-      "sha256": "cb7bb494b4b2ad905f1067b6f3c11e6331faa8beaad533c70d4a5009c456a807"
+      "sha256": "2237a99993338a480835d8cf8c62bc0925585d46d01a9859b5ba3afa108af5d1"
     },
     {
       "path": "docs/modules-contract.md",
@@ -4102,7 +4107,7 @@
     {
       "path": "modules/dev-box/app/src/vendor/bongos-client.cjs",
       "mode": "0000644",
-      "sha256": "ee0e25848a938f675e7a2e6e0a48983308117ecafe93ca219f4f1df49cf7ea51"
+      "sha256": "d80b05be7a602fa825f5f45e5b7f2bc002473a4731e2530df19fa3043f0c07fc"
     },
     {
       "path": "modules/dev-box/app/test/unit.mjs",
@@ -4992,7 +4997,7 @@
     {
       "path": "modules/hall-ui/public/oversight.css",
       "mode": "0000644",
-      "sha256": "9aa3fd3f662274571e049eb9931f8dd575eef527a624bc6a5d57102061f54936"
+      "sha256": "13d46f29e77ba9ca30ab52de2e0413f2fcb68bfec44de032730d4d135530e4ba"
     },
     {
       "path": "modules/hall-ui/public/pair.css",
@@ -5312,7 +5317,7 @@
     {
       "path": "modules/hall-ui/public/watch.js",
       "mode": "0000644",
-      "sha256": "66a3fc7edf59112c1126c6c1c96244ac3cae1c0aea99f946c96b202d14f2cbac"
+      "sha256": "058f25fcef75b3db5410ea7fa6b09515b0b7fddc64a7698c1a1c44e753c8a651"
     },
     {
       "path": "modules/hall-ui/public/watch.states.json",
@@ -5917,7 +5922,7 @@
     {
       "path": "modules/onboarding/routes/access-requests.js",
       "mode": "0000644",
-      "sha256": "ebebd2ce84727de2dff8411a6279aefb3792de51577a5ba04dc7d565cbce5494"
+      "sha256": "3c66a404347ef1b93edcf5c63a902c9561b0a3f9bd9bc6c17e8a2a1f1b5f6707"
     },
     {
       "path": "modules/onboarding/routes/onboarding.js",
@@ -5934,10 +5939,15 @@
       "mode": "0000644",
       "sha256": "020279ae50f2f9e7a004fe571e5ca14493ad26bd22c395cc4805f759f5560b72"
     },
+    {
+      "path": "modules/platform-identity/applicant-profile.js",
+      "mode": "0000644",
+      "sha256": "12c1d00965d2d386480bdf94673ab6f140c8ee6ba44a5995a2d1b9593c012d20"
+    },
     {
       "path": "modules/platform-identity/application-echo.js",
       "mode": "0000644",
-      "sha256": "3793f588d62eaa96a74da6bceb55043e8a9de35bc120dbe63f26bcc2b7e904da"
+      "sha256": "8217660dc23b57ba0fb54d6375aca9aec190c7abb1d70f9d44d4e290da272c64"
     },
     {
       "path": "modules/platform-identity/canonical-profile.js",
@@ -6117,7 +6127,7 @@
     {
       "path": "modules/platform-identity/recruiter-sliver.js",
       "mode": "0000644",
-      "sha256": "e1385b83ac5bb82d13ffbe5070043c2fd0ca20385b3d62e8331ef917d9fca496"
+      "sha256": "4f6854050e3c7459f698c550577fa97958a573d7f1981c9de4d29417af2669c0"
     },
     {
       "path": "modules/platform-identity/routes/connections.js",
@@ -6152,7 +6162,7 @@
     {
       "path": "modules/platform-identity/routes/sso.js",
       "mode": "0000644",
-      "sha256": "dbc8eeab6b1911b7fdc8b29e3d10871d355d2dead926a0742e9a816a72215dba"
+      "sha256": "6921323c299eee14e2db75b2c1716e35c245f7c971e6aec57c2b339b106f4d87"
     },
     {
       "path": "modules/platform-identity/scouting-authz.js",
@@ -7562,12 +7572,12 @@
     {
       "path": "package-lock.json",
       "mode": "0000644",
-      "sha256": "ce40726e213f4a94fd3983d81c5919e4cc435fda1d666e7cf598fc2f963b8741"
+      "sha256": "28db9a2f030a69e041ee0c0d277238e7f5f7be0ba8a9bd370ffc2fc644a3c1d1"
     },
     {
       "path": "package.json",
       "mode": "0000644",
-      "sha256": "6ce1fcd5c0378c8001b8249d8359d04ecfa5730e07dc3e21cda4952fcf1deeae"
+      "sha256": "cbec2151e643d5ff302e5d98166488c6298669395eafe9e037a2f39ea23db5c9"
     },
     {
       "path": "public-docs/index.html",
@@ -8982,7 +8992,7 @@
     {
       "path": "src/bongos/auth-admission.js",
       "mode": "0000644",
-      "sha256": "8dc4cc0ab956d387b8044c22e83fce883f2f0129ed27c03503f7348e9d4f00bb"
+      "sha256": "aaa113f476a1d8196324379f8fd78aab22f577455fa0378bac3200b98e6a887f"
     },
     {
       "path": "src/bongos/auth-config.js",
@@ -9007,7 +9017,7 @@
     {
       "path": "src/bongos/auth.js",
       "mode": "0000644",
-      "sha256": "517e25a2ca9b9adafa993725802af9e7fc1708f0a5609102ddce593e82478ca2"
+      "sha256": "eeb1831ab3d033598e0bcd57c30589cac583a1259c98b2dd49fbd9bb7725e11b"
     },
     {
       "path": "src/bongos/cascade-dispatch.js",
@@ -9272,7 +9282,7 @@
     {
       "path": "src/module-api.js",
       "mode": "0000644",
-      "sha256": "c1da85daf5425cfb3bbd7d8e29e6995e90ead6088565476973954ca366ef14f5"
+      "sha256": "a3e2c3a0b4099d54d8cd5c309186feb8a0c7073074095c4d10861f71e9f36ce4"
     },
     {
       "path": "src/module-loader/catalog.js",
@@ -9364,6 +9374,11 @@
       "mode": "0000644",
       "sha256": "125edcec8c7d7536365b9675daa1fceb9fe072a30e2a4a68ee2911cd258a8c10"
     },
+    {
+      "path": "tests/adr_renumber_integrity.mjs",
+      "mode": "0000644",
+      "sha256": "bdc9d3678e12dee3f3252785ca82e06071421762c7146cbc1591d3fc2ec72180"
+    },
     {
       "path": "tests/agents_spawn.mjs",
       "mode": "0000644",
@@ -9424,6 +9439,16 @@
       "mode": "0000644",
       "sha256": "ac84c8d8b1e2f54ef278506570ed657e68d2da4e136968b0df31b51f943af4bb"
     },
+    {
+      "path": "tests/applicant_profile_boundary.mjs",
+      "mode": "0000644",
+      "sha256": "beefe27f5f753185cf3513f6576e55ee44680760ff2d8eed4ced93d56ec92b77"
+    },
+    {
+      "path": "tests/applicant_profile_read_bounds.mjs",
+      "mode": "0000644",
+      "sha256": "185fed67d8b3e65121af637e37392c21d4bcd892bb2b305704479f42ff5987c7"
+    },
     {
       "path": "tests/application_echo.mjs",
       "mode": "0000644",
@@ -11292,7 +11317,7 @@
     {
       "path": "tests/module_api.mjs",
       "mode": "0000644",
-      "sha256": "39812c560bcd88e3b3a7938ed2447fbd4ab24b0f925e9662b375910bcbe7f1da"
+      "sha256": "157d551b9a99320198f22d32ce335fa4166414dc1818d11ef23a0ea05ac80a76"
     },
     {
       "path": "tests/module_api_lazy.mjs",
@@ -11857,7 +11882,7 @@
     {
       "path": "tests/recruiter_sliver_boundary.mjs",
       "mode": "0000644",
-      "sha256": "cad269f556293e0caa234561f5764f90998a5d133b1e0147a5bbf22403c55e3a"
+      "sha256": "a9ad552e7060898e5c94db8af29e63d7cad568294c240c48bef78859a0558ec6"
     },
     {
       "path": "tests/redteam_followup_kind.mjs",
@@ -12592,7 +12617,7 @@
     {
       "path": "tests/watch_applications_queue.mjs",
       "mode": "0000644",
-      "sha256": "b1f7df5aa40b89f8737c76d94def15c539514f7f439cca79a034bf37b922158d"
+      "sha256": "52c5c056c33b0b2ee91076b29e24ea5b650a0148c603fdde5136e60d6c6e926a"
     },
     {
       "path": "tests/web_admission_status.mjs",

package/clients/bongos-client/README.md

@@ -5,7 +5,7 @@ A **generated**, zero-dependency typed client for the Bongos API — produced fr
 by hand; it regenerates when the spec changes, so it can never drift from the routes.
 
 - API version: **v1** (served at `/api/bongos/v1`)
-- 358 operations across 55 resource groups
+- 359 operations across 55 resource groups
 
 ## Install
 

package/clients/bongos-client/bongos-client.global.js

@@ -793,6 +793,8 @@ function createClient(opts = {}) {
     "sso": {
       // POST /sso/activity/rollup — rank: public — POST /sso/activity/rollup
       postSsoActivityRollup: (args) => request("POST", "/sso/activity/rollup", { hasBody: true }, args),
+      // POST /sso/applicant-profile — rank: public — POST /sso/applicant-profile
+      postSsoApplicantProfile: (args) => request("POST", "/sso/applicant-profile", { hasBody: true }, args),
       // GET /sso/authorize — rank: public — GET /sso/authorize
       getSsoAuthorize: (args) => request("GET", "/sso/authorize", { hasBody: false }, args),
       // POST /sso/device/poll — rank: public — POST /sso/device/poll

package/clients/bongos-client/index.cjs

@@ -792,6 +792,8 @@ function createClient(opts = {}) {
     "sso": {
       // POST /sso/activity/rollup — rank: public — POST /sso/activity/rollup
       postSsoActivityRollup: (args) => request("POST", "/sso/activity/rollup", { hasBody: true }, args),
+      // POST /sso/applicant-profile — rank: public — POST /sso/applicant-profile
+      postSsoApplicantProfile: (args) => request("POST", "/sso/applicant-profile", { hasBody: true }, args),
       // GET /sso/authorize — rank: public — GET /sso/authorize
       getSsoAuthorize: (args) => request("GET", "/sso/authorize", { hasBody: false }, args),
       // POST /sso/device/poll — rank: public — POST /sso/device/poll

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

@@ -355,6 +355,8 @@ export interface PostSessionsRequest { session_id: string; task_ids?: number[];
 export interface PostSessionsResponse { skipped?: boolean; reason?: unknown; session?: unknown; token_reward?: unknown }
 export interface PostSsoActivityRollupRequest { client_id: string; client_secret: string; github_id: StringifiableId; credits?: number; tasks_shipped?: number; karma?: number; rank?: string; disciplines?: unknown; recent_ships?: unknown }
 export interface PostSsoActivityRollupResponse { ok: boolean }
+export interface PostSsoApplicantProfileRequest { client_id: string; client_secret: string; github_id: StringifiableId }
+export interface PostSsoApplicantProfileResponse { profile: unknown }
 export interface PostSsoDevicePollRequest { device_code: string }
 export interface PostSsoDeviceStartRequest { origin: string }
 export interface PostSsoMembershipCheckInRequest { client_id: string; client_secret: string; github_id: StringifiableId; github_login: string; display_name?: string; avatar_url?: string; membership_kind?: string; role?: string }
@@ -1119,6 +1121,8 @@ export interface BongosClient {
   "sso": {
     /** POST /sso/activity/rollup — rank: public */
     postSsoActivityRollup(args: RequestArgs & { body: PostSsoActivityRollupRequest }): Promise<PostSsoActivityRollupResponse>;
+    /** POST /sso/applicant-profile — rank: public */
+    postSsoApplicantProfile(args: RequestArgs & { body: PostSsoApplicantProfileRequest }): Promise<PostSsoApplicantProfileResponse>;
     /** GET /sso/authorize — rank: public */
     getSsoAuthorize(args?: RequestArgs): Promise<ApiResponse>;
     /** POST /sso/device/poll — rank: public */

package/clients/bongos-client/index.mjs

@@ -789,6 +789,8 @@ export function createClient(opts = {}) {
     "sso": {
       // POST /sso/activity/rollup — rank: public — POST /sso/activity/rollup
       postSsoActivityRollup: (args) => request("POST", "/sso/activity/rollup", { hasBody: true }, args),
+      // POST /sso/applicant-profile — rank: public — POST /sso/applicant-profile
+      postSsoApplicantProfile: (args) => request("POST", "/sso/applicant-profile", { hasBody: true }, args),
       // GET /sso/authorize — rank: public — GET /sso/authorize
       getSsoAuthorize: (args) => request("GET", "/sso/authorize", { hasBody: false }, args),
       // POST /sso/device/poll — rank: public — POST /sso/device/poll

package/docs/adr/0260-the-application-is-the-consent-and-the-echo-is-the-gate.md

@@ -0,0 +1,146 @@
+# ADR 0260 — An application IS the consent, and the hub's own echo is the gate: the D7 applicant view
+
+- **Status:** accepted
+- **Date:** 2026-09-03
+- **Task:** [task 1002972](https://cloudbongos.com/builders#/task/1002972) (PV7, goal 1000045 — criterion C4)
+- **Relates to:** `docs/specs/<redacted>.md` **D7** (owner-signed 2026-08-16), [ADR 0215](<redacted>.md) (the D3 sliver this reuses), [ADR 0205](<redacted>.md) + security report 1000027 (client credentials name a project, never a person), [ADR 0201](<redacted>.md) D1.2/D1.3 (the vouch mark and the statusless echo), [ADR 0171](<redacted>.md) D4/D5 (indistinguishable nulls, no-store), [ADR 0016](<redacted>.md) (descriptive, never authority), [ADR 0083](<redacted>.md) (the doorway)
+
+## Context
+
+Spec D7 asks for one thing in one sentence: a reviewer looking at an application
+sees **what the applicant's own profile rules would already show them**, plus the
+applicant's note, **evaluated live at review time**. Public account → the public
+profile view. Private account → the D3 sliver. No new disclosure class.
+
+Two halves of that already existed when this task opened. The applicant's note
+reaches the project's queue through the join relay (task 1002330,
+`relayApplicationNote`). The D3 projection exists and is proved
+([ADR 0215](<redacted>.md)). What did not
+exist was the **rule** — which of the two views an applicant gets — and the
+**path** by which a project's reviewer queue could ask the hub for it.
+
+Three things about that path are not obvious, and each could have been got wrong
+in a way that looked like a simplification.
+
+## Decision
+
+### D1 — The rule is one port composing the two EXISTING views, never a third shape
+
+`modules/platform-identity/applicant-profile.js` answers
+`null | { view:'public', account, cross_project } | { view:'sliver', sliver }`.
+
+The public branch's rollup half is `getPublicProfileExtras` — the very port the
+canonical `/u/<handle>` page calls. The private branch's projection is
+`sliverShapeFor`, exported from `recruiter-sliver.js` — the very function the
+recruiting route serializes. **Neither branch builds its own object**, because a
+third five-key lookalike *is* the new disclosure class D7 forbids: free to drift
+from the original field by field, and uncovered by the whitelist proof over it.
+
+`tests/applicant_profile_boundary.mjs` asserts both key sets against the
+**modules' own exported lists**, never against copies kept in the test.
+
+### D2 — The APPLICATION is the consent, not the recruiting opt-in
+
+This is the one place the applicant view differs from the recruiter sliver, and
+it is the decision most likely to be "tidied" away later.
+
+`getRecruiterSliver` floors on `recruiterSliverVisibleSql` = consent **and
+recruiting reach**, because a recruiter browsing a directory was invited by
+nobody. An applicant has done something a browsing recruiter has not — spec D7
+says it in those words: **"applying is an explicit act"**.
+
+So routing this port through `getRecruiterSliver` would be wrong *in the
+direction that looks safe*. `recruiter_discoverable` defaults to **false** for a
+private account, so a private builder who deliberately applied would show their
+reviewer **nothing at all**, and criterion C4 would be satisfied by an empty box.
+The reach opt-out governs the *recruiting surface* — `account-visibility.js` says
+exactly that of `scoutingListableSql` — and was never a gate on a door the
+account itself knocked on.
+
+**What the swap does NOT relax**, and this is what keeps it from meaning
+"applying opts you into everything":
+
+- `accountActiveSql` still floors it — `profile_state='active'` **and**
+  `terms_accepted_at IS NOT NULL`. A provisional account and one that never
+  accepted the platform terms disclose nothing, applying or not.
+- `hide_stats` is untouched in both branches. Applying is consent to be **seen**,
+  never consent to be **counted**.
+- The existence axis stays off, for ADR 0215 D1's reason: the private account is
+  precisely this rule's subject.
+
+The proof asserts the swap **in both directions on the same account** — `PRIVOUT`
+gets an applicant view and gets `null` from `getRecruiterSliver` — so the
+tempting refactor cannot pass quietly.
+
+### D3 — The gate is the hub's own echo, because client credentials name a project and not a person
+
+`POST /sso/applicant-profile` is authenticated by `client_id` + `client_secret`,
+like its two siblings. **That authentication is not sufficient on its own**, and
+this is the whole security argument for the route.
+
+[ADR 0205](<redacted>.md) / security
+report 1000027 is the lesson `/sso/membership/check-in` and `/sso/activity/rollup`
+both had to learn: credentials prove *which project* is calling and say **nothing
+about who the `github_id` in the body is**. Without a per-subject witness, this
+route is a **bulk disclosure oracle** over every account on the platform —
+private ones included, since D7's private branch is exactly the disclosure the
+existence axis normally withholds. That is strictly worse than the rollup hole it
+would mirror.
+
+The witness is `platform_identity_application_echoes` — the statusless
+"you applied to this project on this date" row from
+[ADR 0201](<redacted>.md) D1.3. It is
+the right witness because **the hub writes it itself**, in its own join relay,
+only after the project answered the relayed application with a success. A client
+cannot assert itself into that table. `applicationBacksProfileRead` is the exact
+analogue of `membershipBacksRollup`: a boolean, and the narrowest cross-account
+read the table has — the caller must already name both the account and the
+project, and there is no listing by `client_id`, so a project learns nothing
+about who applied that it was not already told at its own door.
+
+It reuses the **same 30-day window**, and that is load-bearing rather than tidy:
+when the echo stops matching, the view stops rendering, because the platform has
+stopped vouching for the link between that queue row and that account.
+
+Refusal is **404, never 403** — a 403 would confirm the `github_id` names a real
+account. And the gate runs **before any account is read**: the proof asserts that
+on the statement log, not on the response, because a gate that refuses *after*
+reading has already done the disclosure work.
+
+### D4 — LIVE means nothing is stored, at either end
+
+Nothing about the applicant is written to the `access_requests` row and nothing is
+cached on the project. The profile is resolved on **every render**
+(`attachApplicantProfiles`), so an applicant who hides their stats, goes private,
+or loses their account between applying and being reviewed is answered by the next
+read of the queue — criterion C2's "immediately". A snapshot taken at apply time
+would keep publishing a consent that had since been withdrawn, for as long as the
+request sat in the queue. The hub sends `Cache-Control: no-store`; the project
+keeps nothing.
+
+### D5 — The queue keys on the VOUCH, never on `github_login`
+
+`attachApplicantProfiles` resolves only rows carrying `applicant_github_id` — the
+hub's own assertion about who filed the request (`core_230`). `POST /access-requests`
+is the one **public unauthenticated write** on the GDS, so `github_login` is a
+string anybody may type. Resolving a cross-project record against an unvouched
+login is precisely the impersonation surface the vouch exists to close: file a
+request naming a well-known builder, let the owner read that builder's excellent
+record, and walk in. An unvouched row gets `profile: null`, always.
+
+### D6 — The credential stays in core; the module gets a narrow port
+
+The hub call lives in `src/bongos/auth-admission.js` beside the two other calls
+that hold the hub client secret, and `loadIdpConfig` stays **off** the doorway —
+putting it there would hand every module the credential that speaks for the whole
+project. `<redacted>(githubId)` is published instead: one
+`github_id` in, one already-bounded view out. The module can neither widen the
+request nor re-address it.
+
+## Consequences
+
+- **The path is complete but DORMANT until R09 ([task 1002285](https://cloudbongos.com/builders#/task/1002285)) ships the vouch writer.** Nothing in the tree writes `applicant_github_id` today, so every queue row currently resolves `profile: null` and renders exactly as it did before. This is stated rather than glossed: the feature is wired end to end and proved, and it lights up on the day R09 lands its writer — the sequencing R08's own migration comment predicted. 1002972's declared dependency was PV3 alone; **the real dependency on R09 was missing from the graph.**
+- The reviewer queue degrades rather than breaks: a hub outage, a self-hosted instance with no hub, and an applicant with no echo all render a row with its login, note and vouch pill and no profile block.
+- `MAX_LIVE_PROFILE_READS = 25` caps per-render hub round-trips against a 200-row queue. It bites on vouched rows in list order, so the rows a reviewer acts on carry the profile. Raising it buys detail and costs latency; it changes nothing about what may be disclosed.
+- `recruiter-sliver.js` now has a second first-party reader. The sole-reader guard in `tests/recruiter_sliver_boundary.mjs` was widened with a stated reason **and strengthened**: every listed reader is now checked to not *branch* on a sliver field, so the property the guard protects — descriptive data is never consulted as authority — is enforced rather than trusted.
+- **Still not built:** the apply UI's *"your application shares: …"* disclosure line D7 names. There is no apply UI anywhere — `POST /my-projects/join` has no browser caller — so the sentence has no page to live on. It belongs with whichever task builds that surface, and is filed rather than silently dropped.

package/docs/adr/README.md

@@ -351,3 +351,4 @@ This keeps the decision history honest and traceable.
 | 0257 | [**Auth resolves before the hall mounts anything, and a widget's boot read may never navigate** ([task 1003673](https://cloudbongos.com/builders#/task/1003673) · goal 1000063 — *The front door*). An invite-only instance could not admit its FIRST builder, and the symptom lied about where the fault was: an owner saw an empty Access-requests queue and no approve button, because **signing in does not file a request** — only the landing's *Request access* form does, and that form was unreachable. A signed-out visitor to `/builders` was bounced to GitHub, refused as a first-timer ("request access first"), and pointed back at `/builders` to be bounced again. Reproduced against `main`, not just an old pin. `builders.js` was already careful — `/me` is read `softAuth` and a 401 there renders the landing — but `DOMContentLoaded` called `mountHallWidgets()` FIRST, synchronously, and `goals.js`'s mount-time read of `/goals` goes through a `getJSON` with no `softAuth`, which answers 401 by NAVIGATING. The widget's read raced `renderLanding()` and won. **Decision: the front door settles which page this is before anything else runs** — `boot()` reads `/me` (soft), then either renders the landing and stops (nothing mounts, nothing else fetches) or mounts the hall, handing the resolved payload to `loadAll()` so the page still asks once. Widgets are member surfaces (`renderLanding` hid them all after the fact anyway), so not mounting them while signed out removes the CLASS rather than the one instance of it that was found; **a widget's own boot read may never navigate** is the belt beside it (`goals.js` reads soft and renders nothing without a session). A 401 during boot is not an instruction to go and sign in — only a user action is. `tests/hall_landing_boot.mjs` executes the real `builders.js` in a DOM stub and was confirmed to FAIL against the pre-fix file. Rejected: patching `goals.js` alone (it was merely first); making the 401 redirect soft everywhere (an expired session mid-visit SHOULD be sent to sign in — the line is boot vs user action); open enrollment as the cure (removes the gate [ADR 0050](<redacted>.md) chose deliberately instead of repairing the door).](<redacted>.md) | hall-ui / admission / front door |
 | 0258 | [**The public CLI is a generated client-only package, and its file list is proven by running it** ([task 1003679](https://cloudbongos.com/builders#/task/1003679) · goal 1000054 — *A newcomer can build without the UI*). The core ships private as `@bongos/core` ([ADR 0108](<redacted>.md)), so a newcomer with no credential can install NOTHING and the web hall is the only way in — the owner's words: "how am I supposed to easily take on tasks as a new builder? I should be able to do everything without the UI." Open task 1002025 proposed publishing the core, which ships the SERVER and bypasses [ADR 0099](<redacted>.md)'s redaction pipeline (dormant until ~2026-11). **Decision: generate a separate public `@cloudbongos/cli` from the core and do not publish the core.** Four load-bearing parts. (1) SCOPED NAME, because npm shares one namespace between org names and unscoped packages — the bare `cloudbongos` is unpublishable *precisely because the owner owns that org*, which npm reports as "invalid" and reads like the name is taken; and a package name cannot be created on the npm website at all (it exists on first publish, which is why "Add Existing Package" answered `Forbidden`). (2) THE FILE LIST IS DECLARED AND PROVEN BY BEHAVIOUR, never computed — a static require-closure CANNOT answer this, because `src/module-api.js` is the doorway a module may only import ([ADR 0083](<redacted>.md)) and it *names* every kernel capability, so a static walk sees 33 `src/` files from `start.js` alone where runtime resolves **one** (`api-prefix.js`, which imports nothing) — the same trap as task 1003677's unsatisfiable done-when. So the test packs the tarball, installs it into an empty dir with NO repo, and runs every verb: it may fail for want of a session, never for a missing file. That caught two real holes on its first strengthened run — `clients/bongos-client/index.mjs`, reached by a dynamic `import()` no `require()` walk can see, and a hand-listed `files` array that dropped `clients/` and produced a tarball which installed cleanly then died on first use; both are now build-time refusals, and the `files` array is derived from the manifest. (3) `claim`/`ship`/`dev`/`serve`/`module`/`upgrade`/`onboard`/`doctor`/`exec`/`package-core` are ABSENT and the CLI says WHY plus the next step (`bongos shell` → a cloud box with the full CLI) — a bare `unknown command` teaches nothing, which is the exact failure being fixed. The supported journey is `login` → `start` → `shell`. (4) A REDACTION GATE fails the build closed on non-loopback IPv4 (RFC 5737 doc ranges exempt), token/key shapes, and every domain + owner login readable from the instance's own `config/branding.json` — needles come from host config so the core carries no instance identity ([ADR 0062 §7](<redacted>.md)); `cloudbongos.com` is allowlisted as public by design. No `repository` field while the core repo is private (it would 404 for every user and publish the owner's login for nothing). 31 files, one dependency (`undici`), version independent of the core's ([ADR 0161](<redacted>.md)). `@bongos/client` is VENDORED, not depended on — a public package depending on a private one is uninstallable. **The owner runs `npm publish`; a builder must not.** Task 1002025 is superseded. Rejected: publishing the core; deriving from a static closure (structurally impossible past the doorway); waiting for the mirror (dormant, and this is a build product not a source release); an unscoped name; depending on `@bongos/client`; a degraded `claim`; shipping all of `src/` to make lazy getters safe.](<redacted>.md) | cli / distribution / public surface |
 | 0259 | [**A project’s departure from the public list is public, and the copy says so** ([task 1003672](https://cloudbongos.com/builders#/task/1003672) · goal 1000046 — *Project creation*). Decides the leak [ADR 0255](<redacted>.md) §6.2 deliberately filed rather than implied fixed. The public projects feed publishes a named list plus a count of anonymous rows, so when a project flips to stealth its named row LEAVES the identified block while the count RISES BY ONE — *“Mercury is gone, and there is one more black hole”* names it, and the moment, from a single diff of two snapshots. **Everything [ADR 0182](<redacted>.md) D2a does is defeated by it**, because the identity was never carried ON the anonymous row (`STEALTH_ANONYMOUS_KEEPS` is an allow-list precisely so a column added next year is anonymous by default) — it is carried by the ABSENCE of the named row that used to sit beside it. **Larger than the channel 0255 closed**, which needed repeated sampling and correlation; this one is exact and needs two reads. No `ORDER BY` change touches it: it is inherent in publishing a named list at all, so every fix is a product decision with a visible cost and the owner’s call, not a builder’s. **Decision: accept it, and make the copy say so.** Two reasons it is the right end of the trade and not merely the cheapest — (1) it is ALREADY the honest reading of the existing promise, since D2a made existence and count public *by design*, and a count that is public and truthful is a count whose CHANGES are public; (2) both alternatives damage the control they defend. A **delay window** means the owner clicks the privacy setting and is not private yet *without knowing it*, converting an information leak into a false belief — strictly worse, and the wrong direction for a privacy control. **Decoys** spend the count’s truthfulness (it is truthful today) on a guarantee that is still only probabilistic, and a decoy scheme needs some way to tell padding from real rows — the exact stable per-project key D2a forbids. The promise stealth actually keeps is about the project’s CONTENTS, not the TRANSITION: an anonymous row stays anonymous (no name, tagline, art, origin, or key surviving to the next snapshot); what is not private is stepping off a published list readers may keep copies of. So the copy — which read *“its name, and everything else about it, stay yours”*, every clause true and the paragraph as a whole overselling, because a reader takes it to cover the switch — now names the boundary in BOTH places an owner meets the setting (the choice’s blurb and the what-changes fold), in the plain register 0182’s interview fixed for this card. **A privacy control that oversells is worse than one that admits a limit**, the same standard 0255 §6 set for itself. **No behaviour changes** in `projects-feed.js` — the feed, the redaction allow-list and the keyed rotating permutation are decided FINISHED, not insufficient. `tests/projects_hub.mjs` pins the sentence in both surfaces (the copy IS the fix, so a future edit tightening the blurb must not quietly drop it) and re-applies the no-space-metaphor ban to it. Carries 0255 §6.3’s smaller residual so both live in one place: within one 24h epoch the permutation is stable, so same-day snapshots tell black holes apart (not name them) — accepted on the same reasoning, since the fix is a per-request permutation, which breaks pagination exactly as `ORDER BY random()` was rejected for. Guards recorded for any future attempt: no stable per-project key on an anonymous row, and no anonymous ordering an observer can predict or correlate. Rejected: the delay; decoys; dropping the named list (protects a privacy nobody asked for at the cost of the feature); and saying nothing, which is the failure mode this closes.](<redacted>.md) | platform-identity / privacy boundary / copy honesty |
+| 0260 | [**An application IS the consent, and the hub’s own echo is the gate** ([task 1002972](https://cloudbongos.com/builders#/task/1002972) · goal 1000045, criterion C4). Privacy spec **D7** asks that a reviewer see what the applicant’s OWN profile rules would already show, evaluated LIVE at review time. The rule is ONE port composing the two EXISTING views — `getPublicProfileExtras` for a public account, `recruiter-sliver`’s own `sliverShapeFor` for a private one — because a third five-key lookalike **is** the new disclosure class D7 forbids. **The one deliberate difference from the D3 sliver:** `getRecruiterSliver` floors on recruiting REACH, and reusing it verbatim would be wrong in the direction that looks safe — `recruiter_discoverable` defaults to FALSE for a private account, so a private builder who deliberately applied would show their reviewer NOTHING and C4 would be satisfied by an empty box. D7 settles it: *“applying is an explicit act”*. The swap relaxes REACH only; `accountActiveSql` (active **and** terms accepted) and `hide_stats` still floor it, and the proof asserts both directions on the same account so the tempting refactor cannot pass quietly. **The federated route’s gate is the whole security story** ([ADR 0205](<redacted>.md) / security report 1000027): client credentials name a PROJECT and never a person, so `POST /sso/applicant-profile` authenticated alone is a bulk disclosure oracle over every account on the platform, private ones included. `applicationBacksProfileRead` demands a HUB-WRITTEN echo for exactly (this account, this client) inside the same 30-day window — a row only the hub’s own join relay creates — refusing **404, never 403**, and BEFORE any account is read (asserted on the statement log, because a gate that refuses after reading has already done the disclosure work). LIVE means nothing is stored at either end; the queue keys on the VOUCH and never on `github_login` (the one PUBLIC unauthenticated write makes an unvouched login an impersonation surface); and the hub client secret stays in core behind a narrow doorway port. **The path is complete but DORMANT until R09 ([task 1002285](https://cloudbongos.com/builders#/task/1002285)) ships the vouch writer** — nothing writes `applicant_github_id` today, and that dependency was missing from 1002972’s graph. Rejected: routing the port through `getRecruiterSliver`, a snapshot at apply time, resolving by `github_login`, and putting `loadIdpConfig` on the doorway.](<redacted>.md) | platform identity / privacy |

package/docs/api/openapi.json

@@ -13818,6 +13818,45 @@
         "security": []
       }
     },
+    "/sso/applicant-profile": {
+      "post": {
+        "operationId": "post_sso_applicant_profile",
+        "tags": [
+          "sso"
+        ],
+        "summary": "POST /sso/applicant-profile",
+        "description": "POST /sso/applicant-profile — a federated instance resolves ONE applicant's profile view for its own reviewer queue, LIVE at render (privacy spec D7, task 1002972). Server-to-server, client_id+client_secret auth, like the two routes above. Answers { profile: null | { view:'public', … } | { view: 'sliver', … } } — the D7 rule, decided entirely inside ../applicant-profile.js. WHY A POST FOR A READ. The same reason /sso/activity/rollup is one: the credentials are in the body, and a client_secret in a query string lands in access logs and proxy history. Nothing is written. THE ECHO IS THE GATE, AND IT IS THE WHOLE SECURITY ARGUMENT (ADR 0205, security report 1000027). Client credentials prove WHICH PROJECT is calling and nothing about WHO the github_id is, so authenticating the caller is not enough: without a per-subject witness this route is a bulk disclosure oracle over every account on the platform, private ones included, readable by any registered project holding only its own secret. applicationBacksProfileRead demands a HUB-WRITTEN echo for exactly (this account, this client) inside the 30-day window — a row only the hub's own join relay creates, and only after the project accepted the relayed application. A project may therefore read the profile of someone who applied TO IT, and of nobody else. 404, never 403, when the echo is absent — the /scouting/:handle posture. A 403 would confirm that the github_id names a real account, which is the disclosure the whole rule exists to withhold. An account that exists but discloses nothing (provisional, terms never accepted) answers the SAME { profile: null } as one that consented but is simply not readable, so the caller cannot tell those apart either (ADR 0171 D4). NOT AUTHORITY (ADR 0016). The answer is descriptive; the project's own admission gate reads status='invited' and never this. rank: public — authenticated by client_id + client_secret, not a builder rank. The limiter runs BEFORE the client lookup, so a refused probe costs no DB work — the accountExistenceReadRateLimit posture.\n\n**Rank:** `public` — No authentication — any caller.",
+        "x-rank": "public",
+        "x-source": "modules/platform-identity/routes/sso.js",
+        "requestBody": {
+          "required": true,
+          "content": {
+            "application/json": {
+              "schema": {
+                "$ref": "#/components/schemas/PostSsoApplicantProfileRequest"
+              }
+            }
+          },
+          "x-validated": true
+        },
+        "responses": {
+          "200": {
+            "description": "Success.",
+            "content": {
+              "application/json": {
+                "schema": {
+                  "$ref": "#/components/schemas/PostSsoApplicantProfileResponse"
+                }
+              }
+            }
+          },
+          "400": {
+            "$ref": "#/components/responses/ValidationFailed"
+          }
+        },
+        "security": []
+      }
+    },
     "/sso/authorize": {
       "get": {
         "operationId": "get_sso_authorize",
@@ -21703,6 +21742,37 @@
           "ok"
         ]
       },
+      "PostSsoApplicantProfileRequest": {
+        "type": "object",
+        "properties": {
+          "client_id": {
+            "type": "string",
+            "maxLength": 200
+          },
+          "client_secret": {
+            "type": "string",
+            "maxLength": 512
+          },
+          "github_id": {
+            "$ref": "#/components/schemas/StringifiableId"
+          }
+        },
+        "required": [
+          "client_id",
+          "client_secret",
+          "github_id"
+        ],
+        "additionalProperties": false
+      },
+      "PostSsoApplicantProfileResponse": {
+        "type": "object",
+        "properties": {
+          "profile": {}
+        },
+        "required": [
+          "profile"
+        ]
+      },
       "PostSsoDevicePollRequest": {
         "type": "object",
         "properties": {
@@ -22605,9 +22675,9 @@
       "description": "A required dependency/feature is not configured or is temporarily down."
     }
   },
-  "x-endpoint-count": 358,
-  "x-schema-count": 393,
+  "x-endpoint-count": 359,
+  "x-schema-count": 395,
   "x-undocumented-bodies": 9,
-  "x-response-schemas": 266,
+  "x-response-schemas": 267,
   "x-generated-by": "scripts/gds/gen-api-docs.js"
 }