@bongos/core 1.19.274 → 1.19.276

package/modules/ideas/inbox.js

@@ -15,7 +15,11 @@
 // the shared pool through the published doorway (src/module-api.js — the only
 // core file a module may require, ADR 0083). OTB byte-identical.
 
-const { pool } = require('../../src/module-api');
+const api = require('../../src/module-api');
+const { pool } = api;
+// The landing matrix (task 1003065, BV1.R01) — pure, DB-free, its own file so
+// every cell is unit-testable without a Postgres. See ./routing.js.
+const { decideLanding, authorizeRoutedLanding, routedPriority } = require('./routing');
 
 const VALID_KINDS = [
   'feature',
@@ -48,6 +52,13 @@ const IDEA_COL_NAMES = [
   'id', 'title', 'body_md', 'kind', 'suggested_version', 'suggested_priority',
   'captured_at', 'captured_by', 'status', 'promoted_to_task_id', 'reviewed_at',
   'merged_into_idea_id', 'triage_note',
+  // core_222 (task 1003060, BV1.R02): the routing HINT — "this probably belongs
+  // to goal N" — on a row that did NOT convert. Added to the shared list because
+  // R02 shipped the column and nothing read it: /idea-triage (R13) cannot walk
+  // homeless-only work if the read that feeds it never returns the hint. Strictly
+  // advisory: no rank check, no scope wall, and no payout may read it (see the
+  // migration's own header). The BINDING home for "which goal" is tasks.goal_id.
+  'suggested_goal_id',
 ];
 const IDEA_COLS = IDEA_COL_NAMES.join(', ');
 const IDEA_COLS_Q = IDEA_COL_NAMES.map((c) => `i.${c}`).join(', ');
@@ -169,6 +180,41 @@ function classify(title, body = '') {
 // Capture
 // -------------------------------------------------------------------------
 
+// captureIdea — THE ONE CAPTURE CHOKEPOINT, and since task 1003065 (BV1.R01,
+// goal 1000071) also the routing one.
+//
+// WHY ROUTING LIVES HERE AND NOT IN A NEW SIBLING FUNCTION. Every filing vector
+// already funnels through this call — the hall, `capture.js`, the Discord #ideas
+// inbound (via the `ideas.capture` port), agents, seeds. Putting the conversion
+// here means all of them inherit routing by passing ONE new argument, and none of
+// them can acquire a second, attribution-free path to a task. A `captureAndRoute`
+// sibling would have been the same code with an invitation to bypass it.
+//
+// TWO SHAPES, ONE ENTRY POINT:
+//   * goalId absent, or the matrix says don't route  → EXACTLY today's behaviour:
+//     one INSERT, status='open', the idea sits in the inbox. A named-but-unrouted
+//     goal is kept as the core_222 `suggested_goal_id` HINT so /idea-triage (R13)
+//     inherits the guess instead of re-deriving it.
+//   * the matrix says route → ONE TRANSACTION writes the idea row (status
+//     'promoted'), the task (in the goal, at the matrix's status), and the
+//     ideas_task_lineage row (origin='route').
+//
+// THE TRANSACTION IS THE POINT, not an optimisation. This goal exists because
+// Discord #bugs creates tasks DIRECTLY — no captured_by, no lineage — so the
+// ideator-credit lane (goal 1000067) has nothing to pay against. A route that
+// committed the task but lost the lineage row would manufacture exactly that
+// bug, at scale, on the path whose whole promise is that attribution survives
+// (criterion C3). So all three writes commit together or none do.
+//
+// `filerRank`/`grade` are READ-ONLY INPUTS TO THE DECISION. This function never
+// checks authority: the rank floor and the goal's scope wall are separate,
+// load-bearing server-side gates (R05). A caller lying about filerRank can move a
+// bug from 'backlog' to 'ready' and nothing else — which is why R06's abuse matrix
+// tests the route, not this function.
+//
+// `deps` carries the #538 test seam (`deps.pool`, NODE_ENV==='test' only) so the
+// whole transaction is drivable by a SQL-aware fake client with no live Postgres
+// (tests/idea_routing.mjs).
 async function captureIdea({
   title,
   bodyMd = '',
@@ -176,7 +222,18 @@ async function captureIdea({
   suggestedVersion = null,
   suggestedPriority = null,
   capturedBy = null,
-}) {
+  // task 1003065 (BV1.R01) — the routing inputs. All three default to the
+  // pre-routing behaviour, so every existing caller is untouched.
+  goalId = null,
+  filerRank = null,
+  grade = null,
+  // task 1003066 (BV1.R05): OPTIONAL declared blast radius. A human reporting a
+  // bug never supplies this — demanding it as the price of reporting is the
+  // triage tax this goal removes — but a programmatic filer that DOES know
+  // (a hall filing surface, a Discord classifier) can, and when it does the
+  // goal's scope wall is applied to it verbatim. See ./routing.js.
+  touches = null,
+}, deps = {}) {
   if (!title || typeof title !== 'string') {
     throw { code: 'TITLE_REQUIRED' };
   }
@@ -190,17 +247,222 @@ async function captureIdea({
   ) {
     throw { code: 'BAD_PRIORITY', priority: suggestedPriority };
   }
-  const { rows } = await pool.query(
+  const activePool = (deps.pool && process.env.NODE_ENV === 'test') ? deps.pool : pool;
+
+  // The decision, before any write. Pure — see ./routing.js.
+  const landing = decideLanding({ goalId, kind: resolvedKind, grade, filerRank });
+  if (landing.route) {
+    return routeIdeaToGoal({
+      title, bodyMd, resolvedKind, suggestedVersion, suggestedPriority,
+      capturedBy, goalId, landing, filerRank, touches,
+    }, activePool);
+  }
+
+  // NOT routed: the pre-routing path, plus the advisory hint. `suggested_goal_id`
+  // is written even when a goal WAS named — that is the whole reason the column
+  // exists (core_222): a Full Idea or a criterion-proposal that named a goal
+  // should carry the guess forward to triage rather than drop it on the floor.
+  const { rows } = await activePool.query(
     `INSERT INTO idea_inbox
-       (title, body_md, kind, suggested_version, suggested_priority, captured_by, status)
-     VALUES ($1, $2, $3, $4, $5, $6, 'open')
+       (title, body_md, kind, suggested_version, suggested_priority, captured_by, status,
+        suggested_goal_id)
+     VALUES ($1, $2, $3, $4, $5, $6, 'open',
+             $7)
      RETURNING ${IDEA_COLS}`,
-    [title, bodyMd, resolvedKind, suggestedVersion, suggestedPriority, capturedBy]
+    [title, bodyMd, resolvedKind, suggestedVersion, suggestedPriority, capturedBy,
+      goalId ?? null]
   );
   // A brand-new idea has no ideas_grades row, so it is quick by definition —
   // no join needed to know that. Grading it (R143's Full Idea capture) is a
   // separate setIdeaGrade write against the id this returns.
-  return rows[0] ? { ...ungradedProjection(), ...rows[0] } : rows[0];
+  const idea = rows[0] ? { ...ungradedProjection(), ...rows[0] } : rows[0];
+  // The reason is echoed so a caller (and the R15 sweep) can tell "no goal was
+  // named" from "a goal was named and the matrix declined it" without re-running
+  // the matrix. Non-enumerable would be cleaner but this row is JSON-serialised
+  // straight onto the 201 body, and the filer deserves to see why.
+  if (idea) idea.routing = { routed: false, reason: landing.reason };
+  return idea;
+}
+
+// routeIdeaToGoal — the ONE transaction behind a routed capture (task 1003065,
+// BV1.R01). Private: `captureIdea` is the only legal way in, so the matrix can
+// never be skipped.
+//
+// Order is forced by the foreign keys, not by preference: the lineage row
+// references BOTH the idea and the task, so the idea must exist before the task
+// (which carries no idea reference) and both before the lineage. That leaves
+// `promoted_to_task_id` unknowable at insert time, hence the second UPDATE —
+// the same two-step ratifyCriterionProposal takes.
+async function routeIdeaToGoal({
+  title, bodyMd, resolvedKind, suggestedVersion, suggestedPriority,
+  capturedBy, goalId, landing, filerRank = null, touches = null,
+}, activePool) {
+  const client = await activePool.connect();
+  try {
+    await client.query('BEGIN');
+
+    // a. The goal must be a REAL, LIVE HOME. All three checks are inside the
+    //    transaction and the row is locked FOR SHARE, so a goal cannot be
+    //    archived out from under a route that is mid-flight.
+    //
+    //    version status='building' is the load-bearing one, and it is the
+    //    1000771 failure this goal was filed over: Discord #bugs hardcoded a
+    //    SHIPPED version, so every reported bug landed in a shipped version's
+    //    catch-all where nobody would ever look again. A closed version cannot
+    //    receive new work — the route refuses rather than filing into a tomb.
+    const { rows: goalRows } = await client.query(
+      `SELECT g.id, g.status, g.version_id, g.scope_modules, v.status AS version_status
+         FROM goals g
+         JOIN versions v ON v.id = g.version_id
+        WHERE g.id = $1
+        FOR SHARE OF g`,
+      [goalId]
+    );
+    if (goalRows.length === 0) throw { code: 'GOAL_NOT_FOUND', goal_id: goalId };
+    const goal = goalRows[0];
+    if (goal.status !== 'open') {
+      throw { code: 'GOAL_NOT_OPEN', goal_id: goalId, status: goal.status };
+    }
+    if (goal.version_status !== 'building') {
+      throw {
+        code: 'VERSION_NOT_BUILDING',
+        goal_id: goalId,
+        version_id: goal.version_id,
+        version_status: goal.version_status,
+      };
+    }
+
+    // b. The idea row — 'promoted' from birth, because it WAS promoted, in this
+    //    same act. reviewed_at is stamped so the triage walk skips it: routing's
+    //    entire claim is that this row never needed a triage pass.
+    const { rows: ideaRows } = await client.query(
+      `INSERT INTO idea_inbox
+         (title, body_md, kind, suggested_version, suggested_priority, captured_by, status,
+          suggested_goal_id, reviewed_at)
+       VALUES ($1, $2, $3, $4, $5, $6, 'promoted',
+               $7, now())
+       RETURNING ${IDEA_COLS}`,
+      [title, bodyMd, resolvedKind, suggestedVersion, suggestedPriority, capturedBy,
+        goalId]
+    );
+    const idea = ideaRows[0];
+
+    // b2. THE BINDING GATE (task 1003066, BV1.R05). The matrix said what status;
+    //     this says whether the filing is allowed at all and what rank floor the
+    //     task is born with. Both facts come off the goal row we just LOCKED, so
+    //     a rescope cannot land between the check and the insert.
+    //
+    //     scopeIncludesProtected + goalScopeCheck both come through the published
+    //     doorway — the SAME protected roster the pre-push hook, the grader and
+    //     main-audit read (permission-path-check), so this wall cannot drift from
+    //     them. The wall only runs when touches were declared; see ./routing.js
+    //     for why an absent touches[] moves the protection to the rank floor
+    //     instead of refusing the report.
+    const declaredTouches = Array.isArray(touches) ? touches.filter(Boolean) : [];
+    const authorized = authorizeRoutedLanding({
+      landing,
+      filerRank,
+      scopeProtected: api.moduleScopeMap.scopeIncludesProtected(goal.scope_modules),
+      scopeCheck: declaredTouches.length
+        ? api.goalScopeCheck.check(goal.scope_modules, declaredTouches, filerRank)
+        : null,
+    });
+    if (!authorized.ok) {
+      throw {
+        code: 'ROUTE_NOT_AUTHORIZED',
+        goal_id: goalId,
+        gate: authorized.code,
+        reason: authorized.reason,
+        details: authorized.details ?? null,
+      };
+    }
+
+    // c. The task, through the `lifecycle` PORT — never an import of
+    //    modules/lifecycle/ (the one-way module rule, ADR 0083). Resolved at call
+    //    time; the port registers at boot. Passing `client` enlists the INSERT in
+    //    THIS transaction (the seam task 1003065 added to db.createTask).
+    //
+    //    The version is the GOAL'S, never a caller-supplied one, so
+    //    "goal belongs to the version" is true by construction rather than by
+    //    validation. (An idea's own `suggested_version` is kept on the idea row
+    //    as filed and does NOT override it — the goal is the binding home.) One
+    //    read stays outside this transaction by design: createTask's catch-all
+    //    goal fallback, which only runs when goalId is absent and so never on
+    //    this path.
+    //
+    //    `requiresRank` is passed ONLY as the R05 protected-scope floor computed
+    //    above — never from anything the filer said. createTask still derives its
+    //    own floor and takes the HIGHER of the two, so this can raise the bar and
+    //    never lower it. Deliberately NOT passed at all: `creditsReward` (server
+    //    default — createTask auto-assigns the capped suggestion) and
+    //    `discipline` (left 'unclassified', exactly as the other non-authored
+    //    create vectors leave it).
+    const lifecycle = api.resolveOptional && api.resolveOptional('lifecycle');
+    if (!lifecycle || !lifecycle.createTask) {
+      // A vanilla instance without the lifecycle module cannot hold tasks at all,
+      // so there is nothing to route INTO. Refuse loudly rather than silently
+      // degrading to an inbox row the caller was told became a task.
+      throw { code: 'LIFECYCLE_UNAVAILABLE' };
+    }
+    const task = await lifecycle.createTask({
+      versionId: goal.version_id,
+      title,
+      description: bodyMd,
+      status: authorized.status,
+      kind: resolvedKind,
+      priority: routedPriority(suggestedPriority),
+      goalId: goal.id,
+      touches: declaredTouches,
+      // task 1003066 (BV1.R05): the protected-scope floor. null on an ordinary
+      // goal, so createTask derives the floor exactly as for every other vector;
+      // 'metic' when the goal reaches protected territory, and highestRank()
+      // clamps UPWARD only — this can raise a floor, never drop one.
+      ...(authorized.requiresRank ? { requiresRank: authorized.requiresRank } : {}),
+      // The provenance pair the create-vector idempotency read keys on
+      // (db.findTaskBySourceRef): one idea can only ever mint one routed task.
+      source: 'idea-route',
+      sourceRef: `idea-${idea.id}`,
+    }, { client });
+
+    // d. The lineage row — origin='route' (ideas_003 widened the CHECK for
+    //    exactly this). THIS is the row goal 1000067's ideator credit will pay
+    //    against, and the reason all of this is one transaction.
+    await client.query(
+      `INSERT INTO ideas_task_lineage (task_id, idea_id, origin)
+       VALUES ($1, $2, 'route')
+       ON CONFLICT (task_id) DO UPDATE
+          SET idea_id = EXCLUDED.idea_id, origin = EXCLUDED.origin`,
+      [task.id, idea.id]
+    );
+
+    // e. Close the loop the FKs forced open in (b).
+    await client.query(
+      `UPDATE idea_inbox SET promoted_to_task_id = $2 WHERE id = $1`,
+      [idea.id, task.id]
+    );
+
+    await client.query('COMMIT');
+    return {
+      ...ungradedProjection(),
+      ...idea,
+      promoted_to_task_id: task.id,
+      routing: {
+        routed: true,
+        reason: landing.reason,
+        status: authorized.status,
+        requires_rank: authorized.requiresRank,
+        goal_id: goal.id,
+        version_id: goal.version_id,
+        task_id: task.id,
+      },
+      routed_task: task,
+    };
+  } catch (err) {
+    await client.query('ROLLBACK').catch(() => {});
+    throw err;
+  } finally {
+    client.release();
+  }
 }
 
 // -------------------------------------------------------------------------
@@ -418,6 +680,66 @@ async function sourceIdeaForTask(taskId) {
   return rows[0] || null;
 }
 
+// listRoutedAwaitingNod — the NOD QUEUE (task 1003066, BV1.R05).
+//
+// A routed filing that soft-landed is a task sitting at 'backlog' in a real goal,
+// one Metic+ promote from claimable. Owner interview Q3 settled where that queue
+// lives: the EXISTING "Needs your attention" card and the EXISTING
+// POST /tasks/:id/promote — no new surface, no new permission. This is the read
+// that card was missing, and without it the soft landing is a silent drop: the
+// filing looks accepted, nothing tells anyone it needs a nod, and it sits at
+// backlog forever. Criterion C2's "one Metic+ promote away" is only true if
+// somebody can SEE it.
+//
+// Scoped by the lineage row (origin='route'), not by status alone — a task can be
+// at backlog for a dozen unrelated reasons, and this queue is specifically "a
+// person reported this and the system is waiting on a human". It reads the FILER
+// too (captured_by), because Q3's copy calls the pending state "awaiting a nod"
+// and shows kind + who filed it.
+//
+// Deliberately NOT filtered by goal membership or by the viewer: any Metic+ may
+// give the nod (Q3 rejected goal-member-first review as surface cost), so every
+// Metic+ sees one queue. The route is what gates rank; this is a plain read.
+async function listRoutedAwaitingNod({ limit = 20 } = {}, deps = {}) {
+  const activePool = (deps.pool && process.env.NODE_ENV === 'test') ? deps.pool : pool;
+  const { rows } = await activePool.query(
+    `SELECT t.id AS task_id, t.title, t.kind, t.status, t.goal_id, t.version_id,
+            t.requires_rank, t.created_at,
+            l.idea_id, i.captured_by, b.github_login AS filed_by_login,
+            g.title AS goal_title
+       FROM ideas_task_lineage l
+       JOIN tasks t      ON t.id = l.task_id
+       JOIN idea_inbox i ON i.id = l.idea_id
+       LEFT JOIN builders b ON b.id = i.captured_by
+       LEFT JOIN goals g    ON g.id = t.goal_id
+      WHERE l.origin = 'route'
+        AND t.status = 'backlog'
+      ORDER BY t.created_at ASC
+      LIMIT $1`,
+    // The origin filter rides idx_ideas_task_lineage_route (ideas_004): a PARTIAL
+    // index on origin='route' keyed by task_id, so this walks the routed rows and
+    // probes tasks from the same structure. Without it this was a full scan of a
+    // monotonically-growing ledger on EVERY Home load for every Metic+ builder.
+    [limit]
+  );
+  return rows;
+}
+
+// The count behind the card's pill — same predicate as the list, so the number a
+// viewer is shown can never disagree with the rows they can see (the
+// countOpenIdeas precedent two functions up).
+async function countRoutedAwaitingNod(deps = {}) {
+  const activePool = (deps.pool && process.env.NODE_ENV === 'test') ? deps.pool : pool;
+  const { rows } = await activePool.query(
+    `SELECT COUNT(*)::int AS n
+       FROM ideas_task_lineage l
+       JOIN tasks t ON t.id = l.task_id
+      WHERE l.origin = 'route' AND t.status = 'backlog'`
+    // Same predicate ⇒ same index (ideas_004) as the list above.
+  );
+  return rows[0] ? rows[0].n : 0;
+}
+
 // -------------------------------------------------------------------------
 // Grade writes (task 1002916 / BV1.R140)
 //
@@ -741,6 +1063,9 @@ module.exports = {
   linkIdeaTask,
   countShippedTasksForIdea,
   sourceIdeaForTask,
+  // the nod queue (task 1003066, BV1.R05)
+  listRoutedAwaitingNod,
+  countRoutedAwaitingNod,
   // criterion-proposal ratification (V3.R31 / #252)
   ratifyCriterionProposal,
   parseProposalBody,

package/modules/ideas/migrations/ideas_004_lineage_route_index.sql

@@ -0,0 +1,37 @@
+-- ideas_004_lineage_route_index.sql — index the ROUTE lineage lookup
+-- (task 1003066, BV1.R05, goal 1000071 "Idea routing").
+--
+-- WHY. R05 added the nod queue: GET /inbox/awaiting-nod lists routed filings that
+-- soft-landed, filtering `ideas_task_lineage.origin = 'route'` and joining tasks
+-- for status='backlog'. ideas_002 indexes only task_id (the PK) and idea_id —
+-- nothing on `origin` — so that filter was a full scan of a table that grows
+-- monotonically with every promoted or routed idea, forever. And it is not a rare
+-- query: the hall's "Needs your attention" card issues it on EVERY Home page load
+-- for EVERY Metic+ builder, so the scan cost arrives per page view, not per triage
+-- session. (Raised by the grading panel's efficiency worker on the R05 diff.)
+--
+-- WHY PARTIAL, AND WHY KEYED ON task_id. 'route' is one of three origins and will
+-- stay the minority for as long as triage-promotion exists, so `WHERE origin =
+-- 'route'` keeps the index proportional to the routed rows rather than the whole
+-- table. Keying it on task_id means the index serves the JOIN to tasks directly
+-- from the same structure that satisfies the filter — the planner can walk the
+-- routed rows and probe tasks without touching the heap for a discarded origin.
+--
+-- WHY NOT CONCURRENTLY. Same reasoning core_222 recorded for its own index:
+-- CREATE INDEX CONCURRENTLY cannot run inside a transaction block, and this file
+-- is wrapped BEGIN/COMMIT so it lands atomically. The lock is acceptable HERE
+-- specifically because ideas_task_lineage is a low-volume human-filing ledger —
+-- one row per promoted/routed idea, arriving at human pace — so the build is
+-- milliseconds against a small table and no write path of consequence blocks.
+-- This does NOT generalise to a write-hot table.
+--
+-- Module migrations are ADDITIVE and NAMESPACED: every object here is
+-- ideas_-prefixed, no down-migration, idempotent (safe to re-run).
+
+BEGIN;
+
+CREATE INDEX IF NOT EXISTS idx_ideas_task_lineage_route
+  ON ideas_task_lineage (task_id)
+  WHERE origin = 'route';
+
+COMMIT;

package/modules/ideas/routes/inbox.js

@@ -46,6 +46,11 @@ module.exports = function buildInboxRouter() {
       kind: { type: 'string', maxLength: 64 },
       suggested_version: { type: 'string', maxLength: 64 },
       suggested_priority: { type: 'integer', min: 0, max: 100 },
+      // task 1003065 (BV1.R01, goal 1000071) — CAPTURE-TIME ROUTING. Naming a
+      // goal is what turns a filing into a task in that goal, in this one
+      // request. Optional by design: omit it and this endpoint behaves exactly
+      // as it did before routing existed.
+      goal_id: { type: 'integer', min: 1 },
       // Full Idea capture (R143) — ALL OPTIONAL: omitting every one of these is
       // exactly the pre-grade quick capture (tests/idea_quick_guard.mjs pins
       // that title stays the only required field).
@@ -102,6 +107,14 @@ module.exports = function buildInboxRouter() {
         suggestedVersion: body.suggested_version ?? null,
         suggestedPriority: body.suggested_priority ?? null,
         capturedBy: req.builder.id,
+        // task 1003065 (BV1.R01): the routing inputs. The rank comes from the
+        // AUTHENTICATED builder — never from the body — so a filer cannot claim
+        // a tier they do not hold to hard-land a bug. `grade` is read by the
+        // matrix only (a Full Idea never auto-routes); the grade ROW is still
+        // written below, unchanged.
+        goalId: body.goal_id ?? null,
+        filerRank: req.builder?.rank ?? null,
+        grade,
       });
       let grade_warning;
       if (grade === 'full') {
@@ -190,13 +203,42 @@ module.exports = function buildInboxRouter() {
         }
       }
       const open_count = await inbox.countOpenIdeas({ viewerRank: req.builder?.rank ?? null });
-      res.status(201).json({ idea, open_count, kind_auto: !body.kind, ...(grade_warning ? { grade_warning } : {}) });
+      // task 1003065 (BV1.R01): a routed capture returns the TASK it became, at
+      // the top level, so a client does not have to dig it out of the idea row to
+      // link to it. `idea.routing` carries the verdict either way — including the
+      // reason a named goal did NOT route, which is what makes a declined route
+      // debuggable instead of mysterious.
+      const routed_task = idea && idea.routed_task ? idea.routed_task : undefined;
+      if (idea) delete idea.routed_task;
+      res.status(201).json({
+        idea, open_count, kind_auto: !body.kind,
+        ...(routed_task ? { routed_task } : {}),
+        ...(grade_warning ? { grade_warning } : {}),
+      });
     } catch (err) {
       if (err && err.code) {
         const status =
           err.code === 'TITLE_REQUIRED' ? 400 :
           err.code === 'BAD_KIND' ? 400 :
           err.code === 'BAD_PRIORITY' ? 400 :
+          // task 1003065 (BV1.R01) — the routing refusals. A named goal that is
+          // not a live home is the FILER'S mistake to fix (pick another goal, or
+          // omit it and file to the inbox), so these are 4xx with the offending
+          // id echoed: 404 for "no such goal", 409 for "that goal/version is
+          // closed" (a conflict with live state, not a malformed request).
+          err.code === 'GOAL_NOT_FOUND' ? 404 :
+          err.code === 'GOAL_NOT_OPEN' ? 409 :
+          err.code === 'VERSION_NOT_BUILDING' ? 409 :
+          // task 1003066 (BV1.R05): the landing gate refused. Either the goal's
+          // scope reaches protected territory and the filer is below Metic
+          // (gate 'protected_scope'), or they DECLARED touches the wall rejected
+          // (gate 'out_of_scope' / 'protected_path'). 403 and not 400 — the
+          // request is well-formed, the FILER lacks the authority — matching what
+          // POST /goals/:id/tasks returns for the same wall, so one refusal has
+          // one status. `gate` names which rule bit, and the reason tells the
+          // filer the way through: file it without a goal.
+          err.code === 'ROUTE_NOT_AUTHORIZED' ? 403 :
+          err.code === 'LIFECYCLE_UNAVAILABLE' ? 503 :
           500;
         return res.fail(err.code, status, { ...err });
       }
@@ -235,6 +277,41 @@ module.exports = function buildInboxRouter() {
     }
   });
 
+  // GET /inbox/awaiting-nod — the NOD QUEUE (task 1003066, BV1.R05).
+  //
+  // REGISTERED BEFORE /inbox/:id ON PURPOSE. Express matches in registration
+  // order, so a literal segment declared after the wildcard is unreachable —
+  // this would arrive as /inbox/:id with id='awaiting-nod' and 400 on parseId.
+  //
+  // rank: metic+ via the EXISTING idea.triage permission, deliberately reused
+  // rather than minting a new one. Owner interview Q3: "any Metic+ gives the nod,
+  // in the existing Needs-your-attention slice. No new surface, no new
+  // permission." The act this queue leads to is POST /tasks/:id/promote, itself
+  // gated task.promote (Metic+), so a reader who can see this queue can act on it
+  // — the two gates agree by construction instead of by coincidence.
+  //
+  // Placed on /inbox rather than /tasks because the row is defined by its LINEAGE
+  // (origin='route'), and ideas_task_lineage is an ideas-owned table — the
+  // lifecycle module must not query it, and this module must not query it from
+  // there. "A task at backlog that a person reported" is an ideas question.
+  router.get('/inbox/awaiting-nod', api.requireBuilder, api.requirePermission('idea.triage'), async (req, res) => {
+    try {
+      const limitRaw = Number(req.query.limit);
+      const limit = Number.isInteger(limitRaw) && limitRaw > 0 && limitRaw <= 100 ? limitRaw : 20;
+      const [awaiting, count] = await Promise.all([
+        inbox.listRoutedAwaitingNod({ limit }),
+        inbox.countRoutedAwaitingNod(),
+      ]);
+      res.json({ awaiting, count });
+    } catch (err) {
+      // Through the published logger seam, not a raw console call: a module logs
+      // via the doorway, and the console_call_count ratchet holds at its floor
+      // (the task 1003148 precedent).
+      api.logger('ideas').error('GET /inbox/awaiting-nod', err && err.message);
+      res.fail('awaiting_nod_failed', { status: 500, message: 'internal error' });
+    }
+  });
+
   // rank: any-builder — single idea read for the "#NNN" deep-link resolver
   // (#1047). Mirrors GET /blockers/:id. The hall resolves /#/idea/N by id, but
   // the /inbox LIST returns only the open-first-50, so a closed/older idea ref