@xulthekl/team-flow 0.22.4 → 0.23.0

package/skills/build-executor/task-reviewer-prompt.md

@@ -146,7 +146,7 @@ Subagent (general-purpose):
     command for the controller:
 
     ```bash
-    npx --yes --package @xulthekl/team-flow@0.22.4 tf execution review <change-dir> --wave [WAVE_ID] --base [BASE_SHA] --head [HEAD_SHA] --report [REVIEW_REPORT_FILE] --verdict <pass|fail>
+    npx --yes --package @xulthekl/team-flow@0.23.0 tf execution review <change-dir> --wave [WAVE_ID] --base [BASE_SHA] --head [HEAD_SHA] --report [REVIEW_REPORT_FILE] --verdict <pass|fail>
     ```
 
     Use `fail` for any Critical/Important finding. A repair must be re-reviewed

package/skills/ce-brainstorm/SKILL.md

@@ -54,12 +54,18 @@ These rules apply to every brainstorm, including the universal (non-software) fl
 
 Sub-agent dispatch is tiered by task shape, never hardcoded to a model name. When dispatching the Phase 1.1 grounding scout, the Phase 2.6 claim verifier, or the opt-in Slack researcher, read `references/model-tiers.md` for the tier definitions (extraction / generation / ceiling) and the degradation rule for platforms without per-agent model selection or with no subagent primitive at all.
 
+## Optional Inputs
+
+- `docs/ideation/*.md`（可选）：如果 ce-ideate 已产出 ideation artifact，读取作为 brainstorm 的起点。若文件不存在，则从用户提供的 feature description 获取输入。
+
 ## Feature Description
 
 The **feature description** is the input this skill was invoked with — what to explore, present in the current prompt or conversation, whether the user provided it directly or a calling skill passed it.
 
 **If no feature description was provided, ask the user:** "What would you like to explore? Please describe the feature, problem, or improvement you're thinking about."
 
+**If `docs/ideation/*.md` exists**, read it first and use its ranked ideation content as the starting point for the brainstorm.
+
 Do not proceed until you have a feature description from the user.
 
 **Session-settled decisions.** The invoking conversation, or a distilled brief passed as invocation input — from the user or a calling skill — may carry decisions already examined-and-chosen. Read `references/settled-decisions.md` before classifying conversation-carried decisions — it carries the settlement test, the two provenance classes, the annotation shape, and capture rules. Skipping the classification fails in both directions: re-asking a decision the user already made, or promoting an unexamined assertion to settled.

package/skills/code-reviewer/SKILL.md

@@ -16,7 +16,7 @@ Two responsibilities: requesting review (dispatching a reviewer subagent) and re
 1. Get SHAs: `BASE_SHA=$(git rev-parse HEAD~1)` and `HEAD_SHA=$(git rev-parse HEAD)`
 2. Dispatch `general-purpose` subagent using template at `skills/code-reviewer/code-reviewer-prompt.md`
 3. Fill placeholders: `[DESCRIPTION]` (what was built), `[PLAN_OR_REQUIREMENTS]` (contract/spec reference), `[BASE_SHA]`, `[HEAD_SHA]`, `[WAVE_ID]`, and a distinct `[REVIEW_REPORT_FILE]`.
-4. Require the reviewer to write a non-empty persisted review report at `[REVIEW_REPORT_FILE]`, then record that exact path in the wave receipt: `npx --yes --package @xulthekl/team-flow@0.22.4 tf execution review <change-dir> --wave <id> --base <sha> --head <sha> --report <review-report-path> --verdict <pass|fail>`.
+4. Require the reviewer to write a non-empty persisted review report at `[REVIEW_REPORT_FILE]`, then record that exact path in the wave receipt: `npx --yes --package @xulthekl/team-flow@0.23.0 tf execution review <change-dir> --wave <id> --base <sha> --head <sha> --report <review-report-path> --verdict <pass|fail>`.
 5. Act on feedback: Critical/Important findings require a `fail` receipt, focused repair, re-review, and replacement `pass` receipt before a dependent wave or closing can proceed. Note Minor for later, push back with reasoning if reviewer is wrong.
 
 ### Minimality And Scope
