CASAN/docs/plans/CASAN_TEAM_QA.md

# CASAN — Bộ Q&A cho Team (hiểu sâu hệ thống + before/after tối ưu)

> ✅ **Bản CANONICAL** của Q&A hệ thống (được cập nhật). Có một bản sao ngắn hơn/cũ hơn
> ở `optimize-docs/CASAN_TEAM_QA.md` phục vụ ngữ cảnh trình bày — khi lệch, ưu tiên bản này.

> **Mục đích:** đảm bảo mọi thành viên hiểu sâu hệ thống, biết rõ **trước/sau tối ưu đổi gì và VÌ SAO**, trả lời được từ cơ bản đến nâng cao trước giám khảo/khách hàng.
> **Nguyên tắc:** mọi con số gắn nhãn **[đo thật]** (đã chạy, thấy exit code) hoặc **[dự án tự báo / chưa đo]**. Đúng tinh thần CASAN: *"điểm = thứ chứng minh được, không bịa"*.
> **Trọng tâm tối ưu lần này:** **H4 Security · H5 Governance · H6 AgentOps** (đều từng là GAP: 20 / 25 / 30).

---

## PHẦN A — CƠ BẢN: hệ thống là gì

**A1. Dự án này thực chất là cái gì?**
Hai tầng: (1) **sản phẩm** là app OKR (NestJS + React + Prisma); (2) **thứ thật sự được chấm** là **AI-SDLC pipeline** — quy trình để AI tự sinh phần mềm, bao quanh bởi **CASAN Harness** (7 lớp điều khiển an toàn cho agent). App OKR chỉ là *testbed* để chứng minh harness chạy thật.

**A2. "Harness" nghĩa là gì?**
Theo Martin Fowler (CASAN trích): *"everything in an AI agent except the model itself"* — toàn bộ lớp kỹ thuật bao quanh model để AI làm việc an toàn trong doanh nghiệp: ngữ cảnh, công cụ, kiểm định, bảo mật, quản trị, AgentOps, điều phối. **Harness là thứ tạo khác biệt, không phải model** (ai cũng gọi được cùng model).

**A3. 7 harness (H1–H7) là gì?**
H1 Context · H2 Tool · H3 Evaluation · H4 Security · H5 Governance · H6 AgentOps · H7 Orchestration. (Xem `casan_harness_assessment.md`.)

**A4. CASAN gồm mấy cấp?**
5 cấp: **C**urious → **A**ugmented → **S**tandard → **A**utomated → **N**ative. Dự án nhắm **Level 4 (Automated) chứng minh được**.

**A5. Quy tắc vàng CASAN mà cả team PHẢI thuộc?**
(1) *"Điểm = thứ chứng minh được bằng tấn công, không phải thứ khai báo"* → có file ≠ có năng lực. (2) *"Harness thấp nhất quyết định trần"* → 1 harness yếu kéo cả pipeline xuống. (3) *"Thu hẹp khoảng cách từ demo đến production"*.

**A6. Cách chấm điểm 1 harness?**
Mỗi harness 0–100. Trung bình 7 harness + không có GAP (<30) → suy ra CASAN Level. Trên 80 và không GAP = Level 4.

---

## PHẦN B — BEFORE/AFTER: tối ưu đổi những gì (casan-old → casan5)

**B1. Insight lớn nhất của bản nâng cấp là gì?**
**Mã ứng dụng gần như KHÔNG đổi** — backend **647 LOC giống hệt** [đo thật], 8 API endpoint không đổi. Thứ nâng cấp là **harness**: `.specify/scripts` từ **3.127 → 4.301 LOC (+37,5%)**, **22 → 35 script (+13)** [đo thật]. Đây là *trưởng thành hoá governance*, không phải thêm tính năng OKR.

**B2. Trước tối ưu, 3 harness trọng tâm yếu thế nào?**
Theo `casan_harness_assessment.md` mục 5: **H4=20, H5=25, H6=30** — đều là **GAP**. H4 không có injection scan; H5 audit chỉ là text file (không bất biến); H6 chỉ có port check, không đo cost/drift.

