#266 - QA: what #206 shipped — Rijkswaterstaat vaarwegmarkeringen, PDOK OGC API: is it worth wiring in? - jeroen/cartopolis

viberfox-agent commented

2026-09-02 02:14:43 +00:00

Collaborator

Issue #206 (“Rijkswaterstaat vaarwegmarkeringen, 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 #206 (“Rijkswaterstaat vaarwegmarkeringen, 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-09-02 02:14:43 +00:00

viberfox-agent added this to the Viberfox project

2026-09-02 02:15:08 +00:00

viberfox-agent added the

agent:running

label

2026-09-02 02:15:09 +00:00

viberfox-agent commented

2026-09-02 02:15:16 +00:00

Author

Collaborator

🤖 Picked this up — working on branch feat/266-qa-what-206-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/266-qa-what-206-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-09-02 02:33:37 +00:00

gap: a cell's ground waits on api.pdok.nl before it is tessellated #267

viberfox-agent referenced this issue

2026-09-02 02:42:17 +00:00

gap: with the height layer on, every floating navigation mark sinks #268

viberfox-agent closed this issue

2026-09-02 02:42:32 +00:00

viberfox-agent commented

2026-09-02 02:43:03 +00:00

Author

Collaborator

The buoys and beacons #206 added still draw correctly, and I found two new problems: ticking the height layer sinks every buoy, and the whole map now waits on a third-party server before any cell is drawn. Both are filed. No code changed, no branch pushed.

What I ran

The live register. Queried both Rijkswaterstaat collections at the address the client uses. The cell covering the Waal at Nijmegen returns 30 floating and 13 fixed marks — the 43 the note recorded in August. The service is alive and unchanged.
The client, headless, over the Waal. A settled capture reports 115 marks across the nine streamed cells, matching the 115 in the cache files it wrote. Close-up captures at 6 metres show a red can buoy sitting on the water with its lantern on top, correctly placed in the fairway rather than on the bank.
The tests. cargo test -p cartopolis_geo: 236 passed, 0 failed. cargo test -p cartopolis: 820 passed, 0 failed.
Two silent-failure traps re-checked against live data, not fixtures: the fixed collection really does carry its topmark colour under tt_kleur, and its light colour under licht_kl rather than in the sixteen sector fields. Both reads are correct.

What I filed

#268 — with the height layer on, every floating navigation mark sinks. Same buoy, same camera, only --height differs: the visible part of the can drops from 25 pixels to 11, at identical width, with the far waterline unmoved. The water surface is lifted onto the measured ground by one rule (one level for the whole body) and the buoy by another (per vertex), and over a river the two disagree. Moored boats sit on the same rule and will have the same fault.
#267 — a cell's ground waits on api.pdok.nl before it is tessellated. The navigation-marks fetch is awaited before the tessellation job is submitted, so a cell's ground, roads, water and buildings are all held behind an optional layer's server, two requests deep, each on a 20-second timeout, with nothing cached on failure. Healthy this costs about 0.17 seconds per cell (I timed 18 requests at 1.70 seconds total). Unhealthy it reads as "no map", not "no buoys". The level-crossings layer from #216 copied the same shape.

What I did not file

The lantern never lights at night. It is documented as out of scope, and no member of the street-furniture group emits light, so this is a group-wide property rather than something this layer skipped. The shipping commit says it "is its own ticket" — that ticket does not exist.
Permanent caching with no expiry, and the absence of any continuous-integration check that visits a waterway. Both are how every streamed layer here already works.

Worth knowing

The three gaps the previous pass filed are all still open and unfixed (#212, #213, #215). The fix for the fourth — #214, "you cannot find out what a navigation mark is" — was built and sits in open pull request #229, never merged, so what a player meets today is still a nameless buoy with no row of its own in the Layers panel.

Unverified

Colour fidelity, as before: this container renders in software, so whether a red can reads as red still needs a real screen. I could not fault-inject a slow PDOK server — no root in this container — so the 20-second figure in #267 is the timeout the code inherits, not a stall I measured.

Ticket #266 is closed.

No commits were made.

_{🤖 viberfox issue agent on the VPS — 197 turns · $22.98 · session c8be44cc-7f7c-47ab-b4d9-5091048662fc. Reply with @agent to continue this session.}

The buoys and beacons #206 added still draw correctly, and I found two new problems: ticking the height layer sinks every buoy, and the whole map now waits on a third-party server before any cell is drawn. Both are filed. No code changed, no branch pushed. ## What I ran - **The live register.** Queried both Rijkswaterstaat collections at the address the client uses. The cell covering the Waal at Nijmegen returns 30 floating and 13 fixed marks — the 43 the note recorded in August. The service is alive and unchanged. - **The client, headless, over the Waal.** A settled capture reports 115 marks across the nine streamed cells, matching the 115 in the cache files it wrote. Close-up captures at 6 metres show a red can buoy sitting on the water with its lantern on top, correctly placed in the fairway rather than on the bank. - **The tests.** `cargo test -p cartopolis_geo`: 236 passed, 0 failed. `cargo test -p cartopolis`: 820 passed, 0 failed. - **Two silent-failure traps re-checked against live data**, not fixtures: the fixed collection really does carry its topmark colour under `tt_kleur`, and its light colour under `licht_kl` rather than in the sixteen sector fields. Both reads are correct. ## What I filed - **#268 — with the height layer on, every floating navigation mark sinks.** Same buoy, same camera, only `--height` differs: the visible part of the can drops from 25 pixels to 11, at identical width, with the far waterline unmoved. The water surface is lifted onto the measured ground by one rule (one level for the whole body) and the buoy by another (per vertex), and over a river the two disagree. Moored boats sit on the same rule and will have the same fault. - **#267 — a cell's ground waits on `api.pdok.nl` before it is tessellated.** The navigation-marks fetch is awaited *before* the tessellation job is submitted, so a cell's ground, roads, water and buildings are all held behind an optional layer's server, two requests deep, each on a 20-second timeout, with nothing cached on failure. Healthy this costs about 0.17 seconds per cell (I timed 18 requests at 1.70 seconds total). Unhealthy it reads as "no map", not "no buoys". The level-crossings layer from #216 copied the same shape. ## What I did not file - The lantern never lights at night. It is documented as out of scope, and no member of the street-furniture group emits light, so this is a group-wide property rather than something this layer skipped. The shipping commit says it "is its own ticket" — that ticket does not exist. - Permanent caching with no expiry, and the absence of any continuous-integration check that visits a waterway. Both are how every streamed layer here already works. ## Worth knowing The three gaps the previous pass filed are all still open and unfixed (#212, #213, #215). The fix for the fourth — #214, "you cannot find out what a navigation mark is" — was built and sits in **open pull request #229**, never merged, so what a player meets today is still a nameless buoy with no row of its own in the Layers panel. ## Unverified Colour fidelity, as before: this container renders in software, so whether a red can reads as red still needs a real screen. I could not fault-inject a slow PDOK server — no root in this container — so the 20-second figure in #267 is the timeout the code inherits, not a stall I measured. Ticket #266 is closed. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — 197 turns · $22.98 · session `c8be44cc-7f7c-47ab-b4d9-5091048662fc`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:done

and removed

agent:running

labels

2026-09-02 02:43:03 +00:00

viberfox-agent referenced this issue

2026-09-03 00:47:47 +00:00

Autopilot log #257

viberfox-agent referenced this issue

2026-09-03 00:57:04 +00:00

alreadyFiled only ever sees 50 issues, so every autopilot dedupe key silently expires — #206 was QA'd twice #281