[how2how2how2-arch]

Refs #33.

What this changes

A fork copies every event at or before the fork point, and an override replaces one of those outputs. A recorded output captured after the overridden step was produced under the upstream state the override changed, so replay substituting it is not evidence for the modified execution path. Today those outputs are indistinguishable from an ordinary substitution: MatchedCall.action is only substituted or executed, and nothing on the fork says which recorded outputs an override upstream invalidated.

fork_trace() now reports both facts on its result:

• overridden_steps — which steps were replaced (a set, not the existing overrides_applied count)
• stale_event_ids — the retained recorded outputs that follow the earliest of them

The CLI fork report shows them, and docs/fork.md gained a section on what the classification does and does not prove.

The limitation is stated, not implied

This is an upper bound, not dependency analysis: every recorded output after the earliest overridden step is reported, whether or not its inputs actually changed. The event the override replaced is not reported as stale, because its value is the override rather than a reused recording.

Replay does not consult the classification yet, so a call reported as substituted is still not by itself proof that it belongs to the modified path. Neither is the classification persisted into a bundle, so it is available only from the fork_trace() call that produced it. Both are written into the docs rather than left to be discovered.

Tests

tests/unit/test_fork_staleness.py, offline and deterministic:

• outputs after an override are reported stale
• a fork without overrides reports nothing stale
• the override target is not stale itself
• an override late in the prefix does not mark earlier outputs stale
• two overrides report the steps, not a count
• tool calls are never classified as outputs

The plant: replacing overridden_steps[0] with 0 in the classifier — classifying from "an override happened" instead of "which step it was" — fails test_only_outputs_after_the_earliest_override_are_stale with exactly one extra id, and passes again once restored.

Compatibility

No trace or receipt format change: the new fields are additive on ForkResult with defaults, and existing traces load, validate and replay unchanged. ruff check, ruff format --check and mypy src are clean, and the full suite is 722 passed.

Design note

This follows the approach I proposed in the issue thread on 2026-10-28: the classification needs the set of overridden steps, and no arithmetic on overrides_applied can recover it.