Fork vs Fresh Spawning

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

An implementer has defended a design; an independent reviewer needs a fresh view, while another worker resumes unfinished implementation. One should not receive preferred verdict cues; the other may need state. Host inheritance is not universal.

Mechanism

Choose continuity versus independence by purpose. Fresh review gets revision, requirements, artifacts and necessary facts without preferred conclusions. Continuation inherits needed state only under supported permitted semantics. Inspect actual inputs/private boundaries and record inherited content rather than inferring from fresh/fork labels.

Bad example

Fork all design advocacy into supposedly independent review, or give a blank continuation prompt while assuming previous steps are known.

Good example

Use a fresh teaching review brief with candidate/acceptance/artifacts/facts, no author-preferred verdict. For implementation continuation retain objective/open step/state only under verified host support/scope. Inspect what actually crosses the boundary; labels establish neither isolation nor memory.

Why the change matters

Context controls available facts and prior conclusions. Purpose-aware selection preserves continuation while limiting direct review anchoring, with actual-input checks for both.

Observable expectation

The illustrative review omits ‘already best’ while retaining requirements; continuation identifies next step/revision. Inspect no private-scope leak or missing facts turned into guesses.

Fresh does not guarantee unbiased judgment and fork does not guarantee complete state. No real agent is dispatched.

Limits

Inheritance/storage/cache are host-specific. Independence must not omit necessary facts. Respect explicit restrictions on inherited/private context. Provenance remains unconfirmed.