docs: align all documentation with the new repo structure

Update agent protocols (.claude/agents, .github/agents), guides, runbooks and READMEs to the post-restructure layout: .specify/{scripts,tests,security,config,templates, governance,memory,level5-config} -> packages/casan-harness/...; docs/input + golden-runs + traceability-map -> apps/okr/domain/...; drop AINative_OKR_CASAN5/ prefix. Runtime-state paths (.specify/logs, .specify/agentops, .specify/level5/central-governance) kept as-is. Historical evidence under docs/output/ left untouched (immutable run records). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-08 14:36:27 +09:00
parent 36a4812ef3
commit 18997caf49
53 changed files with 167 additions and 167 deletions
@@ -49,7 +49,7 @@ Read the following files to gather context:
 2. **System overview**: `docs/output/srs-systems/srs-overview-system.md` — system-wide context
 3. **Module SRS folder**: `docs/output/srs-systems/<mod-folder>/` — module wireframes & details
 4. **Technical architecture**: `docs/technical_architecture.md` — mandatory tech stack
-5. **BD template**: `.specify/templates/bd-template.md` — output structure template
+5. **BD template**: `packages/casan-harness/templates/bd-template.md` — output structure template

 ---

@@ -57,7 +57,7 @@ Read the following files to gather context:

 Generate the BD document at: `docs/output/ipa-docs/bd/bd-<mod-id>-<name>.md`

-The output **MUST** follow the structure defined in `.specify/templates/bd-template.md`:
+The output **MUST** follow the structure defined in `packages/casan-harness/templates/bd-template.md`:

 | § | Section | Content |
 |---|---------|---------|
@@ -80,7 +80,7 @@ The output **MUST** follow the structure defined in `.specify/templates/bd-templ
 2. Read `docs/output/srs-systems/srs-overview-system.md` for system context
 3. Read module wireframe/detail files from `docs/output/srs-systems/<mod-folder>/`
 4. Read `docs/technical_architecture.md` for tech stack constraints
-5. Read `.specify/templates/bd-template.md` for the output template structure
+5. Read `packages/casan-harness/templates/bd-template.md` for the output template structure

 Log: `[PROCESSING] Input file loading complete`

@@ -151,10 +151,10 @@ report-nn: <NN>           # for speckit.implement only
 report-phase: <phase>     # for speckit.implement only
 casan-harness:
  required: true
-  h4-security: ".specify/scripts/bash/security-check.sh"
-  h5-governance: ".specify/scripts/bash/governance-check.sh"
-  h6-agentops: ".specify/scripts/bash/agent-metrics.sh"
-  wrapper: ".specify/scripts/bash/casan-harness.sh"
+  h4-security: "packages/casan-harness/scripts/bash/security-check.sh"
+  h5-governance: "packages/casan-harness/scripts/bash/governance-check.sh"
+  h6-agentops: "packages/casan-harness/scripts/bash/agent-metrics.sh"
+  wrapper: "packages/casan-harness/scripts/bash/casan-harness.sh"
  evidence:
    trace-dir: ".specify/logs/trace"
    audit-log: ".specify/logs/audit/audit.jsonl"
@@ -174,20 +174,20 @@ For every delegated step, Boss MUST:
 1. Write the step input payload to `docs/output/output_logs/<feature-id>/casan/<step>-input.txt`.
 2. Run H4 input security:
   ```bash
-   .specify/scripts/bash/security-check.sh <step-input> <safe-input> input
+   packages/casan-harness/scripts/bash/security-check.sh <step-input> <safe-input> input
   ```
 3. Run H5 governance:
   ```bash
-   .specify/scripts/bash/governance-check.sh <safe-input> <approved-input> <action-name>
+   packages/casan-harness/scripts/bash/governance-check.sh <safe-input> <approved-input> <action-name>
   ```
 4. Execute the real agent/tool step under H6 metrics:
   ```bash
   CASAN_AGENT_NAME=<agent> CASAN_STEP_NAME=<step> \
-     .specify/scripts/bash/agent-metrics.sh <approved-input> <raw-output> -- <real command>
+     packages/casan-harness/scripts/bash/agent-metrics.sh <approved-input> <raw-output> -- <real command>
   ```
 5. Run H4 output security:
   ```bash
-   .specify/scripts/bash/security-check.sh <raw-output> <final-output> output
+   packages/casan-harness/scripts/bash/security-check.sh <raw-output> <final-output> output
   ```
 6. Update `pipeline-context.yaml` with the H4/H5/H6 trace paths and status.

@@ -204,7 +204,7 @@ Side-effecting action names:

 High-risk actions are denied by default unless `CASAN_APPROVAL_DECISION=approve` and `CASAN_APPROVER=<name>` are set in the environment. Boss must log denied actions and stop that action instead of bypassing governance.

-For side-effecting actions, Boss MUST also call `.specify/scripts/bash/tool-registry-gate.sh <action-name>` with `CASAN_IDEMPOTENCY_KEY` set. Cache hits are allowed only when H4 input, H5 governance, H6 metrics, and H4 output evidence are still written for the current run.
+For side-effecting actions, Boss MUST also call `packages/casan-harness/scripts/bash/tool-registry-gate.sh <action-name>` with `CASAN_IDEMPOTENCY_KEY` set. Cache hits are allowed only when H4 input, H5 governance, H6 metrics, and H4 output evidence are still written for the current run.

 ---

@@ -54,7 +54,7 @@ Read the following files:
 3. **Feature spec**: `docs/output/specs/<feature-id>/spec.md` — feature specification
 4. **Implementation plan**: `docs/output/specs/<feature-id>/plan.md` — tech plan & data model
 5. **Technical architecture**: `docs/technical_architecture.md` — mandatory tech stack
-6. **DD template**: `.specify/templates/dd-template.md` — output structure template
+6. **DD template**: `packages/casan-harness/templates/dd-template.md` — output structure template

 ---

@@ -62,7 +62,7 @@ Read the following files:

 Generate the DD document at: `docs/output/ipa-docs/dd/dd-<mod-id>-<name>.md`

-The output **MUST** follow the structure defined in `.specify/templates/dd-template.md`:
+The output **MUST** follow the structure defined in `packages/casan-harness/templates/dd-template.md`:

 | § | Section | Content |
 |---|---------|---------|
@@ -88,7 +88,7 @@ The output **MUST** follow the structure defined in `.specify/templates/dd-templ
 2. Read SRS for requirements & NFR
 3. Read spec.md and plan.md
 4. Read `docs/technical_architecture.md`
-5. Read `.specify/templates/dd-template.md`
+5. Read `packages/casan-harness/templates/dd-template.md`

 Log: `[PROCESSING] Input file loading complete`

@@ -52,7 +52,7 @@ You are a Senior Code Reviewer specializing in Node.js/NestJS/TypeScript impleme
 $ARGUMENTS
 ```

-If `$ARGUMENTS` is empty, run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` to detect the current active feature.
+If `$ARGUMENTS` is empty, run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` to detect the current active feature.

 ## Constraints

@@ -82,7 +82,7 @@ Add a dedicated section in the report:

 ## Setup

-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly -RequireTasks -IncludeTasks` and parse:
+1. Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly -RequireTasks -IncludeTasks` and parse:
   - `FEATURE_DIR` — feature specs directory
   - `AVAILABLE_DOCS` — list of generated artifacts
 2. Load reference documents:
@@ -90,7 +90,7 @@ Add a dedicated section in the report:
   - `docs/output/specs/<feature-id>/tasks.md` — task completion checklist
   - `docs/output/specs/<feature-id>/plan.md` — implementation plan
   - `docs/output/specs/<feature-id>/data-model.md` — entity model
-   - `.specify/memory/constitution.md` — project Constitution
+   - `packages/casan-harness/memory/constitution.md` — project Constitution
   - `docs/technical_architecture.md` — system architecture
 3. Identify implementation module directory (e.g., `backend/src/modules/workspace/`)

@@ -64,7 +64,7 @@ Optional: feature-id (e.g. `001-xxx`). If empty, auto-detect from the active bra

 ## Setup

-Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root and parse:
+Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root and parse:

 - `FEATURE_DIR` — absolute path to the feature specs directory
 - `FEATURE_SPEC` — path to `spec.md`
@@ -75,7 +75,7 @@ Load the following documents:
 - `docs/output/specs/<feature-id>/contracts/` — API contracts (**warn** if missing)
 - `docs/output/specs/<feature-id>/research.md` — library/framework decisions
 - `docs/output/specs/<feature-id>/quickstart.md` — integration scenarios
- `.specify/memory/constitution.md` — project Constitution
+- `packages/casan-harness/memory/constitution.md` — project Constitution
 - `docs/technical_architecture.md` — system architecture

 ---
@@ -61,7 +61,7 @@ Optional: feature-id (e.g. `001-xxx`). If empty, auto-detect from the active bra

 ## Setup

-Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root and parse:
+Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root and parse:

 - `FEATURE_DIR` — absolute path to the feature specs directory
 - `FEATURE_SPEC` — path to `spec.md`
@@ -69,7 +69,7 @@ Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from
 Load the following reference documents:
 - `docs/output/srs-systems/srs-overview-system.md` — system-level SRS (traceability source)
 - `docs/technical_architecture.md` — technical architecture (feasibility reference)
- `.specify/memory/constitution.md` — project Constitution (compliance gate)
+- `packages/casan-harness/memory/constitution.md` — project Constitution (compliance gate)
 - Feature-specific SRS if exists: `docs/output/ipa-docs/srs/srs-<module>.md`

 ---
@@ -86,7 +86,7 @@ Priority rule: `srs-overview-system.md` → `srs-mod<XX>-detail.md` → `srs-mod

 1. Load `docs/output/srs-systems/srs-overview-system.md` to get system context, then identify the module folder matching `$ARGUMENTS` (e.g., `docs/output/srs-systems/mod01-xxx/`). Load `srs-mod<XX>-detail.md` and `srs-mod<XX>-wireframe.md` from that folder. Enumerate all FEAs belonging to the target module.
 2. Cross-reference `srs-mod<XX>-detail.md` and `srs-mod<XX>-wireframe.md` to fill in any missing details for each FEA.
