# CASAN — Q&A: Vì sao phải làm các Plan mới? > Bộ hỏi–đáp để **bảo vệ roadmap** (Plan 01–10, 12, 08 + backlog phase sau) khi bị chất vấn: *"đã có H4/H5/H6 rồi, sao còn nhiều plan thế?"*. Trả lời thống nhất cho cả nhóm. > > Nguyên tắc: mỗi câu nêu **vấn đề nếu KHÔNG làm** → **lợi ích khi làm** → **mức độ/thời điểm**. Nhãn: [đo thật] · [dự báo] · [mới=chưa xây]. --- ## PHẦN A — Câu hỏi tổng (roadmap) **A1. Đã có H4/H5/H6 chạy được rồi, sao còn cả loạt plan?** Vì cuộc thi và bản thân hệ thống có 3 tầng mục tiêu: (1) **cải thiện H4/H5/H6** — đã làm & đo [đo thật]; (2) **hiểu sâu** — đã nhận diện đường lọt (Plan-07); (3) **hướng production packaging** — đây mới là phần các plan mới giải quyết. Dừng ở H4/H5/H6 chỉ chứng minh "chặn được", chưa chứng minh "**đóng gói, tái dùng, có bằng chứng, đo được chất lượng, vận hành được trong tổ chức**". **A2. Có phải đang "vẽ việc" / scope creep không?** Không — vì chúng tôi **cố ý không mở hết**. Chỉ 3 plan mới đáng làm sớm (09, 10, 12); phần còn lại (B1–B6) **gộp vào 1 file backlog** đánh dấu "chưa xây". Đây chính là biểu hiện kiểm soát phạm vi, không phải phình. **A3. Vì sao không làm tất cả cùng lúc?** Vì (a) rủi ro vỡ bản demo đang chạy; (b) một số plan **phụ thuộc nhau** (ví dụ Domain Pack cần restructure xong; Model benchmark cần nối model thật xong mới có số). Làm sai thứ tự = tốn công mà không có bằng chứng. **A4. Roadmap này có làm mất tính trung thực khi trình bày không?** Không, nếu nói đúng nhãn: *"phần đã làm & đo là H4/H5/H6 + hardening; Evidence Pack và Traceability MVP đã có test; Domain Pack là bước kế tiếp đã có kế hoạch; state machine/governed memory là tầm nhìn dài hạn chưa xây."* Ranh giới rõ ràng = điểm cộng độ chín. **A5. Nếu chỉ được chọn 3 plan, chọn gì và vì sao?** **09 Evidence Pack · 10 Traceability · 12 Domain Pack.** Ba cái này nâng CASAN từ "harness bảo vệ AI" lên "**nền tảng AI-SDLC có bằng chứng, đo chất lượng, tái dùng đa domain**" — đúng 3 trục thi. --- ## PHẦN B — Vì sao cần TỪNG plan **B-01. Vì sao cần Plan-01 Tái cấu trúc?** - *Không làm:* 31 script phẳng, harness trộn với Spec-Kit, sửa 1 dự án phải sửa nhiều chỗ → không thể tái dùng chuyên nghiệp. - *Làm được:* tách `packages/casan-harness` khỏi `apps/`, gate nhóm theo H1–H7, config/domain tách rời → nền cho mọi plan sau (09/12 phụ thuộc nó). - *Mức:* nền tảng, ưu tiên cao. **B-02. Vì sao cần Plan-02 Nối LLM sinh source?** - *Không làm:* hiện source là **template deterministic** [đo thật] — chưa phải AI thật sinh. Tuyên bố "AI sinh code" sẽ **không đúng**. - *Làm được:* LLM thật sinh artifact nhưng **vẫn qua H1→H7**; đúng nghĩa "AI-SDLC có kiểm soát". - *Mức:* cao, nhưng sau 03 (cần model mạnh cho bước khó). **B-03. Vì sao cần Plan-03 Patch cloud?** - *Không làm:* nhánh cloud là **stub** [đo thật] — cắm key vẫn fail. Không mở được đa nhà cung cấp. - *Làm được:* OpenAI/Anthropic chạy thật, giữ SSRF guard + fallback local. - *Mức:* cao, độc lập. **B-04. Vì sao cần Plan-04 Tự cải tiến?** - *Không làm:* cải tiến ngưỡng/corpus/golden làm tay, dễ quên, không audit. - *Làm được:* `casan improve` **đề xuất** tự động + **người duyệt** + ghi audit → cải tiến có kiểm soát. - *Mức:* trung, cần 01+05. **B-05. Vì sao cần Plan-05 CI/CD?** - *Không làm:* gate chạy tay, PR lỗi vẫn merge, không có bằng chứng CI. - *Làm được:* mỗi PR chạy security+adversarial+harness; đỏ thì chặn merge; SemVer + release. - *Mức:* trung, nên sớm. **B-06. Vì sao cần Plan-06 Onboard dự án 2?** - *Không làm:* tuyên bố "tái dùng" chỉ là lý thuyết — registry còn 2 entry **demo**, dự án thật = 1 [đo thật]. - *Làm được:* `HARNESS_REUSE_VALID project_count=2` **thật** → bằng chứng reuse mạnh nhất. - *Mức:* cao (chứng minh reuse). **B-07. Vì sao cần Plan-07 Production hardening?** - *Không làm:* còn đường lọt thật (semantic SKIP, telemetry chưa bất biến, thiếu trần chi phí, tool misuse, supply-chain, sandbox…). "PoC tốt" nhưng chưa production. - *Làm được:* Track A → ~3.8–4.0; Track B+C → production nghiêm túc; kín đòn phản biện. - *Mức:* cao (bảo mật). **B-08. Vì sao cần Plan-08 Nén context?** - *Không làm:* token/cost tăng theo độ dài; không có tối ưu. - *Làm được:* giảm token/latency/cost **mà không phá governance** (scan raw trước, must-keep, faithfulness). - *Mức:* trung, sau Plan-07 core (nén thêm bề mặt rủi ro). **B-09. Vì sao cần Plan-09 Evidence Pack?** - *Không làm:* trả lời "vì sao tin output?" bằng **cảm tính**; bằng chứng nằm rải rác. - *Làm được:* mỗi run có **proof pack** (H1–H7 + red-team + cost + ký) — "giấy khai sinh + giấy kiểm định". - *Mức:* **cao, đáng làm sớm** (rẻ vì gom dữ liệu đã có, ăn điểm thi). **B-10. Vì sao cần Plan-10 Traceability?** - *Không làm:* sinh code nhanh nhưng **không chứng minh code đáp ứng requirement nào** — đúng điểm yếu chung của AI coding tool. - *Làm được:* ma trận REQ→SRS→spec→task→code→test→evidence, đánh dấu GAP; H3 REJECT nếu REQ critical không cover. - *Mức:* cao (khác biệt nhất). **B-12. Vì sao cần Plan-12 Domain Pack?** - *Không làm:* onboard dự án mới phải copy folder tay → reuse không "platform". - *Làm được:* khai báo `domain-pack.yaml` là xong, **không sửa gate**. - *Mức:* trung–cao, sau Plan-01. **B-13. Vì sao cần Plan-13 Control Plane?** - *Không làm:* chỉ có dashboard **read-only**; mọi cấu hình (compression, threshold, kill-switch, model routing) sửa tay qua file, không UI, không audit thay đổi, không RBAC → không vận hành được ở tổ chức lớn. - *Làm được:* web app **React+NestJS** giám sát + **quản lý settings** với deny-by-default + approval + audit hash-chain + rollback; UI không bypass được gate. **[đo thật]** MVP: backend `npm test` 52/0/3-skip, frontend vitest 20/20. - *Mức:* cao (đòn bẩy vận hành enterprise); phụ thuộc 14 (RBAC) + 04 (approval). **B-14. Vì sao cần Plan-14 RBAC & multi-tenant?** - *Không làm:* chỉ có approval-identity (07-C4), chưa có mô hình quyền → ai-thấy-gì/ai-đổi-gì không kiểm soát; đa dự án không cách ly. - *Làm được:* role×resource×action + tenant isolation, deny-by-default fail-closed, ánh xạ từ IdP; mọi quyết định RBAC vào audit. - *Mức:* cao cho bar tổ chức; nền quản lý an toàn của Plan-13. **B-15. Vì sao cần Plan-15 Responsible AI & Data Governance?** - *Không làm:* thiếu phân loại dữ liệu, PII/retention, model card, RAI report → không đạt yêu cầu FPT §14.3–14.4 khi bị soi. - *Làm được:* classification + gate PII→cloud + model card (nối B4 digest) + RAI report qua Evidence Pack + giải trình REQ→code→test. - *Mức:* bắt buộc cho "bar rất cao"; bổ trợ 09/10/13. --- ## PHẦN C — Vì sao HOÃN (không bỏ) các mục backlog **C1. Vì sao B2 (H7 State Machine) và B4 (Governed Memory) để sau?** Vì là **hạ tầng lớn / rủi ro cao** (state machine = rewrite; memory = nguy cơ poisoning). Với thi/demo là over-scope; checkpoint/rollback hiện [có] đã đủ. Chỉ làm khi chạy production đa run thật. **C2. Vì sao B3 (Model benchmark) chưa làm ngay?** Vì benchmark **cần dữ liệu multi-model thật**. Chưa nối model (Plan-02/03) thì benchmark rỗng — làm sớm là số liệu giả. **C3. Vì sao B1/B5 không thành plan riêng?** Vì đã có mầm: approval trong Plan-07 C4 + Plan-04; auto-remediation là bậc nâng của Plan-04. **Mở rộng chỗ có sẵn** hợp lý hơn tạo plan mới → tránh phình. **C4. Backlog có phải "để đó cho có" không?** Không. Mỗi mục ghi **điều kiện tốt nghiệp** thành plan riêng (plan phụ thuộc xong + có nhu cầu/dữ liệu thật). Đây là quản lý backlog, không phải bỏ xó. --- ## PHẦN D — Câu hỏi bẫy / phản biện **D1. "Nhiều plan thế này bao giờ mới xong? Có phải over-engineering?"** Các plan **độc lập, task-level, có verify** — làm được từng phần, không cần xong hết. Ưu tiên rõ: bảo mật (07) + bằng chứng (09) + khác biệt (10) trước. Phần platform gộp backlog. Đây là **lộ trình có kiểm soát**, ngược với over-engineering. **D2. "Sao không viết lại core sang Rust cho xịn?"** Vì core là **sản phẩm governance cần đọc-được** (script minh bạch = tài sản, giám khảo tự kiểm chứng). Rust chỉ đáng cho **primitive crypto/regex/parse** (hybrid), làm **sau thi**. Bottleneck là I/O + model, không phải CPU. **D3. "Đã bảo mật tốt rồi, thêm plan có thừa không?"** Bảo mật tốt ở **prompt-level**, nhưng production còn tool misuse, supply-chain, data-exfil, sandbox (Plan-07 Track C). Không thêm = hở đúng các câu phản biện production thật. **D4. "Roadmap dài có phải hứa suông?"** Không — mọi tuyên bố gắn nhãn: đã làm & **[đo thật]** (H4/H5/H6, 35/35, 43/43); **[mới]** = có kế hoạch task-level chưa xây. Không trộn hai loại. **D5. "Vì sao không chỉ làm 1–2 thứ cho gọn?"** Chúng tôi **có** làm gọn: chỉ 3 plan mới đáng làm sớm, phần còn lại gộp 1 file. Nhưng "gọn" không đồng nghĩa "thiếu tầm nhìn" — roadmap thể hiện tư duy sản phẩm, miễn là ranh giới đã-làm / sẽ-làm rõ ràng. **D6. "Plan nào rủi ro nhất nếu bỏ qua?"** Bỏ **Plan-07 (hardening)** = hệ dễ bị khai thác thật khi lên production. Bỏ **Plan-09 (evidence)** = mất khả năng chứng minh — đi ngược tim CASAN. Hai cái này rủi ro nhất nếu bỏ. --- ## Câu chốt (một dòng bảo vệ roadmap) > *"H4/H5/H6 chứng minh chặn được và đo được. Các plan mới nâng CASAN từ 'harness bảo vệ AI' lên 'nền tảng AI-SDLC có bằng chứng, đo chất lượng, tái dùng đa domain' — làm theo thứ tự phụ thuộc, ưu tiên cái rẻ-mà-đúng-phương-châm trước, phần platform để backlog và nói rõ là chưa xây."* --- _Liên quan: `CASAN_PLAN_00_INDEX.md` · các plan 01–10, 12–15 · `CASAN_PLAN_FUTURE_PHASES.md` · `CASAN_TEAM_QA.md` (Q&A hệ thống — bản canonical ở `casan-next-plans/`) · `CASAN_TU_TUONG_QA.md` (triết lý)._