@nathapp/nax 0.80.1 → 0.81.0-canary.2

package/flows/nax-finish/review-prompts.ts

@@ -1,468 +0,0 @@
-import type { Finding } from "./types";
-
-export const SPEC_REVIEW_DIMENSIONS = `# Spec-relative review dimensions
-
-Reference for the post-impl-review **spec-relative** pass: Compliance, Drift,
-Integration, and Convention Compliance. Apply every dimension below against the
-spec, the filtered diff, the collaborator code you read, and the loaded project
-rules.
-
-## Map external touchpoints first (read the unchanged collaborators)
-
-**Do this before judging anything.** Most real defects in a focused diff live on
-the boundary between the changed code and the *unchanged* code it calls into —
-and that unchanged code is, by definition, not in the diff. A diff-only read
-cannot see them.
-
-From the filtered diff, build a list of **external touchpoints** — every symbol
-the changed code *uses* but does not *define* in the diff:
-
-- **Callees:** functions/methods the new lines call whose body lives in an
-  unchanged file (e.g. \`strategy_instance.get_references(...)\`,
-  \`provider.cache.get_ohlcv(...)\`).
-- **Polymorphic / interface calls:** any call dispatched through a base class,
-  protocol, or registry. The diff sees one signature; the real behaviour is in
-  *every concrete implementation*. Enumerate them.
-- **New or changed arguments to existing APIs:** a value the diff now passes that
-  the callee didn't receive before — especially empty/sentinel/\`None\`/\`{}\`/\`[]\`
-  values, or a newly-shaped object. Verify the callee tolerates it.
-- **Consumers of changed outputs:** unchanged code that reads a field, sentinel,
-  or return value whose meaning the diff altered.
-- **Collaborators named in the spec:** if the spec asserts a cross-cutting goal
-  ("every built-in strategy works", "all callers", "each adapter"), that goal is
-  a claim *about unchanged code*. You must open those files to verify it — the
-  diff alone can never prove it.
-
-For each touchpoint, **read the actual definition(s)** with Read/Grep and check
-the changed code's assumption holds for *all* of them, not just the convenient
-case. Use Grep to find every implementation of an overridden method before
-concluding it's safe.
-
-Examples of assumptions that only break in unchanged code:
-- The diff calls \`iface.method(emptyValue)\`; one concrete implementation
-  immediately indexes a required key → runtime \`KeyError\`/\`NullPointerException\`
-  for that case.
-- The diff sets a sentinel to \`{}\` instead of \`None\`; a downstream guard checks
-  \`is None\`, so \`{}\` slips through and produces a misleading error or silent NaN.
-- The spec says "works for every strategy"; the diff only added tests for
-  static/test-double strategies, leaving the dynamic real ones unverified.
-
-Treat an untested cross-cutting claim as **unverified, not satisfied** — surface
-it as a finding rather than assuming coverage.
-
-## Compliance — per AC/story/requirement
-
-For each numbered or named AC, story, or requirement in the spec, determine:
-- **Covered** — the diff clearly addresses it
-- **Partial** — the diff touches it but leaves something incomplete
-- **Missing** — nothing in the diff implements it
-
-**Coverage ≠ correctness:** when an AC's coverage is a test, do not stop at "a
-test exists." Open the test body and verify it (a) restores any global /
-\`os.environ\` / filesystem / singleton state it mutates (teardown or fixture),
-(b) is deterministic and order-independent, and (c) asserts the AC's actual
-behaviour rather than a tautology. A test that passes only by accident of
-ordering, or that asserts nothing meaningful, is **Partial**, not Covered.
-
-**If the spec has no numbered or named ACs** (it's written as prose): derive
-implicit requirements from the prose — treat each described behaviour, endpoint,
-or constraint as a requirement. Note in the findings header: \`(Spec has no
-structured ACs — requirements inferred from prose)\`.
-
-**Renames and deletions:** treat them as intentional changes when evaluating
-compliance. A diff showing \`rename from A to B\` or a deleted file counts as
-coverage for an AC that required moving or removing that module.
-
-## Drift — holistic across the diff
-
-Check whether the implementation matches the spec's described intent:
-- API shape: do endpoints, request fields, response fields, and status codes
-  match?
-- Approach: is the architectural pattern (module structure, design pattern, data
-  flow) what the spec called for?
-- Constraints: are hard requirements respected (e.g. "must use HMAC-SHA256",
-  "must be idempotent", "must validate at startup")?
-- Naming: do key identifiers (routes, types, env vars, functions) match the
-  spec's terminology?
-
-## Integration — does the changed code actually work against the unchanged collaborators?
-
-For each external touchpoint mapped above, check whether the changed code's
-assumptions hold for *every* real implementation/consumer:
-- Will any concrete callee raise (KeyError, NPE, ValueError, panic) for an input
-  the diff now passes — especially empty/sentinel/\`None\`/\`[]\`/\`{}\` values?
-- Does any sentinel or output the diff changed reach a downstream guard that
-  interprets it the wrong way (\`{}\` slipping past an \`is None\` check; \`[]\`
-  treated as "provided")?
-- Does the spec's cross-cutting claim ("every X works") actually hold for the
-  real, non-test-double implementations — and is each one exercised by a test?
-  An untested real path is a finding, not a pass.
-- Are there edge inputs the new tool/endpoint schema now permits (e.g. an
-  explicitly empty array) that route into a broken branch?
-
-## Convention Compliance — does the diff obey the project's own rules?
-
-**Load the rules first.** Find the repo's own rule files and read every one that
-exists (they may all be absent — then skip this dimension entirely and note
-\`(No project rule files found — Convention Compliance skipped)\` in your findings):
-
-\`\`\`bash
-ls CLAUDE.md AGENTS.md 2>/dev/null
-find .nax/rules .claude/rules -name "*.md" 2>/dev/null
-\`\`\`
-
-\`.nax/rules/\` takes priority over \`.claude/rules/\` when they conflict (nax-native
-is canonical). Honour each file's \`paths:\` / \`appliesTo:\` frontmatter if present —
-a rule scoped to \`src/agents/**\` does not apply to a diff under \`apps/web/\`.
-Extract the concrete, checkable directives (forbidden APIs, required patterns,
-naming, logging fields, file-size limits) and hold them for the checks below.
-
-For each concrete directive extracted from the loaded rule files, check whether
-the changed lines violate it. Only flag rules that actually apply to the changed
-files (respect \`paths:\` / \`appliesTo:\` scoping). Examples of the *kind* of
-directive to check — the real list comes from the loaded files, not this list:
-- Forbidden APIs / patterns (e.g. a banned import, \`console.log\` in source, a
-  Node API in a Bun-native repo, hardcoded patterns the project routes through a
-  resolver).
-- Required structure (barrel imports vs internal paths, file-size limits,
-  mandated error/base classes, dependency-injection patterns).
-- Required fields / format (e.g. a mandated structured-log field,
-  conventional-commit style, naming conventions for routes/types/env vars).
-
-Cite the specific rule file and directive in the finding
-(\`forbidden-patterns.md: no console.log in src/\`). A violation of an explicit,
-in-scope project rule is a real finding; a generic style opinion **not** backed
-by a loaded rule is not — do not invent rules. If no rule files were found, skip
-this dimension entirely.
-
-## Confidence threshold (spec-relative)
-
-**Report only findings you are ≥80% confident are real**, not pre-existing ones
-the diff didn't introduce. A false "AC missing" or a phantom integration crash
-is expensive and erodes trust in the whole report. A missing AC, a runtime crash
-you traced through the collaborator, and an in-scope project-rule violation clear
-this bar easily; a "this might be slow" hunch you haven't reasoned through does
-not — drop it.
-`;
-
-export const QUALITY_REVIEW_DIMENSIONS = `# Code quality & test integrity dimension
-
-Reference for the post-impl-review **code-quality** pass: spec-independent
-defects and design/maintainability concerns in the changed lines. These findings
-are real regardless of what the spec says. Scan the diff — production **and**
-test code — and judge each changed function on its own merits.
-
-## Forcing function — enumerate before you conclude
-
-Before reporting, walk **every function/method the diff adds or changes** and
-write yourself a one-line verdict for each: *earns its place* or *concern: …*.
-This enumeration is a thinking tool — it does not go in the final report, only
-the resulting findings do. Skipping it is how real maintainability issues get
-missed: an agent that pattern-matches a few obvious smells and stops will always
-under-report. Look at each changed function deliberately.
-
-## What to look for
-
-Report only concrete, objective issues, not style preferences:
-
-- **Test isolation:** mutating \`os.environ\` / globals / singletons / filesystem
-  without teardown; cross-test ordering dependence; shared mutable fixtures. A
-  test that only passes because another test happens to clean up after it is a
-  defect even when the suite is currently green.
-- **Dead / redundant code:** assignments with no effect, unreachable branches,
-  set-up the constructor already performed, unused locals introduced by the diff;
-  logic duplicated from an existing helper the diff could have reused.
-- **Resource leaks:** opened files / sockets / handles / subprocesses not closed;
-  timers / listeners not cleared.
-- **Error handling:** swallowed exceptions, bare catches that hide failures,
-  missing validation on a newly-introduced input path.
-- **Concurrency:** shared state mutated without synchronisation; \`await\` inside a
-  loop that should be batched; a race between a check and the action it guards.
-- **Performance:** N+1 queries or network calls in a loop; blocking I/O on a hot
-  path; an obviously quadratic scan over a large collection the diff introduces.
-- **Accessibility (UI diffs only):** interactive elements without an accessible
-  name/label, missing \`alt\`, non-keyboard-reachable controls, form inputs with
-  no associated label.
-- **Security (only when the diff touches it):** hardcoded secrets, unvalidated
-  user input reaching a sink, injection vectors.
-- **Type safety:** unsafe casts, \`any\`/\`unknown\` escapes, weakened or widened
-  types the diff introduces, or a narrowing the diff drops — anywhere the change
-  trades a compile-time guarantee for a runtime risk.
-- **Design & maintainability (open-ended — not a closed checklist):** a changed
-  function that conflates multiple responsibilities (poor separation of
-  concerns); an abstraction the diff introduces that is premature (single caller,
-  speculative generality) or leaky (callers must understand its internals to use
-  it safely); logic the diff writes inline that an existing helper already
-  provides (reinvention, not just literal duplication); control flow so nested or
-  convoluted the next reader will misread it; an identifier whose name actively
-  misleads about what it holds or does; a comment or docstring the diff now leaves
-  stale or contradicting the code it sits on, or a changed public API left without
-  the docs a caller needs; an edge case the changed code's *own* logic implies but
-  doesn't handle. These are the qualitative "this code isn't good yet" findings —
-  judge them, don't skip them because they aren't on the defect list above. Anchor
-  each to the changed line and state the concrete cost (what breaks, or who is
-  misled, later).
-
-Every finding here must point at a specific changed line and name a concrete cost
-— a bug, a future break, or a reader who will be misled. Skip pure formatting and
-personal taste that carry no such cost, and skip hypotheticals about code outside
-the diff. But a design or maintainability concern grounded in a changed line and
-its cost **is** in scope even though it's not on the defect checklist above —
-that is exactly the signal this dimension exists to surface.
-
-## Confidence threshold (code quality)
-
-**Report findings you are ≥60% confident are real**, *provided* each is anchored
-to a specific changed line and names a concrete maintenance or correctness cost.
-Design and maintainability problems are inherently probabilistic — a muddy
-abstraction, a misleading name, or a fragile edge case rarely clears 80%, and a
-blanket 80% gate is precisely what makes a review miss the quality issues it
-exists to catch. Let these land as MEDIUM or LOW per the severity table rather
-than dropping them; the implementer can waive them, but they should see them.
-Still exclude pure formatting and personal taste that carry no stated cost. Do
-**not** over-suppress this tier to hit an arbitrary count — a real
-maintainability concern stated with its cost is worth surfacing even at moderate
-confidence.
-`;
-
-export const WORKER_PROTOCOL = `# Worker protocol (shared mechanics)
-
-Self-contained mechanics for a post-impl-review **worker** (SPEC or QUALITY).
-Read this plus your dimension reference (\`spec-review.md\` or \`code-quality.md\`) —
-you do **not** need to read the dispatcher's \`SKILL.md\`. The dispatcher already
-resolved the spec, detected the base branch, and ran the empty-diff/size guards;
-your job is to review the diff and return findings.
-
-## Get the diff
-
-The dispatcher gave you the base branch. Fetch the diff content:
-
-\`\`\`bash
-git diff origin/<branch>...HEAD --name-only   # changed file list
-git diff origin/<branch>...HEAD               # full diff content
-\`\`\`
-
-## Filter noise
-
-Do not treat churn in these as a reviewable change (you may still *read* them as
-context):
-
-- Lockfiles: \`bun.lock\`, \`package-lock.json\`, \`yarn.lock\`, \`pnpm-lock.yaml\`,
-  \`Cargo.lock\`, \`poetry.lock\`, or anything ending in \`.lock\`.
-- Generated output: files in \`dist/\`, \`build/\`, \`.next/\`, \`.turbo/\`,
-  \`__pycache__/\`, or matching \`*.generated.*\`.
-- nax artifacts: anything under a \`.nax/\` directory at **any depth**
-  (\`**/.nax/**\` — root or nested per-package in a monorepo): specs, PRDs,
-  acceptance result JSON, config, and the generated acceptance tests.
-- Binary files: git marks these \`Binary files a/... and b/... differ\` — skip them.
-
-## Read the unchanged collaborators (before judging)
-
-Most real defects in a focused diff live on the boundary between the changed code
-and the *unchanged* code it calls into — which is, by definition, not in the
-diff. Build the list of external touchpoints (every symbol the changed code
-*uses* but does not *define*: callees, polymorphic/interface calls, new arguments
-to existing APIs, consumers of changed outputs, collaborators named in the spec)
-and read each definition with Read/Grep before concluding. Treat an untested
-cross-cutting claim as **unverified, not satisfied**. (The SPEC dimension file
-has the full procedure with worked examples; the QUALITY worker needs the same
-reads to judge an integration-shaped defect.)
-
-## Severity table
-
-| Severity | Meaning |
-|:---------|:--------|
-| CRITICAL | AC entirely missing; implementation directly contradicts a hard spec requirement; the changed code raises/crashes at runtime for a case the spec requires to work; or a security defect the diff introduces (hardcoded secret, injection sink) |
-| HIGH | Significant drift (wrong API shape, missing constraint, wrong architectural approach); an integration defect that breaks a real collaborator the spec depends on; or a violation of a project rule explicitly marked as required/forbidden (a banned API, a hard-blocked pattern) |
-| MEDIUM | Partial coverage — AC present but incomplete; minor drift affecting correctness; an integration gap reachable through a now-permitted input; a test-isolation defect that can cause false positives or flakiness under reordering/parallelism; a resource leak; a swallowed error on a real path; a concurrency/race or performance regression the diff introduces; or an accessibility defect on a new interactive UI element |
-| LOW | Minor naming deviation, style mismatch, dead/redundant/duplicated code, unused locals, a soft convention deviation, or other non-blocking gap |
-
-## Output format — return ONLY this
-
-Return **only your findings**, nothing else: no \`Spec:\`/\`Base:\` header, no
-\`FINDINGS\` divider, no \`VERDICT\` line (the dispatcher adds those). Emit each
-finding as a block:
-
-\`\`\`
-[SEVERITY] <short title>
-  Problem: <what's wrong, with file/line and the concrete cost>
-  Fix: <the concrete change, or "note intentional deviation">
-\`\`\`
-
-If you found nothing in your group, return the literal line \`No findings.\` as
-your entire final message. That message is the only thing that travels back to
-the dispatcher.
-`;
-
-const CLASSIFIER = [
-  "Mark a finding for human judgment — and only such a finding — by adding a",
-  "`Judgment: yes — <why>` line to its block. Use it when the finding is a spec",
-  "conflict, or a design/judgment call with no safe mechanical fix. Everything",
-  "else will be fixed and re-verified automatically, so a finding with a clear,",
-  "low-risk fix must NOT carry the marker.",
-].join("\n");
-
-/**
- * The reply contract.
- *
- * This supersedes the "Output format — return ONLY this" section of
- * `WORKER_PROTOCOL` above, which is kept verbatim so it stays diffable against
- * the skill's `references/worker-protocol.md`. Its `[SEVERITY]` blocks are
- * exactly this contract's `## FINDINGS` section; the two sections before it are
- * what the flow adds, because the flow — unlike the skill's dispatcher — has no
- * human reading the reply and so must be able to check the obligations itself.
- *
- * There is no JSON. A reply constrained to one JSON object has nowhere to put
- * the per-AC and per-function enumerations both dimension references depend on,
- * and an unreadable object used to discard the entire review (#1614).
- */
-function outputContract(phase: "spec" | "quality"): string {
-  const walk =
-    phase === "spec"
-      ? "one line per AC in the spec: `AC-3 Covered|Partial|Missing — <one clause>`"
-      : "one line per function or method the diff adds or changes: `path.ts:name — earns its place|concern: <one clause>`";
-  return `# Reply contract — your reply must be these three sections, in this order
-
-## TOUCHPOINTS
-One line per external touchpoint whose definition you actually opened:
-\`- path/to/file.ts:symbol — why you opened it\`. If the diff genuinely has none,
-the single line \`- none — <justification>\`. The paths are checked against the
-repo: a list whose paths do not exist is treated as an incomplete review, not a
-clean one, and you will be asked again.
-
-## WALK
-${walk}. This is the enumeration your dimension reference requires. One line each,
-no prose. A missing or empty WALK section is an incomplete review.
-
-## FINDINGS
-The \`[SEVERITY] …\` blocks defined in the worker protocol above — or the literal
-line \`No findings.\` if you found none. This section is the only thing that
-becomes a finding; the two above are the evidence that you were in a position to
-write it.`;
-}
-
-/**
- * Build the reviewer prompt.
- *
- * With `since` set this is a **re-review**: the same reviewer already read the
- * whole branch and raised `priorFindings`, a fix was applied and committed, and
- * the only new material is `since..HEAD`. Re-reading the full branch diff every
- * round made reviews 58% of the flow's wall clock, most of it re-reading code an
- * earlier round had already cleared. The narrowed round still has the full repo
- * available — it is told to open whatever the fix touches — it just is not asked
- * to re-derive a verdict on unchanged code.
- *
- * `since` is the parent of the *first* commit that landed after the previous
- * verdict, not of the latest one (see `incrementalSince`) — the acceptance loop
- * can commit between a spec fix and its re-review, and the window has to span
- * both. So `since..HEAD` provably contains every change made since that
- * verdict, however many commits that took, and it is never supplied at all when
- * no commit landed.
- */
-export function buildReviewPrompt(
-  phase: "spec" | "quality",
-  args: {
-    base: string;
-    specPath: string;
-    since?: string | null;
-    priorFindings?: Finding[];
-    gaps?: string[];
-  },
-): string {
-  const dims = phase === "spec" ? SPEC_REVIEW_DIMENSIONS : QUALITY_REVIEW_DIMENSIONS;
-  const gapNotice =
-    args.gaps && args.gaps.length > 0
-      ? [
-          [
-            "IMPORTANT — your previous review was not accepted, because it skipped a required section:",
-            ...args.gaps.map((g) => `- ${g}`),
-            "Do the reading this time and emit all three sections. A verdict without them is not a review.",
-          ].join("\n"),
-        ]
-      : [];
-  if (!args.since) {
-    return [
-      ...gapNotice,
-      `You are the ${phase.toUpperCase()} reviewer for a completed feature.`,
-      `The spec/requirements source is: ${args.specPath}. Read it in full.`,
-      `Fetch and review the diff: \`git diff ${args.base}...HEAD\` (also \`--name-only\` for the file list).`,
-      WORKER_PROTOCOL,
-      dims,
-      CLASSIFIER,
-      outputContract(phase),
-    ].join("\n\n");
-  }
-  return [
-    ...gapNotice,
-    `You are the ${phase.toUpperCase()} reviewer for a completed feature, continuing a review you already started.`,
-    `On your previous pass over \`git diff ${args.base}...HEAD\` you raised the findings below, and they have since been fixed and committed. Everything else in that diff you already judged acceptable — do not re-derive a verdict on it.`,
-    `Your findings from the previous pass:\n${JSON.stringify(args.priorFindings ?? [], null, 2)}`,
-    `The fix is \`git diff ${args.since}..HEAD\` — this is the only code that has changed since your last verdict. Review it, and only it, for two questions:`,
-    [
-      "1. **Resolved?** Does the fix actually resolve each finding above? A finding that was papered over (assertion weakened, test deleted, check disabled) is NOT resolved — re-raise it.",
-      "2. **Broken?** Did the fix introduce a new problem, in the changed lines or in the unchanged code they now call into?",
-      "",
-      `Read whatever files you need — the spec is at ${args.specPath} and the whole repo is available. Scope means *what you judge*, not *what you may read*.`,
-    ].join("\n"),
-    WORKER_PROTOCOL,
-    dims,
-    CLASSIFIER,
-    outputContract(phase),
-  ].join("\n\n");
-}
-
-/**
- * The fix node's contract.
- *
- * For the two review phases it is no longer "apply these". Every finding used to
- * be implemented unconditionally, so a false positive was always built — and on
- * the diff behind #1614 the comparison review raised one finding a human
- * withdrew, because the change it proposed contradicted a test deliberately
- * pinning the current behaviour. `quality_gates` would then have proved the
- * resulting suite green. Reporting more findings without a way to reject one
- * scales the false-positive exposure with the true-positive one, so the two ship
- * together.
- *
- * A rejection must cite the file:line that pins the behaviour: an unevidenced
- * "I disagree" is how a real finding gets waived, and `commit_<phase>` checks
- * that the cited path exists.
- */
-export function fixPrompt(
-  phase: "acceptance" | "spec" | "quality" | "gate",
-  ctx: { outputs: Record<string, unknown> },
-): string {
-  const outs = ctx.outputs as Record<string, { findings?: Finding[]; output?: string }>;
-  if (phase === "gate" || phase === "acceptance") {
-    const detail = phase === "gate" ? (outs.quality_gates?.output ?? "") : (outs.acceptance?.output ?? "");
-    return [
-      `Apply the recommended fixes for the ${phase} phase, directly in the repo.`,
-      "Do not commit, push, or open PRs — nax-finish commits and pushes your edits itself.",
-      `Context:\n${detail}`,
-      "After fixing, re-run the feature's acceptance tests and the relevant checks; only proceed when they pass.",
-      'Return exactly {"route":"proceed"} when done and green.',
-    ].join("\n\n");
-  }
-  const findings = outs[`review_${phase}`]?.findings ?? [];
-  const numbered = findings
-    .map((f, i) => `[${i + 1}] [${f.severity}] ${f.title}\n  Problem: ${f.problem}\n  Fix: ${f.fix}`)
-    .join("\n");
-  return [
-    `Resolve the ${phase} review findings below, directly in the repo.`,
-    "Do not commit, push, or open PRs — nax-finish commits and pushes your edits itself.",
-    numbered,
-    [
-      "A finding may be REJECTED rather than fixed — but only on evidence, not on preference.",
-      "Reject when the change it asks for would contradict an existing test that deliberately",
-      "pins the current behaviour, or a spec statement that requires it. Cite the `file:line`.",
-      "Anything else you fix.",
-    ].join("\n"),
-    [
-      "After fixing, re-run the feature's acceptance tests and the relevant checks; only proceed when they pass.",
-      "Then end your reply with one line per finding, in this exact shape:",
-      "",
-      "## DISPOSITIONS",
-      "[1] fixed",
-      "[2] rejected — evidence: test/unit/foo.test.ts:42",
-    ].join("\n"),
-  ].join("\n\n");
-}

