# CASAN CI Guide (Gitea Actions)

Wire the CASAN governance gate into your project's CI so every push/PR is governed.

## 1. Add the workflow
DevKit `install.sh` already drops `.gitea/workflows/casan-ci.yml`. To add manually, copy the
template:
```bash
cp packages/casan-devkit/templates/gitea-workflow/ci.yml .gitea/workflows/casan-ci.yml
```

## 2. What it runs
```yaml
- casan verify-harness
- casan gate
```

`CASAN_PROJECT_MANIFEST` must point to the project's manifest. Build and test
commands come from that reviewed manifest; the production package does not contain
CASAN's own source-hub test suites.

## 3. Runner
Uses `runs-on: ci-runner` (a self-hosted Gitea Actions runner). To set one up on your host,
see `.gitea/vps-setup-runbook.md` and `scripts/setup-ci-runner.sh`. The runner needs
`bash`, `python3`, `openssl`, the approved global CASAN release, and the toolchain
declared by the project manifest.

## 4. Expected result
`PROJECT_GATE_SUMMARY ... FAIL=0`. Any FAIL fails the job (exit 1). The gate is
**fail-closed**: missing signatures/policy in enforced mode (`CASAN_PROFILE=prod` or
`CASAN_VERIFY_STRICT=1`) also fail.

## 5. This repo's own CI
The source hub's active pipeline still runs internal regression and adversarial suites.
Those suites validate CASAN itself and are intentionally excluded from customer/runtime
artifacts.

## Tips
- Keep the project gate green as an invariant.
- Do not stage runtime log artifacts (`.specify/logs`, evidence) produced by gate runs.
- For a quick local pre-push check: `casan gate`.