#230 - QA: what #216 shipped — ProRail Spoorwegen, PDOK OGC API: is it worth wiring in? - jeroen/cartopolis

viberfox-agent commented

2026-08-30 09:55:28 +00:00

Collaborator

Issue #216 (“ProRail Spoorwegen, PDOK OGC API: is it worth wiring in?”) was built and merged by the unattended lane, and nobody has used it. Walk what it delivered as a player would meet it.

This is a QA pass, not a build. Change no code and open no pull request on this
ticket — the deliverables are findings.

Exercise it for real. Run what a player would touch, headlessly: cargo run -p cartopolis_simulator with a client or a wire/HTTP probe for anything online, the
loopback tests, cargo run -p cartopolis -- --shot … --dump-state for anything with
geometry. CLAUDE.md lists every harness. If part of this genuinely needs a screen, a
phone or a microphone, verify the half a machine can reach and name the half it cannot.
Walk the user's journey, not the happy path. At each step ask what a real user
would obviously expect to be able to do next — then try exactly that. A refusal or an
absence that would surprise a user is a finding even when every implemented piece
works: registration worked, claiming a house worked, and a registered account still
could not claim a house. No test failed; a user hit a wall.
File each real gap as its own issue: title starting gap:, label qa-gap, with
what you did, what happened, what a user would expect instead, and where in the code
the seam is. Use the Forgejo API with the FORGEJO_TOKEN in your environment. Do not
label them autonomous — a person decides which gaps become work.
Report and close. Your final message: what you exercised, what held, what you
filed. Nothing found after a genuine pass is a good outcome — say what you checked.
Then close this ticket through the API; a QA pass has no branch to merge.

Decide it yourself. Nobody is watching this ticket; a question asked here is a
ticket that stops. Judge by what a reasonable player would expect, verify before
claiming, and never post credentials or file contents from outside the repository.

_{Filed by the autopilot.}

Issue #216 (“ProRail Spoorwegen, PDOK OGC API: is it worth wiring in?”) was built and merged by the unattended lane, and nobody has used it. Walk what it delivered as a player would meet it. **This is a QA pass, not a build.** Change no code and open no pull request on this ticket — the deliverables are findings. 1. **Exercise it for real.** Run what a player would touch, headlessly: `cargo run -p cartopolis_simulator` with a client or a wire/HTTP probe for anything online, the loopback tests, `cargo run -p cartopolis -- --shot … --dump-state` for anything with geometry. CLAUDE.md lists every harness. If part of this genuinely needs a screen, a phone or a microphone, verify the half a machine can reach and name the half it cannot. 2. **Walk the user's journey, not the happy path.** At each step ask what a real user would obviously expect to be able to do next — then try exactly that. A refusal or an absence that would surprise a user is a finding even when every implemented piece works: registration worked, claiming a house worked, and a registered account still could not claim a house. No test failed; a user hit a wall. 3. **File each real gap as its own issue**: title starting `gap:`, label `qa-gap`, with what you did, what happened, what a user would expect instead, and where in the code the seam is. Use the Forgejo API with the `FORGEJO_TOKEN` in your environment. Do not label them `autonomous` — a person decides which gaps become work. 4. **Report and close.** Your final message: what you exercised, what held, what you filed. Nothing found after a genuine pass is a good outcome — say what you checked. Then close this ticket through the API; a QA pass has no branch to merge. **Decide it yourself.** Nobody is watching this ticket; a question asked here is a ticket that stops. Judge by what a reasonable player would expect, verify before claiming, and never post credentials or file contents from outside the repository. Filed by the autopilot.

viberfox-agent added the

agent

autopilot

qa

labels

2026-08-30 09:55:28 +00:00

viberfox-agent added this to the Viberfox project

2026-08-30 09:55:36 +00:00

viberfox-agent added the

agent:running

label

2026-08-30 09:55:37 +00:00

viberfox-agent commented

2026-08-30 09:55:46 +00:00

Author

Collaborator

🤖 Picked this up — working on branch feat/230-qa-what-216-shipped in a fresh worktree on the VPS. I'll report back here when I'm done.

_{Label an issue agent:skip to keep me off it, or driven to keep it in a session you are driving.}

🤖 Picked this up — working on branch `feat/230-qa-what-216-shipped` in a fresh worktree on the VPS. I'll report back here when I'm done. Label an issue `agent:skip` to keep me off it, or `driven` to keep it in a session you are driving.

viberfox-agent referenced this issue

2026-08-30 10:27:45 +00:00

gap: every level crossing is drawn with its barriers permanently lowered across the road #231

viberfox-agent referenced this issue

2026-08-30 10:27:45 +00:00

gap: on a multi-track crossing one of the two barriers stands between the rails #232

viberfox-agent referenced this issue

2026-08-30 10:27:45 +00:00

gap: a crossing is sized for a 7 m road, so its booms stop short and its masts stand in the carriageway #233

viberfox-agent referenced this issue

2026-08-30 10:27:45 +00:00

gap: you walk and drive straight through a level crossing #234

viberfox-agent referenced this issue

2026-08-30 10:27:45 +00:00

gap: driver mode hides the level crossings, the one mode a crossing is about #235

viberfox-agent referenced this issue

2026-08-30 10:28:59 +00:00

gap: the level-crossing rail gate passes every tile, because rail is a Shortbread attribute key #236

viberfox-agent closed this issue

2026-08-30 10:29:31 +00:00

viberfox-agent commented

2026-08-30 10:29:56 +00:00

Author

Collaborator

No code changed — this was the QA pass the ticket asked for, so the branch feat/230-qa-what-216-shipped has no commits and there is no pull request.

What I ran

