Isolated Review Checkout

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

Use case

The main workspace contains uncommitted user edits while reviewing committed revision-a. An isolated checkout avoids switching main, but does not automatically include those edits. Establish scope first.

Mechanism

Record main/target, create permitted isolated checkout and verify identity/dependencies. Sparse views must retain necessary callers. Keep review artifacts separate and compare main afterward. Uncommitted scopes need controlled snapshots, not HEAD substitution. Unavailable isolation leaves main read-only without destructive cleanup.

Bad example

Switch main and clear uncommitted blockers, or call revision-a checkout a review of latest working-tree edits.

Good example

For teaching revision-a, preserve main status and inspect an identity-checked isolated checkout. Verify unchanged main afterward. If scope becomes uncommitted work, materialize a labelled scoped snapshot rather than HEAD. Creation failure reports safe alternatives; cleanup targets verified owned review paths only.

Why the change matters

Isolation protects the implementation site while target identity prevents committed-only data from masquerading as current work. Main comparison establishes preservation rather than assuming it from worktree use.

Observable expectation

Inspect unchanged main and revision-a evidence. Missing sparse callers remain gaps or are retrieved within scope.

Cleanup failure triggers no destructive main fallback; absent uncommitted target cannot pass. No worktree is created/deleted.

Limits

Directories do not isolate shared credentials/cache/services. Verify coverage/capabilities and absolute ownership before cleanup. Frozen commands grant no current permissions.