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>
This commit is contained in:
thanhnv
co-authored by
Claude Opus 4.8
Claude Opus 4.8
parent
fabd5f8783
commit
fbcef967e5
@@ -0,0 +1,72 @@
|
||||
# CASAN — Bộ Kế hoạch Chi tiết (Index)
|
||||
|
||||
> Bộ kế hoạch **task-level, CHƯA thực thi** cho việc chuyên nghiệp hoá CASAN Harness. Mỗi file là một mảng độc lập, có thể giao cho người/nhóm khác nhau.
|
||||
>
|
||||
> Tài liệu gốc (tổng quan): `CASAN_HARNESS_PACKAGING_PLAN.md`.
|
||||
|
||||
## Danh mục kế hoạch
|
||||
|
||||
| # | File | Mảng | Phụ thuộc | Ưu tiên |
|
||||
|---|---|---|---|---|
|
||||
| 01 | `CASAN_PLAN_01_RESTRUCTURE.md` | Tái cấu trúc thư mục Phase 0→6 | — (nền tảng) | Cao |
|
||||
| 02 | `CASAN_PLAN_02_LLM_SOURCEGEN.md` | Nối LLM thật vào sinh source (thay template) | 01 (một phần), 03 | Cao |
|
||||
| 03 | `CASAN_PLAN_03_CLOUD_PATCH.md` | Patch cloud/OpenAI (bỏ stub) | — | Cao |
|
||||
| 04 | `CASAN_PLAN_04_SELFIMPROVE.md` | Khép vòng `casan improve` | 01, 05 | Trung |
|
||||
| 05 | `CASAN_PLAN_05_CICD.md` | CI/CD + phát hành package | 01 | Trung |
|
||||
| 06 | `CASAN_PLAN_06_ONBOARD.md` | Onboard dự án thật thứ 2 | 01, 05 | Cao (chứng minh reuse) |
|
||||
| 07 | `CASAN_PLAN_07_PRODUCTION_HARDENING.md` | Báo cáo production-readiness + vá đường lọt H4/H5/H6 + Track C (ngoài lõi) | — (Track A độc lập) | **Cao (bảo mật)** |
|
||||
|
||||
> **Thứ tự trong Plan-07:** **Track A** (quick wins) → **Track C-MVP** = C1 Tool-authz + C2 Supply-chain + C3 Data-exfil + C6 Sandbox (**minimum bar** trước khi cho agent ghi code/chạy test production-like) → Track B + C-Governance/Ops (production nghiêm túc).
|
||||
| 08 | `CASAN_PLAN_08_CONTEXT_COMPRESSION.md` | Nén prompt/context giảm token (H1.5 cross-cutting dưới H1/H6) | 01, 07, 03 | Trung (tối ưu, sau Plan-07 core) |
|
||||
| 09 | `CASAN_PLAN_09_EVIDENCE_PACK.md` | Evidence Pack & Certification (proof pack mỗi run) | nhẹ (gom H1–H7) | **Cao (đúng phương châm)** |
|
||||
| 10 | `CASAN_PLAN_10_TRACEABILITY_EVAL.md` | Traceability REQ→code→test + H3 Evaluation (gộp ý "11") | 02, 09 | Cao (khác biệt nhất) |
|
||||
| 12 | `CASAN_PLAN_12_DOMAIN_PACK.md` | Domain Pack SDK — onboard bằng khai báo | 01, 06 | Trung–Cao (reuse thật) |
|
||||
| — | `CASAN_PLAN_FUTURE_PHASES.md` | Backlog phase sau (B1–B6: approval workflow · state machine · model benchmark · governed memory · auto-remediation · platform KPI) | các plan nền | Vision (chưa làm) |
|
||||
|
||||
## Thứ tự thực thi đề xuất (khi được duyệt)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P01["01 Restructure<br/>(nền)"] --> P03["03 Cloud patch"]
|
||||
P01 --> P05["05 CI/CD"]
|
||||
P03 --> P02["02 LLM source-gen"]
|
||||
P05 --> P06["06 Onboard dự án 2"]
|
||||
P01 --> P06
|
||||
P02 --> P04["04 Self-improve"]
|
||||
P05 --> P04
|
||||
P07["07 Hardening<br/>Track A → C-MVP (song song, ưu tiên bảo mật)"]
|
||||
P07 --> P08["08 Context compression<br/>(sau Plan-07 core)"]
|
||||
P09["09 Evidence Pack<br/>(đáng làm sớm)"] --> P10["10 Traceability + H3 Eval"]
|
||||
P01 --> P12["12 Domain Pack SDK"]
|
||||
P06 --> P12
|
||||
|
||||
style P01 fill:#d0e8ff,stroke:#2c3e91,stroke-width:2px
|
||||
style P06 fill:#d0ffd0,stroke:#1e8449
|
||||
style P07 fill:#ffd6d6,stroke:#c0392b,stroke-width:2px
|
||||
style P09 fill:#fff0c0,stroke:#b9770e,stroke-width:2px
|
||||
```
|
||||
|
||||
## Quy ước chung mọi file
|
||||
|
||||
- **Nhãn:** [có] tồn tại thật · [demo] mẫu · [mới] cần làm · [chưa tự động] có đo, người quyết.
|
||||
- **Mốc an toàn:** mọi phase đụng harness phải giữ **35/35 harness + 43/43 adversarial PASS**.
|
||||
- **Verify:** mỗi task có lệnh kiểm chứng + tiêu chí Done. Không đánh dấu Done nếu chưa xem output.
|
||||
- **Không bypass:** cấm `--no-verify`, `SKIP_*`, hardcode verdict (đã có `circuit-breaker-check.sh` quét).
|
||||
- **Đường dẫn tuyệt đối:** script dùng `SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"` để không gãy khi di chuyển.
|
||||
|
||||
## Trạng thái tổng (cập nhật khi chạy)
|
||||
|
||||
| Kế hoạch | Trạng thái | Ghi chú |
|
||||
|---|---|---|
|
||||
| 01 Restructure | ⬜ chưa bắt đầu | |
|
||||
| 02 LLM source-gen | ⬜ chưa bắt đầu | |
|
||||
| 03 Cloud patch | ⬜ chưa bắt đầu | |
|
||||
| 04 Self-improve | ⬜ chưa bắt đầu | |
|
||||
| 05 CI/CD | ⬜ chưa bắt đầu | |
|
||||
| 06 Onboard | ⬜ chưa bắt đầu | |
|
||||
| 07 Production hardening | ⬜ chưa bắt đầu | Track A → **Track C-MVP (C1+C2+C3+C6)** là minimum bar trước khi cho agent ghi code/chạy test production-like |
|
||||
| 08 Context compression | ⬜ chưa bắt đầu | H1.5 cross-cutting; làm **sau** Plan-07 core (nén thêm bề mặt rủi ro) |
|
||||
| 09 Evidence Pack | ⬜ chưa bắt đầu | **Đáng làm sớm** — rẻ, đúng phương châm, ăn điểm thi |
|
||||
| 10 Traceability + H3 Eval | ⬜ chưa bắt đầu | Khác biệt nhất; lõi = ma trận REQ→code→test |
|
||||
| 12 Domain Pack SDK | ⬜ chưa bắt đầu | Cần Plan-01 xong trước |
|
||||
| Future phases (B1–B6) | 💤 vision | Backlog `CASAN_PLAN_FUTURE_PHASES.md` — chưa xây |
|
||||
@@ -0,0 +1,87 @@
|
||||
# KẾ HOẠCH 02 — Nối LLM thật vào sinh source (thay template deterministic)
|
||||
|
||||
> Hiện `casan-step.mjs` sinh SRS/spec/plan/code bằng **template hard-code** trong `switch(step)` [có, đọc code]; model chỉ dùng ở H3 judge + H4 semantic. Kế hoạch: cho LLM **thật sự sinh artifact**, nhưng **mọi output vẫn chui qua H1→H7**. Task-level, chưa thực thi.
|
||||
>
|
||||
> Phụ thuộc: nên làm sau **03 (cloud patch)** để có lựa chọn model mạnh cho bước khó; **01** giúp gọn nhưng không bắt buộc.
|
||||
|
||||
## Bối cảnh code hiện tại [có]
|
||||
- `casan-step.mjs`: mỗi `case '<step>'` gọi `write(path, "<nội dung khuôn>")` rồi `report(...)`.
|
||||
- `judgeArtifact()` gọi `model-router.sh --role judge`; `ollamaAvailable()` kiểm 127.0.0.1:11434; vắng model → `SKIP` (không chặn).
|
||||
- `model-router.sh` → `model-call.py` là điểm gọi model chuẩn (đã có H4 trước, H6/H5 sau).
|
||||
|
||||
## Nguyên tắc
|
||||
- **Sinh xong vẫn qua harness:** không được để LLM ghi thẳng bỏ qua H4/H5/H7.
|
||||
- **Có golden để so:** mỗi step cần tiêu chí chấp nhận + golden (drift/H3) để bắt output kém.
|
||||
- **Chuyển dần từng step**, không thay cả 13 bước một lúc.
|
||||
- **Fallback về template:** model vắng/kém → dùng template cũ (không vỡ pipeline).
|
||||
- **Deterministic-friendly:** cố định seed/nhiệt độ thấp cho bước cần ổn định; ghi lại prompt vào audit (H5).
|
||||
|
||||
---
|
||||
|
||||
## Chiến lược chuyển đổi (từng step, có cổng)
|
||||
|
||||
Thứ tự chuyển ưu tiên step **rõ ràng, ít rủi ro** trước:
|
||||
|
||||
| Đợt | Step chuyển | Vì sao trước/sau |
|
||||
|---|---|---|
|
||||
| A | `01-srs`, `02-bd` | văn bản có cấu trúc, dễ chấm, rủi ro thấp |
|
||||
| B | `03-spec`, `06-plan` | có review loop (STEP5/7) đỡ lỗi |
|
||||
| C | `08-dd`, `09-tasks` | phụ thuộc spec/plan tốt |
|
||||
| D | `10-implement` (code) | rủi ro cao nhất → làm cuối, cần test thật (STEP12) làm lưới |
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
| Task | Việc | File | Verify | Done khi |
|
||||
|---|---|---|---|---|
|
||||
| 2.1 | Trừu tượng hoá: thêm hàm `generate(step, ctx)` chọn **model** hoặc **template** theo cờ `CASAN_GEN_MODE` | `casan-step.mjs` | mode=template → hành vi cũ y hệt | không hồi quy |
|
||||
| 2.2 | Viết prompt-template cho mỗi step (đưa requirement + architecture + tiêu chí chấp nhận vào prompt) | mới `prompts/<step>.md` | prompt render đủ ngữ cảnh | có prompt từng step |
|
||||
| 2.3 | Gọi model qua `model-router.sh --role generate` (KHÔNG gọi model-call trực tiếp) | `casan-step.mjs` | output đi qua H4 trước khi ghi | harness bọc |
|
||||
| 2.4 | Chuẩn hoá output model → đúng file artifact + `STEP-RESULT` block | parser | verdict/artifacts hợp lệ | schema đúng |
|
||||
| 2.5 | Nạp **golden + tiêu chí** cho H3 judge từng step | `apps/okr/domain/golden-runs/` | judge chấm được đạt/không | H3 hoạt động |
|
||||
| 2.6 | Fallback: model SKIP/kém → dùng template (đợt A/B), hoặc REJECT → vòng review | `casan-step.mjs` | ép model lỗi → không vỡ | fail-safe |
|
||||
| 2.7 | Chuyển đợt A (srs, bd) sang mode=model | pipeline | chạy full, 2 artifact do model sinh, qua harness | đợt A xong |
|
||||
| 2.8 | Chuyển đợt B (spec, plan) + kiểm vòng REJECT hoạt động | pipeline | ép spec kém → STEP5 REJECT → retry | loop chạy |
|
||||
| 2.9 | Chuyển đợt C (dd, tasks) | pipeline | artifact hợp lệ, drift trong ngưỡng | đợt C xong |
|
||||
| 2.10 | Chuyển đợt D (implement code) — **bắt buộc** STEP12 chạy test thật làm cổng | pipeline | test dự án PASS mới nhận code | đợt D xong |
|
||||
| 2.11 | Ghi prompt + model + token vào audit (H5) & telemetry (H6) | logging | audit có prompt, provider-usage có token | truy vết được |
|
||||
|
||||
---
|
||||
|
||||
## Cơ chế chất lượng (không chỉ "sinh cho có")
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
G["generate(step)"] --> H4["H4 quét output"]
|
||||
H4 --> J["H3 judge vs tiêu chí"]
|
||||
J -- "REJECT" --> RETRY["vòng review (STEP5/7/11)<br/>hoặc leo thang model"]
|
||||
J -- "PASS" --> DR["drift vs golden"]
|
||||
DR -- "lệch nhiều" --> RETRY
|
||||
DR -- "ổn" --> WRITE["ghi + audit (H5) + rollback-ready (H7)"]
|
||||
RETRY --> G
|
||||
|
||||
style RETRY fill:#fff0c0,stroke:#b9770e
|
||||
style WRITE fill:#d0ffd0,stroke:#1e8449
|
||||
```
|
||||
|
||||
- **Leo thang model (escalation-on-demand):** step bị H3 REJECT ≥ N lần → tự đề xuất dùng model mạnh hơn (nối 03). Đây là chỗ cloud/frontier đáng dùng.
|
||||
- **Code (đợt D):** cổng cứng là **STEP12 run-tests thật** — code sinh ra không PASS test thì không được nhận.
|
||||
|
||||
## Rủi ro
|
||||
| Rủi ro | Giảm thiểu |
|
||||
|---|---|
|
||||
| Model sinh sai/ảo | H3 judge + drift + test thật; fallback template |
|
||||
| Không ổn định giữa các lần | nhiệt độ thấp/seed; golden so sánh |
|
||||
| Chi phí tăng | H6 cost-spike + circuit-breaker; local trước, cloud khi cần |
|
||||
| Bỏ qua harness | bắt buộc gọi qua `model-router` + wrapper, cấm ghi thẳng |
|
||||
| Regression pipeline | `CASAN_GEN_MODE=template` luôn giữ đường cũ |
|
||||
|
||||
## Tiêu chí HOÀN THÀNH
|
||||
- [ ] `CASAN_GEN_MODE=template` cho hành vi cũ y hệt (an toàn quay lui).
|
||||
- [ ] `CASAN_GEN_MODE=model`: đợt A–D artifact do LLM sinh, **đều qua H1→H7**.
|
||||
- [ ] Code (đợt D) chỉ nhận khi STEP12 test PASS.
|
||||
- [ ] Prompt/model/token vào audit (H5) + telemetry (H6).
|
||||
- [ ] Có escalation khi H3 REJECT lặp; local vẫn là mặc định.
|
||||
|
||||
> Sau kế hoạch này, câu "pipeline sinh source bằng AI" mới **đúng nghĩa**. Trước đó phải nói rõ đang dùng **template**.
|
||||
@@ -0,0 +1,81 @@
|
||||
# KẾ HOẠCH 04 — Khép vòng tự cải tiến (`casan improve`)
|
||||
|
||||
> Hôm nay: ngưỡng tự canh (cost-spike/circuit) [có] + báo cáo KPI/drift [có] + hành động cải tiến cần người [chưa tự động]. Kế hoạch: thêm lệnh `casan improve` **đề xuất** cải tiến tự động, **người duyệt** rồi mới áp, mọi thay đổi vào audit. Task-level, chưa thực thi.
|
||||
>
|
||||
> Phụ thuộc: **01** (CLI/config), **05** (CI để chạy định kỳ). Không tự retrain model.
|
||||
|
||||
## Cơ sở đã có [có]
|
||||
- `cost-spike-detect.sh`: ngưỡng = `median × mult` (tự canh theo dự án).
|
||||
- `circuit-breaker-check.sh`: đếm fail liên tiếp → `CIRCUIT_OPEN`.
|
||||
- `drift-detect.sh`: so golden, ra report JSON.
|
||||
- `business-kpi-report.sh`: `baseline→current→target`, `improvement_ratio`, `target_met`.
|
||||
- Telemetry: `provider-usage.jsonl`, audit chain, drift report.
|
||||
|
||||
## Nguyên tắc (an toàn governance)
|
||||
- **Đề xuất ≠ áp dụng:** `--dry-run` chỉ sinh diff; `--apply` cần người duyệt.
|
||||
- **Không tự nới lỏng bảo mật:** đề xuất *siết* threshold được ưu tiên; đề xuất *nới* phải có lý do + duyệt cấp cao.
|
||||
- **Có bằng chứng:** mọi thay đổi ghi audit-chain (H5) → cải tiến cũng rollback được (H7).
|
||||
- **Nguồn dữ liệu là telemetry thật**, không phải phỏng đoán.
|
||||
|
||||
---
|
||||
|
||||
## Phân loại đề xuất cải tiến
|
||||
|
||||
| Loại | Nguồn tín hiệu | Ví dụ đề xuất | Chiều an toàn |
|
||||
|---|---|---|---|
|
||||
| Tinh chỉnh threshold | cost-spike/circuit history | median trôi → cập nhật baseline; fail nhiều → giảm threshold | siết = tự động; nới = cần duyệt |
|
||||
| Bổ sung corpus | ca H4 để lọt / judge trượt | thêm mẫu tấn công mới vào redteam-corpus | luôn an toàn (tăng phủ) |
|
||||
| Cập nhật golden | spec đổi hợp lệ → drift báo động giả | cập nhật golden theo spec mới | cần duyệt (tránh che drift thật) |
|
||||
| Leo thang model | step bị H3 REJECT lặp | đề xuất model mạnh hơn cho step đó | cần duyệt (chi phí) |
|
||||
| Điều chỉnh KPI target | improvement_ratio ổn định vượt target | nâng target | cần duyệt |
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
| Task | Việc | File | Verify | Done khi |
|
||||
|---|---|---|---|---|
|
||||
| 4.1 | Định nghĩa schema "improvement proposal" (loại, lý do, diff, mức rủi ro) | mới `config/improve-schema.yaml` | proposal mẫu hợp lệ | schema chốt |
|
||||
| 4.2 | `casan improve --dry-run`: đọc telemetry → sinh **danh sách proposal** (không ghi) | `bin/casan`, mới `improve.sh` | chạy ra proposal + diff, KHÔNG đổi file | dry-run an toàn |
|
||||
| 4.3 | Bộ luật đề xuất threshold từ median/fail history | `improve.sh` | dữ liệu mẫu → đề xuất đúng hướng | luật chạy |
|
||||
| 4.4 | Bộ luật gom **ca trượt** (H4 lọt/judge REJECT) → đề xuất mẫu corpus | `improve.sh` | ca trượt mẫu → sinh mẫu corpus | có đề xuất corpus |
|
||||
| 4.5 | `casan improve --apply --proposal <id>`: cần cờ duyệt của người | `bin/casan` | thiếu duyệt → từ chối áp | glate duyệt hoạt động |
|
||||
| 4.6 | Áp xong ghi audit-chain (H5) + tạo checkpoint (H7) | logging | audit có bản ghi cải tiến; rollback được | truy vết + hoàn tác |
|
||||
| 4.7 | Báo cáo xu hướng qua nhiều lần chạy (dashboard) | `generate-agentops-dashboard.py` | biểu đồ improvement_ratio theo thời gian | có xu hướng |
|
||||
| 4.8 | Chặn tự nới lỏng: proposal "nới bảo mật" bắt buộc nhãn `security-sensitive` + duyệt cấp cao | `improve.sh` | proposal nới → yêu cầu duyệt cao | rào chắn hoạt động |
|
||||
|
||||
---
|
||||
|
||||
## Luồng khép vòng
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
T["Telemetry thật<br/>usage · audit · drift · KPI"] --> DRY["casan improve --dry-run<br/>sinh proposal + diff"]
|
||||
DRY --> REV{"Người/governance<br/>duyệt"}
|
||||
REV -- "REJECT" --> T
|
||||
REV -- "APPROVE" --> APP["casan improve --apply<br/>ghi config/ + domain/"]
|
||||
APP --> AUD["audit-chain (H5) + checkpoint (H7)"]
|
||||
AUD --> RUN["lần chạy sau tốt hơn"]
|
||||
RUN --> T
|
||||
|
||||
style DRY fill:#fff0c0,stroke:#b9770e
|
||||
style REV fill:#e6d6ff,stroke:#6c3483
|
||||
style APP fill:#d0ffd0,stroke:#1e8449
|
||||
```
|
||||
|
||||
## Rủi ro
|
||||
| Rủi ro | Giảm thiểu |
|
||||
|---|---|
|
||||
| Tự nới lỏng bảo mật | 4.8 nhãn security-sensitive + duyệt cao; siết mới auto |
|
||||
| Che drift thật khi cập nhật golden | 4.5 cần duyệt + lý do; audit lại |
|
||||
| Đề xuất rác/nhiễu | ngưỡng tín hiệu tối thiểu (đủ mẫu mới đề xuất) |
|
||||
| Áp nhầm | 4.6 checkpoint → rollback |
|
||||
|
||||
## Tiêu chí HOÀN THÀNH
|
||||
- [ ] `casan improve --dry-run` sinh proposal có diff, KHÔNG đổi file.
|
||||
- [ ] `--apply` chỉ chạy sau duyệt; ghi audit + checkpoint.
|
||||
- [ ] Đề xuất "nới bảo mật" bị chặn nếu chưa duyệt cấp cao.
|
||||
- [ ] Dashboard hiển thị xu hướng improvement qua các lần.
|
||||
- [ ] Không có nhánh nào tự retrain / tự nới mà không có người.
|
||||
|
||||
> Ranh giới trung thực: đây là **continuous improvement có người trong vòng lặp** + tự động hoá phần *đề xuất/đo*, KHÔNG phải AI tự tiến hoá.
|
||||
@@ -0,0 +1,66 @@
|
||||
# KẾ HOẠCH 06 — Onboard dự án thật thứ 2 (chứng minh reuse)
|
||||
|
||||
> `project-registry.json` hiện có 1 dự án active (OKR) + 2 entry **demo** (A/B) [demo]. Kế hoạch: onboard **một dự án thật khác domain** để `verify-harness-reuse.sh` trả `HARNESS_REUSE_VALID` một cách có thật — bằng chứng harness tái dùng được. Task-level, chưa thực thi.
|
||||
>
|
||||
> Phụ thuộc: **01** (package tách + config/domain), **05** (CI). Đây là mảng thuyết phục nhất về "tái sử dụng".
|
||||
|
||||
## Mục tiêu
|
||||
- Chọn 1 domain khác OKR (ví dụ: quản lý công việc/ticket, kho hàng, hoặc CRUD nghiệp vụ khác).
|
||||
- Cắm harness **không sửa gate**, chỉ nạp `config` + `domain` (golden/corpus/input).
|
||||
- Chạy pipeline + harness tests đạt PASS + đăng ký registry → reuse hợp lệ thật.
|
||||
|
||||
## Nguyên tắc
|
||||
- **Không chạm `src/gates`:** nếu phải sửa gate → nghĩa là chưa đủ tách; ghi nhận nợ kỹ thuật.
|
||||
- **Domain data tách bạch:** golden/corpus/input của dự án 2 nằm ở `apps/<x>/domain/`, không lẫn OKR.
|
||||
- **Cùng version package:** dự án 2 dùng đúng `harness_version` với OKR để reuse có nghĩa.
|
||||
|
||||
---
|
||||
|
||||
## Tasks
|
||||
|
||||
| Task | Việc | File/Đối tượng | Verify | Done khi |
|
||||
|---|---|---|---|---|
|
||||
| 6.1 | Chọn domain + viết `okr-requirement`-tương đương cho dự án 2 | mới `apps/<x>/docs/input/*.md` | có requirement + architecture | input sẵn sàng |
|
||||
| 6.2 | Tạo `apps/<x>/` theo khuôn app (pipeline trỏ package) | mới | `casan run` gọi được | app khung chạy |
|
||||
| 6.3 | Nạp `config/thresholds.yaml` riêng (hoặc dùng default) | `apps/<x>/config` | override hoạt động | config áp đúng |
|
||||
| 6.4 | Tạo **golden-runs** cho artifact chính của domain 2 | `apps/<x>/domain/golden-runs/` | drift-detect có mốc | golden sẵn |
|
||||
| 6.5 | Tạo **redteam-corpus** cho domain 2 (injection theo ngữ cảnh mới) | `apps/<x>/domain/redteam-corpus/` | H4 chấm recall | corpus sẵn |
|
||||
| 6.6 | Chạy pipeline dự án 2 qua harness | pipeline | mỗi step qua H1→H7, có verdict | chạy trọn |
|
||||
| 6.7 | Chạy harness tests cho dự án 2 | tests | các gate PASS (điều chỉnh fixture theo domain) | test xanh |
|
||||
| 6.8 | `casan register --project <x> --domain <name>` | `project-registry.json` | entry `status: active` | đã đăng ký |
|
||||
| 6.9 | `verify-harness-reuse.sh` | script | `HARNESS_REUSE_VALID ... project_count=2` | reuse thật |
|
||||
| 6.10 | Ghi lại "phần phải sửa" (nếu có) làm nợ kỹ thuật cho 01/03 | mới notes | có danh sách gap | rút kinh nghiệm |
|
||||
|
||||
---
|
||||
|
||||
## Tiêu chí "tái sử dụng thật" (đo được)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
PKG["packages/casan-harness v1.x<br/>(không sửa gate)"] --> A["apps/okr<br/>domain OKR"]
|
||||
PKG --> B["apps/<x><br/>domain mới"]
|
||||
A --> REG["project-registry.json"]
|
||||
B --> REG
|
||||
REG --> V{"verify-harness-reuse"}
|
||||
V --> OK["HARNESS_REUSE_VALID<br/>project_count=2"]
|
||||
|
||||
style PKG fill:#d0e8ff,stroke:#2c3e91,stroke-width:2px
|
||||
style OK fill:#d0ffd0,stroke:#1e8449,stroke-width:2px
|
||||
```
|
||||
|
||||
## Rủi ro
|
||||
| Rủi ro | Giảm thiểu |
|
||||
|---|---|
|
||||
| Phải sửa gate cho domain mới | ghi nợ (6.10) → đẩy về 01/03 tách thêm; không hack tạm |
|
||||
| Corpus/golden domain 2 sơ sài → gate vô nghĩa | tối thiểu N mẫu/gate; review chất lượng |
|
||||
| Reuse "giả" (chỉ copy folder) | bắt buộc cùng `harness_version` + verify script |
|
||||
| Tốn công dựng app 2 | chọn domain nhỏ, đủ để chứng minh, không cần đầy đủ tính năng |
|
||||
|
||||
## Tiêu chí HOÀN THÀNH
|
||||
- [ ] Dự án 2 chạy pipeline qua harness **không sửa `src/gates`**.
|
||||
- [ ] Golden + corpus domain 2 có thật, gate chấm được.
|
||||
- [ ] `project-registry.json` có 2 entry **active thật** (bỏ/đổi demo A/B).
|
||||
- [ ] `verify-harness-reuse.sh` → `HARNESS_REUSE_VALID project_count=2`.
|
||||
- [ ] Nợ kỹ thuật (nếu có) được ghi lại cho kế hoạch 01/03.
|
||||
|
||||
> Đây là bằng chứng mạnh nhất cho tuyên bố "harness tái sử dụng cho nhiều dự án" — trước khi hoàn thành, chỉ nên nói **"cơ chế reuse có, dự án thật = 1, đang onboard dự án 2"**.
|
||||
@@ -0,0 +1,324 @@
|
||||
# KẾ HOẠCH 07 — Báo cáo Production-Readiness & Kế hoạch Nâng cấp H4·H5·H6
|
||||
|
||||
> **Hai phần trong một tài liệu:** (I) *Báo cáo* đánh giá mức sẵn sàng production của H4 Security · H5 Governance · H6 AgentOps, dựa trên đọc code thật; (II) *Kế hoạch nâng cấp* task-level (chưa thực thi) để vá các đường lọt đã nhận diện.
|
||||
>
|
||||
> Nhãn: [có] tồn tại thật · [demo] mẫu · [mới] cần làm · [chưa tự động] có đo/người quyết. Nguồn threat-model: OWASP LLM Top 10, OWASP Agentic Top 10, CSA MAESTRO, MITRE ATLAS.
|
||||
|
||||
---
|
||||
|
||||
# PHẦN I — BÁO CÁO ĐÁNH GIÁ
|
||||
|
||||
## 1. Câu hỏi lớn: "có nên nâng cấp luôn không?"
|
||||
|
||||
**Khuyến nghị: CÓ, nhưng phân tầng — không đập một lúc.**
|
||||
|
||||
- **Nếu sắp thi/demo:** *đóng băng* bản demo hiện tại; làm nâng cấp trên nhánh riêng. Không để việc siết bảo mật làm vỡ bản đang chạy. Trước giám khảo, **nói ra các đường lọt + lộ trình vá** đã là điểm cộng độ trưởng thành.
|
||||
- **Nếu mục tiêu là production thật:** làm **Track A (quick wins, rủi ro thấp) NGAY**, đưa sau cờ bật/tắt + test đối kháng; **Track B (sâu hơn) làm sau**.
|
||||
|
||||
> Lý do phân tầng: một số lỗ hổng (semantic SKIP, thiếu trần chi phí tuyệt đối) vá nhanh & an toàn; số khác (đa ngôn ngữ, quản lý khóa HSM, chống inject bộ phân loại) cần thời gian và dễ gây hồi quy.
|
||||
|
||||
## 2. Thang điểm sẵn sàng production (0–5, cao = tốt)
|
||||
|
||||
| Chiều | Điểm | Hiện trạng [có/đọc code] | Khoảng trống |
|
||||
|---|---|---|---|
|
||||
| Phủ phát hiện (detection) | 3 | Regex + normalize + semantic tùy chọn | Đa ngôn ngữ, encoding, homoglyph |
|
||||
| Fail-safe | 4 | artifact-scan fail-closed rc=2; nhưng semantic **SKIP** khi vắng model | SKIP âm thầm hạ trần |
|
||||
| Toàn vẹn/chống giả mạo (H5) | 3 | hash-chain + ký RSA HEAD | Telemetry chưa trong chain; mutation ngoài wrapper; khóa |
|
||||
| Kiểm soát chi phí (H6) | 3 | cost-spike `median×mult` + circuit-breaker | Slow-boil, dưới-ngưỡng, cold-start, thiếu trần tuyệt đối |
|
||||
| Quan sát (observability) | 3 | telemetry + dashboard | Toàn vẹn telemetry, cảnh báo thời gian thực |
|
||||
| Đa domain/i18n | 2 | Tuned OKR + tiếng Anh | Corpus VI/JA, domain khác |
|
||||
| Quản lý khóa | 2 | vault-kms [có] | HSM/rotation/tách quyền ký |
|
||||
| Phủ kiểm thử | 4 | 35/35 + 43/43 [đo] | Thiếu test cho các vector mới bên dưới |
|
||||
|
||||
**Điểm trung bình (phạm vi H4/H5/H6) ~3.0/5 → "tốt cho demo/PoC, CHƯA đạt chuẩn production đầy đủ".**
|
||||
|
||||
> ⚠️ **Phạm vi rộng hơn (theo review):** các chiều **ngoài 3 harness lõi** hiện còn rất thấp và được xử lý ở **Track C**:
|
||||
|
||||
| Chiều (Track C) | Điểm | Khoảng trống |
|
||||
|---|---|---|
|
||||
| Tool authorization / action gating | 2 | mới có allowlist tên tool, chưa gate hành động (V17) |
|
||||
| Supply-chain (dependency code sinh ra) | 1 | chưa scan package/lockfile/CVE/SBOM (V18) |
|
||||
| Data-governance / anti-exfil | 2 | secret/PII có, nhưng chưa chặn rò qua cloud/log/artifact (V19) |
|
||||
| Policy governance / approval | 2 | thiếu versioning + reviewer bắt buộc (V20) |
|
||||
| External append-only audit | 1 | audit còn local, dễ rotate mất (V21) |
|
||||
| Runtime sandbox | 1 | chưa cô lập code/test sinh ra (V22) |
|
||||
| Incident response | 1 | chưa có severity/owner/kill-switch (V23) |
|
||||
|
||||
**→ Sẵn sàng production *nghiêm túc* thấp hơn ~3.0 nếu tính cả Track C.** Track A nâng H4/H5/H6 lên ~3.8–4.0; Track B+C mới đủ production toàn diện.
|
||||
|
||||
## 3. Bảng đường lọt (tóm tắt từ threat-model)
|
||||
|
||||
| ID | Harness | Đường lọt | Mức | Vá ở Track |
|
||||
|---|---|---|---|---|
|
||||
| V1 | H4 | Semantic tùy chọn / SKIP khi vắng model | Cao | A |
|
||||
| V2 | H4 | Injection đa ngôn ngữ (VI/JA) né regex Anh | Cao | B |
|
||||
| V3 | H4 | Unicode homoglyph / zero-width / fullwidth | Trung–Cao | A |
|
||||
| V4 | H4 | Encoding smuggling (base64/hex/rot13) | Trung | A |
|
||||
| V5 | H4 | Inject vào chính bộ phân loại/judge | Trung | B |
|
||||
| V6 | H4 | Split/multi-turn injection | Trung | B |
|
||||
| V7 | H4 | Tool-output chưa quét như artifact | Trung | A |
|
||||
| V8 | H5 | Mutation không qua wrapper → không audit | Cao | A |
|
||||
| V9 | H5 | provider-usage.jsonl chưa nằm trong chuỗi ký | Cao | A |
|
||||
| V10 | H5 | Quản lý private key (nội gián/rotation) | Cao | B |
|
||||
| V11 | H5 | TOCTOU (sửa sau verify) | Trung | B |
|
||||
| V12 | H6 | Slow-boil (median trôi, không trip) | Cao | A |
|
||||
| V13 | H6 | Lạm dụng dưới ngưỡng (aggregate) | Trung–Cao | A |
|
||||
| V14 | H6 | Cold-start chưa có baseline | Trung | A |
|
||||
| V15 | H6 | Circuit-breaker né bằng xen kẽ thành công | Trung | B |
|
||||
| V16 | Hệ thống | Tin model backend (poisoning/chiếm Ollama) | Trung | B |
|
||||
| **V17** | H2/H4 | **Tool misuse / over-permission**: gọi tool hợp lệ nhưng hành động vượt quyền (ghi file nhạy cảm, network, lệnh nguy hiểm) | Cao | C |
|
||||
| **V18** | H4/H5 | **Supply-chain**: LLM tự thêm dependency độc/typo-squat/lifecycle script nguy hiểm | Cao | C |
|
||||
| **V19** | H4/H6 | **Data exfiltration** qua model cloud / log / tool call / artifact | Cao | A/C |
|
||||
| **V20** | H5 | **Policy change không qua approval** / rollback policy không rõ (liên kết Plan-04) | Cao | C |
|
||||
| **V21** | H5 | **Audit local bị xóa/rotate mất bằng chứng** (thiếu append-only ngoài runtime) | Trung–Cao | C |
|
||||
| **V22** | H7/Hệ thống | **Runtime escape / resource abuse** của code/test sinh ra (đọc ~/.ssh, network, fork-bomb, ghi ngoài workspace) | Cao | C |
|
||||
| **V23** | H6/H7 | **Thiếu incident workflow** khi gate phát hiện tấn công/spike/tamper (alert, owner, kill-switch) | Trung | A/C |
|
||||
|
||||
> V17–V23 bổ sung theo review: Plan-07 gốc tập trung H4/H5/H6; production **nghiêm túc** cần nhìn rộng hơn → gom vào **TRACK C**.
|
||||
|
||||
---
|
||||
|
||||
# PHẦN II — KẾ HOẠCH NÂNG CẤP (task-level)
|
||||
|
||||
## Nguyên tắc
|
||||
- **Mốc an toàn:** giữ **35/35 + 43/43 PASS** trước & sau mỗi task.
|
||||
- **Fix phải kèm test đối kháng:** mỗi vector Vx có ca red-team chứng minh "trước vá lọt, sau vá chặn".
|
||||
- **Sau cờ bật/tắt:** năng lực mới đưa sau env flag, bật dần.
|
||||
- **Không tự nới lỏng:** mọi thay đổi ngưỡng/chính sách vào audit (H5).
|
||||
|
||||
---
|
||||
|
||||
## TRACK A — Quick wins (rủi ro thấp, làm trước / cho production sớm)
|
||||
|
||||
### A1 — Bịt "semantic SKIP âm thầm" (V1)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| A1.1 | Thêm chế độ `CASAN_SECURITY_STRICT=1`: artifact rủi ro **bắt buộc** semantic; vắng model → **BLOCK (fail-closed)**, không SKIP | ngắt Ollama + strict → rc=2 (không phải 0) | fail-closed thật |
|
||||
| A1.2 | Ghi rõ trong log khi semantic SKIP (không im lặng) | grep log thấy `SEMANTIC_SKIPPED` | có cảnh báo |
|
||||
| A1.3 | Test: prompt injection paraphrase (regex mù) + strict + model on → BLOCK | ca đối kháng PASS | chặn |
|
||||
|
||||
### A2 — Chuẩn hoá Unicode/encoding (V3, V4)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| A2.1 | `normalize_for_match`: thêm NFKC, strip zero-width, fold fullwidth→ascii | homoglyph "ігnore" → khớp `ignore` | chuẩn hoá đúng |
|
||||
| A2.2 | Thêm bước giải base64/hex nghi ngờ rồi quét lại | payload base64 "ignore previous" → BLOCK | chặn encoding |
|
||||
| A2.3 | Test đối kháng cho homoglyph + zero-width + base64 | 3 ca PASS | phủ V3/V4 |
|
||||
|
||||
### A3 — Quét tool-output như artifact (V7)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| A3.1 | Mọi kết quả tool trước khi vào ngữ cảnh model đi qua `artifact-scan` | tool trả payload độc → ARTIFACT_SCAN_BLOCKED | chặn |
|
||||
| A3.2 | Test: tool giả trả injection | ca PASS | phủ V7 |
|
||||
|
||||
### A4 — Toàn vẹn telemetry + mutation qua wrapper (V8, V9)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| A4.1 | Đưa `provider-usage.jsonl` vào chuỗi hash/ký (H5) | sửa 1 dòng token → `AUDIT_HASH_MISMATCH` | telemetry bất biến |
|
||||
| A4.2 | Bổ sung kiểm "mọi mutation qua wrapper": scan artifact ghi ngoài harness | ghi thẳng file → cảnh báo/không audit bị phát hiện | phủ V8 |
|
||||
| A4.3 | Test: giả mạo token để giấu chi phí → bị bắt | ca PASS | phủ V9 |
|
||||
|
||||
### A5 — Trần chi phí tuyệt đối + ngân sách tích luỹ (V12, V13, V14)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| A5.1 | Thêm `cost_absolute_max` (trần cứng mỗi call) cạnh median tương đối | 1 call vượt trần tuyệt đối → exit=2 dù median cao | chặn slow-boil |
|
||||
| A5.2 | Thêm `cost_cumulative_budget` (tổng theo phiên/ngày) | tổng vượt ngân sách → chặn dù mỗi call nhỏ | chặn dưới-ngưỡng |
|
||||
| A5.3 | Cold-start: dùng trần tuyệt đối khi chưa đủ mẫu median | run đầu vẫn có bảo vệ | phủ V14 |
|
||||
| A5.4 | Test: slow-boil (tăng dần) + spray (nhiều call nhỏ) | 2 ca PASS | phủ V12/V13 |
|
||||
|
||||
### A6 — Benign corpus & ngân sách false-positive (chống siết quá)
|
||||
> Theo review: FP trước đây mới nằm ở "rủi ro", nay thành task cứng — gate quá gắt thì team bỏ dùng.
|
||||
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| A6.1 | Dựng **benign corpus** input hợp lệ (VI/JA/EN) | **≥ 30 mẫu / ngôn ngữ** | corpus sẵn |
|
||||
| A6.2 | Mỗi thay đổi H4 báo `block_rate` + `false_positive_rate` | chạy ra 2 chỉ số | có số |
|
||||
| A6.3 | Đặt **FP budget** cụ thể: FP > ngưỡng → không merge | **FP ≤ 3% (strict)** · **adversarial block ≥ 95%** · **vector CRITICAL block = 100%** | cổng FP có số |
|
||||
|
||||
**Cổng ra Track A:** V1,V3,V4,V7,V8,V9,V12,V13,V14 + phần A của V19/V23 có test đối kháng xanh; **benign/FP trong ngân sách**; 35/35 + 43/43 không tụt.
|
||||
|
||||
---
|
||||
|
||||
## TRACK B — Sâu hơn (làm sau / cần thời gian)
|
||||
|
||||
### B1 — Corpus & phát hiện đa ngôn ngữ (V2)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| B1.1 | Bổ sung block-pattern + corpus VI/JA (injection cùng ngữ nghĩa) | câu tiếng Việt "bỏ qua chỉ dẫn trên" → BLOCK | phủ V2 |
|
||||
| B1.2 | Đảm bảo model semantic đủ khả năng đa ngữ (đo recall VI/JA) | recall báo cáo (đo với model) | có số thật |
|
||||
|
||||
### B2 — Chống inject bộ phân loại (V5) & split injection (V6)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| B2.1 | Tách rõ "tiêu chí (tin cậy)" vs "nội dung (không tin)" trong prompt judge (đã có mầm) + gia cố | inject trong artifact không lái được judge | phủ V5 |
|
||||
| B2.2 | Ghép ngữ cảnh nhiều bước để quét payload rải | payload 2 mảnh → BLOCK khi ghép | phủ V6 |
|
||||
|
||||
### B3 — Quản lý khóa & TOCTOU (V10, V11)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| B3.1 | Tách quyền ký (vault/HSM), rotation, private key ngoài repo | key không nằm trong repo; rotate được | giảm rủi ro nội gián |
|
||||
| B3.2 | Verify sát thời điểm dùng (re-verify trước khi commit) | sửa sau verify → bị bắt | phủ V11 |
|
||||
|
||||
### B4 — Tin cậy model backend (V16) & circuit né (V15)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| B4.1 | Pin model digest/checksum; cảnh báo khi model đổi | đổi model bất ngờ → cảnh báo | phủ V16 |
|
||||
| B4.2 | Circuit-breaker theo **tỷ lệ lỗi cửa sổ trượt** (không chỉ liên tiếp) | xen kẽ thành công vẫn trip nếu tỉ lệ cao | phủ V15 |
|
||||
|
||||
**Cổng ra Track B:** V2,V5,V6,V10,V11,V15,V16 có test/biện pháp; tài liệu cập nhật.
|
||||
|
||||
---
|
||||
|
||||
## TRACK C — Production Controls **ngoài** H4/H5/H6 (theo review)
|
||||
|
||||
> Trả lời câu bắt bẻ: *"scan prompt tốt, nhưng agent vẫn có thể thêm dependency độc hoặc ghi file nhạy cảm thì sao?"*. Đây là các kiểm soát production thật sự, ngoài phạm vi 3 harness lõi.
|
||||
|
||||
### C0 — Quy ước chung Track C (priority · outcome · role · severity)
|
||||
|
||||
**Ưu tiên triển khai (chia nhóm):**
|
||||
|
||||
| Nhóm | Gồm | Lý do |
|
||||
|---|---|---|
|
||||
| **C-MVP** | C1 Tool-authz · C2 Supply-chain · C3 Data-exfil · C6 Sandbox | giảm rủi ro production trực tiếp nhất |
|
||||
| **C-Governance** | C4 Policy-approval · C5 External-audit | quan trọng, có thể sau MVP |
|
||||
| **C-Ops** | C7 Incident | nên có sớm, bản tối giản trước |
|
||||
|
||||
> **Track C-MVP (C1+C2+C3+C6) = minimum bar** trước khi cho agent ghi code / chạy test trong môi trường production-like.
|
||||
|
||||
**Chuẩn outcome (thay cho chỉ BLOCK/không):** `ALLOW` · `WARN` · `REQUIRE_APPROVAL` · `BLOCK`.
|
||||
|
||||
| Case | Outcome |
|
||||
|---|---|
|
||||
| Ghi `.env` / private key / `.github/workflows` trái phép | **BLOCK** |
|
||||
| Thêm dependency mới | **REQUIRE_APPROVAL** |
|
||||
| Dependency có CVE critical | **BLOCK** |
|
||||
| Gọi network domain lạ | **BLOCK / REQUIRE_APPROVAL** |
|
||||
| Cost vượt hard budget | **BLOCK** |
|
||||
| Cost tăng nhẹ, trong budget | **WARN** |
|
||||
|
||||
**Reviewer role (cho C4 approval):**
|
||||
|
||||
| Role | Duyệt gì |
|
||||
|---|---|
|
||||
| Security reviewer | H4/H5 policy, corpus, strict-mode |
|
||||
| Tech lead | dependency / codegen policy |
|
||||
| Ops owner | cost budget, kill-switch, provider setting |
|
||||
| Project owner | golden / domain data |
|
||||
|
||||
**Severity mapping (cho C7 incident):**
|
||||
|
||||
| Vector | Severity |
|
||||
|---|---|
|
||||
| Secret gửi lên cloud model (V19) | **CRIT** |
|
||||
| Tool ghi `.env` / private key (V17) | **CRIT** |
|
||||
| Dependency postinstall nguy hiểm (V18) | **HIGH/CRIT** |
|
||||
| Audit chain đứt (V21) | **HIGH** |
|
||||
| Cost vượt budget (V13) | **MED/HIGH** |
|
||||
| Benign FP vượt budget (A6) | **MED** |
|
||||
|
||||
### C1 — Tool authorization / action gating (V17)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| C1.1 | Allowlist **hành động** mỗi tool (ghi file? network? sửa repo? cần approval?) ngoài allowlist tên tool | tool hợp lệ nhưng hành động vượt quyền → BLOCK/approval | có policy hành động |
|
||||
| C1.2 | `adv-tool-overwrite-sensitive-file`: ghi `.env`/private key/CI config | BLOCK | phủ V17 |
|
||||
| C1.3 | `adv-tool-network-exfil`: gửi dữ liệu ra URL lạ | BLOCK | phủ V17 |
|
||||
| C1.4 | `adv-tool-dangerous-command`: `rm -rf`, `curl \| bash`, `chmod 777`, `git push --force` | BLOCK hoặc yêu cầu approval | phủ V17 |
|
||||
|
||||
### C2 — Supply-chain cho code sinh ra (V18)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| C2.1 | Gate: dependency mới trong `package.json`/`requirements.txt`/`pom.xml`/`build.gradle` phải được scan | thêm package lạ → gate yêu cầu duyệt | có gate dep |
|
||||
| C2.2 | Kiểm lockfile diff; chặn typo-squat + lifecycle script (`postinstall`…) | package typo → BLOCK | chặn độc |
|
||||
| C2.3 | Chạy `npm audit`/`pip-audit`/`osv-scanner` + sinh SBOM/diff | có báo cáo CVE + SBOM | có bằng chứng |
|
||||
|
||||
### C3 — Data exfiltration (V19) — phần A + C
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| C3.1 | `adv-secret-to-cloud-model`: input chứa secret → không được gửi lên cloud | BLOCK/mask | phủ V19 (quan trọng khi Plan-03 nối cloud) |
|
||||
| C3.2 | `adv-pii-in-audit-log`: PII vào audit → mask/BLOCK | mask | phủ V19 |
|
||||
| C3.3 | `adv-artifact-leaks-env`: artifact chứa token/env → BLOCK | BLOCK | phủ V19 |
|
||||
|
||||
### C4 — Enterprise policy governance (V20, liên kết Plan-04)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| C4.1 | Policy **versioning + diff**; thay đổi security-sensitive cần reviewer | đổi threshold/corpus/golden/strict-mode phải duyệt | có approval |
|
||||
| C4.2 | Audit **actor identity**: ai approve, lúc nào, lý do | audit ghi đủ danh tính | truy được |
|
||||
| C4.3 | Rollback policy theo version | rollback về bản cũ được | phủ V20 |
|
||||
|
||||
### C5 — External append-only audit (V21)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| C5.1 | Ship audit ra **append-only** ngoài runtime (WORM/S3 Object Lock) | log ngoài hệ đang chạy | khó sửa hơn |
|
||||
| C5.2 | Timestamp từ nguồn tin cậy + retention policy | có dấu thời gian đáng tin | phủ V21 |
|
||||
| C5.3 | Alert khi **audit gap / chain đứt** | tạo gap → cảnh báo | phát hiện mất bằng chứng |
|
||||
|
||||
### C6 — Runtime isolation / sandbox (V22)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| C6.1 | Chạy code/test sinh ra trong **sandbox**: giới hạn file/network/CPU/mem/timeout | vượt giới hạn → bị chặn | có sandbox |
|
||||
| C6.2 | `adv-read-ssh` / `adv-net-egress` / `adv-forkbomb` / `adv-write-outside-workspace` / `adv-huge-file` | tất cả bị chặn | phủ V22 |
|
||||
|
||||
### C7 — Incident response (V23) — phần A + C
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| C7.1 | Gán **severity** (LOW/MED/HIGH/CRIT) cho mỗi loại phát hiện | sự kiện có nhãn severity | có phân loại |
|
||||
| C7.2 | Runbook + owner/on-call + auto-create issue/report | BLOCK → sinh issue/alert | có workflow |
|
||||
| C7.3 | **Kill-switch** theo project/model/provider + postmortem template | bật kill-switch → dừng đúng phạm vi | phủ V23 |
|
||||
|
||||
**Cổng ra Track C:** V17–V23 có test/biện pháp; tool-authz + supply-chain + data-exfil + sandbox có ca đối kháng xanh; có incident runbook + kill-switch.
|
||||
|
||||
---
|
||||
|
||||
## Bộ test đối kháng cần thêm (red-team battery)
|
||||
|
||||
| Test | Vector | Kỳ vọng |
|
||||
|---|---|---|
|
||||
| `adv-homoglyph` | V3 | BLOCK |
|
||||
| `adv-zerowidth` | V3 | BLOCK |
|
||||
| `adv-base64-inject` | V4 | BLOCK |
|
||||
| `adv-multilang-vi` / `-ja` | V2 | BLOCK |
|
||||
| `adv-tool-output-inject` | V7 | ARTIFACT_SCAN_BLOCKED |
|
||||
| `adv-telemetry-tamper` | V9 | AUDIT_HASH_MISMATCH |
|
||||
| `adv-mutation-offwrapper` | V8 | phát hiện/không audit bị bắt |
|
||||
| `adv-cost-slowboil` | V12 | exit=2 (trần tuyệt đối) |
|
||||
| `adv-cost-spray` | V13 | exit=2 (ngân sách) |
|
||||
| `adv-classifier-inject` | V5 | judge không bị lái |
|
||||
| `adv-split-injection` | V6 | BLOCK khi ghép |
|
||||
| `adv-circuit-interleave` | V15 | CIRCUIT_OPEN theo tỷ lệ |
|
||||
| `adv-tool-overwrite-sensitive-file` | V17 | BLOCK |
|
||||
| `adv-tool-network-exfil` | V17 | BLOCK |
|
||||
| `adv-tool-dangerous-command` | V17 | BLOCK/approval |
|
||||
| `adv-dep-typosquat` / `adv-dep-postinstall` | V18 | BLOCK/duyệt |
|
||||
| `adv-secret-to-cloud-model` | V19 | BLOCK/mask |
|
||||
| `adv-pii-in-audit-log` | V19 | mask/BLOCK |
|
||||
| `adv-artifact-leaks-env` | V19 | BLOCK |
|
||||
| `adv-audit-gap` | V21 | cảnh báo chain đứt |
|
||||
| `adv-read-ssh` / `adv-net-egress` / `adv-forkbomb` | V22 | bị chặn (sandbox) |
|
||||
| `benign-vi/ja/en` (FP budget) | A6 | KHÔNG bị chặn (benign PASS) |
|
||||
|
||||
## Ma trận rủi ro khi nâng cấp
|
||||
| Rủi ro | Giảm thiểu |
|
||||
|---|---|
|
||||
| Siết quá gây false-positive chặn cả input hợp lệ | Track A sau cờ; đo tỉ lệ FP trên corpus benign |
|
||||
| Vỡ demo trước thi | Làm trên nhánh; freeze bản demo |
|
||||
| Strict fail-closed chặn khi CI không có model | CI dùng chế độ non-strict; production bật strict |
|
||||
| Regression | 35/35 + 43/43 mỗi task |
|
||||
|
||||
## Tiêu chí HOÀN THÀNH kế hoạch 07
|
||||
- [ ] Track A: 9 vector có test đối kháng xanh; strict fail-closed hoạt động; trần chi phí tuyệt đối + ngân sách; **benign/FP trong ngân sách (A6)**.
|
||||
- [ ] Telemetry nằm trong chuỗi ký; mutation ngoài wrapper bị phát hiện.
|
||||
- [ ] Track B: đa ngôn ngữ + chống inject classifier + quản lý khóa + circuit theo tỷ lệ.
|
||||
- [ ] **Track C: tool-authorization + supply-chain + data-exfil + policy-approval + external-audit + sandbox + incident-response** (V17–V23) có test/biện pháp.
|
||||
- [ ] Thang điểm: Track A → ~3.8–4.0/5 (production nội bộ mức đầu); **Track B+C → production nghiêm túc**, có bằng chứng test.
|
||||
- [ ] Không tụt 35/35 + 43/43 ở bất kỳ cổng nào.
|
||||
|
||||
---
|
||||
|
||||
## Đánh giá 3 mức (theo review) & tuyên bố trung thực
|
||||
|
||||
| Mục tiêu | Trạng thái | Điều kiện |
|
||||
|---|---|---|
|
||||
| **Demo / thi / trình bày** | ✅ đủ mạnh ngay | có before/after + threat-model + test đối kháng + tuyên bố trung thực |
|
||||
| **Production nội bộ mức đầu** | 🟡 sau **Track A** | ~3.8–4.0/5 |
|
||||
| **Production nghiêm túc** | 🔴 cần **Track B + C** | tool-authz, supply-chain, data-exfil, policy-approval, external-audit, sandbox, incident |
|
||||
|
||||
> **Tuyên bố:** H4/H5/H6 hiện **đạt PoC/demo tốt (~3.0/5), chưa đạt production đầy đủ**. Track A vá các điểm lớn (semantic SKIP, telemetry chưa bất biến, thiếu trần chi phí) với rủi ro thấp → ~3.8–4.0. **Track C** (theo review) bổ sung kiểm soát **ngoài 3 harness**: tool-authorization, supply-chain, data-exfiltration, policy-approval, external append-only audit, runtime sandbox, incident-response — đây mới đủ cho production nghiêm túc. Nhận diện được cả những đường lọt ngoài phạm vi lõi = **trưởng thành bảo mật thật**, trung thực hơn tuyên bố "an toàn tuyệt đối".
|
||||
@@ -0,0 +1,157 @@
|
||||
# KẾ HOẠCH 08 — Context Compression / Token Optimizer (nén đầu vào/đầu ra)
|
||||
|
||||
> Năng lực **nén prompt/context để giảm token · latency · cost** — nhưng **không phá governance**. Task-level, chưa thực thi.
|
||||
>
|
||||
> Nhãn: [có] tồn tại thật · [đo] đã kiểm chứng · [mới] cần làm · [chưa tự động] có đo/người quyết.
|
||||
> Phụ thuộc: **01** (đường dẫn sau restructure) · **07** (thứ tự scan/audit an toàn, V19/V5) · **03** (chế độ abstractive dùng model).
|
||||
|
||||
## 1. Bối cảnh & câu hỏi
|
||||
- Ngoài thị trường có thật: **LLMLingua / LongLLMLingua / LLMLingua-2** (Microsoft Research), **PromptFlow** LLMLingua tool, **LangChain ContextualCompressionRetriever** (nén tài liệu RAG trước khi vào LLM).
|
||||
- **Repo hiện tại [đo — grep toàn repo]:** *chưa có* module nén prompt/context. Chỉ có truncation tên nhánh + vài gợi ý "summarize" trong prompt speckit + `max_tokens` trong 1 test. → Đây là **năng lực mới**.
|
||||
|
||||
## 2. Quyết định kiến trúc — **KHÔNG tạo H8**
|
||||
Nén là **capability cắt ngang**, không phải harness thứ 8 (tránh phình kiến trúc 7 harness):
|
||||
|
||||
> **H1.5 Context Compression / Token Optimizer** — cross-cutting capability, **chủ sở hữu H1 (context) + H6 (budget)**, được **verify bởi H3/H4/H5**, dùng **H2** cho tool-output và **H7** cho chunk/retry.
|
||||
|
||||
### 2.1 Map phần → harness
|
||||
| Phần | Harness chính | Vai trò |
|
||||
|---|---|---|
|
||||
| Chọn/rút gọn/dedup/summarize context đầu vào | **H1** | owner nén input |
|
||||
| Nén output "view cho bước sau" (KHÔNG nén artifact cuối) | **H1** (context memory) | giảm token liên-bước |
|
||||
| Nén tool-output dài (log/search/terminal) | **H2 + H1** | H2 kiểm quyền, H1 nén phần liên quan |
|
||||
| Kiểm nén **không mất ý** (faithfulness) | **H3** | gate ngữ nghĩa |
|
||||
| Scan raw **và** bản nén (injection/secret/PII) | **H4** | trước & sau nén |
|
||||
| Audit raw + compressed + ratio + policy | **H5** | bằng chứng bất biến |
|
||||
| Token/cost budget: khi nào nén, ratio, token saved | **H6** | chính sách chi phí |
|
||||
| Chunk/retry/resume khi quá dài / nén fail | **H7** | điều phối |
|
||||
|
||||
**Lớp chính nếu phải chọn một:** **H1 Context**, dưới kiểm soát **H6 budget**, verify bởi **H3/H4/H5**.
|
||||
|
||||
## 3. Nguyên tắc AN TOÀN (bắt buộc — tinh chỉnh so với bản thảo)
|
||||
1. **Scan + audit RAW TRƯỚC khi nén.** Nén trước có thể **xoá dấu injection** hoặc **mất bằng chứng gốc**. Thứ tự: `H4 scan raw → H5 hash raw → H1 nén → H3 faithfulness → H4 scan compressed → H5 audit compressed+ratio → model`.
|
||||
2. **Scan LẠI sau khi nén.** Bản nén có thể *vô tình sinh* hoặc *che* nội dung độc → H4 phải quét cả bản nén.
|
||||
3. **Must-keep invariants (điểm mới quan trọng):** một tập **mệnh đề bắt buộc giữ** — đặc biệt **yêu cầu phủ định / ràng buộc bảo mật** (vd *"Không gửi dữ liệu người dùng lên cloud model"*). Nén **cấm** làm rớt các mệnh đề này; H3 REJECT nếu mất.
|
||||
4. **Không dùng nén để NÉ H4.** Vì luôn scan-after-compress, nén không thể là đường lách bảo mật.
|
||||
5. **Abstractive = một model-call** → chịu **H4** (compressor có thể bị inject), **H6** (tốn token), **H3** (có thể ảo). Do đó abstractive phải gated, không mặc định.
|
||||
6. **Artifact cuối KHÔNG nén.** Code/spec/plan/audit/test-log chính thức giữ **full** để review/rollback/audit; chỉ tạo **compressed view** cho bước kế.
|
||||
|
||||
## 4. Bốn chế độ nén
|
||||
| Mode | Dùng khi | Rủi ro |
|
||||
|---|---|---|
|
||||
| `extractive` | giữ nguyên câu/đoạn quan trọng | thấp nhất — **ưu tiên** |
|
||||
| `structural` | log/spec dài → JSON/table ngắn | thấp — **ưu tiên** |
|
||||
| `semantic-dedup` | loại trùng giữa nhiều artifact/history | trung |
|
||||
| `abstractive` | tóm tắt bằng model, tiết kiệm mạnh | **cao** (mất ý/ảo) → gated |
|
||||
|
||||
> **Khuyến nghị:** bắt đầu **extractive + structural**; **hoãn abstractive** cho requirement/spec (dễ mất chi tiết), chỉ bật sau khi H3 faithfulness + must-keep vững.
|
||||
|
||||
## 5. Luồng chuẩn
|
||||
```
|
||||
1. Nhận raw (input / artifact / tool-output)
|
||||
2. H4 scan raw (injection/secret/PII)
|
||||
3. H5 ghi hash raw (bằng chứng gốc)
|
||||
4. H6 check token budget → nếu KHÔNG vượt: dùng raw, bỏ qua nén
|
||||
5. Nếu vượt budget:
|
||||
a. H1 nén (mode phù hợp) + giữ must-keep invariants
|
||||
b. H3 kiểm faithfulness (không mất ý / không rớt must-keep)
|
||||
c. H4 scan bản nén
|
||||
d. H5 audit: hash raw + hash compressed + ratio + mode + policy
|
||||
6. Đưa bản nén vào model
|
||||
7. Lưu artifact FULL riêng (không mất dữ liệu gốc)
|
||||
```
|
||||
|
||||
## 6. Module layout (đề xuất)
|
||||
Trước restructure (hiện tại):
|
||||
```
|
||||
.specify/scripts/bash/compress-context.sh # H1 owner
|
||||
.specify/scripts/python/context-compress.py # extractive/structural/dedup
|
||||
.specify/scripts/bash/token-budget-check.sh # H6
|
||||
.specify/scripts/python/verify-compression.py # H3 faithfulness + must-keep
|
||||
.specify/level5/compression-policy.yaml # mode, ratio, must-keep, budget
|
||||
```
|
||||
Sau restructure (khớp Plan 01):
|
||||
```
|
||||
src/gates/h1-context/compress-context.sh
|
||||
src/gates/h1-context/context-compress.py
|
||||
src/gates/h6-agentops/token-budget-check.sh
|
||||
src/gates/h3-eval/verify-compression-faithfulness.py
|
||||
config/compression-policy.yaml
|
||||
```
|
||||
|
||||
## 7. Tasks theo track
|
||||
|
||||
### Track 1 — MVP: nén INPUT (extractive + structural)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 1.1 | `compression-policy.yaml`: mode, ratio target, **must-keep patterns**, token budget | policy load được | có policy |
|
||||
| 1.2 | `token-budget-check.sh` (H6): tính token input; vượt → bật nén | input dài → trả `NEED_COMPRESS` | H6 quyết định |
|
||||
| 1.3 | `context-compress.py` extractive + structural (giữ must-keep) | nén ra ≤ budget, giữ must-keep | có bản nén |
|
||||
| 1.4 | Chèn đúng thứ tự an toàn: scan-raw → hash-raw → nén → H3 → scan-compressed → audit | log đúng trình tự | thứ tự an toàn |
|
||||
| 1.5 | `verify-compression-faithfulness.py` (H3): REJECT nếu rớt must-keep | test rớt must-keep → REJECT | H3 gate |
|
||||
| 1.6 | H5 audit raw+compressed+ratio+mode | sửa 1 bên → `AUDIT_HASH_MISMATCH` | bằng chứng |
|
||||
| 1.7 | H4 scan bản nén | payload trong bản nén → BLOCK | scan-after |
|
||||
|
||||
**Cổng ra Track 1:** input dài được nén an toàn, giữ must-keep, có audit ratio; 35/35 + 43/43 không tụt.
|
||||
|
||||
### Track 2 — Nén VIEW liên-bước (artifact full giữ nguyên)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 2.1 | STEP sinh artifact dài → lưu **full** + tạo **compressed view** cho bước sau | full + view cùng tồn tại | không mất gốc |
|
||||
| 2.2 | H3 kiểm view không mất yêu cầu quan trọng | rớt yêu cầu → REJECT | faithfulness |
|
||||
| 2.3 | H5 audit cả full + view | hash cả hai | truy vết |
|
||||
|
||||
### Track 3 — Nén TOOL-OUTPUT (H2 + H1)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 3.1 | Tool trả log/output dài → H4 scan raw → H5 hash → H1 nén phần liên quan → H4 scan nén | tool-output dài → nén qua đúng flow | không đưa thẳng vào model |
|
||||
| 3.2 | Nối với Plan-07 C1/V7 (tool authorization + tool-output scan) | tool-output độc → BLOCK trước nén | an toàn |
|
||||
|
||||
### Track 4 — Abstractive + semantic-dedup (gated, làm sau)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 4.1 | `abstractive` qua model-router (chịu H4/H6) | bật sau cờ; đo token saved | gated |
|
||||
| 4.2 | H3 faithfulness nghiêm cho abstractive (must-keep 100%) | rớt bất kỳ must-keep → REJECT | an toàn ngữ nghĩa |
|
||||
| 4.3 | `semantic-dedup` giữa history/artifact | loại trùng, giữ unique | dedup đúng |
|
||||
|
||||
## 8. Test faithfulness & must-keep (red-team)
|
||||
| Test | Kỳ vọng |
|
||||
|---|---|
|
||||
| `adv-compression-drops-negative-requirement` (rớt *"Không gửi dữ liệu lên cloud"*) | H3 **REJECT** |
|
||||
| `adv-compression-drops-edge-case` (mất điều kiện biên) | H3 REJECT |
|
||||
| `adv-compression-drops-security-instruction` | H3 REJECT |
|
||||
| `adv-compressed-carries-injection` (bản nén chứa payload) | H4 **BLOCK** (scan-after) |
|
||||
| `adv-abstractive-hallucinated-summary` (nghe đúng nhưng sai) | H3 REJECT |
|
||||
| `benign-compression-ratio` (nén hợp lệ) | PASS + đo token saved |
|
||||
|
||||
## 9. Rủi ro
|
||||
| Rủi ro | Giảm thiểu |
|
||||
|---|---|
|
||||
| Nén mất requirement/edge/security | must-keep invariants + H3 faithfulness bắt buộc |
|
||||
| Nén che injection | luôn scan-after-compress (H4) |
|
||||
| Abstractive ảo | gated + H3 nghiêm + ưu tiên extractive |
|
||||
| Mất bằng chứng gốc | scan/hash RAW trước nén; lưu artifact full |
|
||||
| Nén thành đường né H4 | scan cả raw & compressed |
|
||||
| Compressor model bị inject (V5) | H4 quét input của compressor + tách tiêu chí/nội dung |
|
||||
|
||||
## 10. Liên kết Plan-07
|
||||
- **V19 Data exfil:** nén có thể *giúp* (strip secret trước cloud) hoặc *hại* (lộ qua summary) → phải qua C3 data-exfil check.
|
||||
- **V5 classifier/compressor injection:** abstractive compressor là model → gia cố như judge.
|
||||
- **H6 budget (V12/V13):** compression feed `token_saved`, `ratio` vào telemetry; nén là công cụ giữ ngân sách.
|
||||
|
||||
## 11. Tiêu chí HOÀN THÀNH
|
||||
- [ ] Track 1: input nén extractive+structural, giữ must-keep, đúng thứ tự scan/audit, có H3 gate.
|
||||
- [ ] Artifact cuối KHÔNG bị nén; chỉ có compressed view cho bước sau (Track 2).
|
||||
- [ ] Tool-output nén qua H2+H1+H4 (Track 3), không đưa thẳng vào model.
|
||||
- [ ] Abstractive gated sau cờ, H3 must-keep 100% (Track 4).
|
||||
- [ ] Red-team faithfulness (mục 8) xanh; benign đo được `token_saved`/`ratio`.
|
||||
- [ ] 35/35 + 43/43 không tụt.
|
||||
|
||||
## 12. Ghi chú trung thực
|
||||
- Toàn bộ Plan 08 là **[mới]** — repo hiện chưa có module nén ([đo] grep xác nhận).
|
||||
- Không tạo H8; đây là **capability dưới H1/H6**, verify bởi H3/H4/H5.
|
||||
- Giá trị: giảm token/cost **và** giúp CASAN giống một **AI-SDLC platform** thật, nhưng chỉ đáng làm **sau khi Plan-07 core (Track A + C-MVP) vững** — nén thêm bề mặt rủi ro nên phải có governance trước.
|
||||
|
||||
---
|
||||
|
||||
_Liên quan: `CASAN_PLAN_07_PRODUCTION_HARDENING.md` (thứ tự an toàn, V19/V5) · `CASAN_PLAN_01_RESTRUCTURE.md` (đường dẫn) · `CASAN_PLAN_03_CLOUD_PATCH.md` (abstractive dùng model)._
|
||||
@@ -0,0 +1,74 @@
|
||||
# KẾ HOẠCH 09 — CASAN Evidence Pack & Certification
|
||||
|
||||
> Mỗi lần CASAN chạy xong sinh một **gói bằng chứng** đóng gói toàn bộ verdict của H1–H7 + red-team + cost + traceability, trả lời trực tiếp câu: *"Tại sao tôi tin output này?"* bằng **proof pack**, không bằng cảm tính. Task-level, chưa thực thi.
|
||||
>
|
||||
> Nhãn: [có] tồn tại thật · [đo] đã kiểm chứng · [mới] cần làm.
|
||||
> Phụ thuộc: **nhẹ** — chủ yếu *gom* dữ liệu H1–H7 đã có; nối tốt hơn nếu có Plan-01 (đường dẫn) và Plan-10 (traceability).
|
||||
|
||||
## 1. Vì sao đây là plan đáng làm nhất tiếp theo
|
||||
- **Đúng tim CASAN:** "AI không được tin mặc định — mọi quyết định phải có bằng chứng, audit, test, rollback".
|
||||
- **Rẻ:** phần lớn dữ liệu đã tồn tại rời rạc ([có]: audit chain, provider-usage, test report, dashboard, drift report). Plan này **tổng hợp + chuẩn hoá + ký**, không phải xây control mới.
|
||||
- **Ăn điểm trình bày:** giám khảo hỏi "vì sao tin output?" → mở **Evidence Pack**.
|
||||
|
||||
## 2. Cấu trúc gói bằng chứng (mỗi run)
|
||||
```
|
||||
CASAN_EVIDENCE_PACK/<run-id>/
|
||||
run-summary.json # kết quả tổng: verdict, level, pass/fail mỗi harness
|
||||
h1-context-report.json # context checked, token budget, (nén nếu có)
|
||||
h2-tool-audit.json # tool nào gọi, input, outcome
|
||||
h3-eval-scorecard.json # judge/drift/faithfulness + (traceability nếu Plan-10)
|
||||
h4-security-report.json # injection/secret/PII, rc, mode
|
||||
h5-audit-chain-proof.json # hash-chain + chữ ký + verify result
|
||||
h6-cost-telemetry.json # token thật, cost-spike, budget
|
||||
h7-orchestration-report.json # checkpoint/rollback/retry
|
||||
redteam-result.json # ca đối kháng: block_rate
|
||||
benign-fp-report.json # false-positive rate (Plan-07 A6)
|
||||
artifact-manifest.json # hash mọi artifact cuối (full, không nén)
|
||||
decision-log.md # người-đọc-được: đã APPROVE/REJECT/BLOCK gì, vì sao
|
||||
evidence-pack.sig # chữ ký toàn gói (tamper-evident)
|
||||
```
|
||||
|
||||
## 3. Tasks
|
||||
|
||||
### Track 1 — Thu thập & chuẩn hoá (MVP)
|
||||
| Task | Việc | Nguồn [có] | Verify | Done |
|
||||
|---|---|---|---|---|
|
||||
| 1.1 | Định schema `run-summary.json` (verdict/level/harness pass-fail) | tổng hợp | schema hợp lệ | có schema |
|
||||
| 1.2 | Trích H4/H5/H6 report từ log hiện có | security/audit/usage logs | 3 file sinh đúng | có report |
|
||||
| 1.3 | Trích H1/H2/H3/H7 report | trace/tool/eval/rollback logs | 4 file sinh đúng | có report |
|
||||
| 1.4 | `artifact-manifest.json`: hash mọi artifact cuối | artifact dir | hash khớp file | manifest đúng |
|
||||
| 1.5 | `decision-log.md` người-đọc-được | boss log + verdict | liệt kê quyết định + lý do | log rõ |
|
||||
|
||||
### Track 2 — Certification (ký & xác minh)
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 2.1 | Gộp pack → tính hash tổng → **ký** (dùng H5 sign-audit-head) | `evidence-pack.sig` sinh ra | có chữ ký |
|
||||
| 2.2 | `casan verify-pack <run-id>`: kiểm chữ ký + hash từng phần | sửa 1 file → verify FAIL | tamper-evident |
|
||||
| 2.3 | Nhúng verdict red-team + benign/FP (Plan-07) vào pack | 2 file có mặt | đủ bằng chứng bảo mật |
|
||||
| 2.4 | Nối traceability (nếu Plan-10) vào `h3-eval-scorecard.json` | có REQ→code→test | (tuỳ Plan-10) |
|
||||
|
||||
### Track 3 — Trình bày
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 3.1 | `casan pack-report`: render pack → HTML/1 trang tóm tắt | mở xem được | có view đẹp |
|
||||
| 3.2 | Badge "Certified run" khi mọi gate PASS + ký hợp lệ | run pass → badge | có chứng nhận |
|
||||
|
||||
## 4. Rủi ro
|
||||
| Rủi ro | Giảm thiểu |
|
||||
|---|---|
|
||||
| Pack chứa secret/PII | chạy pii-mask/secrets-scan trước khi đóng gói |
|
||||
| Pack bị sửa | ký toàn gói (2.1) + verify (2.2) |
|
||||
| "Certified" nhưng gate SKIP | badge chỉ cấp khi KHÔNG có gate SKIP quan trọng |
|
||||
|
||||
## 5. Tiêu chí HOÀN THÀNH
|
||||
- [ ] Mỗi run sinh Evidence Pack đủ 12 file + chữ ký.
|
||||
- [ ] `casan verify-pack` phát hiện mọi sửa đổi.
|
||||
- [ ] Pack chứa red-team + benign/FP; không lộ secret/PII.
|
||||
- [ ] Có view 1 trang + badge "Certified run" (chỉ khi không SKIP gate quan trọng).
|
||||
- [ ] Không tụt 35/35 + 43/43.
|
||||
|
||||
## 6. Ghi chú trung thực
|
||||
Toàn bộ là **[mới]** (đóng gói), nhưng **dựa trên dữ liệu [có]** — không phóng đại. Badge "Certified" phải trung thực: chỉ cấp khi bằng chứng đầy đủ, không có gate bị bỏ qua âm thầm.
|
||||
|
||||
---
|
||||
_Liên quan: `CASAN_PLAN_10_TRACEABILITY_EVAL.md` (nội dung scorecard) · `CASAN_PLAN_07_PRODUCTION_HARDENING.md` (red-team/FP) · `CASAN_PLAN_01_RESTRUCTURE.md` (CLI/đường dẫn)._
|
||||
@@ -0,0 +1,76 @@
|
||||
# KẾ HOẠCH 12 — CASAN Domain Pack SDK
|
||||
|
||||
> Onboard dự án mới **không copy folder thủ công** — chỉ khai báo một **Domain Pack** (YAML) là CASAN tự hiểu golden/corpus/threshold/quality-rules của domain đó. Chuẩn hoá "harness reusable, domain data tách khỏi core". Task-level, chưa thực thi.
|
||||
>
|
||||
> Nhãn: [có]/[demo]/[mới]. Phụ thuộc: **01** (tách `config`/`apps/<x>/domain`) là điều kiện tiên quyết · **06** (onboard thủ công là bản chạy tay của cái này) · **07/10** (rules tham chiếu).
|
||||
|
||||
## 1. Vì sao đáng làm
|
||||
- Plan-06 onboard dự án 2 **thủ công**; Domain Pack biến việc đó thành **khai báo** → reuse thật ở tầm platform.
|
||||
- Đúng tư tưởng CASAN: **gate (khung) không đổi; domain data khai báo bên ngoài.**
|
||||
|
||||
## 2. Hình dạng Domain Pack
|
||||
```yaml
|
||||
# apps/<project>/domain/domain-pack.yaml
|
||||
domain: okr
|
||||
language: [vi, ja, en]
|
||||
artifact_types: [srs, bd, spec, code, test]
|
||||
golden_runs:
|
||||
path: apps/okr/domain/golden-runs
|
||||
redteam_corpus:
|
||||
path: apps/okr/domain/redteam-corpus
|
||||
benign_corpus:
|
||||
path: apps/okr/domain/benign-corpus
|
||||
thresholds: # đè mặc định package
|
||||
cost_absolute_max: 800
|
||||
fp_budget: 0.03
|
||||
drift_similarity_min: 0.7
|
||||
quality_rules:
|
||||
- requirement_coverage
|
||||
- no_security_regression
|
||||
- no_unapproved_dependency
|
||||
harness_package: fpt-casan-sdd-harness
|
||||
harness_version: 1.0.0
|
||||
```
|
||||
|
||||
## 3. Tasks
|
||||
|
||||
### Track 1 — Loader & schema
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 1.1 | Định schema `domain-pack.yaml` + validate | pack sai field → báo lỗi rõ | schema chốt |
|
||||
| 1.2 | Loader: đọc pack → nạp golden/corpus/threshold/rules vào harness | chạy với pack → dùng đúng data domain | loader chạy |
|
||||
| 1.3 | Cơ chế **override**: pack đè default package; thiếu field → dùng default | field trống → default; có → đè | override đúng |
|
||||
| 1.4 | `casan init-domain <name>`: scaffold pack + thư mục domain rỗng | sinh khung pack | init chạy |
|
||||
|
||||
### Track 2 — Tích hợp & kiểm chứng
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 2.1 | Pipeline đọc domain-pack thay vì hard-code (bỏ `feature-id` cứng) | đổi pack → đổi domain, không sửa gate | tách domain |
|
||||
| 2.2 | `casan register` đọc pack → ghi `project-registry.json` | registry có entry đúng version | đăng ký tự động |
|
||||
| 2.3 | `verify-harness-reuse` với 2 domain pack thật | `HARNESS_REUSE_VALID project_count=2` | reuse thật |
|
||||
| 2.4 | Quality rules trong pack map sang gate (coverage→H3, dependency→C2…) | rule bật/tắt đúng gate | rule-driven |
|
||||
|
||||
### Track 3 — Chất lượng pack
|
||||
| Task | Việc | Verify | Done |
|
||||
|---|---|---|---|
|
||||
| 3.1 | Lint pack: golden/corpus tối thiểu N mẫu; rule hợp lệ | pack thiếu corpus → cảnh báo | lint pack |
|
||||
| 3.2 | `casan doctor <domain>`: kiểm pack sẵn sàng chạy chưa | thiếu gì → liệt kê | health-check |
|
||||
|
||||
## 4. Rủi ro
|
||||
| Rủi ro | Giảm thiểu |
|
||||
|---|---|
|
||||
| Phải sửa gate cho domain mới | nếu xảy ra → nợ kỹ thuật đẩy về Plan-01 (tách chưa đủ) |
|
||||
| Pack sơ sài → gate vô nghĩa | 3.1 lint tối thiểu corpus/golden |
|
||||
| Reuse "giả" (chỉ copy) | cùng `harness_version` + verify script |
|
||||
|
||||
## 5. Tiêu chí HOÀN THÀNH
|
||||
- [ ] Onboard dự án mới = tạo `domain-pack.yaml` + domain data, **không sửa `src/gates`**.
|
||||
- [ ] Override threshold/rule theo pack hoạt động.
|
||||
- [ ] `casan init-domain` / `register` / `doctor` chạy.
|
||||
- [ ] `verify-harness-reuse` = 2 domain pack thật → VALID.
|
||||
|
||||
## 6. Ghi chú trung thực
|
||||
Cần **Plan-01 (tách config/domain) xong trước**; nếu chưa, Domain Pack chỉ là lớp mỏng trên cấu trúc phẳng. Reuse thật chỉ được tuyên bố khi có **≥2 domain pack chạy được**, không tính entry demo.
|
||||
|
||||
---
|
||||
_Liên quan: `CASAN_PLAN_01_RESTRUCTURE.md` · `CASAN_PLAN_06_ONBOARD.md` · `CASAN_PLAN_07/10` (quality rules)._
|
||||
@@ -0,0 +1,63 @@
|
||||
# CASAN — Backlog Phase sau (Vision / Platform, CHƯA làm)
|
||||
|
||||
> Gom các ý tưởng nâng tầm **platform** chưa cần thiết ngay, để lưu và làm ở **phase phát triển sau**. **KHÔNG mở thành plan riêng bây giờ** (tránh phình phạm vi). Mỗi mục sẽ "tốt nghiệp" thành plan riêng khi đủ điều kiện.
|
||||
>
|
||||
> Nhãn: [mở rộng] = nối vào plan đã có · [vision] = hạ tầng lớn, để sau. Nguyên tắc trung thực: đây là **tầm nhìn chưa xây** — khi trình bày phải nói rõ.
|
||||
|
||||
## Điều kiện "tốt nghiệp" thành plan riêng
|
||||
Một mục ở đây chỉ tách ra plan khi: (a) plan phụ thuộc đã xong, và (b) có nhu cầu/dữ liệu thật để làm có ý nghĩa.
|
||||
|
||||
---
|
||||
|
||||
## B1. Human Approval & Decision Workflow [mở rộng — KHÔNG plan riêng]
|
||||
- **Bản chất:** nâng `REQUIRE_APPROVAL` thành workflow thật: phát hiện → tạo approval request → đúng người duyệt → H5 audit actor+reason → H7 resume đúng state.
|
||||
- **Nối vào:** Plan-07 §C0/C4 (outcome + reviewer role) và Plan-04 (duyệt `casan improve`).
|
||||
- **Vì sao chưa tách:** đã có mầm ở 07/04; chỉ cần mở rộng, chưa cần plan mới.
|
||||
- **Tốt nghiệp khi:** 07-C4 + 04 chạy, cần workflow resume-after-approval thật trong tổ chức.
|
||||
|
||||
## B2. H7 Orchestration State Machine [vision]
|
||||
- **Bản chất:** vòng đời run thành state machine: `PENDING→RUNNING_STEP_n→WAITING_APPROVAL→RETRYING→ROLLBACKING→COMPLETED/FAILED_*`; checkpoint/resume/retry/timeout/concurrency/run-lock/kill-switch.
|
||||
- **Vì sao hoãn:** biến harness-script thành **workflow engine** = rewrite hạ tầng lớn; với demo/thi là over-scope. Checkpoint/rollback hiện [có] đã đủ.
|
||||
- **Tốt nghiệp khi:** chạy production đa run song song, cần resume-after-approval + concurrency thật.
|
||||
|
||||
## B3. Model Benchmark, Routing & Escalation [mở rộng — nối 02/03]
|
||||
- **Bản chất:** đo model theo vai (SRS/spec/code), chọn "rẻ nhất vẫn pass H3/H4", escalate khi H3 REJECT ≥ N; `model-router` theo policy.
|
||||
- **Nối vào:** Plan-02 (source-gen escalation) + Plan-03 (đa nhà cung cấp) + `model-fallback.yaml` [có].
|
||||
- **Vì sao chưa tách:** **benchmark cần dữ liệu multi-model thật** — chưa nối model (02/03) thì benchmark rỗng.
|
||||
- **Tốt nghiệp khi:** 02+03 xong, có ≥2 model chạy thật để so số.
|
||||
|
||||
## B4. Governed CASAN Memory [vision]
|
||||
- **Bản chất:** biến lịch sử (lỗi từng gặp, decision đã duyệt, pattern injection đã chặn, cost profile, model perf) thành **memory có governance**: trust_level, domain, expiry, used_by, can_modify.
|
||||
- **Vì sao hoãn:** rủi ro **poisoning** cao; overlap Plan-04; cần audit + quyền duyệt chặt trước.
|
||||
- **Tốt nghiệp khi:** Plan-04 self-improve + Plan-09 evidence vững, cần tái dùng tri thức qua nhiều run/dự án.
|
||||
|
||||
## B5. Safe Auto-remediation [mở rộng — nối 04]
|
||||
- **Bản chất:** gate fail → phân loại root-cause → **tự tạo patch** → chạy test → sinh evidence → `REQUIRE_APPROVAL` (KHÔNG auto-merge).
|
||||
- **Nối vào:** Plan-04 (`casan improve`) như một track cao hơn.
|
||||
- **Vì sao chưa tách:** là bậc nâng của 04, không phải plan độc lập.
|
||||
- **Tốt nghiệp khi:** 04 đề-xuất-cải-tiến chạy ổn, muốn tự sinh patch có kiểm soát.
|
||||
|
||||
## B6. CASAN Platform SLO & KPI Dashboard [một phần mở rộng — nối 18/business-kpi]
|
||||
- **Bản chất:** KPI cho chính CASAN: block_rate, false_positive_rate, false_negative_rate, token_saved, cost_per_run, time_to_approval, rollback_success, incident_count, model_reject_rate, reuse_count.
|
||||
- **Nối vào:** `business-kpi-report.sh` [có] + `generate-agentops-dashboard.py` [có] + Evidence Pack (Plan-09).
|
||||
- **Vì sao chưa tách:** KPI/run trình bày được ngay; KPI **platform đa dự án** cần chạy thật đã (sau 06/12).
|
||||
- **Tốt nghiệp khi:** có ≥2 dự án + nhiều run để KPI có ý nghĩa vận hành.
|
||||
|
||||
---
|
||||
|
||||
## Bảng tổng ưu tiên (khi các plan nền xong)
|
||||
|
||||
| Mục | Loại | Nối/Phụ thuộc | Khi nào làm |
|
||||
|---|---|---|---|
|
||||
| B1 Approval workflow | mở rộng | 07-C4, 04 | sớm (mở rộng nhẹ) |
|
||||
| B3 Model benchmark | mở rộng | 02, 03 | sau khi nối model thật |
|
||||
| B5 Auto-remediation | mở rộng | 04 | sau 04 |
|
||||
| B6 Platform KPI | một phần | 06, 12, 09 | sau khi có nhiều run/dự án |
|
||||
| B2 H7 state machine | vision | 07, 14-scope | production nghiêm túc |
|
||||
| B4 Governed memory | vision | 04, 09 | tầm cao, làm cuối |
|
||||
|
||||
## Tuyên bố trung thực (khi trình bày)
|
||||
> Các năng lực trong file này là **tầm nhìn platform, CHƯA hiện thực**. Phần đã làm & đo được là H4/H5/H6 + production-hardening (Plan-07). Evidence Pack (09), Traceability (10), Domain Pack (12) là bước kế tiếp **đã có kế hoạch**. State machine / governed memory / benchmark là dài hạn.
|
||||
|
||||
---
|
||||
_Liên quan: `CASAN_PLAN_00_INDEX.md` (mục lục) · các plan nền 01–08._
|
||||
@@ -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ý)._
|
||||
@@ -0,0 +1,395 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="vi">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>CASAN Harness — FPT · AI-SDLC có kiểm soát</title>
|
||||
<style>
|
||||
:root{
|
||||
--fpt-orange:#F37021; --fpt-blue:#00AEEF; --fpt-green:#7DBB42;
|
||||
--bg:#070B16; --ink:#eaf0ff; --muted:#93a0c2;
|
||||
--glass:rgba(255,255,255,.045); --glass-brd:rgba(255,255,255,.10);
|
||||
--h4:#ff5a5a; --h5:#3ba7ff; --h6:#5fd08a; --h7:#b98bff;
|
||||
--bad:#ff6b6b; --ok:#5fd08a;
|
||||
}
|
||||
*{box-sizing:border-box;margin:0;padding:0}
|
||||
html,body{height:100%}
|
||||
body{
|
||||
font-family:"Segoe UI",system-ui,-apple-system,"Noto Sans",sans-serif;
|
||||
color:var(--ink); overflow:hidden; background:var(--bg); position:relative;
|
||||
}
|
||||
/* AI-era ambient background */
|
||||
body::before{content:"";position:fixed;inset:0;z-index:0;
|
||||
background:
|
||||
radial-gradient(900px 520px at 8% -8%, rgba(243,112,33,.20), transparent 60%),
|
||||
radial-gradient(900px 520px at 100% 0%, rgba(0,174,239,.18), transparent 55%),
|
||||
radial-gradient(700px 500px at 60% 120%, rgba(125,187,66,.12), transparent 60%);}
|
||||
body::after{content:"";position:fixed;inset:0;z-index:0;opacity:.35;
|
||||
background-image:radial-gradient(rgba(255,255,255,.05) 1px,transparent 1px);
|
||||
background-size:26px 26px;}
|
||||
|
||||
.deck{position:fixed;inset:0;z-index:1}
|
||||
.slide{position:absolute;inset:0;display:none;flex-direction:column;
|
||||
justify-content:center;padding:6vh 7vw;animation:fade .4s ease}
|
||||
.slide.active{display:flex}
|
||||
@keyframes fade{from{opacity:0;transform:translateY(16px)}to{opacity:1;transform:none}}
|
||||
|
||||
.eyebrow{font-family:"Cascadia Code",Consolas,monospace;color:var(--fpt-orange);
|
||||
font-weight:700;letter-spacing:3px;text-transform:uppercase;
|
||||
font-size:clamp(11px,1.2vw,15px);margin-bottom:1em;display:flex;align-items:center;gap:.6em}
|
||||
.eyebrow::before{content:"";width:26px;height:2px;background:var(--fpt-orange)}
|
||||
h1{font-size:clamp(30px,5.2vw,64px);line-height:1.06;letter-spacing:-1px;font-weight:800}
|
||||
h2{font-size:clamp(23px,3.6vw,44px);line-height:1.12;font-weight:800;margin-bottom:.4em}
|
||||
.grad{background:linear-gradient(100deg,var(--fpt-orange),#ffb46b 40%,var(--fpt-blue));
|
||||
-webkit-background-clip:text;background-clip:text;color:transparent}
|
||||
.sub{color:var(--muted);font-size:clamp(15px,1.9vw,23px);margin-top:.8em;line-height:1.55}
|
||||
ul{margin-top:1.1em;list-style:none;display:grid;gap:.7em}
|
||||
li{font-size:clamp(15px,1.95vw,24px);line-height:1.42;padding-left:1.7em;position:relative}
|
||||
li::before{content:"›";position:absolute;left:0;color:var(--fpt-orange);font-weight:800}
|
||||
b,strong{color:#fff}
|
||||
code{font-family:"Cascadia Code",Consolas,monospace;background:rgba(255,255,255,.06);
|
||||
padding:.05em .4em;border-radius:6px;font-size:.9em;color:#ffd8b8}
|
||||
.tag{display:inline-block;font-family:monospace;font-size:.6em;font-weight:800;padding:.2em .7em;
|
||||
border-radius:999px;vertical-align:middle;letter-spacing:.5px}
|
||||
.tag.real{background:rgba(125,187,66,.18);color:#b6f08a;border:1px solid #7dbb4266}
|
||||
.tag.warn{background:rgba(243,112,33,.16);color:#ffc07a;border:1px solid #f3702166}
|
||||
|
||||
/* glass card */
|
||||
.cards{display:grid;gap:1rem;margin-top:1.3em}
|
||||
.c4{grid-template-columns:repeat(4,1fr)} .c3{grid-template-columns:repeat(3,1fr)}
|
||||
.c2{grid-template-columns:repeat(2,1fr)}
|
||||
.card{background:var(--glass);border:1px solid var(--glass-brd);border-radius:18px;
|
||||
padding:1.1em 1.15em;backdrop-filter:blur(10px);box-shadow:0 10px 40px rgba(0,0,0,.3)}
|
||||
.card h3{font-size:clamp(14px,1.7vw,21px);margin-bottom:.4em;display:flex;align-items:center;gap:.4em}
|
||||
.card p{color:var(--muted);font-size:clamp(12px,1.35vw,16px);line-height:1.42}
|
||||
.card.on4{border-top:3px solid var(--h4)} .card.on5{border-top:3px solid var(--h5)}
|
||||
.card.on6{border-top:3px solid var(--h6)} .card.on7{border-top:3px solid var(--h7)}
|
||||
|
||||
/* before/after */
|
||||
.ba{display:grid;grid-template-columns:1fr auto 1fr;gap:1.1rem;align-items:stretch;margin-top:1.2em}
|
||||
.col{border-radius:18px;padding:1.15em 1.25em;backdrop-filter:blur(8px)}
|
||||
.before{background:rgba(255,90,90,.07);border:1px solid rgba(255,90,90,.28)}
|
||||
.after{background:rgba(125,187,66,.08);border:1px solid rgba(125,187,66,.32)}
|
||||
.col .lbl{font-family:monospace;font-weight:800;letter-spacing:1px;font-size:.8em;margin-bottom:.6em}
|
||||
.before .lbl{color:var(--bad)} .after .lbl{color:var(--ok)}
|
||||
.col ul{margin-top:.2em;gap:.5em} .col li{font-size:clamp(13px,1.55vw,20px);padding-left:1.4em}
|
||||
.before li::before{content:"✕";color:var(--bad)} .after li::before{content:"✓";color:var(--ok)}
|
||||
.mid{display:flex;align-items:center;font-size:clamp(22px,3vw,40px);color:var(--fpt-orange)}
|
||||
|
||||
table{width:100%;border-collapse:collapse;margin-top:1.2em;font-size:clamp(13px,1.65vw,21px)}
|
||||
th,td{text-align:left;padding:.52em .7em;border-bottom:1px solid var(--glass-brd)}
|
||||
th{color:var(--fpt-blue);font-family:monospace;font-size:.82em;text-transform:uppercase;letter-spacing:1px}
|
||||
td.big{font-weight:800;color:#fff} td.was{color:var(--muted)}
|
||||
|
||||
.flow{display:flex;align-items:center;gap:.6rem;margin-top:1.4em;flex-wrap:wrap}
|
||||
.node{background:var(--glass);border:1px solid var(--glass-brd);border-radius:14px;
|
||||
padding:.75em 1.05em;font-weight:700;font-size:clamp(13px,1.55vw,20px);text-align:center;backdrop-filter:blur(8px)}
|
||||
.node.in{border-color:rgba(0,174,239,.5)} .node.out{border-color:rgba(125,187,66,.5);background:rgba(125,187,66,.08)}
|
||||
.arrow{color:var(--fpt-orange);font-size:clamp(18px,2.3vw,30px)}
|
||||
.chips{display:flex;gap:.5rem;margin-top:1.1em;flex-wrap:wrap}
|
||||
.chip{padding:.5em .9em;border-radius:11px;font-weight:700;font-size:clamp(11px,1.3vw,17px);
|
||||
border:1px solid var(--glass-brd);background:var(--glass)}
|
||||
.chip.s{border-color:var(--h4);color:#ffb4b4} .chip.g{border-color:var(--h5);color:#a9d5ff}
|
||||
.chip.o{border-color:var(--h6);color:#a6f0c0} .chip.r{border-color:var(--h7);color:#dcc0ff}
|
||||
.chip.y{border-color:var(--fpt-orange);color:#ffc99b}
|
||||
|
||||
.term{margin-top:1.2em;background:rgba(3,5,12,.7);border:1px solid var(--glass-brd);border-radius:14px;
|
||||
padding:1em 1.25em;font-family:"Cascadia Code",Consolas,monospace;
|
||||
font-size:clamp(12px,1.45vw,19px);line-height:1.75;backdrop-filter:blur(8px)}
|
||||
.term .dim{color:#5a678c} .term .ok{color:#8ff0b0;font-weight:700} .term .no{color:#ff9a9a;font-weight:700}
|
||||
|
||||
.quote{font-size:clamp(21px,3.3vw,44px);line-height:1.22;font-weight:800}
|
||||
.quote .hl{color:transparent;background:linear-gradient(100deg,var(--fpt-orange),var(--fpt-blue));
|
||||
-webkit-background-clip:text;background-clip:text}
|
||||
|
||||
/* score meters */
|
||||
.meters{display:grid;grid-template-columns:1fr 1fr;gap:.7em 1.6em;margin-top:1.2em;max-width:1050px}
|
||||
.meter{display:grid;grid-template-columns:180px 1fr 44px;align-items:center;gap:.8em}
|
||||
.meter .m-l{font-size:clamp(12px,1.4vw,18px);color:var(--muted)}
|
||||
.track{height:10px;border-radius:999px;background:rgba(255,255,255,.07);overflow:hidden}
|
||||
.fill{height:100%;border-radius:999px;background:linear-gradient(90deg,var(--fpt-orange),var(--fpt-blue))}
|
||||
.meter .m-v{font-weight:800;text-align:right;font-family:monospace}
|
||||
|
||||
/* chrome */
|
||||
.bar{position:fixed;top:0;left:0;height:4px;z-index:9;transition:width .35s;
|
||||
background:linear-gradient(90deg,var(--fpt-orange),var(--fpt-blue),var(--fpt-green))}
|
||||
.brand{position:fixed;top:20px;right:26px;z-index:9;display:flex;align-items:center;gap:10px}
|
||||
.brand .fpt{font-weight:900;font-size:20px;letter-spacing:1px;
|
||||
background:linear-gradient(100deg,var(--fpt-orange),var(--fpt-blue),var(--fpt-green));
|
||||
-webkit-background-clip:text;background-clip:text;color:transparent}
|
||||
.brand .ai{font-family:monospace;font-size:11px;color:var(--muted);border:1px solid var(--glass-brd);
|
||||
padding:2px 8px;border-radius:999px}
|
||||
.foot{position:fixed;bottom:16px;left:0;right:0;display:flex;justify-content:space-between;
|
||||
align-items:center;padding:0 26px;color:var(--muted);font-size:13px;z-index:9;font-family:monospace}
|
||||
.dots{display:flex;gap:6px} .dot{width:8px;height:8px;border-radius:50%;background:#2a3358;cursor:pointer;transition:.2s}
|
||||
.dot.on{background:var(--fpt-orange);transform:scale(1.3)}
|
||||
.hint{position:fixed;bottom:14px;left:50%;transform:translateX(-50%);color:#48557d;font-size:11px;z-index:9;font-family:monospace}
|
||||
.kbd{border:1px solid var(--glass-brd);border-radius:6px;padding:1px 7px}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="bar" id="bar"></div>
|
||||
<div class="brand"><span class="fpt">FPT</span><span class="ai">AI-SDLC · CASAN</span></div>
|
||||
<div class="deck" id="deck">
|
||||
|
||||
<!-- 1 TITLE -->
|
||||
<section class="slide active">
|
||||
<div class="eyebrow">FPT · CASAN Harness · Thời đại AI</div>
|
||||
<h1>Cải thiện <span class="grad">H4 · H5 · H6</span><br/>cho AI-SDLC <span class="grad">có kiểm soát</span></h1>
|
||||
<p class="sub">Chúng tôi không hỏi "AI viết code nhanh cỡ nào" — mà hỏi:
|
||||
<b>khi AI làm bậy, ai chặn? và làm sao chứng minh đã chặn?</b></p>
|
||||
<p class="sub">Chạy có bằng chứng · Chặn thật · Trung thực về giới hạn · Hướng đóng gói production.</p>
|
||||
</section>
|
||||
|
||||
<!-- 2 GOAL / 3 AXES -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Mục tiêu trình bày</div>
|
||||
<h2>Ba trục chúng tôi chứng minh</h2>
|
||||
<div class="cards c3">
|
||||
<div class="card on4"><h3>🔴 1 · Cải thiện H4·H5·H6</h3><p>Before → After cho từng harness, kèm <b>bằng chứng đo thật</b> (exit-code, số test).</p></div>
|
||||
<div class="card on5"><h3>🧠 2 · Hiểu hệ thống sâu</h3><p>Truy đến <b>gốc lỗi</b> (fail-open), threat-model đường lọt, nguyên tắc "harness thấp nhất quyết định trần".</p></div>
|
||||
<div class="card on6"><h3>📦 3 · Hướng production</h3><p>Thang điểm sẵn sàng, <b>đóng gói package</b> tái dùng, lộ trình hardening có test.</p></div>
|
||||
</div>
|
||||
<p class="sub">Mọi con số gắn nhãn <span class="tag real">ĐO THẬT</span> — giám khảo chạy lại ra đúng.</p>
|
||||
</section>
|
||||
|
||||
<!-- 3 DEPTH: root cause -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Hiểu sâu · Truy gốc lỗi</div>
|
||||
<h2>Điểm mù chí mạng: <span style="color:var(--h4)">fail-open</span></h2>
|
||||
<ul>
|
||||
<li>Bản trước dùng <code>grep "[:space:]"</code> — cú pháp <b>sai</b> trên grep hiện đại → thoát <b style="color:var(--bad)">rc=4</b>.</li>
|
||||
<li>Hệ quả: bộ lọc "tưởng đang chặn" nhưng thực chất <b style="color:var(--bad)">chặn = 0</b> — lọt cả injection kinh điển.</li>
|
||||
<li>Bài học: <b>"có prompt-filter.yaml" ≠ "chặn được thật"</b>. Chỉ tính điểm khi chặn được tấn công thật.</li>
|
||||
</ul>
|
||||
<p class="sub">Phát hiện được lỗi fail-open này = hiểu hệ thống ở tầng thực thi, không dừng ở tài liệu.</p>
|
||||
</section>
|
||||
|
||||
<!-- 4 OVERVIEW -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Kiến trúc CASAN</div>
|
||||
<h2>Mọi lời gọi agent đi xuyên <span class="grad">7 harness</span></h2>
|
||||
<div class="flow">
|
||||
<div class="node in">📥 INPUT</div><div class="arrow">→</div>
|
||||
<div class="node">🧠 Boss · 13 bước AI-SDLC</div><div class="arrow">→</div>
|
||||
<div class="node out">📤 code + BẰNG CHỨNG</div>
|
||||
</div>
|
||||
<div class="chips">
|
||||
<span class="chip y">H1 Context</span><span class="chip y">H2 Tool</span><span class="chip y">H3 Eval</span>
|
||||
<span class="chip s">H4 Security</span><span class="chip g">H5 Governance</span>
|
||||
<span class="chip o">H6 AgentOps</span><span class="chip r">H7 Orchestration</span>
|
||||
</div>
|
||||
<p class="sub">Gate trả <b>APPROVE / REJECT / BLOCK</b> — kiểm soát bọc mọi bước, không đứng bên lề.</p>
|
||||
</section>
|
||||
|
||||
<!-- 5 H4 -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Trục 1 · 🔴 H4 Security</div>
|
||||
<h2>Từ fail-open → <span class="grad">chặn thật đa lớp</span></h2>
|
||||
<div class="ba">
|
||||
<div class="col before"><div class="lbl">BEFORE</div><ul>
|
||||
<li>grep sai → fail-open rc=4, chặn = 0</li>
|
||||
<li>chỉ regex tiếng Anh</li>
|
||||
<li>mù với câu diễn đạt mới</li></ul></div>
|
||||
<div class="mid">→</div>
|
||||
<div class="col after"><div class="lbl">AFTER</div><ul>
|
||||
<li>BLOCK <b>rc=2</b> + normalize leetspeak</li>
|
||||
<li>+ <b>semantic model-as-judge</b></li>
|
||||
<li>artifact-scan (indirect) · secret/PII block</li></ul></div>
|
||||
</div>
|
||||
<p class="sub"><span class="tag real">ĐO THẬT</span> Adversarial <b>43/43 PASS</b> · injection paraphrase → <code>rc=2</code>.</p>
|
||||
</section>
|
||||
|
||||
<!-- 6 H5 -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Trục 1 · 🔵 H5 Governance</div>
|
||||
<h2>Từ log sửa được → <span class="grad">audit bất biến, ký số</span></h2>
|
||||
<div class="ba">
|
||||
<div class="col before"><div class="lbl">BEFORE</div><ul>
|
||||
<li>log thường, sửa được</li>
|
||||
<li>không chống giả mạo</li>
|
||||
<li>không truy vết ký số</li></ul></div>
|
||||
<div class="mid">→</div>
|
||||
<div class="col after"><div class="lbl">AFTER</div><ul>
|
||||
<li><b>hash-chain + ký RSA</b> HEAD</li>
|
||||
<li>sửa 1 ký tự → <b>AUDIT_HASH_MISMATCH</b></li>
|
||||
<li>secrets-scan · quét no-bypass</li></ul></div>
|
||||
</div>
|
||||
<p class="sub"><span class="tag real">ĐO THẬT</span> tamper 1 ký tự → <code>AUDIT_HASH_MISMATCH line=1</code> · chain hợp lệ → <code>AUDIT_CHAIN_VALID</code>.</p>
|
||||
</section>
|
||||
|
||||
<!-- 7 H6 -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Trục 1 · 🟢 H6 AgentOps</div>
|
||||
<h2>Từ mù chi phí → <span class="grad">giám sát & chặn spike</span></h2>
|
||||
<div class="ba">
|
||||
<div class="col before"><div class="lbl">BEFORE</div><ul>
|
||||
<li>không đo chi phí</li>
|
||||
<li>không telemetry token</li>
|
||||
<li>không phát hiện bất thường</li></ul></div>
|
||||
<div class="mid">→</div>
|
||||
<div class="col after"><div class="lbl">AFTER</div><ul>
|
||||
<li><b>cost-spike 3× → exit=2</b></li>
|
||||
<li>telemetry token thật · drift-detect</li>
|
||||
<li>circuit-breaker chặn đốt tiền</li></ul></div>
|
||||
</div>
|
||||
<p class="sub"><span class="tag real">ĐO THẬT</span> spike → <code>COST_SPIKE_DETECTED exit=2</code> · bình thường → <code>exit=0</code>.</p>
|
||||
</section>
|
||||
|
||||
<!-- 8 EVIDENCE -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Bằng chứng tổng hợp <span class="tag real">ĐO THẬT</span></div>
|
||||
<h2>Kiểm chứng ngay trên máy — không nói suông</h2>
|
||||
<div class="term">
|
||||
<div><span class="dim">$</span> run-casan4-harness-tests.sh → <span class="ok">35/35 PASS</span></div>
|
||||
<div><span class="dim">$</span> adversarial-harness-tests.sh → <span class="ok">43/43 PASS</span></div>
|
||||
<div><span class="dim">$</span> security-check (injection) → <span class="no">BLOCKED rc=2</span></div>
|
||||
<div><span class="dim">$</span> tamper audit → <span class="no">AUDIT_HASH_MISMATCH line=1</span></div>
|
||||
<div><span class="dim">$</span> cost 3× → <span class="no">COST_SPIKE_DETECTED exit=2</span></div>
|
||||
</div>
|
||||
<p class="sub">👉 Chiếu terminal thật 1–2 dòng này khi trình bày để tạo sức nặng.</p>
|
||||
</section>
|
||||
|
||||
<!-- 9 DEPTH: threat model + principle -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Trục 2 · Hiểu sâu</div>
|
||||
<h2>Chúng tôi biết <span class="grad">còn lọt ở đâu</span></h2>
|
||||
<div class="cards c3">
|
||||
<div class="card on4"><h3>🔴 H4</h3><p>Semantic SKIP khi vắng model · injection đa ngôn ngữ · homoglyph/encoding.</p></div>
|
||||
<div class="card on5"><h3>🔵 H5</h3><p>Telemetry chưa vào chuỗi ký · mutation ngoài wrapper · quản lý khóa.</p></div>
|
||||
<div class="card on6"><h3>🟢 H6</h3><p>Slow-boil (median trôi) · lạm dụng dưới ngưỡng · cold-start.</p></div>
|
||||
</div>
|
||||
<p class="sub">Chuẩn tham chiếu: OWASP LLM/Agentic · CSA MAESTRO · MITRE ATLAS.
|
||||
Nguyên tắc: <b>"harness thấp nhất quyết định trần"</b> — cái yếu nhất quyết định cả pipeline.</p>
|
||||
</section>
|
||||
|
||||
<!-- 10 MODEL -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Triết lý model · local-first</div>
|
||||
<h2 class="quote">"Model sinh <span class="hl">bản nháp</span>; harness quyết định bản nháp có được <span class="hl">tin</span> hay không."</h2>
|
||||
<ul>
|
||||
<li>Local (Ollama) đủ cho harness — <b>không API key, offline, dữ liệu không rời máy</b> (Sovereign AI).</li>
|
||||
<li>Đổi model <b>không đổi</b> mức an toàn — harness giữ đảm bảo, bất kể model.</li>
|
||||
<li>H6 cost-spike chặn đốt token → điểm cộng là <b>kiểm soát chi phí</b>, không phải "model xịn nhất".</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<!-- 11 PRODUCTION READINESS -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Trục 3 · Hướng production</div>
|
||||
<h2>Thang sẵn sàng: <span class="grad">~3.0/5</span> → mục tiêu ≥ 4.0</h2>
|
||||
<div class="meters">
|
||||
<div class="meter"><div class="m-l">Phủ phát hiện</div><div class="track"><div class="fill" style="width:60%"></div></div><div class="m-v">3</div></div>
|
||||
<div class="meter"><div class="m-l">Fail-safe</div><div class="track"><div class="fill" style="width:80%"></div></div><div class="m-v">4</div></div>
|
||||
<div class="meter"><div class="m-l">Chống giả mạo</div><div class="track"><div class="fill" style="width:60%"></div></div><div class="m-v">3</div></div>
|
||||
<div class="meter"><div class="m-l">Kiểm soát chi phí</div><div class="track"><div class="fill" style="width:60%"></div></div><div class="m-v">3</div></div>
|
||||
<div class="meter"><div class="m-l">Đa domain / i18n</div><div class="track"><div class="fill" style="width:40%"></div></div><div class="m-v">2</div></div>
|
||||
<div class="meter"><div class="m-l">Phủ kiểm thử</div><div class="track"><div class="fill" style="width:80%"></div></div><div class="m-v">4</div></div>
|
||||
</div>
|
||||
<p class="sub"><span class="tag warn">TRUNG THỰC</span> Demo ✅ đủ mạnh · Track A → <b>~3.8–4.0</b> (production nội bộ) · <b>Track B+C</b> → production nghiêm túc. Mỗi vá kèm test đối kháng.</p>
|
||||
</section>
|
||||
|
||||
<!-- 11b TRACK C-1 -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Trục 3 · Track C-MVP · Kín đòn phản biện</div>
|
||||
<h2>Kiểm soát <span class="grad">ngoài</span> H4·H5·H6 — nhóm ưu tiên</h2>
|
||||
<p class="sub">"Scan prompt tốt — nhưng agent vẫn có thể <b>thêm dependency độc</b> / <b>ghi file nhạy cảm</b>?" → đây là <b>minimum bar</b> trước khi cho agent ghi code trong môi trường production-like.</p>
|
||||
<div class="cards c4">
|
||||
<div class="card on4"><h3>🔐 Tool authorization</h3><p>Gate cả <b>hành động</b> (ghi file/network/lệnh nguy hiểm), không chỉ tên tool.</p></div>
|
||||
<div class="card on6"><h3>📦 Supply-chain</h3><p>Scan dependency mới · chặn typo-squat/postinstall · SBOM + CVE.</p></div>
|
||||
<div class="card on4"><h3>🕵️ Data exfiltration</h3><p>Chặn secret/PII rò qua cloud model · log · artifact.</p></div>
|
||||
<div class="card on7"><h3>🧪 Runtime sandbox</h3><p>Cô lập code/test sinh ra: file/network/CPU/mem/timeout.</p></div>
|
||||
</div>
|
||||
<p class="sub">Outcome chuẩn hoá: <code>ALLOW · WARN · REQUIRE_APPROVAL · BLOCK</code> (thêm dependency → duyệt; ghi <code>.env</code> → chặn).</p>
|
||||
</section>
|
||||
|
||||
<!-- 11c TRACK C-2 -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Trục 3 · Track C · Governance & Ops</div>
|
||||
<h2>Quản trị & vận hành <span class="grad">mức enterprise</span></h2>
|
||||
<div class="cards c4">
|
||||
<div class="card on5"><h3>📝 Policy approval</h3><p>Versioning + reviewer bắt buộc · audit actor · rollback policy.</p></div>
|
||||
<div class="card on5"><h3>🗄️ External audit</h3><p>Append-only (WORM) ngoài runtime · alert khi chain đứt.</p></div>
|
||||
<div class="card on6"><h3>🚨 Incident response</h3><p>Severity CRIT→MED · owner · kill-switch theo project/model.</p></div>
|
||||
<div class="card"><h3>✓ Benign / FP</h3><p>≥30 mẫu/ngôn ngữ · FP ≤ 3% · adversarial block ≥ 95%.</p></div>
|
||||
</div>
|
||||
<p class="sub">Reviewer role: Security · Tech lead · Ops owner · Project owner — mỗi loại policy có người duyệt riêng.</p>
|
||||
</section>
|
||||
|
||||
<!-- 12 PACKAGING -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Trục 3 · Đóng gói & tái sử dụng</div>
|
||||
<h2>Giá trị ở <span class="grad">harness tái dùng</span>, không ở app OKR</h2>
|
||||
<ul>
|
||||
<li>Đóng gói <b>package có version</b> — <code>fpt-casan-sdd-harness</code>.</li>
|
||||
<li>Registry + <code>verify-harness-reuse</code> → nhiều dự án dùng chung.</li>
|
||||
<li>Áp dự án mới = cắm golden/corpus/input + đăng ký, <b>không sửa gate</b>.</li>
|
||||
<li>App OKR chỉ là <b>testbed cố định</b> để so sánh công bằng.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
<!-- 13 ROADMAP -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Lộ trình · kế hoạch task-level</div>
|
||||
<h2>Tư duy sản phẩm, không chỉ demo</h2>
|
||||
<div class="cards c4">
|
||||
<div class="card"><h3>01</h3><p>Tái cấu trúc thư mục</p></div>
|
||||
<div class="card"><h3>02</h3><p>Nối LLM sinh source</p></div>
|
||||
<div class="card"><h3>03</h3><p>Patch cloud (bỏ stub)</p></div>
|
||||
<div class="card"><h3>04</h3><p>Khép vòng tự cải tiến</p></div>
|
||||
<div class="card"><h3>05</h3><p>CI/CD + phát hành</p></div>
|
||||
<div class="card"><h3>06</h3><p>Onboard dự án 2</p></div>
|
||||
<div class="card on4"><h3>07</h3><p>Hardening H4·H5·H6</p></div>
|
||||
<div class="card"><h3>✓</h3><p>Verify từng task</p></div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<!-- 14 CLOSE -->
|
||||
<section class="slide">
|
||||
<div class="eyebrow">Chốt</div>
|
||||
<h1 class="quote">Không phải AI <span class="hl">xịn nhất</span> —<br/>mà AI <span class="hl">có kiểm soát, có bằng chứng, tái dùng được</span>.</h1>
|
||||
<ul>
|
||||
<li>H4·H5·H6 cải thiện có <b>before/after + exit-code đo thật</b>.</li>
|
||||
<li>Hiểu hệ thống tới gốc lỗi + threat-model đường lọt.</li>
|
||||
<li>Hướng production: đóng gói package + lộ trình hardening có test.</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
</div>
|
||||
|
||||
<div class="foot">
|
||||
<div id="who">FPT · CASAN Harness</div>
|
||||
<div class="dots" id="dots"></div>
|
||||
<div id="num">1 / 16</div>
|
||||
</div>
|
||||
<div class="hint"><span class="kbd">←</span> <span class="kbd">→</span> / <span class="kbd">Space</span> chuyển slide · <span class="kbd">F</span> toàn màn hình</div>
|
||||
|
||||
<script>
|
||||
const slides=[...document.querySelectorAll('.slide')];
|
||||
const dotsBox=document.getElementById('dots');
|
||||
const bar=document.getElementById('bar'),num=document.getElementById('num');
|
||||
let i=0;
|
||||
slides.forEach((_,k)=>{const d=document.createElement('div');d.className='dot'+(k===0?' on':'');
|
||||
d.onclick=()=>go(k);dotsBox.appendChild(d);});
|
||||
const dots=[...document.querySelectorAll('.dot')];
|
||||
function go(n){
|
||||
i=Math.max(0,Math.min(slides.length-1,n));
|
||||
slides.forEach((s,k)=>s.classList.toggle('active',k===i));
|
||||
dots.forEach((d,k)=>d.classList.toggle('on',k===i));
|
||||
bar.style.width=((i+1)/slides.length*100)+'%';
|
||||
num.textContent=(i+1)+' / '+slides.length;
|
||||
}
|
||||
document.addEventListener('keydown',e=>{
|
||||
if(['ArrowRight','ArrowDown',' ','PageDown'].includes(e.key)){e.preventDefault();go(i+1);}
|
||||
else if(['ArrowLeft','ArrowUp','PageUp'].includes(e.key)){e.preventDefault();go(i-1);}
|
||||
else if(e.key==='Home')go(0); else if(e.key==='End')go(slides.length-1);
|
||||
else if(e.key.toLowerCase()==='f'){if(!document.fullscreenElement)document.documentElement.requestFullscreen();else document.exitFullscreen();}
|
||||
});
|
||||
let sx=0;
|
||||
document.addEventListener('touchstart',e=>sx=e.touches[0].clientX,{passive:true});
|
||||
document.addEventListener('touchend',e=>{const dx=e.changedTouches[0].clientX-sx;
|
||||
if(Math.abs(dx)>50)go(i+(dx<0?1:-1));},{passive:true});
|
||||
go(0);
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,274 @@
|
||||
# CASAN — Bộ Q&A cho Team (hiểu sâu hệ thống + before/after tối ưu)
|
||||
|
||||
> **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 .specify/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** (`.specify/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ụ:
|
||||
```
|
||||
/okr.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`._
|
||||
Reference in New Issue
Block a user