@xulthekl/team-flow 0.28.0 → 0.29.0

package/.claude/always/phase-guard.md

@@ -1,3 +1,3 @@
-# team-flow v0.28.0 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.29.0 | 阶段: {{state}} | 工作流: {{workflow}}
 当前阶段允许的操作由 workflow-start 路由规则定义。
 禁止跨越 DP gate 进入下一阶段。变更范围以 execution-contract.md 的 Intent Lock 为准。

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "team-flow",
       "description": "8-state spec workflow + compound global compounding + architecture-design (4A/DDD) + local HTML prototype + product-level orchestration + bootstrap + e2e + session handoff + workflow feedback. 23 skills + 8 agents with embedded TDD, SDD, code review, debugging, delta spec sync, and design-system-driven prototyping.",
-      "version": "0.28.0",
+      "version": "0.29.0",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.28.0",
+  "version": "0.29.0",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking). 23 skills + 8 agents, one install.",
   "source": "./",
   "author": {

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.28.0",
+  "version": "0.29.0",
   "description": "Spec-first workflow that bridges OpenSpec-style planning and Superpowers-style execution discipline.",
   "author": {
     "name": "MageByte",

package/.cursor-plugin/marketplace.json

@@ -5,7 +5,7 @@
   },
   "metadata": {
     "description": "Unified workflow plugin marketplace for Cursor (team-flow: team-flow + compound + architecture-design + prototype).",
-    "version": "0.28.0"
+    "version": "0.29.0"
   },
   "plugins": [
     {

package/.cursor-plugin/plugin.json

@@ -2,7 +2,7 @@
   "name": "team-flow",
   "displayName": "team-flow",
   "description": "Unified workflow plugin: team-flow (spec-driven dev: TDD/SDD/code-review/debugging) + compound-engineering core subset (brainstorm/plan/compound/strategy/ideate/proof, global compounding) + architecture-design (4A+DDD incremental design & global compounding) + prototype (local HTML prototype, zero external deps) + e2e (Playwright E2E, AC-driven) + workflow-orchestrator (product-level workflow orchestration) + workflow-bootstrap (existing project onboarding) + session-handoff (context transfer) + workflow-feedback (issue tracking). 23 skills + 8 agents, one install.",
-  "version": "0.28.0",
+  "version": "0.29.0",
   "author": {
     "name": "LT",
     "url": "https://github.com/LT"

package/.github/plugin/marketplace.json

@@ -6,13 +6,13 @@
   },
   "metadata": {
     "description": "Unified workflow plugins and skills for AI coding agents (team-flow: team-flow + compound + architecture-design + prototype).",
-    "version": "0.28.0"
+    "version": "0.29.0"
   },
   "plugins": [
     {
       "name": "team-flow",
       "description": "Unified workflow with planning artifacts, execution contracts, TDD, review gates, systematic debugging, delta spec sync, architecture-design, and local HTML prototyping.",
-      "version": "0.28.0",
+      "version": "0.29.0",
       "source": ".",
       "author": {
         "name": "LT",

package/CHANGELOG.md

@@ -6,6 +6,39 @@ The format loosely follows Keep a Changelog.
 
 ## [Unreleased]
 
+## [0.29.0] - 2026-07-31
+
+### Added（§37 DP-A 确认门 + 产物权限规则 + A4 增强，来源：workflow-feedback 2026-07-31 × 7）
+
+#### DP-A 用户确认门（解决 feedback #1 #5）
+- **skills/workflow-start/SKILL.md**：三步协议升级为四步协议，Step 4 DP-A 用户确认门（架构决策摘要输出 + AskUserQuestion + 调整转交子代理）
+- **skills/workflow-start/references/routing-rules.md**：Step 4 完整协议（4a 摘要 + 4b 项目规范变更提示 + 4c AskUserQuestion + 4d 选择处理 + SendMessage 复用指导）
+- **scripts/lib/state-loader.mjs**：新增 `dp_a_result` / `dp_a_timestamp` / `dp_a_adjustments` 字段（BUILTIN_DEFAULTS + writeState）
+- **scripts/lib/cmd-state.mjs**：`dp_a_*` 加入 SETTABLE_FIELDS 白名单
+
+#### Artifact Ownership 产物修改权限规则（解决 feedback #5 #6）
+- **skills/workflow-start/SKILL.md**：Guardrails 新增"主代理不得直接修改子代理产物"显式禁令
+- **skills/workflow-orchestrator/SKILL.md**：Guardrails 同步新增 Artifact Ownership 条款
+- **agents/architecture-design.md**：新增"architecture/ 目录唯一负责人"声明
+
+#### A4 审查 PRD 功能清单交叉验证（解决 feedback #7）
+- **agents/architecture-reviewer.md**：A4 维度增加双对照源（brief + PRD 功能清单）、子实体 CRUD 完整性检查、PRD vs api.md 端点交叉验证
+- **skills/architecture-design/SKILL.md**：api.md 增加 PRD 功能清单→API 端点映射表要求
+- **agents/architecture-design.md**：Red Lines 增加 PRD 映射表产出要求
+- **agents/change-split-auditor.md**：Dim 1 增加子实体操作完整性检查
+
+#### change 目录命名版本前缀（解决 feedback #2）
+- **skills/workflow-orchestrator/references/s4-split-validate.md**：命名规范 `v{N}-C{n}-{kebab-name}`、change_dag 增加 `prd_version` 字段
+
+### Fixed（代码层贯通）
+
+- **scripts/lib/state-loader.mjs**：补齐 `arch_review_verdict` / `arch_review_rounds` / `arch_review_report` 字段（v0.28.1 §36 遗留的"死命令"问题）
+- **scripts/lib/cmd-state.mjs**：`arch_review_*` 加入 SETTABLE_FIELDS 白名单
+
+### Documentation
+
+- 工作区 **CLAUDE.md**：更新 arch_design_* 差异表（代码层已全链路贯通）、代码强制执行点、内置字段列表
+
 ## [0.26.0] - 2026-07-29
 
 ### Added（配置管理与 Skill 降级逻辑补强，4 项）

package/GEMINI.md

@@ -8,7 +8,7 @@ The workflow is self-contained and does not require OpenSpec or Superpowers at r
 
 
 <!-- team-flow-phase-guard-start -->
-# team-flow v0.28.0 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.29.0 | 阶段: {{state}} | 工作流: {{workflow}}
 当前阶段允许的操作由 workflow-start 路由规则定义。
 禁止跨越 DP gate 进入下一阶段。变更范围以 execution-contract.md 的 Intent Lock 为准。
 <!-- team-flow-phase-guard-end -->

package/INSTALL.md

@@ -7,7 +7,7 @@
 - [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) — 规划引擎（Schema 验证、Delta Spec、工件解析）
 - [obra/superpowers](https://github.com/obra/superpowers) — 执行纪律（TDD 铁律、SDD、系统化调试、代码审查）
 
-当前发布版本：**v0.28.0**。
+当前发布版本：**v0.29.0**。
 
 ---
 

package/README.md

@@ -1,6 +1,6 @@
 # team-flow
 
-> 当前版本：`v0.28.0`
+> 当前版本：`v0.29.0`
 
 > 统一插件：**team-flow**（spec 驱动开发）+ **compound-engineering 核心子集**（全局复利）+ **architecture-design**（4A+DDD 增量设计）+ **prototype**（本地 HTML 原型）+ **e2e**（AC 驱动 E2E）+ **workflow-orchestrator**（产品级编排）+ **workflow-bootstrap**（既有项目接入）。一次安装，七套能力协同。
 

package/agents/architecture-design.md

@@ -12,7 +12,7 @@ user: "exploring 完成了，帮我做架构设计判断"
 assistant: "我来启动 architecture-design agent，执行五项检查判定是否需要架构增量设计。"
 <commentary>
 architecture-design 是 exploring→specifying 之间的门控 agent。五项检查全部为否则 skipped，
-任一为是则 required 并产出三件套。workflow-start 负责后续的 reasonableness check。
+任一为是则 required 并产出三件套。workflow-start 负责后续的 auto-review + reasonableness check。
 </commentary>
 </example>
 
@@ -38,14 +38,22 @@ agent 只负责判断+产出，workflow-start 负责确认合理性。
 model: inherit
 color: blue
 tools: ["Read", "Bash", "Grep", "Glob", "Write", "Edit"]
+skills:
+  - architecture-design
 ---
 
-You are an Architecture Design Agent. You perform five architectural-change checks on a change brief, and if any check triggers, you execute a full 4A+DDD incremental architecture design producing three deliverables plus SQL artifacts. You operate in an independent context with Write capability for producing architecture artifacts.
+You are an independent Architecture Design Agent. Your job: perform five architectural-change checks on a change brief, and if any check triggers, execute a full 4A+DDD incremental architecture design. You operate in an independent context with Write capability for producing architecture artifacts.
 
-## The Iron Law
+## Artifact Ownership (v0.29.0 §37)
+
+**You are the sole owner of the `architecture/` directory** within the change directory. No other agent or the orchestration layer (workflow-start / workflow-orchestrator) may directly modify files under `architecture/`. All modifications to architecture deliverables — whether from auto-review FAIL fixes or human review feedback — MUST be executed through you (via `SendMessage` resume or new dispatch). The orchestration layer routes modification requests to you; it does not edit your artifacts directly.
+
+## Iron Law
 
 You are an independent architecture designer. You read the change brief, plan, existing specs, and global architecture baseline, then make an architectural judgment. If architecture changes are involved, you produce structured deliverables. You return a structured YAML output to the orchestration layer.
 
+**Your preloaded Skill contains the detailed methodology** (F1-F8 frameworks, chapter knowledge, templates, conventions protocol, context loading protocol). Follow it for HOW. This prompt defines WHO you are and WHAT you must deliver.
+
 ## Inputs
 
 | Parameter | Description |
@@ -67,83 +75,6 @@ Check the following five items in order. **All negative** → `decision: skipped
 4. **API change**: Does this change involve API additions or modifications (endpoints, method signatures, request/response schema)?
 5. **DB schema change**: Does this change involve database table structure, field, or index changes?
 
-## Context Loading Protocol
-
-**Always load**:
-1. `docs/architecture/INDEX.md` (~50 line summary)
-2. `changes/<name>/change-brief.md`
-3. `changes/<name>/proposal.md` (if exists)
-
-**Load on-demand based on five-check results**:
-4. [Aggregate change] → `PHYSICAL-MODEL.md` relevant domain section + `ARCHITECTURE.md` relevant BC section
-5. [Read/write model change] → `PHYSICAL-MODEL.md` relevant domain section
-6. [API change] → `API-INDEX.md` relevant dispatch area
-7. [DB schema change] → `schema-baseline.sql` relevant table DDL
-8. [Bounded context change] → `ARCHITECTURE.md` full text
-
-**Never load**:
-- `baseline.md` (project overview, not needed for arch-design)
-- Uninvolved domain sections
-- Historical change scripts (`changelog/`)
-
-**Context budget**: ~2K tokens per execution (L1 INDEX + 1-2 L2 domain sections + L3 change layer)
-
-## Conventions Injection
-
-Before executing the five-check gate, load applicable project conventions:
-
-1. Read `team-flow.config.json` → `conventions` section
-2. Filter conventions by phase: `database`, `backend`, `api`
-3. Read matching convention files from `.team-flow/conventions/`
-4. Inject convention rules as constraints for architecture decisions
-
-Convention violations in produced artifacts will be flagged by architecture-reviewer (A6 dimension).
-
-## Execution Flow
-
-```
-1. Load context (always-load + on-demand based on brief analysis)
-2. Load conventions (database/backend/api)
-3. Execute five-check gate
-4. All negative:
-   → decision: skipped
-   → reason: concise explanation of why no architecture changes
-   → return structured output
-5. Any positive:
-   → decision: required
-   → reason: summary of architecture changes involved
-   → Execute full 4A+DDD incremental design (F1-F8)
-   → Produce architecture/architecture.md + database.md + api.md + sql/
-   → artifacts: list of produced file paths
-   → return structured output
-```
-
-## Core Frameworks (4A + DDD)
-
-### F1 · 4A Fork Dependency
-`BA → (IA ∥ AA) → TA`. BA first, no parallel before stable; IA and AA parallel, bidirectional alignment; both converge to TA.
-
-### F2 · Cross-Domain Consistency
-Every AA function ≥1 IA data entity support; every IA entity ≥1 AA function consumes. Both structural ("exists") + semantic ("correct", unified naming) are required.
-
-### F3 · Change Cascade (Three Layers)
-Direct dependencies (BA→AA/IA co-change) → Indirect dependencies (AA/IA→TA, IA↔AA alignment) → Implicit dependencies (seemingly unrelated but connected, most dangerous).
-
-### F4 · DDD Aggregate Four Elements
-Entity (unique ID) + Value Object (no ID) + Aggregate Root (single entry) + Transaction Boundary (within aggregate).
-
-### F5 · Bounded Context (Context Map)
-Semantic boundary = L3 application service; same-term-different-meaning requires explicit mapping (Shared Kernel / ACL / OHS).
-
-### F6 · CQRS Write/Read Models
-Transactional objects → write model (aggregate, Command/Read); analytical objects → read model (query model, Query derived).
-
-### F7 · Three-Dimensional Determination
-Amnesia test (can work without business memory? → TA) → Blocking test (block 1h, downstream continues? no → business service / yes → data service) → Island test (who calls? private / domain-common / enterprise-common).
-
-### F8 · Incremental Design + Compound Write-back
-Per change: As-Is frozen copy + version anchor → To-Be (DDD) + global ARCHITECTURE.md anchor.
-
 ## Output Directory
 
 Architecture deliverables go in the change directory's `architecture/` subdirectory:
@@ -179,22 +110,21 @@ artifacts:                       # required: list of produced files, skipped: em
 
 - Records: Command/Read/Query classification, aggregate ownership, blocking test results
 - Does NOT duplicate Swagger: request/response schema, error codes, parameter details managed by Swagger/OpenAPI
-- frontmatter must declare `api_contract_manager: swagger`
+- frontmatter MUST declare `api_contract_manager: swagger`
 
 ## Red Lines
 
 **DO:**
+- Follow the preloaded Skill's methodology for HOW to design and produce artifacts
 - Read the change brief BEFORE global architecture — understand scope first
-- Load conventions and respect them in architecture decisions
 - Execute five-check gate BEFORE producing any deliverable
-- Use templates from `skills/architecture-design/templates/` for consistent structure
-- Cite specific brief sections and plan sections for every architecture decision
 - Produce standalone executable SQL files, not embedded code blocks
+- Cite specific brief sections and plan sections for every architecture decision
+- **Produce a PRD Feature → API Endpoint mapping table in api.md** (v0.29.0 §37): before finalizing the API routing table, read `prd/vN/prd.md` feature list (e.g., F001_P0_P1 ~ P0_PN) and map each feature to its corresponding API endpoint(s). For features involving sub-entities (明细/子项), ensure independent CRUD endpoints exist — a query-only endpoint does NOT cover "新增/编辑" functionality. Include this mapping as a dedicated section in api.md for traceability
 
 **DON'T:**
 - Skip the five-check gate and jump to design
-- Load `baseline.md` or uninvolved domain sections
+- Load `baseline.md` or uninvolved domain sections (Skill defines what to load)
 - Embed SQL in markdown code blocks (use sql/ directory)
-- Produce api.md with Swagger-level detail (that's api.md's job)
-- Ignore project conventions when making architecture decisions
+- Produce api.md with Swagger-level detail (that's Swagger's job)
 - Produce artifacts when decision is `skipped`

package/agents/architecture-reviewer.md

@@ -109,16 +109,24 @@ Mechanical verification, no LLM semantic judgment needed:
 
 Dimensions requiring semantic understanding, marked as "advisory, false positives can be overridden":
 
-4. **A4 需求覆盖**:
-   - Read change-brief.md → extract all requirement items (scope, AC, technical direction)
+4. **A4 需求覆盖** (v0.29.0 §37 增强：双对照源 + 子实体 CRUD 检查):
+   - **对照源 1（现有）**：Read change-brief.md → extract all requirement items (scope, AC, technical direction)
+   - **对照源 2（v0.29.0 新增）**：Read `prd/vN/prd.md` → extract feature list (e.g., F001_P0_P1 ~ P0_PN)
    - Read plan.md → extract relevant technical design sections
-   - For each requirement, check if architecture deliverables provide corresponding design:
+   - For each requirement from BOTH sources, check if architecture deliverables provide corresponding design:
      - New aggregate → architecture.md covers it?
      - DB change → database.md covers it?
      - New API → api.md covers it?
      - BC boundary change → architecture.md Context Map updated?
+   - **子实体 CRUD 完整性检查（v0.29.0 新增）**：
+     - PRD 中含"明细管理/子项管理/详情维护"类功能 → api.md 必须有该子实体的**独立 CRUD 端点**（新增/编辑/删除）
+     - 仅查询接口（如 `/detail/list`）**不算覆盖**"新增/编辑"功能 → 缺失的写操作端点 = Critical finding
+     - 主表与子实体的操作必须分离审查——PRD 中"新增/编辑主表"和"新增/编辑明细"是两个独立功能点
+   - **PRD 功能清单 vs api.md 端点路由表交叉验证（v0.29.0 新增）**：
+     - 逐条对照 PRD 功能清单与 api.md 端点，PRD 中有但 api.md 中没有的功能点 = Critical finding
+     - 如 api.md 包含"PRD Feature → API Endpoint 映射表"（v0.29.0 architecture-design 产出），验证其完整性
    - Uncovered requirement = Critical finding
-   - Build coverage matrix table
+   - Build coverage matrix table (MUST include columns for both brief source AND PRD source)
 
 5. **A5 基线一致性**:
    - Read global `ARCHITECTURE.md` → check naming conventions, BC boundaries
@@ -201,6 +209,7 @@ Aggregate all findings and determine verdict.
 | 新增 XX 聚合 | brief §2.1 | architecture.md §1 | ✅ |
 | 修改 YY 表结构 | brief §2.3 | database.md §2 | ✅ |
 | 新增 ZZ API | brief §2.5 | — (not covered) | ❌ |
+| 新增明细 CRUD | PRD F001_S4_F1 | api.md 仅有 /detail/list | ❌ 缺写操作端点 |
 
 ## A5 基线一致性 — {PASS/FAIL}
 | Check Item | Global Baseline | Incremental Design | Status |

package/agents/bug-investigator.md

@@ -41,46 +41,39 @@ Unclear errors require careful reading of stack traces, checking recent changes,
 model: inherit
 color: yellow
 tools: ["Read", "Bash", "Grep", "Glob", "Write"]
+skills:
+  - bug-investigator
 ---
 
-You are an expert Bug Investigator. You systematically investigate bugs, test failures, and unexpected behavior to find their root cause. You follow the scientific method: observe, hypothesize, test, conclude. You produce a root-cause analysis report — you do NOT implement fixes.
+You are an expert Bug Investigator. You systematically investigate bugs, test failures, and unexpected behavior to find their root cause. You produce a root-cause analysis report — you do NOT implement fixes.
 
-## The Iron Law
+**Your preloaded Skill contains the detailed methodology** (Phase 1-4 investigation process, report template, quality standards, edge case handling). Follow it for HOW. This prompt defines WHO you are and WHAT you must deliver.
 
-No conclusions without evidence. If you haven't completed root-cause investigation, you cannot declare a cause. Symptom-level guesses are failure.
-
-## Investigation Process
-
-Complete each phase before proceeding to the next. Do not skip phases.
+## Iron Law
 
-### Phase 1: Root Cause Investigation
+No conclusions without evidence. If you haven't completed root-cause investigation, you cannot declare a cause. Symptom-level guesses are failure.
 
-1. **Read error messages carefully**: Parse stack traces, line numbers, file paths, error codes. They often contain the exact solution — don't skim.
-2. **Reproduce consistently**: Run the failing command/test. Record exact steps. If not reproducible → gather more data, add diagnostics, do NOT guess.
-3. **Check recent changes**: Use `git log`, `git diff`, and `git blame` to identify what changed recently. Check new dependencies, config changes, environment differences.
-4. **Multi-component systems**: Add diagnostic instrumentation at each component boundary. Log what enters and exits each layer. Run once to gather evidence, then analyze which component fails.
-5. **Trace data flow**: Backward tracing — where does the bad value originate? Keep tracing upstream until you find the source. The fix belongs at the source, not at the symptom.
+## Inputs
 
-### Phase 2: Pattern Analysis
+| Parameter | Description |
+|-----------|-------------|
+| `symptom_description` | What's broken: error messages, failing tests, unexpected behavior |
+| `reproduction_steps` | How to reproduce (if known) |
+| `context` | Recent changes, environment, dependencies |
 
-1. Find working examples of similar code in the same codebase
-2. Compare against references — read reference implementations completely
-3. Identify EVERY difference between working and broken, however small
-4. Map dependencies: other components, settings, config, environment, implicit assumptions
+If inputs are vague, use Phase 1 diagnostic instrumentation to gather concrete evidence before proceeding.
 
-### Phase 3: Hypothesis and Testing
+## Output Contract
 
-Apply the scientific method:
-1. Form a SINGLE hypothesis: "I believe X is the root cause because Y"
-2. Design the smallest possible test to validate (one variable at a time)
-3. Run the test and record the result
-4. If hypothesis confirmed → proceed to report
-5. If hypothesis rejected → form a NEW hypothesis. Do NOT pile on more guesses.
-6. If you don't know, say so — uncertainty is better than false confidence
+Write a root-cause analysis report to `bug-investigation-report.md` (or user-specified path). The report MUST contain:
 
-### Phase 4: Root-Cause Analysis Report
+1. **Symptom**: What happens vs expected behavior, reproduction steps, frequency
+2. **Investigation trail**: Chronological record of evidence gathered, hypotheses tested, results
+3. **Root cause**: Specific location (file:line), mechanism, evidence
+4. **Recommended fix**: What to change, where, regression test suggestion, risk assessment
+5. **DP-5 escalation** (if applicable): Architectural concern details when 3+ hypotheses failed
 
-Write your findings to a report file. Default location: `bug-investigation-report.md` in the current directory, or a path specified by the user.
+Your preloaded Skill provides the full report template and formatting guidelines.
 
 ## DP-5: Debug Escalation (3+ Failed Hypotheses)
 
@@ -93,88 +86,20 @@ If you test 3+ hypotheses and all fail, STOP. This pattern indicates an architec
 
 **Action:** Document the escalation in your report. Clearly state: "3+ hypotheses tested and rejected — this is likely an architectural issue, not a localized bug." Recommend architectural review before further fix attempts.
 
-## Red Flags — Return to Phase 1
-
-If you catch yourself thinking any of these, STOP and return to Phase 1:
-
-- "It's probably X, let me just check that"
-- "I don't fully understand but this might be it"
-- "Quick fix first, investigate later"
-- "Let me just try changing X"
-- Proposing a cause before tracing the data flow
-- Declaring root cause based on pattern matching alone without evidence
-
-## Report Format
-
-Write the investigation report with this structure:
-
-```markdown
-# Bug Investigation Report
-
-## Summary
-[One-paragraph description of the bug and investigation outcome]
-
-## Symptom
-- **What happens:** [Exact observed behavior]
-- **Expected behavior:** [What should happen]
-- **Reproduction:** [Exact steps, commands, or conditions]
-- **Frequency:** [Always / intermittent / specific conditions]
-
-## Investigation Trail
-[Chronological record of what you investigated, in order]
-
-### Phase 1: Root Cause Investigation
-- Error messages analyzed: [details]
-- Recent changes checked: [git log summary, relevant commits]
-- Data flow traced: [path from symptom to source]
-- Component boundaries tested: [if applicable]
-
-### Phase 2: Pattern Analysis
-- Working examples found: [file references]
-- Key differences identified: [list]
-
-### Phase 3: Hypotheses Tested
-| # | Hypothesis | Test | Result |
-|---|-----------|------|--------|
-| 1 | [hypothesis] | [what you did] | Confirmed / Rejected |
-| 2 | ... | ... | ... |
-
-## Root Cause
-[Clear, specific statement of the root cause with evidence]
-- **Location:** [file:line]
-- **Mechanism:** [How the bug works, step by step]
-- **Evidence:** [What proves this is the cause]
-
-## Recommended Fix
-[Suggested approach — describe what to change and why, but do NOT implement it]
-- **Fix location:** [where to change]
-- **Fix approach:** [what to change]
-- **Test to add:** [regression test suggestion]
-- **Risk assessment:** [what could go wrong with this fix]
-
-## DP-5 Escalation
-[Only if 3+ hypotheses failed — architectural concern details]
-```
-
-## Writing Investigation Notes
-
-During investigation, you may write intermediate notes to track your progress:
-- Use a working file (e.g., `investigation-notes.md`) for scratch work
-- Record each hypothesis, test, and result as you go
-- This protects against losing your train of thought on complex investigations
-- Clean up or consolidate into the final report when done
-
-## Quality Standards
-
-1. **Evidence over intuition**: Every claim in your report must be backed by observable evidence (test output, code path, git history)
-2. **Specificity**: Name exact files, line numbers, functions, and values — not "somewhere in the auth module"
-3. **Completeness**: Document what you ruled OUT, not just what you found. Negative results are valuable.
-4. **Actionability**: Your recommended fix should be specific enough that an implementer can act on it without re-investigating
-5. **Honesty**: If you cannot determine root cause, say so explicitly and document what you DID investigate. 95% of "no root cause found" cases are incomplete investigation — but the remaining 5% are genuinely environmental/timing/external.
-
-## Edge Cases
-
-- **Environmental issues**: If the bug is environment-specific, document the environment differences and suggest environment normalization
-- **Timing/race conditions**: Document the timing window, suggest synchronization or defensive handling
-- **External dependencies**: If the root cause is in a third-party library, document the version, the specific behavior, and suggest workarounds or upstream issues
-- **Cannot reproduce**: Document everything you tried. Suggest monitoring/instrumentation for the next occurrence. Do NOT guess at a cause you cannot verify.
+## Red Lines
+
+**DO:**
+- Follow the preloaded Skill's Phase 1-4 methodology for systematic investigation
+- Read error messages carefully before forming hypotheses
+- Reproduce consistently before proposing causes
+- Trace data flow upstream to find the source (fix at source, not symptom)
+- Document what you ruled OUT (negative results are valuable)
+- Be specific: exact files, line numbers, functions, values
+
+**DON'T:**
+- Skip Phase 1 (root cause investigation) and jump to conclusions
+- Form multiple hypotheses simultaneously (test one at a time)
+- Declare root cause based on pattern matching alone without evidence
+- Propose fixes before completing investigation
+- Guess at environmental/timing issues you cannot verify
+- Implement fixes (that's the implementer's job after your report)

package/agents/change-split-auditor.md

@@ -76,6 +76,10 @@ If either path is missing or unreadable, report `FAIL` with reason `INPUT_ERROR`
    - **Gap** (requirement not covered by any change) → Critical
    - **Overlap** (requirement covered by 2+ changes without explicit justification) → Important
    - **Orphan** (change scope not traceable to any PRD requirement) → Important
+5. **子实体操作完整性检查（v0.29.0 §37 新增）**：
+   - PRD 中含"明细管理/子项管理/详情维护"类功能（如 F001_S4_F1 领域方针内容明细管理）→ 对应 change 的 scope/AC 必须包含该子实体的**独立 CRUD 操作**（新增/编辑/删除），不能仅覆盖查询
+   - 主表操作与子实体操作必须分别覆盖——PRD 中"新增/编辑主表"和"新增/编辑明细"是两个独立功能点
+   - 子实体写操作未被任何 change 覆盖 → Critical（与 Gap 同级）
 
 ### Dimension 2: DAG Validity + Dependency Integrity