cargo test -p cartopolis_geo — 236 passed. cargo test -p cartopolis — 814 passed. All 21 of the level-crossing tests pass.
Fetched the live ProRail service for the Peizerweg cell in Groningen. It answers exactly what the captured fixture says, including the three traps the commit calls out.
Rendered the Peizerweg crossing headlessly from 60 m, 25 m and 7 m, against the live register and the real vector basemap. Both high captures settle and report 3 crossings drawn. (The shot harness does work in this container — lavapipe is installed. The instruction that it does not is out of date.)
Measured the actual track and road layout at that crossing against OpenStreetMap.
Sampled 64 map tiles over Groningen to see how much the layer's railway pre-filter actually filters.

What held

The hard part works. The booms lie across the road, not along the track — the orientation logic the commit calls its one new piece of reasoning is correct on real data. The coverage rectangle refuses Berlin, Copenhagen, Rennes and Paris and admits all four Dutch corners. The service sends the permissive cross-origin header and an hour of caching, so the browser build can reach it directly as claimed. The attribution reaches both the credits screen and the layer list. Turning the Furniture switch off and on rebuilds the surrounding tiles, so the switch is not dead. Crossings follow measured ground height like the rest of the street furniture.

What I filed (six issues, all labelled `qa-gap`)

#231 — every barrier is drawn permanently lowered across the road. The booms are horizontal boxes at 1.05 m; the module's own note says three times that they stand raised. Visible in all three captures.
#232 — at the Peizerweg the register says one track; OpenStreetMap has a second running track 5.9 m away. The spacing comes only from the register, so one of the two barriers is planted between the two lines and the second track is unguarded.
#233 — every installation is sized for a 7 m road. The Peizerweg is an 11 m road, so the masts stand on the asphalt and each boom covers about 4 m of it.
#234 — nothing on a crossing is solid. You walk and drive through the mast and the lowered boom, while the lamppost beside it is solid.
#235 — driver mode switches street furniture off, so the crossings vanish in the one mode where a barrier across the road means something.
#236 — the railway pre-filter passes 64 tiles out of 64, including the note's own railway-free control cell, because rail is an attribute key present in every map tile. It stops nothing; the coverage rectangle is the only gate that does any work.

Still unverified

Colour, lighting and whether the thing reads as a level crossing — this renderer cannot judge those. The browser and Android builds were not run; only the service's headers were checked.

One thing to know: this worktree's git link was deleted by another session partway through, so git commands here fail with "not a git repository". Nothing was lost — no commits were needed — but the directory needs re-adding before anyone works in it.

No commits were made.

_{🤖 viberfox issue agent on the VPS — 92 turns · $9.97 · session 8453616a-6cbb-4ae5-9c60-e3f0502d89ca. Reply with @agent to continue this session.}

No code changed — this was the QA pass the ticket asked for, so the branch `feat/230-qa-what-216-shipped` has no commits and there is no pull request. ## What I ran - `cargo test -p cartopolis_geo` — 236 passed. `cargo test -p cartopolis` — 814 passed. All 21 of the level-crossing tests pass. - Fetched the live ProRail service for the Peizerweg cell in Groningen. It answers exactly what the captured fixture says, including the three traps the commit calls out. - Rendered the Peizerweg crossing headlessly from 60 m, 25 m and 7 m, against the live register and the real vector basemap. Both high captures settle and report 3 crossings drawn. (The shot harness does work in this container — lavapipe is installed. The instruction that it does not is out of date.) - Measured the actual track and road layout at that crossing against OpenStreetMap. - Sampled 64 map tiles over Groningen to see how much the layer's railway pre-filter actually filters. ## What held The hard part works. The booms lie across the road, not along the track — the orientation logic the commit calls its one new piece of reasoning is correct on real data. The coverage rectangle refuses Berlin, Copenhagen, Rennes and Paris and admits all four Dutch corners. The service sends the permissive cross-origin header and an hour of caching, so the browser build can reach it directly as claimed. The attribution reaches both the credits screen and the layer list. Turning the Furniture switch off and on rebuilds the surrounding tiles, so the switch is not dead. Crossings follow measured ground height like the rest of the street furniture. ## What I filed (six issues, all labelled `qa-gap`) - **#231** — every barrier is drawn permanently lowered across the road. The booms are horizontal boxes at 1.05 m; the module's own note says three times that they stand raised. Visible in all three captures. - **#232** — at the Peizerweg the register says one track; OpenStreetMap has a second running track 5.9 m away. The spacing comes only from the register, so one of the two barriers is planted between the two lines and the second track is unguarded. - **#233** — every installation is sized for a 7 m road. The Peizerweg is an 11 m road, so the masts stand on the asphalt and each boom covers about 4 m of it. - **#234** — nothing on a crossing is solid. You walk and drive through the mast and the lowered boom, while the lamppost beside it is solid. - **#235** — driver mode switches street furniture off, so the crossings vanish in the one mode where a barrier across the road means something. - **#236** — the railway pre-filter passes 64 tiles out of 64, including the note's own railway-free control cell, because `rail` is an attribute key present in every map tile. It stops nothing; the coverage rectangle is the only gate that does any work. ## Still unverified Colour, lighting and whether the thing *reads* as a level crossing — this renderer cannot judge those. The browser and Android builds were not run; only the service's headers were checked. One thing to know: this worktree's git link was deleted by another session partway through, so `git` commands here fail with "not a git repository". Nothing was lost — no commits were needed — but the directory needs re-adding before anyone works in it. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — 92 turns · $9.97 · session `8453616a-6cbb-4ae5-9c60-e3f0502d89ca`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:done

and removed

agent:running

labels

2026-08-30 10:29:57 +00:00

viberfox-agent referenced this issue

2026-08-31 00:41:38 +00:00

Autopilot log #181

viberfox-agent referenced this issue

2026-09-01 00:33:04 +00:00

Autopilot log #181