Retrospective: the last 3 day(s), and what to do differently

viberfox-agent commented

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

Collaborator

Step back and read the last 3 day(s) of this lane, then steer it. You are not building anything on this ticket.

Gather. docs/direction.md (the goal and the seven values); every issue closed or
filed in the last 3 day(s) — shipped, failed, parked — and the reports on closed
qa tickets; the open qa-gap backlog. All of it is on the Forgejo API with the
FORGEJO_TOKEN in your environment.
Analyse against the goal. Which shipped work actually moved the twin forward, and
which was busywork? Where did tickets stall, and is the pattern a machinery problem
(conflicts, refusals, flakes) rather than a hard ticket? What do the QA findings say
players keep hitting? Is the frontier still the highest-value queue, or is the gap
backlog now worth more than the next data source?
Act, inside these bounds and no further:
- Promote at most three open qa-gap issues into the build lane by adding the
  autonomous label and the ship label. Only gaps whose success a machine
  can judge, and nothing the fences cover — no wire protocol, no database schema, no
  taste. Only issues already carrying qa-gap: that label is the lane vouching for
  its own finding. Say on each one why it was promoted.
- File a ticket for each machinery problem you can name precisely (the autopilot,
  the watcher, CI, the deploy). These are code under tools/, which the unattended
  lane may build but never merge — they land for review, which is the point.
- Propose direction changes as a ticket titled proposal: …, argued from the
  period you just read. Never edit docs/direction.md here and never label a proposal
  autonomous — the direction is the maintainer's, by that file's own first rule.
Report and close. Final message: the period in five lines, what you promoted and
why, what you filed, what you propose. Then close this ticket through the API.

Decide it yourself. Nobody is watching this ticket. Judge by the seven values; a
promotion you are unsure about is one to leave for the maintainer, not to ask about.

_{Filed by the autopilot.}

Step back and read the last 3 day(s) of this lane, then steer it. You are not building anything on this ticket. 1. **Gather.** `docs/direction.md` (the goal and the seven values); every issue closed or filed in the last 3 day(s) — shipped, failed, parked — and the reports on closed `qa` tickets; the open `qa-gap` backlog. All of it is on the Forgejo API with the `FORGEJO_TOKEN` in your environment. 2. **Analyse against the goal.** Which shipped work actually moved the twin forward, and which was busywork? Where did tickets stall, and is the pattern a machinery problem (conflicts, refusals, flakes) rather than a hard ticket? What do the QA findings say players keep hitting? Is the frontier still the highest-value queue, or is the gap backlog now worth more than the next data source? 3. **Act, inside these bounds and no further:** - **Promote at most three open `qa-gap` issues into the build lane** by adding the `autonomous` label and the `ship` label. Only gaps whose success a machine can judge, and nothing the fences cover — no wire protocol, no database schema, no taste. Only issues already carrying `qa-gap`: that label is the lane vouching for its own finding. Say on each one why it was promoted. - **File a ticket for each machinery problem** you can name precisely (the autopilot, the watcher, CI, the deploy). These are code under `tools/`, which the unattended lane may build but never merge — they land for review, which is the point. - **Propose direction changes as a ticket** titled `proposal: …`, argued from the period you just read. Never edit `docs/direction.md` here and never label a proposal `autonomous` — the direction is the maintainer's, by that file's own first rule. 4. **Report and close.** Final message: the period in five lines, what you promoted and why, what you filed, what you propose. Then close this ticket through the API. **Decide it yourself.** Nobody is watching this ticket. Judge by the seven values; a promotion you are unsure about is one to leave for the maintainer, not to ask about. Filed by the autopilot.

viberfox-agent added the

agent

autopilot

retro

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:18:09 +00:00

viberfox-agent commented

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

Author

Collaborator

