Daily dead-code sweep 2026-10-08: unused generation getter on the directions object

[EnesYilmazcode]

Daily automated dead-code sweep. node --test baseline was green (938 tests, 934 pass, 4 skipped) before and after this change.

Checked against open sweep PRs first. Listed open PRs whose head branch starts with deadcode/ and read every diff before starting, so this doesn't re-find or re-delete anything already pending:

• Daily dead-code sweep 2026-10-04: unused sprite symbols i-bin, i-tick #169 (deadcode/2026-10-04): sprite symbols i-bin, i-tick
• Daily dead-code sweep 2026-09-29: directions.matrix, TERM_NAMES #148 (deadcode/2026-09-29): directions.matrix(), MATRIX_MAX, TERM_NAMES
• Daily dead-code sweep 2026-09-27: the #chips compatibility shim, expiry met #147 (deadcode/2026-09-27): the #chips compatibility shim (expiry met)
• Daily dead-code sweep 2026-09-24: inBounds, a test-only helper #146 (deadcode/2026-09-24): campus.inBounds
• Daily dead-code sweep 2026-09-23: bestGap, inScheduledHours #144 (deadcode/2026-09-23): engine.bestGap, state.inScheduledHours
• Daily dead-code sweep 2026-09-22: allWeekCodes, a test-only helper #143 (deadcode/2026-09-22): state.allWeekCodes

Everything below is new; none of it overlaps those diffs.

Removed

js/directions.js: the get generation() accessor on the object createDirections() returns. (was lines 112–114)

• What it is: a read-only getter exposing the module's internal stale-response counter, alongside invalidate() which bumps that same counter.
• How I proved it dead: built a throwaway Chrome DevTools Protocol coverage harness (reusing scripts/lib/browser.mjs and scripts/lib/pinned-clock.mjs, the same pattern scripts/shoot.mjs uses) that starts Profiler.startPreciseCoverage({callCount:true, detailed:true}) and CSS.startRuleUsageTracking(), then drives the real app at a pinned clock/location through: the question screen, both card swipe verdicts (held and dropped), the way screen, binning the full 35-room deck into the ranked list, selecting a room, the room day-calendar screen with day-nav arrows forward and back, "Sources" → the About/"What Vacant knows" screen, the location picker, the building picker (search + drill into a room + back out), every refusal screen reachable with the shipped data (Saturday 3am, a weekday evening after scheduled hours via the gate button, Thanksgiving Day → CAMPUS_CLOSED, finals week → EXAM_REFUSAL, before-term-start → BETWEEN_TERMS, after-exams → TERM_ENDED), ?dev=1, dev/index.html, a fresh profile with /data/* network-blocked (the boot-failure/cold-start card), and an offline reload after the service worker had cached a normal boot. Merged coverage across all of it: the getter's byte range was never once entered. A repo-wide grep confirms it independently — js/app.js calls state.directions?.invalidate() but never reads .generation back, and no other file does either. invalidate() already returns the freshly-bumped count, so a caller never needed the separate getter to begin with; only a test read it directly.
• What would make me wrong: a caller reading .generation through a path grep can't see — dynamic property access (d['generation']) or reflection. I didn't find either in this codebase, and the coverage sweep's own driving would have exercised any such caller too if one existed on a screen I reached.
• Confidence: high. This is the strongest-evidenced finding of the sweep — both the runtime coverage and the static grep agree, and the removal is mechanical (the getter and its one external reader, a test, are both gone; invalidate() and the internal staleness checks that compare against the closed-over generation variable directly are untouched).

Updated scripts/test/directions.test.mjs accordingly: the one test that read d.generation directly now asserts the same increment-and-report behavior through invalidate()'s own return value, which is what's left to observe it with.

Not removed, not proven

Coverage also flagged plenty of other zero-count functions (map pan/zoom/wheel gesture handlers, the custom map-pin picker, the install-prompt banner, service-worker update UI, the firstrun cold-boot retry button, dev-panel custom date entry, geolocation error callbacks, the Google-consented "Step by step" directions feature). Every one of these has a confirmed real caller via grep — they're wired to native browser events this headless sweep can't easily synthesize (pinch gestures, beforeinstallprompt, a waiting service worker, native geolocation errors) rather than being unreachable. Left alone per the brief: not reached isn't proven dead.

Also confirmed and left alone as explicitly-reachable-later, not dead: the BETWEEN_TERMS "gap" variant (needs current.next, which the shipped data/current.json doesn't carry yet) and the SCHEDULE_DARK/INDEX_REFUSED/CLOCK_REFUSED refusal branches, which require conditions (a near-total schedule blackout, a build that under-delivered rooms, or an unreadable device clock) that don't occur anywhere in the shipped Autumn 2026 data — verified by running resolveState directly over every date the term's calendar actually defines. These are defensive/future-facing branches, not unreachable code.

CSS rule-usage tracking (CSS.startRuleUsageTracking/CSS.takeCoverageDelta) across the same states found no unused rules in index.html's inline stylesheet, and no sprite symbol beyond the two already claimed by #169 has a zero reference count. node scripts/check-dead-code.mjs also reports clean.

Notes

• node scripts/shoot.mjs --check was run; three pre-existing failures (list/room sheet-height assertions) reproduce identically on a clean main checkout with no changes, confirmed by stashing this diff and re-running — unrelated to this PR.
• This change doesn't move the sw.js gzip byte figures outside the test's existing 1% tolerance, so no re-stamp was needed.

🤖 Generated with Claude Code

https://claude.ai/code/session_018uATJfgH74g8DjKBWwoN3e

---

Generated by Claude Code