thanhnvandClaude Opus 4.8
fbcef967e5
Freeze current submission/demo baseline: - casan-next-plans/: full task-level plan set (Plan 00 index + 02/04/06/07/08/09/12, QA, slide deck) - optimize-docs/video-steps/: per-vector scene breakdown (commands/screen-text/script) + start-tmux - run-all.sh / scorecard.sh / map-live.sh: REAL=1 live-battery wiring - regenerated evidence + audit/telemetry logs from live REAL=1 run - submission README + video recording guide updates - dry-run pipeline logs for 001-okr-web-app Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
9.6 KiB
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/Traceability/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-harnesskhỏiapps/, 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=2thậ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.yamllà xong, không sửa gate. - Mức: trung–cao, sau Plan-01.
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 · CASAN_PLAN_FUTURE_PHASES.md · CASAN_TEAM_QA.md (Q&A hệ thống) · CASAN_TU_TUONG_QA.md (triết lý).