Kết luận trước: hướng đi gọn hơn hợp lý, nhưng V6 chưa sẵn sàng chạy

Đề xuất là đóng băng lớp thực thi V5, đồng thời giữ lại phương pháp phân tích và những bài học có bằng chứng. Kiến trúc V6 nên dựa vào bộ điều phối bmad-loop, một khung thực thi duy nhất là Cline, các bước xác minh bên ngoài và một tệp kinh nghiệm dạng văn bản.

Tuy nhiên, đây mới là kiến trúc mục tiêu, không phải hệ thống đã được chứng minh vận hành. Những điểm then chốt—đặc biệt là khả năng nối Cline vào vòng đời bmad-loop, cách ly người kiểm duyệt khỏi ngữ cảnh phát triển, cổng Jev và việc VPS tiếp tục làm việc sau khi máy khách ngắt—vẫn thiếu bằng chứng chạy thực tế.

Vì vậy, quyết định hợp lý không phải là bắt đầu xây thêm một bộ điều khiển, mà là đóng băng V5 và kiểm chứng từng điểm nối cần thiết trước khi cho phép một Story thật chạy qua V6.

V5: vấn đề nằm ở độ lệch giữa độ phức tạp và giá trị đã chứng minh

Kho lưu trữ không phải là bộ thực thi

Tệp bmad_control_store.py được kiểm tra có 315 dòng, không phải 1.728 dòng. Đây là một cơ chế ghi nhận dạng tệp nối tiếp, không phải cơ sở dữ liệu SQL. Chưa có bằng chứng trong lần rà soát này về phiên bản 1.728 dòng trước đó hoặc commit tương ứng.

Mã hiện tại xử lý nhiều chi tiết như danh tính thư mục, quyền tệp, khóa, phiên bản yêu cầu, tính liên tục của lịch sử, hạn mức dung lượng, đọc lại sau khi lưu và dấu vân tay nội dung. Nhưng kết quả trả về cũng nêu rõ những việc nó không làm: không xác thực danh tính con người, không cấp quyền thực thi, không khởi chạy công việc và không lưu tiến độ công việc.

Đó là điểm lệch kiến trúc đáng chú ý: một lớp ghi nhận quyết định có thể rất chặt chẽ, nhưng bản thân nó không chứng minh được quyết định đã dẫn đến hoàn thành công việc. Các kiểm tra an toàn không mặc nhiên là thừa; vấn đề là xây một giao thức lưu trữ chung trước khi chứng minh được vòng công việc thực tế đã khép kín.

Cũng chưa đủ cơ sở để nói phần mã này gây “bùng nổ ngữ cảnh”. Mã chỉ trở thành gánh nặng ngữ cảnh nếu thường xuyên được đưa vào đầu vào của mô hình; lần rà soát này không có dữ liệu tải yêu cầu đầy đủ hay phép đo nhân quả. Tương tự, cơ chế khóa độc quyền không chờ vô hạn mà từ chối khi có xung đột. Khả năng làm chậm tiến độ là một rủi ro cần xem xét, nhưng chưa thể kết luận đã xảy ra deadlock nếu không có nhật ký hoặc chuỗi chờ thực tế.

Thực thi không đồng nhất: nguy cơ có thật, sự cố chưa được chứng minh

Cấu hình hiện tại của backend Pi vô hiệu hóa kỹ năng, tiện ích mở rộng, MCP, mẫu nhắc lệnh và tệp ngữ cảnh, đồng thời giới hạn danh sách công cụ được phép. Điều đó khiến backend không tự phát hiện kỹ năng BMAD. Nếu vẫn yêu cầu nó dùng BMAD, lớp bên ngoài phải tự đưa nội dung kỹ năng vào, xử lý các phụ thuộc và duy trì ánh xạ phiên bản.

Điều này không chứng minh backend hoàn toàn không thể dùng BMAD; nó cho thấy phần việc mà cơ chế nạp kỹ năng gốc có thể đảm nhiệm đang bị đẩy sang lớp tích hợp. Tài liệu bmad-build-auto cũng không chỉ là một đoạn hướng dẫn có thể sao chép tùy ý: nó dựa vào điểm kết xuất trong dự án, thư mục kỹ năng và cách xử lý lỗi cụ thể.

Các tài liệu cũ đã nhận diện rủi ro khi để Cline lập kế hoạch và Pi viết mã cùng tồn tại—như hai nguồn có quyền điều phối, thay đổi nghĩa của phê duyệt hoặc nhầm lẫn giữa lưu lịch sử chat với khôi phục công việc. Đó là những rủi ro đã được mô tả, không phải bằng chứng rằng một sự cố “hai Agent lồng nhau” thực sự đã xảy ra.

Đối với V6, nguyên tắc nên là chỉ dùng một khung thực thi Cline. Quyền tự động chấp thuận công cụ không đồng nghĩa với quyền thay đổi mục tiêu; mô hình cũng không được tự mở rộng phạm vi công việc.

Kiểm thử đơn vị xanh không đồng nghĩa sản phẩm từ xa đã khép kín

Kế hoạch hiện tại ghi nhận 231 bài kiểm thử chuyên biệt từng được người dùng xác nhận là đạt. Nhưng kế hoạch cũng nêu những phần chưa được xác minh: backend thật, xác thực độc lập, việc bắt đầu bước mới sau khi đóng máy khách và vòng công việc từ đầu đến cuối trên môi trường từ xa. Những bài kiểm thử cũ không được chạy lại trong lần rà soát này.

Điểm cần chỉnh không phải là “các bài kiểm thử đều vô nghĩa”, mà là chúng kiểm tra một phạm vi khác với sản phẩm cuối cùng. Kiểm thử khóa, phiên bản và đường dẫn có thể chứng minh các nguyên tắc đó hoạt động theo mã; chúng không chứng minh CLI mục tiêu nạp đúng kỹ năng, mô hình gọi công cụ đúng, hay VPS tự bắt đầu bước mới sau khi IDE cục bộ đóng.

Do đó, nên giữ lại các bài kiểm thử và biên bản như tài sản lịch sử, nhưng không dùng kết quả ấy làm đèn xanh cho V6. Cần giữ phương pháp phân tích, quy trình ba lượt đọc và cách ra quyết định ADR; đồng thời dừng sửa tiếp lớp thực thi V5.

