The shell answered a real product question
On August 9, 2026, commit 4d48acdc added a temporary demo.tsx route for trip results. The useful question was visual: could a trip read as one continuous object, from the two places entered by the rider to the route, transfer, fare, and map action?
The prototype had a compact planner card, a collapsing results header, a route track, a step-by-step journey, and explicit boarding and alighting places. It also made room for failure states and a fare-type selector. Those are good interface questions. They are different from the question of whether the routing engine can produce the trip shown inside the card.
What the prototype actually ran
The source makes the boundary plain. demo.tsx owns a DATA object with three named scenarios, a FAILURES object with five named failure states, and timers that move the card through searching, calculating, and results. There is no call to the transit graph in that route.
This is a historical, partial excerpt from apps/web/src/app/routes/demo.tsx. It is not runnable against the current application.
"2leg": { totalFare: 28, totalMinutes: 30, legs: [ { id: "ride-1", routeName: "Mintal–Buhangin", routeColor: "var(--route-mintal)", boardAt: "SM City Davao", alightAt: "Victoria Plaza", fare: 15, details: "Jeepney · every 15 min", }, { id: "ride-2", routeName: "Matina–Ulas", routeColor: "var(--route-matina)", boardAt: "Victoria Plaza", alightAt: "Abreeza Ayala Mall", fare: 13, details: "Jeepney · every 10 min", }, ], transfer: { distance: "400 m", minutes: 5 }, from: "SM City Davao", to: "Abreeza Ayala Mall",},The 2leg fixture therefore says that a trip from SM City Davao to Abreeza Ayala Mall costs ₱28, takes 30 minutes, and transfers at Victoria Plaza. The value is useful for checking card hierarchy and line wrapping. It is not a measured route result. The 3leg and single fixtures make the same distinction with different numbers: they exercise longer and direct layouts, not the planner's search space.
The transition was simulated. The historical route waits 2,200 milliseconds before entering calculating, then another 3,500 milliseconds before showing the fixture. That makes the loading state easy to inspect, but it says nothing about graph preparation or search cost. The failure buttons have the same limitation: Edit trip is wired to reset the demo, while Browse routes is rendered without a handler in that source.
The visual shell made placeholders look authoritative
The prototype's visual language encouraged a stronger interpretation than its data supported. A route track and two leg cards made the transfer look real. The fare rows used per-leg values and a student/PWD calculation. The large section is styled as co2Card, but its copy displays the total fare and a student/PWD saving. There is no CO₂ value in the committed source. This page should not call that a measured emissions result.
The fare notice is also fixture copy: “Fares as of March 2025. Base ₱15 + ₱2 per stop after 2.” It belongs to the prototype's presentation, not to the current fare contract. Treating it as fare authority would turn a visual placeholder into a product promise.
That is why the August working notes said not to promote the screen directly. The prototype was valuable because it exposed what a good result should explain before the engine could supply those explanations. Its boundary was easy to miss: once a polished card has named a route, a fare, and a transfer, the reader stops seeing the fixture.
What survived in the current planner
The current planner has a different data path. page.tsx asks getTripPrepareClient().planTrip(request) for a typed result, and trip-result-panel.tsx turns a found trip into the summary, journey legs, and information sections. trip-summary-card.tsx still gives the result a short summary, route track, distance and access values, fare state, and map/save actions. trip-legs-card.tsx carries the boarding, alighting, walking, and transfer sequence.
| Prototype shell | Current product path |
|---|---|
DATA["2leg"], DATA["3leg"], or DATA["single"] | A TripResult returned by the prepared planner client |
| Artificial 2,200 ms and 3,500 ms delays | A shared planner worker and its real loading state |
| Fixture leg names, fares, and transfer distance | Materialized rides, access segments, transfer segments, and fare status |
A visual co2Card slot | Current fare and route information with an explicit data warning when needed |
The retained idea is progression. A rider should understand the result at a glance, expand the journey when the details matter, and take the map action without reconstructing the route from raw data. The rejected idea is that the visual shell can stand in for route authority.
Visual evidence that is still missing
The repository contains the deleted prototype source, but it does not contain a screenshot pair, a recorded browser session, or a checked-in before/after capture for this experiment. The PNGs available elsewhere in the workspace are app icons or unrelated temporary captures, so they are not suitable as published evidence for this page.
The durable before/after example is therefore the source comparison above: hard-coded scenario data and artificial timing on one side, typed planner results and current result components on the other. If the original screen is recovered, add a labeled screenshot beside the current result at the same viewport and keep the source comparison. A Mermaid system diagram would add less evidence than that image.