-3. Generate a complete SRS document using **`.specify/templates/srs-template.md`** as the base template. Follow the section mapping in **SRS Output Structure** below to populate each template section with module-specific content.
+3. Generate a complete SRS document using **`packages/casan-harness/templates/srs-template.md`** as the base template. Follow the section mapping in **SRS Output Structure** below to populate each template section with module-specific content.
   > ⚠️ **MANDATORY: TABLE OF CONTENTS** — The SRS document **MUST** include a `## TABLE OF CONTENTS` section immediately after the `Record of Change` table (before §1). Generate a complete, clickable table of contents listing all `##` and `###` level headings with Markdown anchor links. This matches the structure in `srs-template.md`. Do NOT skip this section.
 4. Save to `docs/output/ipa-docs/srs/srs-<MOD-ID>-<module-short-name>.md`.  
  Example: MOD-01 (OKR management module) → `docs/output/ipa-docs/srs/srs-mod01-okr-management.md`
@@ -94,7 +94,7 @@ Priority rule: `srs-overview-system.md` → `srs-mod<XX>-detail.md` → `srs-mod

 ## SRS Output Structure

-Start from a copy of **`.specify/templates/srs-template.md`** and populate every section as follows.
+Start from a copy of **`packages/casan-harness/templates/srs-template.md`** and populate every section as follows.

 **File header** — replace placeholders:

@@ -39,7 +39,7 @@ Mission: produce a **complete, exhaustive, system-wide SRS** covering all module

 If `$ARGUMENTS` specifies a file or folder path, **read that path first** as the primary source. Otherwise, read in this priority order and cross-reference:

-1. **`docs/input/okr-requirement.md`** — Original product requirement document. **Primary source of truth.** Contains functional requirements, screen definitions, field rules, user flows, and validation constraints.
+1. **`apps/okr/domain/input/okr-requirement.md`** — Original product requirement document. **Primary source of truth.** Contains functional requirements, screen definitions, field rules, user flows, and validation constraints.
 2. **`docs/technical_architecture.md`** — Technology stack recommendations. Use for the technology recommendation section only (not for functional requirements).

 **Priority rule:** User-specified input (`$ARGUMENTS`) → Special Specification (Spec) → system-overview.md → `[TBC-XX]` if all are insufficient.
@@ -29,7 +29,7 @@ You are the **Independent QA Agent (okr.testkit)** for OKR web app. Your role is
 **Output:**
 - `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` — Comprehensive test case document

-**Template:** `.specify/templates/testcase-template.md` — Use this template for the output format. Fill in all sections with actual test cases generated from the input documents.
+**Template:** `packages/casan-harness/templates/testcase-template.md` — Use this template for the output format. Fill in all sections with actual test cases generated from the input documents.

 **Process:**

@@ -43,11 +43,11 @@ You are the **Independent QA Agent (okr.testkit)** for OKR web app. Your role is
   - **API Tests (AT)** — From DD internal API contracts + BD external interface → Jest + Supertest
   - **UI/E2E Tests (E2E)** — From BD screen designs + SRS user flows → Playwright
   - **Integration Tests (IT)** — From DD sequence diagrams + data flow → testcontainers-node
-4. **Write test case document** using template `.specify/templates/testcase-template.md` to `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` with full traceability
+4. **Write test case document** using template `packages/casan-harness/templates/testcase-template.md` to `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` with full traceability

 #### Test Case Output

-The output file MUST follow the template at `.specify/templates/testcase-template.md`. Key sections:
+The output file MUST follow the template at `packages/casan-harness/templates/testcase-template.md`. Key sections:
 - **§1 Unit Tests (UT)** — From DD class/method designs → Jest
 - **§2 API Tests (AT)** — From DD internal API contracts + BD external interface → Jest + Supertest
 - **§3 UI/E2E Tests (E2E)** — From BD screen designs + SRS user flows → Playwright
@@ -59,7 +59,7 @@ The template contains embedded generation rules (HTML comments) for each section

 #### ⛔ MANDATORY TABLE FORMAT — STRICTLY ENFORCED

-Each section (UT, AT, E2E, IT) MUST be output as **one single consolidated master table** per section, exactly matching the column structure shown in the template `.specify/templates/testcase-template.md`.
+Each section (UT, AT, E2E, IT) MUST be output as **one single consolidated master table** per section, exactly matching the column structure shown in the template `packages/casan-harness/templates/testcase-template.md`.

 **⛔ PROHIBITED formats (DO NOT USE):**
 - Individual `| Item | Content |` two-column tables for each test case
@@ -162,10 +162,10 @@ Each section (UT, AT, E2E, IT) MUST be output as **one single consolidated maste

 8. **Write test execution summary report** to `docs/output/output_logs/<feature-id>/reports/<NN>-testkit-report.md`:

-**Template:** `.specify/templates/testreport-template.md` — Load this template and fill in all sections with actual test execution results.
+**Template:** `packages/casan-harness/templates/testreport-template.md` — Load this template and fill in all sections with actual test execution results.

 **Process:**
-1. Read the template file: `.specify/templates/testreport-template.md`
+1. Read the template file: `packages/casan-harness/templates/testreport-template.md`
 2. Read `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` and extract ALL TC-IDs from master tables. **Same rules as Phase D apply: exact TC-IDs, zero omissions, all 4 sections mandatory.**
 3. Fill in all placeholders with actual test execution data:
   - §1 Test Execution Summary — aggregate pass/fail/skip counts from Phase B
@@ -294,7 +294,7 @@ Code (TypeScript/JavaScript test scripts) and file paths remain in English.

 This agent is invoked by the Boss orchestrator at two specific points:

-1. **STEP 8b** (after DD): `gen-testcases <feature-id>` → produces `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` using template `.specify/templates/testcase-template.md`
+1. **STEP 8b** (after DD): `gen-testcases <feature-id>` → produces `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` using template `packages/casan-harness/templates/testcase-template.md`
 2. **STEP 12** (after build, FINAL QA AUDIT): `run-tests <feature-id>` → produces test scripts + executes + produces:
   - Pipeline report: `docs/output/output_logs/<feature-id>/reports/<NN>-testkit-report.md` (Phase C)
   - IPA detail report: `docs/output/ipa-docs/testreport/testreport-<MOD-ID>-<module-short-name>.md` (Phase D)
@@ -10,38 +10,38 @@ Raise the SDD Speckit OKR pipeline from CASAN Level 3 to Level 4 by making Secur

 | Harness | Runtime control | Script | Evidence |
 |---|---|---|---|
-| H4 Security | Prompt injection block, PII masking, secret redaction, output filtering | `.specify/scripts/bash/security-check.sh` | `.specify/logs/trace/security-*.json`, `.specify/logs/audit/security.jsonl` |
-| H5 Governance | Risk scoring, non-interactive approval policy, append-only hash-chain audit | `.specify/scripts/bash/governance-check.sh` | `.specify/logs/trace/governance-*.json`, `.specify/logs/audit/audit.jsonl` |
-| H6 AgentOps | Latency, retry, token, cost, status, alert tracking | `.specify/scripts/bash/agent-metrics.sh` | `.specify/logs/trace/agentops-*.json`, `.specify/logs/cost/metrics.jsonl`, `.specify/agentops/alerts.log` |
-| H2 Tool Registry | Side-effect registry, idempotency key, per-call audit | `.specify/scripts/bash/tool-registry-gate.sh` | `.specify/logs/level5/tool-registry.jsonl`, `.specify/logs/audit/tool-calls.jsonl` |
+| H4 Security | Prompt injection block, PII masking, secret redaction, output filtering | `packages/casan-harness/scripts/bash/security-check.sh` | `.specify/logs/trace/security-*.json`, `.specify/logs/audit/security.jsonl` |
+| H5 Governance | Risk scoring, non-interactive approval policy, append-only hash-chain audit | `packages/casan-harness/scripts/bash/governance-check.sh` | `.specify/logs/trace/governance-*.json`, `.specify/logs/audit/audit.jsonl` |
+| H6 AgentOps | Latency, retry, token, cost, status, alert tracking | `packages/casan-harness/scripts/bash/agent-metrics.sh` | `.specify/logs/trace/agentops-*.json`, `.specify/logs/cost/metrics.jsonl`, `.specify/agentops/alerts.log` |
+| H2 Tool Registry | Side-effect registry, idempotency key, per-call audit | `packages/casan-harness/scripts/bash/tool-registry-gate.sh` | `.specify/logs/level5/tool-registry.jsonl`, `.specify/logs/audit/tool-calls.jsonl` |

 ## Mandatory Gate Pattern

 Before every delegated step:

 ```bash
