speccrew 0.6.61 → 0.6.63

package/.speccrew/skills/speccrew-knowledge-bizs-dispatch-xml/SKILL.md

@@ -330,11 +330,31 @@ Continue with knowledge base generation?
     </block>
 
     <block type="loop" id="S1b-L1" over="${platforms}" as="platform" parallel="true" max-concurrency="${max_concurrent_workers}" desc="Generate Feature inventory for each platform IN PARALLEL">
-      <!-- Step 1: Read platform mapping config -->
-      <block type="task" id="S1b-B1" action="run-script" status="pending" desc="Read platform mapping config">
-        <field name="command">node "${ide_skills_dir}/speccrew-knowledge-bizs-init-features/scripts/generate-inventory.js"</field>
-        <field name="arg">--entryDirsFile</field>
-        <field name="arg">${sync_state_bizs_dir}/entry-dirs-${platform.platformId}.json</field>
+      <!-- Step 1: Dispatch Worker to generate feature inventory -->
+      <block type="task" id="S1b-B1" action="dispatch-to-worker" status="pending" desc="Dispatch Worker to generate feature inventory">
+        <field name="worker">speccrew-knowledge-bizs-init-features-xml</field>
+        <field name="instructions">
+Generate feature inventory for the specified platform by analyzing entry directories.
+
+Requirements:
+- Read entry-dirs JSON file to get module entry directories
+- Scan source files in each entry directory
+- Generate features JSON with feature metadata
+- Output to features-{platformId}.json in sync_state_bizs_dir
+        </field>
+        <field name="context">{
+  "platformId": "${platform.platformId}",
+  "platformName": "${platform.platformName}",
+  "platformType": "${platform.platformType}",
+  "platformSubtype": "${platform.platformSubtype}",
+  "sourcePath": "${platform.sourcePath}",
+  "techIdentifier": "${platform.techIdentifier}",
+  "entryDirsFile": "${sync_state_bizs_dir}/entry-dirs-${platform.platformId}.json",
+  "outputDir": "${sync_state_bizs_dir}",
+  "workspace_path": "${workspace_path}",
+  "sync_state_bizs_dir": "${sync_state_bizs_dir}",
+  "language": "${language}"
+}</field>
         <field name="output" var="features_${platform.platformId}"/>
       </block>
 

package/.speccrew/skills/speccrew-knowledge-bizs-identify-entries-xml/SKILL.md

@@ -104,7 +104,7 @@ For each platform, generates:
         <field name="platform_type" value="${platform.platformType}"/>
         <field name="platform_subtype" value="${platform.platformSubtype}"/>
         <field name="tech_stack" value="${platform.techStack}"/>
-        <field name="logic_backend" value="Find all directories containing *Controller.java or *Controller.kt files. These are API entry directories. Module name = the business package name of the entry directory"/>
+        <field name="logic_backend" value="Find all directories containing *Controller.java or *Controller.kt files. These are API entry directories. Module name = the business package name of the entry directory. CRITICAL: Group by DIRECTORY, not by individual controller files. If multiple controllers reside in the same directory, that is ONE module with that directory as entryDirs"/>
         <field name="logic_frontend_vue_react" value="Find views/ or pages/ directories. First-level subdirectories under these directories are business modules"/>
         <field name="logic_mobile_uniapp" value="Find first-level subdirectories under pages/. Plus top-level pages-* directories (module name = directory name without pages- prefix)"/>
         <field name="logic_mobile_miniprogram" value="Find first-level subdirectories under pages/ as modules"/>
@@ -161,8 +161,10 @@ For each platform, generates:
           - Each module in "modules" array MUST have exactly two fields: "name" (string) and "entryDirs" (array of strings)
           - For platforms with hierarchical directory structure (e.g. frontend views/system/user/), flatten into individual modules
           - Module names should use hyphen-separated composite names for sub-modules (e.g. "system-user", "system-role")
+          - Multiple modules MUST NOT share the same entryDirs value. If multiple business areas share the same directory, they belong to ONE module.
           - If the generated JSON does not match this format, you MUST regenerate it before proceeding
         </field>
+        <field name="text">Output is strictly the entry-dirs JSON file at the specified output path. Per xml-workflow-spec.md "Strict Block Adherence" rule, no extra files are permitted.</field>
       </block>
 
       <!-- Checkpoint: Persist Generated JSON -->
@@ -240,6 +242,37 @@ For each platform, generates:
 }
 ```
 
+### Module Granularity (CRITICAL)
+
+- **modules = directory-level groupings**, NOT file-level features
+- Each module represents a distinct source directory (or set of directories) containing entry files
+- **NEVER create multiple modules pointing to the SAME entryDirs** — if 10 controller files all reside in `module_admin/controller/`, that is ONE module named `admin` with entryDirs `["module_admin/controller"]`, NOT 10 separate modules
+- The downstream `generate-inventory.js` script handles file-level decomposition within each module's entryDirs — that is NOT the job of this skill
+- Module names should correspond to directory names, not individual file names
+- Typical module count for a medium project: 3-10 modules (not 30+)
+
+**Correct example** (directory-level):
+```json
+{
+  "modules": [
+    { "name": "admin", "entryDirs": ["module_admin/controller"] },
+    { "name": "ai", "entryDirs": ["module_ai/controller"] },
+    { "name": "bpm", "entryDirs": ["module_bpm/controller"] }
+  ]
+}
+```
+
+**WRONG example** (file-level — FORBIDDEN):
+```json
+{
+  "modules": [
+    { "name": "system-user", "entryDirs": ["module_admin/controller"] },
+    { "name": "system-config", "entryDirs": ["module_admin/controller"] },
+    { "name": "system-dept", "entryDirs": ["module_admin/controller"] }
+  ]
+}
+```
+
 ### Format Constraints
 
 - **MUST use `modules` array** — never use `businessModules`, `components`, or any alternative field name

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "speccrew",
-  "version": "0.6.61",
+  "version": "0.6.63",
   "description": "Spec-Driven Development toolkit for AI-powered IDEs",
   "author": "charlesmu99",
   "repository": {

package/workspace-template/docs/rules/xml-workflow-spec.md

@@ -482,6 +482,19 @@ Team Leader executes:
 7. **`rule level="forbidden"`** = immediate stop if violated
 8. **Input/Output blocks** define the contract — respect required parameters
 
+### Strict Block Adherence
+
+When executing an XML workflow, the Agent MUST strictly follow the block sequence defined in the workflow:
+
+1. **Only perform actions defined by blocks** — Every action the Agent takes must correspond to a specific block in the workflow. The Agent MUST NOT perform any actions not defined by the blocks.
+2. **Prohibited extra actions** include but are not limited to:
+   - Generating files not specified in block output paths (e.g. summary reports, analysis documents, logs)
+   - Running scripts or commands not defined in any block
+   - Creating intermediate/temporary files outside of block definitions
+   - Adding "bonus" analysis steps or documentation beyond what blocks require
+3. **Output scope** — The workflow's output is strictly limited to what is defined in `output` blocks or block-level output fields (`<field name="output">`). Any file or artifact not traceable to a block definition is considered an error.
+4. **When in doubt, don't do it** — If an action is not explicitly defined in any block, the Agent must skip it, even if it seems "helpful".
+
 ### Block Execution Announcement Protocol
 
 Before executing each `<block>`, the agent MUST announce the block being executed. The announcement format is: