# 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

1. `project.manifest.json` selects one project and confines source/artifact paths.
2. The quality profile defines mandatory sections, command executable allowlist, and quality floor.
3. Requirement and architecture inputs are authoritative; generation preserves their IDs.
4. Commands are JSON argv arrays executed without shell interpolation.
5. Changed files select post-patch verification rules; an ambiguous project fails closed.
6. Review is `AND(deterministic rules, model judge when available)`; models cannot override rules.
7. Build failure prevents tests; any failure prevents acceptance and triggers patch rollback.
8. 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

```bash
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:

```bash
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.