@nanobpm/nano-workforce 0.163.2 → 0.164.0

package/scripts/pages-contract.test.ts

@@ -317,21 +317,24 @@ test("issue #205: overview is the landing page and first nav item", async () =>
     );
   }
 
-  // Three collapsible active-work sections, one per dispatch surface, each with a
+  // Four collapsible active-work sections, one per dispatch surface, each with a
   // live count in its header (showCount) and a persisted collapse toggle (collapsible). Each filters
-  // its Active list on a `{field, in:[...]}` predicate: the PR / feature surfaces on `status`, but the
-  // EPIC surface buckets on the DERIVED `list_bucket` (issue #298) — NOT raw `status` — so a `done`
-  // epic still converging, or landed-but-unpromoted, does not vanish from the in-flight Epics section
-  // the instant `status=done`. Guarding the field here is the regression guard for that defect class.
-  // The epic surface binds the derived `plan_read_model` VIEW (epic #412 — the single source of truth
-  // for the wave/delivery projections it also renders), not the raw `plans` table.
+  // its Active list on a `{field, in:[...]}` predicate. The FEATURE and EPIC surfaces bucket on the
+  // DERIVED `list_bucket` — NOT raw `status` — over their read-model VIEW (features: issue #637 —
+  // fixing a drift where the grid read the vestigial base `feature_runs.status` with an allowlist that
+  // hid every converging feature; epics: issue #298), so a `done`-but-unacknowledged item still
+  // converging does not vanish from its in-flight section the instant `status` reads terminal. Guarding
+  // the field here is the regression guard for that defect class. The feature surface binds the derived
+  // `feature_read_model` VIEW (the single source of truth for the `list_bucket` activeness predicate,
+  // shared byte-for-byte with the Feature tab); the epic surface binds `plan_read_model` (epic #412),
+  // not the raw `plans` table. PRs / delivery graphs still bucket on `status` (see #637 follow-up).
   const expected: Record<string, { field: string; in: string[] }> = {
     pull_requests: {
       field: "status",
       in: ["converging", "waiting_review", "escalated", "waiting_deps", "waiting_merge", "queued", "merging"],
     },
     plan_read_model: { field: "list_bucket", in: ["active"] },
-    feature_runs: { field: "status", in: ["running", "escalated", "awaiting_operator"] },
+    feature_read_model: { field: "list_bucket", in: ["active"] },
     // The 4th dispatch surface (issue #386) — active delivery graphs. Both in-flight statuses
     // (`awaiting-approval` parked at the gate, `running` dispatched) show here. Binds the derived
     // `delivery_graph_read_model` VIEW (S7 / #541 — the single source of truth for the pipeline
@@ -461,3 +464,59 @@ test("issue #521: the Delivery Graphs History tab surfaces dispatch time + the i
     "the Instance cell's processExplorer link must key on `process_key`",
   );
 });
+
+test("issue #637: the Overview 'Active Features' grid buckets on the derived read model, in parity with the Feature tab", async () => {
+  // The bug: Overview's "Active Features" grid read the VESTIGIAL base `feature_runs.status` column
+  // with a hand-maintained allowlist (`running`/`escalated`/`awaiting_operator` — not even a valid
+  // feature-status set: those are delivery-graph statuses cloned from the "Active Delivery Graphs"
+  // grid). A feature only ever surfaced there if it happened to be `escalated`; its whole convergence
+  // life (`converging`/`waiting_review`/`waiting_merge`/…) was invisible on Overview while the SAME
+  // feature showed on the dedicated Feature tab — a state-tear between two surfaces that must agree.
+  //
+  // The fix repoints the grid at the derived `feature_read_model` VIEW filtered on the canonical
+  // `list_bucket IN ('active')` activeness predicate — the single declare-once column (app/
+  // featureReadModel.ts, guarded byte-for-byte by check:derivation-parity) that the Feature tab's
+  // "Feature runs" grid already uses. This test pins that parity so the tear can't silently return.
+  const overview = JSON.parse(readFileSync(`${ROOT}pages/overview.page.json`, "utf8"));
+  const feature = JSON.parse(readFileSync(`${ROOT}pages/feature.page.json`, "utf8"));
+
+  const ovGrid = (overview.nodes ?? []).find(
+    (n: Json) => n.type === "dataGrid" && n.props?.title === "Active Features",
+  );
+  assert(ovGrid, "overview.page.json must have an 'Active Features' grid");
+
+  // It must bind the derived read-model VIEW, never the vestigial base `feature_runs` table.
+  assert(
+    ovGrid.props?.data?.table === "feature_read_model",
+    "the Overview 'Active Features' grid must bind the derived feature_read_model VIEW, not the base feature_runs table",
+  );
+
+  // And it must filter on the canonical `list_bucket IN ('active')` activeness predicate — never a
+  // base-`status` allowlist.
+  const ovFilters: Json[] = ovGrid.props?.data?.filter ?? [];
+  assert(
+    !ovFilters.some((f: Json) => f.field === "status"),
+    "the Overview 'Active Features' grid must NOT re-encode activeness as a base-`status` allowlist",
+  );
+  const ovBucket = ovFilters.find((f: Json) => f.field === "list_bucket");
+  assert(
+    ovBucket && JSON.stringify(ovBucket.in) === JSON.stringify(["active"]),
+    "the Overview 'Active Features' grid must filter `list_bucket IN ['active']`",
+  );
+
+  // Parity: the Feature tab's "Feature runs" grid answers "is this feature active?" identically —
+  // same VIEW, same activeness predicate — so the two surfaces show the same active-feature set.
+  const featGrid = (feature.nodes ?? []).find(
+    (n: Json) => n.type === "dataGrid" && n.props?.title === "Feature runs",
+  );
+  assert(featGrid, "feature.page.json must have a 'Feature runs' grid");
+  assert(
+    featGrid.props?.data?.table === ovGrid.props?.data?.table,
+    "the Overview and Feature-tab feature grids must bind the SAME table (feature_read_model)",
+  );
+  const featBucket = (featGrid.props?.data?.filter ?? []).find((f: Json) => f.field === "list_bucket");
+  assert(
+    featBucket && JSON.stringify(featBucket.in) === JSON.stringify(ovBucket.in),
+    "the Overview and Feature-tab feature grids must apply the IDENTICAL list_bucket activeness predicate",
+  );
+});

