CASAN Project Shell — Production Contract

Outcome

CASAN can create and govern multiple independent applications without embedding product knowledge in root .github, shared harness code, patch verification, or pipeline orchestration. Demo fixtures and Service Desk are consumers of the same versioned contract.

Trust boundaries

project.manifest.json selects one project and confines source/artifact paths.
The quality profile defines mandatory sections, command executable allowlist, and quality floor.
Requirement and architecture inputs are authoritative; generation preserves their IDs.
Commands are JSON argv arrays executed without shell interpolation.
Changed files select post-patch verification rules; an ambiguous project fails closed.
Review is AND(deterministic rules, model judge when available); models cannot override rules.
Build failure prevents tests; any failure prevents acceptance and triggers patch rollback.
CI creates a release candidate. Actual deployment requires an environment-specific approved adapter with identity, migration, health/smoke checks, and rollback.

Manifest ownership

Product teams own their Domain Pack and manifest. The CASAN platform team owns schema, shared quality profiles, scaffolder, harness, and generic .github/agents/casan.* entrypoints. Product- specific agent aliases are not shipped in the repository-level .github surface.

Create

packages/casan-devkit/project-scaffold.py \
  --target ../inventory \
  --project inventory \
  --name "Inventory" \
  --template nestjs-react \
  --with-harness

The operation is idempotent and does not overwrite a different existing file. After filling the requirement, architecture, traceability map, corpus, and approved golden baseline:

cd ../inventory
npm install
bin/casan project validate --manifest apps/inventory/domain/project.manifest.json
bin/casan pipeline --manifest apps/inventory/domain/project.manifest.json
bin/casan gate

Goal Orchestrator project creation

“Create production project shell” in Goal Orchestrator runs the same DevKit scaffolder with the NestJS/React template and bundled harness. The shell is isolated under apps/projects/<project-id>/; its own .github/workflows/ci.yml belongs to that project shell and does not add files to the source hub's root .github directory.

The control plane also writes casan.workspace.manifest.json beside the shell. This adapter makes the nested project paths and npm --prefix build/test commands explicit to the source hub, then registers that adapter in the central allowlist. If scaffolding, manifest creation, or registry update fails, the incomplete directory is removed and the project is not exposed to models.

Upgrade and migration

Keep schema_version: 1 until an explicit schema migrator is provided.
Quality profile changes require review because they change acceptance semantics.
Re-run the same scaffold to prove idempotency; use the DevKit upgrade process for harness code.
Do not edit generated golden output merely to pass drift. Baselines require independent approval.
Existing repositories may use adoption-only mode and add a manifest after declaring accurate source roots and argv commands.

Verification evidence

Automated tests cover valid manifests, traversal rejection, command allowlisting, conflicting-file protection, idempotent scaffold/harness registration, generated NestJS/React build and tests, demo-fixture compatibility, Service Desk isolation, source-generation review loops, and per-project patch verification command selection.

3.6 KiB Raw Blame History