Lab assignment
Resume versus fork
Compare continuation and branching while keeping conversation state distinct from workspace state.
The brief
Your assignment
Create a disposable practice repository with one small, intentional defect. Resume the original session to continue one hypothesis, then fork before a major decision to try another. A fork creates an independent session history; it does not create an independent filesystem. Isolate edited work with separate copies or worktrees.
Before you build
Set up a safe workspace
- Create a disposable repository with one small intentional defect.
- Commit or otherwise record a clean baseline.
- Prepare separate copies or worktrees before comparing edited approaches.
Build in checkpoints
One observable behavior at a time
- 01Record the first hypothesis in the original session.
- 02Resume and re-read changed external state.
- 03Fork from the shared baseline for a second hypothesis.
- 04Keep edited filesystem state isolated between approaches.
- 05Compare the two histories and write a recovery note.
What you'll practice
- Distinguish conversation history from external workspace state.
- Re-check stale external state after resuming.
- Use a fork for an independent conversational branch.
- Persist exact facts separately from conversational memory.
Your lab files
Four files for each lab
- 01
decision.mdState the requirement, chosen pattern, rejected alternatives, and the reason for the tradeoff.
- 02
implementation/Keep the smallest working example, configuration, diagram, or synthetic-trace analysis.
- 03
evidence.mdRecord test cases, observed results, failure behavior, limitations, and evidence locations.
- 04
review.mdExplain what must be deterministic, what may remain model-directed, and where a human is required.
What to save
- A baseline commit or checkpoint.
- A redacted session manifest and two hypothesis records.
- A shared/copied/separate state table.
- A recovery note.
Test bench
What good work includes
- Resume continues the prior history.
- Fork creates a separate session history from the shared baseline.
- Changed files are re-read instead of trusted from old tool output.
- Approaches that edit files use isolated filesystem state.
Review questions
- When is resuming cheaper but unsafe?
- What does a fork not isolate?
- What belongs in durable state rather than conversation history?
Strong solutions tend to
- Re-verification after resume.
- Explicit checkpoints and filesystem isolation.
- Durable facts and evidence rather than saved hidden reasoning.
Partial example
What useful evidence can look like
This is one small example, not a complete solution or a template you must copy. Use the notes to see why the evidence is useful.
Open annotated example from evidence.md / state comparison
Resume: same conversation history; same investigation path
Fork: copied history at branch point; new hypothesis
Shared: workspace files written by either session
Separate: later messages and tool observations- Shared
- Prevents a conversation branch from being mistaken for a filesystem rollback.
- Separate
- States exactly what can diverge after the branch.
Review your work
Use evidence from your work—not confidence alone. For each area, run the check and choose the strongest stage your work fully demonstrates.
Resume and stale state
A resumed session keeps useful conversation history but rechecks workspace facts that may have changed.
Change one file after the checkpoint, resume the session, and show where the workflow rereads that file before relying on the old observation.
Needs another pass
The resumed session trusts old tool output as current without checking the workspace again.
Partly demonstrated
Some changed files are reread, but the recovery note does not state which earlier observations remain safe and which are stale.
Demonstrated
The session preserves prior reasoning context, identifies possibly stale observations, rereads changed external state, and records what was revalidated.
Fork and workspace isolation
The two conversational branches share a baseline but cannot overwrite each other’s edited files.
Compare both session IDs and both filesystem paths, then make a different edit in each approach and confirm the other copy does not change.
Needs another pass
The work treats a session fork as a filesystem copy, so both approaches edit the same files.
Partly demonstrated
The sessions are separate, but the workspace table or actual edit test does not prove filesystem isolation.
Demonstrated
The fork has independent session history, each edited approach uses a separate copy or worktree, and the state table correctly labels what is shared and separate.
Durable facts and checkpoints
Exact facts needed by either branch live in a small, reviewable artifact rather than depending on remembered conversation.
Start a fresh session with only the baseline and saved artifacts. Verify that it can recover the defect, evidence locations, hypotheses, decisions, and open questions.
Needs another pass
Important facts exist only in conversation history, or the saved record contains a transcript instead of usable state.
Partly demonstrated
The manifest preserves the main hypothesis but omits exact evidence locations, decisions, or freshness information.
Demonstrated
The manifest preserves exact facts, evidence locations, decisions, open questions, and checkpoint identity without storing hidden reasoning or secrets.
Comparison and recovery evidence
The packet makes the two approaches fairly comparable and shows how work can continue after either session is unavailable.
Confirm both approaches started from the same baseline, then use the recovery note to continue each one without its original conversation.
Needs another pass
The approaches start from different repository states, or there is no usable recovery path.
Partly demonstrated
A common baseline is recorded, but the comparison misses changed state, observed results, or a concrete recovery step.
Demonstrated
Both approaches start from the same checkpoint, their separate changes and results are recorded, and the recovery note identifies the correct session, workspace, evidence, and next action.