thanhnvandClaude Opus 4.8
8c20cfde9f
Organize CASAN as a reusable source hub with SPLIT releases so downstream adopts only the level it needs (packaging/levels.json is the single source of truth). Implemented now: - Level 1 Core: bin/casan CLI (run/gate/test/verify/reuse/dashboard) + VERSION. - Level 2 DevKit: packages/casan-devkit (install.sh, Dockerfile.harness, templates: project scaffold, domain-pack, gitea-workflow). - scripts/package-release.sh core|devkit|platform|all-in-one-demo — builds split bundles into dist/ (BUNDLE-MANIFEST + SHA256SUMS); platform is stamped PREVIEW/INCOMPLETE; enterprise (future) is REFUSED (exit 3, no fake-complete package). Bundles verified: extract → bin/casan works, deterministic + domain suites pass, casan reuse VALID. - docs/packaging: CASAN_PACKAGING_PLAN + ADOPTION + CI + DOMAIN_PACK + GITEA_PACKAGE + DOCKER. Structure + docs only: - Level 3 packages/casan-platform (dashboard exists; control-panel/viewers pending). - Level 4 packages/casan-enterprise (RBAC/tenant/KMS/WORM/approval exist in core; governed console pending). No Chat Console/RBAC-console/tenant-console/model-mgmt built in this task. Harness change (enables extracted bundles to self-resolve): casan-paths.sh + the Python project_root() walk-ups now accept a second root marker `packages/casan-harness` in addition to `.specify`, so a freshly-unpacked core/devkit/demo bundle (no `.specify` yet) roots correctly and creates state on first run. In an adopted repo `.specify` still matches first. policy-bundle.yaml paths corrected to packages/casan-harness (re-signed). Full gate 64/0/3. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4.0 KiB
4.0 KiB
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.
The four levels
| 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 |
| 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, Evidence/Attack/Run-History viewers, read-only Ask CASAN, Gitea webhook. Only the AgentOps dashboard exists today. |
| 4 — Enterprise / Governed Console | casan-enterprise, casan-governed-console |
📋 future | Governed Chat Console, Prompt Router, Model-Provider Mgmt, Operator/Codegen modes, Agent/Skill Registry, RBAC, approval, tenant isolation, KMS/WORM, policy versioning |
Levels are cumulative: DevKit extends Core, Platform extends DevKit, Enterprise extends Platform.
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 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.
Who adopts what
- Governance-harness-only / BJT initial / CI gate →
casan-core. - New project adopting CASAN →
casan-devkit(install.sh scaffolds domain + CI). - Want dashboards/visibility →
casan-platform(preview; dashboard today). - 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)
bin/casan # CLI
scripts/package-release.sh # release packager
packaging/levels.json # bundle contents + maturity (source of truth)
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. - Structure + docs only: Level 3 Platform (dashboard exists; rest scaffolded), Level 4 Enterprise (RBAC/tenant/KMS/WORM/approval exist in core; governed console not built).
- Not built in this task (do not assume present): Governed Chat Console, Prompt Mode Router, Model Provider Management, Operator/Codegen modes, Agent/Skill Registry, RBAC/ tenant console UX.