@@ -43,6 +43,10 @@ behavior-neutral redundancy; never score by line count.
 | Important | Architecture problems, missing features, poor error handling, test gaps | Fix before next batch |
 | Minor | Code style, optimization, documentation polish | Note for later |
 
+### Architecture Cross-Domain Consistency (v0.10 §28-§31)
+
+When `architecture/api.md` exists, verify the implementation against its **cross-domain consistency** section — specifically the API↔data entity alignment (Command/Read/Query routing vs actual DB entity usage). Flag mismatches as Important.
+
 ### Forbidden Responses
 Never: performative agreement ("You're right!", "Great point!"), blind implementation before verification, thanking the reviewer. Instead: restate the requirement, ask clarifying questions, push back with reasoning, or just fix it (actions > words).
 
@@ -72,7 +76,7 @@ Suggestion breaks existing functionality, reviewer lacks context, violates YAGNI
 | Performative agreement | State requirement or just act |
 | Blind implementation | Verify against codebase first |
 | Batch without testing | One at a time, test each |
-| Proceeding without a wave receipt | Record `pass`/`fail` via `npx --yes --package @xulthekl/team-flow@0.22.4 tf execution review` before the next dependent wave |
+| Proceeding without a wave receipt | Record `pass`/`fail` via `npx --yes --package @xulthekl/team-flow@0.23.0 tf execution review` before the next dependent wave |
 | Assuming reviewer is right | Check if breaks things |
 | Avoiding pushback | Technical correctness > comfort |
 | Partial implementation | Clarify all items first |

package/skills/code-reviewer/code-reviewer-prompt.md

@@ -93,7 +93,7 @@ Subagent (general-purpose):
     report path. End with the exact receipt command:
 
     ```bash
-    npx --yes --package @xulthekl/team-flow@0.22.4 tf execution review <change-dir> --wave [WAVE_ID] --base [BASE_SHA] --head [HEAD_SHA] --report [REVIEW_REPORT_FILE] --verdict <pass|fail>
+    npx --yes --package @xulthekl/team-flow@0.23.0 tf execution review <change-dir> --wave [WAVE_ID] --base [BASE_SHA] --head [HEAD_SHA] --report [REVIEW_REPORT_FILE] --verdict <pass|fail>
     ```
 
     Use `fail` when any Critical or Important finding remains. A repair needs

package/skills/contract-builder/SKILL.md

@@ -5,9 +5,9 @@ description: Convert approved planning artifacts into an execution contract. Inv
 
 # Contract Builder
 
-Converts planning artifacts into a single execution handshake: `execution-contract.md`. Load the baseline with `npx --yes --package @xulthekl/team-flow@0.22.4 tf runtime asset read templates/execution-contract.md`.
+Converts planning artifacts into a single execution handshake: `execution-contract.md`. Load the baseline with `npx --yes --package @xulthekl/team-flow@0.23.0 tf runtime asset read templates/execution-contract.md`.
 
-Read before generating: `proposal.md`, `specs/`, `design.md`, `tasks.md`, then load `docs/artifact-contract.md` with `npx --yes --package @xulthekl/team-flow@0.22.4 tf runtime asset read docs/artifact-contract.md`.
+Read before generating: `proposal.md`, `specs/`, `design.md`, `tasks.md`, then load `docs/artifact-contract.md` with `npx --yes --package @xulthekl/team-flow@0.23.0 tf runtime asset read docs/artifact-contract.md`.
 
 **Architecture Design Outputs (v0.9 §26)**: 若 `architecture/` 目录存在，同时读取 `architecture/architecture.md` / `database.md` / `api.md`，作为执行契约的架构约束补充输入——确保 execution-contract.md 的 Implementation Constraints 段包含架构设计的关键约束（聚合边界/CQRS 分流/API 契约/schema 变更）。`architecture/` 不存在时跳过。
 
@@ -38,8 +38,8 @@ Must make obvious: approved behavior, out-of-scope, constraints, batches, test o
 
 After drafting: summarize handoff rules, identify ambiguity, flag unmapped requirements, ask user to approve explicitly. After approval:
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_3_result "approved: <summary>"
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_3_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_3_result "approved: <summary>"
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_3_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 DP-3 is a hard gate — no implementation without this record.
 
