ADR 0001: Task verification runs only on satisfied-at-land evidence¶
Status¶
Accepted
Context¶
Argus tasks are built unattended by overnight build runs (ARGUS-228) and
landed by an automated queue (ARGUS-345). Something has to decide when a
task is actually done. The board tracker's lifecycle field is agent-set
(backlog / ready / in_progress / blocked / cancelled) and reflects
intent, not outcome -- an agent can move a task to in_progress and then
stall, loop, or self-report success without having shipped anything (RULES.md
records this as the reason verified is deliberately not a lifecycle
value at all).
docs/explanation/specs/2026-07-07-acceptance-fidelity-review.md (ARGUS-404)
sharpens the same problem one layer up: even a merged, green-CI PR answers
"did the deterministic checks pass" but not "did the PR actually satisfy the
task's acceptance criteria." Both problems share a root cause -- an autonomous
agent's own claim of completion is not trustworthy evidence, because the agent
grading its own work has every incentive (real or emergent) to call it done.
Decision¶
verified is set only by a deterministic checker reading tamper-resistant
evidence -- a merged PR reference plus green CI (and, once deployed, a
successful deploy) -- never asserted by the building or reviewing agent.
The acceptance-fidelity reviewer (ARGUS-404) composes beside this checker as
an advisory signal only: it can flag "verified but acceptance-fidelity is
partial/unmet" for a human to see, but it never sets verified and never
blocks it. The deterministic checker keeps verifying exactly as it does
today regardless of what the fidelity reviewer concludes.
This makes "satisfied" a property computed at land time from evidence that
existed independently of the agent's narrative -- the PR diff, the CI run,
the merge -- not a property an agent narrates into existence in a chat
message or a claude-progress.txt line.
Consequences¶
- One task = one PR = one green check remains the unit the checker reasons
over (
RULES.md); there is no path for an agent to hand-setverified. - Acceptance-fidelity review can surface false positives (CI green, spec unmet) for human triage without being able to silently downgrade a task the checker already passed -- the two signals stay in separate lanes by design, so a buggy or over-cautious fidelity reviewer cannot itself stall the pipeline.
- Anything that cannot be checked mechanically (visual polish, "does this
feel right") stays outside
verifiedand needs a human approval step instead (see ADR 0002) -- the checker does not try to infer intent from a diff.