feat(unic-archon-dlc): a review's findings must become work a developer can pick up

What happened

Run 2 produced twenty distinct findings across four mechanisms — a precheck, a goals-check, two review rounds — and posted eleven threads on the pull request.

Nothing exists that a developer picks up. The loop ends at reviewed, not at actionable. The findings live in threads on a pull request that was then abandoned, in a node output only reachable through SQLite, and in a register a human wrote by hand the next day.

Why this is the plugin's problem and not the operator's

The lifecycle has a step that finds defects and no step that converts them into work. Every route from found to fixed in run 2 was walked by a person:

• the register was hand-written from five separate sources
• the design-owned findings were hand-filed into the Consumer's tracker
• the mechanism tickets were hand-sliced from the register

None of that is repeatable and none of it happens if nobody is watching, which is the same conclusion #437 reaches from the other end.

The open question

What is the artefact between a review and a developer? Candidates, none decided: findings become tracker issues automatically · the review writes a file the next Box consumes · a Box triages its own findings into keep, waive and file.

Note that the last one needs the classification that reconcile currently lacks — see #431.

Related

#437 (the gate has no reader) and the recoverable-node-output issue. Same family: detection is not the missing piece; the path from detection to a person is.

Full evidence: docs/research/2026-08-31-dlc-run-2-findings.md.

Start with docs/research/2026-08-31-dlc-run-2-findings.md, then compare the related paths in #437, #431, and the recoverable-node-output issue. Determine which artefact or workflow should connect review findings to developer-owned work. Done means the chosen path is repeatable and produces actionable work without manual reconstruction.