@@ -60,9 +60,9 @@ Generate minimal contract: Intent Lock (one sentence), Task List (numbered), App
 
 ## Post-Generation
 
-Run `npx --yes --package @xulthekl/team-flow@0.22.4 tf state init <change-dir>` to create `.team-flow.yaml` with hashes.
+Run `npx --yes --package @xulthekl/team-flow@0.23.0 tf state init <change-dir>` to create `.team-flow.yaml` with hashes.
 
-For hotfix, after writing the minimal contract, run `npx --yes --package @xulthekl/team-flow@0.22.4 tf state init <change-dir>` or `npx --yes --package @xulthekl/team-flow@0.22.4 tf state rebuild <change-dir>` so `contract_hash` is recorded. DP-3 remains mandatory before build.
+For hotfix, after writing the minimal contract, run `npx --yes --package @xulthekl/team-flow@0.23.0 tf state init <change-dir>` or `npx --yes --package @xulthekl/team-flow@0.23.0 tf state rebuild <change-dir>` so `contract_hash` is recorded. DP-3 remains mandatory before build.
 
 ## Exception Handling
 

package/skills/need-explorer/SKILL.md

@@ -41,8 +41,8 @@ Restate what you heard: "Here's what I'm hearing: [problem, scope, non-goals, su
 
 After user confirms the summary:
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_1_result "confirmed: <one-line summary>"
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_1_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_1_result "confirmed: <one-line summary>"
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_1_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 DP-1 confirms scope, non-goals, and success criteria before artifact creation.
 

package/skills/release-archivist/SKILL.md

@@ -48,6 +48,7 @@ Check for files modified outside scope fence, new dependencies not in design. Un
 | Correctness | PASS/FAIL/WARN | [list] |
 | Coherence | PASS/FAIL/WARN | [list] |
 
+- **Architecture merge**: <merged architecture.md + database.md + api.md + N SQL scripts to docs/architecture/ | architecture/ absent — skipped>
 - **Prototype sync**: <synced N pages / N components / design-system updated | no UX delta | conflicts: N>
 - **Compound promotion**: <promoted N learnings / updated N confirmed patterns | no learnings>
 
