dflow-sdd-ddd 0.10.0 → 0.11.0

package/CHANGELOG.md

@@ -6,6 +6,49 @@
 
 ---
 
+## 0.11.0 — 2026-06-27 — DDD 指引深化 + pre-V1 退役 + docs 刷新
+
+**Proposals**：PROPOSAL-059（modeling-guide 盲區補強）、PROPOSAL-060（Subdomain 分類）、PROPOSAL-061（Brownfield aggregate 萌芽判準）、PROPOSAL-062（戰術補遺）、PROPOSAL-064（Brownfield modeling-guide reachability）、PROPOSAL-065（檢查機械化）、PROPOSAL-066（context-map 語彙補完）、PROPOSAL-063（退役 pre-V1 migration story）
+
+本版主線 = DDD 引導指引一輪深化,貫穿主軸：補 AI 自行建模會漏的盲區、擋 AI 過度套用 DDD、讓 Brownfield 也搆得到完整建模指引、把 review / verify 檢查收成可機械執行的判準；另含 pre-V1 migration story 全退役與 README / docs 刷新。
+
+### 新功能 / 行為改善（DDD 建模指引）
+
+- **DDD modeling guide 盲區補強**（PROPOSAL-059）：補不變式三層分類（local / aggregate-boundary / set-based）、聚合子集合無界成長判準、event payload thin/fat 準則、跨 aggregate 事件鏈失敗路徑 BR 化、Event Sourcing 防呆句。
+- **Subdomain-Aware Modeling Depth（防過度工程）**（PROPOSAL-060）：兩軌 `context-map.md` 加 Subdomain Type 欄（core / supporting / generic）；guide 加「依 subdomain 調建模深度」小節（優先序 cap + 三防誤讀邊界：BR 不豁免 / Tier 正交 / criticality 不降級）。方向是省成本而非加流程。
+- **Brownfield aggregate 萌芽判準**（PROPOSAL-061）：modify-existing / new-feature / new-phase 三流加「一概念累積多條狀態轉移 / 原子跨欄位不變式 → Aggregate 正在成形」偵測,建議升 T1 deliberately 建模。
+- **Brownfield 也搆得到 DDD modeling guide**（PROPOSAL-064）：guide 升為 `templates/common/` canonical bundle reference,`dflow init` / `configure-agents` 投影到 Brownfield 專案（先前 greenfield-only）；guide 內 greenfield-coupled artifact 參照 edition-neutral 化（頂部 Edition note 對映 Brownfield 記錄面）。
+- **modeling guide 戰術補遺**（PROPOSAL-062）：Factory（含 reconstitution ≠ creation）、強型別 ID + domain primitives 判準、Read Model 查詢側（列表 / 報表不走 aggregate）。
+- **context-map 語彙補完**（PROPOSAL-066）：guide BC-Relationships 加 Separate Ways（反過度整合）+ Big Ball of Mud（+ ACL,包 legacy 泥球）判準 / 階梯 + Open Host Service 一句；兩軌 `context-map.md` Relationship Type 語彙同步。
+
+### 維護者 / 檢查機械化
+
+- **DDD 檢查機械化**（PROPOSAL-065）：`pr-review` checklist 的 UL 檢查收成「diff domain-facing 命名 ↔ glossary `Code Mapping` 對照 + 同義詞偵測」（兩軌對齊）；`/dflow:verify` reframe 為「rules↔behavior 核心 + optional domain-doc hygiene」,加 events.md 反向檢查（greenfield,收窄 local + business-significant）與 models.md Code-Mapping 資訊檢查（兩軌）；`check-repo-consistency.sh` 加 Edition-note 載重面 guard（dev-only,不影響套件使用者）。
+
+### 文件 / Tutorial
+
+- **README 刷新 + Why Dflow 頁**：README 更新至現況;新增 `docs/why-dflow.md`（+ 英文 parity）。
+- **tutorial 進階觀念**：`tutorial/DDD_MINDSET_SHIFT.md` 加 3 則進階 mindset（Factory / 強型別 ID / Read Model,對齊 PROPOSAL-062）。
+
+### 移除 / 退役
+
+- **退役 pre-V1 migration story**（PROPOSAL-063）：移除 pre-V1 → V1 migration guide、`dflow doctor` / `dflow init` 的 pre-V1 偵測、`AI-AGENT-GUIDE.md` 偵測段。Dflow 任何已發布 npm 版本皆無 pre-V1 採用者 → 該偵測 / 指引已無對象。**對既有專案：無影響。**
+
+### 修正
+
+- **`--skills` help 修正**：`dflow configure-agents --skills` 的 help 文字補列全三家工具（Claude / Codex / Copilot）。
+
+### 升級提醒
+
+- **Brownfield 取得 DDD modeling guide**（PROPOSAL-064）：既有 Brownfield 專案重跑 `dflow configure-agents` 後,`dflow/specs/shared/dflow-workflows/references/` 下新增 `ddd-modeling-guide.md`（先前僅 greenfield 投影）。
+
+### 驗證
+
+- 每個 DDD phase 全程 proposal-stage + implementation-stage cross-model review 收斂；3b（core-invariant,動 `lib/init.js`）另過 fresh cold-eye gate（r1 抓到破包重投影靜默刪已裝 guide 的 data-loss must-fix）。
+- `npm test` + `scripts/check-repo-consistency.sh`（含 `check-cross-refs.mjs` + source↔mirror diff + `npm pack --dry-run`）全綠。
+
+---
+
 ## 0.10.0 — 2026-06-06 — agentskills 標準三家觸發 parity、既有 agent 檔自動注入、投影內容保全與清理
 
 **Proposals**：PROPOSAL-049（feature-slice 使用面語意體檢）、PROPOSAL-050（還原 041 雙軌合一丟失的 skill 內容進 AI-AGENT-GUIDE）、PROPOSAL-051（退役 `templates/CLAUDE.md`）、PROPOSAL-052（bundle stale-removal 推廣到同-edition）、PROPOSAL-054（既有 agent 檔 Dflow 墊片 auto-inject）、PROPOSAL-056（Codex 專案層 skill `--skills` parity）、PROPOSAL-057（以 agentskills.io 標準為三家共同自動觸發層；Phase 2）

package/README.en.md

@@ -4,8 +4,12 @@
 
 > **AI collaboration without DDD = accelerated chaos; with DDD = AI constrained inside the domain model upfront.**
 > A Rich Domain Model (business rules encoded into domain objects themselves, not scattered across services or prompts) puts invariants, business rules, and Aggregate boundaries inside the objects — every line of code the AI writes must pass through that contract. Dflow treats DDD as the semantic backbone of SDD.
