@bongos/core 1.20.27 → 1.20.28

package/tests/module_api.mjs

@@ -49,6 +49,7 @@ const PUBLISHED_SURFACE = [
   'artistGate', // added by task 1003575 (ADR 0241): the artist gate — off | advisory | strict, plus the pure verdict helpers over it. Two modules ask it two different questions ("file this review?" and "does an open one hold the deploy?") and both must resolve the knob through this one reader, never branding().project
   'readApplicantProfileFromHub', // added by task 1002972 (privacy spec D7): the reviewer queue's LIVE per-render read of one applicant's hub profile view. NARROW by design — 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
   'notifyHubOfInvite', // added by task 1002818 (ADR 0353): tell the hub about one of THIS project's invites (or its rescind) so the invitee sees it in My Projects. The same NARROW-port reason as readApplicantProfileFromHub: the call carries this instance's hub client secret, so a module passes one login and one direction and can neither widen nor re-address it
+  'inviteExpiry', // added by task 1002969 (ADR 0356): the ONE read-time definition of when a recruit invite's door closes. The sign-in gate reads it in core; the onboarding queues and the hub's notice list are modules, so without the doorway each would restate the 30 days and the predicate, and two copies can close a door on different days
   'readApplicationVouch', // added by task 1002285 (ADR 0201 D2): the public access-request write's check of the hub's application vouch. NARROW for the same reason — core supplies the hub key and this instance's client_id, so a module passes a token and a login and can neither swap the key nor re-address the audience
   'enabledDisciplines', // BV1.R81: instance offered-disciplines (1.9.0; onboarding restock backstop)
   'isModuleEnabled', // task 1003881: is ANOTHER module present? onboarding's Discord approve/decline control is only actionable when the `discord` module's reaction handler is loaded, so the posting half has to be able to ask

package/tests/project_admin_console_model.mjs

@@ -6,8 +6,9 @@
 // drift quietly is worse than none, so the load-bearing ones are pinned here:
 //
 //   D1  the hub relays and notifies; it never writes a project's admission row
-//   D2  an invite is a row the existing gate already reads — `kind` and
-//       `created_by` are descriptive and never enter the admission read
+//   D2  an invite is a row the existing gate already reads — `created_by` never
+//       enters the admission read, and `kind` enters it only through the invite
+//       expiry, which can close a door and never open one (ADR 0356 amends D2.5)
 //   D3  the admission verdict stays `access_request.review` at the archon floor,
 //       and `project.recruit`, once minted, takes exactly the shape the ADR fixes
 //
@@ -66,16 +67,22 @@ test('the ADR exists, is indexed, and ADR 0141 names it as superseding its §5 i
 
 // Both admission reads: the gate's own (hasInvitedAccessRequest) and the state the
 // "confirming access" waiting page polls (accessStateByLogin), which must agree with it.
-test('D2: both admission reads look at status alone — an invite and an approved application admit identically', () => {
+// Since ADR 0356 (task 1002969) `kind` reaches them through ONE door: the ANDed
+// invite-expiry unit, which only ever narrows `status = 'invited'`.
+test('D2: both admission reads look at status, narrowed only by the invite expiry — never widened by kind', () => {
   const src = read('src', 'bongos', 'db-kernel.js');
   for (const fn of ['hasInvitedAccessRequest', 'accessStateByLogin']) {
     const m = new RegExp(`async function ${fn}\\([^)]*\\)\\s*\\{([\\s\\S]*?)\\n\\}`).exec(src);
     assert.ok(m, `${fn} is still an admission read in db-kernel.js`);
     const body = m[1];
-    assert.match(body, /status\s*=\s*'invited'/, `${fn}: admission is status = invited`);
-    assert.doesNotMatch(body, /\bkind\b/, `${fn}: kind is descriptive; it must never decide admission`);
+    assert.match(body, /status\s*=\s*'invited'\s+AND\s+\$\{inviteLiveSql\(\)\}/, `${fn}: admission is status = invited AND the invite has not expired`);
+    assert.doesNotMatch(body, /\bkind\b/, `${fn}: kind is never read directly; only through inviteLiveSql`);
     assert.doesNotMatch(body, /\bcreated_by\b/, `${fn}: created_by is audit data; it must never decide admission`);
   }
+  // And that unit can only close a door: NOT (an invite AND past its window).
+  const { inviteLiveSql } = require('../src/bongos/invite-expiry.js');
+  assert.match(inviteLiveSql(), /^NOT \(kind = 'invite' AND created_at <= now\(\) - interval '\d+ days'\)$/,
+    'the expiry is a pure narrowing: a row that is not an invite is untouched by it');
 });
 
 test('D1: no hub (platform-identity) source writes access_requests — the hub relays, it never admits', () => {