@bongos/core 1.19.1081 → 1.20.1

package/modules/lifecycle/db-relevance-flags.js

@@ -0,0 +1,183 @@
+// modules/lifecycle/db-relevance-flags.js — the ADR 0101 Part 1 relevance/
+// anti-hack judge's data layer (task 1001691, goal 1000089): the flag table
+// (lifecycle_014) plus the CLAIM-time friction gate.
+//
+// THE BOUNDARY (ADR 0093 §1): this file reaches core ONLY through the
+// published doorway ../../src/module-api.js.
+//
+// relevanceFrictionFailures is the goalMembershipFailures precedent
+// (claim-feed.js): a pure-ish, DB-read gate check called from all THREE claim
+// surfaces (db-claims.js's claimTask / claimTasksBatch / validateClaimBatch),
+// so a flagged task cannot be claimed via any of them while friction_required
+// is true and the flag sits open. It is a SEPARATE file (not inlined into
+// db-claims.js) for the same reason claim-feed.js is: the table it reads is
+// this file's own domain, and a second claim surface duplicating the query
+// inline is exactly the bypass ADR 0101 Part 1 must not create.
+
+'use strict';
+
+const api = require('../../src/module-api');
+const { pool, withTx } = api;
+
+// createRelevanceFlag — INSERT the judge's verdict. Only ever called when the
+// judge flagged the task (verdict === 'flag'); an 'ok' verdict writes nothing,
+// same as idea_inbox only ever holding a captured idea.
+async function createRelevanceFlag({
+  taskId, goalId, builderId, confidence, reasoning, model, costUsd, frictionRequired,
+}) {
+  const { rows } = await pool.query(
+    `INSERT INTO lifecycle_goal_task_relevance_flags
+       (task_id, goal_id, flagged_builder_id, confidence, reasoning, model, cost_usd, friction_required)
+     VALUES ($1, $2, $3, $4, $5, $6, $7, $8)
+     RETURNING *`,
+    [taskId, goalId, builderId ?? null, confidence, reasoning ?? null, model ?? null, costUsd ?? 0, frictionRequired === true]
+  );
+  return rows[0];
+}
+
+// countPriorRelevanceFlagsForBuilder — the repeat-gaming signal the judge's
+// frictionRequired() weighs. Counts every flag ever raised against this
+// builder EXCEPT one a Metic already reviewed and called a false positive —
+// a reviewed-and-cleared flag is not evidence of a pattern, and counting it
+// would let one wrong judge call permanently escalate friction on an innocent
+// builder's every future task.
+async function countPriorRelevanceFlagsForBuilder(builderId) {
+  if (builderId == null) return 0;
+  const { rows } = await pool.query(
+    `SELECT count(*)::int AS n
+       FROM lifecycle_goal_task_relevance_flags
+      WHERE flagged_builder_id = $1
+        AND decision IS DISTINCT FROM 'false_positive'`,
+    [builderId]
+  );
+  return rows[0] ? rows[0].n : 0;
+}
+
+// listPendingRelevanceFlags — the Metic review queue (mirrors /goal-review's
+// / /idea-triage's queue cadence): every open flag, oldest first, with enough
+// of the task + goal to triage without a second round trip.
+//
+// DELIBERATELY NOT ADR-0112-SCOPED to the reader's own goal membership,
+// unlike sky.js/goal-graph.js/activity.js's "a private goal loses EVERY piece
+// of prose" rule. Those are general-purpose reads a builder's own membership
+// bounds; this is a POLICING surface — the reviewer's authority (perm
+// task.promote, Metic+) is exactly the authority to see what is being flagged
+// as possible gaming, private goal or not, the same way an idea's Full-Idea
+// text is shown in full to the Board Room rather than redacted per-viewer.
+// Narrowing it to members-only would let a private goal's own gaming go
+// unreviewed by anyone outside it.
+async function listPendingRelevanceFlags({ limit = 50 } = {}) {
+  const { rows } = await pool.query(
+    `SELECT f.*, t.title AS task_title, t.description AS task_description,
+            t.touches AS task_touches, g.title AS goal_title
+       FROM lifecycle_goal_task_relevance_flags f
+       JOIN tasks t ON t.id = f.task_id
+       JOIN goals g ON g.id = f.goal_id
+      WHERE f.status = 'open'
+      ORDER BY f.created_at ASC
+      LIMIT $1`,
+    [Math.max(1, Math.min(200, Number(limit) || 50))]
+  );
+  return rows;
+}
+
+// decideRelevanceFlag — a Metic resolves the flag. Either decision CLEARS the
+// friction hold (status flips to 'resolved'): the hold exists to get a human's
+// eyes on it, never to police the verdict forever (ADR 0101 Part 1: "never a
+// silent, opaque AI no"). Returns null when there is no OPEN flag with that id
+// — an already-decided or nonexistent flag is not re-decided.
+//
+// SELF-DECIDE IS REFUSED, unlike db-overrides.js's artist-gate release (which
+// PERMITS and merely records a self-release — the normal case on a solo
+// instance). Here it is the opposite: the whole point of the friction hold is
+// a Metic CO-SIGN on the flagged builder's OWN work, so letting that same
+// builder clear their own hold defeats it outright (hacker finding) — never
+// exempted by rank, since a Metic/Archon author is exactly who a repeat/high-
+// confidence flag is watching. A genuinely solo instance still has the
+// existing task_override_requests escape valve for anything this refuses.
+//
+// AUDITED regardless of outcome (api.insertAuditLog) — best-effort: the
+// decision is durable in the flag row, and a failed audit write must not roll
+// back a Metic's actual decision, only log loudly.
+//
+// LOCKED, not two independent statements: the self-decide check and the
+// UPDATE run inside ONE transaction with the row taken FOR UPDATE first — the
+// removal-proposals.js / db-overrides.js precedent — so two concurrent
+// decides on the same flag can't both read 'open' and race past the check;
+// the second finds the row already 'resolved' and returns null, never a
+// second self-decide-checked write.
+async function decideRelevanceFlag({ flagId, decidedByBuilderId, decision, note }) {
+  const flag = await withTx(async (client) => {
+    const { rows: flagRows } = await client.query(
+      `SELECT flagged_builder_id FROM lifecycle_goal_task_relevance_flags WHERE id = $1 AND status = 'open' FOR UPDATE`,
+      [flagId]
+    );
+    if (flagRows.length === 0) return null;
+    if (flagRows[0].flagged_builder_id != null && String(flagRows[0].flagged_builder_id) === String(decidedByBuilderId)) {
+      throw Object.assign(new Error('a flagged builder may not decide their own relevance flag'), {
+        code: 'SELF_DECIDE_FORBIDDEN',
+      });
+    }
+    const { rows } = await client.query(
+      `UPDATE lifecycle_goal_task_relevance_flags
+          SET status = 'resolved', decision = $2, decided_by_builder_id = $3,
+              decided_at = now(), decision_note = $4
+        WHERE id = $1 AND status = 'open'
+        RETURNING *`,
+      [flagId, decision, decidedByBuilderId, note ?? null]
+    );
+    return rows[0] || null;
+  });
+  if (flag) {
+    try {
+      await api.insertAuditLog({
+        builderId: decidedByBuilderId,
+        route: '/api/bongos/goal-task-relevance/:id/decide',
+        method: 'POST',
+        requestBodyRedacted: { flag_id: String(flag.id), task_id: String(flag.task_id), decision },
+        responseStatus: 200,
+      });
+    } catch (e) {
+      api.logger('lifecycle').error(`[relevance-flag] decide ${flag.id}: audit write failed — ${e && e.message}`);
+    }
+  }
+  return flag;
+}
+
+// relevanceFrictionFailures — the CLAIM-time gate (the goalMembershipFailures
+// shape, claim-feed.js). `client` is the caller's open txn client (claimTask)
+// or the pool itself (validateClaimBatch's read-only dry run) — same
+// convention goalMembershipFailures already uses. Returns
+// [{ task_id, refusal }], empty when nothing is held.
+async function relevanceFrictionFailures({ client, tasks }) {
+  const ids = (tasks || []).map((t) => Number(t.id)).filter((n) => Number.isFinite(n));
+  if (ids.length === 0) return [];
+  const { rows } = await client.query(
+    `SELECT task_id FROM lifecycle_goal_task_relevance_flags
+      WHERE task_id = ANY($1::bigint[]) AND friction_required = true AND status = 'open'`,
+    [ids]
+  );
+  const held = new Set(rows.map((r) => Number(r.task_id)));
+  if (held.size === 0) return [];
+  return ids
+    .filter((id) => held.has(id))
+    .map((id) => ({
+      task_id: id,
+      refusal: {
+        code: 'RELEVANCE_REVIEW_PENDING',
+        message: 'The ADR 0101 relevance judge flagged this task as possible scope-gaming; '
+          + 'it needs a Metic to review before it can be claimed. This never permanently blocks '
+          + 'the task — either decision (confirmed or false positive) releases it.',
+        hint: 'A Metic can review it via GET /goal-task-relevance/pending and '
+          + 'POST /goal-task-relevance/:id/decide.',
+      },
+    }));
+}
+
+module.exports = {
+  createRelevanceFlag,
+  countPriorRelevanceFlagsForBuilder,
+  listPendingRelevanceFlags,
+  decideRelevanceFlag,
+  relevanceFrictionFailures,
+};

