The repos_clean: verify clause: assert that sessions committed their work.

verify:
  repos_clean:
    - repo: "app"
      pushed: true      # default false

When a packet runs with --no-commit, the runner's committer never runs and each session is responsible for committing its own work. changed_paths_only is useless in that arrangement — it reads git status --porcelain, which is empty precisely because the session committed — so it passes vacuously. repos_clean: is the clause that actually holds such a packet to account.

pushed: semantics:

• pushed: false (the default) checks only that the working tree is clean. A branch with no upstream is fine, and an existing upstream is not compared. A repository that starts local and stays local until its author decides to publish it must not fail a gate for that.
• pushed: true additionally requires an upstream. A missing upstream is a failure, not a pass: the clause was asked to assert publication and cannot.

The upstream comparison asks the remote directly with git ls-remote, under a bounded timeout (remote_timeout_ms, default 90s). ls-remote is a pure query: unlike git fetch it does not create or move remote-tracking refs, so this clause writes nothing at all into the repository it is judging. A gate that mutates any part of its subject is a gate that can change the thing it measures.

The bound matters because a verify clause runs after the model work is already spent and an unreachable remote must not hang the run. When the remote cannot be reached, the comparison falls back to the cached remote-tracking ref and says so in details. That fallback is biased toward reporting not pushed, because a cached ref can only be behind the remote, never ahead of it — the safe direction for a clause whose whole job is to assert publication.