@bongos/core 1.19.1016 → 1.19.1018

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/account-visibility.js

@@ -32,8 +32,13 @@
 //   recruiterReachSql / isRecruiterDiscoverable  REACH — the COALESCE, privacy
 //       spec D1. A reach predicate only: it never buys addressability.
 //   scoutingListableSql                    THE DIRECTORY — numbers AND reach,
-//       the ONE predicate the recruiting directory joins (ADR 0210, task
-//       1002290). Composed, never restated.
+//       the predicate the recruiting directory's ranked tier joins (ADR 0210,
+//       task 1002290). Composed, never restated.
+//   scoutingNameOnlySql                    THE DIRECTORY'S NAME-ONLY TIER —
+//       existence AND hidden AND reach (ADR 0334, task 1002291; privacy spec D2:
+//       a hidden builder is "listed name-only (if not opted out)"). The same
+//       predicate as the one above with the hide term flipped, so the two tiers
+//       partition the directory: hide decides a row's SHAPE, reach its presence.
 //   recruiterSliverVisibleSql / isRecruiterSliverVisible  THE PRE-ACCEPT
 //       SLIVER — consent AND reach, WITHOUT the existence axis (ADR 0215, task
 //       1002968; privacy spec D3). The one predicate that deliberately does not
@@ -205,6 +210,31 @@ function scoutingListableSql(alias) {
   return `(${rollupVisibleSql(alias)} AND ${recruiterReachSql(alias)})`;
 }
 
+// scoutingNameOnlySql — WHO the recruiting directory lists by NAME ALONE: a
+// publicly visible, reachable account that hid its cross-project record (ADR
+// 0334, task 1002291). Privacy spec D2's recruiter column lists that account
+// "name-only (if not opted out)"; before this the directory dropped it outright,
+// reading hide as a second opt-out while Settings told the builder recruiters
+// would see their name and picture.
+//
+// It is scoutingListableSql with the hide term FLIPPED and nothing else, shaped
+// identically so the two tiers cannot overlap or leave a gap
+// (tests/effective_visibility_predicate.mjs holds that). It keeps the EXISTENCE
+// floor, so a private account is never listed even by name — that is the D3
+// sliver's subject, at the archon floor (ADR 0215/0217).
+//
+// DANGEROUS OUTSIDE ITS ONE READER. It admits hidden accounts by design, so a
+// read that joined it and returned a number would hand out exactly the record
+// hide_stats withholds. scouting-name-only.js is its only reader and selects
+// three identity columns; the guard pins both.
+function scoutingNameOnlySql(alias) {
+  if (alias && !/^[A-Za-z_][A-Za-z0-9_]*$/.test(String(alias))) {
+    throw new Error('scoutingNameOnlySql: alias must be a bare SQL identifier');
+  }
+  const q = alias ? `${alias}.` : '';
+  return `((${accountVisibleSql(alias)} AND ${q}hide_stats) AND ${recruiterReachSql(alias)})`;
+}
+
 // recruiterSliverVisibleSql — THE predicate the PRE-ACCEPT recruiter sliver
 // joins: the CONSENT floor AND the reach axis (ADR 0215, privacy spec D3; task
 // 1002968). modules/platform-identity/recruiter-sliver.js is its one reader.
@@ -256,6 +286,7 @@ module.exports = {
   isRecruiterDiscoverable,
   recruiterReachSql,
   scoutingListableSql,
+  scoutingNameOnlySql,
   recruiterSliverVisibleSql,
   isRecruiterSliverVisible,
 };

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

