feat(packaging): level-based source hub — Core + DevKit packaging, Platform/Enterprise scaffold

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>
2026-07-08 15:55:37 +09:00
parent 4918012199
commit 8c20cfde9f
25 changed files with 1008 additions and 0 deletions
@@ -0,0 +1,25 @@
+# CASAN harness runtime image (Level 1/2). Runs the governance gate on a mounted repo.
+# Minimal: bash + python3 + openssl (+ git for repo-root marker). No app runtime.
+#
+# Build (from source hub or an extracted casan-devkit bundle):
+#   docker build -f packages/casan-devkit/Dockerfile.harness -t casan-harness:1.0.0 .
+# Run the gate against a project mounted at /workspace:
+#   docker run --rm -v "$PWD":/workspace -w /workspace casan-harness:1.0.0 casan gate
+FROM debian:bookworm-slim
+
+RUN apt-get update \
+ && apt-get install -y --no-install-recommends bash python3 openssl git ca-certificates rsync \
+ && rm -rf /var/lib/apt/lists/*
+
+# Ship the core harness + CLI inside the image.
+WORKDIR /opt/casan
+COPY packages/casan-harness/ ./packages/casan-harness/
+COPY bin/casan ./bin/casan
+COPY VERSION ./VERSION
+RUN chmod +x ./bin/casan && ln -s /opt/casan/bin/casan /usr/local/bin/casan
+
+# Default working dir is the mounted project.
+WORKDIR /workspace
+ENV CASAN_HARNESS_ROOT=/opt/casan/packages/casan-harness
+ENTRYPOINT ["casan"]
+CMD ["help"]
@@ -0,0 +1,31 @@
+# CASAN DevKit (Level 2 — Adoption Kit)
+
+Everything a new project needs to adopt the CASAN governance harness in a repeatable way.
+**Level 2 = Level 1 core harness + adoption tooling.**
+
+## Contents
+| Path | Purpose |
+|---|---|
+| `install.sh` | Install core harness + `bin/casan` into a target repo, scaffold a domain, register it |
+| `Dockerfile.harness` | Minimal image to run the gate on any mounted repo (`casan gate`) |
+| `templates/domain-pack/` | Per-project domain scaffold (input / golden-runs / corpus / `domain-pack.yaml`) |
+| `templates/gitea-workflow/ci.yml` | Reusable Gitea Actions gate workflow |
+| `templates/project/` | Minimal new-project skeleton that consumes the harness |
+
+## Quick adopt
+```bash
+# from a CASAN source hub or an extracted casan-devkit bundle
+packages/casan-devkit/install.sh --target ../my-project --project ticketing --domain "Ticketing"
+cd ../my-project
+# add requirement + golden baseline under apps/ticketing/domain/, then:
+CASAN_DOMAIN_ROOT=apps/ticketing/domain bin/casan gate
+bin/casan reuse     # HARNESS_REUSE_VALID
+```
+
+## Guides
+- `docs/packaging/ADOPTION_GUIDE.md` — end-to-end adoption
+- `docs/packaging/DOMAIN_PACK_GUIDE.md` — how to fill a domain pack
+- `docs/packaging/CI_GUIDE.md` — wire the gate into Gitea CI
+- `docs/packaging/DOCKER_GUIDE.md` — run/build the harness image
+
+Adoption is **config + domain only** — you never edit gate logic (H1→H7).
@@ -0,0 +1,72 @@
+#!/usr/bin/env bash
+# CASAN DevKit installer — adopt the CASAN harness into a target project.
+#
+# Copies the Level-1 core harness (packages/casan-harness + bin/casan) into a target
+# repo, scaffolds a per-project domain from the domain-pack template, and registers the
+# project in project-registry.json so `casan reuse` sees it. Does NOT touch harness gate
+# logic — adoption is config + domain only.
+#
+# Usage:
+#   packages/casan-devkit/install.sh --target <dir> --project <id> [--domain <name>]
+#
+# Run from a CASAN source hub (or an extracted casan-devkit bundle).
+set -euo pipefail
+
+TARGET="" PROJECT="" DOMAIN="custom"
+while [[ $# -gt 0 ]]; do
+  case "$1" in
+    --target)  TARGET="$2"; shift 2 ;;
+    --project) PROJECT="$2"; shift 2 ;;
+    --domain)  DOMAIN="$2"; shift 2 ;;
+    -h|--help) grep '^#' "$0" | sed 's/^# \{0,1\}//'; exit 0 ;;
+    *) echo "install: unknown arg $1" >&2; exit 64 ;;
+  esac
+done
+[[ -n "$TARGET" && -n "$PROJECT" ]] || { echo "install: --target and --project are required" >&2; exit 64; }
+
+SRC="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.." && pwd)"   # source-hub / bundle root
+[[ -d "$SRC/packages/casan-harness" ]] || { echo "install: cannot find packages/casan-harness under $SRC" >&2; exit 1; }
+
+echo "==> installing CASAN core into $TARGET (project=$PROJECT domain=$DOMAIN)"
+mkdir -p "$TARGET/packages" "$TARGET/bin" "$TARGET/apps/$PROJECT/domain"
+
+# 1) core harness + CLI
+rsync -a --exclude='__pycache__' --exclude='*.pyc' "$SRC/packages/casan-harness/" "$TARGET/packages/casan-harness/"
+cp "$SRC/bin/casan" "$TARGET/bin/casan"; chmod +x "$TARGET/bin/casan"
+[[ -f "$SRC/VERSION" ]] && cp "$SRC/VERSION" "$TARGET/VERSION"
+
+# 2) per-project domain from the domain-pack template
+rsync -a "$SRC/packages/casan-devkit/templates/domain-pack/" "$TARGET/apps/$PROJECT/domain/"
+
+# 3) Gitea CI workflow (adoption)
+mkdir -p "$TARGET/.gitea/workflows"
+cp "$SRC/packages/casan-devkit/templates/gitea-workflow/ci.yml" "$TARGET/.gitea/workflows/casan-ci.yml"
+
+# 4) register in project-registry.json (append if absent)
+REG="$TARGET/packages/casan-harness/level5/project-registry.json"
+python3 - "$REG" "$PROJECT" "$DOMAIN" <<'PY'
+import json, sys
+reg, pid, dom = sys.argv[1], sys.argv[2], sys.argv[3]
+data = json.load(open(reg))
+if not any(p.get("project_id") == pid for p in data["projects"]):
+    data["projects"].append({
+        "project_id": pid, "domain": dom, "domain_root": f"apps/{pid}/domain",
+        "harness_package": "fpt-casan-sdd-harness",
+        "harness_version": data["projects"][0]["harness_version"],
+        "status": "active",
+    })
+    json.dump(data, open(reg, "w"), indent=2, ensure_ascii=False); open(reg, "a").write("\n")
+    print(f"registered {pid}")
+else:
+    print(f"{pid} already registered")
+PY
+
+cat <<EOF
+
+==> done. Next steps in $TARGET:
+  1. Put your requirement in   apps/$PROJECT/domain/input/requirement.md
+  2. Add golden baseline in    apps/$PROJECT/domain/golden-runs/
+  3. Run the gate:             CASAN_DOMAIN_ROOT=apps/$PROJECT/domain bin/casan gate
+  4. Prove reuse:              bin/casan reuse   # expects HARNESS_REUSE_VALID
+See docs/packaging/ADOPTION_GUIDE.md and DOMAIN_PACK_GUIDE.md.
+EOF
@@ -0,0 +1 @@
+# Benign corpus for H4 false-positive budget. One .txt per benign sample.
@@ -0,0 +1 @@
+{"note":"red-team attack vectors for this domain — one JSON object per line"}
@@ -0,0 +1 @@
+{"note":"red-team vectors used by benign-fp-report / redteam metrics"}
@@ -0,0 +1,33 @@
+# CASAN Domain Pack — declarative domain adoption (template).
+# Copy this into apps/<project>/domain/ and fill it in. The harness reads domain data
+# from CASAN_DOMAIN_ROOT (defaults to apps/<project>/domain); this file documents what
+# each project must provide. See docs/packaging/DOMAIN_PACK_GUIDE.md.
+
+domain:
+  id: custom                      # short id, e.g. okr, ticketing, inventory
+  name: "Custom domain"
+  owner: your-team
+
+# Requirement/architecture the harness pipeline consumes (H3/traceability, source-gen).
+input:
+  requirement: input/requirement.md          # FR-xx table drives traceability
+  architecture: input/architecture.md        # optional tech-stack/context
+
+# Golden baselines for drift detection (H7). similarity=1.0 vs golden ⇒ no drift.
+golden_runs:
+  dir: golden-runs
+  # - artifact: plan   ->  golden-runs/plan.golden.txt
+
+# Red-team + benign corpus for H4 security scoring (attack recall + FP budget).
+corpus:
+  redteam: corpus/redteam-corpus.jsonl        # attack vectors (per-line JSON)
+  redteam_vectors: corpus/redteam-vectors.jsonl
+  benign: corpus/benign-corpus                # dir of benign .txt (false-positive budget)
+
+# Requirement→code→test map for the traceability gate (Plan-10).
+traceability_map: traceability-map.json
+
+# Optional per-domain threshold overrides (else harness defaults apply).
+thresholds:
+  # drift_min_similarity: 0.85
+  # fp_rate_max: 0.05
@@ -0,0 +1 @@
+# Golden baselines for drift-detect (H7). Add <artifact>.golden.txt here.
@@ -0,0 +1,17 @@
+# <Project> Requirement (template)
+
+> Replace this with your domain's requirements. The **FR-xx table below drives the
+> traceability gate** (Plan-10): every `FR-xx` must map to ≥1 code file + ≥1 test in
+> `traceability-map.json`. Keep the `| FR-xx | ... |` table format.
+
+## Functional Requirements
+
+| ID | Requirement |
+|------|-------------|
+| FR-01 | Example: user can log in and receive a session token |
+| FR-02 | Example: user can create a primary domain entity |
+| FR-03 | Example: user can update entity progress |
+
+## Notes
+- Add use cases, constraints, and UI expectations as normal prose below.
+- Secrets/credentials must NOT appear here (H4 input scan will block them).
@@ -0,0 +1 @@
+{}
@@ -0,0 +1,39 @@
+# CASAN harness gate — Gitea Actions workflow (adoption template).
+# Copy to .gitea/workflows/casan-ci.yml in your project. Assumes the CASAN core harness
+# lives at packages/casan-harness/ (via casan-devkit install.sh) and domain data at
+# apps/<project>/domain/. Runs the full governance gate on every push/PR.
+name: CASAN Gate
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  casan-gate:
+    runs-on: ci-runner
+    timeout-minutes: 45
+    env:
+      CASAN_CI_RUN_FRONTEND: "0"        # set 1 if your project has a frontend workspace
+      CASAN_CI_RUN_BACKEND: "0"         # set 1 if your project has backend tests
+      CASAN_CI_RUN_INFRA_LAB: "0"
+      CASAN_CI_STEP_TIMEOUT_SEC: "1200" # headroom; some suites are model-backed
+      # CASAN_DOMAIN_ROOT: apps/<project>/domain   # uncomment + set for your project
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Ensure toolchain
+        run: |
+          set -euo pipefail
+          command -v python3 >/dev/null || { apt-get update && apt-get install -y python3; }
+          python3 --version
+
+      - name: Run CASAN harness gate
+        run: bash packages/casan-harness/scripts/bash/ci-harness-gate.sh
+
+      - name: Verify audit chain + policy bundle
+        run: |
+          bash packages/casan-harness/scripts/bash/verify-audit-chain.sh
+          bash packages/casan-harness/scripts/bash/sign-policy-bundle.sh verify
@@ -0,0 +1,39 @@
+# CASAN harness gate — Gitea Actions workflow (adoption template).
+# Copy to .gitea/workflows/casan-ci.yml in your project. Assumes the CASAN core harness
+# lives at packages/casan-harness/ (via casan-devkit install.sh) and domain data at
+# apps/<project>/domain/. Runs the full governance gate on every push/PR.
+name: CASAN Gate
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  casan-gate:
+    runs-on: ci-runner
+    timeout-minutes: 45
+    env:
+      CASAN_CI_RUN_FRONTEND: "0"        # set 1 if your project has a frontend workspace
+      CASAN_CI_RUN_BACKEND: "0"         # set 1 if your project has backend tests
+      CASAN_CI_RUN_INFRA_LAB: "0"
+      CASAN_CI_STEP_TIMEOUT_SEC: "1200" # headroom; some suites are model-backed
+      # CASAN_DOMAIN_ROOT: apps/<project>/domain   # uncomment + set for your project
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Ensure toolchain
+        run: |
+          set -euo pipefail
+          command -v python3 >/dev/null || { apt-get update && apt-get install -y python3; }
+          python3 --version
+
+      - name: Run CASAN harness gate
+        run: bash packages/casan-harness/scripts/bash/ci-harness-gate.sh
+
+      - name: Verify audit chain + policy bundle
+        run: |
+          bash packages/casan-harness/scripts/bash/verify-audit-chain.sh
+          bash packages/casan-harness/scripts/bash/sign-policy-bundle.sh verify
@@ -0,0 +1,21 @@
+# <My Project> — CASAN-governed project (scaffold)
+
+Generated by `casan-devkit install.sh`. Layout:
+
+```
+packages/casan-harness/    # Level-1 core harness (installed; do not edit gate logic)
+bin/casan                  # CLI wrapper
+apps/<project>/domain/     # YOUR domain pack (input / golden-runs / corpus / domain-pack.yaml)
+.gitea/workflows/casan-ci.yml  # gate on push/PR
+.specify/                  # runtime state (created on first run: logs, audit, governance)
+```
+
+## Run
+```bash
+CASAN_DOMAIN_ROOT=apps/<project>/domain bin/casan gate    # full governance gate
+bin/casan run in.txt out.txt my_step -- <command>         # one governed step
+bin/casan reuse                                           # HARNESS_REUSE_VALID
+```
+
+Fill `apps/<project>/domain/` first (see DOMAIN_PACK_GUIDE.md). Upgrade the harness by
+re-running install.sh with a newer casan-devkit — your domain data is untouched.
@@ -0,0 +1,34 @@
+# CASAN Enterprise / Governed Agent Console (Level 4) · **FUTURE / structure-only**
+
+> Status: **FUTURE.** Documented + scaffolded, NOT implemented in this task.
+> `package-release.sh enterprise` **refuses to build** (no fake-complete package) — several
+> building blocks already exist inside the core harness, but the governed console itself
+> does not. Do not ship this as a product yet.
+
+Enterprise governed AI-SDLC console. Packages: `casan-enterprise`, `casan-governed-console`.
+
+## Building blocks that ALREADY exist (in core harness, reusable)
+| Capability | Where |
+|---|---|
+| RBAC | `packages/casan-harness/scripts/bash/rbac-check.py` |
+| Tenant isolation | `tenant-store.sh`, `tenant-paths.sh`, `tenant-registry-verify.sh`, `tenant-crypt.sh` |
+| Approval workflow | `approval-verify.sh`, `approval-sign.sh`, `approval-jwt-mint.py` |
+| KMS | `vault-kms.sh` |
+| WORM ledger | `worm-ledger.py` |
+| Kill-switch / quota | `kill-switch.sh`, `cost-spike-detect.sh` |
+| Loop governance | Plan-17 loop primitives (`loop-*.py`) |
+
+## Components still to build (NOT in this task)
+- Governed Chat Console (Plan-18) · Prompt Mode Router · Model Provider Management
+- Operator mode · Codegen mode · Agent/Skill Registry · policy-versioning UI
+
+## Why it refuses to package
+Per the packaging principle, a level that isn't implemented must **fail clearly** rather
+than emit a fake-complete artifact. Enterprise is `status: future` in
+`packaging/levels.json`, so `scripts/package-release.sh enterprise` exits non-zero with an
+explanation. When the console is built, flip its status to `preview`/`implemented`.
+
+## To implement later
+Sequence: Plan-14 (RBAC console) → Plan-13 (Control Plane) → Plan-18 (Governed Chat
+Console: read-only → operator → chat-as-loop → multi-tenant). Reuse the existing blocks
+above instead of re-writing them.
@@ -0,0 +1,30 @@
+# CASAN Platform (Level 3 — Productization UI) · **PREVIEW / structure-only**
+
+> Status: **PREVIEW.** Only the AgentOps **dashboard** exists today (shipped inside the core
+> harness). The rest of the platform UI is scaffolded here as structure + intent — NOT
+> implemented in this task. `package-release.sh platform` builds a clearly-stamped
+> `casan-platform-preview-*` bundle containing only what exists.
+
+Optional layer for teams that want UI / dashboard / visibility. Packages: `casan-platform`,
+`casan-control-panel`.
+
+## Components
+| Component | Status | Where |
+|---|---|---|
+| AgentOps Dashboard | ✅ exists | `packages/casan-harness/scripts/bash/dashboard-server.py` + `dashboard-serve.sh` (`casan dashboard`) |
+| Control Panel | 📋 planned | Plan-13 (`docs/plans/CASAN_PLAN_13_CONTROL_PLANE.md`) |
+| Evidence Pack Viewer | 📋 planned | reads `docs/output/casan/evidence-packs/` |
+| Attack Battery Viewer | 📋 planned | reads red-team corpus + H4 recall results |
+| Run History Viewer | 📋 planned | reads `.specify/logs/level5/pipeline-run.jsonl` |
+| Read-only Ask CASAN | 📋 planned | Plan-18 MVP-0 (read-only) |
+| Gitea webhook integration | 📋 planned | trigger gate / publish evidence on push |
+
+## Build (preview)
+```bash
+scripts/package-release.sh platform     # → dist/casan-platform-preview-vX.Y.Z.tar.gz
+```
+The bundle includes a `PREVIEW-INCOMPLETE.txt` marker. Do not treat it as a finished product.
+
+## To implement later
+Start from Plan-13 (Control Plane) + Plan-18 MVP-0 (Ask CASAN read-only). Keep the UI
+**read-only over harness artifacts** first; write/governed actions belong to Level 4.
				`@@ -0,0 +1 @@`
				`# Benign corpus for H4 false-positive budget. One .txt per benign sample.`
				`@@ -0,0 +1 @@`
				`{"note":"red-team attack vectors for this domain — one JSON object per line"}`
				`@@ -0,0 +1 @@`
				`{"note":"red-team vectors used by benign-fp-report / redteam metrics"}`
				`@@ -0,0 +1 @@`
				`# Golden baselines for drift-detect (H7). Add <artifact>.golden.txt here.`