Checks and recovery

Checks

Every output is type checked. A step needs no other check by default. Add a check only when it finds a concrete failure that matters to the result. The quickstart example has one, because its task is to copy text without any change:

    check:
      kind: run
      runtime: node
      entrypoint: check-text.mjs

Do not check wording, headings, keywords, lengths, or counts unless the task requires them. A meeting summary, for example, does not need to repeat each meeting name exactly. Use the simplest check that proves the fact: an exact rule (equals, count, present, file), a script, or an agent check with a prompt. Script and agent checks return status (pass, fail, or unknown), reason, and evidence. unknown never passes. A step without a check is recorded as unchecked, not as pass. A check covers outputs and state. An external change needs an effect instead. See Effects.

Recovery

A failed run keeps its accepted steps. Fix the cause, then resume the same run folder:

method run task.method --run-dir .method-runs/RUN --resume

A step that stopped during an external action needs --retry STEP:ITERATION. Inspect what the action changed first: a checkpoint cannot undo an external write. Time and request limits do not reset on resume. For changed inputs, start a new run. A new run reuses unchanged steps from earlier runs on this computer. See Run and resume and method authoring recovery.

​Checks

​Recovery

Checks

Recovery