fix template, remove okr, use casan.*

2026-07-18 16:45:31 +07:00
parent 0dfd1742d3
commit 13fae3e6c3
249 changed files with 4881 additions and 5702 deletions
@@ -0,0 +1,75 @@
+# 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. OKR 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, OKR
+compatibility, Service Desk isolation, source-generation review loops, and per-project patch
+verification command selection.