Context CI — a release check for what your agents know

IMPLEMENTED in 0.4.0: context ci, the shipped pull-request script ci/context-check.sh, and a private-runner GitHub workflow. Everything runs with the control plane's bundled Node; no seif-cli, global Node or source checkout.

pull request changes context-project.json
        ↓
candidate Build (in the CI workspace, never committed)
        ↓
baseline from the Registry: the target environment's current Build
        ↓
Context Tests (with synthetic provider fixtures) → semantic Build diff
        ↓
retained-corpus regression under that environment's own gate policy
        ↓
JSON · Markdown summary · JUnit · GitHub annotations · exit status

export CONTEXT_CI_TOKEN=scw_ci_…   # automation credential (see Service identities)
./context ci --project context/context-project.json \
  --registry https://registry.example --token-ref env:CONTEXT_CI_TOKEN \
  --environment staging --register true --output-dir context-ci

Baseline resolution: --baseline-build DIR (local) › --baseline-ref <b_… or name@N> (Registry) › the environment's current Build › none (first release, reported as NONE with the reason). The candidate is versioned after the Registry's latest Build ref so CI and Workstation Builds never collide. With --register true the candidate is registered under the CI identity and the Registry runs its own regression; that server decision is authoritative for promotion and appears in the report.

Outputs in --output-dir: context-ci.json (context-ci-report.v1: candidate, baseline and its source, policy and corpus digests, provider evaluation mode, metrics before/after, changed layers/rules/sources, decision, blocks, warnings, Registry facts, cases), context-ci.md, context-ci.junit.xml, context-ci.annotations.txt. Under GitHub Actions, failing Context Tests are annotated on their definition line in context-project.json and the Markdown is appended to the job summary. Exit 0 PASS, 1 BLOCK, 2 not evaluated.

## CONTEXT RELEASE CHECK
Candidate: support-agent-context@2 · Baseline: support-agent-context@1 (registry environment · staging)
| Tests | 3 pass · 0 fail · 0 unknown | 3 pass · 0 fail · 0 unknown |
| Required context | 100% | 100% |
| Forbidden leakage | 0 | 0 |
| Average estimated context (tokens) | 937 | 891 |
| Unknown applicability | 4.8% | 4.8% |
Changed layers: history · Providers: FIXTURE (DETERMINISTIC)
### Decision: PASS

GitHub workflow

.github/workflows/context-ci.yml runs on pull requests that touch Context Projects, on a self-hosted runner labelled context-workstation with the control plane unpacked at CONTEXT_HOME. Configure repository variables CONTEXT_PROJECT, CONTEXT_REGISTRY_URL, CONTEXT_BASELINE_ENVIRONMENT, optional CONTEXT_REGISTER_CANDIDATES, and the secret CONTEXT_CI_TOKEN. Actions are pinned by commit SHA; reports are kept as an artifact. The workflow calls the same ci/context-check.sh that the local proofs execute; no hosted runner was available, so remote Actions execution itself is UNPROVEN while the script is proven PASS and BLOCK on macOS and in Linux containers.

Other commands

validate, test, build, verify, artifact, sign --signer ID --key-ref env:KEY, diff, regression --baseline DIR --candidate DIR [--format markdown|junit] [--policy FILE] [--suite FILE] [--at ISO]. Regression over Builds with live providers uses each test's fixtures (deterministic); see Context Regression.