Requirements that say @jwildfire reviewed them

Counted 2026-08-18 against the GitHub API · 113 requirements on jwildfire/obot.roadmap

• 74claim his review with no record of it
• 50of those are still open
• 38of those are at Requirement Gathering
• 0carry an approval that resolves

What the line says, and what it means

Every agent-drafted artifact in this portfolio ends with an attribution line. Until 2026-08-18 it read:

This Issue was drafted by 🧭🤖 obot-navigator (Claude Code using Opus 5) and reviewed by @jwildfire.

The first half is a fact the agent knows. The second half is a claim about somebody else, written by the party it benefits, at the moment of filing — which is to say, before any review could have happened. It costs nothing to write and nothing checks it, and 74 times it drifted from the truth.

The clearest case is #215 itself, the requirement that this convention comes from. It was drafted by the Navigator in an unattended session on 2026-08-16 at 21:02 UTC, filed with that line attached, and @jwildfire had not seen it. The requirement about not letting an agent's inference read as his approval asserted his approval on its own face.

This is not carelessness by any one session. It is what a costless assertion does over six weeks. Requirement #215 warned that an approval field would become a self-certification field within a week if anyone could type into it; the measurement here is that warning already come true, in the field nobody thought of as a field.

What was done about it

The line now ends at the author. Whether @jwildfire approved something is recorded separately, on a line that has to resolve to a record the filer did not write:

Authored by: 🧭🤖 obot-navigator (Claude Code using Opus 5)
Approved by: EMPTY

EMPTY means nobody has approved it, and it is the normal, correct value for work an agent wrote. The alternative is a citation — a decision id such as D0018.1, or his native GitHub review as owner/repo#123 review — which node scripts/provenance.mjs resolve turns back into what was asked, what he said, the channel and the date. Prose does not resolve, and the nightly audit fires on a claim that cannot be shown.

Why these 74 were not rewritten

Editing 74 issue bodies to say something different about @jwildfire's own review is a bulk change to his record, made unattended, on his behalf. That is the shape of act this requirement exists to prevent, and doing it in the name of the requirement would be the joke telling itself.

“Again, we're pushing for transparency and continuous improvement. not perfection.” — @jwildfire, 2026-08-17

So they are counted, named below, and left as they are. Three things follow from that:

• The audit's PROVENANCE-MISSING rule starts at 2026-08-18 by date, so these do not become 74 findings a night against bodies nobody may rewrite.
• The roadmap catalog does not stamp a warning pill on 74 of its rows; it states the count once, under the table, with a link here.
• Anything below that becomes load-bearing — a requirement about to authorise an approval-gated action — gets its provenance block at that moment, from the record, not from the line it currently carries.

Rewriting the population is @jwildfire's call to make, and it is a small one to execute if he wants it: the same tool that reports them can stamp them.

The 50 still open

The 24 already closed

Listed for completeness. Nothing acts on a closed requirement, so these are the least urgent and the least worth touching.