@@ -0,0 +1,153 @@
+// modules/platform-identity/builder-search.js — the PUBLIC builder search (D4,
+// docs/specs/bongos-v1-community-tab.md; task 1002979, goal 1000110 CT3). Answers
+// "find a builder by name, optionally narrowed to a discipline" for the future
+// /community page (tasks 1002980 / 1003363) — NOT the recruiting directory
+// (routes/scouting.js), which stays a separate, project.curate/owner-gated
+// surface with its own consent predicate, and NOT its archon-floor pre-accept
+// sliver (recruiter-sliver.js). This surface reveals nothing beyond the same
+// public-profile rules /profiles/:handle already applies (D8: no new disclosure
+// class).
+//
+// TWO PREDICATES FROM account-visibility.js, ONE PER AXIS D4 NAMES:
+//   NAME MATCH        — accountVisibleSql (existence: active + public). A
+//     hide_stats account is still findable BY NAME — hiding removes the
+//     rollup, not the page (the same rule /profiles/:handle already honors).
+//   DISCIPLINE MATCH   — rollupVisibleSql (existence AND NOT hide_stats),
+//     because a discipline is ROLLUP-DERIVED
+//     (platform_identity_builder_project_activity.disciplines) and the rollup
+//     is exactly what hide_stats suppresses. A hidden account's disciplines are
+//     therefore never attached and never filterable — which is what keeps a
+//     discipline facet from re-exposing a hidden account's rollup by a side
+//     door. Private and provisional accounts never reach either predicate, so
+//     they are absent from every result regardless of query or filter.
+// Both predicates are IMPORTED, never re-derived — the sole-owner rule
+// tests/effective_visibility_predicate.mjs enforces.
+//
+// Matching: handle / display_name PREFIX (escaped LIKE) OR pg_trgm fuzzy (the
+// `%` similarity operator) — the two legs D4 asks for. BOTH legs compare
+// lower(column) against lower($1)/lower($2) — the `%` operator is
+// case-SENSITIVE (unlike ILIKE, pg_trgm has no case-insensitive variant), so
+// without the explicit lower() a query differing only in case would silently
+// miss the fuzzy leg while the `sim` column (already lower()-folded) still
+// scored it. Indexed by migration platform_identity_023_builder_search_trgm.sql
+// — a GIN gin_trgm_ops index on lower(handle) and lower(display_name), which
+// accelerates both legs since both now query that same expression.
+// github_id never crosses the projection — handle is the address, exactly as
+// every sibling public read in this module already treats it.
+'use strict';
+
+const { pool: defaultPool } = require('../../src/module-api');
+const { accountVisibleSql, rollupVisibleSql } = require('./account-visibility');
+
+const DEFAULT_LIMIT = 20;
+const MAX_LIMIT = 50;
+// Deep OFFSET pagination on an unauthenticated route is a free scan-and-discard
+// knob (?offset=999999999 still walks and throws away every matched row before
+// the LIMIT) — capped so a caller can page a reasonable distance and no further.
+const MAX_OFFSET = 1000;
+// A 1-character query has no usable trigram and a near-unselective LIKE
+// prefix, so it would materialize and sort a large share of the table before
+// LIMIT on every anonymous request. 2 chars is the floor at which a trigram
+// exists at all.
+const MIN_QUERY_CHARS = 2;
+const MAX_QUERY_CHARS = 100;
+const MAX_DISCIPLINE_CHARS = 32; // mirrors upsertActivity's per-discipline cap
+
+function clampLimit(limit) {
+  const n = parseInt(limit, 10);
+  if (!Number.isFinite(n) || n <= 0) return DEFAULT_LIMIT;
+  return Math.min(n, MAX_LIMIT);
+}
+
+function clampOffset(offset) {
+  const n = parseInt(offset, 10);
+  if (!Number.isFinite(n) || n < 0) return 0;
+  return Math.min(n, MAX_OFFSET);
+}
+
+// Escape LIKE's own wildcard characters so a searcher's literal % or _ can't
+// turn a prefix match into an unbounded pattern.
+function escapeLikePrefix(s) {
+  return s.replace(/[\\%_]/g, (c) => `\\${c}`);
+}
+
+// searchBuilders — the one read behind GET /community/search. `q` is required
+// (too short/empty/oversized → no results, never a throw — the route
+// validates and 400s before calling this; this stays defensive on its own).
+// `discipline` is optional; '' means no filter. Returns
+// { results, limit, offset } — `limit`/`offset` are the CLAMPED values
+// actually used, so a caller (the route) never re-derives them to echo back.
+// A result's `disciplines` is null for a hidden account or one with no
+// rollup activity.
+async function searchBuilders({ q, discipline, limit, offset, pool = defaultPool } = {}) {
+  const query = typeof q === 'string' ? q.trim() : '';
+  const lim = clampLimit(limit);
+  const off = clampOffset(offset);
+  if (query.length < MIN_QUERY_CHARS || query.length > MAX_QUERY_CHARS) {
+    return { results: [], limit: lim, offset: off };
+  }
+  const disc = typeof discipline === 'string' ? discipline.trim().slice(0, MAX_DISCIPLINE_CHARS) : '';
+
+  const { rows } = await pool.query(
+    `WITH matches AS (
+       SELECT pa.github_id, pa.handle, pa.github_login, pa.display_name, pa.avatar_url,
+              (lower(pa.handle) = lower($1)) AS exact_handle,
+              GREATEST(similarity(lower(pa.handle), lower($1)),
+                       similarity(lower(COALESCE(pa.display_name, '')), lower($1))) AS sim
+         FROM platform_identity_accounts pa
+        WHERE ${accountVisibleSql('pa')}
+          AND (
+            lower(pa.handle) LIKE lower($2) ESCAPE '\\'
+            OR lower(pa.display_name) LIKE lower($2) ESCAPE '\\'
+            OR lower(pa.handle) % lower($1)
+            OR lower(pa.display_name) % lower($1)
+          )
+     ), disc AS (
+       -- Scoped to the name matches only (never the whole activity table),
+       -- which is strictly smaller — though 'matches' itself is bounded only
+       -- by MIN_QUERY_CHARS' selectivity, not by a hard cap, since the
+       -- discipline filter (below) needs every match's disciplines before
+       -- LIMIT can apply.
+       SELECT x.github_id, array_agg(DISTINCT x.d) AS disciplines
+         FROM (SELECT a.github_id, unnest(a.disciplines) AS d
+                 FROM platform_identity_builder_project_activity a
+                WHERE a.github_id IN (SELECT github_id FROM matches)
+                  AND EXISTS (
+                        SELECT 1 FROM platform_identity_accounts pa2
+                         WHERE pa2.github_id = a.github_id AND ${rollupVisibleSql('pa2')})) x
+        WHERE x.d IS NOT NULL
+        GROUP BY x.github_id
+     )
+     SELECT m.handle, m.github_login, m.display_name, m.avatar_url, d.disciplines
+       FROM matches m
+       LEFT JOIN disc d ON d.github_id = m.github_id
+      WHERE ($3::text = '' OR d.disciplines @> ARRAY[$3]::text[])
+      ORDER BY m.exact_handle DESC, m.sim DESC, m.handle
+      LIMIT $4 OFFSET $5`,
+    [query, `${escapeLikePrefix(query)}%`, disc, lim, off],
+  );
+  return {
+    results: rows.map((r) => ({
+      handle: r.handle,
+      github_login: r.github_login,
+      display_name: r.display_name,
+      avatar_url: r.avatar_url,
+      disciplines: Array.isArray(r.disciplines) ? r.disciplines : null,
+    })),
+    limit: lim,
+    offset: off,
+  };
+}
+
+module.exports = {
+  searchBuilders,
+  clampLimit,
+  clampOffset,
+  escapeLikePrefix,
+  DEFAULT_LIMIT,
+  MAX_LIMIT,
+  MAX_OFFSET,
+  MIN_QUERY_CHARS,
+  MAX_QUERY_CHARS,
+  MAX_DISCIPLINE_CHARS,
+};

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/migrations/platform_identity_023_builder_search_trgm.sql