V6: mỗi thành phần một nhiệm vụ, không dựng thêm bộ điều khiển

Thành phần	Vai trò được đề xuất	Giới hạn cần giữ
bmad-loop	Chọn Story, quản lý phiên, xác minh, thử lại, commit và trạng thái chạy	Không tự đổi mục tiêu; không dựng thêm một vòng điều phối bên ngoài
Cline CLI	Thực hiện một nhiệm vụ phát triển hoặc kiểm duyệt trong workspace được chỉ định	Không bật thêm bộ lập kế hoạch, Hub nền hay vòng nhóm tự trị
BMAD-METHOD	Cung cấp vai trò và quy trình lập kế hoạch, xây dựng, rà soát	Không sao chép thành nhánh kỹ năng riêng; không nạp mọi vai trò cho mọi Story
solo-jev-gate	Đánh giá phạm vi và phân loại lỗi trên ứng viên Diff	Không sửa mã, chọn Story tiếp theo hay ghi đè kết quả kiểm thử thật
Cơ chế kinh nghiệm lấy cảm hứng từ Harness²	Lưu những bài học có bằng chứng để phiên sau tham khảo	Không sửa cổng bắt buộc hay tạo thêm vòng tối ưu hóa

bmad-loop điều khiển vòng công việc; mô hình vẫn làm phần việc của mô hình

“No LLM in the control loop” không có nghĩa là toàn hệ thống không dùng mô hình. Ý nghĩa ở đây là chương trình quyết định Story nào được chọn, giới hạn số lần thử, điều kiện qua cổng và trạng thái hoàn tất; các phiên Agent mới vẫn thực hiện viết mã và kiểm duyệt.

Trình tự được mô tả trong tài liệu cụ thể hơn khẩu hiệu: phát triển → xác minh → kiểm duyệt độc lập → xác minh lại → commit. Cách ly bằng Worktree cần được bật rõ ràng; nếu cần giao diện theo dõi, bmad-loop đã có TUI dựa trên Textual và Rich, không nhất thiết phải tự làm một bảng điều khiển khác.

Cần lưu ý một số mặc định: kiểm duyệt độc lập chỉ được kích hoạt theo khuyến nghị của nhà phát triển, không mặc nhiên bắt buộc cho mọi Story. Một số nhánh xử lý khi hết ngân sách kiểm duyệt có thể vẫn cho phép commit; hết lượt rà soát không tự động đồng nghĩa với cấm commit. Giới hạn token tích lũy cho Story thiên về cảnh báo, không phải cơ chế dừng cứng; kiểm soát ngân sách theo phiên còn phụ thuộc khả năng đọc thông tin sử dụng.

V6 nên bổ sung các điều kiện cần thiết tại điểm nối mà dự án hỗ trợ, thay vì sao chép máy trạng thái chọn việc, thử lại, phục hồi và commit của bmad-loop.

Cline: hai cấu hình phiên, không phải hai hệ thống tự trị

Có thể tổ chức hai cấu hình dự án: Slot-DEV cho phát triển và Slot-REVIEW cho kiểm duyệt. Chúng cần dùng thư mục cấu hình và phiên tách biệt; phiên DEV được phép ghi vào Worktree đã duyệt, còn phiên REVIEW chỉ nhận tiêu chí nghiệm thu, ứng viên đã đóng băng, mã liên quan và bằng chứng kiểm thử thật.

Sonnet 5.5 và GPT-6-Sol là tên mô hình mục tiêu trong đề xuất, không phải ID nhà cung cấp đã được xác minh. ID chính xác, giao thức, thông tin xác thực và ngân sách cần được đối chiếu bằng cấu hình không chứa bí mật và kết quả gọi thật.

Đây là nút thắt lớn nhất của V6: danh sách CLI tích hợp của bmad-loop hiện chưa có Cline; bộ chuyển đổi tổng quát cần các Hook vòng đời, trong khi những phương ngữ Hook được tài liệu liệt kê không bao gồm Cline. Tài liệu Cline có đề cập thư mục cấu hình, thư mục trạng thái tách biệt, working directory và tham số mô hình, nhưng chưa xác nhận một lệnh Profile gốc đã được kiểm chứng.

Trước khi chạy Story, cần chứng minh được cách khởi động phiên mới, nhận nhiệm vụ và kết thúc; sự kiện bắt đầu và hoàn tất gắn với đúng phiên; tin nhắn thông thường không bị nhầm thành hoàn tất; thao tác hủy thực sự kết thúc phiên và tiến trình công cụ. Nếu không đọc được mức sử dụng, hệ thống phải báo “không xác định”, không tuyên bố ngân sách đã được cưỡng chế.

Nếu Cline không đáp ứng hợp đồng hiện có, cần dùng điểm tích hợp được hỗ trợ chính thức. Không nên quay về V5 hoặc bọc một bộ điều phối thứ hai quanh Cline.

BMAD-METHOD: nạp theo nhu cầu, không biến kỹ năng thành “búp bê Nga”

Các vai trò được nêu trong tài liệu gồm Winston cho kiến trúc kỹ thuật, Amelia cho thực hiện Story được duyệt và Sofia cho cây ticket. Quy trình xây dựng tự động là một lượt công việc, không phải giấy phép cho mô hình tự trị vô thời hạn.

Thư mục kỹ năng BMAD có thể là nguồn để Cline phát hiện, nhưng vẫn cần kiểm tra thực tế: phát hiện qua liên kết mềm có hoạt động không, kỹ năng có nhìn thấy được trong Worktree không và nội dung có được nạp đúng không. Dự án cũng cần hoàn tất khởi tạo và cài các phụ thuộc kết xuất; chỉ tạo liên kết mềm là chưa đủ.

Danh mục cục bộ có 31 thư mục, trong đó 3 thư mục là hồ sơ mô-đun. Vì vậy không nên gọi cả 31 là kỹ năng Agile có thể gọi trực tiếp, càng không nên nạp toàn bộ vào mọi lượt làm việc.

Jev: quyết định có cấu trúc, nhưng không thay thế các kiểm tra tất định