-.specify/scripts/bash/security-check.sh "$STEP_INPUT" "$SAFE_INPUT" input
-.specify/scripts/bash/governance-check.sh "$SAFE_INPUT" "$APPROVED_INPUT" "$ACTION_NAME"
+packages/casan-harness/scripts/bash/security-check.sh "$STEP_INPUT" "$SAFE_INPUT" input
+packages/casan-harness/scripts/bash/governance-check.sh "$SAFE_INPUT" "$APPROVED_INPUT" "$ACTION_NAME"
 ```

 Around every execution or agent/tool invocation:

 ```bash
 CASAN_AGENT_NAME="<agent>" CASAN_STEP_NAME="<step>" \
-  .specify/scripts/bash/agent-metrics.sh "$APPROVED_INPUT" "$RAW_OUTPUT" -- <real command>
+  packages/casan-harness/scripts/bash/agent-metrics.sh "$APPROVED_INPUT" "$RAW_OUTPUT" -- <real command>
 ```

 After every generated artifact or agent response:

 ```bash
-.specify/scripts/bash/security-check.sh "$RAW_OUTPUT" "$FINAL_OUTPUT" output
+packages/casan-harness/scripts/bash/security-check.sh "$RAW_OUTPUT" "$FINAL_OUTPUT" output
 ```

 When a step can be represented as a single command, Boss MAY use the wrapper:

 ```bash
 CASAN_AGENT_NAME="<agent>" CASAN_STEP_NAME="<step>" \