@@ -0,0 +1,40 @@
+-- platform_identity_023_builder_search_trgm.sql — GIN trigram indexes for the
+-- public builder search (D4, docs/specs/bongos-v1-community-tab.md; task
+-- 1002979). builder-search.js's searchBuilders() queries
+-- lower(handle) LIKE lower($2) OR lower(handle) % lower($1) (and the same
+-- pair for display_name) against platform_identity_accounts on EVERY request
+-- to an UNAUTHENTICATED, rate-limited-but-public route — an unindexed
+-- sequential scan there is a cost every anonymous caller can trigger.
+--
+-- INDEXED ON THE EXPRESSION, NOT THE BARE COLUMN. Both query legs compare
+-- lower(handle)/lower(display_name), so a plain gin_trgm_ops index on the raw
+-- column would never be used — Postgres only matches a functional index
+-- against the identical expression. One index per column then serves BOTH
+-- legs (prefix LIKE and % fuzzy), because pg_trgm's GIN opclass supports LIKE
+-- as well as the trigram similarity operators.
+--
+-- pg_trgm itself is already enabled repo-wide by migrations/103_search_chunks.sql
+-- (a core migration, so it runs before any module migration) — nothing to
+-- create here.
+--
+-- WHY NOT CONCURRENTLY. Same reasoning core_222 and modules/ideas/migrations/-
+-- ideas_004_lineage_route_index.sql recorded for their own indexes: CREATE
+-- INDEX CONCURRENTLY cannot run inside a transaction block, and this file is
+-- wrapped BEGIN/COMMIT so it lands atomically. Acceptable here specifically
+-- because platform_identity_accounts is a hub-only, human-signup-paced table
+-- (one row per platform account) — the build is a light, one-time lock against
+-- a small table, not a write-hot one.
+--
+-- Additive + platform_identity_-namespaced (ADR 0083 §5). Forward-safe: index
+-- creation only, no column/type change, so the previous release runs
+-- unmodified against this schema. Idempotent (IF NOT EXISTS).
+
+BEGIN;
+
+CREATE INDEX IF NOT EXISTS platform_identity_accounts_handle_trgm
+  ON platform_identity_accounts USING gin (lower(handle) gin_trgm_ops);
+
+CREATE INDEX IF NOT EXISTS platform_identity_accounts_display_name_trgm
+  ON platform_identity_accounts USING gin (lower(display_name) gin_trgm_ops);
+
+COMMIT;

