Đặc tả DWP

Phiên bản 4.0.0. Trạng thái: Ổn định. Tài liệu này là đặc tả quy phạm cho phương pháp luận Deep Work Plan (DWP). Các từ khóa MUST, MUST NOT, SHOULD, SHOULD NOT và MAY được diễn giải như mô tả trong RFC 2119.

Bổ sung trong 2.4.0, không có thay đổi phá vỡ. (1) Phần Touched Surface — hợp đồng giữa những gì một tác vụ thay đổi và những gì phải được kiểm chứng, kèm lựa chọn cổng theo lớp rủi ro (cô lập / đường nối / dùng chung-lõi / không rõ); (2) kiểm chứng đầy đủ trở thành một yêu cầu trạng thái cuối cùng chạy trong Final Review bắt buộc duy nhất của kế hoạch, với các quy tắc tái sử dụng bằng chứng rõ ràng; (3) các quyết định về skill theo từng tác vụ chuyển vào tác vụ sở hữu, và Executive Report trở thành tùy chọn, theo yêu cầu; (4) một luồng create tùy thuộc chế độ — chế độ tin cậy vật liệu hóa trực tiếp nhưng vẫn giữ phân tích và các bước kiểm tra chất lượng; (5) vật liệu hóa kế hoạch Lite-first — create có hướng dẫn tạo ra một kế hoạch Lite có thể thực thi trực tiếp thay vì một bản nháp không thể thực thi, có thể được nâng cấp thành một kế hoạch Full vào bất kỳ lúc nào (xem Kế hoạch Lite); và (6) một ma trận tương thích rõ ràng: các kế hoạch và repository từ các phiên bản sớm hơn vẫn tuân thủ.

Chuẩn 4.0.0. Bước nhảy phiên bản căn chỉnh số hiệu của chuẩn với dòng sản phẩm — 2.x là lịch sử và không tồn tại chuẩn 3.x — và không thay đổi yêu cầu nào so với 2.4.0. Các kế hoạch và repository từ các phiên bản trước vẫn phù hợp.

Định nghĩa

Một Deep Work Plan là một thành phần có cấu trúc, chỉ dùng markdown, mô tả một tác vụ kỹ thuật phức tạp được phân rã thành các đơn vị công việc tuần tự, rà soát được, thiết kế để được tạo ra, thực thi và duy trì bởi các agent lập trình AI làm việc tự chủ.

DWP dựa trên đặc tả: kế hoạch là đặc tả, và các agent PHẢI (MUST) thực thi dựa trên tiêu chí chấp nhận rõ ràng và các cổng kiểm chứng của nó thay vì tùy hứng. Đặc tả — chứ không phải một bản chép cuộc chat — là nguồn chân lý bền vững, nên công việc kiểm chứng được và tiếp tục được qua các phiên và các agent. Đó cũng là kỹ thuật harness được làm cho dễ mang theo: ngữ cảnh, vòng điều khiển, hàng rào bảo vệ và trạng thái có thể tiếp tục giúp một agent đáng tin cậy được cài vào chính repository dưới dạng markdown thuần, nên mọi agent tuân thủ ĐỀU CÓ THỂ (MAY) điều khiển repository mà không cần một framework gắn với công cụ cụ thể.

Luồng create — một bước, tùy thuộc chế độ

Luồng create thu thập mục tiêu, ngữ cảnh, các ràng buộc và dàn ý tác vụ một lần, thực hiện phân tích yêu cầu của nó (phạm vi, thứ tự phụ thuộc giữa các tác vụ, lựa chọn kiểm chứng từ Touched Surface, bậc rigor tỷ lệ), rồi vật liệu hóa theo chế độ nhà phát triển đã chọn:

• Chế độ hướng dẫn (mặc định). Luồng vật liệu hóa trực tiếp một kế hoạch Lite — một đề xuất gọn nhẹ, đã có thể thực thi, với các bản ghi tác vụ {#task-N} nội tuyến, có thể rà soát trong một lượt — và yêu cầu nhà phát triển giữ nguyên nó ở dạng Lite, nâng cấp nó thành một kế hoạch Full, yêu cầu chỉnh sửa, hoặc dừng lại. Không có bản nháp trung gian không thể thực thi nào được tạo ra.
• Chế độ tin cậy (trust / auto). Luồng vật liệu hóa trực tiếp biểu diễn đã chọn (Lite, hoặc Lite được nâng cấp ngay sau đó thành Full), không có bước rà soát — nhà phát triển đã từ chối bước đó. Phân tích yêu cầu, thứ tự phụ thuộc và một bước kiểm tra chất lượng kế hoạch vẫn chạy: trust từ chối lượt rà soát, chứ không phải phân tích. Một kế hoạch ở chế độ tin cậy được ghi lại là được phê duyệt trước cho thực thi không có giám sát.

Cả hai chế độ đều quyết định định dạng của kế hoạch (Lite hoặc Full) như một phần của cùng một phân tích yêu cầu, không bao giờ là một suy nghĩ muộn màng. Xem Kế hoạch Lite để biết đầy đủ vòng đời biểu diễn, tạo-và-lựa chọn, và nâng cấp.

Cấu trúc kế hoạch

Một kế hoạch PHẢI là một thư mục dưới .dwp/plans/ được đặt tên PLAN_<slug>/, theo một trong hai dạng biểu diễn:

• Full. Thư mục PHẢI chứa README.md (tổng quan kế hoạch, mục tiêu, bảng tác vụ và trạng thái), một tệp cho mỗi tác vụ đặt tên <n>.task_<slug>.md, và PROGRESS.md (một nhật ký chạy của quá trình thực thi).
• Lite. Các bản ghi tác vụ gọn nhẹ, có thể thực thi đầy đủ, sống nội tuyến trong README.md sau các neo {#task-N} ổn định thay vì các tệp tác vụ riêng biệt — mỗi bản ghi vẫn mang một mục tiêu, một Touched Surface, tiêu chí chấp nhận, kiểm chứng và nhật ký hoàn tất. PROGRESS.md vẫn BẮT BUỘC (REQUIRED). Một kế hoạch Lite CÓ THỂ (MAY) được nâng cấp thành Full vào bất kỳ lúc nào. Xem Kế hoạch Lite để biết vòng đời đầy đủ thay vì lặp lại ở đây.

Một kế hoạch CÓ THỂ (MAY) bổ sung mang lớp trạng thái có thể đọc bằng máy: manifest.json (danh tính tĩnh, được ghi một lần khi vật liệu hóa) và state.json (trạng thái thực thi trực tiếp theo tác vụ). Lớp trạng thái ĐƯỢC KHUYẾN NGHỊ (RECOMMENDED) cho các kế hoạch mới và BẮT BUỘC (REQUIRED) cho thực thi không có giám sát và cho các không gian làm việc agent không có git. Xem Trạng thái kế hoạch.

Cấu trúc tác vụ

Tệp nhiệm vụ

1. 01 Title
2. 02 Context
3. 03 Read Before Starting
4. 04 Goal
5. 05 Touched Surface
6. 06 Instructions
7. 07 Acceptance Criteria
8. 08 Outputs
9. 09 Validation
10. 10 Execution Checklist + Completion & Log

Mỗi tệp tác vụ PHẢI chứa mười phần này, theo thứ tự:

1. Goal — một câu phát biểu một đoạn về điều tác vụ đạt được.
2. Context — bối cảnh, liên kết và lý do tác vụ này tồn tại.
3. Touched Surface — hợp đồng giữa những gì tác vụ thay đổi và những gì phải được kiểm chứng.
4. Steps — các hành động cụ thể, có thứ tự cần thực hiện.
5. Acceptance criteria — một danh sách kiểm các điều kiện định nghĩa thế nào là xong.
6. Validation — các lệnh hoặc test cần chạy để kiểm chứng, được chọn từ Touched Surface.
7. Files — các đường dẫn dự kiến được tạo hoặc sửa đổi.
8. Dependencies — các tác vụ khác hoặc điều kiện tiên quyết bên ngoài.
9. Risks — điều gì có thể sai, và các biện pháp giảm thiểu.
10. Completion & Log — một dấu trạng thái cùng các ghi chú theo trình tự thời gian.

Một tác vụ CÓ THỂ bổ sung bao gồm một phần Delta (ĐƯỢC KHUYẾN NGHỊ cho các thay đổi hành vi trong codebase hiện có — xem bên dưới) và một phần Rollback (ĐƯỢC KHUYẾN NGHỊ cho các lần di chuyển, thay đổi hạ tầng hay triển khai).

Touched Surface

Touched Surface là hợp đồng giữa những gì một tác vụ thay đổi và những gì phải được kiểm chứng. Nó tồn tại để kiểm chứng được chọn theo hiệu ứng, không phải theo thói quen, và để một người đọc về sau thấy được vì sao một cổng được chọn. Một tác vụ thay đổi hành vi PHẢI ghi lại:

• Bề mặt dự kiến — các đường dẫn, mô-đun, gói hoặc cấu hình mà tác vụ định thay đổi, được viết trước khi chỉnh sửa.
• Bề mặt thực tế — danh sách đã đối chiếu sau khi chỉnh sửa, lấy từ diff thật. Agent PHẢI đối chiếu bề mặt dự kiến và bề mặt thực tế trước khi chọn cổng.
• Các bên tiêu thụ bị ảnh hưởng — các mô-đun, gói hoặc dịch vụ phụ thuộc vào bề mặt thực tế, xa nhất mức ánh xạ được tài liệu hóa của repository có thể xác lập. Nơi không thể, mục nhập PHẢI nói rõ điều đó.
• Lớp rủi ro — một trong: cô lập (giới hạn trong một mô-đun và các test của nó); đường nối (thay đổi một hợp đồng, tính bền vững dữ liệu, định tuyến, tuần tự hóa, xác thực hoặc wiring framework giữa các cộng tác viên); dùng chung/lõi (được import rộng rãi, hoặc một thay đổi phụ thuộc, di chuyển, cấu hình build/test, schema hoặc bộ công cụ); không rõ (ánh xạ bị thiếu, lỗi thời hoặc chưa xác minh).
• Ánh xạ test được dùng — ánh xạ hoặc công cụ được tài liệu hóa nào tạo ra lựa chọn.
• Cổng được chọn và lý do — các lệnh chính xác và vì sao chúng bao phủ bề mặt thực tế.

Các tệp cấu hình, schema, manifest phụ thuộc, mẫu, fixture, di chuyển và các tệp chỉ dẫn agent có thể thay đổi hành vi và PHẢI được phân loại theo hiệu ứng của chúng, không bao giờ theo phần mở rộng tệp. Một tác vụ chỉ thay đổi văn xuôi, chú thích hoặc các thành phần nghiên cứu CÓ THỂ (MAY) khai báo bề mặt không áp dụng và vẫn chạy các bước kiểm tra không cần runtime của repository.

Phần Delta (thay đổi trong codebase hiện có)

Hầu hết công việc thực tế sửa đổi hành vi hiện có thay vì tạo ra hành vi mới. Một tác vụ thay đổi cách một hệ thống hiện có hoạt động NÊN mang một phần Delta mô tả sự thay đổi dưới dạng hợp đồng trước/sau rõ ràng, sử dụng ba tiêu đề danh sách:

• ADDED — hành vi tồn tại sau tác vụ mà không có trước.
• MODIFIED — hành vi tồn tại trong cả hai, được nêu là was: … → now: ….
• REMOVED — hành vi tồn tại trước và được loại bỏ có chủ ý sau.

Mỗi mục PHẢI là hành vi có thể quan sát — phản hồi của một endpoint, một cờ CLI, một trạng thái UI, một giá trị mặc định — không phải một chi tiết triển khai. Phần Delta là diff của người rà soát ở mức hành vi: tiêu chí chấp nhận kiểm chứng các mục ADDED/MODIFIED, và các mục REMOVED là giấy phép rõ ràng để xóa. Bất cứ thứ gì không được liệt kê là REMOVED PHẢI tiếp tục hoạt động.

Cổng kiểm chứng — được chọn theo lớp rủi ro

Kiểm chứng là cổng biến một tuyên bố hoàn tất thành bằng chứng của nó: một tác vụ KHÔNG ĐƯỢC (MUST NOT) bị đánh dấu hoàn tất cho đến khi mọi lệnh trong phần Validation của nó đã chạy và đạt. Cổng của một tác vụ thay đổi hành vi được chọn từ Touched Surface đã đối chiếu của nó, theo lớp rủi ro:

Một thay đổi hành vi PHẢI tạo ra một lựa chọn test không rỗng và liên quan — một bộ chọn không hợp lệ hoặc một trình chạy chọn được số không test không phải là độ phủ. Nơi ánh xạ kiểm thử của repository lỗi thời, lệnh gọi đúng được suy diễn và việc cập nhật ánh xạ được ghi lại; một lệnh nhỏ bị thiếu không bao giờ đòi hỏi một lượt onboarding đầy đủ. Nơi không tồn tại lệnh gọi có phạm vi, bộ đầy đủ áp dụng — hành vi kế thừa, không bao giờ là một lỗi.

Khi một tác vụ thêm chức năng lõi mới hoặc thay đổi đáng kể hành vi hiện có, tiêu chí chấp nhận của nó PHẢI bao gồm độ phủ test tự động cho hành vi mới hoặc đã thay đổi, và kiểm chứng của nó chạy các test của repository cùng các bước kiểm tra lint, kiểm tra kiểu và định dạng — chứ không phải chỉ riêng bước build. Các test hiện có PHẢI tiếp tục xanh.

Kiểm chứng trạng thái cuối cùng

Các cổng theo tác vụ kiểm chứng những gì mỗi tác vụ chạm tới; chúng không thay thế việc kiểm chứng kế hoạch như một tổng thể. Trước khi một kế hoạch hoàn tất, kiểm chứng áp dụng đầy đủ của repository PHẢI chạy và đạt trên trạng thái liên quan cuối cùng, sau thay đổi substantive cuối cùng — trong Final Review. Các lượt chạy rộng hơn sớm hơn diễn ra tại các ranh giới tích hợp hoặc sau các thay đổi dùng chung/lõi, không theo một lịch trình đếm tác vụ. Một kết quả đạt CÓ THỂ (MAY) được tái sử dụng chỉ kèm bằng chứng rằng các đầu vào liên quan là tương đương; nếu không, nó được chạy lại. Mỗi lần chạy cổng để lại một bản ghi ngắn gọn: lệnh, phạm vi, revision, kết quả, và một đường dẫn bằng chứng.

Kỷ luật bảo mật

Bảo mật là hạng nhất giống như cách test là hạng nhất, và nó tuân theo cùng một mô hình hai lớp: kỷ luật theo từng tác vụ trong khi công việc diễn ra, cộng với bước rà soát bảo mật của Final Review trên toàn bộ tập thay đổi ở cuối. Bất cứ khi nào một tác vụ chạm đến xác thực hoặc phân quyền, xử lý đầu vào, bí mật hoặc cấu hình, bề mặt mạng, tệp, hoặc shell, hay các phụ thuộc:

• Tiêu chí chấp nhận của nó PHẢI nêu các kỳ vọng bảo mật của thay đổi — đầu vào được kiểm tra và escape, không có chất liệu bí mật trong mã hoặc fixture, các kiểm tra xác thực được giữ nguyên hoặc tăng cường — nhất quán với docs/SECURITY.md.
• Mọi commit PHẢI được xác nhận là không chứa bí mật hoặc thông tin xác thực trước khi nó được đưa vào, bao gồm cả fixture test và ví dụ tài liệu. Một bí mật trong một commit đã push PHẢI được coi là đã rò rỉ và phải xoay vòng, chứ không chỉ đơn thuần bị xóa.
• Nơi công việc nhạy cảm về bảo mật là đáng kể, một tác vụ gia cố chuyên biệt NÊN được đặt ngay sau các tác vụ triển khai và trước tác vụ test toàn diện, để các phát hiện được sửa trước khi test mã hóa hành vi và mỗi phát hiện trở thành một ca hồi quy thay vì làm lại.

Kỷ luật theo từng tác vụ này không thay thế bước rà soát bảo mật của Final Review: các kiểm tra theo từng tác vụ bắt vấn đề ngay tại commit nơi chúng sinh ra, trong khi cổng cuối kiểm toán toàn bộ kế hoạch — bao gồm chính các tác vụ test và tài liệu.

Vòng đời kế hoạch — Final Review

Mọi kế hoạch tuân thủ được viết dưới phiên bản này kết thúc bằng đúng một tác vụ bắt buộc: Final Review (tác vụ N). Hai trách nhiệm mà các phiên bản trước đặt trong các tác vụ khép riêng biệt được tái định vị: các quyết định về skill chuyển vào tác vụ đã tạo ra mô hình, và Executive Report trở thành một thành phẩm tùy chọn, theo yêu cầu. Không gì trong bước rà soát bảo mật bị nới lỏng.

Final Review PHẢI, theo thứ tự:

(a) Bước rà soát bảo mật — rà soát toàn bộ tập thay đổi đã tích lũy của kế hoạch để tìm bí mật hardcode, rủi ro tiêm nhiễm, bề mặt tấn công mới, xác thực bị suy yếu, và dữ liệu nhạy cảm trong log hay tài liệu; kiểm toán các phụ thuộc được đưa vào; xác minh docs/SECURITY.md vẫn phản ánh thực tế; viết báo cáo rà soát bảo mật ngay cả khi sạch. Một phát hiện nghiêm trọng được sửa — hoặc được người dùng chấp nhận rõ ràng — trước khi kế hoạch hoàn tất.

(b) Kiểm chứng trạng thái cuối cùng — kiểm chứng áp dụng đầy đủ của repository chạy và đạt trên trạng thái liên quan cuối cùng.

(c) Đối chiếu skill — mỗi tác vụ mang một kết luận về skill và mọi ứng viên được ghi lại đều có một kết luận; không có báo cáo khám phá lần hai.

(d) Hoàn tất — báo cáo hoàn tất với các sản phẩm bàn giao, bằng chứng kiểm chứng và các hạn chế; đề xuất Executive Report một lần. Kế hoạch hoàn tất bất kể đề xuất có được trả lời hay không.

Final Review chạy tuần tự sau mọi tác vụ khác và không bao giờ được đặt trong một nhóm song song.

Quyết định skill ngay trong tác vụ

Câu hỏi “công việc này có tạo ra một mô hình dùng lại được, đáng giá một skill hay agent không?” được trả lời bên trong tác vụ đã tạo ra mô hình đó, trong khi bằng chứng của nó còn trong ngữ cảnh. Completion & Log của mỗi tác vụ mang một kết luận về skill: không có gì, cập nhật một skill hiện có, tạo một thành phẩm có đặt tên, hoặc một lần hoãn kèm lý do. Việc viết skill khi thực sự có cơ sở diễn ra bên trong tác vụ đó, trước cổng kiểm chứng và commit của nó, sau khi kiểm tra danh mục hiện có để tìm trùng lặp.

Báo cáo điều hành — tùy chọn, theo yêu cầu

Executive Report không còn là một tác vụ bắt buộc. Lúc hoàn tất, agent đề xuất nó một lần; nó chỉ được tạo khi có một yêu cầu rõ ràng, được thỏa mãn từ bằng chứng bền vững mà không cần phát lại kế hoạch. Không trả lời, hoặc một lượt chạy không có giám sát, để kế hoạch hoàn tất mà không tạo báo cáo.

Giao thức hoàn tất tác vụ

Sau khi vượt qua kiểm chứng và trước khi chuyển sang tác vụ tiếp theo, agent PHẢI, theo thứ tự: (1) đánh dấu tác vụ [x] trong README kế hoạch; (2) tăng số đếm trạng thái kế hoạch; (3) điền vào phần Completion & Log của tác vụ mà không có giá trị placeholder; (4) thêm một mục 3–5 gạch đầu dòng vào PROGRESS.md; (5) commit (nơi kế hoạch commit) với định dạng {type}({scope}): {description} — Task {N} of PLAN_{name}; (6) nơi kế hoạch mang lớp trạng thái, ghi lại state.json nguyên tử — tác vụ completed, bản ghi cổng, bản ghi kết quả, băm commit.

Sáu bước tạo thành một giao dịch logic duy nhất. Một agent bị gián đoạn giữa chừng giao thức KHÔNG ĐƯỢC bắt đầu tác vụ tiếp theo — nó phải hoàn tất hoặc hoàn tác việc hoàn tất một phần trước.

Giao thức tiếp tục DWP

Tiếp tục PHẢI có thể thực hiện được chỉ từ các tệp của kế hoạch cộng với git log, không có trạng thái bên ngoài. Trong một không gian làm việc không có git — xem Các kiểu hình §3 — state.json của kế hoạch là BẮT BUỘC (REQUIRED) và thay thế cho git log.

Một agent tiếp tục — một phiên mới, một agent khác, một lượt daemon theo lịch, hay một cloud session thức dậy — PHẢI thực hiện nghi lễ này, theo thứ tự:

1. Tái neo. Đọc README kế hoạch: mục tiêu, hướng dẫn chung, danh sách tác vụ.
2. Định vị điểm kiểm tra. Tìm tác vụ chưa chọn đầu tiên trong README; đọc git log và git status (hoặc checkpoint của state.json nơi git vắng mặt).
3. Điều hòa trạng thái. Nơi state.json tồn tại, so sánh nó với các ô chọn README; khi desync, tái tạo nó từ markdown trước khi tiếp tục.
4. Kiểm tra đường nối. Đọc Completion & Log của tác vụ điểm tiếp tục và mục PROGRESS.md cuối cùng — nền tảng đã xác minh cuối cùng của phiên trước.
5. Smoke-test. Chạy kiểm chứng thường trực rẻ nhất của repository để xác nhận thế giới vẫn hoạt động trước khi xây dựng trên nó. Một smoke test thất bại được điều tra trước, không được xây dựng tiếp.
6. Tiếp tục nguyên tử. Thực thi đúng tác vụ tiếp theo; không gộp nhiều tác vụ.

Agent PHẢI tin vào các dấu đã hoàn tất ([x]) và KHÔNG ĐƯỢC tái kiểm chứng các tác vụ đã hoàn tất trừ khi người dùng yêu cầu rõ ràng, hoặc smoke test thất bại theo cách liên quan đến một tác vụ đã hoàn tất.

Vòng lặp thực thi

DWP định nghĩa năm thao tác:

• create — Sinh ra một kế hoạch mới từ một mục tiêu.
• execute — Thực thi kế hoạch từng tác vụ một.
• refine — Sửa đổi một kế hoạch hiện có.
• resume — Tiếp tục một kế hoạch bị gián đoạn.
• status — Báo cáo trạng thái kế hoạch mà không thực thi.

Không gian làm việc đầu ra

Không gian làm việc đầu ra

• .dwp/ bị git bỏ qua · có thể loại bỏ
• plans/
• PLAN_<name>/
• README.md
• PROGRESS.md
• <n>.task_<slug>.md
• analysis_results/ báo cáo
• SECURITY_REVIEW.md đánh giá bảo mật
• EXECUTIVE_REPORT.md báo cáo điều hành

Tất cả thành phần DWP PHẢI sống dưới một thư mục .dwp/ được gitignore tại gốc repository.

Trạng thái kế hoạch có thể đọc bằng máy

Một kế hoạch CÓ THỂ mang lớp trạng thái có thể đọc bằng máy — manifest.json (danh tính tĩnh) và state.json (trạng thái trực tiếp theo tác vụ, bản ghi cổng kiểm chứng, bản ghi kết quả, điểm kiểm tra, trạng thái bị chặn). Kế hoạch markdown vẫn là nguồn chân lý; lớp JSON là một phép chiếu dẫn xuất, được tái tạo tại các điểm giao thức và được điều hòa khi tiếp tục.

Lớp trạng thái ĐƯỢC KHUYẾN NGHỊ cho các kế hoạch mới, BẮT BUỘC cho thực thi không có giám sát, và BẮT BUỘC cho các không gian làm việc agent không có git. Xem định nghĩa quy phạm đầy đủ trong Trạng thái kế hoạch.

Rigor tỷ lệ

Rigor PHẢI tỷ lệ với công việc. Nghi lễ trên các thay đổi tầm thường là một lỗi phương pháp luận, không phải sự an toàn thêm. Mọi công việc đều thuộc chính xác một bậc:

Một agent được yêu cầu tạo kế hoạch cho công việc bậc micro PHẢI nói rằng một kế hoạch là không tương xứng và đề xuất hình thức nội tuyến thay thế. Một thư mục kế hoạch KHÔNG ĐƯỢC tạo cho một thay đổi đơn tệp tầm thường.

Công việc bậc micro vẫn giữ các yếu tố không thể thương lượng: một mục tiêu rõ ràng, một cổng kiểm chứng chạy và đạt, và kỷ luật test cho các thay đổi hành vi. Bậc thay đổi bao bì, không bao giờ thay đổi các cổng.

Khi phạm vi tăng lên giữa chừng — một tác vụ micro khám phá phạm vi thực sự, một kế hoạch standard nảy sinh các sub-repository — agent PHẢI dừng lại và nâng cấp công việc lên bậc tiếp theo thay vì kéo dài bậc hiện tại.

Tương thích

Các kế hoạch và repository từ các phiên bản sớm hơn vẫn tuân thủ, và một trình kiểm tra tuân thủ PHẢI phân biệt một thành phẩm cũ đã biết (được chấp nhận) với một thành phẩm khai báo phiên bản này mà về khách quan không hợp lệ dưới nó (bị từ chối):

Phiên bản hóa

Đặc tả này tuân theo phiên bản hóa ngữ nghĩa (semantic versioning).