There was an error while loading. Please reload this page.
Record tripId/activeTripId interlining decision for trips-for-route Java always conflates data.list[].tripId with status.activeTripId, schedule, and situationIds — all four are populated from the same active-trip instance with no route-based filtering (verified against TripStatusBeanServiceImpl at the pinned commit). PR #1256 (closing #1254) deliberately decouples them: tripId now resolves to the queried-route trip that caused the block to be selected, while status.activeTripId keeps reflecting whatever trip the vehicle is actually running. Correct the Main Success Scenario and the four affected field descriptions (tripId, situationIds, schedule.stopTimes, status.activeTripId) to describe Java's actual conflated behaviour first, each pointing to the new Implementation Decisions entry where Maglev diverges — matching the maxCount entry's existing pattern of documenting the decision once and cross-referencing it from the spots it affects.
Remove maxCount from trips-for-route Documented the decision to remove the maxCount param. This param is parsed but ignored by the legacy impl. The parameter does not make sense for this endpoint. It was likely included by legacy unintentionally via a shared path.
docs(trips-for-location, trips-for-route): record previous-calendar-day serviceDate for past-midnight trips Both endpoints share trip-for-vehicle's block-resolution path (BlockStatusServiceImpl/BlockCalendarServiceImpl), which already resolves the correct previous-day service date for trips extending past midnight. trip-for-vehicle.md documented this; these two specs didn't.
Remove implementation opinions from API specs Specs describe legacy OBA behaviour only. Any opinion on what Maglev should do belongs exclusively in the Implementation Decisions section. Prescriptive sentences ("The Go implementation should...", "A clean Go reimplementation should...") have been removed or rephrased as tentative statements about what the original developer probably intended ("The intended behaviour was probably..."), so the defect context is preserved without preempting implementation decisions. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Update OBA API specs (2026-05-11T23:13:08Z)