Add to_review/ with the 34 draft issues for map-search

Nothing filed yet - these are for review. Regenerate with
  uv run python scripts/gen_issues.py to_review

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: NoamGaash

to_review/00-VERIFICATION.md

@@ -0,0 +1,25 @@
+# Live re-verification, 2026-08-01 (before filing)
+
+| Defect | Result | Evidence |
+|---|---|---|
+| A `total_actual_rides` = 0 | CONFIRMED | group_by, 4 dates: planned 121420/122088/53260/27327, actual 0/0/0/0 |
+| B `route_short_name` ignored | CONFIRMED | 400 rows / 202 line_refs identical filtered vs unfiltered |
+| E `actual_start_time` is a flag | CONFIRMED | 676 rows with both: 676 identical, 0 differing |
+| E2 unplanned rides (planned null) | CONFIRMED, rate lower | 1.4% (write-up said 3-6%) |
+| G1 route_timetable >1 day | CONFIRMED | 1-day OK; 3-day -> 500 |
+| G3 row cap 15k/20k | CONFIRMED | 15000 OK; 20000 -> 500 |
+| G4 silent default page size | CONFIRMED, varies | agg/list 1000, gtfs_routes 100, agencies 36 |
+| H naive datetime | CONFIRMED | 500 Internal Server Error |
+
+## Corrections to the hackathon write-ups (do NOT quote the old numbers)
+
+1. orion's planned totals (3,498 / 3,510 / 3,227 / 3,927) were computed from
+   `/gtfs_rides_agg/list` WITHOUT an explicit limit, so they are truncated
+   samples of the default 1000-row page, not network totals. Real network
+   planned totals via group_by are ~27k-122k. The actual=0 conclusion is
+   unaffected and holds at every page size and via group_by.
+2. The default page size is 1000 for /gtfs_rides_agg/list and 100 for
+   /gtfs_routes/list - it varies per endpoint. The source repo's "~100 rows"
+   was right for one endpoint, not universally.
+3. Unplanned-ride rate measured at 1.4% on line 480 (write-up said 3-6% on
+   line 2259). Both may be true per-line; quote as "1-6%, line-dependent".

to_review/01-dashboard-charts-show-0-actual-rides-totalactualrides-is-unp.md

