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

viberfox-agent commented

2026-08-30 07:33:39 +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-08-30 07:33:39 +00:00

viberfox-agent added this to the Viberfox project

2026-08-30 07:33:53 +00:00

viberfox-agent added the

agent:running

label

2026-08-30 07:33:53 +00:00

viberfox-agent commented

2026-08-30 07:34:00 +00:00

Author

Collaborator

🤖 Picked this up — working on branch feat/210-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/210-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-08-30 07:56:17 +00:00

gap: the navigation-marks water gate stops nothing inside the Netherlands #212

viberfox-agent referenced this issue

2026-08-30 07:56:53 +00:00

gap: the vaarwegmarkeringen vocabularies are wider than the census the parser was built on #213

viberfox-agent referenced this issue

2026-08-30 07:57:45 +00:00

gap: you cannot find out what a navigation mark is #214

viberfox-agent referenced this issue

2026-08-30 08:05:45 +00:00

gap: a navigation mark is only readable from about mast height, and gone by 450 m #215

viberfox-agent closed this issue

2026-08-30 08:05:54 +00:00

viberfox-agent commented

2026-08-30 08:06:12 +00:00

Author

Collaborator

I ran the QA pass, changed no code, filed four gaps and closed the ticket.

What I exercised

The live register. Queried both Rijkswaterstaat collections at the endpoint the client uses. The Waal cell at Nijmegen returns 30 floating + 13 fixed marks — exactly the 43 the note measured.
The whole path, end to end. Built and ran the client headlessly over the Waal. A settled capture gated with --expect 'settled==true' --expect 'nav_marks>0' exits 0 and reports 115 marks. The 18 cached cell files hold 115 marks between them, so register → parse → cache → decode → mesh → metric all agree.
The picture. Buoys stand in the fairway at the waterline, beacons on the bank. Nothing is sunk, floating or in the wrong place.
The tests. cargo test -p cartopolis_geo: 223 passed, 0 failed. cargo test -p cartopolis: 806 passed, 0 failed.

What held

Everything that was implemented. The MultiPoint geometry, the two different property names for the fixed collection, and the three spellings of "absent" are all read correctly against live data, not just against the fixtures.

What I filed

#212 — the water gate stops nothing inside the Netherlands. 10 of 10 sampled Dutch cells pass it; every one carries a water layer, because the country is drained by ditches. A cold start at the app's own default location (Groningen) sent 18 requests to PDOK and got 18 empty answers. The two tests disagree about Groningen and neither joins the halves. Nothing user-visible — but this is the cost argument the whole design rests on.
#213 — the register's vocabulary is wider than the census it was built on. I censused all 18,474 features instead of the 1,258 sampled. Nationally there are 7 buoy shapes, 26 fixed-mark kinds and 21 colour strings, not 5/14/15. About 130 objects are dropped or drawn with a colour band missing, including a steering light, a leading light and a brown mark. Also: opgeheven really does carry dates on 5 marks, which the note says it never does — the code handles them correctly, the note is what needs fixing.
#214 — you cannot find out what a mark is. Nothing to click, nothing to walk up to, no name, no row of its own in the Layers panel. The register carries the mark's name, its fairway and its light character; all are dropped at parse time. The client already does exactly this for houseboat berths.
#215 — a mark is only readable from about mast height. At 150 m a buoy is a 2–3 pixel speck; at 400 m it is one or two pixels; at 450 m it is hidden. Shape and colour are the datum, and both are gone before the fade even starts.

What I could not check

Colour fidelity. This container renders in software, so whether a red can reads as red still needs a real screen or a phone.

For you to decide

There is no automated check on this layer. The command above works and gates it in one capture, but no continuous integration job runs it — and no other streamed layer has one either, so this is a repository-wide pattern rather than something #206 skipped. I did not file it as a gap.

No branch, no commits, no pull request — the ticket asked for findings only.

No commits were made.

_{🤖 viberfox issue agent on the VPS — 110 turns · $11.20 · session fd73424b-1054-4dd3-bac4-732bd0024536. Reply with @agent to continue this session.}

I ran the QA pass, changed no code, filed four gaps and closed the ticket. ## What I exercised - **The live register.** Queried both Rijkswaterstaat collections at the endpoint the client uses. The Waal cell at Nijmegen returns 30 floating + 13 fixed marks — exactly the 43 the note measured. - **The whole path, end to end.** Built and ran the client headlessly over the Waal. A settled capture gated with `--expect 'settled==true' --expect 'nav_marks>0'` exits 0 and reports **115 marks**. The 18 cached cell files hold 115 marks between them, so register → parse → cache → decode → mesh → metric all agree. - **The picture.** Buoys stand in the fairway at the waterline, beacons on the bank. Nothing is sunk, floating or in the wrong place. - **The tests.** `cargo test -p cartopolis_geo`: 223 passed, 0 failed. `cargo test -p cartopolis`: 806 passed, 0 failed. ## What held Everything that was implemented. The `MultiPoint` geometry, the two different property names for the fixed collection, and the three spellings of "absent" are all read correctly against live data, not just against the fixtures. ## What I filed - **#212 — the water gate stops nothing inside the Netherlands.** 10 of 10 sampled Dutch cells pass it; every one carries a water layer, because the country is drained by ditches. A cold start at the app's own default location (Groningen) sent 18 requests to PDOK and got 18 empty answers. The two tests disagree about Groningen and neither joins the halves. Nothing user-visible — but this is the cost argument the whole design rests on. - **#213 — the register's vocabulary is wider than the census it was built on.** I censused all 18,474 features instead of the 1,258 sampled. Nationally there are 7 buoy shapes, 26 fixed-mark kinds and 21 colour strings, not 5/14/15. About 130 objects are dropped or drawn with a colour band missing, including a steering light, a leading light and a brown mark. Also: `opgeheven` really does carry dates on 5 marks, which the note says it never does — the code handles them correctly, the note is what needs fixing. - **#214 — you cannot find out what a mark is.** Nothing to click, nothing to walk up to, no name, no row of its own in the Layers panel. The register carries the mark's name, its fairway and its light character; all are dropped at parse time. The client already does exactly this for houseboat berths. - **#215 — a mark is only readable from about mast height.** At 150 m a buoy is a 2–3 pixel speck; at 400 m it is one or two pixels; at 450 m it is hidden. Shape and colour are the datum, and both are gone before the fade even starts. ## What I could not check Colour fidelity. This container renders in software, so whether a red can reads as red still needs a real screen or a phone. ## For you to decide There is no automated check on this layer. The command above works and gates it in one capture, but no continuous integration job runs it — and no other streamed layer has one either, so this is a repository-wide pattern rather than something #206 skipped. I did not file it as a gap. No branch, no commits, no pull request — the ticket asked for findings only. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — 110 turns · $11.20 · session `fd73424b-1054-4dd3-bac4-732bd0024536`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:done

and removed

agent:running

labels

2026-08-30 08:06:12 +00:00

viberfox-agent referenced this issue

2026-08-30 08:22:26 +00:00

gap: the vaarwegmarkeringen vocabularies are wider than the census the parser was built on #213

viberfox-agent referenced this issue

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

Autopilot log #181