**B3. Nêu 3 thay đổi "chất" nhất (không phải thêm file)?**
(1) **H4:** sửa **bug fail-open thật** — bản cũ `security-check.sh` dùng sai cú pháp `[:space:]` → trên grep hiện đại **thoát rc=4, không chặn gì**; bản mới chặn cả leetspeak (rc=2) [đo thật]. (2) **H5:** audit chain ký RSA — sửa 1 ký tự bị bắt `AUDIT_HASH_MISMATCH` [đo thật]. (3) **H6:** cost-spike đo token thật, bắt step tốn 3× → `COST_SPIKE_DETECTED exit=2` [đo thật].

**B4. Ngoài 3 harness trọng tâm, còn đổi gì?**
DB **SQLite → MySQL** (production); frontend "test" từ **`tsc --noEmit` giả → 16 vitest thật** [đo thật]; thêm **CI/CD** (GitHub+Gitea), **Docker + Nginx**, tách khoá riêng khỏi git, redteam corpus, model-router.

**B5. "Fail-open" là gì và vì sao nguy hiểm?**
Control gặp lỗi thì **mở cửa cho qua** thay vì chặn. Bản cũ khi grep lỗi cú pháp → thoát rc=4 → **injection lọt hết**. Nguy hiểm vì môi trường cũ (macOS/BSD) che mất, tưởng an toàn nhưng thực ra thủng. Bản mới **fail-closed** (lỗi thì chặn).

**B6. Điểm trung bình harness đổi thế nào?**
Dự án tự báo ~81 → ~84 [dự án tự báo]. Tôi tự đo per-item ~83 [đo thật, per-harness ở Phụ lục C báo cáo].

---

## PHẦN C — H4 · H5 · H6 SÂU (trọng tâm thi)

### H4 — Security
**C1. H4 bảo vệ chống gì?** Prompt injection (trực tiếp + gián tiếp), obfuscation (leetspeak/whitespace), rò rỉ secret/PII, jailbreak — bám OWASP LLM01/LLM02/LLM06 + Agentic Top 10.

**C2. Vì sao regex không đủ, phải cần model?**
Regex chỉ bắt câu *đã biết*. Câu paraphrase mới ("could you set aside the earlier guidance…") **không trùng từ khoá → regex lọt (rc=0)** [đo thật]. Model phân loại theo **ngữ nghĩa** bắt được. Đây là nguyên lý *Computational × Inferential Blend*.

**C3. Con số recall thật là bao nhiêu?**
Regex trên paraphrase mới = **0.00** [đo thật]. Frontier model (làm judge 30 mẫu) = **1.00** [đo thật phiên này]. ornith:9b ≈ **0.85** [dự án tự báo — đo bằng `phase3-redteam-metrics.sh` khi có Ollama].

**C4. "Indirect injection" (gián tiếp) là gì?**
Nhúng lệnh độc vào **artifact** (spec/plan) mà agent sẽ đọc, không phải input trực tiếp. `artifact-scan.sh` quét trước khi agent đọc → `ARTIFACT_SCAN_BLOCKED reason=injection_detected exit=2` [đo thật]. Đây là loại MAESTRO nhấn mạnh (cross-layer L2→L3).

**C5. Chuẩn hoá (normalization) để làm gì?** Fold leetspeak (`1gn0re`→`ignore`), gộp khoảng trắng **TRƯỚC** khi match → né bằng biến thể trở nên vô ích.

### H5 — Governance
**C6. Audit chain hoạt động thế nào?** Mỗi bản ghi hash nối tiếp bản trước (SHA-256 hash-chain) + **ký RSA vào head**. Sửa bất kỳ record nào → hash lệch → verify gãy.

**C7. Vì sao cần ký RSA head, hash-chain chưa đủ?**
Hash-chain tự chứa: kẻ tấn công sửa 1 record rồi **tính lại toàn chain** thì hash vẫn khớp. Ký RSA head = **mỏ neo ngoài** kẻ tấn công không có private key → sửa xong không ký lại được → gãy.

**C8. Chứng minh H5 bằng tấn công nào?** Sửa `high`→`LOW` ở record 1 → verify in `AUDIT_HASH_MISMATCH line=1` [đo thật]. Chuỗi bình thường → `AUDIT_CHAIN_VALID` [đo thật].

**C9. H5 có cần model không?** **KHÔNG** — toàn mật mã, chạy 100% offline. Đây là điểm quan trọng: H5 mạnh không phụ thuộc AI.

