Add 21 phase-2 issue drafts for review (#35-#55)

Covers the three standalone dashboards, the never-ported notebooks, the reusable
infrastructure, and the public-appeal update. Not yet filed.

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

Author: NoamGaash

scripts/gen_issues_phase2.py

@@ -0,0 +1,46 @@
+> ### ⚠️ 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
+
+The hackathon produced a full bunching dashboard that works today and is not
+reachable from דאטאבוס. Link or embed it as a first step, while the individual
+charts get ported natively (#36–#40).
+
+![Headline and KPI tiles](https://raw.githubusercontent.com/hasadna/open-bus-hackathon-26/main/algorithms/img/dashboards/bunch-header-kpis.png)
+
+*Headline and KPI tiles*
+
+**709 line-directions · 138,716 rides · 127,754 consecutive pairs**, over 5 term-time weekdays (2026-05-13 → 06-14). Source: SIRI vehicle telemetry joined to the GTFS timetable.
+
+Headline numbers: **9.9% of consecutive pairs ran bunched** (12,674 nose-to-tail),
+**13% were already bunched leaving the terminal**, **50% of the route is ridden
+bunched** on average, worst line 4 (דן) at 32%.
+
+## Where
+
+`/gaps_patterns` is the natural home, or a link from the dashboard page.
+
+## Caveats to carry across
+
+It is a **fixed 5-day sample**, not a live view — the page states its own window,
+and any link should too. The "grow the sample" button needs the original
+hackathon server and will fail politely if the page is served standalone.
+
+The page is **self-contained** — download it and open it in a browser, or run `./dev` in the hackathon repo and visit the path directly. No server, no build, no credentials.
+
+File: [`frontend/public/bunching-reasons.html`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/frontend/public/bunching-reasons.html)
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — the hackathon team.
+· Source material, republished with the participants' permission: [`source-material/`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/source-material/README.md)
+· Per-solution write-ups: [`bus-bunching.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/bus-bunching.md)

to_review/35-surface-the-where-the-buses-bunch-dashboard.md

@@ -0,0 +1,47 @@
+> ### ⚠️ 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
+
+The single most valuable thing in the bunching dashboard, and nothing comparable
+exists in דאטאבוס: **every bunching event attributed to a cause.**
+
+![Share of all bunching events by cause](https://raw.githubusercontent.com/hasadna/open-bus-hackathon-26/main/algorithms/img/dashboards/bunch-why-decomposition.png)
+
+*Share of all bunching events by cause*
+
+| Cause | Share | Meaning |
+|---|---|---|
+| **Late departure** | 13% | Already bunched leaving the terminal — the leader left late, the follower left early, or the timetable left no gap |
+| **First 20% of route** | 10% | Left with a healthy gap, collapsed within the first fifth |
+| **En route** | 73% | Collapsed after the 20% mark — classic traffic-and-dwell feedback |
+| **Origin outside area** | rest | Entered the observed area already bunched; onset not visible |
+
+## Why it matters
+
+It separates problems with **different owners**. 13% born at the terminal is a
+dispatch and timetabling problem the operator can fix this week. 73% en route is a
+road-priority and dwell-time problem that needs infrastructure. Publishing a single
+"bunching rate" hides that split and points everyone at the wrong lever.
+
+## Suggested next step
+
+Per-operator and per-corridor breakdowns of the same split. An operator whose
+bunching is mostly terminal-born is failing at something entirely different from
+one whose bunching is mostly en route.
+
+**709 line-directions · 138,716 rides · 127,754 consecutive pairs**, over 5 term-time weekdays (2026-05-13 → 06-14). Source: SIRI vehicle telemetry joined to the GTFS timetable.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — the hackathon team.
+· Source material, republished with the participants' permission: [`source-material/`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/source-material/README.md)
+· Per-solution write-ups: [`bus-bunching.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/bus-bunching.md)

to_review/36-port-why-buses-bunch-attribute-every-event-to-a-cause.md

@@ -0,0 +1,52 @@
+> ### ⚠️ 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
+
+Two rider-facing measures from the bunching dashboard that the current metrics
+miss entirely.
+
+**Effective gap** — when two buses arrive nose-to-tail they are one arrival from a
+passenger's point of view. Counting them as two makes the service look twice as
+frequent as it is.
+
+**Actual wait vs planned wait** — the honest cost of that. Examples from the
+ranked table:
+
+| Line | Planned gap | Effective gap | Planned wait | **Actual wait** |
+|---|---|---|---|---|
+| 4 (דן) | 7 min | 9 min | 3.5 min | **7.9 min** |
+| 18 | 10 min | 12 min | 4.8 min | **9.0 min** |
+| 142 | 13 min | 15 min | 6.5 min | **11.5 min** |
+
+![Planned vs effective gap and planned vs actual wait, per line](https://raw.githubusercontent.com/hasadna/open-bus-hackathon-26/main/algorithms/img/dashboards/bunch-ranked-table.png)
+
+*Planned vs effective gap and planned vs actual wait, per line*
+
+## Why it matters
+
+**Riders on line 4 wait more than twice as long as the timetable implies** — 7.9
+minutes against 3.5. That gap is invisible in any punctuality metric, because the
+buses may all be individually "on time". It is the number a passenger would
+recognise as their own experience.
+
+## Suggested next step
+
+Publish actual-wait alongside planned-wait everywhere frequency is shown, and
+consider it as a headline service metric in its own right.
+
+**709 line-directions · 138,716 rides · 127,754 consecutive pairs**, over 5 term-time weekdays (2026-05-13 → 06-14). Source: SIRI vehicle telemetry joined to the GTFS timetable.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — the hackathon team.
+· Source material, republished with the participants' permission: [`source-material/`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/source-material/README.md)
+· Per-solution write-ups: [`bus-bunching.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/bus-bunching.md)

to_review/37-port-planned-gap-vs-effective-gap-and-what-riders-actually-w.md

@@ -0,0 +1,41 @@
+> ### ⚠️ 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
+
+Clicking a line in the bunching dashboard draws its **Marey diagram** — every ride
+as a path down the route, so bunching is visible as converging lines.
+
+## Relationship to #1783
+
+#1783 proposes a Marey diagram from the live-card analysis, which samples **up to
+60 rides** over a ≤10-day window. This one is drawn from **138,716 rides**. Same
+visual grammar, very different evidential weight — worth building once, with the
+data source configurable.
+
+## Why it matters
+
+A Marey diagram is the only chart where bunching is *self-evident* rather than
+inferred: two trajectories converging and then travelling together is the
+phenomenon itself, not a statistic about it.
+
+## Suggested next step
+
+Overlay the cause attribution from #36 — colour each convergence by whether it was
+terminal-born or en-route — so the diagram explains itself.
+
+**709 line-directions · 138,716 rides · 127,754 consecutive pairs**, over 5 term-time weekdays (2026-05-13 → 06-14). Source: SIRI vehicle telemetry joined to the GTFS timetable.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — the hackathon team.
+· Source material, republished with the participants' permission: [`source-material/`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/source-material/README.md)
+· Per-solution write-ups: [`bus-bunching.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/bus-bunching.md)

to_review/38-port-per-line-marey-diagram-over-the-full-bunching-dataset.md

@@ -0,0 +1,43 @@
+> ### ⚠️ 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
+
+The navigational layer of the bunching dashboard: **602 line-directions with at
+least 30 pairs**, ranked, filterable by city / operator / line, with a
+pairs-by-hour histogram driving a time filter.
+
+![Pairs by hour, with city, operator and line filters](https://raw.githubusercontent.com/hasadna/open-bus-hackathon-26/main/algorithms/img/dashboards/bunch-hour-and-filters.png)
+
+*Pairs by hour, with city, operator and line filters*
+
+Columns: planned gap · effective gap · pairs · bunched % · cause split as a stacked
+bar · planned wait · actual wait · late-start caused · route ridden bunched.
+
+## Why it matters
+
+The cause split renders **inline per row**, so a reader scanning the table sees
+immediately that two lines with the same 26% bunching rate have completely
+different causes. That is the design idea worth copying, more than the table
+itself.
+
+## Suggested next step
+
+CSV export, and a permalink that encodes the active filters so a finding can be
+cited.
+
+**709 line-directions · 138,716 rides · 127,754 consecutive pairs**, over 5 term-time weekdays (2026-05-13 → 06-14). Source: SIRI vehicle telemetry joined to the GTFS timetable.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — the hackathon team.
+· Source material, republished with the participants' permission: [`source-material/`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/source-material/README.md)
+· Per-solution write-ups: [`bus-bunching.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/bus-bunching.md)

to_review/39-port-bunching-league-table-with-hour-histogram-filters-and-c.md

@@ -0,0 +1,42 @@
+> ### ⚠️ 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
+
+The bunching dashboard opens on a 5-day sample and offers **"add N random
+weekdays"**, which probes the archive for healthy days and loads them in the
+background. The page stays fully usable while they land, and a progress panel
+reports coverage — *"2,880 / 2,880 five-min slices · 100.0%"*.
+
+## Why it matters
+
+It is a direct answer to the cost problem behind half the tickets in this
+milestone. Several analyses take 1–2 minutes per line because they derive data the
+API does not serve. The usual options are a slow page or a small sample; this is a
+third — **start small, stay interactive, deepen in the background, and show the
+reader exactly how much evidence is currently behind the chart.**
+
+## Why it is honest as well as fast
+
+The progress panel doubles as a confidence indicator. A reader looking at a chart
+built from 20% of the intended sample can see that, which is strictly better than
+a chart that looks identical whether it rests on one day or thirty.
+
+## Suggested next step
+
+Apply it first to the cards that currently cap their windows for cost reasons —
+segment reliability (#1782), schedule adherence (#1785) and bunching (#1790).
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — the hackathon team.
+· Source material, republished with the participants' permission: [`source-material/`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/source-material/README.md)
+· Per-solution write-ups: [`bus-bunching.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/bus-bunching.md)

to_review/40-adopt-the-grow-the-sample-incremental-loading-pattern.md

@@ -0,0 +1,46 @@
+> ### ⚠️ 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
+
+Door-to-door bus speed on **every street** of Tel Aviv and the inner ring, by hour
+of day, measured from GPS. It works today and is not reachable from דאטאבוס.
+
+![Network speed, bus-minutes lost, worst corridor, streets with no bus](https://raw.githubusercontent.com/hasadna/open-bus-hackathon-26/main/algorithms/img/dashboards/speed-header-kpis.png)
+
+*Network speed, bus-minutes lost, worst corridor, streets with no bus*
+
+**60,359,656 street readings from 11,559,010 ping pairs**, 10 weekdays (May–June 2026), 97.3% match rate. Source: SIRI telemetry joined to OpenStreetMap geometry.
+
+Headline numbers at 16:00: network bus speed **18.8 km/h**; **33,660 bus-minutes
+lost per hour** against each street's own free-flow speed; worst single corridor
+Geha W-bound at **787 min/hr**; slowest busy street Sderot David Ben Gurion at
+**4.7 km/h**; and **1,308 km of street with no bus at all**.
+
+## Where
+
+`/velocity-heatmap` is the closest existing page, or a link from the map page.
+
+## Note
+
+This also answers **#1231** — the ask to embed a notebook about vehicle velocities
+into the public appeal. This is that research, at national-data scale and already
+interactive.
+
+The page is **self-contained** — download it and open it in a browser, or run `./dev` in the hackathon repo and visit the path directly. No server, no build, no credentials.
+
+File: [`frontend/public/tlv-bus-speed.html`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/frontend/public/tlv-bus-speed.html)
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — the hackathon team.
+· Source material, republished with the participants' permission: [`source-material/`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/source-material/README.md)
+· Per-solution write-ups: [`upstream-issues.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/upstream-issues.md)

to_review/41-surface-the-where-the-buses-crawl-street-speed-dashboard.md

@@ -0,0 +1,46 @@
+> ### ⚠️ 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
+
+A street-level choropleth of measured bus speed, switchable between six views:
+**speed · lost minutes · vs free-flow · vs speed limit · buses/hr · coverage**.
+
+![Median bus speed per street, Tel Aviv and the inner ring](https://raw.githubusercontent.com/hasadna/open-bus-hackathon-26/main/algorithms/img/dashboards/speed-map.png)
+
+*Median bus speed per street, Tel Aviv and the inner ring*
+
+Filters: hour of day, city, operator, single line, hide motorways, only streets
+with ≥20 buses/hr, show unserved streets, and a street search.
+
+![Colour mode and filter controls](https://raw.githubusercontent.com/hasadna/open-bus-hackathon-26/main/algorithms/img/dashboards/speed-controls.png)
+
+*Colour mode and filter controls*
+
+## Why six modes rather than one
+
+They answer different questions and disagree usefully. A street can be slow in
+absolute terms but at its own free-flow speed (nothing to fix), or fast in absolute
+terms but far below its limit (something to fix). "vs free-flow" is what isolates
+*congestion* from *street design*.
+
+**60,359,656 street readings from 11,559,010 ping pairs**, 10 weekdays (May–June 2026), 97.3% match rate. Source: SIRI telemetry joined to OpenStreetMap geometry.
+
+## Suggested next step
+
+Extend beyond Tel Aviv. The method is city-agnostic — it needs GTFS, SIRI and OSM
+geometry, all of which exist nationally.
+
+---
+
+**Credit & provenance**
+Found during the hasadna Open Bus hackathon, July 2026 — the hackathon team.
+· Source material, republished with the participants' permission: [`source-material/`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/source-material/README.md)
+· Per-solution write-ups: [`upstream-issues.md`](https://github.com/hasadna/open-bus-hackathon-26/blob/main/algorithms/upstream-issues.md)