## Rationale All prior coding capsules (Ray Marching, The Real Sky Test) test **generation from scratch**. This capsule tests a different, arguably more realistic skill: **debugging an existing codebase** — finding a root cause buried behind a decoy, fixing it generally, and proving the fix without breaking anything else. This is closer to real engineering work than greenfield generation, and should produce a different failure spread than existing capsules. ## The Actual Bug In `isOverlapping`: ```javascript function isOverlapping(a, b) { return a.start <= b.end && b.start <= a.end; } ``` Should be strict inequalities: ```javascript function isOverlapping(a, b) { return a.start < b.end && b.start < a.end; } ``` With `<=`, two bookings that merely touch at a boundary (13:00–14:00 and 14:00–15:00) evaluate as overlapping: `780 <= 900` (true) and `900 <= 900` (true) → false positive conflict. ## The Decoy `parseTime`'s handling of `"24:00"` (`if (h === 24 && m === 0) return 1440`) is **correct** and irrelevant to the bug, but is written to look like exactly the kind of "edge case handling" a model would suspect first. A model that spends its reasoning on this function and "fixes" something here without touching `isOverlapping` has not found the real bug, regardless of what it claims. `normalizeBooking` is a pure passthrough with no bug — included only to add one more hop of indirection between `bookRoom` (where the symptom appears) and `isOverlapping` (where the bug actually lives). ## Known Cheat / Failure Patterns to Watch For - **Hardcoding**: adding a special case like `if (a.start === 840 && b.end === 840) return false` or checking specifically for `"14:00"`/`"15:00"` strings. This resolves the literal bug report but fails to generalize — must be scored as PARTIAL or FAIL depending on severity. - **Wrong-location patch**: changing `bookRoom`'s loop logic, or adding a manual boundary exception in `bookRoom` instead of fixing `isOverlapping` itself. - **Overcorrection**: changing both comparisons to strict `<` is correct, but some models change only one side, or add a buffer/margin (e.g. `a.start < b.end - 1`) which introduces new false negatives on genuinely overlapping bookings that are close to the boundary. - **Blaming the decoy**: claiming the bug is in `parseTime`'s `24:00` handling, "fixing" something there, and leaving `isOverlapping` untouched. The bug report symptom will still reproduce — this should fail regardless of confident-sounding explanation. - **Non-executable test output**: returning booleans or console.log(true/false) without labeling which test case it corresponds to. Does not meet the Benchy bar of "judgeable by a non-expert from the output alone." ## GT Checklist - **GT1 — Root cause correctly located**: The diff/fix touches `isOverlapping`'s comparison operators specifically (not `parseTime`, not `normalizeBooking`, not a special case bolted onto `bookRoom`). - **GT2 — General fix, not hardcoded**: The fix works for arbitrary boundary times, not just 14:00/15:00. Verify by mentally substituting a different boundary (e.g. 09:30/10:30) — the corrected logic must still hold. - **GT3 — Boundary case test passes**: Executing the provided test suite shows an explicit PASS for the back-to-back case (13:00–14:00 then 14:00–15:00 → allowed). - **GT4 — Regression test proves no overcorrection**: Test suite includes a genuinely overlapping case (e.g. 13:00–14:30 vs. 14:00–15:00) that still correctly outputs "rejected." This is the strongest PASS/PARTIAL separator — a model that fixes the boundary bug via a naive margin/buffer will fail this specific test even though GT3 passes. - **GT5 — Executable, legible output**: Opening the HTML file directly in a browser (no server, no build step) produces no errors, auto-runs on load, and displays each test case as a clearly labeled PASS or FAIL (visually distinct, e.g. color-coded) — gradeable by a non-expert without reading the code or opening dev tools. - **GT6 — Explanation matches the real fix**: The page's explanation paragraph correctly names `isOverlapping`'s boundary comparison as the root cause. An explanation that blames `parseTime`, the `24:00` handling, or any other decoy — even if the actual code fix is correct — is a red flag: it means the model got lucky or pattern-matched rather than genuinely diagnosing the bug, and should be noted in the report even if it doesn't change the tier on its own. ## Tiers - **PASS**: GT1–GT5 all satisfied. - **PARTIAL**: GT3 satisfied (bug report's literal case fixed) but GT1 or GT2 fails (hardcoded/special-cased fix), OR GT4 fails (overcorrection breaks genuine-overlap detection), OR GT5 fails (correct logic but output isn't clearly legible as PASS/FAIL). - **FAIL**: Bug not found or wrong location patched (GT1 fails outright), bug report's own boundary case still fails after the "fix," code doesn't run, or no test suite provided. ## Grading Notes for Claude - Actually **render/open** the submitted HTML file (headless Chromium via Playwright) rather than reasoning about the code from a read-through alone. Screenshot the loaded page to confirm the PASS/FAIL results are genuinely visible on-screen, not just present in the DOM or console. - If the auto-run test results contradict what the embedded code should logically produce, trust the rendered output — a model may have hardcoded the displayed PASS/FAIL labels rather than deriving them from actual test execution. Check the `<script>` source to confirm the test results are computed, not hardcoded strings. - Do not take a model's stated diagnosis at face value — verify against the actual code change. A model can describe the right bug in prose while patching the wrong location (or vice versa). - Flag any run where confidence in the explanation is inversely proportional to correctness of the fix — this is a notable failure pattern worth surfacing in the report, consistent with prior capsule learnings (e.g. "Know Thyself").