package/modules/lifecycle/db-versions.js

@@ -425,7 +425,8 @@ async function closeVersion({ versionId, plan = [], reason, planningVersionId =
           });
         }
         // The successor carries what makes the goal itself — its prose, its scope
-        // wall, its category and its visibility. It does NOT carry `is_maintenance`
+        // wall, its category, its visibility and its working area (task 1004057 —
+        // area 6 on the next version is still area 6). It does NOT carry `is_maintenance`
         // (the successor version gets its own via ensureMaintenanceGoal) and it
         // does not carry admissions: an override that widened THIS version's scope
         // is spent, and re-creating the row would launder a one-time exception into
@@ -435,9 +436,9 @@ async function closeVersion({ versionId, plan = [], reason, planningVersionId =
              SELECT COALESCE(MAX(sort_order) + 1, 0) AS n FROM goals WHERE version_id = $2
            )
            INSERT INTO goals (version_id, title, subtitle, description, scope_modules,
-                              status, visibility, accepting_requests, created_by, sort_order, category_id)
+                              status, visibility, accepting_requests, created_by, sort_order, category_id, working_area)
            SELECT $2, g.title, g.subtitle, g.description, g.scope_modules,
-                  'open', g.visibility, g.accepting_requests, g.created_by, next_order.n, g.category_id
+                  'open', g.visibility, g.accepting_requests, g.created_by, next_order.n, g.category_id, g.working_area
              FROM goals g, next_order
             WHERE g.id = $1
            RETURNING id`,

package/modules/lifecycle/db.js

@@ -141,6 +141,7 @@ const dbTasksFacade = Object.fromEntries(
 const {
   addDependency,
   addTaskCriterion,
+  addTaskDependencies,
   addTaskDependency,
   attachTaskDepSummaries,
   countTasksWithoutCriterionLink,
@@ -170,6 +171,9 @@ const {
   gradeByBuilder,
   gradeTrendByDay,
   logGradeAttempt,
+  gradeAttemptVerdicts,
+  workerVerdicts,
+  VERDICT_LIMITS,
   mergeLeaseStatus,
   recentGradesForBuilder,
   recentShippedTasks,
@@ -202,6 +206,12 @@ const {
   listOverrideRequests,
 } = require('./db-overrides.js');
 const { applyGrade } = require('./db-grade.js');
+const {
+  createRelevanceFlag,
+  countPriorRelevanceFlagsForBuilder,
+  listPendingRelevanceFlags,
+  decideRelevanceFlag,
+} = require('./db-relevance-flags.js');
 const {
   getActiveClaimsForBuilder,
   getActiveClaimsForSession,
@@ -295,6 +305,7 @@ module.exports = {
   getTaskDependencies,
   getTaskDependents,
   attachTaskDepSummaries,
+  addTaskDependencies,
   addTaskDependency,
   removeTaskDependency,
   setTaskDependencies,
@@ -354,9 +365,17 @@ module.exports = {
   listOverrideRequests,
   decideOverrideRequest,
   logGradeAttempt,
+  gradeAttemptVerdicts, // task 1004292: every round's per-worker verdicts, for the correlation audit
+  workerVerdicts,
+  VERDICT_LIMITS,
   countGradeAttempts,
   gradeAttemptStats, // task 1002661: the grade_attempts remediation-rate reader
   acquireMergeLease,
   releaseMergeLease,
   mergeLeaseStatus,
+  // ADR 0101 Part 1 (task 1001691) — the relevance/anti-hack judge's flag table.
+  createRelevanceFlag,
+  countPriorRelevanceFlagsForBuilder,
+  listPendingRelevanceFlags,
+  decideRelevanceFlag,
 };

package/modules/lifecycle/done-when.js

@@ -78,7 +78,7 @@ async function listCriteria(versionId) {
 // and criteriaGroupedByGoal so the goals query lives in one place.
 async function listGoalsForVersion(versionId) {
   const { rows } = await pool.query(
-    `SELECT id, title, status, scope_modules
+    `SELECT id, title, status, scope_modules, working_area
        FROM goals
       WHERE version_id = $1
       ORDER BY created_at, id`,
