{
 "model": "claude-haiku-5-5",
 "category": "context",
 "scenarios": [
  {
   "id": "c1-handoff",
   "status": "pass",
   "product_defects": [],
   "task_outcome": "Three handoffs across 4 sessions; ARCHITECTURE.md was written in session 2 and corrected in session 4, naming all 11 engine files and three risks. Exit codes all 0, driver.err empty, no leftovers, 0 unpaired tool blocks, sessions mode 600, cost recomputed from usageTotals = $0.07550309 (matches).",
   "notes": "Read-before-handoff was sent at all 3 handoffs, each after unread tool results. Replies were text-only with no tool-use frames, and each starts after a blank line in the saved interrupted message. Session 3's note was cut at 3,244 tokens (room 3,500 - 256) and carries the cut-off marker; the other two finished. No 'not seen yet' wording appears in any saved handoff; handoff.ts sets unseenFrom to lastReply+1, so the writer sees those results as read (the writer's prompt is not saved, so this comes from the code). Stalls ran 1, none (session 2 wrote a file), 1. Progress check text was present in continuations 2 and 4 and absent in 3; sub-agent wording never applied (count stayed below 3). The binding rule leads every continuation and every saved .md. <request> stays the original through the chain. Old sessions are saved as interrupted with the handoff path in metadata.reason. No skill block. Clearing worked twice (43,549 → 29,294 and 42,127 → 35,855, the latter 74.8% with reserve) with pairing intact. Model behaviour, not a defect: sessions 3 and 4 re-read files listed as done, as the known 10h behaviour did. Those seeds were accurate and put a verification pass in Next steps. The '8192' fact in seed 3 was the model's own wrong probe, and session 4 corrected it."
  },
  {
   "id": "c2-compact",
   "status": "pass",
   "product_defects": [],
   "task_outcome": "Asked once (contextFull 1), compacted 3 times mid-turn with no API error, turn completed and ARCHITECTURE.md (8,273 bytes) mentions all 11 modules and three risks. Exit 0, no leftovers, pairs intact, compaction_count 3, cost matches recompute.",
   "notes": "The user's request is kept word for word as contextMessages[0], with the summary next to it holding left-to-do, files and line ranges read, and state. Kept results that were clipped led the model to continue with FileRead offsets; coverage of queryEngine.ts reached 1-967. cacheInvalidations 3 equals the 3 compactions. The re-reading costs extra requests but is the designed clip path."
  },
  {
   "id": "c3-stop-then-continue",
   "status": "pass",
   "product_defects": [],
   "task_outcome": "The stop ended the turn with a clear 93% message and was saved as interrupted. /compact shrank 46,896 → 16,904 tokens and kept the archive in compactArchives. The continuation read only the missing queryEngine.ts range (plus one past-EOF hooks.ts read) and wrote ARCHITECTURE.md (17,014 bytes, a section for all 11 modules). No API 400, exit 0, no leftovers, cost matches.",
   "notes": "Saved compacted text carries 3 parts labelled part 1, 2 and 3 of 3. The part prompts are not saved, so I reproduced them by running snapshot summarizeContext on the saved archive with a fake client under a scratch HOME (reserve 21,000 approximated; since removed). That gave 3 parts, matching the live count. Each part has 'Part i of 3' and the user's request (not the engine stop marker). Results are labelled '[tool result of FileRead <full path ending in the file name>]'. Part 2 ends with '[this block continues in the next part]' and part 3 opens with '[continued from the previous part: …]'. Live summaries agree: part 2 reports hooks.ts cut at line 186, part 3 reports it from 187. Unseen results carry the 'not seen yet' header because the model never replied after those reads. Per-part 'next steps' in the summary are partly stale when joined; the model resolved them correctly."
  },
  {
   "id": "c4-handoff-chain",
   "status": "pass",
   "product_defects": [],
   "task_outcome": "Four handoffs, of which the driver followed 3 (its limit), so the fourth session's handoff was not continued. SUMMARIES.md grew across sessions with all 11 engine/ entries once each and no duplicates. engine2/ was not started when the driver stopped; the final seed states this accurately with next steps. Exit codes 0, no leftovers, cost matches.",
   "notes": "Unfinished only because of the harness hop limit and the model reading several files at once despite 'one by one', not G-Code. Read-before-handoff was sent at all 4 handoffs, replies text-only, blank-line start in all 4. Session 3's note was cut at 5,042 tokens with the marker (room 5,298 - 256). Stalls: none, none (Bash change tracked in outputs), 1, none. Only continuation 4 has 'Progress check: 1 session'. All continuations open with the binding rule and quote the ORIGINAL request; no loop. D17-9 confirmed: continuation 4's notes mention BrowserVerify and no skill block appears. The one failed Bash was `ls` of a not-yet-existing SUMMARIES.md, correctly state failed with its output kept in the error."
  },
  {
   "id": "c5-huge-log",
   "status": "pass",
   "product_defects": [],
   "task_outcome": "REPORT.md counts verified independently: W20 69,326, W10 46,455, E404 18,730, E500 11,674, E200 6,908. First E500 00:00:15, last by file position 20:26:37 (latest clock value 23:59:59; the log wraps at line 86401, and the report gives both readings). Exit 0, no leftovers, cost matches.",
   "notes": "The model used only awk/grep Bash with small outputs, so FileRead on the ~12 MB file and persisted large Bash output were not exercised here. Context stayed at about 16K tokens; cache read ratio 0.947."
  },
  {
   "id": "c6-many-files",
   "status": "pass",
   "product_defects": [],
   "task_outcome": "All 150 notes read (150 distinct FileRead paths). I verified INDEX.md: 150 entries, each once, none missing, every entry in the right Topic section (n mod 7). Exit 0, no leftovers, cost matches.",
   "notes": "Model behaviour: INDEX.md was written at notes/INDEX.md because of a `cd notes` in its script, and the final reply says so and offers to move it. Stray sed stderr in that Bash came from the same `cd`. No context-full at the 120K budget (46.5K used). toolHistory holds 100 entries against 153 calls because of the designed slice(-100) cap in runtimeEvents.ts:18."
  },
  {
   "id": "c7-multi-turn-cache",
   "status": "pass",
   "product_defects": [],
   "task_outcome": "Four turns completed. JSDoc and count() were added with a test. My own `npm test` gives 6 tests, 1 pass, 5 fail, matching the model's report; the 5 failures are seed bugs it was not asked to fix. Exit 0, no leftovers, cost matches.",
   "notes": "Cache read ratio 0.951 overall; last request read 21,382 of 21,822 input tokens; uncached input across all 12 requests is only 32 tokens, so the prefix stays cached across turns. Per-request usage is not saved, so the rise across turns is inferred from totals and lastUsage. learned/patterns.json has `npm test` runs 3, successes 0, broken 0, correct for three calls piped to tail or grep (status unknown). Not shown in the system prompt, and the store is under the run's own HOME."
  },
  {
   "id": "j6-long-session",
   "status": "pass",
   "product_defects": [],
   "task_outcome": "Six turns completed in one session with no handoff needed (62.7K of 90K used). My own `npm test`: 40 tests, 40 pass. src/cli.js, tests and README are present, and the final summary recalls all earlier work. 12 messages saved, pairs intact, exit 0, no leftovers, cost matches.",
   "notes": "Cache read ratio 0.956. The single failed Bash was `npm test | grep` with no match (exit 1), correctly state failed. learned/patterns.json has `npm test` runs 7, successes 0, broken 0, matching the 7 piped runs. Model changed seed behaviour to fix failing tests when asked and listed those decisions for review."
  }
 ]
}