anyone-can-architect 0.2.0 → 0.4.0

package/CONTEXT.md

@@ -72,7 +72,7 @@ _Avoid_: "subsection", "second-level heading", "clause"
 ### subsection
 
 Subsection
-`#### N.N.N Title`, the third level of division below a section and the deepest level, appearing only in blocks specified by a pattern
+`#### N.N.N Title`, the third level of division below a section and the deepest level, used at positions specified by a doc design or pattern
 _Avoid_: "third-level heading"
 
 ### drill-down
@@ -97,7 +97,7 @@ _Avoid_: "imprint", "marker", "version block"
 - [doc-design](#doc-design) references the guiding principles for drill-down and specifies which parts to [drill-down](#drill-down) into
 - [module](#module) uses the module [document-set](#document-set), with [repo-type-spec](#repo-type-spec) determining when to use it
 - [aca-footer](#aca-footer) determines the project's [repo-type](#repo-type)
-- [chapter](#chapter) contains many [section](#section), [section](#section) contains many [subsection](#subsection), and doc designs specify structure only down to section
+- [chapter](#chapter) contains many [section](#section), [section](#section) contains many [subsection](#subsection)
 
 ## Flagged ambiguities
 

package/README.md

@@ -12,7 +12,7 @@
 
 <p align="center"><strong>English</strong> · <a href="README.zh-CN.md">简体中文</a></p>
 
-<p align="center"><img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-8D6E63"> <img alt="Hosts" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20%7C%20Cursor%20%7C%20Grok%20%7C%20Antigravity-E8912D"></p>
+<p align="center"><a href="https://www.npmjs.com/package/anyone-can-architect"><img alt="npm version" src="https://img.shields.io/npm/v/anyone-can-architect?color=CB3837"></a> <img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-8D6E63"> <img alt="Hosts" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20%7C%20Cursor%20%7C%20Grok%20%7C%20Antigravity-E8912D"></p>
 
 ---
 
@@ -35,7 +35,8 @@ flowchart LR
     Brownfield --> Design
     Design --> Implement["/aca-implement<br>build code from the docs"]
     Implement --> Review["/aca-review<br>check against the design"]
-    Review --> Release["/aca-release<br>merge and tag"]
+    Review --> Test["/aca-test<br>run minimal tests"]
+    Test --> Release["/aca-release<br>merge and tag"]
 ```
 
 ---
@@ -84,6 +85,7 @@ In Codex, type `$` instead of `/`, for example `$aca`
 | `/aca-walkthrough` | Walks you through the design docs in plain language and fixes issues on the spot |
 | `/aca-implement` | Builds the code and tests from the design docs |
 | `/aca-review` | Reviews the design docs or the code in the current scope |
+| `/aca-test` | Selects and runs minimal tests based on the implementation or change blast radius |
 | `/aca-repo-audit` | Checks the whole repo for broken links, contradictions and drift between docs and code |
 | `/aca-release` | Merges the verified version into main and tags it |
 | `/aca-feedback` | Files a GitHub issue when a rule does not fit your project |
@@ -104,5 +106,5 @@ Run `bash tests/run-tests.sh` before opening a pull request
 
 ---
 
-> 📦 **Anyone Can Architect v0.2.0**
-> 🤝 Powered by [Anyone Can Architect](https://github.com/ruozi/anyone-can-architect) v0.2.0 · Repo-Type: `guideline`
+> 📦 **Anyone Can Architect v0.4.0**
+> 🤝 Powered by [Anyone Can Architect](https://github.com/ruozi/anyone-can-architect) v0.4.0 · Repo-Type: `guideline`

package/README.zh-CN.md

@@ -12,7 +12,7 @@
 
 <p align="center"><a href="README.md">English</a> · <strong>简体中文</strong></p>
 
-<p align="center"><img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-8D6E63"> <img alt="Hosts" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20%7C%20Cursor%20%7C%20Grok%20%7C%20Antigravity-E8912D"></p>
+<p align="center"><a href="https://www.npmjs.com/package/anyone-can-architect"><img alt="npm version" src="https://img.shields.io/npm/v/anyone-can-architect?color=CB3837"></a> <img alt="License: MIT" src="https://img.shields.io/badge/license-MIT-8D6E63"> <img alt="Hosts" src="https://img.shields.io/badge/hosts-Claude%20Code%20%7C%20Codex%20%7C%20Cursor%20%7C%20Grok%20%7C%20Antigravity-E8912D"></p>
 
 ---
 
@@ -35,7 +35,8 @@ flowchart LR
     Brownfield --> Design
     Design --> Implement["/aca-implement<br>按文档构建代码"]
     Implement --> Review["/aca-review<br>对照设计审查"]
-    Review --> Release["/aca-release<br>合并并打 Tag"]
+    Review --> Test["/aca-test<br>运行最小化测试"]
+    Test --> Release["/aca-release<br>合并并打 Tag"]
 ```
 
 ---
@@ -85,6 +86,7 @@ npx anyone-can-architect install --lang zh
 | `/aca-walkthrough` | 用业务语言带你走读设计文档，当场修正问题 |
 | `/aca-implement` | 按设计文档构建代码与测试 |
 | `/aca-review` | 审查当前范围的设计文档或代码 |
+| `/aca-test` | 按实现或改动影响范围选取并运行最小化测试 |
 | `/aca-repo-audit` | 检查全仓的断链、矛盾及文档与代码的偏移 |
 | `/aca-release` | 将已验证的版本合入 main 并打 Tag |
 | `/aca-feedback` | 规则不适合你的项目时，提交 GitHub Issue |

package/SSOT.md

@@ -32,6 +32,11 @@
 
 - [RFC 9110 (HTTP Semantics)](https://www.rfc-editor.org/rfc/rfc9110): Defines HTTP semantics, including methods, status codes, fields, safety, and idempotency
 - [OWASP API Security Top 10](https://owasp.org/API-Security/): Summarizes common API security risks, including authorization, authentication, resource consumption, and configuration issues
+- [Socket.IO Event Types](https://socket.io/docs/v4/typescript/): Defines how to declare client and server events by direction, with type declarations and runtime validation taking separate responsibilities
+- [Socket.IO Events and Acknowledgements](https://socket.io/docs/v4/emitting-events/): Defines bidirectional events, acknowledgements, and timeouts
+- [Socket.IO Client Options](https://socket.io/docs/v4/client-options/) and [Namespaces](https://socket.io/docs/v4/namespaces/): Define the connection path, namespaces, and how clients connect
+- [Socket.IO Connection Authentication](https://socket.io/docs/v4/middlewares/): Defines how auth credentials are passed and how connection rejections are reported
+- [Socket.IO Delivery Guarantees](https://socket.io/docs/v4/delivery-guarantees/): Defines the default message delivery guarantees and where the application must add its own guarantees
 
 ## 7 Platforms and Tools
 

package/VERSION

@@ -1 +1 @@
-0.2.0
+0.4.0

package/axioms/README.md

@@ -8,4 +8,4 @@
 | Writing | [writing.md](writing.md) | design "Doc Writing" chapter<br>walkthrough / review / repo-audit body<br>Top of each doc design | Doc structure, concepts and references, chapters and sections, lines and tables, characters — "how to write" |
 | Completeness (Boil the Ocean) | [boil-the-ocean.md](boil-the-ocean.md) | specify "Solution Design" chapter | If you can achieve 100%, do not settle for 80% |
 
-Skill-level axioms apply only to skills with design responsibilities, implement / release / feedback handle execution only and receive no injection
+Skill-level axioms apply only to skills with design responsibilities, implement / test / release / feedback handle execution only and receive no injection

package/axioms/writing.md

@@ -7,7 +7,7 @@
 - Present the whole first, then expand on the details, see the [Pyramid Principle](../SSOT.md#2-structure)
 - When stating a judgment, give the conclusion first, then the supporting evidence
 - Merge heading levels that add no information
-- Use numbered lists for items with a sequence or priority, and indent multiple attributes under each item
+- Use numbered lists for items with a sequence or priority; when a step contains sub-items, start the step with a bold phrase stating its purpose and indent specific operations and conditional branches under it
 - Use tables only for content with multiple rows of the same structure, more than two attributes per row, and no sequence between rows
 - Write list items as complete sentences
 - When an item has branches, indent the branches under that item
@@ -26,6 +26,8 @@
 - Remove content that adds no information and does not help understanding
 - Write one sentence per line, with only one fact per sentence
 - State actions directly in operational steps
+- If a specific practice fully expresses a constraint, write the practice directly
+- Keep prohibitions that no specific practice can fully express
 - Write sequential actions as separate items
 - Make the actor, the object of the action, and the referents clear
 - Do not repeat actors, objects of actions, or referents already clear from context

package/dist/antigravity/aca/SKILL.md

@@ -43,8 +43,9 @@ flowchart TD
 | `/aca-specify` | Reason through new requirements or improve existing designs, then proceed to Design after confirming the solution |
 | `/aca-design` | Write and check design docs within the current scope, then determine the next scope or complete the overall closeout |
 | `/aca-walkthrough` | Walk through design docs in business language, confirm design decisions unit by unit, and correct identified issues on the spot after confirmation |
-| `/aca-review` | Determine the review subject and scope, review the design or check implementation compliance with the design, without modifying the docs or code under review |
-| `/aca-implement` | Plan the file structure based on the design, then implement and verify code and tests according to module dependencies |
+| `/aca-review` | Determine the review subject and scope, statically review the design or the overall code structure, without modifying the docs or code under review or running code |
+| `/aca-implement` | Plan the file structure based on the design, then write production code and test code according to module dependencies |
+| `/aca-test` | Select and run minimal tests based on the current implementation scope or the design boundary crossed by changes, testing only without modifying files |
 | `/aca-repo-audit` | Check repository documentation and verify the implementation as needed, with read-only access and no changes |
 | `/aca-release` | Close out according to the repository release workflow, merge into main, and lock in an annotated Tag |
 | `/aca-feedback` | Collect deviations from governance rules and submit an Issue after explicit authorization |

package/dist/antigravity/aca-design/SKILL.md

@@ -22,7 +22,7 @@ Change only documentation, not code
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.gemini/config/skills/aca/SSOT.md#2-structure)
 - When stating a judgment, give the conclusion first, then the supporting evidence
 - Merge heading levels that add no information
-- Use numbered lists for items with a sequence or priority, and indent multiple attributes under each item
+- Use numbered lists for items with a sequence or priority; when a step contains sub-items, start the step with a bold phrase stating its purpose and indent specific operations and conditional branches under it
 - Use tables only for content with multiple rows of the same structure, more than two attributes per row, and no sequence between rows
 - Write list items as complete sentences
 - When an item has branches, indent the branches under that item
@@ -41,6 +41,8 @@ Change only documentation, not code
 - Remove content that adds no information and does not help understanding
 - Write one sentence per line, with only one fact per sentence
 - State actions directly in operational steps
+- If a specific practice fully expresses a constraint, write the practice directly
+- Keep prohibitions that no specific practice can fully express
 - Write sequential actions as separate items
 - Make the actor, the object of the action, and the referents clear
 - Do not repeat actors, objects of actions, or referents already clear from context
@@ -167,11 +169,13 @@ If neither the repo-type spec nor the document set specifies an order, arrange w
      Keep plain text in headings, code blocks, Mermaid labels, and product copy
 4. Synchronize affected test designs
    - Identify affected black-box and white-box test designs based on contracts, flows, and internal mechanisms added, revised, or deleted in this round
+   - Against the confirmed design, check the affected existing test code, fixtures, and the behavior they actually verify
    - Update test designs in sequence according to the corresponding doc designs and [test cases](~/.gemini/config/skills/aca/doc-design/patterns/testcase.md)
      1. Update fixtures
      2. Update test scenarios and their references to design rationale
      3. Update test cases based on the scenarios
         Add missing cases, revise changed cases, and delete or replace invalid cases
+   - Leave actual changes to test code and fixtures to `/aca-implement`
    - If only wording is revised and verified behavior has not changed, check that test designs and references remain valid
    - If solution decisions or as-is evidence required for test design are missing, handle them under §3
    - If affected docs are outside the current scope, record their locations and the content that needs synchronization
@@ -256,8 +260,10 @@ Perform the following steps after writing and scope checks are complete for all
    After all applicable checks pass, commit only actual closeout changes, then push to the remote
    If there are no actual changes, do not create an empty commit, and push existing commits from this round
    If committing or pushing is not possible, record completed work, incomplete actions, and the resumption point, and report incomplete under §8
-5. Continue to review
-   After all closeout requirements are complete, the next step is `/aca-review`
+5. Determine whether design review is needed and continue
+   After all closeout requirements are complete, check whether the design in this round is cross-module (involving multiple modules, the project-level architecture, the module division, or cross-module interfaces and collaboration contracts)
+   - Cross-module: the next step is `/aca-review` for a design review
+   - Not cross-module (only changes inside a single module or local design changes): skip design review and go directly to the next step (`/aca-implement` when this round needs code, or `/aca-release` according to the confirmed version progression plan when this round changes only design docs)
 
 ## 8 Output
 
@@ -275,16 +281,16 @@ Perform the following steps after writing and scope checks are complete for all
 
    | Item | Result |
    | --- | --- |
-   | Scope | <current scope and progress in this round> |
+   | Scope | <current scope, progress in this round, and whether it is cross-module> |
    | Inputs | <solution or as-is state and actual sources> |
    | Docs | <files added, revised, moved, or deleted / none> |
    | Checks | <actual results, basis for reuse, and unverified items> |
    | Commits | <commit and push results / not committed> |
    | Pending | <incomplete items, reasons, and resumption point / none> |
-   | Next step | <target skill and pending scope / fill corresponding gaps / none> |
+   | Next step | </aca-review after cross-module closeout, /aca-implement or /aca-release directly after non-cross-module closeout, or fill corresponding gaps> |
    ```
 
 3. Determine the next step
-   After this round is fully closed out, the next step is `/aca-review`
+   After this round is fully closed out, continue to `/aca-review`, `/aca-implement`, or `/aca-release` according to whether the design is cross-module, as in step 5 of 7.2
    If the current scope is complete but another scope remains, determine the next path under 7.1
    If work is incomplete, fill the corresponding gaps, and do not judge Design complete solely because files have been written

package/dist/antigravity/aca-implement/SKILL.md

@@ -3,12 +3,11 @@ name: aca-implement
 description: |
   1. Set implementation goals and completion criteria based on the design
   2. Plan the responsibilities and structure of source code and test files based on module boundaries and internal design
-  3. Orchestrate implementation and verification tasks by module dependencies
+  3. Orchestrate implementation tasks by module dependencies
   4. Create all directories and file placeholders according to the plan
-  5. Assign sub-agents by module dependencies, implement in parallel wherever possible, and run black-box and white-box tests
-  6. Commit the corresponding changes after each module passes verification
-  7. Integrate the commits of verified modules
-  8. Complete overall verification and check the completion criteria for the goal
+  5. Assign sub-agents by module dependencies and write production code along with black-box and white-box test code in parallel wherever possible
+  6. Commit the corresponding changes and integrate after each module is complete
+  7. Check the completion criteria for the goal and hand off to review and testing
   Change only code and tests
 ---
 <!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
@@ -16,22 +15,21 @@ description: |
 
 # aca-implement
 
-Implement code and tests according to the design docs for the current scope
-Change only code and tests, not design docs
+Write production code and test code according to the design docs for the current scope
+Change only code and tests, without modifying design docs or running tests
 
 ## 1 Principles
 
 1. **Goal-driven**
    Use confirmed delivery goals to determine the implementation scope and task priorities
-   Use completion criteria and their verification evidence to determine whether the goals are met
+   Judge implementation completion by coverage of the design requirements
 2. **Dependency-driven parallelism**
    Use dependencies to determine the implementation order
-   Run tasks in parallel wherever possible when their dependencies are satisfied and they have no shared resource conflicts
-3. **Test-driven**
-   Use external contracts and internal design to determine test expectations
-   Drive implementation with tests and use both black-box and white-box tests to verify design requirements
-4. **Scope constraints**
-   Keep implementation and refactoring within the confirmed design scope
+   Advance tasks in parallel wherever possible when their dependencies are satisfied and they have no file conflicts
+3. **Code and tests in sync**
+   Write production code along with black-box and white-box test code in sync based on external contracts, internal design, and test design
+4. **Write only, no test execution**
+   Write or modify code and tests only during implementation, and hand off test execution to `/aca-test`
 
 ## 2 Workflow
 
@@ -41,14 +39,9 @@ flowchart TD
     Plan --> Prepare["Implementation Preparation · §4"]
     Prepare --> Implement["Implementation and Integration · §5"]
     Implement -- All remaining tasks are blocked and no tasks are in progress --> Report
-    Implement --> Modules{All module tasks are complete and integrated}
+    Implement --> Modules{All module tasks for the current scope are complete and integrated}
     Modules -- No --> Implement
-    Modules -- Yes --> Verify["Overall Verification · §6"]
-    Verify --> Complete{All completion criteria for the current scope are verified as satisfied}
-    Complete -- No, the design is clear and fixes are possible within the current scope --> Implement
-    Complete -- No, remaining verification can continue --> Verify
-    Complete -- No, remaining fixes or verification are blocked --> Report
-    Complete -- Yes --> Report(["Output and Next Step · §7"])
+    Modules -- Yes --> Report(["Output and Next Step · §6"])
 ```
 
 ## 3 Goals and Task Orchestration
@@ -57,49 +50,55 @@ Read the design docs, project configuration, existing code, and tests for the cu
 Check the workspace state and recent commits to verify current implementation progress and existing changes
 Preserve existing changes outside the scope of this implementation
 
-1. List deliverables and their completion criteria based on the confirmed design and implementation scope
-2. Compare delivery requirements with existing code and tests, and list what to reuse, modify, add, or remove
-3. List the tests to run for this implementation based on the black-box and white-box test designs
-   Specify the environments and fixtures these tests require
-4. List the modules involved in this implementation and their dependencies based on the design
-   Modules include submodules at all levels: top-level modules come from architecture, and submodules come from the internal composition of their direct parent's class-design
-5. Specify whether each test uses real dependencies or test doubles based on the test design
-   Check the readiness of required dependencies
-6. Plan the source code and test file structure based on module boundaries, internal design, and repository conventions
-   List all source code and test directories and files within the current implementation scope
-7. Specify each file's responsibilities, owning module, and dependencies
-   Check whether each file has a single responsibility and whether responsibilities overlap
-   Adjust file boundaries when responsibilities are not singular or overlap
-8. Split implementation preparation, module implementation, integration, and overall verification into tasks
-   Use modules in the design as the smallest units of implementation, verification, and commits
-   When submodules exist, create separate tasks for each submodule and the parent's composition implementation, with the parent task depending on all its submodule tasks
-9. Specify each task's dependencies, owner, and completion criteria
-10. Use the goal or task management capabilities provided by the current AI Agent environment to maintain the overall goal and task progress
-    Record each task's status: pending implementation, in progress, complete, or blocked
-    Record verification evidence and the next action for each task
-    When resuming a task, check task records, the workspace, and recent commits
-    Update task status based on the findings and continue implementation
+1. **Specify deliverables and completion criteria**
+   - List deliverables and their completion criteria based on the confirmed design and implementation scope
+2. **Compile the code and test change list**
+   - Compare delivery requirements with existing code and tests, and list what to reuse, modify, add, or remove
+   - Correct or remove outdated or wrong test cases and fixtures according to the confirmed design
+   - When changing test expectations, base the change on the confirmed design or a verified test error
+3. **Orchestrate the corresponding test scope**
+   - List the test cases and fixtures to write or update in this run based on the black-box and white-box test designs
+   - Record the units under test and test case scope corresponding to the current implementation scope for direct execution by `/aca-test`
+4. **Identify modules and dependencies**
+   - List the modules involved in this implementation and their dependencies based on the design
+   - Modules include submodules at all levels: top-level modules come from architecture, and submodules come from the internal composition of their direct parent's class-design
+5. **Plan the source code and test file structure**
+   - Plan the source code and test file structure based on module boundaries, internal design, and repository conventions
+   - List all source code and test directories and files within the current implementation scope
+6. **Check file responsibilities and boundaries**
+   - Specify each file's responsibilities, owning module, and dependencies
+   - Check whether each file has a single responsibility and whether responsibilities overlap
+   - Responsibilities are not singular or overlap: adjust file boundaries
+7. **Split module implementation and integration tasks**
+   - Split implementation preparation, module implementation, and integration into tasks
+   - Use modules in the design as the smallest units of implementation and commits
+   - When submodules exist, create separate tasks for each submodule and the parent's composition implementation, with the parent task depending on all its submodule tasks
+   - Specify each task's dependencies, owner, and completion criteria
+8. **Maintain task status and progress**
+   - Use the goal or task management capabilities provided by the current AI Agent environment to maintain the overall goal and task progress
+   - Record each task's status: pending implementation, in progress, complete, or blocked
+   - When resuming a task, check task records, the workspace, and recent commits, update task status, and continue implementation
 
 ## 4 Implementation Preparation
 
-1. Add all missing source code and test directories and file placeholders for the current scope according to the plan
-   Reuse existing files directly and create new files as empty files
-   Delete files explicitly marked for removal in the plan only after verifying that they no longer serve a valid responsibility
-   When a file's purpose, dependencies, or deletion scope cannot be confirmed, retain it and verify with the developer
-   Start module implementation only after all file placeholders are in place
-2. The main agent assigns separate workspaces to sub-agents
-   Allocate test resources according to the test design to ensure parallel tasks do not interfere with each other
-   Synchronize the prepared file structure to each workspace
-3. Provide each sub-agent with the following task context
+1. **Create directories and file placeholders**
+   - Add all missing source code and test directories and file placeholders for the current scope according to the plan
+   - Reuse existing files directly and create new files as empty files
+   - Delete files explicitly marked for removal in the plan only after verifying that they no longer serve a valid responsibility
+   - File purpose, dependencies, or deletion scope cannot be confirmed: retain the file and verify with the developer
+   - Start module implementation only after all file placeholders are in place
+2. **Assign separate workspaces**
+   - The main agent assigns separate workspaces to sub-agents
+   - Synchronize the prepared file structure to each workspace
+3. **Dispatch task context to sub-agents**
    - The overall implementation goal, the functionality to complete for the current module, and the scope of changes
    - Links to relevant chapters covering the structural basis, interfaces, internal design, and test cases for the current module and its dependencies
      The structural basis for top-level modules is architecture, and the structural basis for submodules is the internal composition of the parent's class-design
    - The readiness of each dependency and the arrangements for real dependencies or test doubles in tests
    - The workspace path, starting commit, files permitted for modification, and applicable repository conventions
-   - Test environments and fixtures, verification commands, and module completion criteria
-   - Change only code and tests
+   - Modify only production code and test code, without modifying design docs or running tests
    - Follow the [Exception Handling](#52-exception-handling) requirements
-   - Return changed files, commit records, verification commands and results, unverified items, and reasons for blockers
+   - Return changed files, commit records, corresponding test scope, and reasons for blockers
 
    When files owned by other tasks or shared files are involved, first ask the main agent to coordinate
 
@@ -107,64 +106,53 @@ Preserve existing changes outside the scope of this implementation
 
 ### 5.1 Implementation Loop
 
-1. The main agent selects module tasks whose dependencies are satisfied
-   Assign tasks that can run in parallel to sub-agents
-2. Implement and verify each module according to the test design
-   1. Prepare and run tests
-      Reuse, write, or update black-box and white-box tests for the module's current scope according to the design
-      When new or changed design requirements are not yet implemented, confirm that the corresponding tests fail
-      For refactoring that preserves behavior, first run the corresponding tests to establish a verification baseline
-   2. Complete and verify changes within the module's current scope according to the design
-      Follow repository conventions for implementation details not specified by the design
-      When the repository has no corresponding conventions, use the simplest implementation that meets the design
-      When the design includes a Lark (Feishu) card mockup, implement it according to [Lark Card Mapping](~/.gemini/config/skills/aca/skills/references/lark-card-mapping.md)
-      Run module tests and confirm that all pass
-   3. Refactor as needed and verify again
-      After refactoring, rerun module tests and confirm that all pass
-   When an unexpected test failure occurs and the design is clear, fix the code and rerun the affected tests
-3. Check black-box and white-box test results and other completion criteria for the module's current scope
-   Once all criteria are satisfied, stage and commit only the current task's changes
-4. The main agent checks module commits and verification evidence
-   Integrate the module's commits after confirming that it meets the completion criteria
-   Run tests for affected modules and integration tests between modules on the integrated code
-5. The main agent updates task status, verification evidence, and dependency readiness
-   Record the reasons for blocked tasks and the conditions for resuming them
-   Synchronize integrated dependency commits that have passed verification to module workspaces that require real dependencies
-   If tasks remain that can be implemented, return to step 1
-   If no tasks can be assigned and tasks are still in progress, wait for execution results
-   After all module tasks are complete and integrated, proceed to [Overall Verification](#6-overall-verification)
-   If all remaining tasks are blocked and no tasks are in progress, report the incomplete status according to [Output](#7-output)
+1. **Dispatch parallelizable module tasks**
+   - The main agent selects module tasks whose dependencies are satisfied and assigns tasks that can run in parallel to sub-agents
+2. **Write module production code and test code**
+   - Reuse, write, or update black-box and white-box test code and fixtures for the module's current scope according to the design
+   - Complete production code changes within the module's current scope according to the design
+   - Follow repository conventions for implementation details not specified by the design, or use the simplest implementation that meets the design when the repository has no corresponding convention
+   - When the design includes a Lark (Feishu) card mockup, implement it according to [Lark Card Mapping](~/.gemini/config/skills/aca/skills/references/lark-card-mapping.md)
+   - Organize code structure as needed to keep responsibilities singular and boundaries clear
+3. **Check module completion criteria and commit**
+   - Check that interface contracts, internal mechanisms, and black-box and white-box test code for the module's current scope are all written according to the design
+   - Stage and commit only the current task's changes
+4. **Integrate module commits**
+   - The main agent checks the file scope and completion status of module commits
+   - Integrate the module's commits after confirming that it meets the completion criteria
+5. **Update progress and advance**
+   - The main agent updates task status, implemented module scope, and dependency readiness
+   - Record the reasons for blocked tasks and the conditions for resuming them
+   - Synchronize integrated dependency commits to downstream module workspaces
+   - Tasks remain that can be implemented: return to step 1
+   - No tasks can be assigned and tasks are still in progress: wait for execution results
+   - All module tasks for the current scope are complete and integrated: proceed to [Output](#6-output)
+   - All remaining tasks are blocked and no tasks are in progress: report the incomplete status according to [Output](#6-output)
 
 ### 5.2 Exception Handling
 
-1. When the design is missing, contains conflicts, or cannot be implemented, the agent executing the task pauses affected tasks
-   Sub-agents report the issue and its scope of impact to the main agent
-   The main agent verifies the issue and its scope of impact, then reports them to the developer
-   When the solution needs additions or revisions, recommend using `/aca-specify`
-   Continue unaffected independent tasks
-2. When issues are found in other repositories, the main agent verifies them and reports the issues and their impact to the developer
-   Do not modify other repositories without authorization
-
-## 6 Overall Verification
-
-After all module tasks are complete and integrated, the main agent performs overall verification for the current delivery scope
-Run module tests, integration tests, system tests, builds, and static checks according to the implementation plan
-Execute the test cases specified in the design and verify the runtime results of the subject under test
-Passing builds or static checks cannot replace behavioral test results
-
-When issues are found for which the design is clear and fixes are possible within the current scope, return to [Implementation and Integration](#5-implementation-and-integration)
-Rerun affected verification after fixes
-Check each completion criterion against the overall goal
-Update task records with verification results and unverified items
-
-## 7 Output
-
-When all completion criteria for the current scope are verified as satisfied, mark the goal and tasks as complete
-If incomplete, report remaining work, reasons for blockers, and actions to resume
-After this implementation is complete, use `/aca-review` to review the implementation within this scope
-Provide Review with the overall goal, corresponding design, implementation scope, and comparison baseline
-Identify the commits and uncommitted changes under review, and provide verification results and evidence
-Use the following format for the final report, filling in the title and results according to the actual status
+1. **Handle missing or conflicting designs**
+   - When the design is missing, contains conflicts, or cannot be implemented, the agent executing the task pauses affected tasks
+   - Sub-agents report the issue and its scope of impact to the main agent
+   - The main agent verifies the issue and its scope of impact, then reports them to the developer
+   - When the solution needs additions or revisions, recommend using `/aca-specify`
+   - Continue unaffected independent tasks
+2. **Handle cross-repository issues**
+   - When issues are found in other repositories, the main agent verifies them and reports the issues and their impact to the developer
+   - Do not modify other repositories without authorization
+
+## 6 Output
+
+1. **Update the task status**
+   - All completion criteria for the current scope are satisfied: mark the goal and task status as complete
+   - Completion criteria are not satisfied: report remaining work, reasons for blockers, and actions to resume
+2. **Check for module and code structure changes and determine the next step**
+   - Check whether the changes are cross-module or change a module's overall code structure (module structure, overall code distribution, function construction)
+   - Cross-module or the module's overall code structure changed: use `/aca-review` to run an implementation review on this scope, then go to `/aca-test` after the review passes
+   - Only inside a module, with no change to the module's overall code structure (such as internal module logic, local function implementation, or test details): skip implementation review and go directly to `/aca-test`
+   - Provide the following `/aca-review` or `/aca-test` with the overall goal, corresponding design, implementation scope, orchestrated test scope, and comparison baseline, and identify the commits and uncommitted changes in this run
+3. **Output the implementation report**
+   Use the following format for the final report, filling in the title and results according to the actual status
 
 ```markdown
 # 🛠️ Implement: <complete / incomplete>
@@ -173,11 +161,11 @@ Use the following format for the final report, filling in the title and results
 | --- | --- |
 | Goal | <overall goal and completion criteria satisfaction> |
 | Scope | <implementation scope and module progress> |
-| Changes | <main implementation changes> |
-| Verification | <test execution, build, and static check results> |
-| Unverified | <unverified scope / none> |
+| Changes | <main production code and test code changes> |
+| Structural change | <yes (cross-module or module's overall code structure changed) / no (only internal module logic or local changes)> |
+| Test scope | <units under test and test case scope orchestrated for /aca-test> |
 | Commits | <commit records / uncommitted> |
 | Blockers | <blockers and reasons / none> |
 | Recommendations | <extension recommendations / none> |
-| Next step | <one immediately actionable step> |
+| Next step | </aca-review when there is a structural change, /aca-test directly when changes are only inside a module with no structural change> |
 ```

package/dist/antigravity/aca-release/SKILL.md

@@ -97,14 +97,10 @@ If execution cannot continue in Chapters 4 through 7, report completed facts, th
 1. Run `bash ~/.gemini/config/skills/aca/bin/aca-release-notify-check .` to check the announcement configuration
    Record the check result and the corresponding configuration location
 2. Act on the check result
-
-   | Result | Action |
-   | --- | --- |
-   | `NOTIFY_NONE` | Record that no transport is configured and continue the release |
-   | `NOTIFY_WIRED` | Record the platform and consumer point and continue the release |
-   | `NOTIFY_UNWIRED` | Stop and report that the announcement does not use `aca-tag-notify-extract <tag>` to extract content, then check again after the configuration is corrected |
-   | Unable to complete the check | Stop and report the reason and resume conditions |
-
+   - `NOTIFY_NONE`: record that no transport is configured and continue the release
+   - `NOTIFY_WIRED`: record the platform and consumer point and continue the release
+   - `NOTIFY_UNWIRED`: stop and report that the announcement does not use `aca-tag-notify-extract <tag>` to extract content, then check again after the configuration is corrected
+   - Unable to complete the check: stop and report the reason and resume conditions
 3. Use the configuration check result for the [Announcement Cross-Check](#72-cross-check-the-release-announcement)
    Check again after the configuration is corrected
    The configuration check confirms that the summary is integrated
@@ -201,9 +197,9 @@ If execution cannot continue in Chapters 4 through 7, report completed facts, th
    Cross-check that the Anyone Can Architect footer matches the current Anyone Can Architect version, immediately follows the repository version line, and is the last line
    Cross-check that the final commit contains the complete design, implementation, and tests for this scope
 3. Complete final verification
-   Complete the verification required by the repository release workflow on the final commit
+   Complete the verification required by the repository release workflow and the `/aca-test` test scope on the final commit
    Record verification results and the corresponding commit
-   When reusing existing results, state which reuse conditions are met and the basis for their correspondence to the final commit
+   When reusing existing `/aca-test` or verification results, state which reuse conditions are met and the basis for their correspondence to the final commit
    If artifacts are involved, cross-check their traceability to this commit
    Verification artifacts cannot replace evidence of completed delivery
 4. Determine whether release locking is allowed
@@ -305,15 +301,11 @@ Release announcements are generated from the NOTIFY block in the annotated Tag
 1. Locate the delivery results
    Use the [announcement configuration](#33-announcement-configuration) and the repository release workflow to find tasks, logs, or delivery receipts for this Tag
 2. Record the delivery status based on evidence
-
-   | Status | Basis for determination |
-   | --- | --- |
-   | Sent | Evidence of successful delivery for this Tag |
-   | Pending delivery | Confirmed to still be waiting or in progress |
-   | Delivery failed | An explicit failure result |
-   | Unconfirmed | Insufficient evidence to determine the delivery status |
-   | Transport not configured | Configuration checks confirm that no delivery mechanism is configured |
-
+   - Evidence of successful delivery for this Tag exists: mark as sent
+   - The task is confirmed to still be waiting or in progress: mark as pending delivery
+   - An explicit delivery failure result exists: mark as delivery failed
+   - Evidence is insufficient to determine the delivery status: mark as unconfirmed
+   - Configuration checks confirm that no delivery mechanism is configured: mark as transport not configured
 3. Handle follow-up actions
    If delivery fails, recover or resend according to repository conventions
    If the status is unconfirmed, report the missing evidence
@@ -368,7 +360,8 @@ Select one immediately executable action based on the incomplete items
 | Execution conditions are missing | Meet the conditions, then check the status against [release preparation](#3-release-preparation) and resume |
 | The design solution still needs reasoning | `/aca-specify` Reason through the solution |
 | The revision solution is clear and only doc changes are needed | `/aca-design` Revise the docs |
-| Implementation issues | `/aca-implement` Fix and verify |
+| Implementation issues | `/aca-implement` Fix code or tests |
+| Tests or final verification incomplete | `/aca-test` Run verification, then resume the release |
 | Merge conflicts | Resolve and commit the conflicts, then rerun the [pre-merge audit](#43-pre-merge-audit) |
 | Push, cleanup, or announcement is still incomplete | Resume from the corresponding incomplete step |
 | Everything is complete and no follow-up items remain | Report that there are no pending tasks |