Spec hiện tại và Spec thay đổi (specs/ vs changes/)
Ý tưởng hay từ OpenSpec: tách rõ “mô tả hệ thống hiện tại” khỏi “một thay đổi đang được đề xuất”. Feature mới không chen thẳng vào bộ spec chính; nó sống trong một change folder riêng cho tới khi được review và archive.
Hai thư mục
specs/- baseline: hệ thống hiện tại đang phải hành xử thế nào.changes/- mỗi thay đổi một folder riêng, gồm:proposal.md(vì sao làm),specs/(delta: ADDED/MODIFIED/REMOVED),design.md(hướng kỹ thuật),tasks.md(checklist).
Chỉ sau khi làm xong và được review, change đó mới được archive, và phần spec mới được nhập vào baseline.
Vì sao cách nghĩ này giữ quy trình mềm
- Spec chính vẫn mô tả hệ thống hiện tại; thay đổi mới có chỗ riêng để thảo luận mà chưa làm rối baseline.
- Team có thể làm song song nhiều thay đổi mà không đụng nhau.
- Với brownfield, cực hữu ích: ghi rõ “đây là hành vi hiện tại” (kể cả xấu, mang nợ lịch sử) và “đây là đề xuất đổi hành vi”, thay vì trộn hai thứ rồi không ai biết đâu là sự thật đang chạy.
Nhịp OpenSpec: /opsx:propose → /opsx:apply → /opsx:sync → /opsx:archive.
Liên quan
- SDD không phải Waterfall - cơ chế giữ quy trình lặp lại, không cứng
- Iterative Improvement - tinh thần “lặp để học”
- Brownfield với SDD - nơi việc tách baseline / đề xuất quan trọng nhất
- Công cụ SDD - OpenSpec và các tool khác