**C10. Còn control H5 nào khác?** `secrets-scan` (chặn commit `.env`/private key, `PASS=6` [đo thật]); `circuit-breaker-check` (no-bypass: cấm `--no-verify` [đo thật]); tách khoá riêng khỏi git (chỉ public key trong repo).

### H6 — AgentOps
**C11. Câu hỏi chốt của H6 là gì?** *"Nếu một step đột nhiên tốn gấp 3 lần token, có ai biết không?"*

**C12. cost-spike-detect làm gì?** Đọc `provider-usage.jsonl`, tính **median total_tokens**, flag step > 3× median. [đo thật] seed 4 record (median 220, plan=710) → `SPIKE step=plan tokens=710 (>660) COST_SPIKE_DETECTED exit=2`. Negative case → `COST_SPIKE_NONE exit=0`.

**C13. Token đo từ đâu (không bịa)?** Từ **provider telemetry thật**: Ollama trả `prompt_eval_count + eval_count`; OpenAI trả `usage.prompt_tokens + completion_tokens`. **Không ước lượng.**

**C14. drift-detect là gì?** So 2 artifact bằng difflib thật (similarity ≠ 1.0) → phát hiện model đổi hành vi. [đo thật] `DRIFT_WARN similarity=0.7692`.

**C15. Vai trò AI local trong H6?** **Nguồn dữ liệu**: mỗi lời gọi model ghi token thật vào `provider-usage.jsonl`. **Logic cost-spike/drift là deterministic** — model chỉ *cấp dữ liệu*, không quyết định.

**C16. H6 còn thiếu gì để full điểm?** Cần **1 lần chạy pipeline ≥3 step** để có telemetry runtime thật (hiện offline chỉ có data seed). [chưa đo — cần chạy pipeline ở nhà].

---

## PHẦN D — CÁC HARNESS CÒN LẠI (H1/H2/H3/H7)

**D1. H1 Context?** Đưa đúng artifact vào agent qua `pipeline-context.yaml`. [đo thật] `CONTEXT_VALID checked=24 all referenced artifacts present`.

**D2. H2 Tool?** Gọi tool đúng quyền, có audit + timeout + JSON-schema. [đo thật] `TOOL_AUDIT_VALID records=18`; `validate-tool-input.sh` chặn tool sai schema (`TOOL_INPUT_INVALID exit=2`); `tool-exec.sh 2 -- <cmd treo>` → `TOOL_EXEC_TIMEOUT after 2s`.

**D3. H3 Evaluation?** Gate AND(rule, model): plan thiếu tiêu chí → REJECT trước khi tốn model (fail-before); model trả rác → fail-closed. [đo thật] rule-path `PASS=3` (model SKIP khi offline, non-blocking) + vitest 16/16.

**D4. H7 Orchestration?** Rollback thật (checkpoint→restore, before==after) + drift + fallback. [đo thật] adversarial `PASS: H7 rollback genuinely restores the file`.

**D5. Vì sao H3 không phải trọng tâm lần này?** Vì H3 đã tốt sẵn (bản cũ 85). Lần này dồn vào 3 GAP: H4/H5/H6.

---

## PHẦN E — MODEL: local vs cloud, tự chủ

**E1. Có OpenAI key thì bỏ được Ollama không?** **KHÔNG với code hiện tại.** `model-call.py` nhánh cloud là **stub**: có key vẫn `fail("cloud_backend_not_implemented_in_wave1")` [đo thật đọc code]. Phải cài thêm ~20 dòng patch (xem `CASAN_MASTER_RUNBOOK.md` Mục 4).

**E2. Còn cần Linux server không?** Server chỉ để host Ollama. Có thể cài **Ollama ngay trên Mac** → bỏ server. Hoặc patch OpenAI → bỏ cả Ollama lẫn server.

**E3. Vì sao local AI ghi điểm CASAN?** Trụ cột **Sovereign AI / Harness tự chủ**: red-team corpus, spec, audit, telemetry **không rời máy**. Và **tái lập offline** — giám khảo replay không cần API key/mạng.

**E4. ornith:9b là "trần" hay "sàn"?** **Sàn**: đủ để thắng regex (0.00) và cấp telemetry thật, nhưng recall (~0.85) thua frontier (1.00). Nói thẳng điều này = đúng tinh thần "honest scope".

**E5. Model chạm tới harness nào?** Chỉ **H4** (recall) và **H6** (nguồn telemetry). **H5 hoàn toàn không cần model.** Phần lớn control là deterministic.

