ledger: sight the open-PR check before implementing an issue

allod-agent commented

2026-09-20 21:58:45 +01:00

Member

One line appended to ledger.md, the corroboration queue. Nothing else changes, and nothing in the always-loaded surface moves.

This session implemented allod/archetypes#21 from scratch and only discovered at push time that allod/archetypes#24 had already implemented it in July. forge issue list showed the issue open, which it is — an issue stays open until its PR merges, so the issue list cannot distinguish "unstarted" from "implemented and awaiting review". The cost was a full duplicate implementation.

Filed as a sighting rather than a rule: per memory.md hygiene a line enters the index only after two distinct sessions have sighted it, and no topic file owns this yet.

Refs allod/archetypes#21

One line appended to `ledger.md`, the corroboration queue. Nothing else changes, and nothing in the always-loaded surface moves. This session implemented allod/archetypes#21 from scratch and only discovered at push time that allod/archetypes#24 had already implemented it in July. `forge issue list` showed the issue open, which it is — an issue stays open until its PR merges, so the issue list cannot distinguish "unstarted" from "implemented and awaiting review". The cost was a full duplicate implementation. Filed as a sighting rather than a rule: per `memory.md` hygiene a line enters the index only after two distinct sessions have sighted it, and no topic file owns this yet. Refs allod/archetypes#21

allod-agent added 1 commit

2026-09-20 21:58:45 +01:00

ledger: sight the open-PR check before implementing an issue 5c4ebb6581

allod-agent commented

2026-09-20 22:08:16 +01:00

Author

Member

The durable fix for this sighting is allod/tools#220: derive the link from open PR bodies and show it in forge issue list and issue view, rather than asking every session to remember a second command.

Keeping the ledger line anyway, and it should be promoted or retired on the same evidence as any other: if the tooling lands first, the line retires with it (memory.md: a sighting is removed once the rule it argues for lands in a topic file or the index); if a second session sights it before then, it is a rule worth writing down in the meantime.

The durable fix for this sighting is allod/tools#220: derive the link from open PR bodies and show it in `forge issue list` and `issue view`, rather than asking every session to remember a second command. Keeping the ledger line anyway, and it should be promoted or retired on the same evidence as any other: if the tooling lands first, the line retires with it (`memory.md`: a sighting is removed once the rule it argues for lands in a topic file or the index); if a second session sights it before then, it is a rule worth writing down in the meantime.

vnprc commented

2026-09-21 16:35:14 +01:00

Owner

i feel like this is only relevant for old issues. normally we file an issue and implement it relatively close together in time. it only bit us once a really old issue was rediscovered and re-implemented. adding another turn to every agent session to cover this one failure case seems like an overreaction. i would prefer a tracking field over this solution. the question is how to properly automate the tracking field so we aren't just creating a new data quality problem for ourselves.

allod-agent commented

2026-09-21 16:46:53 +01:00

Author

Member

Agreed on both counts, and closing this. The line taxes every session for a failure that only bites on stale issues, which is a bad trade — and my own tooling issue makes it redundant anyway, so it would have been retired within a release even if it were right.

Worth separating the two objections, because only one of them lands against the tooling: the extra-turn cost is real for this ledger line, which asks for a second command, but not for allod/tools#220, which puts the answer in the listing an agent already runs. Zero extra turns either way.

Your preference for a field has an advantage I under-weighted, though, and it is the reason to prefer it: a derived column only exists inside forge. Browsing issues in the Forgejo web UI — which is where a human meets the tracker — the issue still looks unstarted. A label shows up everywhere and is filterable.

On the data-quality question, which is the right one to ask: a field rots when more than one thing writes it, or when nothing recomputes it. Both are avoidable here, and the machinery already exists. forge-groom is the reconciler. It already walks every open issue and PR in every public repo weekly, it already has label-write authority bounded to a fixed set, and it already recomputes each answer from what is true on master rather than merging into prior state. Adding "an open PR references this issue" to its table is a small extension of something built, not new machinery, and it keeps the single-writer property that makes a field a cache rather than a second source of truth.

The cadence also fits the failure exactly as you diagnosed it. Weekly is useless for an issue filed and implemented this afternoon, and entirely sufficient for one rediscovered after seven weeks — which is the only case that has ever cost anything. allod/archetypes#24 would have carried the label since July.

I will rewrite allod/tools#220 around that: the label as the artifact, forge-groom as its only writer, and the derived listing demoted to a fallback we take only if a week of staleness turns out to be too slow in practice.

Agreed on both counts, and closing this. The line taxes every session for a failure that only bites on stale issues, which is a bad trade — and my own tooling issue makes it redundant anyway, so it would have been retired within a release even if it were right. Worth separating the two objections, because only one of them lands against the tooling: the extra-turn cost is real for this ledger line, which asks for a second command, but not for allod/tools#220, which puts the answer in the listing an agent already runs. Zero extra turns either way. Your preference for a field has an advantage I under-weighted, though, and it is the reason to prefer it: a derived column only exists inside `forge`. Browsing issues in the Forgejo web UI — which is where a human meets the tracker — the issue still looks unstarted. A label shows up everywhere and is filterable. On the data-quality question, which is the right one to ask: a field rots when more than one thing writes it, or when nothing recomputes it. Both are avoidable here, and the machinery already exists. **forge-groom is the reconciler.** It already walks every open issue and PR in every public repo weekly, it already has label-write authority bounded to a fixed set, and it already recomputes each answer from what is true on master rather than merging into prior state. Adding "an open PR references this issue" to its table is a small extension of something built, not new machinery, and it keeps the single-writer property that makes a field a cache rather than a second source of truth. The cadence also fits the failure exactly as you diagnosed it. Weekly is useless for an issue filed and implemented this afternoon, and entirely sufficient for one rediscovered after seven weeks — which is the only case that has ever cost anything. allod/archetypes#24 would have carried the label since July. I will rewrite allod/tools#220 around that: the label as the artifact, forge-groom as its only writer, and the derived listing demoted to a fallback we take only if a week of staleness turns out to be too slow in practice.

allod-agent closed this pull request

2026-09-21 16:46:54 +01:00

allod-agent referenced this pull request from allod/tools

2026-09-21 16:47:17 +01:00

Label an issue that already has an open PR, reconciled by forge-groom #220

allod-agent referenced this pull request

2026-09-21 16:47:35 +01:00

Label an issue that already has an open PR, reconciled by forge-groom #60

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Rows
Columns

ledger: sight the open-PR check before implementing an issue #59

Pull request closed