-  .specify/scripts/bash/casan-harness.sh "$STEP_INPUT" "$FINAL_OUTPUT" "$ACTION_NAME" -- <real command>
+  packages/casan-harness/scripts/bash/casan-harness.sh "$STEP_INPUT" "$FINAL_OUTPUT" "$ACTION_NAME" -- <real command>
 ```

 Cache hits MUST NOT bypass CASAN evidence. A cached wrapper run still has to produce fresh H4 input, H5 governance, H6 metrics, and H4 output traces for the current execution.
@@ -105,4 +105,4 @@ Boss orchestrator also enforces:
 1. **Self-Security Audit:** Every agent reads `protocols/agent-self-security-rules.md` before output is accepted.
 2. **Self-Governance Audit:** Every agent reads `protocols/governance-risk-policy.md` before high-risk action planning.
 3. **Hallucination Checklist:** Every review agent reads `protocols/hallucination-prevention-checklist.md` during review gates.
-4. **Tool Registry Policy:** Every side-effecting tool is checked against `protocols/tool-registry-policy.md` and `.specify/level5/tool-registry.yaml`.
+4. **Tool Registry Policy:** Every side-effecting tool is checked against `protocols/tool-registry-policy.md` and `packages/casan-harness/level5/tool-registry.yaml`.
@@ -4,7 +4,7 @@ Giao thức này cung cấp bộ checklist bắt buộc để các Review Agents

 ## 1. Nguyên lý đối chiếu chéo (Grounding)
 - Không có bất kỳ chi tiết thiết kế hoặc logic code nào được phép tự ý phát minh nếu không có cơ sở chứng cứ rõ ràng từ:
-  - Tài liệu Yêu cầu nghiệp vụ (`docs/input/okr-requirement.md`).
+  - Tài liệu Yêu cầu nghiệp vụ (`apps/okr/domain/input/okr-requirement.md`).
  - Bản vẽ thiết kế Basic Design (`bd-*.md`) hoặc Detail Design (`dd-*.md`).
  - Tệp thông tin Context hiện tại (`pipeline-context.yaml`).

@@ -32,22 +32,22 @@ tech-stack:
 casan-harness:
  level-target: 5
  h4-security:
-    policy: .specify/security/prompt-filter.yaml
-    output-policy: .specify/security/output-policy.yaml
+    policy: packages/casan-harness/security/prompt-filter.yaml
+    output-policy: packages/casan-harness/security/output-policy.yaml
    audit-log: .specify/logs/audit/security.jsonl
  h5-governance:
-    approval-flow: .specify/governance/approval-flow.yaml
-    risk-registry: .specify/governance/risk-registry.yaml
+    approval-flow: packages/casan-harness/governance/approval-flow.yaml
+    risk-registry: packages/casan-harness/governance/risk-registry.yaml
    audit-log: .specify/logs/audit/audit.jsonl
  h6-agentops:
    metrics-policy: .specify/agentops/metrics.yaml
    metrics-log: .specify/logs/cost/metrics.jsonl
    alert-log: .specify/agentops/alerts.log
  h2-tool-registry:
-    registry: .specify/level5/tool-registry.yaml
+    registry: packages/casan-harness/level5/tool-registry.yaml
    audit-log: .specify/logs/level5/tool-registry.jsonl
  h7-drift:
-    golden-dir: .specify/level5/golden-runs/
+    golden-dir: apps/okr/domain/golden-runs/
    drift-log: .specify/logs/level5/drift.jsonl
  rollback:
    transactions-log: .specify/logs/level5/rollback-transactions.jsonl
@@ -7,7 +7,7 @@ Giao thức này quy định danh sách trắng các công cụ và câu lệnh
 ### A. Boss Orchestrator (okr.bossbuiltin)
 Được phép điều phối và chạy toàn bộ các chuỗi công cụ chuẩn bị và kiểm thử:
 - `Read`, `Write`, `Edit`, `Glob`, `Grep` (IDE Tools)
- Các script hỗ trợ: `.specify/scripts/bash/casan-harness.sh`, `security-check.sh`, `governance-check.sh`, `agent-metrics.sh`
+- Các script hỗ trợ: `packages/casan-harness/scripts/bash/casan-harness.sh`, `security-check.sh`, `governance-check.sh`, `agent-metrics.sh`
 - CLI Commands: `npm install`, `npm run build`, `npm run start:dev`, `docker compose`

 ### B. Special Design/Specification Agents (srs, bd, specify, plan, dd, tasks)
@@ -26,13 +26,13 @@ Identify inconsistencies, duplications, ambiguities, and underspecified items ac

 **STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).

-**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit.analyze`.
+**Constitution Authority**: The project constitution (`packages/casan-harness/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit.analyze`.

 ## Execution Steps

 ### 1. Initialize Analysis Context

-Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
+Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:

 - SPEC = FEATURE_DIR/spec.md
 - PLAN = FEATURE_DIR/plan.md
@@ -70,7 +70,7 @@ Load only the minimal necessary context from each artifact:

 **From constitution:**

- Load `.specify/memory/constitution.md` for principle validation
+- Load `packages/casan-harness/memory/constitution.md` for principle validation

 ### 3. Build Semantic Models

@@ -41,7 +41,7 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Execution Steps

-1. **Setup**: Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
+1. **Setup**: Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
   - All file paths must be absolute.
   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

@@ -212,7 +212,7 @@ You **MUST** consider the user input before proceeding (if not empty).
   - ✅ "Are [edge cases/scenarios] addressed in requirements?"
   - ✅ "Does the spec define [missing aspect]?"

-6. **Structure Reference**: Generate the checklist following the canonical template in `.specify/templates/checklist-template.md` for title, meta section, category headings, and ID formatting. If template is unavailable, use: H1 title, purpose/created meta lines, `##` category sections containing `- [ ] CHK### <requirement item>` lines with globally incrementing IDs starting at CHK001.
+6. **Structure Reference**: Generate the checklist following the canonical template in `packages/casan-harness/templates/checklist-template.md` for title, meta section, category headings, and ID formatting. If template is unavailable, use: H1 title, purpose/created meta lines, `##` category sections containing `- [ ] CHK### <requirement item>` lines with globally incrementing IDs starting at CHK001.

 7. **Report**: Output full path to checklist file, item count, and summarize whether the run created a new file or appended to an existing one. Summarize:
   - Focus areas selected
@@ -58,7 +58,7 @@ Note: This clarification workflow is expected to run (and be completed) BEFORE i

 Execution steps:

-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
+1. Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
   - `FEATURE_DIR`
   - `FEATURE_SPEC`
   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
@@ -20,13 +20,13 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+You are updating the project constitution at `packages/casan-harness/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.

-**Note**: If `.specify/memory/constitution.md` does not exist yet, it should have been initialized from `.specify/templates/constitution-template.md` during project setup. If it's missing, copy the template first.
+**Note**: If `packages/casan-harness/memory/constitution.md` does not exist yet, it should have been initialized from `packages/casan-harness/templates/constitution-template.md` during project setup. If it's missing, copy the template first.

 Follow this execution flow:

-1. Load the existing constitution at `.specify/memory/constitution.md`.
+1. Load the existing constitution at `packages/casan-harness/memory/constitution.md`.
   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.

@@ -47,10 +47,10 @@ Follow this execution flow:
   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.

 4. Consistency propagation checklist (convert prior checklist into active validations):
-   - Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
-   - Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
-   - Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
-   - Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
+   - Read `packages/casan-harness/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
+   - Read `packages/casan-harness/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
+   - Read `packages/casan-harness/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
+   - Read each command file in `packages/casan-harness/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.

 5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
@@ -67,7 +67,7 @@ Follow this execution flow:
   - Dates ISO format YYYY-MM-DD.
   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).

-7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
+7. Write the completed constitution back to `packages/casan-harness/memory/constitution.md` (overwrite).

 8. Output a final summary to the user with:
   - New version and bump rationale.
@@ -85,4 +85,4 @@ If the user supplies partial updates (e.g., only one principle revision), still

 If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.

-Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.
+Do not create a new template; always operate on the existing `packages/casan-harness/memory/constitution.md` file.
@@ -60,7 +60,7 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+1. Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

 2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
   - Scan all checklist files in the checklists/ directory
@@ -51,9 +51,9 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-1. **Setup**: Run `.specify/scripts/powershell/setup-plan.ps1 -Json` from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+1. **Setup**: Run `packages/casan-harness/scripts/powershell/setup-plan.ps1 -Json` from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

-2. **Load context**: Read FEATURE_SPEC and `.specify/memory/constitution.md`. Load IMPL_PLAN template (already copied).
+2. **Load context**: Read FEATURE_SPEC and `packages/casan-harness/memory/constitution.md`. Load IMPL_PLAN template (already copied).

 3. **Execute plan workflow**: Follow the structure in IMPL_PLAN template to:
   - Fill Technical Context (mark unknowns as "NEEDS CLARIFICATION")
@@ -114,7 +114,7 @@ Technical IDs remain unchanged.
   - Skip if project is purely internal (build scripts, one-off tools, etc.)

 3. **Agent context update**:
-   - Run `.specify/scripts/powershell/update-agent-context.ps1 -AgentType copilot`
+   - Run `packages/casan-harness/scripts/powershell/update-agent-context.ps1 -AgentType copilot`
   - These scripts detect which AI agent is in use
   - Update the appropriate agent-specific context file
   - Add only new technology from current plan
@@ -107,10 +107,10 @@ Given that feature description, do this:
      - Find the highest number N
      - Use N+1 for the new branch number

-   g. Run the script `.specify/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS"` with the calculated number and short-name:
+   g. Run the script `packages/casan-harness/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS"` with the calculated number and short-name:
      - Pass `--number N+1` and `--short-name "your-short-name"` along with the feature description
-      - Bash example: `.specify/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" --json --number 5 --short-name "user-auth" "Add user authentication"`
-      - PowerShell example: `.specify/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" -Json -Number 5 -ShortName "user-auth" "Add user authentication"`
+      - Bash example: `packages/casan-harness/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" --json --number 5 --short-name "user-auth" "Add user authentication"`
+      - PowerShell example: `packages/casan-harness/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" -Json -Number 5 -ShortName "user-auth" "Add user authentication"`

   **IMPORTANT**:
   - Check all three sources (remote branches, local branches, specs directories) to find the highest number
@@ -121,7 +121,7 @@ Given that feature description, do this:
   - The JSON output will contain BRANCH_NAME and SPEC_FILE paths
   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot")

-3. Load `.specify/templates/spec-template.md` to understand required sections.
+3. Load `packages/casan-harness/templates/spec-template.md` to understand required sections.

 4. Follow this execution flow:

@@ -51,7 +51,7 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-1. **Setup**: Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+1. **Setup**: Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

 2. **Load design documents**: Read from FEATURE_DIR:
   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)
@@ -69,7 +69,7 @@ You **MUST** consider the user input before proceeding (if not empty).
   - Create parallel execution examples per user story
   - Validate task completeness (each user story has all needed tasks, independently testable)

-4. **Generate tasks.md**: Use `.specify/templates/tasks-template.md` as structure, fill with:
+4. **Generate tasks.md**: Use `packages/casan-harness/templates/tasks-template.md` as structure, fill with:

   **Output Language**: Produce `tasks.md` in Vietnamese. Technical IDs (T001, [US1], [P], etc.) remain unchanged.
   - Correct feature name from plan.md
@@ -21,7 +21,7 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+1. Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
 1. From the executed script, extract the path to **tasks**.
 1. Get the Git remote by running:

@@ -148,7 +148,7 @@ From macOS with the project checked out:
 export VAULT_ADDR=http://161.33.139.73:8200
 export VAULT_TOKEN=<TOKEN>

-cd Output_CASAN5_REFINED  # repo root (app promoted from AINative_OKR_CASAN5/)
+cd Output_CASAN5_REFINED  # repo root (app promoted from )

 # Test sign-policy-bundle with Vault
 bash packages/casan-harness/scripts/bash/sign-policy-bundle.sh sign