**E6. Chạy full pipeline để gen source thì dùng model càng đắt càng tốt?** **KHÔNG.** Model tham gia 2 vai: (1) *sinh source* và (2) *cổng harness* (H3 judge, H4 semantic). Với **repo hiện tại**, phần sinh source là **template deterministic** trong `casan-step.mjs` [đo thật đọc code] → đổi model đắt **không đổi output**. Còn 2 cổng harness chỉ cần model "đủ khôn để phân loại", không cần frontier. Thêm nữa: đốt token vô tội vạ sẽ **tự kích hoạt `cost-spike` (exit=2)** của chính H6 → mâu thuẫn thông điệp "kiểm soát chi phí". **Điểm cộng là kiểm soát được chi phí, không phải dùng model xịn nhất.**

**E7. Chỉ dùng model local có đủ tốt không?** **Đủ cho đúng phần việc harness.** H4 (chặn injection semantic) và H3 (chấm đạt/không đạt) không cần GPT-4/Claude — `ornith:9b` thừa sức, và nếu vắng model thì gate `SKIP` (không vỡ pipeline). Bonus: **không API key, không tốn tiền, dữ liệu không rời máy** — hợp bối cảnh thi/demo và đúng trụ cột Sovereign AI. Cloud/đắt chỉ đáng cân nhắc khi *thật sự* nối LLM vào phần sinh code và gặp việc suy luận phức tạp — kể cả lúc đó là **"chọn model phù hợp", không phải "đắt nhất"**.

**E8. Pipeline còn sinh cả source dự án (không chỉ vỏ harness) — với codebase lớn/logic phức tạp hơn OKR thì vai trò model thế nào theo tư tưởng CASAN?** Tư tưởng cốt lõi: **model là "công nhân sinh code", KHÔNG phải nguồn tin cậy.** Niềm tin đến từ **harness deterministic**, không đến từ việc model thông minh cỡ nào. Cụ thể:
- **Codebase lớn hơn KHÔNG đòi model khôn hơn để AN TOÀN** — nó đòi **harness mở rộng theo**: H1 kiểm nhiều ngữ cảnh hơn, H2 siết nhiều tool hơn, H3 chấm nhiều artifact hơn, H4 quét nhiều bề mặt hơn. Dù model frontier hay local, **output vẫn phải qua đúng bộ cổng đó**.
- **CASAN scale bằng CHIA NHỎ + vòng lặp review, không bằng "model to hơn":** mỗi bước là 1 lời gọi được harness bọc; các vòng REJECT (STEP5/7/11) và H3 model-as-judge bắt lỗi/drift từng phần. Việc phức tạp được bẻ nhỏ tới mức mỗi mảnh kiểm chứng được.
- **Model là hàng hoá thay thế được; harness là tài sản.** Đổi Ollama↔Claude↔GPT không đổi *đảm bảo an toàn/governance* — chỉ đổi *năng suất/chất lượng bản nháp*. Vì thế chọn model theo nguyên tắc **"rẻ nhất mà vẫn qua được cổng H3"**, chỉ **leo thang khi H3/review liên tục từ chối** (escalation-on-demand), không mặc định dùng đắt.
- **Kỷ luật chi phí luôn còn:** H6 `cost-spike` là hàng rào để dự án phức tạp không đốt ngân sách — càng lớn càng cần cổng này, không phải càng cần model đắt.
- **Nói thẳng phạm vi:** trong repo hiện tại phần sinh code là template; muốn LLM *thật sự* sinh code cho dự án lớn thì thay các `write(...)` bằng lời gọi model — nhưng **kiến trúc kiểm soát không đổi**: sinh xong vẫn chui qua H1→H7.

**E9. Vậy một câu chốt về vai trò model trong CASAN?** *"Model sinh ra bản nháp; harness quyết định bản nháp có được tin hay không."* Chất lượng model ảnh hưởng **số lần bị review từ chối**, không ảnh hưởng **mức đảm bảo an toàn** — mức đó do các cổng deterministic H1–H7 giữ, bất kể model nào.

---

## PHẦN F — NÂNG CAO: tấn công, MAESTRO, triết lý

