chore(freeze): snapshot demo state before Plan-07 hardening work

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>

casan-next-plans/CASAN_PLAN_QA.md

@@ -0,0 +1,129 @@
+# 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-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.
+
+---
+
+## 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ý)._