Check a change against your repository

A useful coding result includes more than "done." You need to know what changed, which checks ran, and whether those results still apply to the files you are reviewing. Clio Coder v0.5.7 can use your repository's declared checks and a project quality policy to make those questions explicit.

Start with checks the project already owns

The verifier derives checks from supported build systems, project scripts, and CI definitions. When it cannot resolve a requested check, it should not substitute an arbitrary command and call it a pass.

Read the resolved command and working directory before approving execution. verify is subject to command admission: naming a check does not grant permission to run it, and a denied command is not a validation result.

The tools guide covers discovery and execution. The temperature-calibration example follows a small numerical correction with recorded test results.

Declare what particular changes require

A quality policy selects required checks by changed path. At the Git workspace root:

version: 1
rules:
  - id: source
    paths: ["src/**", "tests/**"]
    inputs: ["src/**", "tests/**", "package.json", "package-lock.json"]
    checks: [test]
    allowLimitations: false

1. 01

   Name the changes a rule covers

   paths selects the rule: here, any change under src/ or tests/.

2. 02

   List every input the result depends on

   inputs feeds freshness. Include fixtures, configuration, helper files, and lockfiles; this example assumes the root package declares a test script and uses that lockfile.

3. 03

   Name existing checks, not commands

   checks refers to declared checks. A policy cannot insert an arbitrary shell command or bypass approvals.

4. 04

   Decide whether limitations are acceptable

   allowLimitations: false means a reported limitation does not satisfy the rule.

Clio does not write this policy for you. Review it as a repository contract: a command that passes a narrow subset of tests should not satisfy a policy that requires the full declared test check.

Inspect freshness after editing

Clio compares source, check-declaration, and policy fingerprints. A passing check becomes stale after relevant inputs change, and a later failure supersedes an earlier pass of the same check.

This matters during an iterative fix. The agent might run a test, make another edit, and then summarize the earlier success. The current assessment should describe the work that exists now, not the best result observed along the way.

Required checks run through verify without argument or working-directory overrides. Declare subproject checks with the correct working directory in the supported catalog or a root script. The quality-policy guide explains check identity and freshness.

Read the result where you work

On the desktop alpha, open Artifacts, then Results, beside the conversation; Files shows paths and changes recorded by tools. In the terminal, /view opens artifacts and receipts.