@@ -71,12 +72,12 @@ If an `e2e/` suite exists for the change, fold its report into verification (see
 - Scope added without artifact updates?
 - Unresolved blockers or known risks?
 - Delta specs exist that need merging?
-- Run `npx --yes --package @xulthekl/team-flow@0.22.4 tf audit <change-dir>` — include `decision-point-audit.md` in archive
+- Run `npx --yes --package @xulthekl/team-flow@0.23.0 tf audit <change-dir>` — include `decision-point-audit.md` in archive
 
 ### DP-6 (Verification Outcome)
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_6_result "<pass|conditional|fail>: <summary>"
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_6_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_6_result "<pass|conditional|fail>: <summary>"
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_6_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 If FAIL, do NOT proceed to DP-7. Route back or ask about abandonment.
 
@@ -84,13 +85,13 @@ After recording a PASS outcome, also record it as the verification gate so the
 `executing → closing` transition is allowed (the guard accepts either
 `test_result: pass` or a `dp_6_result` starting with `pass`):
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> test_result pass
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> test_result pass
 ```
 
 ### DP-7 (Archive Confirmation)
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_7_result "confirmed: <archive summary>"
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_7_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_7_result "confirmed: <archive summary>"
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_7_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 Verify DP-0 through DP-6 are recorded before DP-7.
 
@@ -100,17 +101,29 @@ If implementation diverged from the contract, return to `bridging` before closur
 
 ## Post-Verification
 
-Run `npx --yes --package @xulthekl/team-flow@0.22.4 tf state transition <change-dir> closing`. If delta specs exist, route to `spec-merger`.
+Run `npx --yes --package @xulthekl/team-flow@0.23.0 tf state transition <change-dir> closing`. If delta specs exist, route to `spec-merger`.
+
+### Architecture Merge (v0.10 §28-§31) — MUST run first
+
+Merge change-level architecture artifacts to the global `docs/architecture/` baseline **before** any other post-verification step:
+
+```bash
+npx --yes --package @xulthekl/team-flow@0.23.0 tf arch-merge <change-dir>
+```
+
+This merges `architecture/{architecture,database,api}.md` and `architecture/sql/` into the global architecture docs. Skip silently when `architecture/` does not exist (architecture-design was `skipped`).
+
+**Execution order (mandatory)**: `arch-merge` → `prototype-sync` → `compound promotion`. Do not parallelise — global docs must not be in a half-updated state.
 
 ### Prototype Sync (v0.5)
 
 After `arch-merge` completes, run prototype-sync to merge UX deltas back to the global prototype:
 
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf prototype-sync <change-dir>
+npx --yes --package @xulthekl/team-flow@0.23.0 tf prototype-sync <change-dir>
 ```
 
-**Write-back order (mandatory)**: `arch-merge` → `prototype-sync` must be executed **sequentially** within the same change closing. Do not run them in parallel — the global `docs/architecture/` and `prototype/` must not be in a half-updated state when the next change grounds on them.
+**Write-back order (mandatory)**: `arch-merge` → `prototype-sync` → `compound promotion` must be executed **sequentially** within the same change closing. Do not run them in parallel — the global `docs/architecture/` and `prototype/` must not be in a half-updated state when the next change grounds on them.
 
 If `prototype-sync` reports conflicts, list them in the closing summary and flag for manual resolution. Do not block closing on prototype-sync conflicts (advisory level).
 
@@ -119,7 +132,7 @@ If `prototype-sync` reports conflicts, list them in the closing summary and flag
 During closing, promote change-level learnings to the global solutions library:
 
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf solutions promote <change-dir>
+npx --yes --package @xulthekl/team-flow@0.23.0 tf solutions promote <change-dir>
 ```
 
 This checks `specs/<cap>/learnings.md` for entries meeting promotion criteria:
@@ -139,7 +152,7 @@ Before finalizing the closing, check if this change produced any learnable momen
 
 If any of the above occurred, capture the learning:
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf solutions capture \
+npx --yes --package @xulthekl/team-flow@0.23.0 tf solutions capture \
   --phase cross-phase --domain <domain> --type pitfall \
   --severity medium --summary "<what happened and how to prevent it>"
 ```
@@ -161,6 +174,6 @@ Verify files exist and are non-empty, run `node --check` on code files, skip 5-s
 ## Exception Handling
 
 - **Parse failures**: Report exact file and section
-- **Missing files**: If audit can't generate, run `npx --yes --package @xulthekl/team-flow@0.22.4 tf audit` manually
+- **Missing files**: If audit can't generate, run `npx --yes --package @xulthekl/team-flow@0.23.0 tf audit` manually
 - **User interruption**: Re-run verification from the beginning on resume
 - **DP gaps**: Flag missing DPs during DP-6; ask user whether to proceed or return

package/skills/release-archivist/references/closing-procedures.md

@@ -7,7 +7,7 @@
 After `arch-merge` completes, run prototype-sync to merge UX deltas back to the global prototype:
 
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf prototype-sync <change-dir>
+npx --yes --package @xulthekl/team-flow@0.23.0 tf prototype-sync <change-dir>
 ```
 
 **Write-back order (mandatory)**: `arch-merge` → `prototype-sync` must be executed **sequentially** within the same change closing. Do not run them in parallel.
@@ -19,7 +19,7 @@ If `prototype-sync` reports conflicts, list them in the closing summary and flag
 During closing, promote change-level learnings to the global solutions library:
 
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf solutions promote <change-dir>
+npx --yes --package @xulthekl/team-flow@0.23.0 tf solutions promote <change-dir>
 ```
 
 Promotion criteria:
@@ -39,7 +39,7 @@ Before finalizing the closing, check if this change produced any learnable momen
 
 If any occurred, capture the learning:
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf solutions capture \
+npx --yes --package @xulthekl/team-flow@0.23.0 tf solutions capture \
   --phase cross-phase --domain <domain> --type pitfall \
   --severity medium --summary "<what happened and how to prevent it>"
 ```
@@ -49,22 +49,22 @@ Advisory — skip silently if no learnable moments detected.
 ## DP-6 (Verification Outcome)
 
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_6_result "<pass|conditional|fail>: <summary>"
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_6_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_6_result "<pass|conditional|fail>: <summary>"
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_6_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 
 If FAIL, do NOT proceed to DP-7. Route back or ask about abandonment.
 
 After PASS, also record the verification gate:
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> test_result pass
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> test_result pass
 ```
 
 ## DP-7 (Archive Confirmation)
 
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_7_result "confirmed: <archive summary>"
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_7_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_7_result "confirmed: <archive summary>"
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_7_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 
 Verify DP-0 through DP-6 are recorded before DP-7.

package/skills/spec-merger/SKILL.md

@@ -10,7 +10,7 @@ After a change completes, delta specs (ADDED/MODIFIED/REMOVED/RENAMED) must be m
 ## Pre-Flight Checks
 
 ### Conflict Detection
-Run `npx --yes --package @xulthekl/team-flow@0.22.4 tf sync <change-dir>`. If conflicts are detected (same requirement modified by multiple changes), present the conflict list to the user for resolution order.
+Run `npx --yes --package @xulthekl/team-flow@0.23.0 tf sync <change-dir>`. If conflicts are detected (same requirement modified by multiple changes), present the conflict list to the user for resolution order.
 
 ### Abandoned Change Guard
 Check if the change is `abandoned`. If so → STOP: "Abandoned changes cannot be synced. Delta specs are preserved for reference but must not be merged."
@@ -55,7 +55,7 @@ Output sync report table: Capability, ADDED/MODIFIED/REMOVED/RENAMED counts, Sta
 2. Change folder (including deltas) remains for traceability.
 3. Record that merging is complete so the `executing → closing` guard allows closure:
    ```bash
-   npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> spec_merged true
+   npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> spec_merged true
    ```
    (If the change had no delta sections, still set `spec_merged true` — there was nothing to merge.)
 

package/skills/spec-writer/SKILL.md

@@ -41,19 +41,21 @@ Read `docs/solutions/INDEX.md` if it exists. Filter entries where `phase = spec
 若 `architecture/` 目录存在（本 change 经 workflow-start 的 architecture-design 判断门判定为 `required` 并产出了架构设计），读取以下文件作为 design.md / tasks.md 的架构约束输入：
 
 - `architecture/architecture.md` → design.md `## Decisions` 的架构约束（聚合/限界上下文/CQRS 决策）
-- `architecture/database.md` → design.md + tasks.md 的数据层约束（实体/读写模型/schema 变更）
-- `architecture/api.md` → tasks.md 的接口定义约束（端点/方法签名/Command-Read-Query 分流）
+- `architecture/database.md` → design.md + tasks.md 的数据层约束（实体/读写模型/schema 变更）；注意 database.md 引用 `architecture/sql/` 路径而非内嵌 DDL
+- `architecture/api.md` → tasks.md 的接口路由约束（**架构路由表**：Command/Read/Query 分类，非详细 API 规格——详细规格由 Swagger 管理）
+- `architecture/sql/ddl/*.sql` → tasks.md 数据层任务的 DDL 脚本约束（可执行建表/改表脚本）
+- `architecture/sql/migration/*.sql` → tasks.md 数据层任务的数据迁移约束
 
 **约束传递规则**：
 - design.md 的 `## Decisions` 段必须**引用** architecture/ 中的架构决策，不得与之矛盾
-- tasks.md 的接口定义（Interfaces 段）必须与 `architecture/api.md` 的 API 设计对齐
-- tasks.md 的数据层任务必须与 `architecture/database.md` 的 schema 变更对齐
+- tasks.md 的接口定义（Interfaces 段）必须与 `architecture/api.md` 的架构路由表（Command/Read/Query 分类）对齐——详细 API 规格由 Swagger 管理，api.md 不含
+- tasks.md 的数据层任务必须与 `architecture/database.md` 的 schema 变更对齐，并引用 `architecture/sql/ddl/*.sql` 和 `architecture/sql/migration/*.sql` 作为可执行脚本路径
 
 `architecture/` 目录不存在时（判定为 `skipped`）跳过本段。
 
 ## Config Check
 
-Run: `npx --yes --package @xulthekl/team-flow@0.22.4 tf runtime config --get artifacts.order` — generate in configured order (default: proposal → specs → design → tasks). Run with `artifacts.skip` — skip any listed artifacts.
+Run: `npx --yes --package @xulthekl/team-flow@0.23.0 tf runtime config --get artifacts.order` — generate in configured order (default: proposal → specs → design → tasks). Run with `artifacts.skip` — skip any listed artifacts.
 
 ## Artifact Roles
 
@@ -69,7 +71,7 @@ Run: `npx --yes --package @xulthekl/team-flow@0.22.4 tf runtime config --get art
 
 **Honor Brief (v0.9)**: 若 `change-brief.md` 存在，尊重其 scope 边界与 AC 列表（见 Required Inputs「Change Brief」）——不静默丢弃 brief AC、不静默超出 brief scope；与 plan.md 冲突时以 plan.md 为准并注明。
 
-**Honor Architecture (v0.9 §26)**: 若 `architecture/` 目录存在，design.md 的 Decisions 段必须引用其架构决策（聚合/限界上下文/CQRS/API/DB），tasks.md 的接口定义和数据层任务必须与 architecture/ 产出对齐——不得静默忽略或矛盾架构设计产出。
+**Honor Architecture (v0.9 §26, v0.10 §28-§31)**: 若 `architecture/` 目录存在，design.md 的 Decisions 段必须引用其架构决策（聚合/限界上下文/CQRS/API/DB），tasks.md 的接口定义（对齐 api.md 架构路由表）和数据层任务（引用 sql/ddl/ + sql/migration/ 脚本路径）必须与 architecture/ 产出对齐——不得静默忽略或矛盾架构设计产出。
 
 ### proposal.md
 Must state: problem, what changes, capabilities affected, impact areas.
@@ -122,7 +124,7 @@ Generate one at a time. Confirm each before next. This prevents scope drift —
 
 ### design.md
 - `## Context`, `## Goals`, `## Decisions` (≥1, with Choice+Rationale+Alternatives), `## Risks And Trade-Offs`
-- **Architecture alignment (v0.9 §26)**: 若 `architecture/` 存在，`## Decisions` 必须引用架构设计产出中的关键决策（聚合/限界上下文/CQRS/API/DB）
+- **Architecture alignment (v0.9 §26, v0.10 §28-§31)**: 若 `architecture/` 存在，`## Decisions` 必须引用架构设计产出中的关键决策（聚合/限界上下文/CQRS/API/DB）；tasks.md 数据层任务须引用 `architecture/sql/` 脚本路径，接口定义须对齐 api.md 架构路由表
 
 ### tasks.md
 - `## File Structure`, `## Interfaces`, numbered tasks, exact file paths, TDD phases, ≤5 min steps, no placeholders, every requirement mapped, explicit dependencies
@@ -133,8 +135,8 @@ Generate one at a time. Confirm each before next. This prevents scope drift —
 
 Present summary of all 4 artifacts (2-3 sentences each). Ask user for adjustments. After approval:
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_2_result "approved: <summary>"
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state set <change-dir> dp_2_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_2_result "approved: <summary>"
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state set <change-dir> dp_2_timestamp $(date -u +%Y-%m-%dT%H:%M:%SZ)
 ```
 
 ## Handoff Rule

package/skills/workflow-bootstrap/SKILL.md

@@ -66,9 +66,30 @@ Do NOT invoke for:
 
 **条件**：如果 B1 侦察发现项目有一定复杂度（≥5 个模块或 ≥10 个源文件），执行此阶段。否则跳过。
 
+**B2 成果物导入（v0.23.0 新增）**：
+
+```
+Step 1: 询问用户是否有既有成果物
+  ├── 有 SQL DDL 脚本 → 导入到 docs/architecture/schema-baseline.sql
+  ├── 有物理模型文档 → 转换为 docs/architecture/PHYSICAL-MODEL.md（对齐标准格式）
+  ├── 有 API 文档/Swagger 导出 → 提取端点生成 docs/architecture/API-INDEX.md
+  └── 无既有成果物 → Step 2 兜底
+
+Step 2: 确定性提取（兜底）
+  ├── recon-probe.sh 增加 DDL 提取能力（解析 Entity 类 / SHOW CREATE TABLE）
+  ├── 从 schema-baseline.sql 反向生成 PHYSICAL-MODEL.md
+  └── 扫描 Controller/Router 类 → 生成 API-INDEX.md
+
+优先级原则：用户既有成果物 > 确定性提取 > LLM 推断
+```
+
 产出：
 - `docs/architecture/ARCHITECTURE.md` — 分层、模块边界、技术选型（瘦锚点格式）
 - `docs/architecture/DATABASE.md` — 数据模型（如适用）
+- `docs/architecture/PHYSICAL-MODEL.md` — 物理模型（v0.23.0 新增）
+- `docs/architecture/schema-baseline.sql` — DDL 基线脚本（v0.23.0 新增）
+- `docs/architecture/API-INDEX.md` — API 端点索引（v0.23.0 新增）
+- `docs/architecture/INDEX.md` — 架构文档索引（v0.23.0 新增）
 - `docs/architecture/<bc>/` — 每个有界上下文的目录（如能识别）
 
 **轻量 vs 完整**：
@@ -82,7 +103,9 @@ Do NOT invoke for:
 
 ### B3: Domain Vocabulary Bootstrap（领域词汇种子）
 
-从代码命名中提取领域词汇，创建或更新 `CONCEPTS.md`。
+从代码命名中提取领域词汇，创建或更新 `docs/architecture/CONCEPTS.md`。
+
+> **v0.23.0 变更**：`CONCEPTS.md` 已迁移至 `docs/architecture/CONCEPTS.md`（原根目录位置已弃用）。如根目录存在旧文件，应迁移至新路径。
 
 **提取策略**：
 1. 扫描实体类名、服务类名、模块名
@@ -104,7 +127,7 @@ Do NOT invoke for:
 ```
 
 **已有 CONCEPTS.md 处理**：
-- 如果 `CONCEPTS.md` 已存在（由之前的 ce-compound 运行创建）→ **合并**而非覆盖
+- 如果 `docs/architecture/CONCEPTS.md` 已存在（由之前的 ce-compound 运行创建）→ **合并**而非覆盖
 - 读取已有词汇，补充从代码中新发现的术语
 - 标注来源："workflow-bootstrap B3 补充"
 
@@ -124,7 +147,7 @@ Do NOT invoke for:
 > - C) 我只是想建立架构基线，暂不开发新需求（→ 结束）
 
 **上下文传递**：
