Parallel-Safe Step Identification

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

Use case

A user explicitly requests a local commit of a.js while unrelated edits exist. Stable status/diff/history reads are independent; staging changes the index, commit consumes it and final status follows commit.

Mechanism

Map dependencies/write surfaces, batch independent reads and inspect every result. Select scope, then stage→inspect index→commit→status sequentially. Recheck changed snapshots rather than mixing states. No commit authorization means read/preparation only.

Bad example

Run add/commit/status together, treat the first result as final and stage unrelated files.

Good example

Under teaching authorization collect status/diff/style, select a.js only, then stage, inspect staged diff, commit and check final status. Preserve b.js. Recheck intervening input changes and never race commit against add. Without a commit request deliver inspection rather than infer Git rights from parallel reads.

Why the change matters

Reads do not consume one another; dependent mutations do. Restricting concurrency to true independence preserves state/evidence order.

Observable expectation

The fixture includes a.js only, staged inspection before commit and status afterward, retaining b.js. Inspect matched snapshots and failed results too.

Launching in one script alone proves no ordering; no real commit occurs.

Limits

Parallel reads need stable inputs, and shared files/tables/index require coordination. Frozen pane/worktree counts are not universal capacity; permission/risk governs.