#217 - QA: what #203 shipped — RVO crop parcels (BRP), PDOK OGC API: is it worth wiring in? - jeroen/cartopolis

viberfox-agent commented

2026-08-30 08:09:35 +00:00

Collaborator

Issue #203 (“RVO crop parcels (BRP), 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 #203 (“RVO crop parcels (BRP), 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 08:09:35 +00:00

viberfox-agent added this to the Viberfox project

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

viberfox-agent added the

agent:running

label

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

viberfox-agent commented

2026-08-30 08:09:42 +00:00

Author

Collaborator

🤖 Picked this up — working on branch feat/217-qa-what-203-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/217-qa-what-203-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 08:37:36 +00:00

gap: a crop parcel is drawn but its crop can never be named #222

viberfox-agent referenced this issue

2026-08-30 08:37:36 +00:00

gap: the crop parcels have no row in Map layers and cannot be switched off #223

viberfox-agent referenced this issue

2026-08-30 08:37:36 +00:00

gap: grass still grows on the half of an arable parcel that crosses a cell boundary #224

viberfox-agent referenced this issue

2026-08-30 08:37:36 +00:00

gap: the grass keep-out asks the register's category, so orchards and cover crops lose their grass too #225

viberfox-agent referenced this issue

2026-08-30 08:37:52 +00:00

cartopy: server/pipeline/brp.ts — the extractor half of the crop parcels #204

viberfox-agent closed this issue

2026-08-30 08:38:18 +00:00

viberfox-agent commented

2026-08-30 08:38:52 +00:00

Author

Collaborator

I made no code changes — this was the QA pass the ticket asked for. Four gaps filed, ticket closed.

What I ran

Issue #203 shipped the client half of the crop-parcel layer and said the extractor that feeds it is a separate ticket (#204, still open), so on a normal machine it draws nothing. I stood in for that extractor: pulled the RVO crop register off the live PDOK service for three z14 cells, wrote the exact files systems::crops fetches, served them on loopback and pointed the client at them with CARTO_3DBAG_URL. Then I flew over the fields and stood in them.

The layer works. Over the Flevoland cell the client fetched, parsed and drew all 94 parcels the register has there (crop_parcels=94), each crop in its own tone, against one flat green in the same view without it. Over Groningen it drew 96 and barely changed the picture, exactly as the note's "94 % of it is grassland" warning predicts.
The depth rung the commit called unverified is fine. A paired flicker capture over the fields measured 328 changed pixels with the parcels drawn and 422 without — the parcels do not add depth fighting.
Tests pass: 223 in cartopolis_geo, 806 in cartopolis.
The wire form is reproducible. My stand-in extractor was accepted first try, and the feature counts matched the note's table (199 and 308 features). I put the confirmed format on #204 for whoever writes the real one.

Gaps filed (label `qa-gap`)

#222 — a field is drawn in its crop's colour and the crop can never be named. The register carries 233 / "Tarwe, winter-"; the wire carries the number, the client turns it into a colour and drops it. No legend, no readout, nothing — while the same client will tell you the house number next door.
#223 — no row in Map layers, so it cannot be seen or switched off. Flood defences, the same kind of registered layer, has a checkbox.
#224 — grass still grows on half of an arable field. Parcels are drawn whole across a cell boundary but the grass keep-out is built per cell, so the far side keeps its lawn. Photographed both ways at one seam, and 19 of 72 arable parcels in that cell straddle one.
#225 — the keep-out asks the register's category, so pear orchards and ryegrass cover crops lose their grass too. The orchard floor now renders bare; the same file already knows those codes well enough to give them their own green.

Unverified

Colour and lighting: this container renders in software, so I judged geometry, placement and counts, not tone. And I served the data myself — nothing has yet been checked against the real extractor, because it does not exist.

No commits were made.

_{🤖 viberfox issue agent on the VPS — 126 turns · $12.93 · session 7b6428a0-4419-4770-860a-d86ddf629575. Reply with @agent to continue this session.}

I made no code changes — this was the QA pass the ticket asked for. Four gaps filed, ticket closed. ## What I ran Issue #203 shipped the client half of the crop-parcel layer and said the extractor that feeds it is a separate ticket (#204, still open), so on a normal machine it draws nothing. I stood in for that extractor: pulled the RVO crop register off the live PDOK service for three z14 cells, wrote the exact files `systems::crops` fetches, served them on loopback and pointed the client at them with `CARTO_3DBAG_URL`. Then I flew over the fields and stood in them. - **The layer works.** Over the Flevoland cell the client fetched, parsed and drew all 94 parcels the register has there (`crop_parcels=94`), each crop in its own tone, against one flat green in the same view without it. Over Groningen it drew 96 and barely changed the picture, exactly as the note's "94 % of it is grassland" warning predicts. - **The depth rung the commit called unverified is fine.** A paired flicker capture over the fields measured 328 changed pixels with the parcels drawn and 422 without — the parcels do not add depth fighting. - **Tests pass:** 223 in `cartopolis_geo`, 806 in `cartopolis`. - **The wire form is reproducible.** My stand-in extractor was accepted first try, and the feature counts matched the note's table (199 and 308 features). I put the confirmed format on #204 for whoever writes the real one. ## Gaps filed (label `qa-gap`) - **#222** — a field is drawn in its crop's colour and the crop can never be named. The register carries `233 / "Tarwe, winter-"`; the wire carries the number, the client turns it into a colour and drops it. No legend, no readout, nothing — while the same client will tell you the house number next door. - **#223** — no row in Map layers, so it cannot be seen or switched off. Flood defences, the same kind of registered layer, has a checkbox. - **#224** — grass still grows on half of an arable field. Parcels are drawn whole across a cell boundary but the grass keep-out is built per cell, so the far side keeps its lawn. Photographed both ways at one seam, and 19 of 72 arable parcels in that cell straddle one. - **#225** — the keep-out asks the register's category, so pear orchards and ryegrass cover crops lose their grass too. The orchard floor now renders bare; the same file already knows those codes well enough to give them their own green. ## Unverified Colour and lighting: this container renders in software, so I judged geometry, placement and counts, not tone. And I served the data myself — nothing has yet been checked against the real extractor, because it does not exist. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — 126 turns · $12.93 · session `7b6428a0-4419-4770-860a-d86ddf629575`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:done

and removed

agent:running

labels

2026-08-30 08:38:52 +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