thanhnv
06c404084d
CASAN Supply Chain and Provenance / verify-scan-attest (push) Canceled after 0s
CASAN CI Gate / Frontend Tests (H3 gate) (push) Canceled after 0s
CASAN CI Gate / CASAN Security Gate + Vault KMS (H4/H5) (push) Canceled after 0s
CASAN CI Gate / Build & Deploy OKR → /opt/webapps/okr (push) Canceled after 0s
CASAN Harness CI / harness (push) Canceled after 0s
59 lines
2.8 KiB
Markdown
59 lines
2.8 KiB
Markdown
---
|
|
name: casan
|
|
description: Operate the CASAN governed AI coding assurance runtime. Use when adopting CASAN into a repository, configuring Claude Code or Codex hooks, checking readiness or runtime integrity, running governance gates, inspecting assurance reports, exporting evidence, or diagnosing CASAN installation and enforcement problems.
|
|
---
|
|
|
|
# CASAN
|
|
|
|
Use the installed CASAN CLI as the only operational entry point. This skill is
|
|
an operator facade; it does not duplicate the assurance kernel and installing
|
|
the plugin alone does not enable enforcement.
|
|
|
|
## Resolve the runtime
|
|
|
|
1. Work from the target repository root.
|
|
2. Resolve `casan` with `command -v casan`.
|
|
3. If it is unavailable, report that the DevKit runtime must be installed. Do
|
|
not install into the user's home directory unless the user explicitly asks.
|
|
4. If the current checkout is the CASAN source hub and installation is
|
|
requested, use `sh install.sh --level devkit` on macOS/Linux or
|
|
`pwsh ./install.ps1` on Windows.
|
|
5. Never treat plugin registration as proof that project hooks or enforcement
|
|
are active.
|
|
|
|
## Route the request
|
|
|
|
- Adopt or reconfigure a repository: run `casan init`. Preserve an existing
|
|
runtime and enforcement choice unless the user explicitly changes it.
|
|
- Configure automation: run `casan init --non-interactive --edition core
|
|
--runtime managed --mode enforce --client claude,codex` and adjust only the
|
|
options the user requested.
|
|
- Diagnose an installation or project: run `casan doctor`, then
|
|
`casan readiness --refresh` and `casan verify-harness` as needed.
|
|
- Verify governance: run `casan gate` for project checks and `casan verify` for
|
|
audit, tool, and policy verification.
|
|
- Inspect evidence: use `casan report latest`, `casan view`, or
|
|
`casan report export` according to the requested output.
|
|
- Inspect the product selection: use `casan edition show`. Do not equate an
|
|
installed edition with CASAN Maturity L1-L5.
|
|
|
|
## Preserve the trust boundary
|
|
|
|
- Check `.casan/config.json`, `.casan/version.lock`, and the selected client
|
|
hook projection before claiming CASAN is active.
|
|
- Require the user to review and trust native client hooks where the client
|
|
exposes a trust step.
|
|
- Never edit `version.lock` to suppress integrity drift. Restore or reinstall
|
|
the approved runtime and rerun `casan verify-harness`.
|
|
- Never silently change `observe` to `enforce`, switch managed/vendored mode,
|
|
or enable additional client integrations.
|
|
- Keep generated evidence and state in the target project. Do not write runtime
|
|
state into the plugin cache or global version directory.
|
|
|
|
## Report results
|
|
|
|
State the resolved runtime, project edition, enforcement mode, configured
|
|
clients, commands run, and any failing assurance control. Distinguish a missing
|
|
optional Domain Pipeline or provider telemetry integration from a failed Core
|
|
assurance control.
|