feat: harden CASAN production install lifecycle

2026-07-24 11:11:44 +07:00
parent c7671ab198
commit 114340c719
48 changed files with 1036 additions and 165 deletions
@@ -24,6 +24,8 @@ This copies the core harness + `bin/casan` into `../my-project`, scaffolds
 `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.
+The copied harness follows the production allowlist and excludes CASAN's own tests,
+legacy `level5/`, internal CI runners, and Platform-only helpers.

 ## Option A2 — New production project shell

@@ -9,7 +9,7 @@ contents + maturity: [`packaging/levels.json`](../../packaging/levels.json).

 | Lvl | Package names | Status | What it is |
 |---|---|:--:|---|
-| **1 — Core Harness** | `casan-core`, `casan-harness` | ✅ implemented | H1–H7 harness, security + action gates, evidence pack, audit, cost/telemetry, hardening tests, policy/config defaults, `bin/casan` CLI |
+| **1 — Core Harness** | `casan-core`, `casan-harness` | ✅ implemented | Minimal H1–H7 production runtime: security + action gates, evidence pack, audit, cost/telemetry, policy/config defaults, adapters, `bin/casan` CLI |
 | **2 — DevKit / Adoption Kit** | `casan-devkit`, `casan-project-kit` | ✅ implemented | Level 1 + project templates, domain-pack scaffold, Gitea workflow template, harness Dockerfile, install script, adoption/CI/domain-pack guides |
 | **3 — Platform Components** | `casan-platform`, `casan-control-panel` | 🟡 preview | Control Panel, Dashboard, Run History, governed chat MVP and **Evidence Pack Viewer**. Attack Battery Viewer, Gitea evidence publishing, and managed rollout are still pending. |
 | **4 — Enterprise / Governed Console** | `casan-enterprise`, `casan-governed-console` | 📋 future | Promotion layer requiring managed deployment, KMS/Object Lock operations, HA/DR/SLA, external review and compliance/support evidence. |
@@ -38,6 +38,26 @@ Docker images (see `DOCKER_GUIDE.md`): `casan-harness:X.Y.Z` ✅ · `casan-platf
 Every bundle carries `BUNDLE-MANIFEST.txt` + `SHA256SUMS`; preview bundles also carry
 `PREVIEW-INCOMPLETE.txt`.

+## Production runtime boundary
+
+`packaging/runtime-layout.json` is the canonical allowlist used by macOS/Linux,
+Windows, vendored adoption, project scaffolding, and release packaging.
+
+Production Core/DevKit artifacts never include:
+
+- `packages/casan-harness/tests/` or `packages/casan-devkit/tests/`;
+- internal CI/adversarial runners (`ci-harness-gate.sh`, `security-gate.sh`,
+  `test-integrity.py`, cloud smoke);
+- the legacy `packages/casan-harness/level5/` directory;
+- Platform-only dashboard/local-infrastructure helpers;
+- source documentation, installer copies, Dockerfiles, caches, or release tooling
+  inside the installed version directory.
+
+Policies formerly under `level5/` live in `packages/casan-harness/config/`.
+Test fixtures live under the source-only `tests/fixtures/`. The source hub retains
+its tests so CASAN itself remains verifiable; only the install/release boundary is
+minimal.
+
 ## Who adopts what
 - **Governance-harness-only / BJT initial / CI gate** → `casan-core`.
 - **New project adopting CASAN** → `casan-devkit` (install.sh scaffolds domain + CI).
@@ -54,6 +74,7 @@ packages/casan-enterprise/  # L4 structure-only (future; README)
 bin/casan                   # CLI
 scripts/package-release.sh  # release packager
 packaging/levels.json       # bundle contents + maturity (source of truth)
+packaging/runtime-layout.json # exact production runtime allowlist
 docs/packaging/             # this plan + adoption/CI/domain-pack/gitea/docker guides
 ```

@@ -11,37 +11,31 @@ cp packages/casan-devkit/templates/gitea-workflow/ci.yml .gitea/workflows/casan-

 ## 2. What it runs
 ```yaml
- bash packages/casan-harness/scripts/bash/ci-harness-gate.sh   # all governance suites
- bash packages/casan-harness/scripts/bash/verify-audit-chain.sh
- bash packages/casan-harness/scripts/bash/sign-policy-bundle.sh verify
+- casan verify-harness
+- casan gate
 ```

-## 3. Environment knobs
-| Var | Default | Use |
-|---|---|---|
-| `CASAN_CI_RUN_FRONTEND` | 0 | 1 if you have a frontend workspace |
-| `CASAN_CI_RUN_BACKEND` | 0 | 1 to run backend tests |
-| `CASAN_CI_RUN_INFRA_LAB` | 0 | 1 to run the Docker infra lab |
-| `CASAN_CI_STEP_TIMEOUT_SEC` | 600 | raise to 1200 — some suites are model-backed and run ~450s; 600 flakes under load |
-| `CASAN_CI_SUITE_FILTER` | — | regex to run a subset of suites |
-| `CASAN_DOMAIN_ROOT` | apps/okr/domain | point at your project's domain |
+`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.

-## 4. Runner
+## 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` (and `node`/`npm` only if you enable apps/okr/frontend/backend tests).
+`bash`, `python3`, `openssl`, the approved global CASAN release, and the toolchain
+declared by the project manifest.

-## 5. Expected result
-`CI_GATE_SUMMARY PASS=<n> FAIL=0 SKIP=<k>`. Any FAIL fails the job (exit 1). The gate is
+## 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.

-## 6. This repo's own CI
-The source hub's active pipeline is `.gitea/workflows/ci.yml` (frontend tests → security
-gate → deploy). It already runs the gate from the promoted root layout
-(`packages/casan-harness/...`). Use it as a worked example.
+## 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 gate green as an invariant; every new control must ship a fail-able adversarial test.
+- 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: `bin/casan gate` (or a filtered subset).
+- For a quick local pre-push check: `casan gate`.
@@ -42,7 +42,7 @@ apps/<project>/domain/
 export CASAN_PROJECT_MANIFEST=apps/<project>/domain/project.manifest.json
 bin/casan gate                 # runs domain-dependent suites against your pack
 ```
-`domain_root` is also recorded per-project in `packages/casan-harness/level5/project-registry.json`
+`domain_root` is also recorded per-project in `packages/casan-harness/config/project-registry.json`
 so `bin/casan reuse` can prove multi-project reuse.

 ## Reference example
@@ -65,7 +65,7 @@ curl -fsSL -XPOST -H "Authorization: token $GITEA_TOKEN" \
 ## 5. Recommended cadence
 - Tag `vX.Y.Z` on `main` → CI green → build bundles → publish `core` + `devkit` (always),
  `platform` as `-preview`, `all-in-one-demo` for demos. Never publish `enterprise`.
- Keep `VERSION` and `packages/casan-harness/level5/harness-package.json` version in lockstep.
+- Keep `VERSION` and `packages/casan-harness/config/harness-package.json` version in lockstep.

 ## Automated release (recommended — already wired)
 `.gitea/workflows/release.yml` does all of the above automatically on a version tag. You
@@ -80,7 +80,7 @@ never hand a token to anyone — it lives in a CI secret.
 ```bash
 # bump the version everywhere first
 echo 1.0.1 > VERSION            # must match the tag
-# (also bump packages/casan-harness/level5/harness-package.json "version")
+# (also bump packages/casan-harness/config/harness-package.json "version")
 git commit -am "release v1.0.1"
 git tag -a v1.0.1 -m "CASAN v1.0.1"
 git push origin main --follow-tags