Cursor

---
description: How to verify a change with Ciresk CI from Cursor: the commands, the exit codes, the drill-down order and the MCP tools. Always on.
alwaysApply: true
---

# Ciresk CI

- Verify with `ciresk ci check` (remote, the exit code is the result). Exit 0 is a pass, 1 is a failed task or
  test; 2 usage, 3 auth, 4 policy, 5 budget, 6 cancelled, 7 timed out, 8 infrastructure, 9 awaiting approval.
  3, 4 and 5 are not code failures: stop and report them; 9 means a person approves a gated task: tell yours.
- Tests for one crate or package: `ciresk ci test -p <crate>`; the whole suite only when asked.
- On failure read the summary, then `ciresk ci tests <job>`, then the `next` command the output ends with.
  Never ask for a whole log: `ciresk ci logs` is failed-only, 200 lines, 64 KiB by default.
- Do not run workspace-wide builds or test suites on this machine; they go through Ciresk CI.
- Through MCP (`ciresk` server): `ciresk ci run <kind> --json` in the terminal uploads the working tree and
  prints `data.id` and `data.tree.root`; pass the id to `job_wait`, or the root as `tree_root` to `run` with
  `kind` and `repo`. `run` with `base_ref` alone works only for a repository the cell can fetch without
  credentials. `job_wait` waits up to 55 s per call; `job_tests` and `job_logs` are the drill-downs; `job_cancel` asks for
  confirmation. `full: true` needs the policy and the `ci:jobs.run_full` scope.
- Show the job id and the summary as evidence; never claim success without a `succeeded` verdict.

{
  "mcpServers": {
    "ciresk": {
      "url": "https://ci.eu.ciresk.com/v1/ci/mcp"
    }
  }
}