+>
+> **Dflow doesn't teach AI what DDD is — it's a scaffold:** it forces the AI to keep a full record of the trade-offs behind each design decision and fills in the blind spots the AI tends to miss while filling in details on its own and that review can't easily catch.
+>
+> In other words: not whether the AI can do DDD, but whether you can trust it when it does.
 
-Dflow is a spec-first workflow kit for AI-assisted software development. It gives your AI coding agent a concrete process for turning change requests into structured specs, domain language, implementation plans, drift checks, and reviewable code instead of jumping straight from prompt to code.
+Concretely, it is a spec-first workflow kit for AI-assisted software development. It gives your AI coding agent a concrete process for turning change requests into structured specs, domain language, implementation plans, drift checks, and reviewable code instead of jumping straight from prompt to code.
 
 The goal is not the process itself, but repeatable software change with clearer meaning, fewer scattered rules, and less prompt-dependent behavior.
 
@@ -20,7 +24,7 @@ The goal is not the process itself, but repeatable software change with clearer
 | **Three-layer documentation model** | Matches how feature branches actually evolve: phase (one propose-implement-archive cycle) / feature (the whole branch's running state and resume pointer) / system (cross-feature long-term knowledge). Many spec tools only ship phase + system, which breaks down when a feature branch spans multiple phases. Detailed below. |
 | **Change-depth-based tiers (T1/T2/T3)** | AI scales specification and verification by change depth: color/typo gets one inline row in `_index.md`; bug fixes get a lightweight spec plus focused verification; new features or bounded-context-level changes go through a full phase-spec plus layer-by-layer implementation planning / verification. Small changes don't get dragged down by the process. |
 | **Drift verification** | `/dflow:verify` cross-checks specs, domain documents, implementation, tests, and tech-debt records to surface the "documentation still describes the old behavior" drift that PR review by eye usually misses. |
-| **Multi-AI-tool rule sharing** | A canonical project guide plus thin tool-specific shims (`CLAUDE.md` / `AGENTS.md` / Copilot instructions) — teams switching between Claude, Codex, and Copilot don't have to maintain multiple copies of workflow rules. |
+| **Multi-AI-tool rule sharing** | A canonical project guide plus thin tool-specific shims (`CLAUDE.md` / `AGENTS.md` / Copilot instructions) — teams switching between Claude, Codex, and Copilot don't have to maintain multiple copies of workflow rules. All three also share one project-level skill built on the agentskills.io open standard, so natural language auto-triggers the matching workflow (Copilot CLI summons it via `/dflow`). |
 
 ## Get Started
 
@@ -48,44 +52,27 @@ tool, run:
 dflow configure-agents
 ```
 
-If you also want tool-native command / prompt wrappers, use the opt-in mode:
+Adding `--skills` projects a project-level skill for all three tools (Claude,
+Codex, and GitHub Copilot), restoring natural-language auto-trigger (you say "I
+want to add a feature" and the AI suggests the matching workflow; Copilot CLI
+still summons it via `/dflow`). All three support it now, so treat it as the
+recommended standard install:
 
 ```bash
-dflow configure-agents --command-adapters
+dflow configure-agents --skills
 ```
 
-This command only configures AI instruction files and optional command
-adapters. It does not rerun project initialization or touch existing specs.
-
-### Alternative: try without installing
-
-If you cannot or do not want to do a global install (no admin rights,
-ephemeral environment, or one-shot evaluation), every Dflow CLI command is
-also available through `npx`:
-
-```bash
-npx dflow-sdd-ddd init
-npx dflow-sdd-ddd doctor
-npx dflow-sdd-ddd configure-agents
-```
-
-When using this path, all commands in the same session must also use the full
-`npx dflow-sdd-ddd <subcommand>` form. The bare `dflow` alias is only
-available after a global install.
-
-### Check legacy artifacts (optional)
-
-To check whether the project still has legacy or pre-V1 artifacts (such as
-a top-level `specs/` directory or a `_共用/` directory left over from older
-Dflow forms), run:
+If you also want tool-native `/` command / prompt menus, add `--command-adapters`
+(it composes with `--skills`):
 
 ```bash
-dflow doctor
+dflow configure-agents --command-adapters --skills
 ```
 
-`doctor` is a read-only health check. It never modifies files; it only
-reports findings and points at the migration guide. Freshly initialized
-projects won't have legacy artifacts and can skip this step.
+These commands (re)configure AI instruction files and refresh the
+project-vendored workflow bundle, plus optional command adapters / skills; they
+do not rerun init's interactive prompts and do not overwrite specs you authored
+yourself.
 
 ### Start using the Dflow workflow
 
@@ -107,7 +94,8 @@ behaves differently. Use these practical invocation forms:
 | Tool | Recommended invocation |
 |---|---|
 | Claude Code after `--command-adapters` | `/dflow:<id>`, for example `/dflow:new-feature` |
-| GitHub Copilot | `/dflow:<id>` as chat text; `/dflow-<id>` in the VS Code prompt menu |
+| GitHub Copilot (VS Code Chat) | Command entry is `/dflow-<id>` (hyphen, needs `--command-adapters`); natural language also auto-triggers. `/dflow:<id>` (colon) is only a text reference, not a command |
+| GitHub Copilot CLI | No per-id command; type `/dflow` to summon the skill, then describe the workflow in natural language |
 | Codex CLI | no-slash plain text `dflow:<id>`, for example `dflow:new-feature` |
 
 If your tool does not support custom slash commands, use the workflow name as
@@ -245,8 +233,8 @@ without maintaining multiple copies of the workflow rules.
 You can run `dflow configure-agents` later to add more tool shims as the team
 adopts additional AI coding agents. If you need Claude / Copilot tool-native
 command entries, use `dflow configure-agents --command-adapters`. For
-natural-language auto-trigger (a project-level skill for Claude Code and Codex),
-use `dflow configure-agents --skills`.
+natural-language auto-trigger (a project-level skill for Claude Code, Codex, and
+GitHub Copilot), use `dflow configure-agents --skills`.
 
 ### Version-Control Policy for Generated Artifacts (recommended default)
 
@@ -260,7 +248,7 @@ version-control the source, not the generated artifacts.
 | `dflow/` (canonical guide, specs, fallback merge snippets) | source | **version-control** |
 | Thin shims or marked Dflow blocks in existing root agent files (`CLAUDE.md` / `AGENTS.md` / `.github/copilot-instructions.md`) | source | **version-control** |
 | `.claude/commands/dflow/`, `.github/prompts/dflow-*.prompt.md` | generated | **recommended: do not version-control (gitignore)**; regenerate after clone with `configure-agents --command-adapters` |
-| `.claude/skills/dflow/`, `.agents/skills/dflow/` | generated | **recommended: do not version-control (gitignore)**; regenerate after clone with `configure-agents --skills` |
+| `.claude/skills/dflow/`, `.agents/skills/dflow/`, `.github/skills/dflow/` | generated | **recommended: do not version-control (gitignore)**; regenerate after clone with `configure-agents --skills` |
 
 This is a **recommendation**, not the only valid policy. If your team wants a
 native `/` menu immediately after clone, or your CI / dev environment does not
@@ -279,6 +267,20 @@ to avoid a registry / guide version mismatch. Per-tool `.gitignore` snippets,
 glob side effects, the `git rm --cached` switch-over step, and upgrade details
 are covered in the per-tool guides.
 
+**Caveat when upgrading an existing project**: `configure-agents` only
+re-projects the layers Dflow itself owns (the workflow bundle, command / skill
+adapters, and the marked block inside existing agent files). It does **not**
+refresh the canonical guide (`AI-AGENT-GUIDE.md`) or the other user-owned layers
+(such as `_conventions.md` or the prose outside a shim's markers) — those become
+project-owned right after init and are deliberately left untouched. The trade-off:
+when a new release adds content into the canonical guide, an existing project does
+not pick it up automatically and can silently drift from that release's canonical
+shape. After upgrading an existing project, reconcile manually and use a fresh
+comparison baseline — run a **brand-new `dflow init` with the same edition and the
+same answers** elsewhere, then diff it file-by-file against your project: every
+difference should classify as either "your user content" or "known
+outside-the-markers", otherwise it is a missed update.
+
 For tool-specific walk-throughs of what `init` writes and how Dflow's
 workflow commands appear in a given AI tool, see the per-tool guides under
 `docs/`:
@@ -363,6 +365,16 @@ Domain meaning -> Structured spec -> AI implementation -> Code as output
 
 For a longer explanation, see [Why DDD Matters More with AI](docs/why-ddd-for-ai.en.md).
 
+## Why Dflow (Even When AI Already Knows DDD)
+
+A common objection: "AI already understands DDD — tell it to *build a feature using DDD* and it will, so adding a process layer is over-engineering." That is half right — the AI can indeed state the correct DDD answer. But stating the right answer and letting you see how it got there — and check what it missed — at review are two different things. So the comparison is not "AI tool vs process" but **AI alone vs AI + scaffold**: the difference is not a smarter AI, it is a **more reviewable AI**.
+
+And Dflow's guidance is fed back from real blind spots — and once it is added, the model actually reuses it. One example: modeling on its own, the same model guarded a "only one active at a time" uniqueness rule with just an in-memory check inside the aggregate — textbook-correct, but under concurrency two requests each pass the check and break the invariant (modeling-correct, production-broken); after that blind spot was encoded as a section of Dflow guidance, re-run on a different domain, the same model proactively cited it and added DB-level protection (a unique index + a concurrency token + a 409). That is the value: Dflow turns "the blind spots AI misses on its own" into reusable guidance it actually follows.
+
+For audit-sensitive domains (medical, finance, compliance, anything where a production failure is expensive), the difference is a deal-breaker. The cost has two sides. *Producing* the DDD documents is no longer the pre-AI era of DDD by hand — the AI generates the specs, the decision record, and the domain model for you, so the marginal cost is mainly a few more tokens and running the workflow; and just being constrained by the domain model during generation already makes the output steadier (as in the concurrency blind spot above), which you get even if you never read the record closely. But cashing in the further "reviewable" value still takes a person actually reviewing that record — that is the cost in human attention and discipline. So the trade-off stands: when stakes are high, an audit is needed, or a team maintains it long-term, the investment clearly pays off; when you won't review it, the cost of failure is low, and iteration is fast, AI alone may still be the more practical choice.
+
+For the full loop (how a blind spot becomes guidance, and why the flip points to the guidance content rather than the domain or framing change), a few more "Dflow forces it on the record, AI tends to miss it on its own" observations, and the steps to verify it yourself, see [Why Dflow](docs/why-dflow.en.md).
+
 ## Repository Layout
 
 | Path | Purpose |
@@ -385,17 +397,19 @@ Publish Checklist](docs/npm-publish-checklist.md).
 ## Status
 
 Dflow is currently published as `dflow-sdd-ddd` on npm. The latest published
-npm package is `0.2.0`, covering:
+npm package is `0.10.0`, covering:
 
-- Project initialization (`dflow init`)
-- Workflow documentation (the `/dflow:*` flows)
-- Multi-AI agent setup (CLAUDE.md / AGENTS.md / Copilot instructions shims)
+- Project initialization (`dflow init`) and idempotent upgrade re-projection (`dflow configure-agents`)
+- Workflow documentation (the `/dflow:*` flows) plus a workflow bundle vendored into each project
+- Multi-AI agent setup: a canonical guide plus thin per-tool shims (CLAUDE.md / AGENTS.md / Copilot instructions), with existing agent files auto-injected as a marked block (no manual merge)
+- Native project-level skills for all three tools (Claude / Codex / GitHub Copilot), sharing the agentskills.io open standard with natural-language auto-trigger (Copilot CLI still summons via `/dflow`)
+- Optional tool-native command entries (`--command-adapters`) and an auto-trigger skill (`--skills`)
 - AI-agent-readable SDD/DDD guidance
-- Public migration tooling: manual migration guide plus `dflow doctor` read-only health check
-- Public onboarding: evaluator guide and per-tool walkthroughs for Claude Code and Codex CLI
+- `dflow doctor` read-only project health check
+- Public onboarding: evaluator guide and per-tool walkthroughs for Claude Code, Codex CLI, and GitHub Copilot
 - A verification-only CI workflow (it does not execute publish)
 
-The GitHub source may include post-`0.2.0` repository changes before the
+The GitHub source may include post-`0.10.0` repository changes before the
 next npm release is published. See [CHANGELOG.md](CHANGELOG.md) for full
 release history.
 

package/README.md

@@ -4,8 +4,12 @@
 
 > **AI 協作沒 DDD = 加速混亂；有 DDD = 把 AI 事先約束在領域模型內。**
 > Rich Domain Model（業務規則寫在領域物件本身、而非散在 service 或 prompt 裡）把不變條件、業務規則、Aggregate 邊界編碼進物件 — AI 寫的程式碼必須穿過這個契約。Dflow 把 DDD 當成 SDD 的語意骨幹。
+>
+> **Dflow 不是教 AI 什麼是 DDD——它是一層 scaffold（鷹架）：** 強迫 AI 把每個設計決策的取捨完整留檔，並補上「AI 自己補細節時容易漏、而 review 又難一眼看出」的盲區。
+>
+> 換句話說，不是「AI 會不會 DDD」，而是「AI 做 DDD 時，你能不能信他」。
 
-Dflow 是一套 spec-first 的工作流程工具集，專為 AI 輔助軟體開發設計。它為你的 AI 程式設計助理提供具體流程，把變更需求轉成結構化規格、領域語言、實作計畫、漂移檢查、與可審查的程式碼，而不是從 prompt 直接跳到程式碼。
+具體來說，它是一套 spec-first 的工作流程工具集，專為 AI 輔助軟體開發設計。它為你的 AI 程式設計助理提供具體流程，把變更需求轉成結構化規格、領域語言、實作計畫、漂移檢查、與可審查的程式碼，而不是從 prompt 直接跳到程式碼。
 
 目標不是流程本身，而是讓軟體變更可重複、語意更清楚、規則更不散落、行為更不依賴 prompt。
 
@@ -20,7 +24,7 @@ Dflow 是一套 spec-first 的工作流程工具集，專為 AI 輔助軟體開
 | **三層文件模型** | 對應 feature branch 的實際節奏：phase（單次提案-實作循環）/ feature（整條 branch 的累積狀態與接續指引）/ system（跨 feature 的長期知識）。許多 spec 工具只有 phase + system 兩層，多次迭代的 feature branch 跨多個 phase 時就會失真。下方有完整說明。 |
 | **依改動深淺的 Tier 制（T1/T2/T3）** | AI 依改動深淺自動決定規格與驗證量級：改顏色 / typo 只需 `_index.md` 一行；bug fix 用 lightweight spec + 聚焦驗證；新 feature 或動到 bounded context 才走完整 phase-spec + 分層實作計畫 / 驗證。小修改不會被流程拖累。 |
 | **漂移驗證** | `/dflow:verify` 把規格、領域文件、實作、測試、技術債紀錄做交叉比對，找出 PR review 人眼看不出來的「文件還在描述舊行為」漂移。 |
-| **多 AI 工具共用一份規則** | Canonical 專案指南 + 各工具薄 shim（`CLAUDE.md` / `AGENTS.md` / Copilot instructions），團隊在 Claude / Codex / Copilot 之間切換時不必維護多份 workflow 規則。 |
+| **多 AI 工具共用一份規則** | Canonical 專案指南 + 各工具薄 shim（`CLAUDE.md` / `AGENTS.md` / Copilot instructions），團隊在 Claude / Codex / Copilot 之間切換時不必維護多份 workflow 規則。三家還共用一份依 agentskills.io 開放標準的 project-level skill，可用自然語言自動觸發對應 workflow（Copilot CLI 需先打 `/dflow` 喚起）。 |
 
 ## 開始使用
 
@@ -41,35 +45,19 @@ init 流程會詢問是 greenfield 或 brownfield、團隊採用的 Git policy
 dflow configure-agents
 ```
 
-若想同時建立工具原生的命令 / prompt wrapper，使用 opt-in 模式：
+加上 `--skills` 會為 Claude / Codex / GitHub Copilot 三家投影 project-level skill，找回自然語言自動觸發（你描述「我要加一個功能」，AI 就主動建議對應 workflow；Copilot CLI 仍需先打 `/dflow` 喚起）。三家現在都支援，建議當成標準安裝：
 
 ```bash
-dflow configure-agents --command-adapters
+dflow configure-agents --skills
 ```
 
-此指令只設定 AI 指示檔與選配 command adapters，不會重跑專案初始化，也不會動到既有 specs。
-
-### 替代路徑：不安裝直接試用
-
-若無法或不想全域安裝（沒有管理員權限、暫時性環境、或只想試一次），Dflow 每個 CLI 指令都可透過 `npx` 執行：
-
-```bash
-npx dflow-sdd-ddd init
-npx dflow-sdd-ddd doctor
-npx dflow-sdd-ddd configure-agents
-```
-
-走這條路徑時，同一個 session 內所有指令都要用完整的 `npx dflow-sdd-ddd <subcommand>` 形式；裸 `dflow` 別名只有全域安裝後才能用。
-
-### 檢查 legacy artifacts（選用）
-
-要檢查專案內是否仍有 legacy 或 pre-V1 artifacts（如根目錄的 `specs/` 或舊版的 `_共用/`），執行：
+若還想要工具原生的 `/` 命令 / prompt 選單，再加 `--command-adapters`（可與 `--skills` 並用）：
 
 ```bash
-dflow doctor
+dflow configure-agents --command-adapters --skills
 ```
 
-`doctor` 是唯讀健康檢查；不會修改任何檔案，只報告找到的問題並指向 migration guide。剛 init 的新專案不會有 legacy artifacts、可跳過此步驟。
+這些指令會（重新）設定 AI 指示檔、刷新隨專案 vendored 的 workflow bundle，並選配 command adapters / skills；它們不會重跑 init 的互動問答，也不會覆寫你自己撰寫的 specs。
 
 ### 開始使用 Dflow workflow
 
@@ -90,7 +78,8 @@ dflow doctor
 | 工具 | 建議叫法 |
 |---|---|
 | Claude Code（安裝 `--command-adapters` 後） | `/dflow:<id>`，例如 `/dflow:new-feature` |
-| GitHub Copilot | chat 文字可用 `/dflow:<id>`；VS Code prompt 選單使用 `/dflow-<id>` |
+| GitHub Copilot（VS Code Chat） | 命令入口用 `/dflow-<id>`（連字號，需 `--command-adapters`）；也可自然語言自動觸發。`/dflow:<id>`（冒號）僅當文字稱呼、非命令 |
+| GitHub Copilot CLI | 沒有 per-id 命令；先打 `/dflow` 喚起 skill，再用自然語言描述 workflow |
 | Codex CLI | 不帶斜線的純文字 `dflow:<id>`，例如 `dflow:new-feature` |
 
 若你的工具不支援自訂 slash command，把 workflow 名稱當成普通對話訊息輸入即可。Dflow 是 Markdown-based 的 workflow 材料加一個 scaffolding CLI，能與任何可讀專案指示與 repo 上下文的 AI 程式設計助理一起運作。
@@ -208,7 +197,7 @@ Dflow 也會為你的 AI 程式設計助理建立或更新專案指示檔；確
 才會改寫 fallback merge snippet 到 `dflow/specs/shared/`。專案指南保持單一
 source of truth，團隊就能用多個 AI 工具而不必維護多份 workflow 規則。
 
-之後團隊採用新 AI 程式設計助理時，可隨時跑 `dflow configure-agents` 新增 shim；若需要 Claude / Copilot 的工具原生命令入口，改用 `dflow configure-agents --command-adapters`；若要自然語言自動觸發（為 Claude Code 與 Codex 投影專案層 skill），改用 `dflow configure-agents --skills`。
+之後團隊採用新 AI 程式設計助理時，可隨時跑 `dflow configure-agents` 新增 shim；若需要 Claude / Copilot 的工具原生命令入口，改用 `dflow configure-agents --command-adapters`；若要自然語言自動觸發（為 Claude Code、Codex 與 GitHub Copilot 投影專案層 skill），改用 `dflow configure-agents --skills`。
 
 ### 產生物的版控政策（建議預設）
 
@@ -219,12 +208,14 @@ source of truth，團隊就能用多個 AI 工具而不必維護多份 workflow
 | `dflow/`（canonical guide、規格、fallback merge snippet） | source | **版控** |
 | 薄 shim 或既有 root agent 檔案中的 marked Dflow block（`CLAUDE.md` / `AGENTS.md` / `.github/copilot-instructions.md`） | source | **版控** |
 | `.claude/commands/dflow/`、`.github/prompts/dflow-*.prompt.md` | 衍生物 | **建議不版控（gitignore）**，clone 後重跑 `configure-agents --command-adapters` 重生成 |
-| `.claude/skills/dflow/`、`.agents/skills/dflow/` | 衍生物 | **建議不版控（gitignore）**，clone 後重跑 `configure-agents --skills` 重生成 |
+| `.claude/skills/dflow/`、`.agents/skills/dflow/`、`.github/skills/dflow/` | 衍生物 | **建議不版控（gitignore）**，clone 後重跑 `configure-agents --skills` 重生成 |
 
 這是**建議**，不是唯一正解。若團隊希望 clone 後立即有原生 `/` 選單、或 CI / 開發環境不裝 npm，**版控 adapter** 也是合理選擇——代價是升級若改了命名，要重投影並 commit 刪除舊檔。關鍵原則：**同一專案對所有工具採一致策略**，別像常見的踩雷一樣一邊 ignore、一邊版控。
 
 升級 dflow 後重跑 `dflow configure-agents --command-adapters`，adapter 會用**新版的 command registry** 重投影；但**不會**覆寫已存在的 `dflow/specs/shared/AI-AGENT-GUIDE.md`（canonical guide 已存在則保留）。「重投影 adapter」與「升級 canonical guide」是兩件事；升級時請用**相同的 dflow CLI 版本**重投影，避免 registry 與 guide 版本錯位。各工具的 `.gitignore` 片段、glob 副作用、`git rm --cached` 切換步驟與升級細節見 per-tool 指南。
 
+**升級既有專案的 caveat**：`configure-agents` 只重投影 Dflow 自己擁有的自動層（workflow bundle、command / skill adapters，以及既有 agent 檔內帶 marker 的區塊）。它**不會**刷新 canonical 指南（`AI-AGENT-GUIDE.md`）與其他 user-owned 層（如 `_conventions.md`、shim marker 以外的文字）——這些檔在 init 後即歸專案所有、刻意不被覆寫。代價是：當新版把內容加進 canonical 指南時，既有專案不會自動拿到，可能與該版的 canonical 形狀 silent drift。升級既有專案後，建議手動 reconcile，並以「在別處跑一個**同 edition、同答案的全新 `dflow init`**、再與你的專案逐檔 diff」當驗證基準：每個差異都應能歸類為「你的 user content」或「已知 marker 以外」，否則就是漏修。
+
 特定工具的 init 寫入內容與 Dflow workflow 命令呈現方式，見 `docs/` 內的 per-tool 指南：
 
 - [在 Claude Code 中使用 Dflow](docs/using-with-claude-code.md)
@@ -304,6 +295,16 @@ Dflow 把 DDD 當成規格背後的語意結構：ubiquitous language 讓命名
 
 更詳細的說明見 [為什麼 AI 時代 DDD 更重要](docs/why-ddd-for-ai.md)。
 
+## 為什麼用 Dflow（即使 AI 已經會 DDD）
+
+常見的質疑是：「現在的 AI 已經懂 DDD，叫它『用 DDD 建一個 feature』它就會做，再加一層 process 是過度工程。」這句話對了一半——AI 確實能說出對的 DDD 答案。但「能說出對的答案」和「在 review 時看得到它怎麼想、查得出它有沒有漏」是兩回事。所以該比的不是「AI 工具 vs process」，而是 **AI alone vs AI + scaffold**：差別不是更聰明的 AI，是**更可審查的 AI**。
+
+而且 Dflow 的引導是從真實盲區回灌的、補上後模型真的會沿用。一個實例：模型自己建模時，把「同時只能有一筆 active」這類唯一性規則只用 aggregate 內的 in-memory check 保護——教科書上對、但並發下兩個請求會各自通過檢查、破壞不變式（modeling-correct、production-broken）；把這個盲區寫成一段引導補進 Dflow 後，換一個 domain 重跑，同一個模型就主動引用它、補上 DB 層保護（unique index + concurrency token + 409）。Dflow 的價值就在這：把「AI 自己會漏的盲區」固化成可重用、會被遵循的引導。
+
+對需要 audit 的領域（醫療、金融、合規、任何「上線出包代價高」的場景），這個差異是 deal-breaker。成本要分兩塊看：**產出** DDD 文件已經不是徒手做 DDD 的年代——AI 幫你生規格、決策紀錄與領域模型，邊際成本主要是多花一些 token 與走一遍流程；而且光是「生成時被領域模型約束」就已讓產出更穩（如前面那個並發盲區），這部分就算你沒深讀紀錄也拿得到。但要再兌現「可審查」這份價值，得有人實際去 review 那份紀錄——那才是人力與紀律的成本。所以取捨仍在：高風險、需 audit、要長期維護時，這筆投資明顯划算；你不會去 review、失敗成本低、迭代又快時，AI alone 仍可能更實際。
+
+完整的迴路（盲區怎麼變成引導、為什麼這歸到引導內容而非 domain / framing 的差異）、其他幾個「Dflow 強制留檔、AI 自己容易漏」的觀察，以及自己動手驗證的步驟，見 [為什麼用 Dflow](docs/why-dflow.md)。
+
 ## Repo 結構
 
 | 路徑 | 用途 |
@@ -321,17 +322,19 @@ issue 與 pull request 指引見 [CONTRIBUTING.md](CONTRIBUTING.md)。Pull reque
 
 ## 狀態
 
-Dflow 目前以 `dflow-sdd-ddd` 名稱發佈於 npm。最新發佈版本為 `0.2.0`，涵蓋：
+Dflow 目前以 `dflow-sdd-ddd` 名稱發佈於 npm。最新發佈版本為 `0.10.0`，涵蓋：
 
-- 專案初始化（`dflow init`）
-- Workflow 文件（`/dflow:*` 流程）
-- 多 AI agent 設定（CLAUDE.md / AGENTS.md / Copilot instructions shim）
+- 專案初始化（`dflow init`）與 idempotent 升級重投影（`dflow configure-agents`）
+- Workflow 文件（`/dflow:*` 流程）＋隨專案 vendored 的 workflow bundle
+- 多 AI agent 設定：canonical 指南 + 各工具薄 shim（CLAUDE.md / AGENTS.md / Copilot instructions）；既有 agent 檔以帶 marker 的區塊自動注入、零手動合併
+- 三家原生 project-level skill（Claude / Codex / GitHub Copilot），共用 agentskills.io 開放標準、支援自然語言自動觸發（Copilot CLI 仍需先打 `/dflow` 喚起）
+- 選配工具原生命令入口（`--command-adapters`）與自動觸發 skill（`--skills`）
 - AI agent 可讀的 SDD/DDD 指引
-- 公開 migration tooling：手動 migration guide 與 `dflow doctor` 唯讀健康檢查
-- 公開 onboarding：evaluator 指南、Claude Code / Codex CLI 的 per-tool walkthrough
+- `dflow doctor` 唯讀專案健康檢查
+- 公開 onboarding：evaluator 指南，Claude Code / Codex CLI / GitHub Copilot 的 per-tool walkthrough
 - 僅驗證的 CI workflow（不執行 publish）
 
-GitHub 上的 source 可能包含 `0.2.0` 之後尚未發佈的 repo 變更。完整 release history 見 [CHANGELOG.md](CHANGELOG.md)。
+GitHub 上的 source 可能包含 `0.10.0` 之後尚未發佈的 repo 變更。完整 release history 見 [CHANGELOG.md](CHANGELOG.md)。
 
 ## 授權
 

package/TEMPLATE-LANGUAGE-GLOSSARY.md

@@ -32,6 +32,7 @@ The "使用位置" column refers to file paths where the term appears structural
 | Business Rules | 業務規則 | `rules.md`, `_index.md` | BR-ID declarative rules |
 | Current BR Snapshot | 目前業務規則快照 | `_index.md` | feature-level rules snapshot |
 | Domain Models | 領域模型 | `models.md` | Entities / Value Objects / Services 等模型索引 |
+| Subdomain Type | 子領域類型 | `context-map.md` | 標記 BC 為 core / supporting / generic,決定建模深度（Subdomain-Aware Modeling Depth）；不降低 BR / Tier / 安全測試要求 |
 | Change Scope | 變動範圍 | `Git-principles-*.md`, spec templates | 描述本次變更涵蓋的功能 / 文件 / 程式碼範圍 |
 | Feature Goal | 功能目標 | `Git-principles-*.md`, `finish-feature-flow.md` | Integration Summary 與整合 commit message 的主目標段落 |
 | Related BR-IDs | 關聯 BR-ID 清單 | `Git-principles-*.md`, `finish-feature-flow.md` | 統整本次變更涉及的 ADDED / MODIFIED / REMOVED BR-ID |

package/bin/dflow.js

@@ -11,7 +11,7 @@ function printHelp() {
 Usage:
   dflow init              Initialize Dflow specs in the current project
   dflow configure-agents  Add or update AI agent instruction shims
-  dflow doctor            Read-only health check for legacy / pre-V1 artifacts
+  dflow doctor            Read-only project health check
   dflow --help            Show this help
   dflow --version         Show the CLI version
 `);
@@ -39,7 +39,7 @@ dflow/specs/shared/AI-AGENT-GUIDE.md file.
 
 Options:
   --command-adapters  Also generate tool-native thin wrappers for supported tools.
-  --skills            Also generate project-level skill adapters for supported tools (Claude Code and Codex), restoring natural-language auto-trigger.
+  --skills            Also generate project-level skill adapters for supported tools (Claude Code, Codex, and GitHub Copilot), restoring natural-language auto-trigger.
 `);
 }
 
