@xulthekl/team-flow 0.28.0 → 0.28.1

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

@@ -1,3 +1,3 @@
-# team-flow v0.28.0 | 阶段: {{state}} | 工作流: {{workflow}}
+# team-flow v0.28.1 | 阶段: {{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.28.1",
       "source": "./",
       "author": {
         "name": "LT",

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "team-flow",
-  "version": "0.28.0",
+  "version": "0.28.1",
   "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.28.1",
   "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.28.1"
   },
   "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.28.1",
   "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.28.1"
   },
   "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.28.1",
       "source": ".",
       "author": {
         "name": "LT",

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.28.1 | 阶段: {{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.28.1**。
 
 ---
 

package/README.md

@@ -1,6 +1,6 @@
 # team-flow
 
-> 当前版本：`v0.28.0`
+> 当前版本：`v0.28.1`
 
 > 统一插件：**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,18 @@ 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
+## 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 +71,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 +106,20 @@ 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
 
 **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/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)