@@ -0,0 +1,86 @@
+# Dashboard charts show ~0% actual rides — `total_actual_rides` is unpopulated upstream
+
+> ### ⚠️ AI-generated draft — needs human validation
+>
+> This issue was **written by an AI agent** from materials produced during the
+> hasadna Open Bus hackathon (July 2026). The underlying analysis was built fast,
+> under hackathon conditions, and **has not been peer-reviewed**. Figures,
+> endpoint behaviour and conclusions all need independent verification before
+> anyone acts on them or quotes them publicly.
+>
+> **Please validate before implementing. Corrections very welcome.**
+
+## Symptom
+
+`totalActualRides` is consumed in five places, all fed by `useGroupBy` →
+`/gtfs_rides_agg/group_by` (`src/api/groupByService.ts`):
+
+- `src/pages/dashboard/AllLineschart/AllLinesChart.tsx`
+- `src/pages/dashboard/WorstLinesChart/WorstLinesChart.tsx`
+- `src/pages/dashboard/ArrivalByTimeChart/DayTimeChart.tsx`
+- `src/pages/operator/OperatorGaps.tsx`
+- `src/pages/DataResearch/DataResearch.tsx`
+
+That column is **0 for every row, network-wide**. The rendered result is not an
+empty state — it is a confident chart showing that essentially no bus in Israel ran.
+
+Here is the same defect reproduced on the hackathon dashboard, which uses the
+same endpoint. Note the flat `Actual` series and the caption *"Overall 0.0% of
+planned rides were observed"*:
+
+![Planned vs actual rides — Actual is flat at zero](https://raw.githubusercontent.com/hasadna/open-bus-hackathon-26/main/algorithms/img/service-by-operator.png)
+
+*Planned vs actual rides — Actual is flat at zero — screenshot of the hackathon dashboard card.*
+
+## Evidence
+
+*Re-verified against the live Stride API on 2026-08-01 immediately before filing; the reproduction below is the exact check that was run.*
+
+```python
+from openbus_hack import stride
+for d in ["2026-07-01", "2026-06-15", "2026-04-01", "2025-11-01"]:
+    rows = stride.get("/gtfs_rides_agg/group_by",
+                      {"date_from": d, "date_to": d,
+                       "group_by": "operator_ref,gtfs_route_date"})
+    print(d, sum(r["total_planned_rides"] or 0 for r in rows),
+             sum(r["total_actual_rides"] or 0 for r in rows))
+```
+
+| Date | Σ `total_planned_rides` | Σ `total_actual_rides` |
+|---|---|---|
+| 2026-07-01 | 121,420 | **0** |
+| 2026-06-15 | 122,088 | **0** |
+| 2026-04-01 | 53,260 | **0** |
+| 2025-11-01 | 27,327 | **0** |
+
+**This is not ingestion lag.** Control: line 2259 on 2026-07-29 reports
+`total_actual_rides = 0` in the aggregate, while `/rides_execution/list` for the
+same line and date returns real `actual_start_time` values and zero
+cancellations. Actuals exist at ride level; they are not being rolled into the
+aggregate.
+
+`num_planned_rides` is populated and cross-checks well against the ride-level
+endpoint, so the aggregate remains usable **as a planned-ride denominator**.
+
+## Upstream
+
+Root cause belongs to the API/ETL — hasadna/open-bus-stride-api#49 reports the
+same thing for a single date (2025-09-17); the evidence above extends it to nine
+months, network-wide, with a control. This issue tracks the **frontend symptom**.
+
+Closely related: #24 (better indication of partial data in the UI) — that is the
+general ask; this is one concrete, currently-live instance of it.
+
+## Suggested interim mitigation
+
+Until the upstream column is fixed, detect
+`totalActualRides === 0 && totalPlannedRides > 0` across a whole response and show
+a data-quality banner instead of plotting a zero series.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — analysis by the hackathon team.
+· Method, evidence and caveats: [`algorithms/service-by-operator.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/service-by-operator.md)
+· Original work: https://github.com/hasadna/open-bus-hackathon-26
+· Issue drafts and the full defect list: [`algorithms/upstream-issues.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/upstream-issues.md)

to_review/02-stride-api-sirivehiclelocationslist-accepts-gtfsrouteroutesh.md

@@ -0,0 +1,64 @@
+# `stride-api:` `/siri_vehicle_locations/list` accepts `gtfs_route__route_short_name` and silently ignores it
+
+> ### ⚠️ AI-generated draft — needs human validation
+>
+> This issue was **written by an AI agent** from materials produced during the
+> hasadna Open Bus hackathon (July 2026). The underlying analysis was built fast,
+> under hackathon conditions, and **has not been peer-reviewed**. Figures,
+> endpoint behaviour and conclusions all need independent verification before
+> anyone acts on them or quotes them publicly.
+>
+> **Please validate before implementing. Corrections very welcome.**
+
+## What happens
+
+Passing `gtfs_route__route_short_name` to `/siri_vehicle_locations/list` does not
+filter. It does not error, does not warn, and does not return an empty set — it
+returns **every ping in the time window, from every line in the country**, which
+the caller then treats as belonging to their line.
+
+## Evidence
+
+*Re-verified against the live Stride API on 2026-08-01 immediately before filing; the reproduction below is the exact check that was run.*
+
+```python
+base = {"recorded_at_time_from": "2026-07-28T08:00+03:00",
+        "recorded_at_time_to":   "2026-07-28T09:00+03:00", "limit": 400}
+unfiltered = stride.get("/siri_vehicle_locations/list", base)
+filtered   = stride.get("/siri_vehicle_locations/list",
+                        {**base, "gtfs_route__route_short_name": "23"})
+```
+
+| Query | rows | distinct `siri_route__line_ref` |
+|---|---|---|
+| unfiltered | 400 | **202** |
+| with `gtfs_route__route_short_name=23` | 400 | **202** |
+
+Byte-identical result sets. The parameter has no effect.
+
+## Why it matters
+
+How it was originally caught: an off-route analysis reported buses **50 km from
+their route on 97.7% of pings**. The buses were fine — the pings belonged to other
+lines. That was only obvious because the number was absurd. Anything computing a
+rate, a median or a coverage percentage gets a **plausible wrong answer** with no
+indication anything went wrong. Two hackathon participants hit this independently.
+
+The working filter is `siri_routes__line_ref` (a `line_ref`, not a
+`route_short_name`), which requires resolving through `/gtfs_routes/list` first.
+
+## Requested
+
+Either apply the filter, or reject the parameter with a 4xx. Silently ignoring a
+filter is the worst of the three options.
+
+Possibly the same class of bug as hasadna/open-bus-stride-api#23 (closed), where
+`/siri_rides/list` did not join on `line_ref`/`operator_ref`.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — analysis by the hackathon team.
+· Method, evidence and caveats: [`algorithms/route-divergence.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/route-divergence.md)
+· Original work: https://github.com/hasadna/open-bus-hackathon-26
+· Issue drafts and the full defect list: [`algorithms/upstream-issues.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/upstream-issues.md)

to_review/03-pipelines-sirigtfs-ride-matching-has-written-no-matches-sinc.md

@@ -0,0 +1,55 @@
+# `pipelines:` SIRI→GTFS ride-matching has written no matches since 2024-10
+
+> ### ⚠️ AI-generated draft — needs human validation
+>
+> This issue was **written by an AI agent** from materials produced during the
+> hasadna Open Bus hackathon (July 2026). The underlying analysis was built fast,
+> under hackathon conditions, and **has not been peer-reviewed**. Figures,
+> endpoint behaviour and conclusions all need independent verification before
+> anyone acts on them or quotes them publicly.
+>
+> **Please validate before implementing. Corrections very welcome.**
+
+## What happens
+
+Two related symptoms, observed independently by two hackathon projects.
+
+**1. The ride link.** `siri_ride.gtfs_ride_id` and its three siblings
+(`route_gtfs_ride_id`, `scheduled_time_gtfs_ride_id`, `journey_gtfs_ride_id`) stop
+being populated together. Reported as healthy through 2024-08, degrading 2024-09,
+effectively zero 2024-10 → 2026-07. The raw feed never stopped — roughly 2.9–3.1M
+`siri_ride` rows per month are still created.
+
+**2. The enrichment.** `siri_ride.first_vehicle_location_id` reported null for
+100% of rides across 18 consecutive months (2024-12 → 2026-05, ~49.4M rides), with
+`duration_minutes` tracking the same pattern.
+
+A hackathon analysis independently found these columns *"inconsistently NULL —
+present for some days, absent for others, for identical, genuinely-tracked
+rides"*, and had to derive planned-vs-actual from raw GPS pings instead.
+
+## Interpretation risk worth flagging separately
+
+`first_vehicle_location_id` **looks** like it means "this vehicle never reported
+its position", and it is easy to build a per-operator transmission metric on it.
+It does not mean that — it encodes **whether the enrichment job has processed that
+day**. It is a processing-state flag, not a property of the bus.
+
+## Confidence
+
+The 18-month and 21-month figures come from a separate hackathon project
+(BusAnalysis by lihay7) whose repository is currently private, so **the census
+numbers cannot be independently checked from this issue alone.** What *was*
+reproduced in the shared hackathon repo is the qualitative finding: these columns
+are unreliable enough that every planned-vs-actual analysis had to bypass them.
+
+Treat the precise dates and percentages as **needing confirmation against the
+database** before anyone acts on them.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — analysis by lihay7.
+· Method, evidence and caveats: [`algorithms/service-violations.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/service-violations.md)
+· Original work: https://github.com/lihay7/BusAnalysis *(private repo — ask the owner for access)*
+· Issue drafts and the full defect list: [`algorithms/upstream-issues.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/upstream-issues.md)

to_review/04-stride-db-duplicate-siriride-journeys-and-repeated-location.md

@@ -0,0 +1,61 @@
+# `stride-db:` duplicate `siri_ride` journeys and repeated location rows
+
+> ### ⚠️ AI-generated draft — needs human validation
+>
+> This issue was **written by an AI agent** from materials produced during the
+> hasadna Open Bus hackathon (July 2026). The underlying analysis was built fast,
+> under hackathon conditions, and **has not been peer-reviewed**. Figures,
+> endpoint behaviour and conclusions all need independent verification before
+> anyone acts on them or quotes them publicly.
+>
+> **Please validate before implementing. Corrections very welcome.**
+
+## What happens
+
+**Ride level.** The same physical journey is stored more than once. Reported at
+3.93% of rides sitting in a duplicated `(siri_route_id, journey_ref, service day)`
+group and 2.56% of all rows being surplus duplicates, over a full census of
+~116.3M rows — 66× skewed across operators, and roughly quadrupling from 2023 to
+2026. Attributed to `scheduled_start_time` drift: when a journey's scheduled start
+drifts, a **new** row is written rather than the existing one updated.
+
+**The same shape appears in GTFS.** On 2026-07-26 one line returned 259
+`/rides_execution/list` rows for 127 distinct `planned_start_time`s (some ×4)
+under 255 distinct `gtfs_ride_id`s — one physical departure emitted under several
+ride ids. Any naive count of planned rides double-counts, and a duplicated row
+with a null actual becomes a phantom cancellation.
+
+**Location level.** Overlapping SIRI snapshots repeat the same physical
+observation — same `siri_ride__id`, same `recorded_at_time`, same lat/lon — at
+roughly 10% of rows. Harmless for `min()`/`max()` aggregations; **not** harmless
+for anything weighted or counted. One hackathon analysis computes a
+distance-weighted average position, where a duplicated ping carries its weight
+twice and drags the result.
+
+## Evidence of the workaround spreading
+
+Every analysis in the hackathon repo now dedups on
+`(siri_ride__id, recorded_at_time, lat, lon)` as a matter of course:
+
+```python
+pings = pings.drop_duplicates(
+    subset=["siri_ride__id", "recorded_at_time", "lat", "lon"])
+```
+
+That is a workaround every consumer is independently reinventing, which is the
+strongest argument for fixing it at the source.
+
+## Confidence
+
+The ride-level census figures come from a hackathon project (BusAnalysis by
+lihay7) whose repository is currently private — **treat them as needing
+confirmation.** The GTFS duplicate-departure observation and the ~10% duplicate
+ping rate were reproduced in the shared hackathon repo.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — analysis by lihay7.
+· Method, evidence and caveats: [`algorithms/days-with-no-cancellations.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/days-with-no-cancellations.md)
+· Original work: https://github.com/lihay7/BusAnalysis *(private repo — ask the owner for access)*
+· Issue drafts and the full defect list: [`algorithms/upstream-issues.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/upstream-issues.md)

to_review/05-stride-api-ridesexecutionactualstarttime-always-equals-plann.md

@@ -0,0 +1,61 @@
+# `stride-api:` `rides_execution.actual_start_time` always equals `planned_start_time`
+
+> ### ⚠️ AI-generated draft — needs human validation
+>
+> This issue was **written by an AI agent** from materials produced during the
+> hasadna Open Bus hackathon (July 2026). The underlying analysis was built fast,
+> under hackathon conditions, and **has not been peer-reviewed**. Figures,
+> endpoint behaviour and conclusions all need independent verification before
+> anyone acts on them or quotes them publicly.
+>
+> **Please validate before implementing. Corrections very welcome.**
+
+## What happens
+
+`actual_start_time` never carries an observed departure time. Where both fields
+are present, it is byte-identical to `planned_start_time`.
+
+## Evidence
+
+*Re-verified against the live Stride API on 2026-08-01 immediately before filing; the reproduction below is the exact check that was run.*
+
+Line 480, all resolved `line_ref` variants, 2026-07-15 → 2026-07-29:
+
+| | count |
+|---|---|
+| rows with **both** planned and actual | 676 |
+| `actual_start_time == planned_start_time` | **676** |
+| `actual_start_time != planned_start_time` | **0** |
+| cancelled (`actual_start_time` null) | 4 |
+| unplanned (`planned_start_time` null) | 10 (1.4% of rows) |
+
+## Why this still matters
+
+The field is genuinely useful as-is — null means the ride did not run, which is
+the cleanest cancellation signal in the API, and a working
+days-without-cancellations score was built on exactly that. But the **name
+promises an observed departure time and it is not one**, so the endpoint can never
+be used for delay or punctuality work.
+
+## Requested
+
+Either populate it from SIRI, or rename/document it as a `did_run`-style boolean
+so nobody builds a punctuality metric on it.
+
+Related: #19 (improve rides reliability metric by adding "actual start time" ETL)
+— that issue is arguably the fix for this one.
+
+## Note on a possibly-related closed issue
+
+hasadna/open-bus-stride-api#54 (`rides_execution/list` used UTC midnight instead of
+Israel midnight) is closed. The hackathon code still carries a client-side
+re-filter working around fuzzy service-date boundaries; if #54's fix shipped, that
+workaround may now be unnecessary. Worth confirming.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — analysis by Broundal.
+· Method, evidence and caveats: [`algorithms/days-with-no-cancellations.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/days-with-no-cancellations.md)
+· Original work: https://github.com/hasadna/open-bus-hackathon-26/tree/main/orion
+· Issue drafts and the full defect list: [`algorithms/upstream-issues.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/upstream-issues.md)