**F1. "Cross-layer attack chain" là gì?** Chuỗi tấn công xuyên nhiều lớp MAESTRO: injection (L1) → lạm dụng tool (L3) → rò rỉ data (L2) → hành động sai (L4). Framework theo từng lớp riêng lẻ **bỏ sót** nó. Harness chặn ở nhiều lớp (defense-in-depth): H4 chặn đầu → H2 schema chặn tool → H4 timeout → H5 audit ghi lại.

**F2. Stack 6 lớp bảo mật CASAN gồm gì?** NIST AI RMF (quản trị rủi ro), OWASP LLM Top 10 + Agentic Top 10 (lỗ hổng ứng dụng), CSA MAESTRO (threat model 7 lớp), MITRE ATLAS (tri thức tấn công), ISO/IEC 42001 (chứng nhận), EU AI Act (pháp lý). Áp dụng **tích luỹ theo cấp**.

**F3. Vì sao "có prompt-filter.yaml" không đủ điểm?** Vì file chỉ *khai báo ý định*. Bản GHCP gốc có file "block jailbreak" nhưng **leak private key** do lỗi grep → chứng minh "có file ≠ có năng lực". Điểm chỉ tính khi **chặn được tấn công thật**.

**F4. Vì sao "harness thấp nhất quyết định trần"?** Vì kẻ tấn công đi vào chỗ yếu nhất. Dù H1/H3 = 90, nếu H4 = 0 (không chặn injection) thì trong production agent vẫn bị chiếm quyền → cả pipeline không thể gọi là Level 4 thật.

**F5. L0–L5 (mức uỷ quyền AI) là gì?** L0 quan sát → L1 nháp (người duyệt 100%) → L2 đề xuất → L3 thực thi rủi ro thấp → L4 vận hành workflow có hàng rào → L5 tự chủ cao trong vùng governance nghiêm ngặt.

**F6. Vì sao app OKR "không đổi" lại là điểm mạnh, không phải điểm yếu?** Vì nó chứng minh giá trị nằm ở **harness tái sử dụng được** cho *bất kỳ* sản phẩm nào — không phải sửa app cho đẹp. App là testbed cố định để so sánh công bằng.

---

## PHẦN G — THỰC HÀNH / VẬN HÀNH

**G1. Chạy full self-scoring bằng gì?** `bash packages/casan-harness/scripts/bash/security-gate.sh` → kỳ vọng `PASS=10 FAIL=0 SKIP=0` (khi có model + node).

**G2. Vì sao trên máy sạch harness "FAIL" lúc đầu?** Do **môi trường**: thiếu `python` (script gọi `python` không phải `python3`), BSD grep, thiếu coreutils, hoặc msys fork trên Windows. **Không phải control giả** — vá xong là xanh. [đo thật: casan4 35/35 sau khi có python].

**G3. Chạy pipeline để sinh telemetry H6?** `node scripts/run-casan-pipeline.mjs` (cần model sống). Sinh `provider-usage.jsonl` + audit chain. Xem `CASAN_MASTER_RUNBOOK.md` Mục 5.

**G4. Môi trường tái lập sạch nhất?** Docker `node:24-slim` + apt `python3 openssl git curl jq`. [đo thật] đủ chạy 35/35, 43/43, cost-spike, vitest 16.

**G5. Muốn secrets-scan sạch (không warning)?** Chạy trong **git repo thật** (`git init`) — vì nó dùng `git ls-files`.

---

## PHẦN J — HARNESS vs SẢN PHẨM OKR & CÁCH DÙNG THỰC TẾ

**J1. Harness có liên quan gì tới app OKR không?**
Về bản chất **tách biệt**. **OKR chỉ là testbed** (sản phẩm mẫu để chứng minh). **Harness** (`packages/casan-harness/scripts/bash/*` + `.specify/level5/*`) là **lớp kiểm soát dùng chung**, **không phụ thuộc OKR** — `casan-harness.sh` nhận `-- <bất kỳ lệnh nào>` nên bọc được mọi agent/domain. Hai thứ chỉ "đấu dây" tại **một file**: `scripts/run-casan-pipeline.mjs` (nó gọi `casan-harness.sh ... -- node casan-step.mjs <step>`). Bỏ OKR đi, harness vẫn nguyên vẹn dùng cho dự án khác.

**J2. Có mấy cách dùng hệ thống?** **Hai:**

