PLAYBOOK SDD ADD & CODEX | Chương 13

Hybrid Framework

Khi nào Spec, Khi nào Agent - Nghệ thuật phối hợp SDD + ADD

6

Sections

7

Bước workflow

12

Bảng dữ liệu

22

Trang tài liệu

Giới thiệu chương

Vì sao Hybrid Framework quan trọng?

Chương 1-12 đã xây dựng hai framework đầy đủ: SDD cho các phần cần chính xác ngay từ đầu và ADD cho phần cần tốc độ triển khai. Câu hỏi thực tế của mọi đội là chọn cái nào cho mỗi task, và khi nào cần chuyển trạng thái từ Spec-driven sang Agent-driven.

Chương 13 trả lời bằng bộ công cụ vận hành: mô hình Core & Shell, ma trận quyết định 3 chiều, workflow 7 bước có Escape Hatch, template thư mục và Git strategy, cùng Constitution mẫu cho đồ án 20 tuần.

Thông điệp trung tâm của chương là triết lý điều phối: Spec ở tầng kiến trúc, Agent ở tầng implementation. Không phải quy tắc cứng nhắc, mà là cách giữ cân bằng giữa rủi ro, tốc độ và chất lượng.

INFO - Câu hỏi trung tâm

SDD bảo vệ những thứ không được phép sai. ADD tăng tốc những thứ cần xoay chuyển nhanh. Kết hợp đúng mới là kỹ năng quan trọng của kỹ sư thời đại AI.

Mục lục

Cấu trúc Chương 13

13.1

Nguyên tắc Hybrid - Core & Shell

13.2

Decision Matrix - Spec x Autonomy x Risk

13.3

Hybrid Workflow 7 bước

13.4

Template thư mục Hybrid Project

13.5

Constitution mẫu đồ án SE 20 tuần

13.6

3 Anti-patterns cần tránh

13.1

Section Header

Nguyên tắc Hybrid - Mô hình Core & Shell

Mô hình Core & Shell mượn tư duy kiến trúc hệ thống: phần lõi cần ổn định tuyệt đối, phần vỏ cần linh hoạt để thích nghi nhanh.

13.1.1 CORE - Những thứ không được phép sai
13.1.2 SHELL - Những thứ cần xoay chuyển nhanh
13.1.3 Ranh giới CORE vs SHELL

13.1.1

Core & Shell Model trong thực thi

Trong Hybrid Framework, SDD bảo vệ CORE còn ADD triển khai SHELL. Core chứa database schema, API contract, security, authentication, state machine và payment flow. Shell chứa UI, business logic, CRUD, boilerplate, tests và docs.

Table

CORE - Những thứ không được phép sai

Core element	Tại sao không được sai	SDD level cần	Cost khi sai
Database schema	Migration phá dữ liệu production	Formal mức 3	Mất ngày restore backup, data loss
API contracts	Breaking change ảnh hưởng consumers	Formal	Clients lỗi hàng loạt, SLA breach
Authentication flow	Security vulnerability	Formal + security review	Data breach, legal liability
Payment state machine	Mất tiền hoặc duplicate charge	Formal + audit trail	Financial loss, churn
Data models	Sai domain kéo theo sai toàn hệ thống	Detailed/Formal	Refactor nhiều tháng
Security policies	Compliance violation	Formal + compliance review	Fine, reputational damage

13.1.2

SHELL - Nơi ưu tiên tốc độ và iteration

Shell là vùng mà lỗi có thể sửa nhanh với chi phí thấp. UI sai có thể chỉnh CSS trong vài phút, logic sai có thể debug trong sprint, test thiếu có thể bổ sung. Vì vậy mô hình Agent-first phù hợp.