Jev được TypeSafe mô tả là mô hình đưa ra quyết định có cấu trúc: nó nhận trạng thái cùng các câu hỏi kiểu hóa và trả về câu trả lời có cấu trúc, chứ không phải chatbot viết mã.12 Điều đó mở ra một phương án dùng Jev để đánh giá ngữ nghĩa của Diff; nhưng không chứng minh Jev có thể tự phát hiện đáng tin cậy mọi vi phạm phạm vi hay mọi nguyên nhân lỗi kiểm thử.

Cổng đề xuất nên chia làm hai phần. Lớp tất định liệt kê toàn bộ tệp thay đổi, kể cả tệp mới, rồi so với đường dẫn được duyệt và tài sản bị cấm. Đường dẫn vượt phạm vi phải bị chặn trực tiếp, không đưa ra biểu quyết của mô hình. Sau đó Jev có thể đánh giá phạm vi ngữ nghĩa và phân loại lỗi là vấn đề triển khai, môi trường hay chưa rõ. Trường hợp chưa rõ không được mặc định cho qua.

Một quy ước mã thoát có thể dùng là: 0 khi vượt qua kiểm tra; 1 khi ứng viên vi phạm phạm vi hoặc tiêu chí; 75 khi dịch vụ ngoài, xác thực, truyền tải hay môi trường không khả dụng. Mã 75 cần được ánh xạ vào cấu hình xác minh của bmad-loop sau khi kiểm tra thực tế. Định dạng yêu cầu Jev, xác thực phản hồi và phạm vi dữ liệu gửi ra ngoài cũng còn cần xác minh.

Cổng bên ngoài chạy sau khi mã đã được viết, nên nó không thể ngăn mọi tác dụng phụ từ trước. Worktree, quyền tài khoản và việc không cấp thông tin đăng nhập sản xuất mới là ranh giới hạn chế tác động; cổng trước commit không thể đảo ngược hành động bên ngoài đã xảy ra.

Kinh nghiệm từ Harness², không phải triển khai trọn bộ Harness²

Tài liệu Harness² mô tả hai tầng cải tiến: vòng lặp ở cấp nhiệm vụ và việc tích lũy kinh nghiệm cho nhiệm vụ sau. Tuy nhiên, phần phát hành được nêu trong ngữ cảnh này liệt kê OpenCode và Codex, không phải Cline.

Vì vậy, MVP chỉ nên mượn ý tưởng phản tư qua các nhiệm vụ: một tệp experience.md lưu điều kiện áp dụng, một bài học hành động được, vị trí của Story và bằng chứng thật, cùng trường hợp ngoại lệ. Phiên mới chỉ đọc những mục liên quan trong giới hạn xác định. Kinh nghiệm không được thay đổi quyền hạn hoặc tiêu chí nghiệm thu.

Không nên cài một bộ chạy Harness² hoàn chỉnh hay thêm vòng thử nghiệm, tinh chỉnh riêng. Cách gọi chính xác là cơ chế kinh nghiệm dạng văn bản “lấy cảm hứng từ Harness²”, không phải triển khai đầy đủ kiến trúc đệ quy hai tầng.

Một Story đi qua V6 như thế nào?

Lấy ví dụ một Story về ngăn gửi đơn hàng trùng lặp, giả định sản phẩm đã xác định rõ thế nào là gửi trùng và đã duyệt phạm vi sửa phần xử lý đơn hàng cùng kiểm thử liên quan.

1. Nhận Story: bmad-loop chọn ticket đã được duyệt, kiểm tra phụ thuộc và tạo Worktree riêng. Trong lần đầu, dùng tài sản ticket trong cùng kho mã để tránh phải đồng bộ trạng thái giữa nhiều kho.
2. Mở phiên DEV mới: Cline đọc Story, tiêu chí nghiệm thu, kinh nghiệm liên quan và mã cần thiết. Phiên này không tiếp tục hội thoại cũ hay nạp lại bộ điều khiển V5.
3. Tạo ứng viên: Agent sửa mã và bổ sung trường hợp kiểm thử. Việc phiên Agent kết thúc chỉ cho biết nó đã dừng, không chứng minh Story đã đạt.
4. Xác minh bên ngoài: Kiểm tra tất cả tệp thay đổi, chạy kiểm thử liên quan và gọi Jev để đánh giá phạm vi. Bất kỳ bước bắt buộc nào thất bại thì không được commit.
5. Đóng băng bằng chứng: Ghi nhận danh tính nội dung ban đầu và ứng viên, tiêu chí nghiệm thu, lệnh kiểm thử cùng mã thoát thật. Đưa cả tệp mới vào phạm vi rà soát, không chỉ xem Diff của tệp đã được theo dõi.
6. Kiểm duyệt mù độc lập: Mở phiên REVIEW mới, không đưa hội thoại phát triển, bản tự tóm tắt hay lời biện hộ của phiên DEV vào. Người kiểm duyệt chỉ đọc ứng viên và bằng chứng, rồi trả về chấp thuận, từ chối hoặc chưa rõ kèm lý do; không sửa mã nghiệp vụ.
7. Rút kinh nghiệm: Chỉ ghi bài học khi có phản ví dụ hoặc bằng chứng thật. Nếu không có bài học mới thì không cần thêm mục; không được bịa “quy luật cải thiện” chỉ để tạo cảm giác hệ thống đang tiến hóa.
8. Kiểm tra cuối: Đối chiếu lại nội dung cuối, kết quả kiểm thử, Jev và quyết định kiểm duyệt. Nếu mã thay đổi sau khi duyệt, phê duyệt cũ hết hiệu lực.
9. Commit và merge: Chỉ bộ điều phối gốc thực hiện các bước này. Kinh nghiệm nên được commit cùng ứng viên đã qua cổng, tránh để một bài học chưa gắn với thay đổi đã được chấp nhận làm nhiễu nhiệm vụ sau.
10. Chuyển sang Story tiếp theo: Tạo Worktree mới từ nhánh đích và chỉ đọc những bài học liên quan. Nếu commit hoặc cập nhật ticket bị gián đoạn, giữ nguyên trạng thái gốc thay vì dùng một script vá để tự commit lần nữa.

Các lỗi phải thử trước khi gọi V6 là dùng được