| | (A) Pipeline 1 lệnh | (B) Chat tương tác (Spec-Kit) |
|---|---|---|
| Chạy | `node scripts/run-casan-pipeline.mjs` | Mở IDE (Claude Code / GitHub Copilot) → gõ slash command từng bước |
| Ai điều khiển | Boss tự chạy 13 bước | **Con người** chat với agent |
| Harness | ✅ **ép buộc bằng code** | ⚠️ **theo protocol (mềm)**, xem J5 |
| Dùng cho | demo/CI/tái lập bằng chứng | phát triển thật, làm từng bước |

**J3. Cách (A) — pipeline 1 lệnh — làm gì?**
Một lệnh chạy toàn bộ 13 bước SRS→…→deploy. Trong `run-casan-pipeline.mjs`, **mỗi bước** được bọc:
```
casan-harness.sh <input> <output> agent_step_<id> -- node casan-step.mjs <step>
```
→ Harness (H1→H7) **thực thi thật** trước/sau mỗi bước: chặn injection (rc=2), ghi audit ký số, đo cost-spike… Đây là nơi "chạy có bằng chứng" là **thật** [đo thật].

**J4. Cách (B) — "setup rồi chat" — cụ thể thế nào?**
Đúng như bạn hình dung: trong IDE có agent, bạn gọi **lệnh slash lần lượt**, ví dụ:
```
/casan.srs         → sinh SRS
/speckit.specify   → sinh spec.md
/speckit.plan      → sinh plan.md
/speckit.tasks     → sinh tasks.md
/speckit.implement → sinh code
```
Mỗi lệnh là một **prompt agent** (`.github/prompts/*` hoặc `.claude/commands/*`). Bạn chat, review, gọi bước tiếp. Đây là luồng phát triển bình thường.

**J5. Khi chat (cách B), harness CÓ tự chạy không?**
**Không tự động ở repo hiện tại** [đo thật — grep các file slash-command không hề gọi script harness]. Có tài liệu `casan-harness-protocol.md` ghi harness là **"mandatory cho Boss và mọi agent step"** kèm gate pattern, **nhưng đó là hướng dẫn** — enforcement phụ thuộc agent **có tuân theo** hay không.
→ Phân biệt quan trọng:
- **Pipeline (A) = enforcement CỨNG** (gọi trong code, không thể bỏ qua).
- **Chat (B) = enforcement MỀM** (agent phải chủ động chạy script theo protocol; nếu không, bước đó không qua harness).

**J6. Gate pattern chuẩn khi chat (theo protocol) là gì?**
Trước mỗi bước:
```
security-check.sh  "$IN"  "$SAFE"     input      # H4 quét đầu vào
governance-check.sh "$SAFE" "$OK" "$ACTION"       # H5 risk + audit
```
Bọc lúc thực thi:
```
agent-metrics.sh "$OK" "$OUT" -- <lệnh thật>      # H6 telemetry
```
Sau khi có output:
```
security-check.sh "$OUT" "$FINAL" output          # H4 quét đầu ra
```
Hoặc gọn bằng wrapper `casan-harness.sh ... -- <lệnh>`. Muốn chat "có kiểm soát thật" thì agent phải chạy đúng các lệnh này.

**J7. High-risk trong chat được duyệt thế nào (không interactive)?**
Theo protocol: rủi ro cao **bị từ chối** trừ khi có **cả hai** biến:
```
CASAN_APPROVAL_DECISION=approve
CASAN_APPROVER=<tên architect/reviewer>
```
Pipeline **cấm** dùng `read` tương tác — mọi quyết định phải **deterministic + auditable**.

**J8. Vậy khi THI nên demo cách nào?**
Demo **cách (A) pipeline 1 lệnh** — vì đó là nơi harness **ép cứng** và sinh bằng chứng thật (exit-code, audit, cost). Nói rõ: chat mode (B) là luồng phát triển, và **hợp nhất "chat cũng đi qua harness"** là mục tiêu Plan-01 (CLI `casan run`) + Plan-02 (agent thật gọi qua wrapper).

**J9. Làm sao để chat mode cũng ép harness (không còn mềm)?**
Ba hướng (thuộc roadmap): (1) đóng gói CLI `casan run <step>` để agent gọi 1 lệnh là qua đủ H1→H7 (Plan-01); (2) sửa prompt slash-command **nhúng** gate pattern J6; (3) Plan-02 thay `casan-step.mjs` template bằng agent thật nhưng **bắt buộc qua `casan-harness.sh`**. Đích: dù (A) hay (B), mọi lời gọi đều xuyên harness.

