# CASAN Packaging Plan — Level-Based Source Hub

CASAN is **not** packaged as "core only". This repository is a **reusable source hub** that
holds (or scaffolds) all major CASAN components, and **releases are split by level** so a
downstream project adopts only the level it needs. Single source of truth for bundle
contents + maturity: [`packaging/levels.json`](../../packaging/levels.json).

## The four product editions

| Edition | Package names | Status | What it is |
|---|---|:--:|---|
| **1 — Core Harness** | `casan-core`, `casan-harness` | ✅ implemented | Minimal H1–H7 production runtime, native Codex/Claude operator façade, plus zero-dependency Local Assurance Viewer: latest/history, interactive H1–H7, H6 and on-demand export |
| **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. |

Editions are cumulative: DevKit extends Core, Platform extends DevKit, Enterprise extends
Platform. Historical numeric packaging levels remain compatibility aliases only.

Do not confuse editions with **CASAN Maturity L1–L5**. Maturity is an
evidence-based operational assessment. Installing an edition never grants a
maturity claim.

## Packaging principle
The source hub may contain all levels, **but releases must be split**. Do NOT force a
downstream project to install everything. A level that is not implemented must **fail
clearly** or be stamped **PREVIEW/INCOMPLETE** — never a fake-complete package.

## Release artifacts
Built by [`scripts/package-release.sh`](../../scripts/package-release.sh) into `dist/`:

| Command | Artifact | Status |
|---|---|:--:|
| `package-release.sh core` | `casan-core-vX.Y.Z.tar.gz` | ✅ builds |
| `package-release.sh devkit` | `casan-devkit-vX.Y.Z.tar.gz` | ✅ builds |
| `package-release.sh platform` | `casan-platform-preview-vX.Y.Z.tar.gz` | 🟡 preview (stamped) |
| `package-release.sh all-in-one-demo` | `casan-all-in-one-demo-vX.Y.Z.tar.gz` | ✅ builds (full runnable snapshot) |
| `package-release.sh enterprise` | — | 📋 refused (exit 3, future) |

Docker images (see `DOCKER_GUIDE.md`): `casan-harness:X.Y.Z` ✅ · `casan-platform:X.Y.Z` 🟡 preview · `casan-enterprise:X.Y.Z` 📋 future.

Every bundle carries `BUNDLE-MANIFEST.txt` + `SHA256SUMS`; preview bundles also carry
`PREVIEW-INCOMPLETE.txt`.

Core and every cumulative bundle also carry `.codex-plugin/`, `.claude-plugin/`
and `skills/casan/`. These files expose an optional native `$casan` operator
surface. They do not install the shared runtime or enable project hooks; the
production trust path remains global/vendored runtime installation followed by
`casan init` and client hook review.

## 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 centralized Control Plane/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 / single-project visual assurance** → `casan-core`.
- **New project adopting CASAN** → `casan-devkit` (install.sh scaffolds domain + CI).
- **Want centralized multi-project operations, RBAC and approvals** →
  `casan-platform` (preview). Core already provides single-project H1–H7, H6,
  history and on-demand run/H6 exports.
- **Enterprise governed console** → future; building blocks (RBAC/tenant/KMS/WORM/approval)
  already live in core.

## Repository map
```
packages/casan-harness/     # L1 core (implemented)
packages/casan-devkit/      # L2 adoption kit (implemented)
packages/casan-platform/    # L3 structure-only (preview; README)
packages/casan-enterprise/  # L4 structure-only (future; README)
skills/casan/               # native operator skill shared by Codex + Claude
.codex-plugin/              # Codex plugin manifest
.claude-plugin/             # Claude plugin + marketplace manifests
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
```

## Implemented now vs future
- **Implemented now:** Level 1 Core packaging, Level 2 DevKit packaging, release script,
  `bin/casan`, templates, docs, all-in-one-demo bundle.
- **Platform preview:** a shipped preview bundle containing the Control Panel,
  governed-chat MVP, and Evidence Pack Viewer. It is explicitly incomplete.
- **Structure + docs only:** Level 4 Enterprise. RBAC/tenant/KMS/WORM/approval
  building blocks exist, but no Enterprise artifact is shipped.
- **Not built in this task (do not assume present):** Attack Battery Viewer,
  Gitea webhook evidence publishing, enterprise managed deployment, HA/DR/SLA,
  external security assessment and compliance certification.

For customer claims and limitations, use
[`EDITION_FEATURE_LIMITATION_MATRIX.md`](EDITION_FEATURE_LIMITATION_MATRIX.md),
not this overview alone.