• Máy khách hoặc SSH ngắt kết nối: VPS phải phát sinh được một sự kiện thực thi mới sau khi ngắt. Chỉ chứng minh tmux còn sống là chưa đủ.
• VPS mất kết nối tới mô hình hoặc Jev: Hệ thống phải dừng trong thời hạn hữu hạn; không thể đòi gọi dịch vụ từ xa khi hoàn toàn không có mạng.
• Kiểm thử thất bại: Giữ lại kết quả thật và không commit; số lần sửa do giới hạn của bộ điều phối kiểm soát.
• Kiểm duyệt từ chối, chưa rõ hoặc hết thời gian: Không commit; không được dùng cơ chế “hết giờ thì bỏ qua” để lách kiểm duyệt độc lập.
• Ứng viên thay đổi sau kiểm duyệt: Phê duyệt cũ không còn áp dụng.
• Không ghi được kinh nghiệm: Nếu tệp kinh nghiệm là tài sản bắt buộc của Story, phải dừng; không thể báo toàn bộ quy trình đã hoàn tất.
• Commit, merge hoặc cập nhật ticket bị ngắt: Giữ lại trạng thái và bằng chứng gốc, không dựng thêm máy trạng thái phục hồi riêng.
• Người dùng yêu cầu dừng: Cần chứng minh phiên và tiến trình công cụ đã kết thúc, không chỉ ghi nhận yêu cầu dừng.

Cần phân biệt “máy khách ngắt nhưng VPS vẫn hoạt động” với “VPS mất toàn bộ kết nối mạng”. V6 có thể hướng đến trường hợp thứ nhất; trong trường hợp thứ hai, tiêu chí đúng là dừng an toàn và giữ lại kết quả.

Đóng băng V5 và những điều kiện tối thiểu trước khi chạy V6

Giữ nguyên lịch sử, không biến việc dừng thành một trạng thái hoàn tất giả

Kế hoạch đang chờ thực hiện nên được lưu lại với toàn bộ hạng mục chưa hoàn thành và biên bản cũ. Có thể dùng trạng thái SUSPENDED đã có để ghi nhận V5 ngừng được triển khai, kèm giải thích rằng lớp thực thi V5 bị dừng về mặt chiến lược. Không nên tự thêm trạng thái mới mà bộ kiểm tra cũ không nhận biết.

Các hạng mục chưa xong không được đánh dấu hoàn tất, và kết quả kiểm thử lịch sử không được đổi nhãn thành kết quả xác minh V6. V6 cần có danh tính kế hoạch mới. ADR liên quan tiếp tục giữ trạng thái lịch sử PROPOSED; không hồi tố coi quyết định cũ đã được chấp nhận. “Đóng băng tài liệu” cũng không có nghĩa là tiến trình đang chạy đã dừng—việc vô hiệu hóa lối khởi động cũ, xử lý tiến trình đang chạy và lưu trữ vật lý cần một thao tác được ủy quyền riêng.

Bộ công cụ tối thiểu

Tài liệu thượng nguồn yêu cầu Python 3.11 trở lên, Git 2.34 trở lên và tmux 3.2 trở lên. TUI có phụ thuộc tùy chọn; chế độ ticket còn cần uv và một dự án BMAD được khởi tạo đúng.

Bộ triển khai tối thiểu còn cần Cline và bmad-loop ở phiên bản cố định, BMAD-METHOD cùng script kết xuất của dự án và các phụ thuộc cần để chạy kiểm thử. Phiên bản Node tối thiểu cho Cline phải được xác nhận từ siêu dữ liệu gói thực tế, không nên đoán. Không cần cài toàn bộ Harness², một executor thứ hai, hàng đợi thông điệp, cơ sở dữ liệu hay bảng điều khiển riêng.

Tài liệu đề xuất không xây cơ sở dữ liệu mới, nhưng chưa kiểm tra toàn bộ cơ chế lưu trữ nội bộ của Cline. Nếu yêu cầu “không cơ sở dữ liệu” bao gồm cả lưu trữ nội bộ của nhà cung cấp, điều này vẫn chưa được chứng minh.

Điều kiện qua cửa trước bài chạy thử

Trước khi khởi chạy một Story thật, cần có:

• Hai cấu hình DEV và REVIEW đã được kiểm tra bằng phiên thật, không chỉ khai báo trên tệp.
• BMAD được khởi tạo và kỹ năng được Cline phát hiện đúng trong Worktree.
• Cổng kiểm tra chạy thất bại theo hướng an toàn, xử lý được cả tệp mới và kiểm tra danh tính ứng viên sau kiểm duyệt.
• Quyết định kiểm duyệt được xác minh riêng; việc phiên kết thúc không bị hiểu nhầm là đã chấp thuận.
• Quyền truy cập mạng, thông tin xác thực, mô hình, chi phí, lệnh kiểm thử và cách dừng đã được phê duyệt rõ ràng.
• Một bài chạy thử thật đi qua phát triển, kiểm thử, Jev, kiểm duyệt độc lập và commit gốc.
• Sau khi máy khách cục bộ ngắt, một giai đoạn thực thi mới vẫn diễn ra trên VPS và có bằng chứng tương ứng.

Một Story có thể chứng minh luồng cơ bản, nhưng chưa chứng minh được kinh nghiệm đã chuyển sang phiên tiếp theo. Muốn xác nhận khả năng tiếp tục qua nhiều nhiệm vụ, cần ít nhất Story thứ hai đọc được kinh nghiệm đã commit từ Story đầu.

Phán quyết

Nên dừng mở rộng lớp thực thi V5, giữ lại phân tích và bằng chứng lịch sử, rồi mở một kế hoạch V6 mới. Hướng kiến trúc gọn hơn có cơ sở, nhưng tuyên bố rằng tất cả thành phần đã tương thích và có thể chạy xuyên suốt thì chưa có cơ sở.

Ưu tiên kỹ thuật số một là chứng minh Cline đáp ứng được hợp đồng phiên của bmad-loop, sau đó kiểm tra một chuỗi kiểm duyệt độc lập và commit có cơ chế chặn lỗi. Nếu điểm nối không đạt, hãy dừng tại đó. Đừng biến khoảng trống tích hợp thành lý do để xây lại một bộ trung gian kiểu V5.