**J10. Chốt một câu?**
> **Harness ≠ OKR** — OKR là testbed, harness là lớp kiểm soát tái dùng. Có 2 cách dùng: **pipeline 1 lệnh** (harness ép cứng, để demo) và **chat Spec-Kit** (harness hiện mới ở mức protocol mềm). Hợp nhất hai đường là việc Plan-01/02 nhắm tới.

---

## PHẦN H — CÂU HỎI BẪY / PHẢN BIỆN (test hiểu sâu)

**H1. "Điểm ~84 là bạn tự chạy ra đúng không?"** Không hoàn toàn — số gốc là **casan5 tự chấm**. Tôi **tự chạy per-item** xác nhận ~83 và ghi rõ cái nào VERIFIED, cái nào chờ Ollama (recall 9B, telemetry H6). Trung thực là tiêu chí.

**H2. "adversarial báo 44 PASS mà bạn chỉ ra 43?"** Đúng — tôi tự đo **43 PASS** offline; 1 chênh là 2 test model SKIP khi không có Ollama (non-blocking). macOS+Ollama mới đủ 44. Không giấu.

**H3. "Cost-spike bạn demo bằng data seed, có phải bịa không?"** Không — tôi **chứng minh LOGIC control** hoạt động bằng dữ liệu kiểm soát (positive + negative). Dữ liệu token THẬT đến từ chạy pipeline (Mục G3). Tôi nói rõ đâu là seed, đâu là runtime.

**H4. "OpenAI key là chạy được ngay chứ gì?"** Sai — cloud backend là **stub chưa cài** (đọc code). Nói "chạy ngay" là bịa.

**H5. "Vì sao không tin 100% điểm của chính dự án?"** Vì nguyên tắc CASAN: điểm phải **chứng minh được bằng tấn công**, không phải trích dẫn. Bản GHCP gốc từng bị thổi phồng (file "block jailbreak" nhưng leak).

**H6. "Bản cũ chạy PASS=11 adversarial mà, sao bảo yếu?"** Vì `PASS=11` của bản cũ là **ảo do môi trường cũ dung thứ bug**. Trên grep hiện đại, `security-check.sh` bản cũ **fail-open rc=4** — không chặn cả injection kinh điển [đo thật].

**H7. "Nếu H6 chưa có telemetry runtime thì Level 4 có thật không?"** Logic H6 đã chứng minh (cost-spike/drift chạy đúng). Chỉ thiếu *dữ liệu runtime* — cần 1 lần chạy pipeline. Theo "harness thấp nhất quyết định trần", H6 (~82) đang là mục cần đóng nốt để chắc trần.

**H8. "Khác biệt casan-old vs casan5 trong 1 câu?"** *"casan-old thắng được một buổi demo; casan5 sống sót trong production"* — vì control giờ **chặn được tấn công thật, có exit code**, không phải "có file".

---

## PHẦN I — CHECKLIST HIỂU BÀI (tự kiểm tra thành viên)

Thành viên đạt nếu trả lời được:
- [ ] 3 harness trọng tâm + điểm GAP cũ (H4=20, H5=25, H6=30).
- [ ] Bug fail-open `[:space:]` của bản cũ và cách bản mới sửa.
- [ ] Vì sao ký RSA head (chống re-forge chain).
- [ ] Câu hỏi chốt H6 + cách cost-spike trả lời (exit=2).
- [ ] Regex 0.00 vs model recall — vì sao cần semantic.
- [ ] OpenAI hiện là stub, muốn dùng phải patch.
- [ ] Vai trò AI local: chỉ chạm H4/H6, H5 độc lập; giá trị lớn là tự chủ dữ liệu.
- [ ] Phân biệt [đo thật] vs [dự án tự báo].

---

_Tài liệu này bám bằng chứng đã kiểm chứng trong repo. Nhãn [đo thật] = có exit code thật (Docker node:24-slim + WSL, 2026-07-02). Tham chiếu: `CASAN_OLD_vs_CASAN5_Executive_Assessment.md`, `CASAN_MASTER_RUNBOOK.md`, `casan_harness_assessment.md`, `FPT_CASAN_Full.md`._