CASAN/docs/packaging/DOMAIN_PACK_GUIDE.md

CASAN Domain Pack Guide

A Domain Pack is optional per-project data the harness needs for a project-specific SRS→test pipeline. Core prompt assurance and visual reporting do not require it. A pack commonly lives at apps/<project>/domain/. The harness code (packages/casan-harness/) never contains domain data — this is what makes it reusable.

Scaffold template: packages/casan-devkit/templates/domain-pack/.

Layout

apps/<project>/domain/
├── domain-pack.yaml           # manifest describing this pack
├── project.manifest.json      # executable project/build/test/verification contract
├── input/
│   ├── requirement.md         # FR-xx table drives the traceability gate
│   └── architecture.md        # optional tech-stack/context
├── golden-runs/
│   └── <artifact>.golden.txt  # baseline for drift detection (H7)
├── corpus/
│   ├── redteam-corpus.jsonl   # attack vectors (H4 recall) — one JSON per line
│   ├── redteam-vectors.jsonl  # vectors for benign-fp-report / redteam metrics
│   └── benign-corpus/*.txt    # benign samples (H4 false-positive budget)
└── traceability-map.json      # FR-xx → code files + test files (+ optional symbols/lines)

Each piece

• input/requirement.md — must contain a | FR-xx | ... | table. The traceability gate (Plan-10) requires every FR-xx to map to ≥1 existing code file and ≥1 test file. No secrets/PII (the H4 input scan blocks them).
• golden-runs/ — a canonical "good" artifact per pipeline output. drift-detect compares a run against it; similarity 1.0 = no drift. Real drift detection is proven separately.
• corpus/ — red-team attack vectors (scored for H4 recall) + a benign corpus (bounds the false-positive rate). Domain-specific injections make the H4 score meaningful.
• traceability-map.json — {"FR-01": {"name": "...", "code": ["apps/okr/backend/src/...", {"file":"...","symbols":["Foo"],"lines":[12]}], "tests": ["..."]}}. Symbol/line refs are optional but tighten the gate.
• domain-pack.yaml — documents the above + optional threshold overrides.
• project.manifest.json — selects authoritative inputs, source roots, quality profile, feature/artifact namespace, argv build/test commands, and per-path verification commands.

Wire it up

casan domain discover
casan domain configure apps/<project>/domain/project.manifest.json
casan domain status

# Existing automation remains supported
export CASAN_PROJECT_MANIFEST=apps/<project>/domain/project.manifest.json
bin/casan gate                 # runs domain-dependent suites against your pack

casan domain configure writes only .casan/domain.json; it references an existing in-project manifest and never copies, rewrites or invents application requirements, source mappings or tests.

domain_root is also recorded per-project in packages/casan-harness/config/project-registry.json so bin/casan reuse can prove multi-project reuse.

Reference example

The OKR app's own pack is the worked example: apps/okr/domain/ (golden-runs, corpus, input, traceability-map). Copy its shape for your domain.

The project manifest is validated fail-closed by both Node and Python runtimes. Paths are confined to the repository, commands are argv arrays checked against the quality-profile executable allowlist, and every source root must map to a post-patch verification rule.