mutate round 2 burned 763 s on must_write: artifact predates node start (reset does not clear .ai/hypothesis.patch between rounds, or maker writes a no-op)

[bkrabach]

Found in passing by the pipeline reviews (attractor REVIEW-pipelines-2026-09.md §8.2). Evidence: #64 run 2, mutate round 2 across three sessions: mtime 1788737217.642 <= node_start 1788744193.583; planted before or at node start. The must_write freshness floor correctly refused a stale artifact, but the graph then retried the maker three times (763 s) instead of resetting. Ask: (a) determine whether author_reset/rival_reset should also clear .ai/hypothesis.patch between rounds, or whether the maker legitimately produced identical content (no-op write → same mtime); (b) fix the reset or make the maker's write unconditional; (c) add a hermetic test that a round-2 maker starts with a clean artifact slot.

[github-actions]

Specify stage: hit its wall-clock ceiling mid-work -- no postmortem is possible on this path.

What happened: the pipeline was still doing real work (not stalled)
when it hit its wall-clock fuse. 0 of 2 iteration(s) completed; fuse --param max_duration=19800s; mean cost of a complete iteration 330 min; at that cost the fuse affords ~1 complete iteration(s). The fuse tripped mid-work.

Why there is no postmortem here: the fuse exits the run directly,
before the engine's own recover/postmortem step ever gets a chance to
run -- a known, separate engine limitation, not a sign anything else
went wrong. This is NOT the same thing as "ran out of iteration budget
without converging".

What happens next: a maintainer will personally review this issue
and follow up.

Workflow run: https://github.com/microsoft/amplifier-bundle-dot-runner/actions/runs/34161668813

[github-actions]

Specify stage: the automated pipeline couldn't produce a verified work plan for this yet.

What happened: the pipeline ran, but did not converge on a proven
work capsule within its iteration budget.

What this does NOT mean: this is not a judgment of your report.

What happens next: a maintainer will personally review this issue
and follow up.

Technical postmortem (for maintainers)

# Capsule-run postmortem

## Lead finding: the void dodge greened, but was never adjudicated

`.ai/findings/void-greened.md` must be carried forward to the human's attention. In the first non-vacuity round, the void patch was recorded as `greened` (`.ai/convergence.jsonl`, iteration 1, `gate: nonvacuity`). In the next round it was not disproven: it became `no_apply`, with `void_greened: false`, `void_alive: 0`, and `void_noapply: 1` (`.ai/convergence.jsonl`, iteration 2, `gate: nonvacuity`). The accompanying finding explicitly says that not-applicable is unmeasured, not closed. Therefore no critic has ruled that the current gate rejects that dodge. This is unresolved evidence, not a successful non-vacuity result.

## What was tried

### Setup and orientation

The run established a real pinned base at `6d6fa9141ea3dfcb19de12b524f1308569cfbae4`, read the issue, and surveyed the capsule graph and reset commands. The internal brief grounded the suspected behavior in the `author_reset` round boundary, the `mutate` node's `must_write` contract, and the engine's `planted before or at node start` diagnostic. Setup found shipped tests and proceeded (`.ai/convergence.jsonl`, iteration 0).

### Round 1

- **author_reset:** passed the reset/cleanliness gate (`dirty: false`, with three PYC artifacts purged).
- **round and leak:** passed (`shape: ok`, `clean: true`).
- **redgate:** correctly returned `rc: 1`, so the verifier was RED at this stage.
- **nonvacuity:** hypothesis A greened, hypothesis B greened, the rival greened, and the void patch also greened. The record says the void patch had `void_archive: 1` and `void_alive: 1` (`.ai/convergence.jsonl`, iteration 1). The rival was separately measured as green, but the later critique notes that its added test failed (`1 failed, 25 passed`) and that the gate did not actually exercise that maker/retry surface.
- **critique:** returned `ITERATE`.

The round-1 critique identified that the verifier deleted the runtime-seeded stale artifact after running the public reset and before asserting its survival/absence behavior. It also identified that the gate only drove `author_reset`, did not exercise `rival_reset` or the maker/retry path, and imposed an unsupported byte-for-byte `.ai/feedback` preservation requirement. These findings are recorded in `.ai/gate.log` and `.ai/critique.md`.

The associated mutation attempts were not a convergent repair: hypothesis A changed the verifier, hypothesis B changed the shipped `author_reset` call path, and the void patch removed the post-reset assertion. Those mechanisms produced green measurements rather than a critic-approved, behavior-bound definition.

### Round 2

- **author_reset:** again passed the reset/cleanliness gate (`dirty: false`, three PYC artifacts purged).
- **round and leak:** again passed (`shape: ok`, `clean: true`).
- **redgate:** again returned `rc: 1`.
- **nonvacuity:** A and B again greened; the rival again greened; the archived void patch was `no_apply`, not measured. The same convergence row records `void_ratchet: no_apply` and `hermetic: unprobed_apply` (`.ai/convergence.jsonl`, iteration 2).
- **critique:** returned `ITERATE` again.

The author-stage summary claimed that the stale-artifact assertion had been re-enabled, but the actual gate evidence still found `rm -f "$prior_artifact"` in the verifier between the public command and the relevant assertion. The direct control described in `.ai/gate.log` failed with the intended stale-artifact diagnostic only when those deletion lines were removed; the shipped verifier exited successfully because it erased the witness first. Thus the central RED-for-the-right-reason proof remained invalid.

