Validate Delivery

validate-delivery — run behavioral tests, file evidence and deltas

The skill is named validate-delivery; it is the execution-to-evidence leg of the devague method — the seventh leg in flow order (the eighth origin skill, chronologically), sitting between the two closing execution skills:

scope -> think -> challenge -> spec-to-plan -> assign-to-workforce ->
deviate -> validate-delivery -> summarize-delivery

Where /assign-to-workforce fans out a converged plan's waves and /summarize-delivery closes the loop afterward, /validate-delivery runs after waves merge and before the delivery summary is written. It is the gap that used to be filled by memory: the confirmed plan's claims are obligations, and until this skill existed nothing forced the run to check whether the merged code actually behaves as claimed before the summary asserted it did.

When to invoke

Run this skill once a wave (or the whole plan) has merged and there is behavior to check against a claim or an approved deviation — always before /summarize-delivery, never as a substitute for it. It is not gated on a complete run: a partial or failed fan-out is still worth validating for whatever did merge.

The method

1. Identify the obligations. Read the plan's confirmed claims (via the frame) and any approved /deviate records to see what the run promised — an announcement, an after-state, a success signal, an acceptance criterion. Each one that has a behavioral test backing it is an obligation this leg checks.
2. Locate the behavioral tests. Consuming repos identify behavioral tests one of two ways (either is valid; pick whichever the repo already uses, and say which one in the filed evidence):
   • a pytest marker, e.g. @pytest.mark.behavioral — run with pytest -m behavioral;
   • a dedicated folder, e.g. tests/behavioral/ or behavioral-tests/ — run that path directly.
3. Run the tests agent-side. The agent (not the devague CLI) executes the behavioral test suite, or the specific tests relevant to the obligations in scope. This is read-only against the codebase — it does not modify code to make a test pass.
4. File evidence for every obligation checked. For each obligation, file an evidence record naming the obligation met, the test that asserted the behavior, and the outcome — pass or fail. A failing outcome is filed exactly like a passing one; it is never omitted or reworded into something softer.
5. File behavioral deltas for what changed. When the run's actual behavior added, amended, or removed a behavior relative to the plan, file a delta record — added / amended / removed — with provenance back to the claim or approved deviation that motivated it, and forward to the evidence record(s) that back it.
6. Report faithfully. Summarize what was validated, what passed, what failed, and what could not be checked at all (no behavioral test exists for that obligation yet). An unmet obligation is unmet — it is reported as such, not folded into a passing tally or left out of the report.
7. Hand off to /summarize-delivery. The filed evidence and deltas feed directly into devague summary's Delivery Claims table: evidence strength (coverage / fidelity / execution / sensitivity) is the confidence vocabulary there, and any approved lapse on a claim caps its confidence the same way it always has.

The CLI surface this skill drives

Record-only. The devague CLI never runs a test itself (issue #20) — it only records what the agent already ran and found. The exact verb shapes below are minimal placeholders while the underlying schema lands in a parallel task; treat the verb names as stable and the flags as illustrative, and reconcile against devague explain <move> once that task merges.

--origin llm on oblige / evidence / delta lands the record proposed — exactly the same anti-fabrication contract as deviate and lapse: an agent's own filing never self-confirms, and only the human's --confirm / --reject moves a proposed record forward. A user-origin filing auto-approves, mirroring deviate and lapse.

Hard rules (do not violate)

• The CLI never runs tests. devague oblige / evidence / delta are record-only moves — they take the agent's already-obtained result and file it. Running the suite is the agent's job, agent-side, exactly like /summarize-delivery's read-only verification step (issue #20).
• Unmet is unmet. A failing or unchecked obligation is filed and reported as failing or unchecked — never smoothed into "mostly passing" or silently dropped from the report. This is the direct fix for the motivating failure below: findings discovered only by reading data after the fact, never by a test failing loudly in the record.
• A partial or failed run is still a valid input. There is no completion precondition — validate whatever merged, report the rest as not yet checkable.
• llm-origin filings stay proposed until the user confirms. Same anti-fabrication contract as every other origin vocabulary in this method — an agent's own proposal never self-confirms.
• Provenance both ways. Every evidence record ties back to an obligation (a claim or an approved deviation); every delta ties back to what it diverges from and forward to the evidence that backs it. An untraceable evidence or delta record is not filed.
• This is not a new gate. Like /deviate, /validate-delivery does not add a fourth standing human gate — it produces the record /summarize- delivery and the final PR review consume; the three gates (spec, implementation split plan, final PR) are unchanged.
• File the record the moment the thing happens, never at closeout — written late is written flattering (issue 97).