-- 将 `docs/architecture/baseline.md` 和 `CONCEPTS.md` 的路径传递给 workflow-orchestrator S1
+- 将 `docs/architecture/baseline.md` 和 `docs/architecture/CONCEPTS.md` 的路径传递给 workflow-orchestrator S1
 - 作为后续流程的架构上下文
 
 ## Guardrails
@@ -140,9 +163,9 @@ Do NOT invoke for:
 
 每次交互结束时说明：
 1. 已完成的阶段（B1-B5）
-2. 已产出的制品（baseline.md / ARCHITECTURE.md / CONCEPTS.md / 目录结构）
+2. 已产出的制品（baseline.md / ARCHITECTURE.md / PHYSICAL-MODEL.md / schema-baseline.sql / API-INDEX.md / INDEX.md / CONCEPTS.md / 目录结构）
 3. 下一步建议（调用哪个 skill）
 
 ## Success Output
 
-接入结束时输出：侦察模式、产出清单（baseline.md / ARCHITECTURE.md / DATABASE.md / CONCEPTS.md / 目录结构）、关键发现（技术栈/模块数/架构模式/测试覆盖）、下一步建议。完整模板见 `references/b1-reconnaissance.md`「Success Output 模板」。
+接入结束时输出：侦察模式、产出清单（baseline.md / ARCHITECTURE.md / DATABASE.md / PHYSICAL-MODEL.md / schema-baseline.sql / API-INDEX.md / INDEX.md / docs/architecture/CONCEPTS.md / 目录结构）、关键发现（技术栈/模块数/架构模式/测试覆盖）、下一步建议。完整模板见 `references/b1-reconnaissance.md`「Success Output 模板」。

