# War Room — Kiến trúc, Logic & Lý tưởng > Tài liệu tổng hợp toàn bộ hệ thống **War Room**: một "startup org" AI (C-suite + đội ngũ) > chạy dưới dạng multi-agent, **audit thẳng thắn** một sản phẩm/codebase và **hiện thực hoá** > kết quả thành một **hệ thống ticket git-native** (Jira nhẹ) với **verdict launch-readiness, > P0 blockers, critical path, Sprint 0** — rồi thực thi các ticket an toàn, giá trị cao. --- ## 0. Một câu Gõ "war room" → dựng **CEO/CTO/CPO/CMO/COO + team** dưới dạng sub-agent → mỗi lead audit domain của mình song song → đội chuyên môn nở các ticket P0/P1 thành spec làm được → một Chief-of-Staff gộp thành **1 board thống nhất** → materialize ra `board.json` → render `BOARD.md` → commit → thực thi. --- ## 1. Lý tưởng / Triết lý (7 nguyên tắc) 1. **Trung thực tàn nhẫn (brutal honesty).** Audit phải phơi bày phần **giả/mô phỏng, lỗ hổng bảo mật, bẫy pháp lý** — kể cả khi trái ý founder. *Audit nịnh = vô dụng.* Đây là nguyên tắc bất khả xâm phạm. 2. **Grounding là đòn bẩy chất lượng số 1.** Một `CONTEXT` bám sát sản phẩm thật (đã có gì, gap, stack, repo path, ràng buộc) biến agent từ "nói chung chung" thành "tìm ra lỗi thật". 3. **Board là nguồn sự thật sống.** Mọi trạng thái nằm ở `board.json` (versioned trong git), `BOARD.md` chỉ là bản render. Sống xuyên session — đóng máy mở lại vẫn resume được. 4. **Chảy một chiều, có thể hồi phục.** Ticket đi theo lifecycle cố định; mọi thay đổi qua file + git → luôn revert được. 5. **Người giữ cổng cho việc nhạy cảm.** AI làm các P0 **an toàn/không phụ thuộc quyết định thị trường** (security, honesty, data-model, CI, gỡ link chết). Việc cần người quyết (ký hợp đồng, pháp lý, tiền thật) → gắn cờ cho founder, **không tự làm**. 6. **Launch-ready ASAP, không cầu toàn.** Mục tiêu là "đưa được cho người thật dùng sớm nhất một cách trung thực", không phải hoàn hảo. CEO định nghĩa "mức tối thiểu để launch". 7. **Tự nâng cấp.** Học được prompt tốt hơn / lead mới / rubric sắc hơn → sửa `METHODOLOGY.md` + template → **mọi war-room sau kế thừa**. Phương pháp tiến hoá theo thời gian. --- ## 2. Kiến trúc tổng thể Bốn lớp: **Trigger → Nguồn sự thật (brain) → Orchestration → Sản phẩm trong repo đích.** ``` ┌──────────────────────────────────────────────────────────────────────┐ │ A. TRIGGER (công tắc) │ │ ~/.claude/skills/war-room/SKILL.md │ │ "war room" / "gọi war room" / "bật mode CTO" → nạp phương pháp │ └───────────────┬──────────────────────────────────────────────────────┘ │ trỏ về ┌───────────────▼──────────────────────────────────────────────────────┐ │ B. BRAIN (nguồn sự thật dùng chung — /home/ubuntu/brain/warroom/) │ │ METHODOLOGY.md ← phương pháp đầy đủ │ │ templates/ │ │ war-room-workflow.js ← script orchestration 3 phase │ │ materialize.mjs ← result → board.json │ │ build-board.mjs ← board.json → BOARD.md │ │ board.seed.json ← scaffold board rỗng │ │ README.md ← doc hệ thống ticket (copy vào repo) │ └───────────────┬──────────────────────────────────────────────────────┘ │ chạy qua tool Workflow ┌───────────────▼──────────────────────────────────────────────────────┐ │ C. ORCHESTRATION (multi-agent, tool `Workflow`) │ │ Phase 1 C-Suite Audit → 5 lead audit song song │ │ Phase 2 Team Deep-Dive → team nở P0/P1 thành spec │ │ Phase 3 Synthesize → Chief-of-Staff gộp 1 board │ │ return { org, synthesis } │ └───────────────┬──────────────────────────────────────────────────────┘ │ materialize + render + commit ┌───────────────▼──────────────────────────────────────────────────────┐ │ D. SẢN PHẨM (trong repo đích — /warroom/) │ │ board.json ← NGUỒN SỰ THẬT (org, readiness, tickets, deps…) │ │ BOARD.md ← kanban người đọc (generated, đừng sửa tay) │ │ README.md ← cách hệ thống ticket hoạt động │ │ (versioned trong git → resume xuyên session) │ └──────────────────────────────────────────────────────────────────────┘ ``` **Ý đồ tách lớp:** *skill = công tắc* (mỏng, chỉ trigger); *brain = phương pháp* (dày, tái dùng cho mọi project, nâng cấp một chỗ ăn mọi nơi); *warroom/ trong repo = trạng thái riêng của từng dự án*. --- ## 3. Mô hình tổ chức (C-suite + teams) Mặc định 5 lead, **thêm/bớt theo domain** (CISO cho sản phẩm bảo mật, CMO Y khoa, Head of Data cho ML…). | Lead | Team | Sở hữu (lens) | |------|------|---------------| | **CEO** | Strategy & BizDev | Ưu tiên hoá, định nghĩa "launch-ready", GTM & positioning, go/no-go, rủi ro sống-còn | | **CTO** | Engineering (BE/FE/DevOps/QA) | Kiến trúc, bảo mật (auth/secrets/RBAC), độ tin cậy, data model, test, CI/CD, monitoring, scale, tech debt | | **CPO** | Product & Design | Luồng lõi, onboarding, funnel chuyển đổi, UX, i18n, empty state, **sự trung thực của sản phẩm**, mobile | | **CMO** | Growth, Content & SEO | Kênh acquisition (thật & hợp pháp), SEO, content, brand/trust (thật, không bịa), funnel | | **COO** | Ops, Legal & Finance | Pháp lý/compliance, payments, KYC/AML, support, unit economics, checklist launch & cổng go/no-go | Mỗi lead tự khai **roster 3-5 vai trò chuyên môn** trong team của mình (title + focus) khi audit. --- ## 4. Logic vận hành — Workflow 3 phase Script: `templates/war-room-workflow.js` (JS thuần, chạy qua tool `Workflow`). Điền 2 hằng: `CONTEXT` (grounding) và `LEADS` (roster). Trả về `{ org, synthesis }`. ``` LEADS ─┐ ├─ pipeline(mỗi lead chạy độc lập, KHÔNG chờ nhau giữa 2 phase): │ Phase 1 C-SUITE AUDIT agent(auditPrompt(lead), schema=AUDIT_SCHEMA) │ → { role, team, roster[3-5], findings[4-8], tickets[5-10] } │ Phase 2 TEAM DEEP-DIVE lấy top ≤4 ticket P0/P1 của lead → │ parallel( agent(expandPrompt, schema=EXPANDED_SCHEMA) ) │ → mỗi ticket: { approach, subtasks, acceptance, estimate, risks, crossTeamDeps } │ └────────────── (barrier) ──────────────┐ │ Phase 3 SYNTHESIZE agent(Chief-of-Staff, schema=SYNTH_SCHEMA, effort=high) gộp toàn bộ findings + tickets + expanded → { readiness{verdict,score,summary}, blockers[], criticalPath[], sprint0[], crossTeamDeps[], tickets[25-40 đã dedupe, id=-NNN] } ``` **Điểm thiết kế của logic:** - **Pipeline, không barrier giữa Phase 1↔2:** lead nào audit xong là team lead đó nở ticket ngay, không chờ lead chậm nhất → tiết kiệm wall-clock. - **Chỉ nở top ≤4 P0/P1 mỗi lead:** dồn công sức vào việc quan trọng, không phình. - **Barrier trước Synthesize:** vì Chief-of-Staff cần TOÀN BỘ để dedupe & xếp critical path. - **Structured output (schema) ở mọi agent:** không parse chuỗi, model buộc trả JSON đúng khuôn → materialize được ngay. - **Synthesize chạy `effort:'high'`:** khâu khó nhất (gộp + xếp thứ tự + chấm điểm) cần nhiều suy luận. --- ## 5. Mô hình dữ liệu ### Ticket ```jsonc { "id": "CTO-001", // -NNN "title": "…", "role": "CTO", "team": "Engineering", "priority": "P0", // P0 blocker · P1 trước launch · P2 fast-follow · P3 sau "effort": "M", // S <½d · M ~1-2d · L ~1wk · XL nhiều tuần "area": "…", "status": "backlog", // backlog → todo → in_progress → review → done "problem": "…", "acceptance": ["…"], // tiêu chí nghiệm thu cụ thể, test được "deps": ["CTO-000"], // id ticket khác (blocked = có dep chưa done) "comments": [], // trao đổi liên-team sống ở đây "created": "YYYY-MM-DD" } ``` ### board.json (nguồn sự thật) `{ meta, org[], readiness{verdict,score,summary}, blockers[], criticalPath[], sprint0[], crossTeamDeps[], tickets[] }` ### Lifecycle & quy ước - **Status:** `backlog → todo → in_progress → review → done` (`blocked` biểu diễn qua `deps` chưa done). - **Priority:** P0 (chặn launch) · P1 (trước public) · P2 (fast-follow) · P3 (sau). - **Effort:** S/M/L/XL. **Id:** `-NNN`. **Giao tiếp liên-team:** trong `comments[]` của từng ticket. --- ## 6. Pipeline hiện thực hoá (materialize → render → commit) ``` kết quả Workflow { org, synthesis } │ node materialize.mjs /warroom [YYYY-MM-DD] ▼ /warroom/board.json (normalize role→CEO/CTO/CPO/CMO/COO; status="backlog"; comments:[]) │ node /warroom/build-board.mjs ▼ /warroom/BOARD.md (kanban: readiness → blockers → critical path → Sprint 0 → bảng theo role) │ git add + commit ▼ Board sống — cập nhật status/comments → rebuild → commit → resume xuyên session ``` - `materialize.mjs`: đọc `.result`, chuẩn hoá role (regex CEO|CTO|CPO|CMO|COO|CISO|CFO), map team, gắn `status/comments/created`, ghi `board.json`. - `build-board.mjs`: **không phụ thuộc gì** (chỉ Node fs). Render readiness, P0 blockers, critical path, Sprint 0, bảng đếm priority/status, và bảng ticket nhóm theo role. --- ## 7. Quy trình chạy — 5 bước 1. **Scaffold** `warroom/` vào repo đích: copy `templates/README.md`, `build-board.mjs`, `board.seed.json` (điền `org`). 2. **Dựng CONTEXT** (grounding): sản phẩm là gì · stack/repo path · đã có gì · gap/rủi ro · chiến lược/north star · live URL · ràng buộc cứng (pháp lý/thị trường/nền tảng) · mục tiêu. *← đòn bẩy chất lượng số 1.* 3. **Chạy workflow:** điền `CONTEXT` + `LEADS` vào `war-room-workflow.js` → `Workflow({ script })`. 4. **Materialize:** `node materialize.mjs /warroom` → `node /warroom/build-board.mjs` → commit. 5. **Present + execute:** trình **verdict + P0 blockers + critical path + Sprint 0**; làm các **P0 an toàn** trước (security/honesty/data/CI/gỡ placeholder), **gắn cờ việc cần người quyết**. Xong ticket → update `status` + `comments` → rebuild → commit. --- ## 8. Resume / Status / Nâng cấp - **status:** đọc `warroom/BOARD.md` (hoặc `board.json`) → tóm tắt P0 đang mở + việc `in_progress`. - **resume:** chọn ticket P0/P1 chưa bị chặn (mọi `deps` đã `done`) → làm → đánh `done` + ghi comment → rebuild → commit → lặp. Workflow dừng giữa chừng resume được: `Workflow({scriptPath, resumeFromRunId})` (agent đã xong trả cache). - **Nâng cấp phương pháp:** học được gì hay → sửa `METHODOLOGY.md` + template ở brain → mọi war-room sau kế thừa; ghi adaptation đáng chú ý vào brain memory của project và link ngược về. --- ## 9. Bản đồ file | File | Vai trò | |---|---| | `skill/SKILL.md` | Công tắc toàn cục; mô tả trigger + tóm tắt 5 bước; trỏ về brain | | `brain/README.md` | Tổng quan brain (tiếng Việt) + đã dùng ở đâu | | `brain/METHODOLOGY.md` | Phương pháp luận đầy đủ (nguồn của SKILL) | | `brain/templates/war-room-workflow.js` | Script orchestration 3 phase (điền CONTEXT/LEADS) — **trái tim hệ thống** | | `brain/templates/materialize.mjs` | Kết quả workflow → `board.json` | | `brain/templates/build-board.mjs` | `board.json` → `BOARD.md` (renderer, no-dep) | | `brain/templates/board.seed.json` | Scaffold board rỗng | | `brain/templates/README.md` | Doc hệ thống ticket (copy vào repo `warroom/`) | | `brain/boards/chunhung-kho/` | **Ví dụ thật** — 1 board đã chạy (org roster + tickets) | --- ## 10. Vì sao thiết kế như vậy (design rationale) - **Tại sao file-based/git-native thay vì Jira/Notion?** Không phụ thuộc dịch vụ ngoài, versioned, agent đọc/ghi trực tiếp, diff review được, sống xuyên session, free. - **Tại sao tách skill vs brain?** Skill mỏng để trigger nhanh & đồng bộ; brain dày để tái dùng & nâng cấp một chỗ. Sản phẩm (warroom/ trong repo) là trạng thái riêng từng dự án. - **Tại sao C-suite thay vì 1 agent to?** Mỗi lens (chiến lược/kỹ thuật/sản phẩm/tăng trưởng/vận hành) bắt loại lỗi khác nhau; song song → phủ rộng & nhanh; Chief-of-Staff mới là người gộp. - **Tại sao structured output khắp nơi?** Để materialize deterministic — không parse chữ, không lỗi định dạng. - **Tại sao "honesty rule" đặt lên hàng đầu?** Vì giá trị của audit nằm ở việc nói ra sự thật khó nghe; một board đẹp nhưng bỏ qua lỗ hổng bảo mật/pháp lý là nguy hiểm hơn không audit. --- *Nguồn: chắt lọc từ `SKILL.md` + `METHODOLOGY.md` + templates trong `/home/ubuntu/brain/warroom/`. Muốn nâng cấp, sửa ở brain rồi sync sang skill — mọi war-room sau sẽ kế thừa.*