🤖 Picked this up — working on branch feat/218-retrospective-last-3-day 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/218-retrospective-last-3-day` 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: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-30 08:22:39 +00:00

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

viberfox-agent referenced this issue

2026-08-30 08:23:25 +00:00

The deploy step refuses a documentation-only merge, and the ship tick stalls 45 minutes on it #219

viberfox-agent referenced this issue

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

The watcher waits for CI on a branch push, so agent:done never means "CI agreed" #220

viberfox-agent referenced this issue

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

proposal: a source is not wired until a player can find it, and gaps outrank the next candidate #221

viberfox-agent referenced this issue

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

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

viberfox-agent referenced this issue

2026-08-30 08:24:26 +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:24:39 +00:00

viberfox-agent commented

2026-08-30 08:24:58 +00:00

Author

Collaborator

No code was written — this ticket says not to build anything. The branch has no commits and nothing was pushed. Everything below happened through the Forgejo API.

The period in five lines

Ten tickets closed in three days. Six ended as documentation saying a data source is not worth taking; one refilled the candidate list; one shipped a verdict with code (the BGT collections); two shipped map layers.
Of those two layers, crop parcels draws nothing — it needs an extractor in the cartopy repository, which this container still cannot reach (404), tracked as unlabelled issue #204.
The other, navigation marks, drew 18,474 objects and produced four gap reports within hours. Two say the same thing: you cannot find out what a mark is, and you cannot see one above 150 metres.
Ten of ten tickets reached agent:done with no test run at all. The build system is deliberately configured not to run on a branch push, so the wait can only ever time out.
Six tickets ended with a scary "merged, but not deployed" message on a documentation-only change that had nothing to deploy — each one after the lane sat still for about 45 minutes.

Promoted into the build lane (2 of 4 gaps)

#213 — the buoy register's vocabulary is wider than the sample the parser was built on, so about 130 objects are dropped and seven are drawn in the wrong colour. Success is three counts, nothing to look at. Not the wire protocol: the format in question is a disk cache.
#214 — a navigation mark cannot be identified by any means. nearest_berth in interact.rs is the same shape already in the tree, so the panel is inherited rather than invented.

I left #212 and #215 for you and said why on each ticket: both ask for a decision rather than a fix. #215 was the close call — the fix has an exact precedent, but choosing how big a buoy should look is judged by eye, which the direction file puts out of bounds.

Filed

#219 (autonomous, no ship — the autopilot's own fence handles that) — the deploy script refuses a documentation-only merge as unverified, and the ship step blocks for the timeout. The autopilot already knows the rule; the deploy script does not. Both should read it from one place.
#220 (report only) — the watcher waits for a verdict on a branch push, which by design never runs. tools/autopilot.ts was already fixed for this; the watcher lives in a separate repository and was not. docs/notes/agent-verification.md currently states something false about what agent:done means.

Proposed

#221 — a source is not "wired" until a player can find it, ask what it is, and see it at the altitude it lives at; and an open gap on a wired source should outrank the next unchecked candidate. I included the arguments against, including that the gap backlog is one layer deep and may be too thin to generalise from.

For you to decide

#204 is stuck. Crop parcels are on the "wired" list and draw nothing. Nothing in this lane can pick it up.
Four issues (#175, #180, #186, #187) carry both agent:failed and agent:shipped. They shipped fine; the failure label is stale from a bug since fixed. I left them alone — cleaning them was outside this ticket's bounds.

Nothing here needed a visual check, and none was attempted.

No commits were made.

_{🤖 viberfox issue agent on the VPS — 41 turns · $3.74 · session 7261d333-9d3c-4645-8da8-93e37a5aca4e. Reply with @agent to continue this session.}

No code was written — this ticket says not to build anything. The branch has no commits and nothing was pushed. Everything below happened through the Forgejo API. ## The period in five lines - Ten tickets closed in three days. Six ended as documentation saying a data source is **not** worth taking; one refilled the candidate list; one shipped a verdict with code (the BGT collections); two shipped map layers. - Of those two layers, **crop parcels draws nothing** — it needs an extractor in the cartopy repository, which this container still cannot reach (404), tracked as unlabelled issue #204. - The other, navigation marks, drew 18,474 objects and produced four gap reports within hours. Two say the same thing: you cannot find out what a mark is, and you cannot see one above 150 metres. - **Ten of ten tickets reached `agent:done` with no test run at all.** The build system is deliberately configured not to run on a branch push, so the wait can only ever time out. - Six tickets ended with a scary "merged, but not deployed" message on a documentation-only change that had nothing to deploy — each one after the lane sat still for about 45 minutes. ## Promoted into the build lane (2 of 4 gaps) - **#213** — the buoy register's vocabulary is wider than the sample the parser was built on, so about 130 objects are dropped and seven are drawn in the wrong colour. Success is three counts, nothing to look at. Not the wire protocol: the format in question is a disk cache. - **#214** — a navigation mark cannot be identified by any means. `nearest_berth` in `interact.rs` is the same shape already in the tree, so the panel is inherited rather than invented. I left **#212** and **#215** for you and said why on each ticket: both ask for a decision rather than a fix. #215 was the close call — the fix has an exact precedent, but choosing how big a buoy should look is judged by eye, which the direction file puts out of bounds. ## Filed - **#219** (`autonomous`, no `ship` — the autopilot's own fence handles that) — the deploy script refuses a documentation-only merge as unverified, and the ship step blocks for the timeout. The autopilot already knows the rule; the deploy script does not. Both should read it from one place. - **#220** (report only) — the watcher waits for a verdict on a branch push, which by design never runs. `tools/autopilot.ts` was already fixed for this; the watcher lives in a separate repository and was not. `docs/notes/agent-verification.md` currently states something false about what `agent:done` means. ## Proposed - **#221** — a source is not "wired" until a player can find it, ask what it is, and see it at the altitude it lives at; and an open gap on a wired source should outrank the next unchecked candidate. I included the arguments against, including that the gap backlog is one layer deep and may be too thin to generalise from. ## For you to decide 1. **#204 is stuck.** Crop parcels are on the "wired" list and draw nothing. Nothing in this lane can pick it up. 2. Four issues (#175, #180, #186, #187) carry both `agent:failed` and `agent:shipped`. They shipped fine; the failure label is stale from a bug since fixed. I left them alone — cleaning them was outside this ticket's bounds. Nothing here needed a visual check, and none was attempted. _No commits were made._ --- 🤖 viberfox issue agent on the VPS — 41 turns · $3.74 · session `7261d333-9d3c-4645-8da8-93e37a5aca4e`. Reply with **@agent** to continue this session.

viberfox-agent added

agent:done

and removed

agent:running

labels

2026-08-30 08:24:58 +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