1.9 KiB
CASAN Multi-Project Repository Instructions
This repository contains shared CASAN platform code and multiple independently governed applications. Never infer that the active project is OKR from the repository location.
Project selection is mandatory
Before changing application code, locate exactly one apps/<project>/domain/project.manifest.json:
- Prefer
CASAN_PROJECT_MANIFESTwhen supplied. - Otherwise select the manifest whose
source_rootscontains every target file. - If zero or multiple manifests match, stop and request an explicit project selection.
The selected manifest is authoritative for project ID, source roots, requirement input, architecture input, quality profile, build/test argv commands, verification mapping, and artifact namespace. Paths must remain repository-relative and inside the repository root.
Implementation contract
- Read the manifest's requirement and architecture documents before generating code.
- Every behavior must trace to a requirement ID; do not invent product functionality.
- Follow the selected architecture and use only its approved dependencies.
- Keep application code inside manifest
source_roots. - Run manifest build and test commands without shell interpolation.
- Run every verification rule matching changed files.
- A draft is not accepted until build, test, security, traceability, review, and evidence gates pass.
- Never weaken a gate, golden baseline, test, corpus, or threshold to make a project pass.
- Shared CASAN code must not contain product-specific paths, roles, entities, endpoints, or fixtures.
Repository-wide files
Root .github, packages/casan-harness, packages/casan-devkit, bin, and shared scripts
must remain project-neutral. Product-specific knowledge belongs in the selected Domain Pack,
project manifest, architecture, requirement, quality extension, or explicitly named legacy alias.