@bongos/core 1.19.579 → 1.19.580

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

@@ -80,6 +80,57 @@ function normalizeLogin(raw) {
   return String(raw || '').trim().replace(/^@/, '');
 }
 
+// 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
+// hub to read a queue that is perfectly readable without it.
+//
+// The cap bites on VOUCHED rows only — an unvouched row has no account to
+// resolve and costs nothing — and it is applied to the list AS ORDERED, newest
+// first, so the rows a reviewer actually acts on are the ones that carry a
+// profile. Beyond it, `profile` is null and the row renders exactly as an
+// unvouched one does: the queue never degrades into an error, it degrades into
+// less detail. Raising this number buys detail and costs latency; it changes
+// nothing about WHAT may be disclosed.
+const MAX_LIVE_PROFILE_READS = 25;
+
+// attachApplicantProfiles(rows) — the LIVE half of D7, and "live" is the whole
+// design rather than a performance note. Nothing about the applicant is stored
+// on the access_requests row; the profile is resolved from the hub ON EVERY
+// RENDER, so an applicant who goes private, hides their stats, or loses their
+// account between applying and being reviewed is answered by the NEXT read of
+// this queue (criterion C2's "immediately"). A snapshot taken at apply time
+// would keep publishing a consent that had since been withdrawn.
+//
+// KEYED ON THE VOUCH, NEVER ON github_login. `applicant_github_id` is the hub's
+// own assertion about who filed this request (core_230); the login is a string
+// anybody may type into the one PUBLIC unauthenticated write on this API.
+// 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. So an unvouched row gets `profile: null`, always, and the queue's own
+// "Name unvouched" pill already tells the reviewer why.
+//
+// Each read fails soft to null independently (the doorway port swallows), so one
+// slow or missing account cannot fail the others or the listing.
+async function attachApplicantProfiles(rows) {
+  // The budget is spent UP FRONT, by index, rather than by decrementing a shared
+  // counter inside the concurrent callbacks. Both are correct today — `.map`
+  // invokes each async callback synchronously up to its first `await`, so the
+  // decrements happen in list order before any hub call starts — but resting a
+  // disclosure-shaped cap on that guarantee is the kind of correctness that
+  // breaks silently the day someone reaches for a concurrency helper here. This
+  // form is correct for a reason a reader can see without knowing that rule.
+  const resolvable = new Set();
+  rows.forEach((r, i) => {
+    if (r.applicant_github_id && resolvable.size < MAX_LIVE_PROFILE_READS) resolvable.add(i);
+  });
+  return Promise.all(rows.map(async (r, i) => ({
+    ...r,
+    profile: resolvable.has(i) ? await api.readApplicantProfileFromHub(r.applicant_github_id) : null,
+  })));
+}
+
 module.exports = function buildAccessRequestsRouter() {
   const router = express.Router();
 
@@ -235,7 +286,11 @@ module.exports = function buildAccessRequestsRouter() {
           LIMIT 200`,
         [status]
       );
-      res.json({ requests: rows });
+      // C4's other half (privacy spec D7, task 1002972): the applicant's own
+      // profile, as their OWN privacy rules would show it, resolved from the hub
+      // at render. See attachApplicantProfiles — it is keyed on the vouch, never
+      // on the login, and every row it cannot resolve carries `profile: null`.
+      res.json({ requests: await attachApplicantProfiles(rows) });
     } catch (err) {
       log.error('[gds] GET /access-requests', err);
       res.fail('list_failed', { status: 500, message: 'internal error' });

package/modules/platform-identity/applicant-profile.js

@@ -0,0 +1,158 @@
+// modules/platform-identity/applicant-profile.js — THE D7 RULE: what a reviewer
+// sees of the person who applied to their project (privacy spec D7, task
+// 1002972, goal 1000045).
+//
+// ONE RULE, NO NEW DISCLOSURE CLASS. That is D7's whole claim, and this file is
+// where it is true or not:
+//
+//   PUBLIC account   → the SAME payload GET /profiles/:handle already serves —
+//                      the identity band plus the cross-project rollup, which is
+//                      null when `hide_stats` is set. Not a copy of that shape:
+//                      the rollup half is getPublicProfileExtras, the very port
+//                      the public page calls.
+//   PRIVATE account  → the D3 sliver's projection, built by recruiter-sliver's
+//                      own sliverShapeFor — again the same code, not a similar
+//                      one. Name-only under `hide_stats`, by that file's rule.
+//   PROVISIONAL, or an account that never accepted the terms → NOTHING (null).
+//
+// So a reviewer never sees a field that some existing surface would not already
+// have shown them. A THIRD shape here would BE the new disclosure class D7
+// forbids, which is why neither branch builds its own object.
+//
+// EVALUATED LIVE, AND THAT IS A REQUIREMENT RATHER THAN AN IMPLEMENTATION NOTE
+// (spec C2, D7). Nothing here is stored, cached or snapshotted at apply time. An
+// applicant who flips `hide_stats`, goes private, or has their account
+// deactivated between applying and being reviewed is answered by the NEXT render
+// — because the next render is the only place the answer exists. A snapshot
+// taken at apply time would keep publishing a withdrawn consent for as long as
+// the request sat in the queue, which is exactly the failure C2's "immediately"
+// is written against.
+//
+// THE CONSENT IS THE APPLICATION, AND THAT IS THE ONE PLACE THIS DIFFERS FROM
+// THE RECRUITER SLIVER — stated out loud because it is the decision a reader
+// will want to check. getRecruiterSliver floors on recruiterSliverVisibleSql =
+// consent AND *recruiting reach*, because a recruiter browsing a directory has
+// been 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
+// reusing getRecruiterSliver verbatim here 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); it was never a gate on a door the account itself
+// knocked on.
+//
+// WHAT STILL FLOORS IT, so "the application is the consent" cannot be read as
+// "applying opts you into everything":
+//   * accountActiveSql — profile_state='active' AND terms_accepted_at IS NOT
+//     NULL. A provisional account (no human ever witnessed at the hub) and an
+//     account that never accepted the platform terms disclose NOTHING here, the
+//     same as on every other surface. This is the shared predicate, called, not
+//     re-spelled (tests/effective_visibility_predicate.mjs enforces that).
+//   * hide_stats — untouched, in both branches, by the two ports themselves.
+//   * the existence axis is deliberately NOT a floor, for the same reason the D3
+//     sliver drops it: the private account is precisely this rule's subject, and
+//     flooring on accountVisibleSql would empty the private branch of everything
+//     it exists to carry.
+//
+// NOT AUTHORITY (ADR 0016). A reviewer holding this view holds a description,
+// never a permission: nothing here says the applicant may enter, and admission
+// still reads status='invited' and nothing else (hasInvitedAccessRequest). It
+// does not even say they applied — the CALLER must prove that first; see
+// applicationBacksProfileRead in ./application-echo.js, which is the gate the
+// one route over this port is built on.
+//
+// WHO MAY CALL IT is not this file's question (routes/sso.js gates the one
+// surface). WHAT crosses is decided here, and by the two ports it composes.
+//
+// tests/applicant_profile_boundary.mjs is the proof.
+'use strict';
+
+const pi = require('./platform-identity');
+const recruiterSliver = require('./recruiter-sliver');
+const { accountActiveSql, isAccountVisible } = require('./account-visibility');
+
+// The two shapes this port may answer with, as a closed vocabulary. Exported so
+// the proof asserts against these constants rather than a copy of the strings —
+// a third view added here and quietly added to the test's own expectation is the
+// failure a whitelist is supposed to make impossible.
+const VIEW_PUBLIC = 'public';
+const VIEW_SLIVER = 'sliver';
+const APPLICANT_VIEWS = [VIEW_PUBLIC, VIEW_SLIVER];
+
+// readApplicantAccount — the ONE account read behind the port: the identity band
+// of an account that clears the CONSENT floor, plus the columns the branch below
+// needs to decide the shape. Null for anyone who does not clear it.
+//
+// It selects `account_visibility` and the consent columns deliberately: the
+// EXISTENCE decision is made in JS by isAccountVisible, on this row, rather than
+// by a second query with a second predicate — one read, one row, one branch.
+async function readApplicantAccount(githubId, { pool }) {
+  const { rows } = await pool.query(
+    `SELECT github_id, github_login, display_name, avatar_url, handle, bio, links,
+            created_at, profile_state, terms_accepted_at, account_visibility,
+            recruiter_discoverable, hide_stats
+       FROM platform_identity_accounts
+      WHERE ${accountActiveSql()} AND github_id = $1::bigint
+      LIMIT 1`,
+    [String(githubId)],
+  );
+  return rows[0] || null;
+}
+
+// publicApplicantView(account, { pool }) — the PUBLIC branch, assembled from the
+// same two pieces GET /profiles/:handle serves: the identity band off the row,
+// and the cross-project rollup off getPublicProfileExtras — which returns null
+// for a `hide_stats` account, so hiding is honoured by the port rather than by a
+// rule restated here.
+//
+// github_id and profile_state never cross, exactly as on the public page: the
+// join key stays internal and the answer itself is the addressability signal.
+async function publicApplicantView(account, { pool }) {
+  return {
+    view: VIEW_PUBLIC,
+    account: {
+      handle: account.handle ?? null,
+      github_login: account.github_login,
+      display_name: account.display_name ?? null,
+      avatar_url: account.avatar_url ?? null,
+      member_since: account.created_at,
+      // RENDER CONTRACT, inherited verbatim from getPublicProfileByHandle:
+      // escape the bio, never linkify it, and emit links with
+      // rel="nofollow ugc noopener". Validated at write; still user content.
+      bio: account.bio ?? null,
+      links: account.links ?? null,
+    },
+    cross_project: await pi.getPublicProfileExtras(account.github_id, { pool }),
+  };
+}
+
+// getApplicantProfileView(githubId, { pool }) — THE port D7 names.
+//
+// Answers null | { view:'public', account, cross_project } | { view:'sliver',
+// sliver }. A non-numeric principal (core's 'system:bfg' shape) answers null
+// rather than throwing a bigint cast mid-request, like every other read in this
+// module.
+//
+// FAIL-CLOSED IN ONE DIRECTION ONLY: everything that is not disclosable is the
+// SAME null — absent account, provisional account, terms never accepted, and an
+// unusable principal are indistinguishable to a caller, which is the ADR 0171 D4
+// rule. The caller renders "no record", never a reason.
+async function getApplicantProfileView(githubId, { pool } = {}) {
+  if (!pi.isNumericGithubId(githubId)) return null;
+  const account = await readApplicantAccount(githubId, { pool });
+  if (!account) return null;
+  if (isAccountVisible(account)) return publicApplicantView(account, { pool });
+  // PRIVATE: the D3 projection, built by the sliver's own code. sliverShapeFor
+  // takes the row this function already holds and applies the `hide_stats`
+  // shape rule — the CONSENT predicate is not re-applied there, which is why
+  // the floor above is this function's own responsibility and is not optional.
+  return { view: VIEW_SLIVER, sliver: await recruiterSliver.sliverShapeFor(account, { pool }) };
+}
+
+module.exports = {
+  APPLICANT_VIEWS,
+  VIEW_PUBLIC,
+  VIEW_SLIVER,
+  getApplicantProfileView,
+};

package/modules/platform-identity/application-echo.js

@@ -88,6 +88,55 @@ async function listRecentApplications(githubId, { pool = defaultPool } = {}) {
   return rows;
 }
 
+// applicationBacksProfileRead — "did THIS account apply to THIS project, inside
+// the window?" The gate under POST /sso/applicant-profile (task 1002972, D7),
+// and the exact analogue of membershipBacksRollup: a boolean, nothing more.
+//
+// WHY IT HAS TO EXIST, and it is the whole security argument for that route.
+// Client credentials say WHICH PROJECT is calling; they say NOTHING about who
+// the github_id in the body is (ADR 0205, security report 1000027 — the lesson
+// /sso/membership/check-in and /sso/activity/rollup both had to learn). Without
+// this check, any registered project holding only its own secret could walk the
+// github_id space and pull an applicant view for every account on the platform,
+// PRIVATE ONES INCLUDED — D7's private branch would become a bulk disclosure
+// oracle, which is strictly worse than the rollup hole it mirrors. The echo is
+// the right witness precisely because the HUB writes it, in its own join relay
+// (routes/my-projects.js), only after the project answered the relayed
+// application with a success. A client cannot assert itself into this table.
+//
+// THIS IS THE ONE CROSS-ACCOUNT READ OF THIS TABLE, and it is deliberately the
+// narrowest possible one — the caller must already name both the account and the
+// project, and gets back a yes/no. It cannot enumerate: there is no listing by
+// client_id here, so a project learns nothing about who applied that it was not
+// already told when the application arrived at its own door. (The header's
+// "own-scope only" line describes listRecentApplications, which is still the
+// only surface that returns a LIST.)
+//
+// THE WINDOW IS THE SAME 30 DAYS, and reusing it is load-bearing rather than
+// tidy: the echo is what makes an applicant view readable, so when the echo
+// stops matching, the view stops being readable. A queue row older than the
+// window renders no record — which is the correct answer, because the platform
+// stopped vouching for the connection between that row and that account.
+//
+// Fail-closed: a non-numeric principal, an empty client, and no row are the same
+// false. Never authority (ADR 0016) — a true here buys the caller a DESCRIPTION,
+// and admission still reads status='invited' alone.
+async function applicationBacksProfileRead({ githubId, clientId }, { pool = defaultPool } = {}) {
+  if (!isNumericGithubId(githubId)) return false;
+  const client = String(clientId || '');
+  if (!client) return false;
+  const { rows } = await pool.query(
+    `SELECT 1
+       FROM platform_identity_application_echoes
+      WHERE github_id = $1::bigint
+        AND client_id = $2
+        AND applied_at > now() - make_interval(days => $3::int)
+      LIMIT 1`,
+    [String(githubId), client, APPLICATION_ECHO_WINDOW_DAYS],
+  );
+  return rows.length > 0;
+}
+
 // forgetApplication — drop this account's echo for one project. Called when the
 // account LEAVES the project: the echo means "I asked to join and have not yet",
 // and someone who joined and left has neither. Without it, leaving RESURRECTS the
@@ -111,5 +160,6 @@ module.exports = {
   APPLICATION_ECHO_WINDOW_DAYS,
   recordApplication,
   listRecentApplications,
+  applicationBacksProfileRead,
   forgetApplication,
 };

package/modules/platform-identity/recruiter-sliver.js

@@ -159,6 +159,22 @@ function projectSliver(account, activity) {
 // shape, and for a hidden account DO NOT ISSUE the activity read at all. Not
 // merely dropping the fields after fetching them is the point — the cheapest way
 // for a future edit to leak a number is for the number to already be in hand.
+//
+// EXPORTED as `sliverShapeFor` for ONE other caller — ./applicant-profile.js,
+// the D7 rule (task 1002972) — and the export carries a contract worth stating,
+// because it is the half of this file that does NOT decide consent:
+//
+//   THIS FUNCTION APPLIES NO CONSENT PREDICATE. It takes a row somebody else
+//   already decided may be disclosed, and answers only "what SHAPE of sliver
+//   does this row get" — the `hide_stats` rule and the whitelist. The two entry
+//   points below reach it through readSliverAccount, whose WHERE carries
+//   recruiterSliverVisibleSql; a caller that does not go through them owes the
+//   floor itself.
+//
+// It is shared rather than copied for the reason D7 exists: an applicant view
+// that built its own five-key object would be a SECOND pre-accept projection,
+// free to drift from this one field by field, and the whitelist proof over this
+// file would not cover it. One projection, two consent gates above it.
 async function sliverFor(account, { pool }) {
   if (!account) return null;
   if (account.hide_stats) return projectSliver(account, null);
@@ -194,4 +210,7 @@ module.exports = {
   ACTIVE_WINDOW_DAYS,
   getRecruiterSliver,
   getRecruiterSliverByHandle,
+  // The SHAPE without the consent gate — see the contract on sliverFor above.
+  // One caller: ./applicant-profile.js, which supplies its own floor.
+  sliverShapeFor: sliverFor,
 };

package/modules/platform-identity/routes/sso.js

@@ -23,6 +23,61 @@ const canonicalProfile = require('../canonical-profile');
 const inviteSuggestions = require('../invite-suggestions');
 const hubKeys = require('../hub-keys');
 const hubDevice = require('../hub-device');
+// The D7 applicant-profile read (task 1002972) and the echo that gates it.
+const applicantProfile = require('../applicant-profile');
+const applicationEcho = require('../application-echo');
+
+// Per-IP cap for POST /sso/applicant-profile — DEFENCE IN DEPTH behind the echo
+// gate, not the gate itself (task 1002972 grade advisory). The echo already
+// closes the enumeration oracle: a caller can only read someone who applied to
+// it, which it already knows about. What a ceiling adds is a bound on the cost
+// of GUESSING — an attacker holding a stolen client secret, or simply a buggy
+// instance, cannot walk the github_id space at line rate against the hub's
+// database. The route's siblings (/sso/membership/check-in, /sso/activity/rollup)
+// carry none; this one is a READ of another person's profile, which is why it
+// gets the treatment GET /access-requests/status was retrofitted with.
+//
+// Vendored rather than shared: `accountExistenceReadRateLimit` is a per-IP budget
+// deliberately SHARED between core's admission-status and the onboarding probe so
+// the two cannot be alternated. This is a different audience — a federated
+// instance's server, not a browser — and folding it into that budget would let a
+// busy legitimate project exhaust the door a stranger uses to check their own
+// admission. `perIpSlidingWindow` is not on the doorway, so this mirrors
+// public-profile.js's vendored window instead.
+//
+// Sized for server-to-server: a reviewer render resolves at most 25 applicants
+// (MAX_LIVE_PROFILE_READS), so 300/60s leaves a busy project ample headroom while
+// still bounding a scripted walk.
+const APPLICANT_READ_WINDOW_MS = 60 * 1000;
+const APPLICANT_READ_LIMIT = 300;
+const applicantReadBuckets = new Map(); // ip -> timestamp[]
+
+const applicantSweep = setInterval(() => {
+  const cutoff = Date.now() - APPLICANT_READ_WINDOW_MS;
+  for (const [k, arr] of applicantReadBuckets) {
+    while (arr.length && arr[0] < cutoff) arr.shift();
+    if (arr.length === 0) applicantReadBuckets.delete(k);
+  }
+}, 5 * 60 * 1000);
+if (typeof applicantSweep.unref === 'function') applicantSweep.unref();
+
+function applicantReadRateLimit(req, res, next) {
+  const now = Date.now();
+  const key = req.ip || req.socket?.remoteAddress || 'unknown';
+  let bucket = applicantReadBuckets.get(key);
+  if (!bucket) { bucket = []; applicantReadBuckets.set(key, bucket); }
+  const cutoff = now - APPLICANT_READ_WINDOW_MS;
+  while (bucket.length && bucket[0] < cutoff) bucket.shift();
+  if (bucket.length >= APPLICANT_READ_LIMIT) {
+    const retryAfter = Math.max(1, Math.ceil((bucket[0] + APPLICANT_READ_WINDOW_MS - now) / 1000));
+    res.set('Retry-After', String(retryAfter));
+    res.set('X-RateLimit-Scope', 'applicant-profile-read');
+    res.set('X-RateLimit-Limit', String(APPLICANT_READ_LIMIT));
+    return res.fail('rate_limited', 429, { scope: 'applicant-profile-read', retry_after_seconds: retryAfter });
+  }
+  bucket.push(now);
+  return next();
+}
 // task 1003208: structured logging (pino via the doorway) — was console.*.
 const log = api.logger('platform-identity');
 
@@ -549,5 +604,76 @@ module.exports = function ssoRoutes() {
     }
   });
 
+  // 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.
+  router.post('/sso/applicant-profile', applicantReadRateLimit, async (req, res) => {
+    if (validateOrRespond(req, res, {
+      client_id: { required: true, type: 'string', maxLength: 200 },
+      client_secret: { required: true, type: 'string', maxLength: 512 },
+      github_id: { required: true },
+    })) return;
+    const b = req.body || {};
+    try {
+      const client = await pi.getClient(b.client_id, { pool });
+      if (!client || client.status !== 'active' || !pi.clientSecretValid(client, b.client_secret)) {
+        return res.fail('invalid_client', 401);
+      }
+      // Rejected before the bigint column, like every sibling route here.
+      if (!pi.isNumericGithubId(b.github_id)) {
+        return res.fail('invalid_github_id', 400);
+      }
+      // The witness FIRST — no disclosable data is read until the caller has
+      // proved this person applied to it. The client_id is the AUTHENTICATED
+      // one, never the body's, for the reason every route here takes it that way.
+      const applied = await applicationEcho.applicationBacksProfileRead(
+        { githubId: b.github_id, clientId: client.client_id }, { pool },
+      );
+      if (!applied) return res.fail('no_application', 404);
+      const profile = await applicantProfile.getApplicantProfileView(b.github_id, { pool });
+      // The rollup half is live-derived and hide must beat any cache (ADR 0171
+      // D5) — and D7's "live at review time" says the same thing louder: a
+      // cached applicant view is a snapshot, which is the one thing the rule
+      // forbids.
+      res.set('Cache-Control', 'no-store');
+      res.json({ profile });
+    } catch (err) {
+      log.error('[platform-identity] /sso/applicant-profile', err);
+      res.fail('applicant_profile_failed', { status: 500, message: 'internal error' });
+    }
+  });
+
   return router;
 };

package/package-lock.json

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bongos/core",
-  "version": "1.19.579",
+  "version": "1.19.580",
   "description": "Cloud Bongos — the AI-first build platform core (GDS + platform surfaces + module system), installed as a versioned dependency (ADR 0108).",
   "license": "AGPL-3.0-or-later",
   "main": "src/platform-server.js",

package/src/bongos/auth-admission.js

@@ -394,9 +394,70 @@ async function safeSyncRankRole(builder) {
 }
 
 
+// readApplicantProfileFromHub(githubId) — the reviewer queue's LIVE read of one
+// applicant's profile view from the hub (privacy spec D7, task 1002972). The
+// project side of POST /sso/applicant-profile.
+//
+// WHY IT LIVES IN THE KERNEL AND NOT IN THE onboarding MODULE THAT USES IT. The
+// call is authenticated with this instance's HUB CLIENT SECRET, and
+// loadIdpConfig is deliberately not on the doorway — putting it there would hand
+// every module the credential that speaks for this whole project. So the secret
+// stays in core beside the two other hub calls that hold it
+// (reportMembershipCheckIn, reportActivityRollup) and the module reaches a
+// NARROW port instead: one github_id in, one already-bounded view out.
+//
+// RESOLVED FRESH ON EVERY CALL — no cache, no memo, no store. That is D7's
+// "evaluated LIVE at review time, never a snapshot" (spec C2), and the reason a
+// hub outage answers null rather than a stale-but-helpful last-known value: an
+// applicant who hid their stats an hour ago must not have them rendered from
+// this instance's memory. The hub already sends Cache-Control: no-store; this
+// end simply keeps nothing.
+//
+// FAILS SOFT TO null, ALWAYS. A self-hosted instance with no hub (idp unset), a
+// hub that is down, a 404 for an applicant this project has no echo for, a
+// non-JSON body — every one of them is the same null, and the queue renders "no
+// record" beside a row that still shows its login, note and vouch pill. A
+// reviewer losing the profile block is a degraded queue; a queue that fails to
+// load because the hub is slow is a broken one, and admission does not depend on
+// any of this (ADR 0016).
+//
+// BOUNDED IN TIME, which is what makes the paragraph above true rather than
+// aspirational (task 1003681, grader finding). This is the only hub call that
+// FANS OUT: the other two fire at most once per sign-in or per ship, while this
+// one runs up to MAX_LIVE_PROFILE_READS (25) times concurrently inside the
+// Promise.all that GET /access-requests awaits. Unbounded, one unresponsive hub
+// holds the whole reviewer queue open for as long as the socket lives — the
+// exact "broken one" this comment disclaims. The timeout converts that into the
+// null this function already promises on every other failure.
+const APPLICANT_PROFILE_TIMEOUT_MS = 5000;
+
+async function readApplicantProfileFromHub(githubId) {
+  const idp = loadIdpConfig();
+  if (!idp || githubId == null) return null;
+  try {
+    const r = await fetch(`${idp.origin}/api/gds/sso/applicant-profile`, {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json', Accept: 'application/json', 'User-Agent': userAgent() },
+      signal: AbortSignal.timeout(APPLICANT_PROFILE_TIMEOUT_MS),
+      body: JSON.stringify({
+        client_id: idp.clientId,
+        client_secret: idp.clientSecret,
+        github_id: githubId,
+      }),
+    });
+    if (!r.ok) return null;
+    const body = await r.json().catch(() => null);
+    return (body && body.profile) || null;
+  } catch (err) {
+    log.info('[auth] hub applicant-profile read failed (non-blocking):', err.message);
+    return null;
+  }
+}
+
 module.exports = {
   firstAdminLogin,
   firstTimeAdmissionBlocked,
+  readApplicantProfileFromHub,
   // Re-exported, not defined here (task 1003579 moved it to project-door.js with
   // the two knobs it composes against). auth.js, the doorway's api.joinabilityMode
   // and four test files import it by this path, and the read-back it answers —

package/src/bongos/auth.js

@@ -55,7 +55,7 @@ const ic = require('../instance-config');
 const { branding, userAgent } = require('../branding');
 
 const { SCOPE, authConfigured, grantedScopeCoversRepos, idpConfigured, idpEnabled, loadIdpConfig, scopeForWebFlow } = require('./auth-config.js');
-const { firstAdminLogin, firstTimeAdmissionBlocked, joinabilityMode, maybeSeatFirstAdmin, membershipKind, openEnrollmentEnabled, webAdmissionStatus } = require('./auth-admission.js');
+const { firstAdminLogin, firstTimeAdmissionBlocked, joinabilityMode, maybeSeatFirstAdmin, membershipKind, openEnrollmentEnabled, readApplicantProfileFromHub, webAdmissionStatus } = require('./auth-admission.js');
 const { buildAuthorizeUrl, completeWebFlow, pollDeviceFlow, startDeviceFlow } = require('./auth-github.js');
 const { buildIdpAuthorizeUrl, completeDeviceExchange, completeIdpFlow, idpAuthorizeUrl, loadHubPublicKey, logoutTokenJtiSeenAndRecord, verifyHubAssertion, verifyHubLogoutToken } = require('./auth-idp.js');
 const { addDiscordGuildMember, buildDiscordAuthorizeUrl, discordAuthorizeUrl, discordBotConfigured, discordConfigured, exchangeDiscordCode, fetchDiscordUser, isValidDiscordUserId, loadDiscordBotToken, loadDiscordCreds, removeDiscordGuildMember } = require('./auth-discord.js');
@@ -787,6 +787,7 @@ module.exports = {
   idpConfigured,
   openEnrollmentEnabled,
   joinabilityMode,
+  readApplicantProfileFromHub,
   firstTimeAdmissionBlocked,
   webAdmissionStatus,
   firstAdminLogin,

package/src/module-api.js

@@ -55,7 +55,7 @@ const { buildInfo } = require('./build-info');
 // there. scripts/gds/bump-version.js still rewrites the literal below; it appends
 // the entry to that file. Look for a version's history there, not here.
 // ---------------------------------------------------------------------------
-const CORE_VERSION = '1.19.579'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
+const CORE_VERSION = '1.19.580'; // CI auto-patch carrier (ADR 0161); changelog: docs/module-api-changelog.md
 
 // A namespaced logger so a module's log lines are attributable + consistent.
 // Usage: const log = api.logger('dev-box'); log.info('mounted');
@@ -273,6 +273,16 @@ module.exports = {
   //     the other two had closed. Optional `{ publishable }` for a caller that
   //     holds a publish verdict — see src/bongos/project-door.js.
   projectJoinDoor: (opts) => require('./bongos/project-door').effectiveJoinDoor(opts),
+  // readApplicantProfileFromHub(githubId) — the reviewer queue's LIVE per-render
+  //     read of one applicant's hub profile view (privacy spec D7, task
+  //     1002972). Published as a NARROW port on purpose: the underlying call is
+  //     authenticated with this instance's hub client secret, and loadIdpConfig
+  //     stays off the doorway so no module ever holds the credential that speaks
+  //     for the whole project. A module passes one github_id and gets one
+  //     already-bounded view (or null) — it can neither widen the request nor
+  //     re-address it. Fails soft to null on every error, so a hub outage costs
+  //     the profile block and never the queue.
+  get readApplicantProfileFromHub() { return require('./bongos/auth').readApplicantProfileFromHub; },
   // userAgent — the instance's HTTP User-Agent string (branding-derived). The
   // carved lifecycle module's github-push.js stamps every GitHub API request with
   // it instead of reaching into src/branding.js directly (BV1.R86).