Kết luận trước: hướng đi gọn hơn hợp lý, nhưng V6 chưa sẵn sàng chạy

Đề xuất là đóng băng lớp thực thi V5, đồng thời giữ lại phương pháp phân tích và những bài học có bằng chứng. Kiến trúc V6 nên dựa vào bộ điều phối bmad-loop, một khung thực thi duy nhất là Cline, các bước xác minh bên ngoài và một tệp kinh nghiệm dạng văn bản.

Tuy nhiên, đây mới là kiến trúc mục tiêu, không phải hệ thống đã được chứng minh vận hành. Những điểm then chốt—đặc biệt là khả năng nối Cline vào vòng đời bmad-loop, cách ly người kiểm duyệt khỏi ngữ cảnh phát triển, cổng Jev và việc VPS tiếp tục làm việc sau khi máy khách ngắt—vẫn thiếu bằng chứng chạy thực tế.

Vì vậy, quyết định hợp lý không phải là bắt đầu xây thêm một bộ điều khiển, mà là đóng băng V5 và kiểm chứng từng điểm nối cần thiết trước khi cho phép một Story thật chạy qua V6.

V5: vấn đề nằm ở độ lệch giữa độ phức tạp và giá trị đã chứng minh

Kho lưu trữ không phải là bộ thực thi

Tệp bmad_control_store.py được kiểm tra có 315 dòng, không phải 1.728 dòng. Đây là một cơ chế ghi nhận dạng tệp nối tiếp, không phải cơ sở dữ liệu SQL. Chưa có bằng chứng trong lần rà soát này về phiên bản 1.728 dòng trước đó hoặc commit tương ứng.

Mã hiện tại xử lý nhiều chi tiết như danh tính thư mục, quyền tệp, khóa, phiên bản yêu cầu, tính liên tục của lịch sử, hạn mức dung lượng, đọc lại sau khi lưu và dấu vân tay nội dung. Nhưng kết quả trả về cũng nêu rõ những việc nó không làm: không xác thực danh tính con người, không cấp quyền thực thi, không khởi chạy công việc và không lưu tiến độ công việc.

Đó là điểm lệch kiến trúc đáng chú ý: một lớp ghi nhận quyết định có thể rất chặt chẽ, nhưng bản thân nó không chứng minh được quyết định đã dẫn đến hoàn thành công việc. Các kiểm tra an toàn không mặc nhiên là thừa; vấn đề là xây một giao thức lưu trữ chung trước khi chứng minh được vòng công việc thực tế đã khép kín.

Cũng chưa đủ cơ sở để nói phần mã này gây “bùng nổ ngữ cảnh”. Mã chỉ trở thành gánh nặng ngữ cảnh nếu thường xuyên được đưa vào đầu vào của mô hình; lần rà soát này không có dữ liệu tải yêu cầu đầy đủ hay phép đo nhân quả. Tương tự, cơ chế khóa độc quyền không chờ vô hạn mà từ chối khi có xung đột. Khả năng làm chậm tiến độ là một rủi ro cần xem xét, nhưng chưa thể kết luận đã xảy ra deadlock nếu không có nhật ký hoặc chuỗi chờ thực tế.

Thực thi không đồng nhất: nguy cơ có thật, sự cố chưa được chứng minh

Cấu hình hiện tại của backend Pi vô hiệu hóa kỹ năng, tiện ích mở rộng, MCP, mẫu nhắc lệnh và tệp ngữ cảnh, đồng thời giới hạn danh sách công cụ được phép. Điều đó khiến backend không tự phát hiện kỹ năng BMAD. Nếu vẫn yêu cầu nó dùng BMAD, lớp bên ngoài phải tự đưa nội dung kỹ năng vào, xử lý các phụ thuộc và duy trì ánh xạ phiên bản.

Điều này không chứng minh backend hoàn toàn không thể dùng BMAD; nó cho thấy phần việc mà cơ chế nạp kỹ năng gốc có thể đảm nhiệm đang bị đẩy sang lớp tích hợp. Tài liệu bmad-build-auto cũng không chỉ là một đoạn hướng dẫn có thể sao chép tùy ý: nó dựa vào điểm kết xuất trong dự án, thư mục kỹ năng và cách xử lý lỗi cụ thể.

Các tài liệu cũ đã nhận diện rủi ro khi để Cline lập kế hoạch và Pi viết mã cùng tồn tại—như hai nguồn có quyền điều phối, thay đổi nghĩa của phê duyệt hoặc nhầm lẫn giữa lưu lịch sử chat với khôi phục công việc. Đó là những rủi ro đã được mô tả, không phải bằng chứng rằng một sự cố “hai Agent lồng nhau” thực sự đã xảy ra.

Đối với V6, nguyên tắc nên là chỉ dùng một khung thực thi Cline. Quyền tự động chấp thuận công cụ không đồng nghĩa với quyền thay đổi mục tiêu; mô hình cũng không được tự mở rộng phạm vi công việc.

Kiểm thử đơn vị xanh không đồng nghĩa sản phẩm từ xa đã khép kín

Kế hoạch hiện tại ghi nhận 231 bài kiểm thử chuyên biệt từng được người dùng xác nhận là đạt. Nhưng kế hoạch cũng nêu những phần chưa được xác minh: backend thật, xác thực độc lập, việc bắt đầu bước mới sau khi đóng máy khách và vòng công việc từ đầu đến cuối trên môi trường từ xa. Những bài kiểm thử cũ không được chạy lại trong lần rà soát này.

Điểm cần chỉnh không phải là “các bài kiểm thử đều vô nghĩa”, mà là chúng kiểm tra một phạm vi khác với sản phẩm cuối cùng. Kiểm thử khóa, phiên bản và đường dẫn có thể chứng minh các nguyên tắc đó hoạt động theo mã; chúng không chứng minh CLI mục tiêu nạp đúng kỹ năng, mô hình gọi công cụ đúng, hay VPS tự bắt đầu bước mới sau khi IDE cục bộ đóng.

Do đó, nên giữ lại các bài kiểm thử và biên bản như tài sản lịch sử, nhưng không dùng kết quả ấy làm đèn xanh cho V6. Cần giữ phương pháp phân tích, quy trình ba lượt đọc và cách ra quyết định ADR; đồng thời dừng sửa tiếp lớp thực thi V5.