package/flows/nax-finish/steps/acceptance.ts

@@ -1,76 +0,0 @@
-import { DEFAULT_ACCEPTANCE_TIMEOUT_MS, runShell } from "../exec";
-import type { AcceptanceGroup, ShellRunFn } from "../types";
-
-export const _acceptanceDeps: { runShell: ShellRunFn } = { runShell };
-
-/** Single-quote a path for `/bin/sh -c`, so spaces in a repo path can't split the command. */
-function shellQuote(value: string): string {
-  return `'${value.replaceAll("'", `'\\''`)}'`;
-}
-
-/**
- * Build the acceptance command for one group, mirroring nax's own execution:
- * the configured `command` template (any `{{FILE}}` / `{{file}}` / `{{files}}`
- * placeholder replaced by the **absolute** test path) run from the group's
- * package dir. The command is a string, run through `/bin/sh -c`, because
- * configured commands legitimately contain `&&`, quotes and flags.
- */
-export function buildAcceptanceCommand(repoRoot: string, group: AcceptanceGroup): string {
-  const absFile = shellQuote(`${repoRoot}/${group.testPath}`);
-  const template = group.command ?? `${languageRunner(group.language)} {{FILE}}`;
-  return template.replace(/\{\{FILE\}\}|\{\{file\}\}|\{\{files\}\}/g, absFile);
-}
-
-export interface AcceptanceGateOutcome {
-  /** Every group that ran exited 0. Says nothing about groups that could not run. */
-  passed: boolean;
-  ran: number;
-  /**
-   * Package names whose acceptance test the resolver expected at its canonical
-   * path but which is absent on disk — never generated, or generation failed.
-   * The caller must treat a non-empty list as a coverage hole rather than a
-   * pass: skipping these silently is how a feature reached a "ready" PR with
-   * nothing verified.
-   */
-  missing: string[];
-  output: string;
-}
-
-export async function runAcceptanceGate(
-  repoRoot: string,
-  groups: AcceptanceGroup[],
-  opts: { timeoutMs?: number } = {},
-): Promise<AcceptanceGateOutcome> {
-  const chunks: string[] = [];
-  const timeoutMs = opts.timeoutMs ?? DEFAULT_ACCEPTANCE_TIMEOUT_MS;
-  const missing: string[] = [];
-  let ran = 0;
-  for (const g of groups) {
-    const name = g.packageDir || "root";
-    if (!g.exists) {
-      missing.push(name);
-      continue;
-    }
-    const cwd = g.packageDir ? `${repoRoot}/${g.packageDir}` : repoRoot;
-    ran += 1;
-    const res = await _acceptanceDeps.runShell(buildAcceptanceCommand(repoRoot, g), { cwd, timeoutMs });
-    chunks.push(`[${name}] exit=${res.exitCode}\n${res.stdout}\n${res.stderr}`);
-    if (res.exitCode !== 0) return { passed: false, ran, missing, output: chunks.join("\n\n") };
-  }
-  if (missing.length > 0) {
-    chunks.push(`[acceptance] no acceptance test file on disk for: ${missing.join(", ")}`);
-  }
-  if (ran === 0) chunks.push("[acceptance] no acceptance test files present — nothing to run");
-  return { passed: true, ran, missing, output: chunks.join("\n\n") };
-}
-
-function languageRunner(language: string): string {
-  switch (language) {
-    case "python":
-      return "uv run pytest";
-    case "go":
-      return "go test";
-    default:
-      return "bun test";
-  }
-}

package/flows/nax-finish/steps/commit-round.ts

@@ -1,67 +0,0 @@
-/**
- * Assembling the audit round a `commit_<phase>` node records.
- *
- * Split out of `nax-finish.flow.ts` for room — that file sits against the
- * 600-line source cap — but the split earns its keep independently: the round's
- * shape is a data decision with four conditional fields, and it is now unit
- * testable without driving a flow node through a git mock.
- *
- * Pairs with `./review-round`, which records the rounds that produce no commit.
- */
-import type { Finding, FindingDisposition, FinishPhase, FinishRound, FinishRoundOutcome } from "../types";
-
-/** Phases that own a reviewer node; every other phase's round has nobody behind it. */
-const REVIEWED_PHASES: FinishPhase[] = ["spec", "quality"];
-
-/**
- * What produced this round, given the successor the commit routed to.
- *
- * `route` no longer changes the answer, and that is the point: since #1510
- * every committed gate fix re-enters `review_quality`, so no route can skip an
- * owed re-review. The parameter stays because the round is still keyed on the
- * successor conceptually, and a future route that *does* bypass a reviewer
- * would need to be reflected here rather than silently inheriting
- * `no-reviewer`.
- */
-export function commitRoundOutcome(phase: FinishPhase, _route: string): FinishRoundOutcome {
-  if (REVIEWED_PHASES.includes(phase)) return "fixed";
-  return "no-reviewer";
-}
-
-export interface CommitRoundInput {
-  phase: FinishPhase;
-  attempt: number;
-  committed: boolean;
-  /** The successor this commit routed to — see `commitRoundOutcome`. */
-  route: string;
-  findings: Finding[];
-  /** Gate commands that were red this round; omitted for non-gate phases. */
-  failing?: string[];
-  /** Post-commit HEAD, when there was a commit. */
-  shaAfter?: string | null;
-  now: string;
-  /** What the fixer did with each finding it was handed (spec/quality phases). */
-  dispositions?: FindingDisposition[];
-}
-
-/**
- * Build the round record for a commit checkpoint.
- *
- * `sha` and `failing` are omitted rather than set to null/undefined: a reader of
- * the JSONL distinguishes "no commit" from "record lost" by the key's absence,
- * and that only works if absence is never used to mean anything else.
- */
-export function buildCommitRound(i: CommitRoundInput): FinishRound {
-  return {
-    ts: i.now,
-    phase: i.phase,
-    attempt: i.attempt,
-    committed: i.committed,
-    outcome: commitRoundOutcome(i.phase, i.route),
-    findings: i.findings,
-    route: i.route,
-    ...(i.failing ? { failing: i.failing } : {}),
-    ...(i.committed && i.shaAfter ? { sha: i.shaAfter } : {}),
-    ...(i.dispositions && i.dispositions.length > 0 ? { dispositions: i.dispositions } : {}),
-  };
-}