orchestrator-workflow 0.32.0 → 0.34.0

package/CHANGELOG.md

@@ -7,6 +7,64 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.34.0] - 2026-09-13
+
+- Reviewer findings now carry `introduced_by_delta: yes | no | unknown`.
+  A `no` attribution requires a named base build and replay in `reproduction`;
+  it remains in the ordinary finding gate and Findings table, while only `yes`
+  and `unknown` participate in bounded halt and escalation rules. The legacy
+  five-cell table and placeholder row remain byte-compatible with the
+  completeness reader; concrete rows record attribution parenthetically in
+  their Description field.
+
+## [0.33.0] - 2026-09-12
+
+### Changed
+
+- Implementer reports now paste non-empty commit lists from `git log --reverse
+  --format=%H <base>..HEAD`, and foreground verification/probe plans and
+  repeat tallies return in the same turn as the last check; a background
+  monitor does not substitute. Anchored by pandora batch48 evidence.
+
+- The implementer output contract now enumerates mutation-probe `result` as
+  `killed | survived | not_applicable` in both the installed prompt and the
+  SKILL.md reference. The docs-consistency guard separately pins each copy's
+  complete field block, including that enum, and now recognizes versioned
+  parenthesized headings in `see <name> below` forward pointers.
+
+- The implementer and reviewer prompts (`assets/agents/implementer.md`,
+  `assets/agents/reviewer.md`, mirrored in SKILL.md) now say: cite a
+  coverage gate's threshold and pass/fail counts, not a run-specific
+  coverage percentage; cite a percentage only together with the exact
+  commit and the run count, since branch coverage varies between runs of
+  the same commit. Anchored by pandora run
+  `.ai/runs/2026-09-11-memory-sync-wipe`.
+- The implementer `mutation_probes` output field (`assets/agents/
+  implementer.md`, mirrored in SKILL.md, and the `04-implementation-
+  summary.md` template's Mutation Probes table) now carries the mutant's
+  definition, not only its label: `file`, `anchor` (a line number or a
+  unique string), `before`, and `after` alongside the existing
+  `verified_applied_via`, `result`, `restored_verified`, and `replayed`
+  fields, so a later round can mechanically reapply the same edit instead
+  of only reading a prose description. Added `expectation: met | violated
+  | not_applicable` beside `result`, reporting whether the probe's
+  `result` matched its `--expect`, scoped to a measured `killed` or
+  `survived` `result` (a routine negative-control probe now reports
+  `result: survived, expectation: met`, which is not a regression) and
+  `not_applicable` otherwise (for example when the mutant could not be
+  applied and no `result` was measured). Added an eleventh sub-field,
+  `reason`: free text, required when `result` is `not_applicable`, empty
+  otherwise, carrying one of two canonical strings that distinguish a
+  non-regression from a regression: `no definition recorded` (a
+  prior-round probe recorded with only an id, no definition to reapply)
+  and `target text no longer present` (a replayed probe whose mutant can
+  no longer be applied). The fix-round replay rule now names a
+  probe to replay by its definition, not merely by its id, and treats a
+  replayed probe whose `expectation` is now `violated` (or which can no
+  longer be applied) as the regression signal, not `result` alone.
+  Anchored by pandora run `.ai/runs/2026-09-11-memory-sync-wipe` and the
+  agent-primitives `probe` result/expectation split (0.3.0).
+
 ## [0.32.0] - 2026-09-11
 
 ### Added

package/assets/agents/implementer.md

@@ -31,28 +31,56 @@ Rules:
 - Touch only the files relevant to the assigned task. Respect the
   allowed_changes and forbidden_changes lists in your task contract.
 - Add or update tests where appropriate. Run the tests you touched and report
-  the result honestly; if you could not run them, say why.
+  the result honestly; if you could not run them, say why. Cite a coverage
+  gate's threshold and pass/fail counts, not a run-specific coverage
+  percentage; cite a percentage only together with the exact commit and the
+  run count, since branch coverage can vary between runs of the same commit.
 - When the task assignment names mutation probes to run, run each one and
-  report it in the `mutation_probes` field of your output (mutant,
-  verified_applied_via, result, restored_verified); an output missing that
-  field when probes were named is treated as a misfire, not evidence. When
-  the assignment names no mutation probes, return `mutation_probes: []`
-  rather than omitting the field. Each item also carries `replayed`:
-  `false` for a probe newly introduced this round.
+  report it in the `mutation_probes` field of your output (mutant, file,
+  anchor, before, after, verified_applied_via, result, expectation,
+  reason, restored_verified); an output missing that field when probes
+  were named is treated as a misfire, not evidence. `file` and `anchor`
+  (a line number or a unique surrounding string) locate the mutant;
+  `before` and `after` are the exact text swapped there, so a later round
+  can reapply the same edit without guessing instead of only a prose
+  description. `expectation` records whether `result` matched what the
+  probe was expected to do (`met`) or not (`violated`), independent of
+  `result` itself, only alongside a measured `killed` or `survived`
+  `result`; it is `not_applicable` otherwise (for example when the mutant
+  could not be applied and no `result` was measured). `reason` is free
+  text, required when `result` is `not_applicable`, empty otherwise,
+  carrying one of two canonical strings that distinguish a non-regression
+  from a regression: `no definition recorded` (a prior-round probe
+  recorded with only an id, no definition to reapply) and `target text no
+  longer present` (a replayed probe whose mutant can no longer be
+  applied). When the assignment names no mutation probes, return
+  `mutation_probes: []` rather than omitting the field.
+  Each item also carries `replayed`: `false` for a probe newly
+  introduced this round.
 - On any round after the task's first, the assignment also names every
   mutation probe named in an earlier round of this task (on the task's
   first round there are none), drawn from the run's
-  `04-implementation-summary.md`. Replay each one, not only this round's
-  new probes, before returning your report, and report each replayed
-  probe in `mutation_probes` with the four evidence fields plus
-  `replayed: true`. A replayed probe whose mutant now survives or can no
-  longer be applied is a regression signal: report it as such (`result`
-  `survived` or `not_applicable` with the reason) and resolve it before
-  the next reviewer spawn.
+  `04-implementation-summary.md`, naming each by its mutant definition
+  (file, anchor, before, after), not merely by its id; a probe recorded
+  with only an id and no definition to reapply cannot be replayed and is
+  `not_applicable` (reason: `no definition recorded`), not a regression.
+  Replay each one, not only this round's new probes, before returning your
+  report, and report each replayed probe in `mutation_probes` with the
+  evidence fields plus `replayed: true`. A replayed probe whose
+  `expectation` is now `violated`, or which can no longer be applied
+  (reason: `target text no longer present`), is the regression signal;
+  `result` alone is not: report it as such (`result` `survived` or
+  `not_applicable` with the reason) and resolve it before the next
+  reviewer spawn.
 - When a verify runner is available, run it for the checks the acceptance
   criteria name and report its summary under `tests.executed`; when a
   mutation-probe runner is available, run the named probes through it and
-  copy its fields into `mutation_probes`.
+  copy its fields into `mutation_probes`; when the runner reports a
+  probe's mutant record (`file`, `anchor`, `before`, `after`) separately
+  from its result fields (`verified_applied_via`, `result`, `expectation`,
+  `reason`, `restored_verified`), take the definition fields from that
+  mutant record so the copied report still carries all eleven
+  `mutation_probes` sub-fields.
 - Run every long test, build, or mutation-probe command in the foreground
   and wait for it to finish before returning. When one foreground call
   cannot hold it to completion, poll the backgrounded run to completion
@@ -80,6 +108,11 @@ Rules:
   when the task assignment asked for a commit is treated as a misfire, not
   evidence. When the task produced no commit, return `commits: []` rather
   than omitting the field.
+- Populate a non-empty `commits` field by pasting `git log --reverse
+  --format=%H <base>..HEAD`; never type or hand-complete commit shas.
+- Verification plans, probe plans, and repeat tallies run in the foreground,
+  and the implementer reports their returns in the same turn as the last
+  check. A background monitor is no substitute for those returns.
 - Only write a verification claim (for example "Verified by ...") in a code
   comment, commit message, or your report for a check you actually ran and
   measured yourself; never claim a run you did not execute.
@@ -131,8 +164,14 @@ tests:
   not_executed_reason: ""
 mutation_probes:
   - mutant: ""
+    file: ""
+    anchor: ""
+    before: ""
+    after: ""
     verified_applied_via: ""
-    result: ""
+    result: killed | survived | not_applicable
+    expectation: met | violated | not_applicable
+    reason: ""
     restored_verified: ""
     replayed: false | true
 risks:

package/assets/agents/reviewer.md

@@ -73,7 +73,7 @@ Check, at minimum:
   review round, classify each finding as `new` or `repeated` against the
   earlier rounds you were told about; on a first round every finding is
   `new` by definition. The orchestrator uses this to detect the
-  review-round escalation budget's trigger.
+  review-round escalation budget's trigger. Delta attribution: classify every finding as `introduced_by_delta: yes | no | unknown`; set `no` only after naming the base build and replaying the same reproduction in `reproduction`, and record it in `05-review-findings.md` through the ordinary gate rather than bounded-round halt/escalation guidance (yes/unknown only).
 - GitHub Actions shell replay: for any diff that adds or changes a GitHub
   Actions `run:` step, replay it yourself under the shell the step actually
   runs: `bash --noprofile --norc -eo pipefail` when `shell: bash` is set on
@@ -135,13 +135,16 @@ Rules:
   shell replay above is a second, explicitly non-probabilistic trigger for
   the same field: report it in `reproduction` too, with `sample_size:
   not_applicable` when the replay itself has no meaningful sample size.
+- When citing a coverage gate, cite the threshold and pass/fail counts, not
+  a run-specific coverage percentage; cite a percentage only together with
+  the exact commit and the run count, since branch coverage can vary
+  between runs of the same commit.
 - When a mutation-probe runner is available in the session, run probes
   through it instead of editing files by hand, and carry its result fields
   into your findings and `reproduction`; when a verify runner is available,
   read its summary before opening full logs.
 
 Return exactly this structure as your final output, nothing else:
-
 ```yaml
 status: reviewed
 role: reviewer
@@ -154,6 +157,7 @@ findings:
     description: ""
     suggested_fix: ""
     recurrence: new | repeated
+    introduced_by_delta: yes | no | unknown
 acceptance_recommendation: accept | accept_with_notes | fix_required | reject
 missing_tests:
   - ""

package/assets/agents-md-section.md

@@ -128,9 +128,9 @@ trivial change.
   the exhausted tier path falls straight to the merge-hold), or an
   operator merge-hold, and adds a row (task, choice, reason) to
   `03-decisions.md`'s Review-round escalation table, then sets the
-  `review-round-escalation` marker to the most recent choice. A counted
-  round is a completed reviewer return recommending `fix_required` or
-  `reject`; a misfired review is not a round. Which of the three is
+  `review-round-escalation` marker to the most recent choice. A negative round
+  has an `acceptance_recommendation` of `fix_required` or `reject`; a misfired
+  review is not a round. A negative round counts only with at least one introduced_by_delta yes/unknown finding; no stays ordinary gate. Which of the three is
   picked is judgment; that one is picked and recorded is not. Escalating
   never substitutes for a review round and comes in addition to the halt
   rule's split-or-redesign response, not instead of it.

package/assets/skill/SKILL.md

@@ -211,20 +211,34 @@ directory and the subagents.
    for real, observe the named test fail, restore, re-verify). Hold the
    implementer's report to the claim-only-what-was-measured rule too: treat any
    verification claim there that is not backed by a check it actually ran as
-   unverified. On any round after the task's first, the briefing also names
+   unverified. The installed `implementer.md` prompt has the implementer cite
+   a coverage gate's threshold and pass/fail counts, not a run-specific
+   coverage percentage, citing a percentage only together with the exact
+   commit and the run count, since branch coverage can vary between runs of
+   the same commit. On any round after the task's first, the briefing also names
    every mutation probe named in an earlier round of this task (on the
    task's first round there are none), drawn from the run's
-   `04-implementation-summary.md`; the implementer replays each one, not
-   only the round's new probes, before the next reviewer spawn, and
-   reports each in `mutation_probes` with the four evidence fields plus
-   `replayed: true`. A replayed probe whose mutant now survives or can no
-   longer be applied is a regression signal, reported as such (`result`
-   `survived` or `not_applicable` with the reason) and resolved before the
-   next reviewer spawn. Record meaningful decisions in
+   `04-implementation-summary.md`, naming each by its mutant definition
+   (file, anchor, before, after), not merely by its id; a probe recorded
+   with only an id and no definition to reapply cannot be replayed and is
+   `not_applicable` (reason: `no definition recorded`), not a regression.
+   The implementer replays each one, not only the round's new probes,
+   before the next reviewer spawn, and reports each in `mutation_probes`
+   with the evidence fields plus `replayed: true`. A replayed probe whose
+   `expectation` is now `violated`, or which can no longer be applied
+   (reason: `target text no longer present`), is the regression signal;
+   `result` alone is not: reported as such (`result` `survived` or
+   `not_applicable` with the reason) and resolved before the next reviewer
+   spawn. Record meaningful decisions in
    `03-decisions.md` and consolidate evidence in
    `04-implementation-summary.md`, recording each probe the implementer
    reports as a row in `04-implementation-summary.md`'s Mutation Probes
-   subsection, with the round it was named in. For any diff that adds or
+   subsection, with the round it was named in. Each row's Before/After
+   cells hold a single-line excerpt; when the mutant's actual before/after
+   text is multi-line or contains an unescaped `|`, or the mutant is a
+   patch/diff rather than a text swap, the full text or diff goes in the
+   implementer report or a fenced block placed directly under the table,
+   with the row noting where it lives. For any diff that adds or
    changes a GitHub Actions `run:` step, the installed `implementer.md`
    prompt requires replaying it locally under the shell the step actually
    runs, with the expected-success and the expected-failure inputs, before
@@ -258,54 +272,60 @@ directory and the subagents.
    operator flags high-risk; `normal` only for docs, renames, or batch
    cosmetics; `rigorous` otherwise. The method is orthogonal to the tier and
    never substitutes for it: do not pair `adversarial` with the `-medium`
-   reviewer tier, a budget mismatch that names probes without the effort to
-   run them; tiers themselves are unchanged by this axis. When the
-   reviewer's environment cannot use version
-   control to see the diff (for example a policy-gated repository), supply the
-   diff as a pre-generated file in the briefing instead of expecting the
-   reviewer to derive it, and have the reviewer report explicitly if it could
-   only reconstruct the delta some other way, rather than silently reviewing
-   less than the full change. The reviewer checks spec compliance, architecture
-   consistency, edge cases, security, test adequacy (including whether new
-   tests would fail if the change were reverted), and maintainability. Findings
-   go to `05-review-findings.md`; transfer each finding from the reviewer
-   output contract into the table's columns as-is, keeping the Severity and
-   Decision headers unchanged, since those two are what the
-   orchestrator-workflow completeness reader verifies. Replace the shipped
-   placeholder/legend row with the transferred findings; for a genuine
-   zero-findings review, delete that row instead of leaving it in place, since
-   the completeness reader treats an untouched placeholder row with no finding
-   rows as the template never having been filled in. When acceptance rests on
-   empirical or probabilistic evidence (flake rates, benchmarks, "n runs
-   green", performance/timing numbers), the reviewer must independently
-   reproduce it — its own runs or measurements, not a re-read of the
-   implementer's log — and record the method, sample size, and result against
-   the implementer's claim in the reviewer output contract's `reproduction`
-   field. This does not apply to deterministic checks (a single test run,
-   `tsc`, lint): only claims that could vary run to run trigger it. The GitHub
-   Actions shell replay named in step 6 is a second, explicitly
+   reviewer tier, a budget mismatch that names probes without the effort to run
+   them; tiers themselves are unchanged by this axis. When the reviewer's
+   environment cannot use version control to see the diff (for example a
+   policy-gated repository), supply the diff as a pre-generated file in the
+   briefing instead of expecting the reviewer to derive it, and have the
+   reviewer report explicitly if it could only reconstruct the delta some other
+   way, rather than silently reviewing less than the full change. The reviewer
+   checks spec compliance, architecture consistency, edge cases, security, test
+   adequacy (including whether new tests would fail if the change were
+   reverted), and maintainability. Findings go to `05-review-findings.md`;
+   transfer each finding from the reviewer output contract into the table's
+   columns as-is, keeping the Severity and Decision headers unchanged, since
+   those two are what the orchestrator-workflow completeness reader verifies.
+   Replace the shipped placeholder/legend row with the transferred findings;
+   for a genuine zero-findings review, delete that row instead of leaving it in
+   place, since the completeness reader treats an untouched placeholder row
+   with no finding rows as the template never having been filled in. When
+   acceptance rests on empirical or probabilistic evidence (flake rates,
+   benchmarks, "n runs green", performance/timing numbers), the reviewer must
+   independently reproduce it — its own runs or measurements, not a re-read of
+   the implementer's log — and record the method, sample size, and result
+   against the implementer's claim in the reviewer output contract's
+   `reproduction` field. This does not apply to deterministic checks (a single
+   test run, `tsc`, lint): only claims that could vary run to run trigger it.
+   The GitHub Actions shell replay named in step 6 is a second, explicitly
    non-probabilistic trigger for the same field, with `sample_size:
    not_applicable` allowed when the replay itself has no meaningful sample
-   size. A change that deletes or renames an exported identifier, type, config
-   key, or file is also checked for identifier drift (docs or comments still
-   describing the old name as current), by the reviewer or by the orchestrator
-   itself when it reviews a trivial rename per Scaling delegation, using a
-   connected drift check when one exists. When this is not the task's first
-   review round, name the round number in the briefing; the reviewer marks each
-   finding's `recurrence` as `new` or `repeated` against the earlier rounds it
-   was told about, which is what lets the orchestrator detect the Review-round
-   escalation budget's trigger (see below) without re-deriving it by hand. When
-   the implementer's report replays a prior round's mutation probe, the
-   orchestrator's reviewer briefing names the replayed probes the implementer
-   reports as killed together with their `mutant` and `verified_applied_via`
-   values; the reviewer may then skip re-running those. The reviewer output
-   contract itself is unchanged. Never run mutation probes in place against a
-   worktree a reviewer subagent is concurrently reviewing; isolate the probe in
-   a separate worktree or wait until the reviewer has returned before probing
-   that tree again. For an explicitly adopted v1 run, ask the reviewer to
-   compare the frozen delegated criteria with the referenced evidence and judge
-   semantic adequacy, including whether a manual check is actually concrete and
-   reasoned.
+   size. When citing a coverage gate, the installed `reviewer.md` prompt has
+   the reviewer cite the threshold and pass/fail counts, not a run-specific
+   coverage percentage, citing a percentage only together with the exact commit
+   and the run count, since branch coverage can vary between runs of the same
+   commit. A change that deletes or renames an exported identifier, type,
+   config key, or file is also checked for identifier drift (docs or comments
+   still describing the old name as current), by the reviewer or by the
+   orchestrator itself when it reviews a trivial rename per Scaling delegation,
+   using a connected drift check when one exists. When this is not the task's
+   first review round, name the round number in the briefing; the reviewer
+   marks each finding's `recurrence` as `new` or `repeated` against the earlier
+   rounds it was told about, which is what lets the orchestrator detect the
+   Review-round escalation budget's trigger (see below) without re-deriving it
+   by hand. The reviewer classifies every finding with the `introduced_by_delta` field (`yes`, `no`, or `unknown`); it sets `no` only after naming a base build and replaying the same reproduction in `reproduction`, and transfers it through the ordinary gate (not bounded-round guidance, which considers only `yes`/`unknown`). When findings are transferred, record the classification parenthetically in the `Description` field as `(introduced_by_delta: yes|no|unknown)`. When the implementer's report replays a prior round's mutation
+   probe, the orchestrator's reviewer briefing names the replayed probes the
+   implementer reports as killed together with their mutant definition
+   (`file`, `anchor`, `before`, `after`) and `verified_applied_via` value,
+   not merely their id; a probe recorded with only an id and no definition
+   cannot be skipped this way and is `not_applicable`. The reviewer may
+   then skip re-running the ones named by definition.
+   The reviewer output contract itself is unchanged. Never run mutation probes
+   in place against a worktree a reviewer subagent is concurrently reviewing;
+   isolate the probe in a separate worktree or wait until the reviewer has
+   returned before probing that tree again. For an explicitly adopted v1 run,
+   ask the reviewer to compare the frozen delegated criteria with the
+   referenced evidence and judge semantic adequacy, including whether a manual
+   check is actually concrete and reasoned.
 8. **Decide acceptance.** Accept, request fixes, defer, or escalate to the
    operator. High or critical findings block acceptance until fixed or
    explicitly waived: critical findings require operator sign-off; high
@@ -313,8 +333,8 @@ directory and the subagents.
    or critical finding counts as a waiver and follows the same rules. Record
    all decisions and waivers in `03-decisions.md` and summarize waivers in
    the Accepted Waivers section of `06-handoff.md`. A reviewer recommendation is not orchestrator acceptance and cannot authorize a critical waiver; only the operator may authorize a critical waiver. For newly created decision records, identify a stable ID, trigger/evidence, decision, accountable authority/source with concrete approval evidence, consequences, and a superseded decision ID when revising a prior decision. Link baseline revisions and waivers to those decision IDs. Established runs retain their recorded decision format; absent fields never create a retroactive blocker. Routine decisions within the delegated contract remain the orchestrator's responsibility; an out-of-scope change requires an operator decision. Markdown records evidence of real authority and never grant it by themselves. Do not accept while a
-   required baseline criterion in an explicitly adopted v1 run has an open residual; a residual retains its ID
-   and cannot be converted away. After independent review,
+   required baseline criterion in an explicitly adopted v1 run has an open
+   residual; a residual retains its ID and cannot be converted away. After independent review,
    the orchestrator may close a docs-only delta without another reviewer round only
    when the entire unreviewed delta contains only explanatory
    documentation, comments, or citations; contains no source- or test-file
@@ -454,8 +474,14 @@ tests:
   not_executed_reason: ""
 mutation_probes:
   - mutant: ""
+    file: ""
+    anchor: ""
+    before: ""
+    after: ""
     verified_applied_via: ""
-    result: ""
+    result: killed | survived | not_applicable
+    expectation: met | violated | not_applicable
+    reason: ""
     restored_verified: ""
     replayed: false | true
 risks:
@@ -481,19 +507,37 @@ identifies the reviewed artifact and revision, reviewer, method, pass/fail
 standard, reasoned result, and baseline/criterion identities; it stays manual.
 
 When the task assignment names mutation probes to run, the implementer
-reports each one in the `mutation_probes` field (mutant,
-verified_applied_via, result, restored_verified); when the assignment
-names none, it returns `mutation_probes: []` rather than omitting the
-field, so 'none asked for' is distinguishable from 'asked for and not
-reported'. Each item also carries `replayed`: `false` for a probe newly
-introduced this round, `true` for a prior round's probe replayed this
-round under the replay rule in step 6. On any round after the task's
-first, the implementer replays every probe named in an earlier round of
-this task (on the task's first round there are none), not only this
-round's new probes, before the next reviewer spawn, reporting each one in
-`mutation_probes` alongside the round's new probes. A replayed probe
-whose mutant now survives or can no longer be applied is a regression
-signal, reported as such and resolved before the next reviewer spawn.
+reports each one in the `mutation_probes` field (mutant, file, anchor,
+before, after, verified_applied_via, result, expectation, reason,
+restored_verified); `file` and `anchor` (a line number or a unique
+surrounding string) locate the mutant, `before` and `after` are the
+exact text swapped there, and `expectation` records whether `result`
+matched what the probe was expected to do (`met`) or not (`violated`),
+independent of `result` itself, only alongside a measured `killed` or
+`survived` `result`; it is `not_applicable` otherwise (for example when
+the mutant could not be applied and no `result` was measured). `reason`
+is free text, required when `result` is `not_applicable`, empty
+otherwise, carrying one of two canonical strings that distinguish a
+non-regression from a regression: `no definition recorded` (a
+prior-round probe recorded with only an id, no definition to reapply)
+and `target text no longer present` (a replayed probe whose mutant can
+no longer be applied). When the assignment names none, it returns
+`mutation_probes: []` rather than
+omitting the field, so 'none asked for' is distinguishable from 'asked
+for and not reported'. Each item also carries `replayed`: `false` for a
+probe newly introduced this round, `true` for a prior round's probe
+replayed this round under the replay rule in step 6. On any round after
+the task's first, the implementer replays every probe named in an
+earlier round of this task (on the task's first round there are none),
+naming each by its mutant definition, not merely by its id, not only
+this round's new probes, before the next reviewer spawn, reporting each
+one in `mutation_probes` alongside the round's new probes. A replayed
+probe whose `expectation` is now `violated`, or which can no longer be
+applied (reason: `target text no longer present`), is the regression
+signal, reported as such and resolved before the next reviewer spawn;
+`result` alone is not a regression signal, and a probe recorded with
+only an id and no definition to reapply is `not_applicable` (reason:
+`no definition recorded`).
 
 The `commits` field lists the full sha of every commit the implementer
 produced on the task branch, in the order produced; when the task
@@ -501,12 +545,17 @@ produced no commit, the implementer returns `commits: []` rather than
 omitting the field, so 'did not commit' is distinguishable from
 'forgot to report'.
 
+For a non-empty `commits` field, the implementer pastes `git log
+--reverse --format=%H <base>..HEAD`; it never types or hand-completes commit
+shas. Verification plans, probe plans, and repeat tallies run in the foreground, and the
+implementer reports their returns in the same turn as the last check. A
+background monitor is no substitute for those returns.
+
 ## Reviewer output contract
 
 The output shape remains the same for either selected contract. Compare the
 delegated versioned records and producer evidence under Contract selection
 above; a recommendation does not replace orchestrator acceptance.
-
 ```yaml
 status: reviewed
 role: reviewer
@@ -519,6 +568,7 @@ findings:
     description: ""
     suggested_fix: ""
     recurrence: new | repeated
+    introduced_by_delta: yes | no | unknown
 acceptance_recommendation: accept | accept_with_notes | fix_required | reject
 missing_tests:
   - ""
@@ -534,7 +584,6 @@ withdrawn:
   - description: ""
     reason: ""
 ```
-
 `acceptance_recommendation` is mandatory: every reviewer return must set it.
 When it is missing, the orchestrator asks the reviewer to resupply it
 instead of inferring one from the findings list.
@@ -544,6 +593,7 @@ task: `new` for a defect class not previously found here, `repeated` for
 one that already appeared in an earlier round. On a task's first review
 round every finding is `new` by definition. This is what feeds the
 Review-round escalation budget's trigger.
+`introduced_by_delta` records whether a finding is attributable to the reviewed delta: `no` requires a named base build and replay in `reproduction`, is transferred parenthetically in the `Description` field of `05-review-findings.md` without renaming `Severity`/`Decision`, and follows the ordinary gate; only `yes`/`unknown` participate in bounded-round rules.
 
 `method_applied` echoes the `review_method` named in the briefing (see step
 7); `withdrawn` lists each finding the reviewer proposed and then retracted
@@ -715,7 +765,7 @@ review and never satisfies the review gate, since review is never skipped.
 The signal: a review round finds a new defect of the same class a previous
 round's fix already addressed, so the class has recurred once after being
 fixed, and the next fix would again be case-by-case enumeration (boundary
-tokens, spellings, and similar one-off patches). Stop the first time this
+tokens, spellings, and similar one-off patches). Apply this signal only to `introduced_by_delta: yes`/`unknown`; `no` continues through the ordinary finding gate. Stop the first time this
 signal fires: the recurrence is already the class's second occurrence, so
 do not wait for a third one before stopping. Name the structural cause in
 one sentence, and decide to split or redesign rather than keep accreting
@@ -733,11 +783,9 @@ and across repeated review rounds, so effort does not keep accumulating
 unaided: by the second round-2 halt signal on the same task, or by the
 third `fix_required` review round on the same task, whichever comes
 first, choose one of three escalations instead of running another round
-the same way. A counted round is a completed reviewer return whose
-`acceptance_recommendation` is `fix_required` or `reject`; a misfired
-review is not a round (see Subagent misfire rule); the escalation is
-chosen once the third such round has returned, before the next attempt
-starts. The escalation is chosen in addition to the halt rule's
+the same way. A negative round has an `acceptance_recommendation` of
+`fix_required` or `reject`; a misfired review is not a round (see Subagent
+misfire rule). A negative round counts only with at least one introduced_by_delta yes/unknown finding; no stays ordinary gate. The escalation is chosen in addition to the halt rule's
 split-or-redesign response, not instead of it.
 
 - **Tier or model escalation**: raise the implementer to at least

package/assets/templates/03-decisions.md

@@ -13,7 +13,7 @@ critical waivers remain distinct. -->
 
 ## Review-round escalation
 
-<!-- One row per task that triggers the Review-round escalation budget in SKILL.md: the second round-2 halt signal or the third fix_required review round on that task. A run carries multiple tasks, so this table can carry multiple rows. Leave the single placeholder row as n/a when no task in this run has triggered the budget. -->
+<!-- One row per task that triggers the Review-round escalation budget in SKILL.md: the second round-2 halt signal or the third negative round on that task. A negative round counts only with at least one introduced_by_delta yes/unknown finding; no stays ordinary gate. A run carries multiple tasks, so this table can carry multiple rows. Leave the single placeholder row as n/a when no task in this run has triggered the budget. -->
 
 | Task | Choice | Reason |
 |---|---|---|

package/assets/templates/04-implementation-summary.md

@@ -68,9 +68,15 @@ an optional row cannot stand in for a required criterion.
 
 ### Mutation Probes
 
-| Round | Mutant | Verified Applied Via | Result | Restored Verified | Replayed |
-|---|---|---|---|---|---|
-| <!-- round --> | <!-- mutant --> | <!-- verified_applied_via --> | <!-- result --> | <!-- restored_verified --> | <!-- replayed --> |
+Before/After cells hold a single-line excerpt. When the mutant's actual
+before/after text is multi-line or contains an unescaped `|`, or the mutant
+is a patch/diff rather than a text swap, put the full text or diff in the
+implementer report or a fenced block directly under the table, and note
+where it lives in the row's own cell.
+
+| Round | Mutant | File | Anchor | Before | After | Verified Applied Via | Result | Expectation | Reason | Restored Verified | Replayed |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+| <!-- round --> | <!-- mutant --> | <!-- file --> | <!-- anchor --> | <!-- before --> | <!-- after --> | <!-- verified_applied_via --> | <!-- result --> | <!-- expectation --> | <!-- reason --> | <!-- restored_verified --> | <!-- replayed --> |
 
 ## Risks / Notes
 

package/assets/templates/05-review-findings.md

@@ -16,7 +16,8 @@ by the grounding-mcp completeness reader yet).
 | Severity | Category | Description | Suggested Fix | Decision |
 |---|---|---|---|---|
 | low/medium/high/critical | correctness/architecture/security/tests/maintainability/performance/docs | <!-- finding --> | <!-- fix --> | accepted/defer |
-<!-- This row is the shipped template placeholder, not a finding: the orchestrator-workflow completeness reader fails the completeness gate closed when this exact row survives untouched and no concrete finding row has been added, the same way a `TODO` marker does. During findings transfer (step 7), replace this row with each reviewer finding. For a genuine zero-findings review, delete this row instead — a header row with no data rows is a valid, complete table; leaving this row next to real finding rows is also fine. This mirrors grounding-mcp's placeholder-row detection; keep the two in sync. -->
+<!-- This legacy five-cell table and placeholder row are the shipped template, not a finding: the orchestrator-workflow completeness reader matches the row byte-for-byte and fails the completeness gate closed when it survives untouched with no concrete finding row, the same way a `TODO` marker does. During findings transfer (step 7), replace this row with each reviewer finding and record its attribution parenthetically in the Description field as `(introduced_by_delta: yes|no|unknown)`. For a genuine zero-findings review, delete this row instead — a header row with no data rows is a valid, complete table; leaving this row next to real finding rows is also fine. This mirrors grounding-mcp's placeholder-row detection; keep the two in sync. -->
+<!-- A `no` classification requires the named base build and replay recorded in the reviewer's `reproduction`; it follows the ordinary finding gate, while only `yes`/`unknown` feed bounded-round halt and escalation guidance. The load-bearing Severity and Decision headers remain unchanged. -->
 
 ## Missing Tests
 
@@ -35,4 +36,3 @@ accept | accept_with_notes | fix_required | reject
 <!-- Reproduction note: when a finding rests on empirical or probabilistic evidence (flake rates, benchmarks, "n runs green", performance/timing numbers), record the reviewer's independent reproduction (method, sample size, result vs. the implementer's claim) in the reviewer output contract's `reproduction` field (SKILL.md step 7). Deterministic checks (a single test run, tsc, lint) do not require it. -->
 
 <!-- Recurrence note: each finding in the reviewer output contract also carries a `recurrence` field (new or repeated), letting the orchestrator read the Review-round escalation budget's trigger (SKILL.md, Review-round escalation budget) off the reviewer's own return instead of reconstructing it by hand. A repeated finding here is what feeds that budget's round count. -->
-

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "orchestrator-workflow",
-  "version": "0.32.0",
+  "version": "0.34.0",
   "description": "Installer for an orchestrator-led agent workflow: .ai/ run state, an AGENTS.md policy section, and per-harness subagent definitions for Claude Code, OpenAI Codex, and opencode",
   "main": "dist/index.js",
   "type": "module",