# `mix surfex.confirm`
[🔗](https://github.com/dcoai/surfex/blob/v0.6.2/lib/mix/tasks/surfex.confirm.ex#L1)

Confirms **one** relation, named by its ends and type, with a note saying what was
judged (`Surfex.Record.confirm/7`):

    mix surfex.confirm "test:MyApp.CartTest: rejects a closed cart" spec.md#closed \
      --type verifies --note "spec reworded; the test still checks a closed cart is refused"

It is the judgement path (§18): a `verifies` relation after a spec rewording that
changes no behaviour, an `excuses` relation, a structural relation after a change, and
an `implements` relation to a shape (a type, which no run exercises). It never confirms
any other `implements` relation: code is validated by evidence or a review, never
asserted. There is no form that confirms every relation touching an id.

With `--file PATH` it confirms many in one run (`Surfex.Record.batch/3`): one relation
per line, tab-separated `FROM`, `TO`, `TYPE`, `NOTE`, each judged as the single form
judges it. The notes must be distinct, and a refused line fails the whole batch.

`--merge PATH` (once per file) also reads other runs' evidence, such as CI artifacts,
with the local run as one history (`Surfex.Evidence.combined/1`), so a test excluded
locally counts from the run that had its environment. A missing file fails.

With `--evidence` it confirms instead what the test evidence justifies
(`Surfex.Record.confirm_by_evidence/4`): each test relation on its test's failing run,
each `tests` and `implements` relation on a red run and then a green one:

    mix test && mix surfex.confirm --evidence

With `require_red: true` in `.surfex.exs`, a `tests` relation isn't confirmed by hand
until its test's current version has failed first.

---

*Consult [api-reference.md](api-reference.md) for complete listing*