Shell element	Tại sao Agent-first OK	ADD approach	Iteration cycle
UI Components	Visual feedback kiểm chứng nhanh	Agentic với Cline/Cursor	Minutes - hours
Business Logic	Test-driven correction khả thi	Agentic + DoD	Hours - days
CRUD operations	Pattern-based, complexity thấp	Template + Agent	Minutes
Boilerplate	Mechanical, dễ verify	Fully agentic	Seconds - minutes
Tests	Acceptance criteria rõ	Agent from spec	Hours
Documentation	Nội dung quan trọng hơn format	Agent + human review	Hours

13.1.3

Ranh giới Core vs Shell

Ranh giới không luôn rõ ràng. Ví dụ email validation tưởng là Shell nhưng nếu email là unique identifier ở database thì nó trở thành Core.

3 câu hỏi phân biệt nhanh

Nếu sai có sửa được mà không migration/rollback không?
Thành phần này có consumer ngoài module không?
Sai ở đây có liên quan security/compliance không?

Quy tắc quyết định

Có thể sửa nhanh, phạm vi cục bộ: Shell
Có consumer ngoài, ảnh hưởng hợp đồng: Core
Liên quan compliance hoặc security: Core + Formal Spec

13.2

Section Header

Decision Matrix - Spec Depth x Agent Autonomy x Risk

13.2.1 Ba chiều của ma trận
13.2.2 Ma trận 9 ô + Risk overlay
13.2.3 Flowchart quyết định nhanh
13.2.4 5 tình huống áp dụng

13.2.1

Ba chiều của Decision Matrix

Công cụ này trả lời ba câu hỏi cho mọi task: cần spec sâu bao nhiêu, trao autonomy cho agent ở mức nào, và risk thực tế là gì.

Chiều	Levels	Định nghĩa
Spec Depth	None / Light / Full	None: prompt; Light: EARS + scope + DoD; Full: 8-component + EARS + state diagram
Agent Autonomy	Guided / Agentic / Multi-agent	Guided: human-in-loop từng bước; Agentic: tự execute có gates; Multi-agent: team có orchestrator
Risk Level	Low / Medium / High	Low: lỗi dễ sửa; Medium: ảnh hưởng UX/data; High: tiền, security, compliance

Table

Decision Matrix 9 ô

Spec \ Autonomy	Guided	Agentic	Multi-agent
No Spec	Tránh: output khó đoán, chỉ hợp hackathon	Có thể dùng cho CSS tweak, utility đơn giản	Tránh: nhiều agent không contract sẽ hỗn loạn
Light Spec	Tốt cho feature medium risk, module đơn	Sweet spot cho đa số feature UI/logic/tests	Tốt cho parallel FE+BE với shared contracts
Full Spec	Mandatory cho payment/auth/compliance	Standard cho feature phức tạp có business rules	Enterprise cross-team, API chia sẻ, regulated

Table

Risk Overlay - Áp dụng chiều thứ ba

Risk	Spec depth	Autonomy	Ví dụ	Approach
High + Complex	Full mandatory	Guided	Payment/Auth	Full SDD - Guided Agent - Audit
High + Simple	Full	Agentic with gates	Rate limiting config	Spec + Agentic + Constitution
Medium + Complex	Light - Full	Agentic	Order management, reports	Light spec + Agentic + tests
Medium + Simple	Light	Agentic	Profile update	EARS + Agent + DoD
Low + Complex	Light	Multi-agent	Dashboard nhiều chart	Shared contracts + parallel agents
Low + Simple	None	Autonomous	CSS button, utils	Direct prompt - accept output

13.2.3

Flowchart quyết định nhanh

START: Tôi có một task cần làm Q1: Nếu sai, có cần DB migration/rollback không? NO -> CORE PATH -> Full Spec MANDATORY -> Human approval mọi step YES -> Q2: Có cần >1 agent làm song song? YES -> 2 agents: Light Spec + Agentic | 3+ agents: Light/Full + Multi-agent NO -> Q3: Rủi ro nếu agent hiểu sai intent? HIGH: Light/Full + Agentic (EARS + DoD) MEDIUM: Light + Agentic (Scope + DoD) LOW: No Spec + Agentic (Direct prompt + shadow plan)