@@ -226,7 +226,8 @@ async function criterionProgress(versionId) {
 }
 
 // Group the flat criteria under their goals (Version → Goals → Criteria, ADR 0086
-// §2). Pure: takes the goal rows (id, title, status, scope_modules) + the built
+// §2). Pure: takes the goal rows (id, title, status, scope_modules, working_area
+// — the ADR 0264 area number or null, task 1004057) + the built
 // criteria, returns the goals[] each carrying its criteria in cnum order. A goal
 // with no criteria is kept (renders gracefully). Criteria whose goal_id matches no
 // goal row (shouldn't happen post-backfill, but defended) collect under a trailing
@@ -239,6 +240,7 @@ function buildGoals(goalRows, criteria) {
       title: g.title,
       status: g.status,
       scope_modules: g.scope_modules || [],
+      working_area: g.working_area == null ? null : Number(g.working_area),
       criteria: [],
     });
   }
@@ -249,7 +251,7 @@ function buildGoals(goalRows, criteria) {
   }
   const goals = [...byGoal.values()];
   if (ungrouped.length) {
-    goals.push({ id: null, title: '(ungrouped)', status: 'open', scope_modules: [], criteria: ungrouped });
+    goals.push({ id: null, title: '(ungrouped)', status: 'open', scope_modules: [], working_area: null, criteria: ungrouped });
   }
   return goals;
 }