package/workers/merge-stall-probe/worker.ts

@@ -0,0 +1,66 @@
+// pr.merge-stall-probe — the mergeable-wait timer fired: the in-process poller never published
+// `merge-ready` within `mergeableWaitTimeout` (it died across a redeploy, errored on this PR, or
+// skipped the verdict), so the instance would otherwise sit wedged at `waiting_merge` forever with
+// no timeout and no escalation (issue #636). This is the bounded-wait backstop: re-derive
+// ground-truth mergeability directly from GitHub — reusing the poller's own classifier
+// (`classifyMergeability` over a fresh `fetchPrState`, protocol-aware via `loadMergeProtocol`) — and
+// emit `mergeState` so the *existing* `gw-mergeable` routes the token to the correct arm:
+//   • ready    → attempt-merge
+//   • conflict → rebase arm
+//   • blocked  → CI-fix arm
+//   • draft / waiting (still computing) → not-landable escalation (gw-mergeable default)
+// The timer only guarantees the remediation machinery is ENTERED when the poller is dead; every
+// downstream arm is the same one the live poller feeds. A bounded `mergeStallRounds` counter
+// (incremented by this task's output mapping, capped by `mergeStallMax`) stops the probe from
+// re-arming forever: once exhausted, `gw-merge-stall` routes to human escalation instead.
+import type { AppJobHandler } from "@nanobpm/urban";
+import { classifyMergeability, fetchPrState } from "../../app/github.ts";
+import { loadMergeProtocol } from "../../app/mergeProtocol.ts";
+import type { WorkerInputs } from "../../nano-generated/worker-io.d.ts";
+
+// Input typed off the model data envelope (`MergeStallProbeIn` in merge-loop.bpmn) — ADR 0040.
+type In = WorkerInputs["pr.merge-stall-probe"];
+
+interface Out extends Record<string, unknown> {
+  // Mirrors the poller's `merge-ready {mergeState}` payload so the existing `gw-mergeable` FEEL
+  // routes it. `waiting` (GitHub still computing / no verdict) is surfaced verbatim; gw-mergeable
+  // has no `waiting` arm, so it falls to the not-landable default and escalates — the correct
+  // backstop when the poller is dead and 30 minutes on GitHub still cannot settle the PR.
+  mergeState: string;
+  failingChecks: number;
+  failingChecksList: string;
+}
+
+const handler: AppJobHandler<In, Out> = async (job, app) => {
+  const { repo, prNumber } = job.variables;
+  const token = process.env.GITHUB_TOKEN ?? "";
+
+  // Re-derive ground truth exactly as the poller does (service.ts block 2). Load the repo's merge
+  // protocol so the protocol-aware backstop (#392) gates a red DECLARED-required check even when
+  // GitHub reports UNSTABLE. Any transport hiccup is treated as "still waiting" — never a spurious
+  // ready/conflict verdict — so a bad read is surfaced as `waiting`, which `gw-mergeable` routes to
+  // its not-landable default (human escalation), erring toward a human rather than misrouting the
+  // token to a wrong remediation arm.
+  const st = await fetchPrState(repo, prNumber, token).catch(() => null);
+  if (st === null) {
+    return { mergeState: "waiting", failingChecks: 0, failingChecksList: "" };
+  }
+  const protocol = await loadMergeProtocol(repo, token).catch(() => null);
+  const mergeState = classifyMergeability(st, protocol ?? undefined);
+
+  app.log.info("merge-stall-probe: poller stalled — re-derived mergeability", {
+    prKey: job.variables.prKey,
+    mergeState,
+    mergeStateStatus: st.mergeStateStatus,
+  });
+
+  return {
+    mergeState,
+    // Carried for the CI-fix arm (mergeState "blocked" = a failed required check), mirroring the
+    // poller's `merge-ready` payload so fix-ci knows which gates to green.
+    failingChecks: st.failingChecks,
+    failingChecksList: st.failingCheckNames.join("\n"),
+  };
+};
+
+export default handler;