The second critique also retained the surface-coverage and unlicensed-preservation findings. It additionally recorded that the rival's proposed regression test was not a passing supporting result.

## Convergence classification

The loop was **WANDERING**, not descending. The convergence record shows that the basic stages and `redgate` repeated the same outcomes in iterations 1 and 2, while the substantive non-vacuity measurements remained green for A, B, and the rival. The only apparent change for the void dodge was from `greened` to `no_apply`; `.ai/findings/void-greened.md` explicitly says that this means unmeasured rather than closed. Hermeticity also remained `unprobed_apply`. There is no sequence of critic-approved reductions in the blocking surface, and there is not a stable alternation between two competing, measured hypotheses that would justify calling this oscillation. The run repeatedly traversed the pipeline without resolving the same witness-deletion and behavior-coverage defects.

## Best hypothesis for non-convergence

The capsule author optimized around getting a verifier and mutation patches through the mechanical gates rather than first fixing the observable contract. In particular:

1. The verifier mutated its own witness (`rm -f "$prior_artifact"`) before checking the reported round-boundary behavior. That makes a green result compatible with the base SHA and prevents the RED result from proving the issue.
2. The gate chose one convenient shell seam (`author_reset`) instead of defining a public behavior that admits the issue's two stated repair alternatives: clearing the stale artifact at a round boundary or ensuring the maker performs a fresh, content-bearing `must_write` write. Consequently, a correct change in the retry/maker path, or at the rival reset seam, could remain RED.
3. The capsule added an exact `.ai/feedback` preservation assertion that the issue does not authorize, making the definition stricter than the report while leaving the key artifact assertion unsound.
4. The adversarial and rival evidence was treated as progress even when it was either a voided assertion, a non-applying patch, an unprobed surface, or a failing added test. The convergence ledger therefore recorded green/no-apply statuses without a critic ruling on the actual behavior-bound question.

## Value salvaged and questions for the filer

The run did establish useful constraints: the pinned base really preserves `.ai/` across the shown `git clean -qfd -e .ai` reset; the engine's `must_write` freshness floor rejects a planted artifact using the stable diagnostic `planted before or at node start`; and an ordinary no-write maker can consume the in-node retry budget. What it did not establish is which legal repair boundary the issue expects. The following questions are concrete and answerable by the person who filed `/home/runner/work/_temp/capsule-run/issue.md`:

1. **Which externally observable contract should be accepted?** Should the definition require that `author_reset` remove `.ai/hypothesis.patch`, should it require the maker to perform a fresh write on the next `mutate` visit, or are both implementations intentionally acceptable as the issue wording suggests?
2. **Which public path is the report about?** Is the required regression scenario specifically the author-to-`mutate` second-round path, the `rival_reset` path, the maker/retry path in `retry.py`, or a single end-to-end capsule round that must cover all of them? Please name the command or graph traversal a maintainer would run.
3. **What should happen to the artifact at the round boundary?** Is `.ai/hypothesis.patch` per-round ephemeral state that must be absent before the next maker visit, while the capsule, feedback, findings, and convergence files remain in `.ai`? If so, which other hypothesis artifacts, if any, have the same lifecycle?
4. **What is the intended no-op-write rule?** If the maker produces identical bytes, is refreshing the artifact's mtime enough to satisfy `must_write`, or must the content change? If identical content is not acceptable, what non-triviality/freshness outcome should the regression test assert?
5. **What evidence is available for the reported 763 seconds?** Can the filer provide the round-2 node trace, maker response, attempt timestamps, and whether the maker skipped the filesystem write, so the test can distinguish a stale preserved artifact from a maker that simply failed to write?
6. **Is `.ai/feedback` preservation part of the intended contract?** The issue does not state byte-for-byte preservation. If it is required, please state that rule and whether it applies across `author_reset`, `rival_reset`, and non-vacuity round trips; otherwise the capsule should not make it an acceptance condition.
7. **What result should a repaired round expose?** Beyond avoiding the stale-artifact retry, should the test require a newly written `.ai/hypothesis.patch`, a successful `mutate` outcome, a bounded number of attempts, or a particular elapsed-time ceiling?

Until these answers are supplied, a human can reject the current capsule for the right reasons, but cannot approve a replacement definition without guessing at the intended repair surface and state-lifecycle contract.

Workflow run: https://github.com/microsoft/amplifier-bundle-dot-runner/actions/runs/34189585014

[bkrabach]

Resolved source-first:

• Source correction: amplifier-bundle-attractor#353, merged at 6d301c60c501d0449f615abd1f73c81a59de9c26.
• Downstream port: amplifier-bundle-dot-runner#93, merged at e32603b7de802cd76866abb1ceb9253a0ac28d21.
• Valid port proof: baseline e33a8d9 was RED in all three reset cases; semantic change 3da0f49 was GREEN; c81b3e9 is provenance-only and has the same executable reset bytes as 3da0f49.
• Independent DTU reset79-cross-repo-20260908 and validator confirmed the red-to-green behavior, unchanged feedback, loud cleanup failure, and the required freshness controls (absent/no-write failed twice; identical actual-byte rewrites passed twice). No model or paid semantic pipeline run was used.

The issue is now closed by the merged port PR.