Table

Ví dụ áp dụng ma trận (1/2)

Tình huống	Risk	Complexity	Quyết định	Thực hiện
Thêm màu button	Low	Low	No Spec + Agentic	Prompt trực tiếp, accept output
Add pagination danh sách	Low	Medium	Light Spec + Agentic	EARS + scope + DoD, 1 agent
Implement user registration	Medium	Medium	Light Spec + Agentic	EARS + auth constraints + DoD

Table

Ví dụ áp dụng ma trận (2/2)

Tình huống	Risk	Complexity	Quyết định	Thực hiện
Payment checkout flow	High	Complex	Full Spec + Guided	Formal spec + state machine + human every step
Dashboard 3 charts	Low	Complex	Light Spec + Multi-agent	Shared API contract + 3 agents song song

13.3

Section Header

Hybrid Workflow 7 Bước - Từ Idea đến Production

B1 Constitution Setup
B2 Feature Specification
B3 Plan Review
B4 Task Decomposition
B5 Agentic Implementation + Escape Hatch
B6 Validation Gate
B7 Integration & Review

13.3 Overview

Workflow chuẩn hóa SDD + ADD

Mục tiêu của quy trình 7 bước là giảm rework ở CORE, tăng tốc ở SHELL, và chốt chất lượng bằng Validation Gate trước merge. Escape Hatch được thiết kế như cơ chế kiểm soát rủi ro, không phải thất bại.

B1 Constitution Setup (một lần) B2 Feature Specification (mỗi feature) B3 Plan Review (Human + AI) B4 Task Decomposition (AI generate) B5 Agentic Implementation (ADD loop) - Escape Hatch any step B6 Validation Gate (Spec-based quality check) B7 Integration & Review (Human final)

Table

B1 - Constitution Setup artifacts