V6: mỗi thành phần một nhiệm vụ, không dựng thêm bộ điều khiển

Thành phần	Vai trò được đề xuất	Giới hạn cần giữ
bmad-loop	Chọn Story, quản lý phiên, xác minh, thử lại, commit và trạng thái chạy	Không tự đổi mục tiêu; không dựng thêm một vòng điều phối bên ngoài
Cline CLI	Thực hiện một nhiệm vụ phát triển hoặc kiểm duyệt trong workspace được chỉ định	Không bật thêm bộ lập kế hoạch, Hub nền hay vòng nhóm tự trị
BMAD-METHOD	Cung cấp vai trò và quy trình lập kế hoạch, xây dựng, rà soát	Không sao chép thành nhánh kỹ năng riêng; không nạp mọi vai trò cho mọi Story
solo-jev-gate	Đánh giá phạm vi và phân loại lỗi trên ứng viên Diff	Không sửa mã, chọn Story tiếp theo hay ghi đè kết quả kiểm thử thật
Cơ chế kinh nghiệm lấy cảm hứng từ Harness²	Lưu những bài học có bằng chứng để phiên sau tham khảo	Không sửa cổng bắt buộc hay tạo thêm vòng tối ưu hóa

bmad-loop điều khiển vòng công việc; mô hình vẫn làm phần việc của mô hình

“No LLM in the control loop” không có nghĩa là toàn hệ thống không dùng mô hình. Ý nghĩa ở đây là chương trình quyết định Story nào được chọn, giới hạn số lần thử, điều kiện qua cổng và trạng thái hoàn tất; các phiên Agent mới vẫn thực hiện viết mã và kiểm duyệt.

Trình tự được mô tả trong tài liệu cụ thể hơn khẩu hiệu: phát triển → xác minh → kiểm duyệt độc lập → xác minh lại → commit. Cách ly bằng Worktree cần được bật rõ ràng; nếu cần giao diện theo dõi, bmad-loop đã có TUI dựa trên Textual và Rich, không nhất thiết phải tự làm một bảng điều khiển khác.

Cần lưu ý một số mặc định: kiểm duyệt độc lập chỉ được kích hoạt theo khuyến nghị của nhà phát triển, không mặc nhiên bắt buộc cho mọi Story. Một số nhánh xử lý khi hết ngân sách kiểm duyệt có thể vẫn cho phép commit; hết lượt rà soát không tự động đồng nghĩa với cấm commit. Giới hạn token tích lũy cho Story thiên về cảnh báo, không phải cơ chế dừng cứng; kiểm soát ngân sách theo phiên còn phụ thuộc khả năng đọc thông tin sử dụng.

V6 nên bổ sung các điều kiện cần thiết tại điểm nối mà dự án hỗ trợ, thay vì sao chép máy trạng thái chọn việc, thử lại, phục hồi và commit của bmad-loop.

Cline: hai cấu hình phiên, không phải hai hệ thống tự trị

Có thể tổ chức hai cấu hình dự án: Slot-DEV cho phát triển và Slot-REVIEW cho kiểm duyệt. Chúng cần dùng thư mục cấu hình và phiên tách biệt; phiên DEV được phép ghi vào Worktree đã duyệt, còn phiên REVIEW chỉ nhận tiêu chí nghiệm thu, ứng viên đã đóng băng, mã liên quan và bằng chứng kiểm thử thật.

Sonnet 5.5 và GPT-6-Sol là tên mô hình mục tiêu trong đề xuất, không phải ID nhà cung cấp đã được xác minh. ID chính xác, giao thức, thông tin xác thực và ngân sách cần được đối chiếu bằng cấu hình không chứa bí mật và kết quả gọi thật.

Đây là nút thắt lớn nhất của V6: danh sách CLI tích hợp của bmad-loop hiện chưa có Cline; bộ chuyển đổi tổng quát cần các Hook vòng đời, trong khi những phương ngữ Hook được tài liệu liệt kê không bao gồm Cline. Tài liệu Cline có đề cập thư mục cấu hình, thư mục trạng thái tách biệt, working directory và tham số mô hình, nhưng chưa xác nhận một lệnh Profile gốc đã được kiểm chứng.

Trước khi chạy Story, cần chứng minh được cách khởi động phiên mới, nhận nhiệm vụ và kết thúc; sự kiện bắt đầu và hoàn tất gắn với đúng phiên; tin nhắn thông thường không bị nhầm thành hoàn tất; thao tác hủy thực sự kết thúc phiên và tiến trình công cụ. Nếu không đọc được mức sử dụng, hệ thống phải báo “không xác định”, không tuyên bố ngân sách đã được cưỡng chế.

Nếu Cline không đáp ứng hợp đồng hiện có, cần dùng điểm tích hợp được hỗ trợ chính thức. Không nên quay về V5 hoặc bọc một bộ điều phối thứ hai quanh Cline.

BMAD-METHOD: nạp theo nhu cầu, không biến kỹ năng thành “búp bê Nga”

Các vai trò được nêu trong tài liệu gồm Winston cho kiến trúc kỹ thuật, Amelia cho thực hiện Story được duyệt và Sofia cho cây ticket. Quy trình xây dựng tự động là một lượt công việc, không phải giấy phép cho mô hình tự trị vô thời hạn.

Thư mục kỹ năng BMAD có thể là nguồn để Cline phát hiện, nhưng vẫn cần kiểm tra thực tế: phát hiện qua liên kết mềm có hoạt động không, kỹ năng có nhìn thấy được trong Worktree không và nội dung có được nạp đúng không. Dự án cũng cần hoàn tất khởi tạo và cài các phụ thuộc kết xuất; chỉ tạo liên kết mềm là chưa đủ.

Danh mục cục bộ có 31 thư mục, trong đó 3 thư mục là hồ sơ mô-đun. Vì vậy không nên gọi cả 31 là kỹ năng Agile có thể gọi trực tiếp, càng không nên nạp toàn bộ vào mọi lượt làm việc.

Jev: quyết định có cấu trúc, nhưng không thay thế các kiểm tra tất định

