#238 - QA: what #201 shipped — The frontier is empty — find the next things worth importing - jeroen/cartopolis

viberfox-agent commented

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

Collaborator

Issue #201 (“The frontier is empty — find the next things worth importing”) 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 #201 (“The frontier is empty — find the next things worth importing”) 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 10:55:45 +00:00

viberfox-agent added this to the Viberfox project

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

viberfox-agent added the

agent:running

label

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

viberfox-agent commented

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

Author

Collaborator

🤖 Picked this up — working on branch feat/238-qa-what-201-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/238-qa-what-201-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 11:04:02 +00:00

gap: the frontier can never ask to be refilled again — the refill key is always frontier-refill-0 #239

viberfox-agent referenced this issue

2026-08-30 11:04:02 +00:00

gap: the geografische namen row's "11 names in 4.7 KB" is one collection of five, and not the one carrying the settlements #240

viberfox-agent closed this issue

2026-08-30 11:04:26 +00:00

viberfox-agent commented

2026-08-30 11:04:45 +00:00

Author

Collaborator

I filed two gaps and closed the ticket. No code changed — this was a QA pass.

What #201 shipped: seven rows in the candidate table in docs/direction.md, the queue the unattended lane pulls work from. Three have already been used up and correctly moved to the "Wired" list (crop parcels, navigation marks, level crossings), each with a note file that exists. Four remain.

What I did: requested every one of the four remaining sources over HTTP, measured what came back against what the row claims, and separately read and replayed the code that turns a row into a ticket.

What held:

Rijkswaterstaat Weggegevens — real, and the row's figure reproduces. A quiet cell on the A28 near Beilen returns 6 sections in 10.2 KB; a busy cell near Groningen returns 86 in 66 KB. Lane descriptions ("1 -> 1") and speed limits with start and end times are all there.
RDW parking — exact. 237 garages in 70.8 KB in one request, each with a position. Capacity, height limit and charging points are in a second table of 3,137 rows, which the row says.
OpenSky aircraft — works with no key, one request, answers in 0.13 seconds. It returned 175 aircraft in 22.7 KB over the Netherlands rather than the row's 24 in 3.2 KB, because the row was measured at 03:34 in the morning. Still cheap; not worth a ticket.
The table can still be read. The parser in tools/autopilot.ts sees all four rows cleanly and derives sensible keys from them.

What I filed:

#239 — the lane can never ask for a refill again. The refill ticket's key is built from the number of rows left, which is zero at the moment it fires, and issue #201 has already used that key. I confirmed this against the live board: the check the code runs returns "already filed" today. When the last of the four rows is finished, the lane files nothing and logs that the refill ticket is already open, forever. That is a few days away and it fails silently.
#240 — the geografische namen row's "11 names in 4.7 KB" is honest but describes one of five collections, and not the one it promises. Those 11 are all buildings; across the whole province that collection holds no settlement, district or water body at all. Those live in two other collections costing about 910 KB per map cell, and a third collection is 490 KB of street names the client already draws from OpenStreetMap. Total for the dataset over one cell is 1,405 KB, against the 4.7 KB the table advertises.

Unverified: I could not read the lane's state file — this session is correctly blocked from the host — so #239 rests on the code and the live board rather than on what the lane has recorded. Nothing here needed a screen.

No commits were made.

_{🤖 viberfox issue agent on the VPS — 50 turns · $4.00 · session d6c3d1f8-0b6f-4cf9-b7d2-24df3a8627f6. Reply with @agent to continue this session.}

I filed two gaps and closed the ticket. No code changed — this was a QA pass. **What #201 shipped:** seven rows in the candidate table in `docs/direction.md`, the queue the unattended lane pulls work from. Three have already been used up and correctly moved to the "Wired" list (crop parcels, navigation marks, level crossings), each with a note file that exists. Four remain. **What I did:** requested every one of the four remaining sources over HTTP, measured what came back against what the row claims, and separately read and replayed the code that turns a row into a ticket. **What held:** - **Rijkswaterstaat Weggegevens** — real, and the row's figure reproduces. A quiet cell on the A28 near Beilen returns 6 sections in 10.2 KB; a busy cell near Groningen returns 86 in 66 KB. Lane descriptions ("1 -> 1") and speed limits with start and end times are all there. - **RDW parking** — exact. 237 garages in 70.8 KB in one request, each with a position. Capacity, height limit and charging points are in a second table of 3,137 rows, which the row says. - **OpenSky aircraft** — works with no key, one request, answers in 0.13 seconds. It returned 175 aircraft in 22.7 KB over the Netherlands rather than the row's 24 in 3.2 KB, because the row was measured at 03:34 in the morning. Still cheap; not worth a ticket. - **The table can still be read.** The parser in `tools/autopilot.ts` sees all four rows cleanly and derives sensible keys from them. **What I filed:** - **#239** — the lane can never ask for a refill again. The refill ticket's key is built from the number of rows left, which is zero at the moment it fires, and issue #201 has already used that key. I confirmed this against the live board: the check the code runs returns "already filed" today. When the last of the four rows is finished, the lane files nothing and logs that the refill ticket is already open, forever. That is a few days away and it fails silently. - **#240** — the geografische namen row's "11 names in 4.7 KB" is honest but describes one of five collections, and not the one it promises. Those 11 are all buildings; across the whole province that collection holds no settlement, district or water body at all. Those live in two other collections costing about 910 KB per map cell, and a third collection is 490 KB of street names the client already draws from OpenStreetMap. Total for the dataset over one cell is 1,405 KB, against the 4.7 KB the table advertises. **Unverified:** I could not read the lane's state file — this session is correctly blocked from the host — so #239 rests on the code and the live board rather than on what the lane has recorded. Nothing here needed a screen. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — 50 turns · $4.00 · session `d6c3d1f8-0b6f-4cf9-b7d2-24df3a8627f6`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:done

and removed

agent:running

labels

2026-08-30 11:04:45 +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