[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"capsule:f41a748d-1d15-45d0-a148-5ac0fe4d3150":3},["Reactive",4],{"id":5,"user_id":6,"title":7,"prompt_content":8,"prompt_type":9,"is_locked":10,"is_public":10,"fork_of":11,"created_at":12,"updated_at":13,"category":14,"brief":15,"attachments":16,"expected_markers":17,"user":19},"f41a748d-1d15-45d0-a148-5ac0fe4d3150","695c8e6c-9654-4858-b2d3-925adefacc35","The Silent Regression","You are handed a small meeting room booking system. Users have filed the following bug report:\n\n> \"Back-to-back meetings are being rejected as conflicts. If I have a meeting from 13:00–14:00 and try to book a new meeting from 14:00–15:00, the system says the room is unavailable — even though the first meeting has already ended by the time the second one starts. This should be allowed.\"\n\n## Your Task\n\n1. **Find the root cause** of this bug in the code below. Do not just patch the symptom — identify why the logic produces this incorrect result.\n2. **Fix it** with a minimal, general-purpose correction (not a special case for 14:00\u002F15:00 specifically — the fix must work for any boundary time).\n3. **Write a test suite** (in the same language, runnable via `node \u003Cfilename>` with no external dependencies) that proves your fix works. Your tests must output a clear, human-readable PASS or FAIL for each case — not just a silent return value.\n4. Your test suite must cover **at least**:\n   - The exact back-to-back case from the bug report (should be **allowed**)\n   - A genuinely overlapping case, e.g. one booking partially overlapping another (should still be **rejected** — prove your fix didn't overcorrect)\n   - A clearly non-overlapping case (should be **allowed**)\n\n## Source Code\n\n```javascript\n\u002F\u002F booking.js\n\u002F\u002F Meeting Room Booking System\n\u002F\u002F Handles conflict detection for room reservations.\n\n\u002F**\n * Parses a time string \"HH:MM\" (24-hour format) into minutes since midnight.\n * Supports \"24:00\" as a special end-of-day marker (converted to 1440).\n *\u002F\nfunction parseTime(str) {\n  const [h, m] = str.split(':').map(Number);\n  if (h === 24 && m === 0) return 1440; \u002F\u002F handle midnight edge case\n  return h * 60 + m;\n}\n\n\u002F**\n * Normalizes a raw booking object ({start: \"HH:MM\", end: \"HH:MM\"})\n * into minute-based numeric representation.\n *\u002F\nfunction normalizeBooking(booking) {\n  return {\n    start: parseTime(booking.start),\n    end: parseTime(booking.end),\n    label: booking.label || null\n  };\n}\n\n\u002F**\n * Determines whether two normalized bookings overlap in time.\n * Two bookings that merely touch at a boundary (one ends exactly\n * when the other starts) are NOT considered overlapping.\n *\u002F\nfunction isOverlapping(a, b) {\n  return a.start \u003C= b.end && b.start \u003C= a.end;\n}\n\n\u002F**\n * Attempts to book a room. Returns { allowed: true } if no conflicts,\n * or { allowed: false, conflictWith: \u003Cbooking> } if a conflict is found.\n *\u002F\nfunction bookRoom(existingBookings, newBookingRaw) {\n  const newBooking = normalizeBooking(newBookingRaw);\n  for (const existingRaw of existingBookings) {\n    const existing = normalizeBooking(existingRaw);\n    if (isOverlapping(existing, newBooking)) {\n      return { allowed: false, conflictWith: existingRaw };\n    }\n  }\n  return { allowed: true };\n}\n\nmodule.exports = { parseTime, normalizeBooking, isOverlapping, bookRoom };\n```\n\n## Deliverable\n\nProvide a **single, self-contained HTML file** that:\n\n1. Includes your **corrected booking logic** (embedded in a `\u003Cscript>` tag — plain JavaScript, no build tools or external libraries).\n2. **Automatically runs all required test cases the moment the file is opened in a browser** — no button click, no console required.\n3. **Visually displays the result of each test case on the page itself** (not just in the browser console), clearly labeled PASS or FAIL, including:\n   - The exact back-to-back case from the bug report (should be **allowed**)\n   - A genuinely overlapping case, e.g. one booking partially overlapping another (should still be **rejected**)\n   - A clearly non-overlapping case (should be **allowed**)\n4. Makes it obvious at a glance — to someone who does not read the code — whether each test passed or failed (e.g. green\u002Fred styling, a checklist, or similar).\n\nThe file must open and run correctly with no server, no build step, and no internet connection — just double-clicking it in a browser.\n\nIn addition to the auto-running tests, the same HTML page must also display, below the test results:\n\n**Section 1 — Corrected Code**\nThe full corrected source code, shown readably on the page (e.g. in a `\u003Cpre>` block), not just embedded silently in a `\u003Cscript>` tag.\n\n**Section 2 — Explanation**\nA short paragraph explaining what the bug was, where it was located, and why your fix resolves it.","text",true,null,"2026-07-09T12:49:20.082233+00:00","2026-07-09T12:51:26.972589+00:00","coding","## Rationale\n\nAll 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.\n\n## The Actual Bug\n\nIn `isOverlapping`:\n```javascript\nfunction isOverlapping(a, b) {\n  return a.start \u003C= b.end && b.start \u003C= a.end;\n}\n```\nShould be strict inequalities:\n```javascript\nfunction isOverlapping(a, b) {\n  return a.start \u003C b.end && b.start \u003C a.end;\n}\n```\nWith `\u003C=`, two bookings that merely touch at a boundary (13:00–14:00 and 14:00–15:00) evaluate as overlapping: `780 \u003C= 900` (true) and `900 \u003C= 900` (true) → false positive conflict.\n\n## The Decoy\n\n`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.\n\n`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).\n\n## Known Cheat \u002F Failure Patterns to Watch For\n\n- **Hardcoding**: adding a special case like `if (a.start === 840 && b.end === 840) return false` or checking specifically for `\"14:00\"`\u002F`\"15:00\"` strings. This resolves the literal bug report but fails to generalize — must be scored as PARTIAL or FAIL depending on severity.\n- **Wrong-location patch**: changing `bookRoom`'s loop logic, or adding a manual boundary exception in `bookRoom` instead of fixing `isOverlapping` itself.\n- **Overcorrection**: changing both comparisons to strict `\u003C` is correct, but some models change only one side, or add a buffer\u002Fmargin (e.g. `a.start \u003C b.end - 1`) which introduces new false negatives on genuinely overlapping bookings that are close to the boundary.\n- **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.\n- **Non-executable test output**: returning booleans or console.log(true\u002Ffalse) without labeling which test case it corresponds to. Does not meet the Benchy bar of \"judgeable by a non-expert from the output alone.\"\n\n## GT Checklist\n\n- **GT1 — Root cause correctly located**: The diff\u002Ffix touches `isOverlapping`'s comparison operators specifically (not `parseTime`, not `normalizeBooking`, not a special case bolted onto `bookRoom`).\n- **GT2 — General fix, not hardcoded**: The fix works for arbitrary boundary times, not just 14:00\u002F15:00. Verify by mentally substituting a different boundary (e.g. 09:30\u002F10:30) — the corrected logic must still hold.\n- **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).\n- **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\u002FPARTIAL separator — a model that fixes the boundary bug via a naive margin\u002Fbuffer will fail this specific test even though GT3 passes.\n- **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.\n- **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.\n\n## Tiers\n\n- **PASS**: GT1–GT5 all satisfied.\n- **PARTIAL**: GT3 satisfied (bug report's literal case fixed) but GT1 or GT2 fails (hardcoded\u002Fspecial-cased fix), OR GT4 fails (overcorrection breaks genuine-overlap detection), OR GT5 fails (correct logic but output isn't clearly legible as PASS\u002FFAIL).\n- **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.\n\n## Grading Notes for Claude\n\n- Actually **render\u002Fopen** 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\u002FFAIL results are genuinely visible on-screen, not just present in the DOM or console.\n- 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\u002FFAIL labels rather than deriving them from actual test execution. Check the `\u003Cscript>` source to confirm the test results are computed, not hardcoded strings.\n- 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).\n- 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\").",[],{"items":18,"matchAll":10},[],{"username":20,"avatar_url":21},"Ezarwebmaster","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42354978?v=4"]