feat(devkit): enforce governed prompt adoption

docs/packaging/ADOPTION_GUIDE.md

@@ -1,16 +1,29 @@
 # CASAN Adoption Guide
 
+The installer also provisions the mandatory prompt-enforcement pack. After adoption, send project prompts through `bin/casan-chat` (or `bin/casan-chat.ps1` on Windows/WSL2) and run `bin/casan prompt verify`. See [PROMPT_ENFORCEMENT_GUIDE.md](PROMPT_ENFORCEMENT_GUIDE.md) for the technical boundary and per-trace certification.
+
 How a downstream project adopts the CASAN governance harness. Adoption is **config +
 domain only** — you never edit gate logic (H1→H7).
 
 ## Option A — DevKit install (recommended)
-From a CASAN source hub or an extracted `casan-devkit` bundle:
+
+Clone CASAN Core from your Gitea repository once, and pull the latest `main` before each install or upgrade:
+
+```bash
+git clone <gitea-casan-core-url> casan-core
+cd casan-core
+git pull --ff-only origin main
+```
+
+Then run the installer from that CASAN checkout:
+
 ```bash
 packages/casan-devkit/install.sh --target ../my-project --project ticketing --domain "Ticketing"
 ```
 This copies the core harness + `bin/casan` into `../my-project`, scaffolds
-`apps/ticketing/domain/` from the domain-pack template, adds `.gitea/workflows/casan-ci.yml`,
-and registers the project in `project-registry.json`.
+`apps/ticketing/domain/` from the domain-pack template, installs the prompt entrypoints and
+standalone `.gitea/workflows/casan-prompt-enforcement.yml`, and registers the project in
+`project-registry.json`. Existing domain files, registry state, and project CI are preserved.
 
 ## Option A2 — New production project shell
 
@@ -32,12 +45,15 @@ tar -xzf casan-core-v1.0.0.tar.gz
 cp -R casan-core-v1.0.0/{packages,bin,VERSION} /path/to/project/
 ```
 Then create `apps/<project>/domain/` yourself (see `DOMAIN_PACK_GUIDE.md`).
+This harness-only option does not install the mandatory repository prompt-enforcement pack;
+use Option A when every project prompt must be governed and certifiable.
 
 ## Option C — Docker (no install into repo)
 ```bash
 docker run --rm -v "$PWD":/workspace -w /workspace casan-harness:1.0.0 casan gate
 ```
 See `DOCKER_GUIDE.md`.
+This runtime-only option also does not enforce repository-agent entrypoints.
 
 ## After install
 1. Requirement → `apps/<project>/domain/input/requirement.md` (keep the `| FR-xx |` table).

docs/packaging/PROMPT_ENFORCEMENT_GUIDE.md

@@ -0,0 +1,67 @@
+# CASAN Prompt Enforcement for Adopted Projects
+
+The DevKit installer configures an adopted repository so supported repository agents and team members use CASAN as the certified prompt boundary.
+
+## What is enforced
+
+- `bin/casan-chat` is the macOS/Linux/WSL2 prompt entrypoint.
+- `bin/casan-chat.ps1` is the Windows wrapper and executes the same entrypoint through WSL2.
+- `.casan/prompt-policy.json` binds prompts and H6 telemetry to one `project_id`.
+- `AGENTS.md`, `CLAUDE.md`, and `.github/copilot-instructions.md` tell supported repository agents to refuse direct prompt work and require resubmission through CASAN.
+- The standalone `.gitea/workflows/casan-prompt-enforcement.yml` workflow verifies that the policy, launchers, instructions, domain root, and workflow contract are present and have not been stripped. Existing project CI is not overwritten.
+- A certified prompt must produce a trace with passing H1-H7 gates and H6 telemetry attributed to the configured project.
+
+## Enforcement boundary
+
+A repository cannot technically intercept text typed directly into an external ChatGPT, Claude, or Copilot website. Such conversations are outside the CASAN runtime and therefore are **not CASAN-certified**. The enforceable rule is:
+
+1. Use a CASAN-owned entrypoint for every project prompt.
+2. Repository-aware agents must refuse direct execution when their instruction file is loaded.
+3. Accept governed output only when its CASAN trace passes verification.
+
+For stronger organizational control, restrict direct external AI sites at the identity, proxy, or network layer. That control is outside the repository and complements CASAN rather than replacing its H1-H7 evidence.
+
+## Install or upgrade
+
+From a checked-out CASAN Core repository:
+
+```bash
+packages/casan-devkit/install.sh \
+  --target "/absolute/path/to/existing-project" \
+  --project "project-id" \
+  --domain "Project display name"
+```
+
+The installer is idempotent for the managed instruction blocks. Existing content outside the CASAN markers, project domain documents, project registry, and existing CI workflows is retained.
+
+## Send prompts
+
+macOS, Linux, or WSL2:
+
+```bash
+bin/casan-chat "Review the current requirements and identify missing acceptance criteria"
+```
+
+Windows PowerShell with WSL2:
+
+```powershell
+powershell -ExecutionPolicy Bypass -File bin\casan-chat.ps1 "Review the current requirements"
+```
+
+Run without a prompt to enter interactive mode.
+
+## Verify
+
+Verify the repository contract:
+
+```bash
+bin/casan prompt verify
+```
+
+Verify an individual governed result:
+
+```bash
+bin/casan prompt trace <trace-id>
+```
+
+Only the second command proves that the individual prompt completed H1-H7 and has matching H6 project telemetry.