reset-node reuses an immutable attempt-ledger identity

[aviggiano]

Summary

After a failed node attempt has already been projected into the immutable node-attempt ledger, a same-run resume --reset-node can reopen the same runner attempt identity with different timestamps and state. The next status synchronization then rejects the replacement record even though the workflow is running.

Minimal synthetic fixture

1. Create a temporary Git project with a one-node workflow and a deterministic stub agent.
2. Let attempt 1 fail, then invoke ultrafuzz status --json once so the terminal attempt is projected into the node-attempt ledger.
3. Run ultrafuzz resume synthetic-run --project /tmp/uf-reset-ledger/project --reset-node node:worker --max-concurrency 1 --json.
4. Keep the reopened attempt running long enough to invoke ultrafuzz status synthetic-run --project /tmp/uf-reset-ledger/project --json again.

The status payload reports a running workflow but also returns ok: false with:

NODE_ATTEMPT_LEDGER_WRITE_FAILED
node attempt ["synthetic-run", 42] was already recorded with different immutable data

No model or target-specific artifact is required; the collision is between reset semantics and the generic immutable attempt-ledger contract.

Expected behavior

A reset execution must receive a distinct immutable ledger identity, or be represented as a new reset revision without rewriting the prior attempt row. Historical terminal rows remain unchanged, while status and stats continue to emit schema-valid snapshots during the reopened execution.

Acceptance criteria

• A model-free fixture projects a failed attempt, resets that node, and synchronizes while the replacement attempt is running.
• The prior ledger row remains byte-for-byte unchanged.
• The replacement execution has a distinct stable identity and lifecycle.
• status --json and stats --json do not emit an attempt-ledger write diagnostic.
• Repeated synchronization is idempotent.

[aviggiano]

Could not reproduce on main. Ledger identity is [workflow_run_id, source_event_sequence], Smithers never reuses a sequence, and the existing test at runtime.test.ts:21275 covers a reset that reuses the attempt number. PR #1038 targets a key-order drift that has no path on main; see the analysis there. Please attach the two conflicting attempts.jsonl rows or the sync log so the differing field can be identified.

[aviggiano]

The immutable-row collision remains unreproduced, with a stronger real-run control now available. On main a5b0a905, a model-free sealed/generated workflow used the pinned Smithers runner and a deterministic local provider. A genuine CLI status call recorded failed event 24 before production resume --reset-node. The replacement reused iteration 0/attempt 1 and finished at event 47. After completion, two status and two stats calls succeeded without diagnostics, preserved the failed row byte-for-byte, and appended the replacement once. Repeated ledger bytes stayed identical; stats reported two executed attempts and one retry.

Limits: this baseline used original-policy continuation compensation: explicitly supplying the genuine launch governance-policy path to isolate ledger/reset behavior from the separate defect addressed by #1117. The final #1117 runs required no such manual input. This baseline's running-stage snapshot retained the old ledger bytes, but its four CLI checks occurred after completion; this does not complete the issue's live, while-running CLI acceptance criterion. The existing deterministic synchronization test also passes through a running replacement, using fixture Smithers responses.

Reusing the physical attempt number therefore does not itself reproduce a collision: the recorded occurrences retain distinct source-event sequences. Keep this issue open for the original conflicting immutable rows and the field that changed. #1038 was closed without merging its speculative digest migration. The separate unrecorded-history failure in #1099, and #1117's prevention before stopped reset, do not establish or repair the collision reported here.