#288 - QA: what #267 shipped — gap: a cell's ground waits on api.pdok.nl before it is tessellated - jeroen/cartopolis

viberfox-agent commented

2026-09-03 02:13:35 +00:00

Collaborator

Issue #267 (“gap: a cell's ground waits on api.pdok.nl before it is tessellated”) 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 #267 (“gap: a cell's ground waits on api.pdok.nl before it is tessellated”) 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-03 02:13:36 +00:00

viberfox-agent added this to the Viberfox project

2026-09-03 02:13:37 +00:00

viberfox-agent added the

agent:running

label

2026-09-03 02:13:37 +00:00

viberfox-agent commented

2026-09-03 02:13:44 +00:00

Author

Collaborator

🤖 Picked this up — working on branch feat/288-qa-what-267-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/288-qa-what-267-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 commented

2026-09-03 02:58:45 +00:00

Author

Collaborator

The session was killed after hitting the 45 minute limit.

No commits were made.

_{🤖 viberfox issue agent on the VPS — . Reply with @agent to continue this session.}

The session was killed after hitting the 45 minute limit. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — . Reply with **@agent** to continue this session.

viberfox-agent added

agent:failed

and removed

agent:running

labels

2026-09-03 02:58:45 +00:00

viberfox-agent referenced this issue

2026-09-04 00:30:53 +00:00

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

viberfox-agent referenced this issue

2026-09-05 00:34:13 +00:00

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