anyone-can-architect 0.2.0 → 0.4.0

package/dist/codex/aca-test/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: aca-test
+description: Select and run minimal tests based on the current implementation or change blast radius, testing only without modifying files
+---
+<!-- AUTO-GENERATED from SKILL.md.tmpl — do not edit directly -->
+<!-- Regenerate: bash scripts/build-skills.sh --host codex -->
+
+# aca-test
+
+Select and run the corresponding minimal tests based on the current implementation scope or the design boundary crossed by changes
+Run tests and verification only, without modifying design docs, production code, or test code
+
+## 1 Principles
+
+1. **Blast-Radius Scoping**
+   Determine the minimal test scope from the contract boundaries and dependencies of the current implementation or changes
+2. **Test Only, No Edits**
+   Run tests and verify results only, without modifying design docs, production code, or test code
+3. **Evidence Binding**
+   Bind test results to the commit under test, test scope, and commands actually executed for direct reuse by downstream stages
+
+## 2 Workflow
+
+```mermaid
+flowchart TD
+    Start([Receive test request]) --> Scope["Determine test scope · §3"]
+    Scope --> Reuse{"Result reuse conditions met? · §3"}
+    Reuse -- Yes --> Report(["Output and next step · §5"])
+    Reuse -- No --> Ready{"Test environment and prerequisites ready? · §3"}
+    Ready -- No --> Report
+    Ready -- Yes --> Run["Run tests and recheck anomalies · §4"]
+    Run --> Report
+```
+
+## 3 Determine Test Scope
+
+1. **Identify the subject under test and scope of changes**
+   - Developer or upstream caller has specified the scope to test: use that scope directly
+   - Scope not specified: read current workspace changes and recent commits, and locate the modules, commands, or events to which the changes belong against the design docs
+   - Record the commit under test and any uncommitted changes included in verification
+2. **Select the minimal test set by the design boundary crossed by changes**
+   - Only internal implementation of a module, command, or event is added or modified, and the module `interface`, command routing, and event dispatch contracts are unchanged: select only the unit's own white-box and black-box tests
+   - Module `interface`, command routing, event dispatch, or cross-unit collaboration is modified: select this unit's tests, tests of modules or commands and events that call this contract, and black-box tests in project-level `testcase` whose design basis links to this unit
+   - Shared foundation across modules such as common infrastructure, global configuration, data migration, build, or deployment is modified: select all affected tests and the corresponding environment verification
+   - When the repository `release` doc specifies additional verification for the current scope, include it as well
+3. **Check reuse conditions and execution environment**
+   - Existing test results cover the selected scope and the content under test, test code, fixtures, configuration, and dependency environment have not changed: reuse the results directly, record the basis, and proceed to [Output and Next Step](#5-output-and-next-step)
+   - Test execution required: check the readiness of the required environment, fixtures, and real dependencies or test doubles according to the test design
+   - Environment or dependencies not ready: record the missing conditions and report incomplete according to [Output and Next Step](#5-output-and-next-step)
+
+## 4 Run and Recheck
+
+1. **Control concurrency and resource isolation**
+   - Set up fixtures and an isolated environment according to the test design
+   - When shared or heavy resources such as containers, databases, real platforms, or model evaluations are involved, limit concurrency and isolate resources to prevent timeouts caused by parallel contention
+2. **Run the selected tests**
+   - Run the test cases selected in [Determine Test Scope](#3-determine-test-scope) along with required builds or static checks
+   - After execution completes, clean up test data and temporary resources created in this run according to the fixture rules
+   - Do not modify design docs, production code, test code, or commit history during verification
+3. **Recheck failures and distinguish causes**
+   - All pass: record the executed commands, number of passing test cases, and elapsed time
+   - Failures occur: against the confirmed design, check the failure logs, test cases, fixtures, and implementation
+   - Suspected timeout caused by high host load or resource contention: rerun the failed items individually under low-concurrency isolated conditions to verify
+   - Individual rerun passes consistently and is confirmed to be caused by environment load: record the initial anomaly, rerun command, and passing result
+   - The implementation deviates from the design: report an implementation issue, and identify the failing test cases and the corresponding implementation locations
+   - Test expectations are outdated or the tests or fixtures are wrong: report a test issue, and identify the corresponding design basis and error locations
+   - The design is missing or contracts conflict: mark the corresponding verification as incomplete, and hand it to `/aca-specify` or `/aca-design`
+   - Environment failure or diagnostics cannot be verified: mark the corresponding verification as incomplete and record the reason
+
+## 5 Output and Next Step
+
+### 5.1 Verdict
+
+| Verdict | Criteria |
+| --- | --- |
+| Pass | All tests and required checks in the selected scope pass (including reused results or timeout rechecks), with no failing or incomplete items |
+| Fail | Confirmed code or test failures exist |
+| Incomplete | The design is missing, contracts conflict, the environment is missing, execution is impossible, or diagnostics cannot be verified, and no confirmed failures exist |
+
+When both confirmed failures and incomplete items exist, the verdict is fail, and the incomplete items must be listed
+
+### 5.2 Test Report
+
+Output the test results in the current conversation using the following template
+
+```markdown
+# 🧪 Test: <pass / fail / incomplete>
+
+| Item | Result |
+| --- | --- |
+| Scope | <unit or change scope under test> |
+| Baseline | <commit under test and uncommitted changes included in verification> |
+| Selection basis | <upstream scope / intra-unit tests with unchanged contract / dependency-chain tests for contract change / full tests for global foundation> |
+| Commands | <actual test and check commands run, or basis for reuse> |
+| Result | <pass count, fail count, and elapsed time> |
+| Anomaly recheck | <individual rerun verification result for timeouts / none> |
+| Failures | <failing test cases, causes, and corresponding locations / none> |
+| Incomplete | <unexecuted verification, reasons, and conditions for resuming / none> |
+| Next step | <one immediately actionable step> |
+```
+
+### 5.3 Follow-Up Actions
+
+Select the next step based on the test verdict and progress in the current round
+
+| Verdict | Situation | Next step |
+| --- | --- | --- |
+| Incomplete | Test environment, fixtures, or external dependencies are missing | Supply the environment conditions and verify again through `/aca-test` |
+| Fail | Code or test implementation issues | Fix through `/aca-implement` (verify again directly through `/aca-test` when the code structure is unchanged, or review through `/aca-review` before running `/aca-test` when the code structure changes) |
+| Incomplete | Missing design or contract conflict | Revise the design through `/aca-specify` or `/aca-design` |
+| Pass | Subsequent implementation tasks remain in this round | Continue implementing the next scope through `/aca-implement` |
+| Pass | All implementation scopes in this round have passed verification | Proceed to `/aca-release` according to the version progression plan or conclude the current task |

package/dist/codex/aca-walkthrough/SKILL.md

@@ -33,7 +33,7 @@ Confirm design decisions unit by unit and correct identified issues on the spot
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.codex/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
@@ -52,6 +52,8 @@ Confirm design decisions unit by unit and correct identified issues on the spot
 - 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
@@ -98,7 +100,7 @@ flowchart TD
    If it still cannot be located, ask the developer to specify the doc location
    Read `~/.codex/skills/aca/doc-design/repo-types/{repo-type}.md`
    Read `CONTEXT.md` and the design docs in the current scope
-   Read the corresponding document set, doc design, and patterns actually used
+   Read the corresponding document set and doc design, and read relevant patterns as needed
 4. Arrange the walkthrough order
    Follow the governance order in the repo-type spec
    Within a document set, follow the order specified by that document set
@@ -152,14 +154,15 @@ flowchart TD
 
 ### 4.2 Discuss and Cross-Check
 
-1. First explain the problems and requirements the current unit must address in business language
-   Then explain how the design meets these requirements
-   When business concepts are involved, link to the corresponding entries in the project's `CONTEXT.md`
-   Explain each concept's meaning and role in the current design
-2. Cross-check the design of the current unit
-   Cross-check each applicable checklist item in the document set, doc design, and patterns actually used
-   When walking through the overall doc structure, discuss chapter and section divisions, content placement, and presentation order against the corresponding Doc Design
-   Identify content that needs to be merged, split, or reordered
+1. **Walk through the current unit in business language**
+   - First explain the problems and requirements the current unit must address, then explain how the design meets these requirements
+   - Business concepts are involved: link to the corresponding entries in the project's `CONTEXT.md`, and explain each concept's meaning and role in the current design
+2. **Cross-check organization and expression**
+   - Walking through the overall doc structure: explain chapter and section divisions, content placement, and presentation order against the corresponding doc design, and propose content to merge, split, or reorder
+   - Walking through a Chapter or Section: against the expression requirements of the corresponding doc design and the applicable scenarios in `~/.codex/skills/aca/doc-design/patterns/`, tell the developer whether the current form of expression fits the content, without keeping existing code, tables, or diagrams by default
+   - The current form of expression does not fit: first propose a replacement, split, or combined form of expression to the developer and read the selected pattern, without patching the original expression locally
+3. **Cross-check each checklist item**
+   - Cross-check each checklist item in the document set, doc design, and selected patterns that applies to the current unit
 
    | Check item | Focus |
    | --- | --- |
@@ -167,14 +170,14 @@ flowchart TD
    | Completeness | Omissions in responsibilities, behavior, boundaries, and exception handling |
    | Ambiguity and implementation uniqueness | Multiple reasonable interpretations, implementations that match the description but behave differently, and unresolved design decisions |
    | Redundancy | Duplicate maintenance and content that adds no information |
-   | Expression | Writing axiom, corresponding doc design, and terminology consistency |
+   | Expression | Choice and fit of the form of expression, writing axiom, corresponding doc design, and terminology consistency |
 
 ### 4.3 Confirm, Revise, and Check
 
-1. Ask the developer to confirm the current unit's design decisions
+1. Ask the developer to confirm the current unit's design decisions and changes to the form of expression
    If the developer does not understand or disagrees, clarify the meaning and rationale
    If not yet confirmed, continue discussing the current unit according to [Discuss and Cross-Check](#42-discuss-and-cross-check)
-2. When changes are confirmed, revise on the spot according to the corresponding doc design
+2. When changes are confirmed, revise on the spot according to the corresponding doc design and selected patterns
    When chapters or sections change, also update affected references and related designs
 3. After revision, rerun affected checklist items and mechanical checks
    Report the corrections and check results
@@ -243,4 +246,5 @@ Choose one immediately executable action based on completion status and progress
 | --- | --- | --- |
 | Incomplete | Units still await a walkthrough or verification conditions are missing | Meet the conditions, then continue this walkthrough through `/aca-walkthrough` |
 | Incomplete | The design solution cannot be determined this round | Use `/aca-specify` to reason through the solution |
-| Complete | The walkthrough of the current scope is complete | Review the design through `/aca-review` according to the confirmed arrangements |
+| Complete | The walkthrough of the current scope is complete, and the design in this round is cross-module | Review the design through `/aca-review` |
+| Complete | The walkthrough of the current scope is complete, and the design in this round is not cross-module | Go directly to the next step (`/aca-implement` when code is needed, `/aca-release` when only design docs change) |

package/dist/cursor/aca/SKILL.md

@@ -44,8 +44,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/cursor/aca-design/SKILL.md

@@ -23,7 +23,7 @@ Change only documentation, not code
 - Present the whole first, then expand on the details, see the [Pyramid Principle](~/.cursor/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
@@ -42,6 +42,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
@@ -168,11 +170,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](~/.cursor/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
@@ -257,8 +261,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
 
@@ -276,16 +282,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/cursor/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
 disable-model-invocation: true
 ---
@@ -17,22 +16,21 @@ disable-model-invocation: true
 
 # 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
 
@@ -42,14 +40,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
@@ -58,49 +51,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
 
@@ -108,64 +107,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](~/.cursor/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](~/.cursor/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>
@@ -174,11 +162,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> |
 ```