Run the gate in CI

Continuous integration, or CI, runs checks when changes reach your code-hosting service. Running discerndiscern↗A tool that installs and runs an agent development practice in a project. there lets your project use the same declared checks locally and remotely, with a result that another person can inspect.

Suppose a change works on your laptop but needs to work on Linux too. A CI job can exercise it there and keep the failure output with the change. You and your agent get another place to check the result without maintaining a second list of quality rules.

Once the project has completed discern setup, ask your agent or the person maintaining your CI:

Add discern's gateGate↗The configured checks a change must satisfy for ordinary completion. to our CI workflow. Use the checks already declared for this project, keep useful failure output, and show that the workflow fails for a known broken change and passes for a corrected one. Explain any repository setting I need to change.

Choose the operating systems and runtimes the workflow should cover. Your agent can recommend them from the project's runtimes and users. CI configuration and any credentials belong to your hosting service; discern runs the checks you configure there.

A passing CI report says what ran on that runner. It does not give permission to land, record an agent's checkpointCheckpoint↗A review question presented when a relevant kind of change occurs. answers, or create the Proof that discern acceptance requires. The task still goes through its ordinary completion and review process.

The workflow checks out the change, installs a pinned discern versiondiscern version↗The version of discern you are running, shown by discern --version. and the project's required runtimes, and installs locked dependencies. Dependency setup comes before the gate so checks can run concurrently without competing to install their tools.

Keep [jobs], scopeScope↗A named set of project paths used to select work or policy. gates, and standards in discern.toml as the shared check definitions. The workflow should invoke those definitions through discern rather than copy each check into a separate CI command.

The workflow also needs enough Git history to identify what changed. Fetch the event's actual comparison commit into a local reference. For a pull request, use its base commit; for a push, use the prior commit. This policy base lets discern compare the rules before and after the change. Comparing a pushed change with its own new tip could hide a weakened rule.

From the repository root, the CI runner invokes:

discern done --ci --standalone --policy-base refs/discern/ci-policy-base --markdown

This workflow produces a separate CI report. Its result never becomes the task's Proof, and a report never puts the task in the landing queue.

This example assumes the workflow has fetched the comparison commit into refs/discern/ci-policy-base.

The options make the purpose explicit:

• --ci reports checkpoint questionsQuestion↗Something the agent is asked to judge about the project or a change. without recording answers for the task.
• --standalone requests transient diagnostics without producing Proof, and allows the report to run on a tree that still holds uncommitted rewrites.
• --policy-base identifies the rules the report should compare against. It is valid only together with --ci and --standalone.
• --markdown keeps a readable result in the job log or summary. Use --json if another step needs structured fields.

Retain the command's failure status and complete diagnostic. A later log-upload or summary step must not turn a failed gate into a successful CI job.

After the gate, the workflow checks for changes made by formatters, generators, or refresh:

git diff --exit-code

A tracked diff means the submitted commit did not include the output its configured commands produce. Your agent should run discern prepare in the task's worktreeWorktree↗A separate working copy and branch for one effort., review and commit the output, and send the corrected commit through CI.

The CI report covers the checks and measurements the project configures, run on the workflow's runner. It is evidence you can read, and a useful place to catch a platform difference. It is not evidence the task's agent can import: ordinary discern done in the task's worktree produces the Proof that landing requires, and a standalone report leaves nothing for it to reuse.

When CI fails, give the result to the agent working on that change:

Investigate this CI failure in the existing task. Explain whether it is a behavior problem or an environment difference, fix the cause, and return the checked result.

The agent uses captured output and the reported reproduction command, corrects the cause, and returns through preparation, commit, and full completion. Fix a red gate explains that recovery.

If CI reports a checkpoint question, the task's agent judges it with the actual change in view. A declared-unmet answer still needs your explicit decision on that exception.

Use your hosting service's branch-protection settings to require the CI job before a merge. Your agent can identify the job and explain the setting; you may need to apply it using your account's permissions.

Before discern acceptance, the task still runs ordinary discern done. That process records checkpoint judgments and gathers current completion evidence. You review the result and supply any required landing decision through Finish and land a change.

Verify the workflow with a deliberately failing test change on a disposable branch, then a corrected version. The first should make the required job fail with a useful explanation. The second should pass without uncommitted rewrites. Neither report should claim landing Proof.

You now have a remote check that follows the project's declared practice and gives a failed change a clear route back to its agent. The CLI reference supplies exact options and exit codes; Proof and checkpoint formats explains report-only records.