@@ -47,16 +47,12 @@ function printDoctorHelp() {
   process.stdout.write(`Usage:
   dflow doctor
 
-Read-only health check for the current project. Reports legacy
-or pre-V1 artifacts that may need manual migration:
+Read-only health check for the current project. Reports findings such as:
 
-  - root specs/ directory containing Dflow content
-  - _共用/ directory under specs/ or dflow/specs/
   - dflow/specs/shared/_conventions.md missing the Dflow Version
     front-matter line
 
-Doctor never modifies files. See docs/migrating-to-dflow-v1.md
-for the manual migration checklist.
+Doctor never modifies files.
 `);
 }
 

package/docs/why-dflow.en.md

@@ -0,0 +1,72 @@
+# Why Dflow (Even When AI Already Knows DDD)
+
+> [繁體中文](why-dflow.md) | **English**
+
+If your instinct is "today's AI already knows DDD — tell it to *build a feature using DDD* and out come aggregates, value objects, events; isn't a spec-first tool on top of that over-engineering?" — this document is written for you. It is not trying to convince you; it lays Dflow's value, the evidence, and the limits flat so you can judge for yourself.
+
+## What Dflow is
+
+Dflow does not teach AI what DDD is — it is a scaffold: it forces the AI to keep a full record of the trade-offs behind each design decision, and fills in the blind spots the AI tends to miss while filling in details on its own and that review can't easily catch.
+
+Split "AI knows DDD" into two things and you see why it is still needed:
+
+1. **Can the AI state the correct DDD answer?** Yes. The model has read the textbooks — aggregate boundaries, invariants, ubiquitous language, it can recite them all.
+2. **When you review it, does the AI leave a complete enough record to audit — which options it weighed, why it chose this one, what it left undecided — and does it proactively catch the traps it tends to miss on its own?** Not necessarily — it depends on how you ask.
+
+So the real comparison is not "AI tool vs process" but:
+
+- **AI alone** output = AI knowledge × the implicit prompt structure × your ability to review it
+- **AI + Dflow** output = AI knowledge × an **explicit elicitation scaffold** × an **auditable record of the decisions (trade-offs, rejected options, open questions)** × your ability to review it
+
+The difference is not "a smarter AI." It is "**a more reviewable AI**."
+
+## Dflow's DDD guidance is grown, not copied from a textbook
+
+Part of Dflow's value is this: its guidance is fed back from real blind spots, and once added, the model actually reuses it afterward. A concrete, checkable example —
+
+**Blind spot**: modeling on its own, the model guarded "a connector can have at most one in-progress charging session" — a uniqueness rule — with just an in-memory `if Status == InUse throw` check inside the aggregate. By the DDD textbook this is correct, but under concurrency two requests each read `Available`, each pass the check, and each save → the invariant is broken (modeling-correct, production-broken).
+
+**Feedback**: that blind spot was written up as a section of guidance and added to Dflow's `ddd-modeling-guide.md` — "Set-Based / Uniqueness Invariants": for any "only one active X at a time" rule, no matter how you slice the aggregate, an in-memory check is never enough under concurrency; you need a DB unique / partial index or a concurrency token, and you must translate the conflict into an HTTP 409.
+
+**Reuse**: on a different domain (cold-chain sensors, "a sensor is attached to at most one carton at a time," structurally parallel) and with the model unaware it was being tested, it **proactively cited that section** and produced the full three-layer protection (in-memory guard + a concurrency token + a DB partial unique index + a 409).
+
+What this proves is something concrete: **Dflow turns "the blind spots AI misses on its own" into reusable guidance it actually follows.** This is not the grand conclusion "a few runs prove AI+process wins across the board" (the sample is small); it is evidence that Dflow's guidance loop works — **blind spot → add guidance → the model reuses it**. You can reproduce it yourself (see the end).
+
+> An honesty note: the domain and the framing also differ between the two runs, but both cut against the "it wasn't the guidance" counter-argument — neither domain is a high-frequency concurrency-design topic in the model's pre-training; the framing in the second run is purer (unaware of the test), and if that were the cause the result should be worse, not better. Once those two are pushed down as less plausible, the best remaining explanation for the flip is whether that section is present.
+
+## A few more things Dflow forces on the record that AI misses on its own
+
+The same observation round also showed (each point is "what Dflow does → what happens without it"):
+
+- **Forces the rejected-alternative reasoning**: one prompt in the aggregate-design template elicits a full decision block — "this boundary + why + which alternatives were considered + why rejected." On its own the AI usually hands you a single option, and at review you cannot audit "did it consider X?"
+- **Step gates turn decisions into reviewable moments**: the model naturally stops to confirm at naming and model-spike points; on its own the AI writes all the way to code and tests before you get to review, by which time the aggregate boundary is no longer negotiable.
+- **Open Questions get logged for the domain expert**: the model lists uncertain points as OQs awaiting an answer, instead of "guess something plausible" and burying the assumption in code logic.
+- **Ubiquitous language does not drift**: a glossary plus code mapping keeps spec / model / code on one set of terms; on its own the AI can mix `Sensor` / `Device` / `Tracker` within a single paragraph.
+- **Rules are queryable**: each business rule has an ID, a status, an owning aggregate, and a behavior link; on its own the AI scatters rules across prose, so "which tests does BR-003 affect?" is answerable only by grep and inference.
+
+## The honest trade-off
+
+Not hiding the limits is what makes the argument trustworthy:
+
+- **Scope**: the observations so far ran on a single model × a few moderate-complexity domains × lightweight modeling scope (through domain modeling, not the implementation phase). Whether the guidance is equally effective at the implementation phase, and whether a different model behaves the same, is **untested**.
+- **Prior**: the tested model already has a DDD pre-training prior. Dflow demonstrates it can turn "knows DDD but doesn't always think carefully" into "thinks carefully" — **not** "turns an AI with no DDD concept into one that does."
+- **Adoption implies compliance**: Dflow is a spec-first tool; it only works when it is followed. Cases where the AI or a person deliberately bypasses it are outside the claim. That is a property of the tool, not a bug.
+
+For audit-sensitive settings — medical, finance, compliance, safety-sensitive, or anything where a production failure is expensive or carries personal liability — this reviewability difference is a deal-breaker. The cost has two sides. *Producing* the DDD documents is no longer the pre-AI era when DDD by hand carried a heavy labor cost — the AI generates the specs, the decision record, and the domain model for you, so the marginal cost is mainly a few more tokens and running the workflow; and just being constrained by the domain model during generation already makes the output steadier (as in the concurrency blind spot above), a layer you get even if you never read the record closely. Dflow's DDD is also deliberately pragmatic (not the full academic suite), fitting a typical company's mid-sized systems with a low adoption barrier (a team need not be DDD experts first). But cashing in the further "reviewable" value still takes a person actually reviewing that record — that is the key cost in human attention and discipline. So the trade-off stands and is worth discussing: when stakes are high, an audit is needed, or a team maintains it long-term, the investment clearly pays off; when you won't review it, the cost of failure is low, and iteration is fast, AI alone may still be the more practical choice — Dflow does not always win.
+
+## Verify it yourself
+
+Don't trust any of the above — run it once (about 10–30 minutes):
+
+```bash
+npm install -g dflow-sdd-ddd
+mkdir dflow-test && cd dflow-test
+git init && git commit --allow-empty -m "init"
+dflow init           # choose greenfield + your AI tool + your stack
+```
+
+Then in your AI coding agent run `/dflow:new-feature` and assign a feature with a "cross-instance uniqueness" invariant, e.g. "at most one active session per account at a time." Watch whether, at domain modeling, the model reaches the "Set-Based / Uniqueness Invariants" section (in Dflow's `ddd-modeling-guide.md`), cites it, and adds a DB unique / partial index + a concurrency token + a 409. Note: installing the latest version verifies the half "when the guidance is present the model uses it"; the "without the guidance the model misses it" half was established by the run above before the guidance was added, and is not a variable you can toggle on the latest version — which always contains it.
+
+---
+
+Dflow does not claim to make the AI smarter; it makes the AI more reviewable: spec-first, domain meaning made explicit, decisions and rejected alternatives kept on the record, AI constrained before implementation, and drift verified before the work is called done. For why domain meaning itself matters more in the AI era, see [Why DDD Matters More with AI](why-ddd-for-ai.en.md).

package/docs/why-dflow.md

@@ -0,0 +1,72 @@
+# 為什麼用 Dflow（即使 AI 已經會 DDD）
+
+> **繁體中文** | [English](why-dflow.en.md)
+
+如果你的直覺是「現在的 AI 已經會 DDD，叫它『用 DDD 建一個 feature』，aggregate、value object、event 都出得來，再加一層 spec-first 工具是不是過度工程？」——這份文件是寫給你的。它不打算說服你，而是把 Dflow 的價值、證據與限制攤平，讓你自己判斷。
+
+## Dflow 是什麼
+
+Dflow 不是教 AI 什麼是 DDD——它是一層 scaffold（鷹架）：強迫 AI 把每個設計決策的取捨完整留檔，並補上「AI 自己補細節時容易漏、而 review 又難一眼看出」的盲區。
+
+把「AI 會 DDD」拆成兩件事，就懂為什麼還需要它：
+
+1. **AI 能不能說出對的 DDD 答案？** 能。模型讀過教科書，aggregate 邊界、不變式、ubiquitous language 都答得出來。
+2. **AI 在你 review 時會不會留下夠完整的紀錄（它考慮過哪些、為何這樣選、哪裡還沒確定）讓你 audit、會不會主動 catch 它自己容易漏的陷阱？** 不一定，要看你怎麼問。
+
+所以真正該比的不是「AI 工具 vs process」，而是：
+
+- **AI alone** 的產出 = AI 知識 × 隱含的 prompt 結構 × 你 review 它的能力
+- **AI + Dflow** 的產出 = AI 知識 × **明確的 elicitation scaffold** × **可審查的決策紀錄（取捨、否決的方案、open questions）** × 你 review 它的能力
+
+差異不是「更聰明的 AI」，是「**更可審查的 AI**」。
+
+## Dflow 的 DDD 引導是「長出來的」，不是抄教科書
+
+Dflow 的價值有一部分在於：它的引導是從真實盲區回灌的，而且補上之後，模型真的會在後續主動沿用。一個具體、可檢查的例子——
+
+**盲區**：模型自己建模時，把「一個充電槍同時只能有一筆進行中 session」這條唯一性規則，只用 aggregate 內 `if Status == InUse throw` 的 in-memory check 保護。DDD 教科書角度這是對的，但並發下兩個請求各自讀到 `Available`、各自通過檢查、各自 save → 不變式被破壞（modeling-correct、production-broken）。
+
+**回灌**：把這個盲區寫成一段引導，補進 Dflow 的 `ddd-modeling-guide.md`——「Set-Based / Uniqueness Invariants」：這類「同 X 只能有一筆 active」的規則，無論怎麼切 aggregate，in-memory check 在並發下永遠不夠，要加 DB unique / partial index 或 concurrency token，並把衝突 translate 成 HTTP 409。
+
+**沿用**：換一個 domain（冷鏈感測器「一個 sensor 同時最多掛在一個 carton」，結構平行）、且讓模型不知道自己在被測，它就**主動引用那段**、補上完整三層保護（in-memory guard + concurrency token + DB partial unique index + 409）。
+
+這證明的是一件具體的事：**Dflow 把「AI 自己會漏的盲區」固化成可重用、會被遵循的引導。** 這不是「跑幾次就證明 AI+process 全面勝出」那種大結論（樣本很小）；它是 Dflow 引導迴路有效的證據——**盲區 → 補引導 → 模型沿用**。你也能自己複現（見文末）。
+
+> 補充誠實度：兩次 run 之間 domain 與 framing 也不同，但都不利於「不是引導的功勞」這個反方——兩個 domain 在模型的 pre-training 裡都不是高頻並發設計題材；framing 在第二次更純（不知被測），若它是主因，結果該更差而非更好。把這兩條的可能性壓低後，最能解釋這個翻轉的就剩那段引導在不在。
+
+## 其他幾個「Dflow 強制留檔、AI 自己容易漏」
+
+同一輪觀察裡還看到（每點都是「Dflow 做了什麼 → 沒它會怎樣」）：
+
+- **強迫寫否決理由**：aggregate 設計模板一句 prompt，誘出「選這個邊界 + 理由 + 考慮過哪些替代 + 為何否決」的完整決策段；AI 自己通常只給你一個方案，review 時你無法 audit「它想過 X 嗎」。
+- **Step gate 把決策變成 reviewable moment**：模型在命名、模型 spike 等節點自然停下等確認；AI 自己一路寫到 code、tests 都好了你才有機會 review，這時 aggregate 邊界已經沒有商量空間。
+- **Open Question 留檔給 domain expert**：模型把不確定的點列成 OQ 等人答，而不是「不確定就猜一個合理的」把假設藏進 code。
+- **Ubiquitous language 不漂移**：術語表 + code mapping 讓 spec / model / code 用同一組名詞；AI 自己一段話內就能混用 Sensor / Device / Tracker。
+- **規則可被查詢**：每條 business rule 有 ID、status、所屬 aggregate、behavior 連結；AI 自己把規則散在 prose 裡，「BR-003 影響哪些測試」只能用 grep 推敲。
+
+## 誠實的取捨
+
+不掩蓋限制，反而是這套論點的可信來源：
+
+- **scope**：目前觀察只跑在單一模型 × 幾個中等複雜度 domain × lightweight modeling scope（到領域建模、不含 implementation phase）。implementation 階段的引導是否同樣有效、換不同模型會不會一樣，**未驗**。
+- **先驗**：被測模型本來就對 DDD 有 pre-training 先驗。Dflow 證明的是「能讓『會、但不一定每次仔細想』變成『仔細想』」，**不是**「能讓完全不懂 DDD 的 AI 變會」。
+- **採用即承諾遵循**：Dflow 是 spec-first 工具，只在被遵循時有效；AI 或人故意走偏的情境不在宣稱範圍內。這是工具屬性，不是 bug。
+
+對需要 audit 的場景——醫療、金融、合規、安全敏感、或任何「上線出包代價高 / 個人責任重」的領域——這個 reviewability 差異是 deal-breaker。成本要分兩塊看：**產出** DDD 文件已經不是徒手做 DDD 的高人力年代——AI 幫你生規格、決策紀錄與領域模型，邊際成本主要是多花一些 token 與走一遍流程；而且光是「生成時被領域模型約束」就已讓產出更穩（如上面那個並發盲區），這層就算你沒深讀紀錄也拿得到。Dflow 的 DDD 也刻意務實裁剪（不是學院派全套）、適合一般公司的中型系統，採用門檻不高（不需要團隊先是 DDD 專家）。但要再兌現「可審查」這份價值，得有人實際去 review 那份紀錄——那才是人力與紀律的關鍵成本。所以取捨仍在、值得討論：高風險、需 audit、要長期維護時，這筆投資明顯划算；你不會去 review、失敗成本低、迭代又快時，AI alone 仍可能是更實際的選擇，不是 Dflow 一定贏。
+
+## 自己驗證
+
+不用相信任何說法，自己跑一次（約 10–30 分鐘）：
+
+```bash
+npm install -g dflow-sdd-ddd
+mkdir dflow-test && cd dflow-test
+git init && git commit --allow-empty -m "init"
+dflow init           # 選 greenfield + 你的 AI 工具 + 你的 stack
+```
+
+接著在你的 AI coding agent 裡跑 `/dflow:new-feature`，指派一個含「跨實例唯一」型不變式的 feature，例如「同帳號同時最多一個 active session」。看模型走到領域建模時，會不會寫到「Set-Based / Uniqueness Invariants」段（Dflow 的 `ddd-modeling-guide.md`）、cite 它、並補上 DB unique / partial index + concurrency token + 409。注意：裝最新版能驗證的是「引導在場時模型確實會用它」這一半；「引導不在場時模型會漏」那一半是上面那段在加入引導之前建立的，不是你在最新版上能切換的——最新版一律含這段。
+
+---
+
+Dflow 不宣稱讓 AI 更聰明，它讓 AI 更可審查：規格優先、領域語義顯式化、把決策與否決理由留檔、在實作前約束、完成前驗證漂移（drift）。為什麼領域語義本身在 AI 時代更關鍵，見 [為什麼 AI 時代 DDD 更重要](why-ddd-for-ai.md)。