Jev được TypeSafe mô tả là mô hình đưa ra quyết định có cấu trúc: nó nhận trạng thái cùng các câu hỏi kiểu hóa và trả về câu trả lời có cấu trúc, chứ không phải chatbot viết mã.12 Điều đó mở ra một phương án dùng Jev để đánh giá ngữ nghĩa của Diff; nhưng không chứng minh Jev có thể tự phát hiện đáng tin cậy mọi vi phạm phạm vi hay mọi nguyên nhân lỗi kiểm thử.

Cổng đề xuất nên chia làm hai phần. Lớp tất định liệt kê toàn bộ tệp thay đổi, kể cả tệp mới, rồi so với đường dẫn được duyệt và tài sản bị cấm. Đường dẫn vượt phạm vi phải bị chặn trực tiếp, không đưa ra biểu quyết của mô hình. Sau đó Jev có thể đánh giá phạm vi ngữ nghĩa và phân loại lỗi là vấn đề triển khai, môi trường hay chưa rõ. Trường hợp chưa rõ không được mặc định cho qua.

Một quy ước mã thoát có thể dùng là: 0 khi vượt qua kiểm tra; 1 khi ứng viên vi phạm phạm vi hoặc tiêu chí; 75 khi dịch vụ ngoài, xác thực, truyền tải hay môi trường không khả dụng. Mã 75 cần được ánh xạ vào cấu hình xác minh của bmad-loop sau khi kiểm tra thực tế. Định dạng yêu cầu Jev, xác thực phản hồi và phạm vi dữ liệu gửi ra ngoài cũng còn cần xác minh.

Cổng bên ngoài chạy sau khi mã đã được viết, nên nó không thể ngăn mọi tác dụng phụ từ trước. Worktree, quyền tài khoản và việc không cấp thông tin đăng nhập sản xuất mới là ranh giới hạn chế tác động; cổng trước commit không thể đảo ngược hành động bên ngoài đã xảy ra.

Kinh nghiệm từ Harness², không phải triển khai trọn bộ Harness²

Tài liệu Harness² mô tả hai tầng cải tiến: vòng lặp ở cấp nhiệm vụ và việc tích lũy kinh nghiệm cho nhiệm vụ sau. Tuy nhiên, phần phát hành được nêu trong ngữ cảnh này liệt kê OpenCode và Codex, không phải Cline.

Vì vậy, MVP chỉ nên mượn ý tưởng phản tư qua các nhiệm vụ: một tệp experience.md lưu điều kiện áp dụng, một bài học hành động được, vị trí của Story và bằng chứng thật, cùng trường hợp ngoại lệ. Phiên mới chỉ đọc những mục liên quan trong giới hạn xác định. Kinh nghiệm không được thay đổi quyền hạn hoặc tiêu chí nghiệm thu.

Không nên cài một bộ chạy Harness² hoàn chỉnh hay thêm vòng thử nghiệm, tinh chỉnh riêng. Cách gọi chính xác là cơ chế kinh nghiệm dạng văn bản “lấy cảm hứng từ Harness²”, không phải triển khai đầy đủ kiến trúc đệ quy hai tầng.

Một Story đi qua V6 như thế nào?

Lấy ví dụ một Story về ngăn gửi đơn hàng trùng lặp, giả định sản phẩm đã xác định rõ thế nào là gửi trùng và đã duyệt phạm vi sửa phần xử lý đơn hàng cùng kiểm thử liên quan.

1. Nhận Story: bmad-loop chọn ticket đã được duyệt, kiểm tra phụ thuộc và tạo Worktree riêng. Trong lần đầu, dùng tài sản ticket trong cùng kho mã để tránh phải đồng bộ trạng thái giữa nhiều kho.
2. Mở phiên DEV mới: Cline đọc Story, tiêu chí nghiệm thu, kinh nghiệm liên quan và mã cần thiết. Phiên này không tiếp tục hội thoại cũ hay nạp lại bộ điều khiển V5.
3. Tạo ứng viên: Agent sửa mã và bổ sung trường hợp kiểm thử. Việc phiên Agent kết thúc chỉ cho biết nó đã dừng, không chứng minh Story đã đạt.
4. Xác minh bên ngoài: Kiểm tra tất cả tệp thay đổi, chạy kiểm thử liên quan và gọi Jev để đánh giá phạm vi. Bất kỳ bước bắt buộc nào thất bại thì không được commit.
5. Đóng băng bằng chứng: Ghi nhận danh tính nội dung ban đầu và ứng viên, tiêu chí nghiệm thu, lệnh kiểm thử cùng mã thoát thật. Đưa cả tệp mới vào phạm vi rà soát, không chỉ xem Diff của tệp đã được theo dõi.
6. Kiểm duyệt mù độc lập: Mở phiên REVIEW mới, không đưa hội thoại phát triển, bản tự tóm tắt hay lời biện hộ của phiên DEV vào. Người kiểm duyệt chỉ đọc ứng viên và bằng chứng, rồi trả về chấp thuận, từ chối hoặc chưa rõ kèm lý do; không sửa mã nghiệp vụ.
7. Rút kinh nghiệm: Chỉ ghi bài học khi có phản ví dụ hoặc bằng chứng thật. Nếu không có bài học mới thì không cần thêm mục; không được bịa “quy luật cải thiện” chỉ để tạo cảm giác hệ thống đang tiến hóa.
8. Kiểm tra cuối: Đối chiếu lại nội dung cuối, kết quả kiểm thử, Jev và quyết định kiểm duyệt. Nếu mã thay đổi sau khi duyệt, phê duyệt cũ hết hiệu lực.
9. Commit và merge: Chỉ bộ điều phối gốc thực hiện các bước này. Kinh nghiệm nên được commit cùng ứng viên đã qua cổng, tránh để một bài học chưa gắn với thay đổi đã được chấp nhận làm nhiễu nhiệm vụ sau.
10. Chuyển sang Story tiếp theo: Tạo Worktree mới từ nhánh đích và chỉ đọc những bài học liên quan. Nếu commit hoặc cập nhật ticket bị gián đoạn, giữ nguyên trạng thái gốc thay vì dùng một script vá để tự commit lần nữa.

Các lỗi phải thử trước khi gọi V6 là dùng được

