fix template, remove okr, use casan.*

docs/guides/CASAN_PROJECT_SHELL_PRODUCTION.md

@@ -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.

docs/guides/CASAN_USING_FOR_REAL_PROJECTS_VI.md

@@ -256,20 +256,30 @@ Browser Chat
   → commit + CI + evidence pack
 ```
 
-**Luồng này chưa hoàn chỉnh trong bản hiện tại.** Những phần đã có là model
-router, agent/skill binding, RBAC, codegen draft, action gate, approval inbox,
-loop gate, tests, audit và evidence. Những phần còn thiếu để browser-only là:
+Luồng CLI/project-shell production hiện đã hoàn chỉnh ở lớp repository:
+
+```bash
+packages/casan-devkit/install.sh --target ../my-app --project my-app \
+  --domain "My App" --template nestjs-react
+cd ../my-app
+npm install
+bin/casan project validate --manifest apps/my-app/domain/project.manifest.json
+bin/casan pipeline --manifest apps/my-app/domain/project.manifest.json
+```
+
+Scaffolder tạo shell NestJS/React, Docker, CI, Domain Pack, manifest, quality profile và harness;
+pipeline lấy FR/SCR, artifact, source root, build/test và verification hoàn toàn từ manifest.
+Patch chỉ được áp sau approval và tự rollback khi verification thất bại.
+
+Phần còn thiếu chỉ dành cho trải nghiệm **browser-only** là:
 
 1. Workspace service quản lý nhiều file/diff.
-2. Skill `project-scaffold` và `apply-patch` được đăng ký rõ quyền.
-3. Action chạy build/test theo project, không phải command tự do.
-4. Approval để apply diff vào source tree.
-5. Git commit/revert gắn với provenance.
-6. Streaming token/delta và progress của từng bước build/test.
+2. UI gọi project-scaffold và hiển thị manifest form.
+3. Streaming token/delta và progress build/test trong browser.
+4. UI release/deployment adapter theo từng môi trường đích.
 
-Cho tới khi sáu phần này hoàn thành, cách dùng đúng là: **Chat tạo draft và
-evidence; con người hoặc một registered automation áp draft vào project.** Coding
-agent là tùy chọn, không phải dependency của CASAN.
+CLI, CI và registered automation đã có thể tạo/kiểm chứng/apply project; browser hiện vẫn dùng
+cho chat, evidence và approval thay vì thay thế hoàn toàn terminal/CI.
 
 ## 9. Cách dùng khuyến nghị cho môi trường hiện tại