package/modules/platform-identity/module.json

@@ -10,7 +10,7 @@
   "maintainer": "Cloud Bongos maintainers",
   "maintenance": { "status": "core-maintained" },
   "contributes": {
-    "routes": ["sso", "projects", "my-projects", "scouting", "profile", "public-profile", "connections"],
+    "routes": ["sso", "projects", "my-projects", "scouting", "profile", "public-profile", "connections", "community-search"],
     "migrations": true,
     "pollers": ["code-sweep", "visibility-pull"]
   },

package/modules/platform-identity/routes/community-search.js

@@ -0,0 +1,120 @@
+// modules/platform-identity/routes/community-search.js — GET /community/search,
+// the PUBLIC builder-search read behind the future /community page (D4,
+// docs/specs/bongos-v1-community-tab.md; task 1002979, goal 1000110 CT3). A
+// sibling of public-profile.js and scouting.js — same module, same doorway,
+// DIFFERENT surface: this is name+discipline search under exactly the
+// public-profile visibility rules, never the project.curate/owner-gated
+// recruiting directory (routes/scouting.js `GET /scouting`) and never its
+// archon-floor pre-accept sliver (`GET /scouting/:handle`). The visibility
+// decision lives entirely in ../builder-search.js (account-visibility.js's
+// shared predicates); this file is the thin HTTP shell — validation, the
+// per-IP rate limit, the response envelope.
+//
+// Reaches core only through the doorway (ADR 0083).
+'use strict';
+
+const express = require('express');
+const api = require('../../../src/module-api');
+const builderSearch = require('../builder-search');
+
+const { pool, corsPublicGet } = api;
+
+// Resolved at CALL time, never at load — the scouting.js precedent: a proof
+// that stubs a PARTIAL doorway (pool + the auth gates only) must still be able
+// to require() this file, and a module-scope api.logger() call would break
+// that. A logging line is not worth breaking a privacy proof over.
+let resolvedLog = null;
+const log = {
+  error: (msg) => {
+    if (!resolvedLog) resolvedLog = typeof api.logger === 'function' ? api.logger('platform-identity') : { error: () => {} };
+    resolvedLog.error(msg);
+  },
+};
+
+// Per-IP read cap for this UNAUTHENTICATED route (the public-profile.js R05
+// posture: the global limiter only meters WRITES, so an uncapped scraper could
+// otherwise run the trigram leg at line rate). Vendored, not shared — the core
+// /public/* limiter is not on the doorway, and each public GET here owns its
+// own budget rather than reaching into a sibling module's copy.
+const READ_RATE_WINDOW_MS = 60 * 1000;
+const READ_RATE_LIMIT = 60;
+const buckets = new Map(); // ip -> timestamp[]
+
+const sweepTimer = setInterval(() => {
+  const cutoff = Date.now() - READ_RATE_WINDOW_MS;
+  for (const [k, arr] of buckets) {
+    while (arr.length && arr[0] < cutoff) arr.shift();
+    if (arr.length === 0) buckets.delete(k);
+  }
+}, 5 * 60 * 1000);
+if (typeof sweepTimer.unref === 'function') sweepTimer.unref();
+
+function searchReadRateLimit(req, res, next) {
+  const now = Date.now();
+  const key = req.ip || req.socket?.remoteAddress || 'unknown';
+  let bucket = buckets.get(key);
+  if (!bucket) { bucket = []; buckets.set(key, bucket); }
+  const cutoff = now - READ_RATE_WINDOW_MS;
+  while (bucket.length && bucket[0] < cutoff) bucket.shift();
+  if (bucket.length >= READ_RATE_LIMIT) {
+    const retryAfter = Math.max(1, Math.ceil((bucket[0] + READ_RATE_WINDOW_MS - now) / 1000));
+    res.set('Retry-After', String(retryAfter));
+    res.set('X-RateLimit-Scope', 'community-search-read');
+    res.set('X-RateLimit-Limit', String(READ_RATE_LIMIT));
+    return res.fail('rate_limited', 429, { scope: 'community-search-read', retry_after_seconds: retryAfter });
+  }
+  bucket.push(now);
+  return next();
+}
+
+module.exports = function communitySearchRoutes() {
+  const router = express.Router();
+
+  router.use('/community/search', corsPublicGet('/community/search'));
+
+  // rank: public — a name/discipline search under EXACTLY the public-profile
+  // visibility rules (D4): a hide_stats account is findable by name but drops
+  // out of a discipline-filtered result (disciplines are rollup-derived, and
+  // the rollup is what hide_stats suppresses); private and provisional
+  // accounts never appear. no-store: the same hide-must-beat-the-cache posture
+  // as /profiles/:handle (ADR 0171 D5) — this reads the identical predicate
+  // and a flip must be reflected on the very next request.
+  router.get('/community/search', searchReadRateLimit, async (req, res) => {
+    const q = (typeof req.query.q === 'string' ? req.query.q : '').trim();
+    if (!q) {
+      return res.fail('bad_request', { status: 400, message: 'q (a non-empty search string) is required' });
+    }
+    if (q.length < builderSearch.MIN_QUERY_CHARS) {
+      return res.fail('query_too_short', { status: 400, message: `q must be at least ${builderSearch.MIN_QUERY_CHARS} characters` });
+    }
+    if (q.length > builderSearch.MAX_QUERY_CHARS) {
+      return res.fail('query_too_long', { status: 400, message: `q must be at most ${builderSearch.MAX_QUERY_CHARS} characters` });
+    }
+    const discipline = (typeof req.query.discipline === 'string' ? req.query.discipline : '').trim();
+    if (discipline.length > builderSearch.MAX_DISCIPLINE_CHARS) {
+      return res.fail('discipline_too_long', { status: 400, message: `discipline must be at most ${builderSearch.MAX_DISCIPLINE_CHARS} characters` });
+    }
+    try {
+      const { results, limit, offset } = await builderSearch.searchBuilders({
+        q, discipline, limit: req.query.limit, offset: req.query.offset, pool,
+      });
+      res.set('Cache-Control', 'no-store');
+      res.json({
+        query: q,
+        discipline: discipline || null,
+        count: results.length,
+        results,
+        page: { limit, offset },
+      });
+    } catch (err) {
+      log.error(`GET /community/search failed: ${err && err.message}`);
+      res.fail('search_failed', { status: 500, message: 'internal error' });
+    }
+  });
+
+  return router;
+};
+
+// Exported for tests — the pure rate-limit bucket logic + limits (the
+// modules/memory/routes/search.js precedent).
+module.exports._internals = { searchReadRateLimit, READ_RATE_LIMIT, READ_RATE_WINDOW_MS };

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),