package/skills/workflow-bootstrap/references/b1-reconnaissance.md

@@ -15,6 +15,17 @@ bash scripts/recon-probe.sh --root <项目根> --out /tmp/recon-<slug>.json
 
 固定采集（不依赖 LLM，两次接入结果一致）：目录树（限深 4 层）、依赖清单（pom/package.json/requirements/go.mod/build.gradle）、LOC 与文件类型分布、测试文件计数（含 `.test.mjs`/`.spec.mjs`）、DB 迁移文件清单、README/docs 探测。输出结构化 JSON 供子代理消费。脚本只做确定性机械采集（§17.8 第四类载体），语义判断交给子代理 LLM。
 
+## B1.1a DDL 提取能力（v0.23.0 新增）
+
+`recon-probe.sh` 需增加 DDL 提取能力，用于 B2 成果物导入阶段的兜底提取：
+
+- **Entity 类解析**：扫描 `@Entity`、`@Table` 注解的 Java 类，或 ORM 模型定义文件，提取表名、字段名、字段类型、索引信息
+- **SHOW CREATE TABLE**：当项目配置了数据库连接时，执行 `SHOW CREATE TABLE` 导出各表 DDL
+- **迁移文件解析**：解析 Flyway / Liquibase / Alembic 等迁移脚本，提取最终态 schema
+- **输出**：将提取结果写入 `docs/architecture/schema-baseline.sql`，格式为标准 DDL（CREATE TABLE 语句）
+
+此能力为 B2 Step 2 兜底提取的前置依赖。当用户无既有 DDL 脚本时，由 recon-probe.sh 自动从代码/数据库中提取 schema 基线。
+
 ## B1.2 并行派发侦察子代理（语义增强）
 
 读 `references/agents/codebase-recon-analyst.md`，把 B1.1 的 JSON 路径作为 `recon_json` 入参，按维度**并行派发**子代理（每个子代理消费 JSON 基底 + 按需补读源码，按 §18.1 返回结构化摘要）：