@@ -162,7 +162,7 @@ On the VPS (or via Gitea web UI), create a new repository:

 On your local machine:
 ```bash
-cd Output_CASAN5_REFINED  # repo root (app promoted from AINative_OKR_CASAN5/)
+cd Output_CASAN5_REFINED  # repo root (app promoted from )

 # Add Gitea as remote
 git remote add gitea ssh://git@161.33.139.73:2222/<YOUR_USER>/casan5.git
@@ -8,7 +8,7 @@ You are an expert full-stack developer specializing in NestJS and a **master of
 
 -   **Architecture:** Refer to `docs/technical_architecture.md` for the overall system design, module responsibilities, and technology stack.
 
-   **Requirements:** Refer to `docs/input/okr-requirement.md` for functional requirements, use cases, and UI mockups.
+-   **Requirements:** Refer to `apps/okr/domain/input/okr-requirement.md` for functional requirements, use cases, and UI mockups.
 
 -   **Your Task:** Your role is to translate these designs into code, not to be creative.
 
@@ -63,7 +63,7 @@ You are an expert full-stack developer specializing in NestJS and a **master of
 
 **Design Style: Clean Modern Dashboard (Pure Tailwind CSS)**
 
-This project uses **pure Tailwind CSS** — no external component library (no MUI, no Ant Design). The design is clean, professional, and matches the OKR dashboard wireframes defined in `docs/input/okr-requirement.md`.
+This project uses **pure Tailwind CSS** — no external component library (no MUI, no Ant Design). The design is clean, professional, and matches the OKR dashboard wireframes defined in `apps/okr/domain/input/okr-requirement.md`.
 
 ### Layout Structure (matches OKR wireframes):
 
@@ -49,7 +49,7 @@ Read the following files to gather context:
 2. **System overview**: `docs/output/srs-systems/srs-overview-system.md` — system-wide context
 3. **Module SRS folder**: `docs/output/srs-systems/<mod-folder>/` — module wireframes & details
 4. **Technical architecture**: `docs/technical_architecture.md` — mandatory tech stack
-5. **BD template**: `.specify/templates/bd-template.md` — output structure template
+5. **BD template**: `packages/casan-harness/templates/bd-template.md` — output structure template

 ---

@@ -57,7 +57,7 @@ Read the following files to gather context:

 Generate the BD document at: `docs/output/ipa-docs/bd/bd-<mod-id>-<name>.md`

-The output **MUST** follow the structure defined in `.specify/templates/bd-template.md`:
+The output **MUST** follow the structure defined in `packages/casan-harness/templates/bd-template.md`:

 | § | Section | Content |
 |---|---------|---------|
@@ -80,7 +80,7 @@ The output **MUST** follow the structure defined in `.specify/templates/bd-templ
 2. Read `docs/output/srs-systems/srs-overview-system.md` for system context
 3. Read module wireframe/detail files from `docs/output/srs-systems/<mod-folder>/`
 4. Read `docs/technical_architecture.md` for tech stack constraints
-5. Read `.specify/templates/bd-template.md` for the output template structure
+5. Read `packages/casan-harness/templates/bd-template.md` for the output template structure

 Log: `[PROCESSING] Input file loading complete`

@@ -115,10 +115,10 @@ report-nn: <NN>           # for speckit.implement only
 report-phase: <phase>     # for speckit.implement only
 casan-harness:
  required: true
-  h4-security: ".specify/scripts/bash/security-check.sh"
-  h5-governance: ".specify/scripts/bash/governance-check.sh"
-  h6-agentops: ".specify/scripts/bash/agent-metrics.sh"
-  wrapper: ".specify/scripts/bash/casan-harness.sh"
+  h4-security: "packages/casan-harness/scripts/bash/security-check.sh"
+  h5-governance: "packages/casan-harness/scripts/bash/governance-check.sh"
+  h6-agentops: "packages/casan-harness/scripts/bash/agent-metrics.sh"
+  wrapper: "packages/casan-harness/scripts/bash/casan-harness.sh"
  evidence:
    trace-dir: ".specify/logs/trace"
    audit-log: ".specify/logs/audit/audit.jsonl"
@@ -54,7 +54,7 @@ Read the following files:
 3. **Feature spec**: `specs/<feature-id>/spec.md` — feature specification
 4. **Implementation plan**: `specs/<feature-id>/plan.md` — tech plan & data model
 5. **Technical architecture**: `docs/technical_architecture.md` — mandatory tech stack
-6. **DD template**: `.specify/templates/dd-template.md` — output structure template
+6. **DD template**: `packages/casan-harness/templates/dd-template.md` — output structure template

 ---

@@ -62,7 +62,7 @@ Read the following files:

 Generate the DD document at: `docs/output/ipa-docs/dd/dd-<mod-id>-<name>.md`

-The output **MUST** follow the structure defined in `.specify/templates/dd-template.md`:
+The output **MUST** follow the structure defined in `packages/casan-harness/templates/dd-template.md`:

 | § | Section | Content |
 |---|---------|---------|
@@ -88,7 +88,7 @@ The output **MUST** follow the structure defined in `.specify/templates/dd-templ
 2. Read SRS for requirements & NFR
 3. Read spec.md and plan.md
 4. Read `docs/technical_architecture.md`
-5. Read `.specify/templates/dd-template.md`
+5. Read `packages/casan-harness/templates/dd-template.md`

 Log: `[PROCESSING] Input file loading complete`

@@ -52,7 +52,7 @@ You are a Senior Code Reviewer specializing in Node.js/NestJS/TypeScript impleme
 $ARGUMENTS
 ```

-If `$ARGUMENTS` is empty, run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` to detect the current active feature.
+If `$ARGUMENTS` is empty, run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` to detect the current active feature.

 ## Constraints

@@ -82,7 +82,7 @@ Add a dedicated section in the report:

 ## Setup

-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly -RequireTasks -IncludeTasks` and parse:
+1. Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly -RequireTasks -IncludeTasks` and parse:
   - `FEATURE_DIR` — feature specs directory
   - `AVAILABLE_DOCS` — list of generated artifacts
 2. Load reference documents:
@@ -90,7 +90,7 @@ Add a dedicated section in the report:
   - `specs/<feature-id>/tasks.md` — task completion checklist
   - `specs/<feature-id>/plan.md` — implementation plan
   - `specs/<feature-id>/data-model.md` — entity model
-   - `.specify/memory/constitution.md` — project Constitution
+   - `packages/casan-harness/memory/constitution.md` — project Constitution
   - `docs/technical_architecture.md` — system architecture
 3. Identify implementation module directory (e.g., `backend/src/modules/workspace/`)

@@ -64,7 +64,7 @@ Optional: feature-id (e.g. `001-xxx`). If empty, auto-detect from the active bra

 ## Setup

-Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root and parse:
+Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root and parse:

 - `FEATURE_DIR` — absolute path to the feature specs directory
 - `FEATURE_SPEC` — path to `spec.md`
@@ -75,7 +75,7 @@ Load the following documents:
 - `specs/<feature-id>/contracts/` — API contracts (**warn** if missing)
 - `specs/<feature-id>/research.md` — library/framework decisions
 - `specs/<feature-id>/quickstart.md` — integration scenarios
- `.specify/memory/constitution.md` — project Constitution
+- `packages/casan-harness/memory/constitution.md` — project Constitution
 - `docs/technical_architecture.md` — system architecture

 ---
@@ -61,7 +61,7 @@ Optional: feature-id (e.g. `001-xxx`). If empty, auto-detect from the active bra

 ## Setup

-Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root and parse:
+Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root and parse:

 - `FEATURE_DIR` — absolute path to the feature specs directory
 - `FEATURE_SPEC` — path to `spec.md`
@@ -69,7 +69,7 @@ Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from
 Load the following reference documents:
 - `docs/output/srs-systems/srs-overview-system.md` — system-level SRS (traceability source)
 - `docs/technical_architecture.md` — technical architecture (feasibility reference)
- `.specify/memory/constitution.md` — project Constitution (compliance gate)
+- `packages/casan-harness/memory/constitution.md` — project Constitution (compliance gate)
 - Feature-specific SRS if exists: `docs/output/ipa-docs/srs/srs-<module>.md`

 ---
@@ -86,7 +86,7 @@ Priority rule: `srs-overview-system.md` → `srs-mod<XX>-detail.md` → `srs-mod

 1. Load `docs/output/srs-systems/srs-overview-system.md` to get system context, then identify the module folder matching `$ARGUMENTS` (e.g., `docs/output/srs-systems/mod01-xxx/`). Load `srs-mod<XX>-detail.md` and `srs-mod<XX>-wireframe.md` from that folder. Enumerate all FEAs belonging to the target module.
 2. Cross-reference `srs-mod<XX>-detail.md` and `srs-mod<XX>-wireframe.md` to fill in any missing details for each FEA.
-3. Generate a complete SRS document using **`.specify/templates/srs-template.md`** as the base template. Follow the section mapping in **SRS Output Structure** below to populate each template section with module-specific content.
+3. Generate a complete SRS document using **`packages/casan-harness/templates/srs-template.md`** as the base template. Follow the section mapping in **SRS Output Structure** below to populate each template section with module-specific content.
   > ⚠️ **MANDATORY: TABLE OF CONTENTS** — The SRS document **MUST** include a `## TABLE OF CONTENTS` section immediately after the `Record of Change` table (before §1). Generate a complete, clickable table of contents listing all `##` and `###` level headings with Markdown anchor links. This matches the structure in `srs-template.md`. Do NOT skip this section.
 4. Save to `docs/output/ipa-docs/srs/srs-<MOD-ID>-<module-short-name>.md`.  
  Example: MOD-01 (OKR management module) → `docs/output/ipa-docs/srs/srs-mod01-okr-management.md`
