thanhnvandClaude Opus 4.8
fa3dd94c76
The plan set (Plan-00..18, backlog/hardening/QA status, team allocation) is the ONGOING roadmap, not a finished competition artifact — restored from history into docs/plans/. Plan-01 (restructure) marked ✅ done; the rest remain to do. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
145 lines
11 KiB
Markdown
145 lines
11 KiB
Markdown
# 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ý)._
|