@@ -115,7 +115,7 @@ The 9 vehicles in service at 12:28:
 | `515218:216` | 12:00 Horní Oldřichov / 12:00 | yes (finished) |
 | `515229:241` | 12:07 Bynov / 12:07 | yes |
 | `515229:242` | 12:18 Nebočady / 12:18 | yes |
-| `515216:303` | none listed / 09:00 ZOO Děčín | **no**: valid 2026-05-01 to 09-28 (DPMD-Q7) |
+| `515216:303` | none listed / 09:00 ZOO Děčín | **no**: the Sunday twin of 203, and line 216's only version ends 2026-09-28 (DPMD-Q7) |
 
 8 of 9 resolve exactly, with matching first departures.
 
@@ -145,7 +145,7 @@ The 9 vehicles in service at 12:28:
 | DPMD-Q4 | the delay is whole minutes, absent at 0 and never negative: early running shows as on time | absent `Zpoždění` on a trip is `Delay(0)` as a weak constraint; GPS progress decides |
 | DPMD-Q5 | parked vehicles (`off: 1`, blue) stay in the list with their last position, up to about two weeks old in the capture | dropped by the connector |
 | DPMD-Q6 | a finished trip's key stays on the vehicle at the terminus, with its last delay (`515201:231` ended 12:24 and was still reported at 12:28 with 2 min) | as DUK-Q4: the journey finishes from GPS progress and the vehicle is in layover |
-| DPMD-Q7 | a trip number the timetable does not run that day: `515216:303` is a summer weekend trip (valid until 2026-09-28, 09:00 from ZOO Děčín), driven at 12:28 on 2026-10-10 towards Masarykovo nám. with no timetable in its popup | literal key, so `not_in_service`; to be checked against the 2026-10-09 release and DPMD's published timetable (a season extension missing from the export?) |
+| DPMD-Q7 | weekend trips come in twins: the Saturday trip `200 + n` and the Sunday trip `300 + n` have identical times (`515201:231`/`331` 11:50, `515229:241`/`341` 12:07; weekday trips are numbered separately), and a bus can report the other day's twin, as on DPMÚL (DUK-Q16). Seen once: `515216:303` (Sunday) on Saturday 2026-10-10 at 12:28, with no timetable in DPMD's own popup | taken literally, so `not_in_service`; the candidate fix is one twin rule for both sources (bind `200 + n` ↔ `300 + n` when only the twin runs that day). The sighting is only partly explained: line 216 has only its summer version (`260501`, last day 2026-09-28) in both the 2026-10-06 and 2026-10-09 releases, so neither 203 nor 303 runs on 2026-10-10, and both are the 09:00 trip from ZOO Děčín, not a 12:28 run |
 | DPMD-Q8 | every vehicle carries its driver's number (`driver`, `Řidič`) | personal data: a recorder filter removes it before archiving; the core never sees it |
 | DPMD-Q9 | without a fresh `v` the server returns a cached copy (5 minutes old on 2026-10-10) | always send `v=<epoch ms>`, and compare `TimeStamp` with reception (a stale body is skipped) |
 
@@ -186,8 +186,8 @@ Note it for R2 arbitration.
 ## Open questions
 
 - Terms of use: the endpoint is public with CORS `*`, and nothing is published about reuse.
-- DPMD-Q7: does the 2026-10-09 release run `515216:303` on 2026-10-10, and is it an extended
-  season or a reused number?
+- DPMD-Q7: does line 216 run in October (a version missing from the national export, as
+  DUK-Q17) or was bus 705 on an extra run? More twin sightings are needed before a twin rule.
 - How the source behaves around midnight, DST and service starts: the capture covers only
   3 minutes at midday. A 25-hour capture (`obehy rt record`) is the next step, as for the other
   sources.
 
@@ -207,7 +207,7 @@ Each quirk is handled where stated and has a scenario test named after its ID
 | DUK-Q13 | `Azimut` is exactly 0 in about 5 % of entries, often while the vehicle moves | 0 is read as no bearing; progress uses bearing only when present |
 | DUK-Q14 | in State 2/3, `Delay` is the time since the trip's scheduled departure, growing while the vehicle stands (vehicle 171, 2026-10-09: `582480:140` of 21:59 in the depot at 23:52, `Delay` 113) | source delay ignored until the trip starts (manifest `pre_trip_delay_is_elapsed`) |
 | DUK-Q15 | State 2/3 with a trip key whose scheduled end has passed: a stale key from the depot (same vehicle) | `stale_key`: not bound, and a journey that never started is dropped; a running vehicle keeps the late-running window (manifest `pre_trip_after_end_is_stale`) |
-| DUK-Q16 | DPmÚL night lines (`59504x`) run Friday nights under the weekend numbers: on 2026-10-09 at 23:51 a bus reported `595041:309` (Sat/Sun, 23:51–00:20) while the timetable runs the identical weekday trip `9` that night; `595043:2310` likewise. Weekday `n` and weekend `300 + n` have identical times | taken literally (as DUK-Q3): `not_in_service`, no realtime. Not handled; a DPmÚL-only twin rule (bind `n` ↔ `300 + n` when only the twin runs at that time) is the candidate fix |
+| DUK-Q16 | DPmÚL night lines (`59504x`) run Friday nights under the weekend numbers: on 2026-10-09 at 23:51 a bus reported `595041:309` (Sat/Sun, 23:51–00:20) while the timetable runs the identical weekday trip `9` that night; `595043:2310` likewise. Weekday `n` and weekend `300 + n` have identical times | taken literally (as DUK-Q3): `not_in_service`, no realtime. Not handled; a twin rule (bind `n` ↔ `300 + n` when only the twin runs at that time) is the candidate fix; DPMD numbers its weekend twins the same way (DPMD-Q7) |
 | DUK-Q17 | DPmÚL trip numbers absent from the release: `595042:201`, `595046:512` (2026-10-09 night; lines 42 and 46 have only 1–14 and 301–314) | `no_trip`. Not investigated: probably a temporary or diversion JDF version missing from the national export or dropped by `merge-jdf` |
 | DUK-Q18 | the onboard unit misses a departure: State 3 all through the trip, `TODepartureDT` already the same departure on the next run day, `StationNode` frozen (vehicle 177, 2026-10-10: `582803:206` of 00:54 driven about 3 min late, `TODepartureDT` 2026-10-11 00:54) | running once, after the scheduled start, the source plans the same wall-clock departure on a later day and the vehicle is on the trip's path past the first stop; the source delay stays ignored while it says State 2/3, delays come from GPS. Applies to every source: a vehicle driving its trip is never left without realtime |