@@ -94,7 +94,7 @@ Priority rule: `srs-overview-system.md` → `srs-mod<XX>-detail.md` → `srs-mod

 ## SRS Output Structure

-Start from a copy of **`.specify/templates/srs-template.md`** and populate every section as follows.
+Start from a copy of **`packages/casan-harness/templates/srs-template.md`** and populate every section as follows.

 **File header** — replace placeholders:

@@ -39,7 +39,7 @@ Mission: produce a **complete, exhaustive, system-wide SRS** covering all module

 If `$ARGUMENTS` specifies a file or folder path, **read that path first** as the primary source. Otherwise, read in this priority order and cross-reference:

-1. **`docs/input/okr-requirement.md`** — Original product requirement document. **Primary source of truth.** Contains functional requirements, screen definitions, field rules, user flows, and validation constraints.
+1. **`apps/okr/domain/input/okr-requirement.md`** — Original product requirement document. **Primary source of truth.** Contains functional requirements, screen definitions, field rules, user flows, and validation constraints.
 2. **`docs/technical_architecture.md`** — Technology stack recommendations. Use for the technology recommendation section only (not for functional requirements).

 **Priority rule:** User-specified input (`$ARGUMENTS`) → Special Specification (Spec) → system-overview.md → `[TBC-XX]` if all are insufficient.
@@ -29,7 +29,7 @@ You are the **Independent QA Agent (okr.testkit)** for OKR web app. Your role is
 **Output:**
 - `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` — Comprehensive test case document

-**Template:** `.specify/templates/testcase-template.md` — Use this template for the output format. Fill in all sections with actual test cases generated from the input documents.
+**Template:** `packages/casan-harness/templates/testcase-template.md` — Use this template for the output format. Fill in all sections with actual test cases generated from the input documents.

 **Process:**

@@ -43,11 +43,11 @@ You are the **Independent QA Agent (okr.testkit)** for OKR web app. Your role is
   - **API Tests (AT)** — From DD internal API contracts + BD external interface → Jest + Supertest
   - **UI/E2E Tests (E2E)** — From BD screen designs + SRS user flows → Playwright
   - **Integration Tests (IT)** — From DD sequence diagrams + data flow → testcontainers-node
-4. **Write test case document** using template `.specify/templates/testcase-template.md` to `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` with full traceability
+4. **Write test case document** using template `packages/casan-harness/templates/testcase-template.md` to `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` with full traceability

 #### Test Case Output

-The output file MUST follow the template at `.specify/templates/testcase-template.md`. Key sections:
+The output file MUST follow the template at `packages/casan-harness/templates/testcase-template.md`. Key sections:
 - **§1 Unit Tests (UT)** — From DD class/method designs → Jest
 - **§2 API Tests (AT)** — From DD internal API contracts + BD external interface → Jest + Supertest
 - **§3 UI/E2E Tests (E2E)** — From BD screen designs + SRS user flows → Playwright
@@ -59,7 +59,7 @@ The template contains embedded generation rules (HTML comments) for each section

 #### ⛔ MANDATORY TABLE FORMAT — STRICTLY ENFORCED

-Each section (UT, AT, E2E, IT) MUST be output as **one single consolidated master table** per section, exactly matching the column structure shown in the template `.specify/templates/testcase-template.md`.
+Each section (UT, AT, E2E, IT) MUST be output as **one single consolidated master table** per section, exactly matching the column structure shown in the template `packages/casan-harness/templates/testcase-template.md`.

 **⛔ PROHIBITED formats (DO NOT USE):**
 - Individual `| Item | Content |` two-column tables for each test case
@@ -162,10 +162,10 @@ Each section (UT, AT, E2E, IT) MUST be output as **one single consolidated maste

 8. **Write test execution summary report** to `docs/output/output_logs/<feature-id>/reports/<NN>-testkit-report.md`:

-**Template:** `.specify/templates/testreport-template.md` — Load this template and fill in all sections with actual test execution results.
+**Template:** `packages/casan-harness/templates/testreport-template.md` — Load this template and fill in all sections with actual test execution results.

 **Process:**
-1. Read the template file: `.specify/templates/testreport-template.md`
+1. Read the template file: `packages/casan-harness/templates/testreport-template.md`
 2. Read `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` and extract ALL TC-IDs from master tables. **Same rules as Phase D apply: exact TC-IDs, zero omissions, all 4 sections mandatory.**
 3. Fill in all placeholders with actual test execution data:
   - §1 Test Execution Summary — aggregate pass/fail/skip counts from Phase B
@@ -294,7 +294,7 @@ Code (TypeScript/JavaScript test scripts) and file paths remain in English.

 This agent is invoked by the Boss orchestrator at two specific points:

-1. **STEP 8b** (after DD): `gen-testcases <feature-id>` → produces `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` using template `.specify/templates/testcase-template.md`
+1. **STEP 8b** (after DD): `gen-testcases <feature-id>` → produces `docs/output/ipa-docs/testcase/testcase-<MOD-ID>-<module-short-name>.md` using template `packages/casan-harness/templates/testcase-template.md`
 2. **STEP 12** (after build, FINAL QA AUDIT): `run-tests <feature-id>` → produces test scripts + executes + produces:
   - Pipeline report: `docs/output/output_logs/<feature-id>/reports/<NN>-testkit-report.md` (Phase C)
   - IPA detail report: `docs/output/ipa-docs/testreport/testreport-<MOD-ID>-<module-short-name>.md` (Phase D)
@@ -10,38 +10,38 @@ Raise the SDD Speckit OKR pipeline from CASAN Level 3 to Level 4 by making Secur

 | Harness | Runtime control | Script | Evidence |
 |---|---|---|---|
-| H4 Security | Prompt injection block, PII masking, secret redaction, output filtering | `.specify/scripts/bash/security-check.sh` | `.specify/logs/trace/security-*.json`, `.specify/logs/audit/security.jsonl` |
-| H5 Governance | Risk scoring, non-interactive approval policy, append-only hash-chain audit | `.specify/scripts/bash/governance-check.sh` | `.specify/logs/trace/governance-*.json`, `.specify/logs/audit/audit.jsonl` |
-| H6 AgentOps | Latency, retry, token, cost, status, alert tracking | `.specify/scripts/bash/agent-metrics.sh` | `.specify/logs/trace/agentops-*.json`, `.specify/logs/cost/metrics.jsonl`, `.specify/agentops/alerts.log` |
-| H2 Tool Registry | Side-effect registry, idempotency key, per-call audit | `.specify/scripts/bash/tool-registry-gate.sh` | `.specify/logs/level5/tool-registry.jsonl`, `.specify/logs/audit/tool-calls.jsonl` |
+| H4 Security | Prompt injection block, PII masking, secret redaction, output filtering | `packages/casan-harness/scripts/bash/security-check.sh` | `.specify/logs/trace/security-*.json`, `.specify/logs/audit/security.jsonl` |
+| H5 Governance | Risk scoring, non-interactive approval policy, append-only hash-chain audit | `packages/casan-harness/scripts/bash/governance-check.sh` | `.specify/logs/trace/governance-*.json`, `.specify/logs/audit/audit.jsonl` |
+| H6 AgentOps | Latency, retry, token, cost, status, alert tracking | `packages/casan-harness/scripts/bash/agent-metrics.sh` | `.specify/logs/trace/agentops-*.json`, `.specify/logs/cost/metrics.jsonl`, `.specify/agentops/alerts.log` |
+| H2 Tool Registry | Side-effect registry, idempotency key, per-call audit | `packages/casan-harness/scripts/bash/tool-registry-gate.sh` | `.specify/logs/level5/tool-registry.jsonl`, `.specify/logs/audit/tool-calls.jsonl` |

 ## Mandatory Gate Pattern

 Before every delegated step:

 ```bash
-.specify/scripts/bash/security-check.sh "$STEP_INPUT" "$SAFE_INPUT" input
-.specify/scripts/bash/governance-check.sh "$SAFE_INPUT" "$APPROVED_INPUT" "$ACTION_NAME"
+packages/casan-harness/scripts/bash/security-check.sh "$STEP_INPUT" "$SAFE_INPUT" input
+packages/casan-harness/scripts/bash/governance-check.sh "$SAFE_INPUT" "$APPROVED_INPUT" "$ACTION_NAME"
 ```

 Around every execution or agent/tool invocation:

 ```bash
 CASAN_AGENT_NAME="<agent>" CASAN_STEP_NAME="<step>" \
