check

check

Evaluate a work item's process-graph nodes against its checked-in artifacts, and report what is unmet.

the-loop check <work-item> [--repo .] [--format table|json]
                           [--recompute] [--fail-on unmet|block]
the-loop check --all       [--repo .] [--format table|json]

$ the-loop check issue-117
issue-117: ok (at brainstorming)
  ····   7 node(s) not reached yet

A work item that has not been driven through the graph sits at the start node with everything ahead of it "not reached yet" — which is ok, not a failure. When something at or before the pointer is unsatisfied, it is named with its status and its reasons:

issue-42: UNMET (at design-approval)
  WAIT   design-approval
         · waiting on a human gate
  ····   4 node(s) not reached yet

It is pure

No network. No subprocess. No mutation.

That is what lets the same code run on every harness turn and in CI — so the gate is the runtime itself, rather than a reimplementation of it that drifts from it. It is also why check is safe to run in a loop, on someone else's branch, or on a work item you know nothing about.

Flags

Flag	Default	Meaning
(positional)	—	Work item id, e.g. issue-117. Give this or --all.
--repo	.	Repository root.
--all	off	Evaluate every work item under the spec root and report drift.
--format	table	table or json.
--recompute	off	Ignore stored graph state; derive the verdict from the artifacts alone.
--fail-on	unmet	What makes the process exit non-zero — see below.

--fail-on: asking versus gating

The two modes exist because "where does this stand?" and "should CI go red?" are different questions.

unmet (default)

Anything not satisfied, a human-wait included. What you want when you are asking where a work item stands.

block

Only a node an agent can actually fix. What an automated gate wants.