@@ -65,7 +76,11 @@ bash scripts/recon-probe.sh --root <项目根> --out /tmp/recon-<slug>.json
 - docs/architecture/baseline.md（项目基线画像）
 - docs/architecture/ARCHITECTURE.md（架构锚点，如适用）
 - docs/architecture/DATABASE.md（数据模型，如适用）
-- CONCEPTS.md（领域词汇，N 个术语）
+- docs/architecture/PHYSICAL-MODEL.md（物理模型，v0.23.0）
+- docs/architecture/schema-baseline.sql（DDL 基线脚本，v0.23.0）
+- docs/architecture/API-INDEX.md（API 端点索引，v0.23.0）
+- docs/architecture/INDEX.md（架构文档索引，v0.23.0）
+- docs/architecture/CONCEPTS.md（领域词汇，N 个术语）
 - 目录结构：prd/ prototype/ docs/ changes/
 
 关键发现：

package/skills/workflow-orchestrator/references/s2-prd-prototype-loop.md

@@ -54,7 +54,7 @@
 检测可复利时刻（需求矛盾、原型返工、自动评审发现不一致并修正等）。每次自动评审发现不一致并修正后触发：
 
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf solutions capture --phase prd --domain <domain> --type pitfall --severity <sev> --summary "<summary>"
+npx --yes --package @xulthekl/team-flow@0.23.0 tf solutions capture --phase prd --domain <domain> --type pitfall --severity <sev> --summary "<summary>"
 ```
 
 ### 6. 反馈环路检查点

package/skills/workflow-orchestrator/references/s4-split-validate.md

@@ -38,7 +38,7 @@ verdict = FAIL → 必须回退 S3 调整拆分后重新审计，不可绕过直
 
 ```bash
 mkdir -p changes/<change-name>
-npx --yes --package @xulthekl/team-flow@0.22.4 tf state init changes/<change-name>
+npx --yes --package @xulthekl/team-flow@0.23.0 tf state init changes/<change-name>
 ```
 
 > ⚠️ **路径约束**：change 脚手架目录固定为项目根 `changes/<change-name>/`。

package/skills/workflow-orchestrator/references/s5-monitoring.md

@@ -34,7 +34,7 @@
 change closing 时检查经验晋升（change 内经验 → 产品级经验）：
 
 ```bash
-npx --yes --package @xulthekl/team-flow@0.22.4 tf solutions promote <change-dir>
+npx --yes --package @xulthekl/team-flow@0.23.0 tf solutions promote <change-dir>
 ```
 
 ### 4. 动态重规划触发