-  .specify/scripts/bash/agent-metrics.sh "$APPROVED_INPUT" "$RAW_OUTPUT" -- <real command>
+  packages/casan-harness/scripts/bash/agent-metrics.sh "$APPROVED_INPUT" "$RAW_OUTPUT" -- <real command>
 ```

 After every generated artifact or agent response:

 ```bash
-.specify/scripts/bash/security-check.sh "$RAW_OUTPUT" "$FINAL_OUTPUT" output
+packages/casan-harness/scripts/bash/security-check.sh "$RAW_OUTPUT" "$FINAL_OUTPUT" output
 ```

 When a step can be represented as a single command, Boss MAY use the wrapper:

 ```bash
 CASAN_AGENT_NAME="<agent>" CASAN_STEP_NAME="<step>" \
-  .specify/scripts/bash/casan-harness.sh "$STEP_INPUT" "$FINAL_OUTPUT" "$ACTION_NAME" -- <real command>
+  packages/casan-harness/scripts/bash/casan-harness.sh "$STEP_INPUT" "$FINAL_OUTPUT" "$ACTION_NAME" -- <real command>
 ```

 Cache hits MUST NOT bypass CASAN evidence. A cached wrapper run still has to produce fresh H4 input, H5 governance, H6 metrics, and H4 output traces for the current execution.
@@ -105,4 +105,4 @@ Boss orchestrator also enforces:
 1. **Self-Security Audit:** Every agent reads `protocols/agent-self-security-rules.md` before output is accepted.
 2. **Self-Governance Audit:** Every agent reads `protocols/governance-risk-policy.md` before high-risk action planning.
 3. **Hallucination Checklist:** Every review agent reads `protocols/hallucination-prevention-checklist.md` during review gates.
-4. **Tool Registry Policy:** Every side-effecting tool is checked against `protocols/tool-registry-policy.md` and `.specify/level5/tool-registry.yaml`.
+4. **Tool Registry Policy:** Every side-effecting tool is checked against `protocols/tool-registry-policy.md` and `packages/casan-harness/level5/tool-registry.yaml`.
@@ -4,7 +4,7 @@ Giao thức này cung cấp bộ checklist bắt buộc để các Review Agents

 ## 1. Nguyên lý đối chiếu chéo (Grounding)
 - Không có bất kỳ chi tiết thiết kế hoặc logic code nào được phép tự ý phát minh nếu không có cơ sở chứng cứ rõ ràng từ:
-  - Tài liệu Yêu cầu nghiệp vụ (`docs/input/okr-requirement.md`).
+  - Tài liệu Yêu cầu nghiệp vụ (`apps/okr/domain/input/okr-requirement.md`).
  - Bản vẽ thiết kế Basic Design (`bd-*.md`) hoặc Detail Design (`dd-*.md`).
  - Tệp thông tin Context hiện tại (`pipeline-context.yaml`).

@@ -32,22 +32,22 @@ tech-stack:
 casan-harness:
  level-target: 5
  h4-security:
-    policy: .specify/security/prompt-filter.yaml
-    output-policy: .specify/security/output-policy.yaml
+    policy: packages/casan-harness/security/prompt-filter.yaml
+    output-policy: packages/casan-harness/security/output-policy.yaml
    audit-log: .specify/logs/audit/security.jsonl
  h5-governance:
-    approval-flow: .specify/governance/approval-flow.yaml
-    risk-registry: .specify/governance/risk-registry.yaml
+    approval-flow: packages/casan-harness/governance/approval-flow.yaml
+    risk-registry: packages/casan-harness/governance/risk-registry.yaml
    audit-log: .specify/logs/audit/audit.jsonl
  h6-agentops:
    metrics-policy: .specify/agentops/metrics.yaml
    metrics-log: .specify/logs/cost/metrics.jsonl
    alert-log: .specify/agentops/alerts.log
  h2-tool-registry:
-    registry: .specify/level5/tool-registry.yaml
+    registry: packages/casan-harness/level5/tool-registry.yaml
    audit-log: .specify/logs/level5/tool-registry.jsonl
  h7-drift:
-    golden-dir: .specify/level5/golden-runs/
+    golden-dir: apps/okr/domain/golden-runs/
    drift-log: .specify/logs/level5/drift.jsonl
  rollback:
    transactions-log: .specify/logs/level5/rollback-transactions.jsonl
@@ -7,7 +7,7 @@ Giao thức này quy định danh sách trắng các công cụ và câu lệnh
 ### A. Boss Orchestrator (okr.bossbuiltin)
 Được phép điều phối và chạy toàn bộ các chuỗi công cụ chuẩn bị và kiểm thử:
 - `Read`, `Write`, `Edit`, `Glob`, `Grep` (IDE Tools)
- Các script hỗ trợ: `.specify/scripts/bash/casan-harness.sh`, `security-check.sh`, `governance-check.sh`, `agent-metrics.sh`
+- Các script hỗ trợ: `packages/casan-harness/scripts/bash/casan-harness.sh`, `security-check.sh`, `governance-check.sh`, `agent-metrics.sh`
 - CLI Commands: `npm install`, `npm run build`, `npm run start:dev`, `docker compose`

 ### B. Special Design/Specification Agents (srs, bd, specify, plan, dd, tasks)
@@ -26,13 +26,13 @@ Identify inconsistencies, duplications, ambiguities, and underspecified items ac

 **STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).

-**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit.analyze`.
+**Constitution Authority**: The project constitution (`packages/casan-harness/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit.analyze`.

 ## Execution Steps

 ### 1. Initialize Analysis Context

-Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
+Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:

 - SPEC = FEATURE_DIR/spec.md
 - PLAN = FEATURE_DIR/plan.md
@@ -70,7 +70,7 @@ Load only the minimal necessary context from each artifact:

 **From constitution:**

- Load `.specify/memory/constitution.md` for principle validation
+- Load `packages/casan-harness/memory/constitution.md` for principle validation

 ### 3. Build Semantic Models

@@ -41,7 +41,7 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Execution Steps

-1. **Setup**: Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
+1. **Setup**: Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list.
   - All file paths must be absolute.
   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

@@ -212,7 +212,7 @@ You **MUST** consider the user input before proceeding (if not empty).
   - ✅ "Are [edge cases/scenarios] addressed in requirements?"
   - ✅ "Does the spec define [missing aspect]?"

-6. **Structure Reference**: Generate the checklist following the canonical template in `.specify/templates/checklist-template.md` for title, meta section, category headings, and ID formatting. If template is unavailable, use: H1 title, purpose/created meta lines, `##` category sections containing `- [ ] CHK### <requirement item>` lines with globally incrementing IDs starting at CHK001.
+6. **Structure Reference**: Generate the checklist following the canonical template in `packages/casan-harness/templates/checklist-template.md` for title, meta section, category headings, and ID formatting. If template is unavailable, use: H1 title, purpose/created meta lines, `##` category sections containing `- [ ] CHK### <requirement item>` lines with globally incrementing IDs starting at CHK001.

 7. **Report**: Output full path to checklist file, item count, and summarize whether the run created a new file or appended to an existing one. Summarize:
   - Focus areas selected
@@ -62,7 +62,7 @@ Note: This clarification workflow is expected to run (and be completed) BEFORE i

 Execution steps:

-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
+1. Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
   - `FEATURE_DIR`
   - `FEATURE_SPEC`
   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
@@ -24,13 +24,13 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+You are updating the project constitution at `packages/casan-harness/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.

-**Note**: If `.specify/memory/constitution.md` does not exist yet, it should have been initialized from `.specify/templates/constitution-template.md` during project setup. If it's missing, copy the template first.
+**Note**: If `packages/casan-harness/memory/constitution.md` does not exist yet, it should have been initialized from `packages/casan-harness/templates/constitution-template.md` during project setup. If it's missing, copy the template first.

 Follow this execution flow:

-1. Load the existing constitution at `.specify/memory/constitution.md`.
+1. Load the existing constitution at `packages/casan-harness/memory/constitution.md`.
   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.

@@ -51,10 +51,10 @@ Follow this execution flow:
   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.

 4. Consistency propagation checklist (convert prior checklist into active validations):
-   - Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
-   - Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
-   - Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
-   - Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
+   - Read `packages/casan-harness/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
+   - Read `packages/casan-harness/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
+   - Read `packages/casan-harness/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
+   - Read each command file in `packages/casan-harness/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.

 5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
@@ -71,7 +71,7 @@ Follow this execution flow:
   - Dates ISO format YYYY-MM-DD.
   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).

-7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
+7. Write the completed constitution back to `packages/casan-harness/memory/constitution.md` (overwrite).

 8. Output a final summary to the user with:
   - New version and bump rationale.
@@ -89,4 +89,4 @@ If the user supplies partial updates (e.g., only one principle revision), still

 If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.

-Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.
+Do not create a new template; always operate on the existing `packages/casan-harness/memory/constitution.md` file.
@@ -60,7 +60,7 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+1. Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

 2. **Check checklists status** (if FEATURE_DIR/checklists/ exists):
   - Scan all checklist files in the checklists/ directory
@@ -59,9 +59,9 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-1. **Setup**: Run `.specify/scripts/powershell/setup-plan.ps1 -Json` from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+1. **Setup**: Run `packages/casan-harness/scripts/powershell/setup-plan.ps1 -Json` from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

-2. **Load context**: Read FEATURE_SPEC and `.specify/memory/constitution.md`. Load IMPL_PLAN template (already copied).
+2. **Load context**: Read FEATURE_SPEC and `packages/casan-harness/memory/constitution.md`. Load IMPL_PLAN template (already copied).

 3. **Execute plan workflow**: Follow the structure in IMPL_PLAN template to:
   - Fill Technical Context (mark unknowns as "NEEDS CLARIFICATION")
@@ -122,7 +122,7 @@ Technical IDs remain unchanged.
   - Skip if project is purely internal (build scripts, one-off tools, etc.)

 3. **Agent context update**:
-   - Run `.specify/scripts/powershell/update-agent-context.ps1 -AgentType copilot`
+   - Run `packages/casan-harness/scripts/powershell/update-agent-context.ps1 -AgentType copilot`
   - These scripts detect which AI agent is in use
   - Update the appropriate agent-specific context file
   - Add only new technology from current plan
@@ -115,10 +115,10 @@ Given that feature description, do this:
      - Find the highest number N
      - Use N+1 for the new branch number

-   g. Run the script `.specify/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS"` with the calculated number and short-name:
+   g. Run the script `packages/casan-harness/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS"` with the calculated number and short-name:
      - Pass `--number N+1` and `--short-name "your-short-name"` along with the feature description
-      - Bash example: `.specify/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" --json --number 5 --short-name "user-auth" "Add user authentication"`
-      - PowerShell example: `.specify/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" -Json -Number 5 -ShortName "user-auth" "Add user authentication"`
+      - Bash example: `packages/casan-harness/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" --json --number 5 --short-name "user-auth" "Add user authentication"`
+      - PowerShell example: `packages/casan-harness/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" -Json -Number 5 -ShortName "user-auth" "Add user authentication"`

   **IMPORTANT**:
   - Check all three sources (remote branches, local branches, specs directories) to find the highest number
@@ -129,7 +129,7 @@ Given that feature description, do this:
   - The JSON output will contain BRANCH_NAME and SPEC_FILE paths
   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot")

-3. Load `.specify/templates/spec-template.md` to understand required sections.
+3. Load `packages/casan-harness/templates/spec-template.md` to understand required sections.

 4. Follow this execution flow:

@@ -60,7 +60,7 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-1. **Setup**: Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+1. **Setup**: Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").

 2. **Load design documents**: Read from FEATURE_DIR:
   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)
