QA: what #186 shipped — NDW traffic: is it worth wiring in? #251

Closed
opened 2026-09-01 01:28:10 +00:00 by viberfox-agent · 2 comments
Collaborator

Issue #186 (“NDW traffic: 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.

Issue #186 (“NDW traffic: 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. <sub>Filed by the autopilot. <!-- autopilot:qa-reverify-186 --></sub>
Author
Collaborator

🤖 Picked this up — working on branch feat/251-qa-what-186-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/251-qa-what-186-shipped` in a fresh worktree on the VPS. I'll report back here when I'm done. <sub>Label an issue `agent:skip` to keep me off it, or `driven` to keep it in a session you are driving.</sub>
Author
Collaborator

Issue #186 shipped a research note, not a feature — it checked the Dutch traffic-measurement feeds and decided not to use them. So I re-ran its measurements against the live feeds and separately checked that the invented traffic it chose to keep still works. The decision holds up. I changed no code and made no commits.

What held

The coverage table the whole decision rests on reproduces exactly, three days later — same counts, same nearest distances:

Point ≤260 m ≤390 m ≤1 km nearest
Groningen, Grote Markt 0 4 20 311 m
Amsterdam, Dam 0 0 4 919 m
Utrecht, Domplein 0 0 0 1942 m
Rotterdam, Coolsingel 2 4 12 106 m
A2 south of Utrecht 0 2 30 368 m

Also confirmed: 20,519 reporting sites; no area query (a bbox parameter returns a byte-identical file); /api/ and /ogc/v1 both answer 404; no road identifier to join on anywhere in the 390 MB site table; the licence is unrestricted; the travel-time feed is 80,756 sites with no vehicle counts in it at all. The code the note cites is accurate — cars are placed within 260 m and recycled at 390 m, and the pool is 180.

The invented traffic works: a headless capture over the Grote Markt reports 180 cars and 220 pedestrians placed and visible. The traffic tests pass (6 of 6), and the full client suite passes (820 tests, 0 failures).

What I filed

  • #252 — the note recommends the incident feed and defers it to "a different frontier row", but no such row exists in docs/direction.md. A source someone already measured is recorded only inside a note headed "not taken".
  • #253 — two of the note's recommendation figures are single readings taken one Saturday evening. Re-measured on a Tuesday night, the share of incidents carrying a plain coordinate is 35% (the note implies the location table is unnecessary), and travel-time reporting is 56% against the note's 92.5%. The structural claims all reproduce; only the coverage percentages move. This is probably a day/night effect rather than an error, which is exactly why the hour needs recording.
  • #254 — the note rejects the feed on the grounds that replacing the invented cars would empty every street, which is true. It never says whether adding measurement where loops exist was considered, though its own numbers support it and the guiding value is "add, don't replace".

What I could not check

Both figures in #253 need one re-reading at a weekday daytime hour; I cannot reach that hour from here. The account-gated interfaces still need a credential nobody has. Colour and lighting in the capture are not evidence — this machine renders on the processor, not a graphics card.

No commits were made.


🤖 viberfox issue agent on the VPS — 71 turns · $5.57 · session 6e74935c-8d13-43f8-8e7b-96eae9bed0d6. Reply with @agent to continue this session.

Issue #186 shipped a research note, not a feature — it checked the Dutch traffic-measurement feeds and decided not to use them. So I re-ran its measurements against the live feeds and separately checked that the invented traffic it chose to keep still works. **The decision holds up. I changed no code and made no commits.** ## What held The coverage table the whole decision rests on **reproduces exactly**, three days later — same counts, same nearest distances: | Point | ≤260 m | ≤390 m | ≤1 km | nearest | |---|---|---|---|---| | Groningen, Grote Markt | 0 | 4 | 20 | 311 m | | Amsterdam, Dam | 0 | 0 | 4 | 919 m | | Utrecht, Domplein | 0 | 0 | 0 | 1942 m | | Rotterdam, Coolsingel | 2 | 4 | 12 | 106 m | | A2 south of Utrecht | 0 | 2 | 30 | 368 m | Also confirmed: 20,519 reporting sites; no area query (a `bbox` parameter returns a byte-identical file); `/api/` and `/ogc/v1` both answer 404; no road identifier to join on anywhere in the 390 MB site table; the licence is unrestricted; the travel-time feed is 80,756 sites with no vehicle counts in it at all. The code the note cites is accurate — cars are placed within 260 m and recycled at 390 m, and the pool is 180. The invented traffic works: a headless capture over the Grote Markt reports **180 cars and 220 pedestrians placed and visible**. The traffic tests pass (6 of 6), and the full client suite passes (820 tests, 0 failures). ## What I filed - **#252** — the note recommends the incident feed and defers it to "a different frontier row", but no such row exists in `docs/direction.md`. A source someone already measured is recorded only inside a note headed "not taken". - **#253** — two of the note's recommendation figures are single readings taken one Saturday evening. Re-measured on a Tuesday night, the share of incidents carrying a plain coordinate is 35% (the note implies the location table is unnecessary), and travel-time reporting is 56% against the note's 92.5%. The structural claims all reproduce; only the coverage percentages move. This is probably a day/night effect rather than an error, which is exactly why the hour needs recording. - **#254** — the note rejects the feed on the grounds that *replacing* the invented cars would empty every street, which is true. It never says whether *adding* measurement where loops exist was considered, though its own numbers support it and the guiding value is "add, don't replace". ## What I could not check Both figures in #253 need one re-reading at a weekday daytime hour; I cannot reach that hour from here. The account-gated interfaces still need a credential nobody has. Colour and lighting in the capture are not evidence — this machine renders on the processor, not a graphics card. _No commits were made._ --- <sub>🤖 viberfox issue agent on the VPS — 71 turns · $5.57 · session `6e74935c-8d13-43f8-8e7b-96eae9bed0d6`. Reply with **@agent** to continue this session.</sub>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
jeroen/cartopolis#251
No description provided.