• Máy khách hoặc SSH ngắt kết nối: VPS phải phát sinh được một sự kiện thực thi mới sau khi ngắt. Chỉ chứng minh tmux còn sống là chưa đủ.
• VPS mất kết nối tới mô hình hoặc Jev: Hệ thống phải dừng trong thời hạn hữu hạn; không thể đòi gọi dịch vụ từ xa khi hoàn toàn không có mạng.
• Kiểm thử thất bại: Giữ lại kết quả thật và không commit; số lần sửa do giới hạn của bộ điều phối kiểm soát.
• Kiểm duyệt từ chối, chưa rõ hoặc hết thời gian: Không commit; không được dùng cơ chế “hết giờ thì bỏ qua” để lách kiểm duyệt độc lập.
• Ứng viên thay đổi sau kiểm duyệt: Phê duyệt cũ không còn áp dụng.
• Không ghi được kinh nghiệm: Nếu tệp kinh nghiệm là tài sản bắt buộc của Story, phải dừng; không thể báo toàn bộ quy trình đã hoàn tất.
• Commit, merge hoặc cập nhật ticket bị ngắt: Giữ lại trạng thái và bằng chứng gốc, không dựng thêm máy trạng thái phục hồi riêng.
• Người dùng yêu cầu dừng: Cần chứng minh phiên và tiến trình công cụ đã kết thúc, không chỉ ghi nhận yêu cầu dừng.

Cần phân biệt “máy khách ngắt nhưng VPS vẫn hoạt động” với “VPS mất toàn bộ kết nối mạng”. V6 có thể hướng đến trường hợp thứ nhất; trong trường hợp thứ hai, tiêu chí đúng là dừng an toàn và giữ lại kết quả.

Đóng băng V5 và những điều kiện tối thiểu trước khi chạy V6

Giữ nguyên lịch sử, không biến việc dừng thành một trạng thái hoàn tất giả

Kế hoạch đang chờ thực hiện nên được lưu lại với toàn bộ hạng mục chưa hoàn thành và biên bản cũ. Có thể dùng trạng thái SUSPENDED đã có để ghi nhận V5 ngừng được triển khai, kèm giải thích rằng lớp thực thi V5 bị dừng về mặt chiến lược. Không nên tự thêm trạng thái mới mà bộ kiểm tra cũ không nhận biết.

Các hạng mục chưa xong không được đánh dấu hoàn tất, và kết quả kiểm thử lịch sử không được đổi nhãn thành kết quả xác minh V6. V6 cần có danh tính kế hoạch mới. ADR liên quan tiếp tục giữ trạng thái lịch sử PROPOSED; không hồi tố coi quyết định cũ đã được chấp nhận. “Đóng băng tài liệu” cũng không có nghĩa là tiến trình đang chạy đã dừng—việc vô hiệu hóa lối khởi động cũ, xử lý tiến trình đang chạy và lưu trữ vật lý cần một thao tác được ủy quyền riêng.

Bộ công cụ tối thiểu

Tài liệu thượng nguồn yêu cầu Python 3.11 trở lên, Git 2.34 trở lên và tmux 3.2 trở lên. TUI có phụ thuộc tùy chọn; chế độ ticket còn cần uv và một dự án BMAD được khởi tạo đúng.

Bộ triển khai tối thiểu còn cần Cline và bmad-loop ở phiên bản cố định, BMAD-METHOD cùng script kết xuất của dự án và các phụ thuộc cần để chạy kiểm thử. Phiên bản Node tối thiểu cho Cline phải được xác nhận từ siêu dữ liệu gói thực tế, không nên đoán. Không cần cài toàn bộ Harness², một executor thứ hai, hàng đợi thông điệp, cơ sở dữ liệu hay bảng điều khiển riêng.

Tài liệu đề xuất không xây cơ sở dữ liệu mới, nhưng chưa kiểm tra toàn bộ cơ chế lưu trữ nội bộ của Cline. Nếu yêu cầu “không cơ sở dữ liệu” bao gồm cả lưu trữ nội bộ của nhà cung cấp, điều này vẫn chưa được chứng minh.

Điều kiện qua cửa trước bài chạy thử

Trước khi khởi chạy một Story thật, cần có:

• Hai cấu hình DEV và REVIEW đã được kiểm tra bằng phiên thật, không chỉ khai báo trên tệp.
• BMAD được khởi tạo và kỹ năng được Cline phát hiện đúng trong Worktree.
• Cổng kiểm tra chạy thất bại theo hướng an toàn, xử lý được cả tệp mới và kiểm tra danh tính ứng viên sau kiểm duyệt.
• Quyết định kiểm duyệt được xác minh riêng; việc phiên kết thúc không bị hiểu nhầm là đã chấp thuận.
• Quyền truy cập mạng, thông tin xác thực, mô hình, chi phí, lệnh kiểm thử và cách dừng đã được phê duyệt rõ ràng.
• Một bài chạy thử thật đi qua phát triển, kiểm thử, Jev, kiểm duyệt độc lập và commit gốc.
• Sau khi máy khách cục bộ ngắt, một giai đoạn thực thi mới vẫn diễn ra trên VPS và có bằng chứng tương ứng.

Một Story có thể chứng minh luồng cơ bản, nhưng chưa chứng minh được kinh nghiệm đã chuyển sang phiên tiếp theo. Muốn xác nhận khả năng tiếp tục qua nhiều nhiệm vụ, cần ít nhất Story thứ hai đọc được kinh nghiệm đã commit từ Story đầu.

Phán quyết

Nên dừng mở rộng lớp thực thi V5, giữ lại phân tích và bằng chứng lịch sử, rồi mở một kế hoạch V6 mới. Hướng kiến trúc gọn hơn có cơ sở, nhưng tuyên bố rằng tất cả thành phần đã tương thích và có thể chạy xuyên suốt thì chưa có cơ sở.

Ưu tiên kỹ thuật số một là chứng minh Cline đáp ứng được hợp đồng phiên của bmad-loop, sau đó kiểm tra một chuỗi kiểm duyệt độc lập và commit có cơ chế chặn lỗi. Nếu điểm nối không đạt, hãy dừng tại đó. Đừng biến khoảng trống tích hợp thành lý do để xây lại một bộ trung gian kiểu V5.