@@ -78,7 +78,7 @@ You **MUST** consider the user input before proceeding (if not empty).
   - Create parallel execution examples per user story
   - Validate task completeness (each user story has all needed tasks, independently testable)

-4. **Generate tasks.md**: Use `.specify/templates/tasks-template.md` as structure, fill with:
+4. **Generate tasks.md**: Use `packages/casan-harness/templates/tasks-template.md` as structure, fill with:

   **Output Language**: Produce `tasks.md` in Vietnamese. Technical IDs (T001, [US1], [P], etc.) remain unchanged.
   - Correct feature name from plan.md
@@ -21,7 +21,7 @@ You **MUST** consider the user input before proceeding (if not empty).

 ## Outline

-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
+1. Run `packages/casan-harness/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
 1. From the executed script, extract the path to **tasks**.
 1. Get the Git remote by running:

@@ -2,7 +2,7 @@
 ## step 1: gen wide system srs
 - use agent: 　okr.srsallsystem
 - Prompt
-> Generate system-wide SRS (Full Module Requirements Definition) for the OKR web app base on input at docs/input/okr-requirement.md
+> Generate system-wide SRS (Full Module Requirements Definition) for the OKR web app base on input at apps/okr/domain/input/okr-requirement.md

 ## step 2: chọn module sẽ tạo
 ### a. Case run from vscode
@@ -18,4 +18,4 @@
 # II. Change spec
 ## step 3: thực hiện CR cho 1 module
 - Prompt
-> execute an UPDATE pipeline for change requests at docs/input/change-request/change-0405.md for MOD-02: Workspace & Dashboard
+> execute an UPDATE pipeline for change requests at apps/okr/domain/input/change-request/change-0405.md for MOD-02: Workspace & Dashboard
@@ -4,6 +4,6 @@ OKR-domain data consumed by the CASAN harness, kept separate from the reusable h
 Populated in Plan-01 Phase 5. Referenced by scripts via `CASAN_DOMAIN_ROOT` (default this dir).

 Planned contents (moved from `.specify/` / `docs/` in Phase 5):
- `golden-runs/` — golden baselines for drift/H7 (from `.specify/level5/golden-runs/`)
- `input/` — requirement/architecture specs (from `docs/input/`)
- `corpus/` — redteam + benign corpora (from `.specify/security/redteam-*.jsonl`, `benign-corpus/`)
+- `golden-runs/` — golden baselines for drift/H7 (from `apps/okr/domain/golden-runs/`)
+- `input/` — requirement/architecture specs (from `apps/okr/domain/input/`)
+- `corpus/` — redteam + benign corpora (from `packages/casan-harness/security/redteam-*.jsonl`, `benign-corpus/`)
@@ -18,10 +18,10 @@ CASAN Tier 2 from "needs infra" to locally testable production-like controls.
 ## Commands

 ```bash
-bash .specify/scripts/bash/infra-lab.sh start
-bash .specify/scripts/bash/infra-lab.sh verify
-bash .specify/scripts/bash/infra-lab.sh env
-bash .specify/scripts/bash/infra-lab.sh stop
+bash packages/casan-harness/scripts/bash/infra-lab.sh start
+bash packages/casan-harness/scripts/bash/infra-lab.sh verify
+bash packages/casan-harness/scripts/bash/infra-lab.sh env
+bash packages/casan-harness/scripts/bash/infra-lab.sh stop
 ```

 This is a lab, not a compliance claim. AWS S3 Object Lock, real enterprise IdP,
@@ -5,10 +5,10 @@ Modified principles: placeholder principle 1 -> I. Requirement-First Definition;
 Added sections: Product Scope Constraints; Delivery Workflow and Quality Gates
 Removed sections: none
 Templates requiring updates:
- ✅ .specify/templates/spec-template.md
- ✅ .specify/templates/plan-template.md
- ✅ .specify/templates/tasks-template.md
- ⚠ pending none in .specify/templates/commands because that directory does not exist in this repository
+- ✅ packages/casan-harness/templates/spec-template.md
+- ✅ packages/casan-harness/templates/plan-template.md
+- ✅ packages/casan-harness/templates/tasks-template.md
+- ⚠ pending none in packages/casan-harness/templates/commands because that directory does not exist in this repository
 - ✅ README.md
 Follow-up TODOs: none
 -->
@@ -15,11 +15,11 @@ LOG + TRACE + METRICS + AUDIT
 Unified wrapper:

 ```bash
-.specify/scripts/bash/casan-harness.sh input.txt output.txt agent_step
+packages/casan-harness/scripts/bash/casan-harness.sh input.txt output.txt agent_step
 ```

 Verification:

 ```bash
-bash .specify/tests/run-casan4-harness-tests.sh
+bash packages/casan-harness/tests/run-casan4-harness-tests.sh
 ```
@@ -3,7 +3,7 @@
 **Branch**: `[###-feature-name]` | **Date**: [DATE] | **Spec**: [link]
 **Input**: Feature specification from `/specs/[###-feature-name]/spec.md`

-**Note**: This template is filled in by the `/speckit.plan` command. See `.specify/templates/plan-template.md` for the execution workflow.
+**Note**: This template is filled in by the `/speckit.plan` command. See `packages/casan-harness/templates/plan-template.md` for the execution workflow.

 ## Summary