orchestrator-workflow 0.33.0 → 0.34.0

package/CHANGELOG.md

@@ -7,6 +7,16 @@ 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

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
@@ -145,7 +145,6 @@ Rules:
   read its summary before opening full logs.
 
 Return exactly this structure as your final output, nothing else:
-
 ```yaml
 status: reviewed
 role: reviewer
@@ -158,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

@@ -312,7 +312,7 @@ directory and the subagents.
    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
+   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,
@@ -556,7 +556,6 @@ background monitor is no substitute for those returns.
 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
@@ -569,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:
   - ""
@@ -584,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.
@@ -594,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
@@ -765,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
@@ -783,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/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.33.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",