Artifact	File	Nội dung	Owner
Constitution	.sdd/constitution.md	Hard rules, architectural constraints, security	Tech Lead
Agent Persona	AGENTS.md	Stack, expertise, forbidden actions	Tech Lead
Project Context	CLAUDE.md	Architecture, patterns, lessons learned	Team
Global Constraints	.sdd/constraints/*.md	Tech stack, business rules, safety	Tech Lead
Skill Library	.sdd/skills/*.md	Domain expertise, reusable patterns	Senior devs

B1 DoD

Agent Pass Test trước khi đi tiếp

B1 DoD
Run: "Describe this project in 5 bullets"
-> Agent phải trả lời đúng bối cảnh, kiến trúc, ràng buộc.

Run: "What is NOT allowed in this project?"
-> Agent phải liệt kê đúng các vi phạm constitution.

Nếu sai/thiếu:
- Update context docs (AGENTS.md, CLAUDE.md, constraints)
- Chạy lại pass test trước khi qua B2.

B2

Feature Specification theo Core/Shell

Ở B2, mỗi feature được chia thành Core elements và Shell elements. Core dùng Full Spec; Shell dùng Light/No Spec để giữ tốc độ.

B2 checklist + ví dụ User Profile Update
1) Identify CORE elements:
   - Email uniqueness validation -> Full Spec
   - Phone number format (PII/compliance) -> Full Spec

2) Identify SHELL elements:
   - Profile form UI -> Light Spec
   - Toast notification -> No Spec
   - Avatar crop/resize -> Light Spec

Spec files cho CORE:
.sdd/features/feat-profile-update/core-email-validation.md
.sdd/features/feat-profile-update/core-phone-format.md

B3

Plan Review - điểm veto cuối trước khi code

Plan Review prompt
Đọc:
- .sdd/features/.../core-email-validation.md
- AGENTS.md và .sdd/constraints/

Viết execution plan:
1. CORE elements + approach
2. SHELL elements + approach
3. Agent team structure
4. Files sẽ thay đổi
5. Integration risks
6. Assumptions

DỪNG và đợi human approval.

WARN - Human review questions

CORE/SHELL phân loại đúng chưa? Team size agent phù hợp chưa? Có risk ẩn nào bị bỏ sót không? Assumptions có đúng context hệ thống không?

B4

Task Decomposition thành atomic tasks

Sau approve plan, agent tách task vào TASKS.md. Mỗi task nên dưới 4 giờ, có dependency rõ và DoD riêng.

TASKS.md output mẫu
T001 DB migration add phone_number | 1h | rollback OK
T002 Email validation service      | 2h | unit tests + constitution check
T003 Phone format validator E.164  | 2h | tests cover 10+ formats
T004 Profile form UI (depends T001)| 3h | renders + validation
T005 API endpoint (T002,T003)      | 2h | tests pass + OpenAPI updated
T006 Integration test              | 2h | E2E flow pass

Parallel:
- T001/T002/T003 chạy đồng thời
- T004/T005 đồng thời sau khi T001-T003 xong

B5

Agentic Implementation + Escape Hatch

B5 vận hành theo Plan-Act-Check. Human can thiệp ở approval gates hoặc khi agent stuck. Escape Hatch cho phép chuyển manual coding sau 3 lần loop lỗi hoặc khi thời hạn quá gấp.

Escape Hatch Protocol
Trigger:
- Agent loop > 3 lần cùng một lỗi
- Output quality liên tục dưới ngưỡng
- Task đòi hỏi domain knowledge chưa encode
- Deadline không cho phép chờ agent tự tìm ra

Khi kích hoạt:
1. Interrupt agent session
2. Manual code phần khó
3. Ghi vào plan.md: lý do, file, line, learning
4. Tiếp tục workflow với các task còn lại

Quote Spotlight

"Đừng tin AI khi nó nói: I have finished the task.\nHãy tin khi Unit Test xanh và Spec Checklist hoàn thành."

Table

B6 Validation Gate - 4 lớp kiểm tra

Layer	Kiểm tra	Tool	Fail = ?
L1 Automated	Unit tests, lint, type check	go test, eslint, mypy	Block merge, yêu cầu agent fix
L2 Spec Compliance	Mọi SHALL có code + EARS trace	Manual + AI-assisted	Task chưa được coi là done
L3 Constitution	Security, architecture, standards	CI pipeline checks	Block merge, escalate
L4 Acceptance	Criteria từ spec §7	Manual test + demo	Quay lại B5 để làm rõ/fix

B6 Checklist

Checklist bắt buộc trước merge

Validation Gate checklist
[L1]
[ ] go test ./... ALL PASS
[ ] golangci-lint ZERO errors
[ ] go vet CLEAN
[ ] gitleaks NO secrets

[L2]
[ ] Mỗi SHALL trong SPEC.md có implementation
[ ] EARS tags traceable
[ ] Không code out-of-scope
[ ] WHERE constraints có error handling

[L3]
[ ] Constitution self-check prompt pass
[ ] CI pipeline pass, không bypass

[L4]
[ ] Tất cả checkbox acceptance criteria được verify
[ ] Demo end-to-end pass

RULE: Chỉ 1 fail => quay về B5 và revalidate.

B7

Integration & Review - Human final gate

B7 không lặp lại việc kiểm spec hoặc code quality (đã xử lý ở B6). B7 tập trung vào system fit, kiến trúc tổng thể và tác động tương lai.

System & Architecture

Hidden dependency mới?
Side effect module khác?
Service boundaries có bị vi phạm?
Cross-service DB access có xuất hiện?

Future & Documentation

Có tạo tech debt hay breaking change tiềm ẩn?
Cần update shared_context.md / CHANGELOG?
Có lesson learned cần ghi vào CLAUDE.md?
Quyết định mới có cần ADR?

13.4

Section Header

Template Cấu trúc Thư mục Hybrid Project

13.4.1 Git Branching Strategy cho SDD
13.4.2 File Naming Conventions

13.4

Directory structure chuẩn cho Hybrid Project

Một cấu trúc thư mục tốt giúp agent và con người tìm đúng thông tin, giữ Git history rõ ràng, và cấu hình CI/CD đơn giản hơn.

Hybrid Project Directory
my-project/
├── .sdd/
│   ├── constitution.md
│   ├── shared_context.md
│   ├── constraints/{global,business,safety}.md
│   ├── specs/_template.md
│   ├── specs/feat-{name}/{SPEC,PLAN,TASKS,CHANGELOG}.md
│   ├── skills/*.md
│   ├── rfcs/ADR-001-*.md
│   └── reviews/
├── .agents/{AGENTS.md,CLAUDE.md,.agentignore}
├── src/{domain,usecase,interface,infra}
├── tests/{unit,integration,e2e}
├── docs/{api,architecture}
├── plan.md
├── AGENTS.md (symlink)
├── CLAUDE.md (symlink)
└── .github/workflows/

13.4.1

Git Branching Strategy - audit trail theo spec

Git flow
MAIN BRANCHES:
main (production, protected)
develop (integration, tests must pass)

SPEC BRANCHES:
spec/{feature-name}
- viết spec, AI review, human approval
- merge vào main (chỉ .sdd files)

AGENT BRANCHES:
agent/{feature-name}
- code implementation từ spec đã approved
- merge vào develop sau Validation Gate pass

HOTFIX:
fix/{issue-id}

FLOW:
1) spec/feature -> review -> approve
2) merge spec vào main
3) tạo agent/feature từ develop
4) agent implement
5) pass B6 -> merge develop
6) QA -> merge main

TAGS:
spec/payment/v1.0.0
release/v2.1.0

Table

File Naming Conventions

Artifact	Pattern	Ví dụ	Notes
Feature spec folder	feat-{kebab-name}	feat-user-profile	Lowercase + hyphens
Spec file	SPEC.md	SPEC.md	UPPERCASE, locked khi approved
Task file	TASKS.md	TASKS.md	Agent cập nhật
Skill file	{domain}-{name}.md	sql-performance.md	Kebab-case
ADR file	ADR-{n}-{name}.md	ADR-001-auth-approach.md	Zero-padded number
Git spec branch	spec/{feature}	spec/payment-v2	Slash chỉ dùng cho prefix
Git agent branch	agent/{feature}	agent/payment-v2	Match spec branch name
Git spec tag	spec/{name}/v{semver}	spec/payment/v1.0.0	Semver cho spec versions

13.5

Section Header

Template Constitution cho Đồ án SE 20 tuần

Layer 1: Hard Rules (Security, Data)
Layer 2: Architectural Constraints - API First
Layer 3: Engineering Standards + AI Agent Policy

13.5

Constitution Template - khung xương vận hành 20 tuần

Template này dành cho team 3-5 sinh viên, gồm rule bảo mật, ràng buộc kiến trúc, coding/testing standards, Git conventions, review process, deployment rules và agent policy.

Header mẫu
# PROJECT CONSTITUTION - [Tên đồ án]
# Version: 1.0.0 | Status: LOCKED
# Team: [Danh sách thành viên]
# Supervisor: [GVHD]
# Timeline: [Ngày bắt đầu] -> [Ngày bảo vệ]
# Last updated: [Date]

TIP

Constitution chỉ hiệu quả khi được coi là contract có thể enforce, không phải tài liệu tham khảo tùy ý.

Layer 1

Hard Rules - không bao giờ vi phạm

Layer 1 rules
SEC-01 Password Security:
- Hash password bằng bcrypt cost >=12 hoặc argon2id
- Không lưu plaintext

SEC-02 API Authentication:
- JWT Bearer cho mọi endpoint mutating
- Public endpoint phải comment // PUBLIC ENDPOINT

SEC-03 Input Validation:
- Validate + sanitize tất cả user input
- Không raw SQL concatenation

DATA-01 Soft Delete:
- Dùng deleted_at cho business entities
- Hard delete chỉ cho temp data/logs

AUDIT-01 Change Logging:
- Log CREATE/UPDATE/DELETE với actor, action, object_id, timestamp, ip_address

Layer 2

Architectural Constraints - API First bắt buộc

ARCH constraints
ARCH-01 API First Policy:
1) Update docs/api/openapi.yaml trước code
2) Review approval >= 1 member
3) Sau approve mới implement
Enforcement: CI fail nếu endpoint có trong code nhưng không có trong openapi.yaml

ARCH-02 Layer Boundaries:
controller -> service -> repository
Service không import repository của service khác
Cross-service qua events hoặc API calls

ARCH-03 Error Handling:
Không expose stack trace ra client
Error format: {error_code, message, request_id}
Stack trace chỉ ở server logs

Layer 3

Engineering Standards + Testing + Git conventions

Tech stack và standards
Tech stack mẫu:
Backend FastAPI 0.111+ (Python 3.12+)
Database PostgreSQL 16 + SQLAlchemy 2.0
Cache Redis 7
Frontend React 18 + TypeScript 5 + Vite
Styling Tailwind CSS 3
Testing pytest + Vitest
Docs OpenAPI 3.1

Python: type hints public funcs, Google docstring, black 88, ruff
TypeScript: strict mode, no any, prettier + eslint

Testing requirements:
- Backend coverage >= 80%
- Integration tests cho mọi API endpoint
- Frontend unit/component/E2E

DoD universal:
- tests pass 100%
- no lint errors
- coverage >= 80%
- OpenAPI updated nếu đổi API

Git conventions:
- branches: spec/*, agent/*, fix/*
- conventional commits: feat/fix/docs/spec/chore
- PR: >=1 reviewer, CI pass, no self-approval

AI Agent Policy

Agent Permissions, Forbidden, Must-do

Allowed / Forbidden

Allowed: read/write src/, tests/, docs/
Allowed: execute pytest, vitest, ruff, eslint, git add/commit
Forbidden không có human confirm: delete files, sửa constitution, push main/develop
Forbidden: thêm dependency và đổi DB schema khi chưa có approval

Agent MUST-DO

Chạy Spec Self-Check trước khi submit code
Update plan.md sau mỗi completed step
Báo cáo edge case không có trong spec
Shadow Plan trước khi execute task mới

13.6

Section Header

3 Anti-patterns cần tránh

AP1 Over-Specification
AP2 Blind Trust
AP3 Context Amnesia

AP1

Over-Specification - Spec 500 dòng cho button

Over-specification xảy ra khi team dùng Formal Spec cho task chỉ cần prompt hoặc Light Spec. Hệ quả là chậm velocity, spec tự mâu thuẫn và agent quá tải bởi instruction density.

Dấu hiệu sớm

SPEC.md > 200 dòng cho utility/component, mô tả HOW thay vì WHAT, team mất >2 giờ review feature chỉ mất 1 ngày implement.

Cách sửa
1) Luôn chạy Risk x Complexity matrix trước khi viết spec
2) Verify bằng mắt dưới 30 giây => không cần EARS formal
3) Spec >150 dòng cho feature 1 ngày => trim xuống requirement cốt lõi
4) Nội dung thuần presentational (color/layout/animation) => Figma + prompt

AP2

Blind Trust - Accept all agent output

"Tests pass" không đồng nghĩa với đúng spec. Nếu tests không cover business rule hoặc tests được viết theo implementation sai, team sẽ merge bug với độ tự tin cao.

Ví dụ blind trust
# Agent viết login, test pass:
assert response.status_code == 200
assert "access_token" in response.json()

# Nhưng SPEC §6 yêu cầu:
# Wrong email và wrong password phải trả cùng message
# để tránh user enumeration.

# Agent lại trả:
# - Wrong email: "User not found"
# - Wrong password: "Incorrect password"
# => Security vulnerability dù tests vẫn xanh.

Fix bắt buộc

Validation Gate 4 lớp phải là điều kiện merge. Rule: "Agent says done" chỉ là điểm bắt đầu kiểm định, không phải điểm kết thúc task.

AP3

Context Amnesia - Không maintain memory

Khi AGENTS.md, CLAUDE.md và shared_context.md không được cập nhật sau quyết định quan trọng, agent sẽ lặp lại pattern cũ đã bị deprecated.

Scenario từ tài liệu
Sprint 3: team migrate password hashing từ bcrypt sang argon2id
PR discussion có ghi, nhưng AGENTS.md không update.

Sprint 5: agent tạo feature mới, đọc AGENTS.md cũ -> dùng bcrypt.
Tests vẫn pass, human review bỏ sót.
Sprint 7 audit phát hiện bcrypt trong code mới.
Sprint 8 phải refactor lại -> tốn 1 sprint.

Root cause: thiếu cập nhật memory artifact cùng commit quyết định.

Memory ritual

Mọi quyết định scope > 1 sprint phải update AGENTS.md/CLAUDE.md cùng PR; weekly review context docs; dùng ADR cho quyết định lớn; log breaking change vào shared_context.md ngay lập tức.

Table

Bảng tổng hợp 3 Anti-patterns

Anti-pattern	Dấu hiệu sớm	Cost nếu không sửa	Fix nhanh
Over-specification	Spec > 200 dòng cho task đơn giản	Slow velocity, giảm morale	Apply Risk Matrix trước khi viết spec
Blind Trust	Merge không qua Validation Gate	Security/compliance bugs	Mandatory Validation Gate checklist trong PR template
Context Amnesia	Agent lặp pattern deprecated	Rework, inconsistency, tech debt	Update AGENTS.md cùng PR code change

Summary + Next Chapter

Tổng kết Chương 13

Section	Key Technique	Điểm cốt lõi
13.1 Core & Shell	Phân loại theo risk	Xác định thành phần nào cần Full Spec, thành phần nào chạy Agent-first
13.2 Decision Matrix	9-cell + Risk overlay + Flowchart	Mọi task đều có cách chọn Spec depth và autonomy có hệ thống
13.3 Workflow 7 bước	B1-B7 + Escape Hatch + Validation Gate	Không bỏ qua B6 nếu muốn reliability thật sự
13.4 Directory template	Folder architecture + branch model	Tạo audit trail rõ giữa spec và code
13.5 Constitution	3-layer policy cho đồ án 20 tuần	Rule rõ + enforce được mới giữ chất lượng bền vững
13.6 Anti-patterns	3 cạm bẫy + cách né	Tránh over-spec, blind trust, context amnesia để giảm rework

Chương tiếp theo

Chương 14 - Tương lai của SDD + ADD

Khi model mạnh hơn và context window mở rộng, vai trò developer sẽ chuyển từ code executor sang system architect, policy designer và quality governor. Chương 14 phân tích cách SDD/ADD tiến hóa trong 5 năm tới.

5 Key Takeaways

5 điểm chốt cần nhớ

1) Core phải được khóa bằng Spec

Các phần như schema, auth, payment, security luôn cần Full Spec và approval rõ ràng trước khi code.

2) Shell là vùng tăng tốc của Agent

UI, CRUD, boilerplate, docs nên đi theo ADD để giảm cycle time và nhận feedback nhanh.

3) Decision Matrix giúp bỏ cảm tính

Dùng ba chiều Spec Depth x Autonomy x Risk để chọn chiến lược phù hợp cho từng task.

4) Validation Gate là điểm khóa chất lượng

Không có L1-L4 đầy đủ thì không merge. "Done" từ agent không thay thế evidence.

5) Memory management là năng lực chiến lược

Context docs phải được bảo trì liên tục để agent không tái tạo quyết định cũ đã lỗi thời.

PLAYBOOK SDD ADD & CODEX - Closing

Hybrid Framework

Chương 13 - Khi nào Spec, Khi nào Agent

LinhNDM

Nguyễn Đình Mạnh Linh