# CASAN Prompt Enforcement for Adopted Projects

CASAN adopts existing repositories through native project hooks. The global
DevKit provides `casan init`; each project pins either a managed or vendored
Core runtime.

## Supported boundaries

- Claude Code: project hooks in `.claude/settings.json`.
- Codex: project hooks in `.codex/hooks.json`, subject to explicit `/hooks`
  review and trust.
- VS Code/Copilot: CASAN-owned explicit `@casan` route.

CASAN does not claim to intercept arbitrary prompts typed into external web
sites or built-in Copilot Chat outside the explicit `@casan` route.

## Install

Install the DevKit once:

```bash
sh install.sh --level devkit
```

Adopt an existing project with the recommended managed Core:

```bash
cd /absolute/path/to/existing-project
casan init --project project-id --client claude,codex
casan doctor
casan verify-harness
```

For an offline/self-contained repository:

```bash
casan init --runtime vendored --project project-id --client claude,codex
```

Vendored Core is installed under `.casan/runtime/casan-core` using the same
production allowlist as the global release. Tests, legacy `level5`, internal
runners and Platform-only helpers are excluded.

## Runtime contract

`.casan/config.json` records:

- project ID and enforcement mode;
- selected client integrations;
- project capability level;
- runtime mode and path.

`.casan/version.lock` records the exact Core version and integrity hash.
`casan verify-harness` recomputes the live hash; it does not trust a cached
value. Vendored mode fails closed if the local Core is absent instead of
silently falling back to global Core.

## Existing repository safety

`casan init` merges only CASAN handlers into supported client configuration.
Existing hooks, agents, skills, instructions and CI workflows are preserved.
Re-running init is idempotent and preserves the selected runtime mode unless
`--runtime managed|vendored` is explicitly supplied.

## Verification

```bash
casan doctor
casan verify-harness
casan level show
```

For Codex, open `/hooks`, review the exact project hook and trust its hash.

For CI, verify the pin before executing governance gates:

```bash
casan verify-harness
casan gate
```

## Uninstall

```bash
casan uninstall
```

This removes CASAN hooks/config, CASAN-owned Gitea workflows, unchanged CASAN
scaffold files and vendored Core. User-authored hooks/workflows and modified
project files are retained. Add `--purge` to remove `.specify` logs/state, and
use `--remove-vscode-extension` only when the shared extension is no longer
needed by any project.