{
  "module": "8 — State, Checkpointing & Multi-Session",
  "course": "Master Course — Harness Engineering",
  "version": "1.0.0", "duration_minutes": 30, "total_questions": 10,
  "bloom_distribution": { "target": "20/40/40", "actual": { "recall": 2, "application": 4, "analysis": 4 } },
  "passing_score_percent": 70,
  "questions": [
    { "id": "Q01", "bloom": "recall", "type": "multiple_choice", "prompt": "Name the 5 checkpointing patterns.", "options": ["RAM/disk/tape/cloud/hybrid", "Git · LangGraph super-steps · External file · DB-backed · None", "Local/remote/cache/CDN/origin", "Sync/async/batch/stream/none"], "answer_index": 1, "rationale": "From code-only (git) to fully stateless (none). Choice depends on use case and infrastructure." },
    { "id": "Q02", "bloom": "recall", "type": "multiple_choice", "prompt": "Why must a checkpoint write be atomic?", "options": ["For performance", "A half-written checkpoint is WORSE than none — resume from corrupt state = undefined behavior. Temp+rename ensures old-or-new, never mixed.", "For security", "For readability"], "answer_index": 1, "rationale": "Crash-safety. The temp+rename pattern (POSIX atomic rename) guarantees the path always points to a valid checkpoint." },
    { "id": "Q03", "bloom": "application", "type": "multiple_choice", "prompt": "A harness writes checkpoints by direct file write (no temp+rename). It crashes mid-write. What happens on resume?", "options": ["Clean resume", "Corrupt checkpoint → undefined behavior on resume. The half-written file is neither the old nor new state. Fix: temp+rename.", "Automatic recovery", "The harness detects corruption"], "answer_index": 1, "rationale": "The non-atomic-write failure. Direct writes can be interrupted. Temp+rename is atomic on POSIX — the fix." },
    { "id": "Q04", "bloom": "application", "type": "multiple_choice", "prompt": "You're building a coding agent in a git repo. Which checkpoint pattern?", "options": ["DB-backed", "Git commits — free version control, human-readable, rollback native (git reset). Each step committed = a checkpoint.", "None", "External file"], "answer_index": 1, "rationale": "Git is ideal for code-centric tasks. Free rollback, readable history. The coding-agent default (Claude Code, Aider)." },
    { "id": "Q05", "bloom": "application", "type": "multiple_choice", "prompt": "You changed your system prompt and want to know if agent behavior regressed. What technique?", "options": ["Re-read the prompt", "Session diffing — compare checkpointed sessions before and after the change to find behavioral drift.", "Run more tests", "Ask the user"], "answer_index": 1, "rationale": "Session diffing compares two checkpointed runs to detect drift — faster, more reliable, more error-prone, etc." },
    { "id": "Q06", "bloom": "application", "type": "multiple_choice", "prompt": "A harness has no checkpointing. A 30-step task crashes at step 15. What's the consequence?", "options": ["Resume at 15", "Full restart from step 1. All 15 completed steps' work is lost (unless separately committed to git). 'No checkpointing' is a production defect for multi-step tasks.", "The harness retries automatically", "The user must redo everything"], "answer_index": 1, "rationale": "The cost of no checkpointing. Every interruption = restart. For real multi-step tasks, this is a defect." },
    { "id": "Q07", "bloom": "analysis", "type": "multiple_choice", "prompt": "Checkpoint vs handoff — why both?", "options": ["Redundancy", "Checkpoint = technical substrate for lossless resume (the bytes). Handoff = human-legible summary for the continuation agent's orientation (the meaning). Both needed: bytes for resume, meaning for orientation.", "Only checkpoint needed", "Only handoff needed"], "answer_index": 1, "rationale": "Complementary layers. Checkpoint (Module 8) enables lossless resume; handoff (Module 4) tells the continuation agent WHAT to resume and WHY." },
    { "id": "Q08", "bloom": "analysis", "type": "multiple_choice", "prompt": "Module 6's interrupt() and Module 8's checkpointing — relationship?", "options": ["Unrelated", "Two views of the same infrastructure. interrupt() pauses and needs serialization to resume losslessly; checkpointing IS that serialization. No HITL without checkpointing.", "interrupt replaces checkpointing", "Checkpointing replaces interrupt"], "answer_index": 1, "rationale": "Same capability, two APIs. interrupt() is the pause interface; checkpointing is the state serialization that makes the pause lossless." },
    { "id": "Q09", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is git 'not atomic' as a checkpoint for non-code state?", "options": ["Git is slow", "Git checkpoints work for files in the repo. Agent state that's NOT a file (in-memory context, runtime variables) isn't captured by a git commit. Need a separate state checkpoint for non-file state.", "Git is insecure", "Git doesn't support checkpoints"], "answer_index": 1, "rationale": "Git captures file state, not in-memory runtime state. A coding agent whose work is files is well-served; an agent with complex in-memory state needs an additional checkpoint mechanism." },
    { "id": "Q10", "bloom": "analysis", "type": "multiple_choice", "prompt": "Why is 'temp + rename' crash-safe but 'direct write' not?", "options": ["Temp files are faster", "POSIX rename() is atomic — the path always points to old-or-new, never a mix. Direct write can be interrupted mid-write, leaving a partial/corrupt file. The rename is the single commit point.", "Rename compresses", "Direct write is illegal"], "answer_index": 1, "rationale": "The POSIX atomicity guarantee. rename() is a single atomic operation; direct write is a multi-block operation that can be interrupted between blocks." }
  ]
}