package/modules/lifecycle/est-advisory.js

@@ -129,10 +129,37 @@ function adviseEstimate({ estMinutes, kind, summary, taskId = null }) {
 // Lives HERE rather than in db.js: db.js is over the size ratchet's cap and this
 // is the only caller. The pool comes through the published module doorway.
 // Deliberately not fail-open — buildEstAdvisory below is the single failure site.
-async function calibrationSummary({ pool } = {}) {
+//
+// CACHED (task 1003656): the function is a full historical aggregate (percentile_cont
+// per kind over every shipped row), yet the population only moves when a task ships —
+// not on every create. A short in-process TTL bounds the staleness to a minute (the
+// advisory is a scale hint over ~1,000 rows; one more ship cannot move a median
+// noticeably), concurrent creates share one in-flight query, and a failure is never
+// cached so the next create retries. Keyed on the pool so a test's fake pool is never
+// served another pool's rows.
+const CALIBRATION_TTL_MS = 60 * 1000;
+let calibrationCache = null; // { pool, at, rows } | { pool, inflight }
+
+function resetCalibrationCache() { calibrationCache = null; }
+
+async function calibrationSummary({ pool, now = Date.now } = {}) {
   const p = pool || require('../../src/module-api').getPool();
-  const { rows } = await p.query('SELECT kind, median_ratio, sample_size FROM pms_calibration_summary()');
-  return rows || [];
+  const c = calibrationCache;
+  if (c && c.pool === p) {
+    if (c.inflight) return c.inflight;
+    if (now() - c.at < CALIBRATION_TTL_MS) return c.rows;
+  }
+  const inflight = p.query('SELECT kind, median_ratio, sample_size FROM pms_calibration_summary()')
+    .then(({ rows }) => {
+      const out = rows || [];
+      calibrationCache = { pool: p, at: now(), rows: out };
+      return out;
+    }, (e) => {
+      if (calibrationCache && calibrationCache.inflight === inflight) calibrationCache = null;
+      throw e;
+    });
+  calibrationCache = { pool: p, inflight };
+  return inflight;
 }
 
 // The DB-touching wrapper. NON-BLOCKING BY CONSTRUCTION — any failure yields null
@@ -159,4 +186,4 @@ async function buildEstAdvisory({ db, task } = {}) {
   }
 }
 
-module.exports = { adviseEstimate, pickRatio, buildEstAdvisory, calibrationSummary, MIN_MATERIAL_DELTA, SCALE_OK_RATIO, MIN_KIND_SAMPLES, MIN_OVERALL_SAMPLES };
+module.exports = { adviseEstimate, pickRatio, buildEstAdvisory, calibrationSummary, resetCalibrationCache, CALIBRATION_TTL_MS, MIN_MATERIAL_DELTA, SCALE_OK_RATIO, MIN_KIND_SAMPLES, MIN_OVERALL_SAMPLES };

package/modules/lifecycle/goal-task-relevance-advisory.js

@@ -0,0 +1,153 @@
+// modules/lifecycle/goal-task-relevance-advisory.js — wires the ADR 0101 Part 1
+// judge (goal-task-relevance-judge.js) live on POST /goals/:id/tasks (task
+// 1001691, goal 1000089).
+//
+// FIRE-AND-FORGET, DELIBERATELY — the one place this file departs from the
+// goal-advisory.js / dependency-advisory.js precedent it otherwise follows.
+// Those advisories are pure DB reads and are AWAITED inline so their verdict
+// can ride the 201 response. This one spawns a real model call (a `claude -p`
+// subprocess via grade.runSubagent, seconds at the cheapest rung), and ADR
+// 0101 Part 1 requires the judge be advisory and never slow down — let alone
+// fail — the create it reviews. So runRelevanceJudge is invoked WITHOUT await
+// right after the task is created (goals.js) and reports through the flag
+// table instead of the create response, the same non-blocking, post-commit
+// posture modules/lifecycle/cascade.js already uses for ship-time rules ("it
+// can never fail the ship it reacts to").
+//
+// Swallows every failure — a judge outage must degrade to "no flag was
+// raised", never to a 500 on an already-committed task.
+
+'use strict';
+
+const { assessGoalTaskRelevance } = require('./goal-task-relevance-judge.js');
+
+// THE SPAWN BUDGET (hacker/efficiency findings, rounds 2-3): an any-builder
+// write (POST /goals/:id/tasks) fires this judge un-awaited, so with no cap
+// here a create-burst (a planning session authoring N goal-tasks in a loop)
+// would fan out to N concurrent `claude -p` subprocesses — unbounded host
+// CPU/memory and unbounded billable spend, worse still once a failing rung
+// escalates (runSubagentAsRunner) rather than aborting after one attempt.
+// Two axes, deliberately scoped DIFFERENTLY:
+//   - CONCURRENCY is GLOBAL (host CPU/memory is a genuinely shared resource —
+//     capping it per builder would still let N builders each run their own
+//     cap concurrently and sum past the host's real limit).
+//   - the RATE WINDOW is PER BUILDER (round-3 finding: a global window meant
+//     the exact actor this control polices could burst MAX_JUDGES_PER_WINDOW
+//     innocuous creates, then file the gaming task while the window sat
+//     exhausted — invisible AND collateral, since it blinded every OTHER
+//     builder's judge too, not just their own). Per-builder scoping removes
+//     the cross-builder blast radius entirely; it does NOT remove a single
+//     actor's ability to exhaust their OWN window before their one gaming
+//     task — an accepted residual, consistent with the ADR's own "a wrong or
+//     missed judge call costs a review, never a builder's ability to work"
+//     stance (Part 1's whole reason to be advisory rather than a hard gate).
+// Process-local, in-memory — no new table, no cross-request coordination
+// needed for a single instance's app host. Over either cap, the judge is
+// SKIPPED (never queued, never blocking) — advisory means the check itself
+// may go missing under load, exactly like a judge outage degrading to "no
+// flag was raised". The per-builder map is capped (evicts the oldest entry)
+// so an unbounded stream of distinct builder ids can't grow it forever.
+const MAX_CONCURRENT_JUDGES = 2;
+const MAX_JUDGES_PER_WINDOW_PER_BUILDER = 10;
+const WINDOW_MS = 60_000;
+const MAX_TRACKED_BUILDERS = 5_000;
+let inFlight = 0;
+const perBuilderWindows = new Map(); // builderId -> { windowStartedAt, count }
+
+function judgeBudgetAllows(builderId) {
+  if (inFlight >= MAX_CONCURRENT_JUDGES) return false;
+  const key = builderId == null ? 'anonymous' : String(builderId);
+  const now = Date.now();
+  const entry = perBuilderWindows.get(key);
+  if (!entry || now - entry.windowStartedAt >= WINDOW_MS) return true; // fresh window
+  return entry.count < MAX_JUDGES_PER_WINDOW_PER_BUILDER;
+}
+
+// consumeJudgeBudget — call ONLY after judgeBudgetAllows() passed, atomically
+// with that check (both run synchronously in runRelevanceJudge, no await
+// between them, so two concurrent calls can't both pass the check and both
+// consume against a stale count).
+//
+// ALWAYS delete-then-set, never mutate an existing entry in place (round-4
+// quality finding): a Map keeps a key's ORIGINAL insertion position across a
+// plain `.set()` on an already-present key, so mutating `entry.count` in
+// place left a persistently active builder's key frozen at the front of
+// iteration order forever — exactly the "oldest" position the eviction below
+// deletes from, so the MOST active builder was the first one evicted once
+// MAX_TRACKED_BUILDERS distinct ids had ever been seen. Deleting before
+// re-setting moves a touched key to the END, so the front of the map is
+// always the genuinely least-recently-touched builder — real LRU eviction.
+function consumeJudgeBudget(builderId) {
+  const key = builderId == null ? 'anonymous' : String(builderId);
+  const now = Date.now();
+  const entry = perBuilderWindows.get(key);
+  const fresh = !entry || now - entry.windowStartedAt >= WINDOW_MS;
+  perBuilderWindows.delete(key);
+  perBuilderWindows.set(key, fresh ? { windowStartedAt: now, count: 1 } : { windowStartedAt: entry.windowStartedAt, count: entry.count + 1 });
+  if (perBuilderWindows.size > MAX_TRACKED_BUILDERS) {
+    perBuilderWindows.delete(perBuilderWindows.keys().next().value);
+  }
+}
+
+// runRelevanceJudge — the whole non-blocking pipeline: resolve the grade port
+// (best-effort — a grading-disabled instance simply runs no judge), read the
+// builder's prior-flag count, assess, and persist a flag row IF the verdict
+// was 'flag'. An 'ok' verdict writes nothing (the idea_inbox precedent: only
+// what needs a human's attention becomes a row).
+async function runRelevanceJudge({ db, api, goal, task }) {
+  const log = api.logger('lifecycle');
+  try {
+    const grade = api.resolveOptional('grade');
+    if (!grade) return null; // grading module off — no judge, not an error
+    if (!judgeBudgetAllows(task.created_by)) {
+      log.info('relevance-judge skipped (over the in-flight/per-builder-rate budget)', { task_id: task.id, builder_id: task.created_by });
+      return null;
+    }
+    consumeJudgeBudget(task.created_by);
+    inFlight += 1;
+    let assessment;
+    try {
+      const priorFlagCount = await db.countPriorRelevanceFlagsForBuilder(task.created_by);
+      assessment = await assessGoalTaskRelevance({
+        goal, task, priorFlagCount, grade, cascadeDispatch: api.cascadeDispatch,
+      });
+    } finally {
+      inFlight -= 1;
+    }
+    // Spend visibility (src/bongos/CLAUDE.md: "a new spend path that skips
+    // these is invisible to the ledger"). An 'ok' verdict writes no flag row
+    // (only what needs a human's attention becomes one), so its cost would
+    // otherwise vanish entirely — logged here at minimum. It does NOT reach
+    // cost_log: that table is written by builder-facing CLI flows through an
+    // authenticated session (scripts/gds/ship-grade-steps.js), and this judge
+    // runs inside the live server with no such session to post through; wiring
+    // a live-server spend port for the economy module is real work beyond this
+    // task's scope, tracked as a known gap rather than silently left unstated.
+    if (assessment) {
+      log.info('relevance-judge spend', { task_id: task.id, model: assessment.model, cost_usd: assessment.cost_usd, verdict: assessment.verdict });
+    }
+    if (!assessment || assessment.verdict !== 'flag') return null;
+    return await db.createRelevanceFlag({
+      taskId: task.id,
+      goalId: goal.id,
+      builderId: task.created_by,
+      confidence: assessment.confidence,
+      reasoning: assessment.reasoning,
+      model: assessment.model,
+      costUsd: assessment.cost_usd,
+      frictionRequired: assessment.friction_required,
+    });
+  } catch (e) {
+    log.error('relevance-judge (non-blocking, post-create)', e && e.message);
+    return null;
+  }
+}
+
+// Exported for tests/goal_task_relevance.mjs — pure state, no pool, so the
+// budget logic is unit-tested without spawning anything.
+function _resetJudgeBudgetForTests() {
+  inFlight = 0;
+  perBuilderWindows.clear();
+}
+
+module.exports = { runRelevanceJudge, _resetJudgeBudgetForTests };