dflow-sdd-ddd 0.10.0 → 0.11.0

package/templates/greenfield/references/drift-verification.md

@@ -4,18 +4,24 @@ Triggered by `/dflow:verify` or `/dflow:verify <bounded-context>`.
 
 ## Purpose
 
-The A+C structure (`rules.md` as index + `behavior.md` as scenario content) introduces a drift risk — the two files can fall out of sync. This command provides a mechanical verification safety net that developers can run at key moments: before a PR, after a refactor, or when onboarding to an unfamiliar Bounded Context.
+The A+C structure (`rules.md` as index + `behavior.md` as scenario content) introduces a drift risk — the two files can fall out of sync. This command's **core** is a mechanical safety net for that `rules.md` ↔ `behavior.md` correspondence, run at key moments: before a PR, after a refactor, or when onboarding to an unfamiliar Bounded Context. On top of the core it also runs **optional, non-blocking domain-doc hygiene checks** on the BC's other docs (`events.md`, `models.md`) — see Scope.
 
 ## Scope
 
-### This command does (mechanical layer)
+### This command does (core + optional hygiene)
 
-Three string-matching checks that AI can perform deterministically:
+A small **core** of three deterministic string-matching checks on the
+`rules.md` ↔ `behavior.md` correspondence:
 
 1. **BR-ID forward check**: Every `BR-*` declared in `rules.md` has a corresponding section in `behavior.md`
 2. **Anchor validity**: If `rules.md` links to `behavior.md#section`, that anchor exists
 3. **BR-ID reverse check**: Every `BR-*` referenced in `behavior.md` is declared in `rules.md`
 
+Plus **optional domain-doc hygiene** warnings (non-blocking — they never fail the
+command, only surface "confirm this is intentional" signals): the `events.md`
+cross-check (forward + reverse, see Core-Specific Notes) and the `models.md`
+Code-Mapping hygiene check (see Model Catalog Notes).
+
 ### This command does NOT do (semantic layer — explicitly excluded)
 
 Semantic verification (LLM reads the one-line summary in `rules.md` vs the Given/When/Then in `behavior.md` and judges whether they contradict) is **out of scope**. Reasons:
@@ -40,9 +46,9 @@ Reasons:
 - BC-level current state is already maintained by `rules.md` /
   `behavior.md` / `events.md`, written by the same
   `/dflow:finish-feature` Step 3
-- `/dflow:verify` keeps a small, mechanical scope: just the
-  `rules.md` ↔ `behavior.md` correspondence inside one BC, plus the
-  events.md bonus check below
+- `/dflow:verify` keeps a small core: the `rules.md` ↔ `behavior.md`
+  correspondence inside one BC, plus the optional domain-doc hygiene
+  checks below (events.md, models.md)
 - Cross-feature / cross-phase aggregation would mix `/dflow:verify`'s
   job with `/dflow:finish-feature`'s job and produce false positives
   during in-progress features
@@ -86,6 +92,10 @@ For each Bounded Context:
       - behavior.md → templates/behavior.md
       Or run the completion flow to populate it from existing completed specs
   ```
+- Also locate the **optional** hygiene inputs for this BC — `events.md` and
+  `models.md`. They feed the non-blocking hygiene checks (Core-Specific Notes /
+  Model Catalog Notes). If either is absent, **skip its hygiene check silently** —
+  do not report or stop; they are bonus, not part of the core.
 
 ### Step 2: Extract BR-IDs from rules.md
 
@@ -155,15 +165,52 @@ Issues:
      remove the stale scenario reference from behavior.md
 ```
 
+The optional domain-doc hygiene checks (below) append their non-blocking signals
+to this same report — the `events.md` cross-check as `⚠`, the `models.md`
+Code-Mapping check as `ℹ` — and never change the core pass / fail count.
+
 ## Core-Specific Notes
 
-When verifying a Core context, also check:
-- `events.md` references in `behavior.md`: if a scenario says "And {DomainEvent} is raised", confirm the event is listed in `events.md`
-- This is a **bonus check**, not a blocking failure — report as a warning:
+When verifying a Core context, also run the `events.md` cross-check — **both
+directions, bonus only** (warnings, never a blocking failure):
+
+- **Forward** — `events.md` referenced from `behavior.md`: if a scenario says
+  "And {DomainEvent} is raised", confirm the event is listed in `events.md`:
   ```
   ⚠ BR-001 scenario references ExpenseReportSubmitted event,
     but events.md does not list it
   ```
+- **Reverse** — an `events.md` event with no scenario: for each Event Catalog row
+  that is **locally produced** (Producer is this BC's Aggregate / Application
+  Service) **and business-significant**, confirm at least one `behavior.md`
+  scenario references it; warn if none:
+  ```
+  ⚠ events.md lists OrderCancelled (produced by Order) but no behavior.md
+    scenario references it — confirm intentional (orphan / not yet specced)
+  ```
+  Exclude (else noisy): the `{EventName}` seed row, and best-effort side-effect
+  events (notification / logging) that the modeling guide lets live in
+  `events.md` / tech-debt without a BR. The reverse check is deterministic name
+  matching **plus** this applicability judgment — not a pure string match.
+
+## Model Catalog Notes
+
+A non-blocking **informational** hygiene check on `models.md`:
+
+- For each row whose **primary name cell** holds a real value, if the
+  `Code Mapping` column is empty or still a `{Namespace.Class}` placeholder,
+  surface it:
+  ```
+  ℹ models.md: Entity "ExpenseReport" has no Code Mapping yet — link it if the
+    code exists; if it is deliberately deferred, this is expected
+  ```
+- **Skip untouched seed rows by the name cell only**: a row whose name is still a
+  `{...}` placeholder is seed scaffolding. But a row with a **real name** and a
+  placeholder / empty Code Mapping is exactly the one to surface — do not skip it
+  just because that one cell still holds `{...}`.
+- This is **informational, not drift** — a recorded model with no Code Mapping is a
+  normal state before the code is written. An explicit "planned / deferred" note on
+  the row counts as accounted for; do not surface it.
 
 ## When to Run
 
@@ -178,9 +225,10 @@ Recommended trigger points (not enforced — developer's judgment):
 ## Path Assumptions
 
 This command operates entirely within `dflow/specs/domain/{context}/` files
-(`rules.md`, `behavior.md`, and the `events.md` bonus check). It does
-**not** read from `dflow/specs/features/active/{SPEC-ID}-{slug}/` directories
-— the feature directory layout is not part of verify's input.
+(`rules.md` and `behavior.md` for the core check; `events.md` and `models.md`
+for the optional hygiene warnings). It does **not** read from
+`dflow/specs/features/active/{SPEC-ID}-{slug}/` directories — the feature
+directory layout is not part of verify's input.
 
 ## Interaction with Other Commands
 

package/templates/greenfield/references/new-feature-flow.md

@@ -52,13 +52,36 @@ If it crosses contexts:
 - Do we need an Anti-Corruption Layer?"
 ```
 
+Once the BC is confirmed, classify and record its **Subdomain Type** as part
+of the same confirmation (not a separate gate):
+
+```
+"Is this capability core (差異化來源), supporting (必要但非差異化),
+or generic (可買 / 可套件 / 簡單 CRUD)? I'll record it in context-map.md."
+```
+
+If the BC already has a Subdomain Type in `context-map.md`, reuse it — don't
+re-ask unless the developer wants to reclassify. Record it in
+`dflow/specs/domain/context-map.md`:
+
+- If the **Subdomain Type column is missing** (an older context-map), add the
+  column **preserving every existing row** — do not rewrite their content.
+- The greenfield context-map is created at init, so the file normally exists;
+  if for any reason it is absent, create it from `templates/context-map.md`.
+
+The classification sets the modeling depth used in Step 3 (see
+`references/ddd-modeling-guide.md` § Subdomain-Aware Modeling Depth).
+
 **→ Transition (step-internal)**: Step 2 complete. Announce "Step 2 complete (BC identified). Entering Step 3: Domain Modeling." and continue.
 
 ## Step 3: Domain Modeling
 
 This is where the Greenfield Clean Architecture workflow diverges
 significantly from the Brownfield edition.
-Read `references/ddd-modeling-guide.md` for detailed patterns.
+Read `references/ddd-modeling-guide.md` for detailed patterns. Apply the
+modeling depth set by this BC's Subdomain Type from Step 2 (see that guide's
+§ Subdomain-Aware Modeling Depth): a `generic` context gets a thin model, not
+the full tactical treatment below.
 
 Walk through:
 
@@ -174,12 +197,17 @@ dflow/specs/features/active/{SPEC-ID}-{slug}/
    using `templates/phase-spec.md`. The "Delta from prior phases" section
    is filled with "首 phase，無前置 Delta" (first phase has nothing to
    delta against).
-4. **If this feature introduces a new Aggregate**, also create an
-   `aggregate-design.md` from `templates/aggregate-design.md` **inside this
-   feature directory** as the per-Aggregate design worksheet. It is a working
-   artifact scoped to the feature; the Aggregate's durable, long-lived catalog
-   entry still lives in `dflow/specs/domain/{context}/models.md`.
-   `aggregate-design.md` complements `models.md`, it does not replace it.
+4. **If this feature introduces a new Aggregate**, whether to create an
+   `aggregate-design.md` worksheet from `templates/aggregate-design.md`
+   **inside this feature directory** follows the BC's Subdomain Type (Step 2;
+   see `references/ddd-modeling-guide.md` § Subdomain-Aware Modeling Depth):
+   **core** → create it; **supporting** → create it but keep it lean;
+   **generic** → skip by default (a thin wrapper needs no design worksheet)
+   unless the developer explicitly opts into deeper modeling and records why.
+   When created, it is a working artifact scoped to the feature; the
+   Aggregate's durable, long-lived catalog entry still lives in
+   `dflow/specs/domain/{context}/models.md` — `aggregate-design.md`
+   complements `models.md`, it does not replace it.
 
 Key additions compared to Brownfield edition:
 - **Aggregate State Transitions**: Document how Aggregate state changes

package/templates/greenfield/references/new-phase-flow.md

@@ -95,7 +95,10 @@ Walk the developer through what the new phase covers:
    BRs (ADDED), changed BRs (MODIFIED), removed BRs (REMOVED), renamed
    (RENAMED). Items not mentioned stay UNCHANGED implicitly.
 3. **Any Aggregate / Domain concepts introduced or changed?** New
-   Aggregates, Value Objects, Domain Events, or invariants?
+   Aggregates, Value Objects, Domain Events, or invariants? Model new concepts
+   at the depth set by the BC's Subdomain Type (see
+   `references/ddd-modeling-guide.md` § Subdomain-Aware Modeling Depth) — don't
+   bypass the classification just because this is a phase, not a new feature.
 4. **Cross-context impact?** Does this phase introduce / change Domain
    Events that other contexts consume? (If yes, plan for `context-map.md`
    updates at finish-feature time.)

package/templates/greenfield/references/pr-review-checklist.md

@@ -116,7 +116,15 @@ If the closeout commit is in this PR (`/dflow:finish-feature` was run):
 
 ## Cross-Cutting
 
-- [ ] **Glossary consistency** — new terms documented?
+- [ ] **Glossary consistency** — any new business concept added to `glossary.md`?
+- [ ] **Naming matches the Ubiquitous Language** — for each **domain-facing** type
+      or member the diff introduces (skip DTO / test / framework names), is there a
+      matching term in `glossary.md`? The `Code Mapping` column maps each term to
+      its `{Namespace/Class/Member}` — a domain name in the diff with no glossary
+      term, or a term whose Code Mapping is now stale, is the signal.
+- [ ] **No synonym drift** — is the code naming a concept with a different word than
+      the glossary (e.g. "reimbursement" in code vs "報銷 / Expense Claim" in the
+      glossary)? Align it. (Judgment call, not a string match.)
 - [ ] **Context boundaries respected** — no reaching into another context's internals
 - [ ] **Domain Events documented** — events.md updated?
 - [ ] **Tests cover invariants** — not just happy path

package/templates/greenfield/scaffolding/AI-AGENT-GUIDE.md

@@ -313,34 +313,6 @@ are verified against the phase-spec before Step 7 completion.
 - Application tests: command / query handler behavior
 - Integration tests: repository, external services
 
-## Pre-V1 Artifacts Detection
-
-When working in a project that adopted Dflow before `dflow-sdd-ddd@0.1.0`,
-you may encounter layout or naming patterns that predate the V1 baseline.
-If any of the following appear, surface the observation to the developer
-and recommend manual migration; do not rewrite anything silently.
-
-Signals:
-
-- Top-level `specs/` directory containing Dflow-shaped content (V1 layout
-  uses `dflow/specs/`).
-- `_共用/` directory under `specs/` or `dflow/specs/` (V1 uses `shared/`).
-- Section headings in Traditional Chinese where V1 templates render
-  canonical English; compare against `TEMPLATE-LANGUAGE-GLOSSARY.md` if
-  available.
-- References to a runtime `/dflow:init-project` slash command (V1
-  replaced it with the Dflow CLI init command (`dflow init`, or
-  `npx dflow-sdd-ddd init` when using the no-install path)).
-- A root `CLAUDE.md`, `AGENTS.md`, or equivalent that holds the full
-  Dflow workflow text instead of being a thin shim pointing to this
-  file.
-- `dflow/specs/shared/_conventions.md` is missing the `> Dflow Version:`
-  front-matter line (V1 init writes it automatically).
-
-Recommend `docs/migrating-to-dflow-v1.md` for the manual migration
-checklist. Migration affects every spec the team has written; manual
-review is required.
-
 ## Workflow Steps
 
 This guide is the **command registry, routing rules, and project context**.

package/templates/greenfield/templates/aggregate-design.md

@@ -13,6 +13,12 @@ created: {YYYY-MM-DD}
 ## Invariants
 
 > 必須永遠為真的規則。這是 Aggregate 存在的理由。
+> 主體列 **boundary invariants**(需同時看到 Aggregate 內多個物件的狀態才能判的規則)。
+> 單一物件可判的 local constraint 不列這裡 — 純格式/必填走 Validator、有 domain
+> 語意走 VO / Entity constructor。跨 instance 的規則(唯一性、僅一筆 active)可列,
+> 但標 `set-based` 並在 Behavior on Violation 寫明 store-level guard(unique /
+> partial index、concurrency token;見 ddd-modeling-guide 的 Invariant
+> Classification 與 Set-Based 段)。
 
 | ID | Invariant | Behavior on Violation |
 |---|---|---|

package/templates/greenfield/templates/context-map.md

@@ -6,15 +6,24 @@
 
 ## Contexts
 
-| Bounded Context | Responsibility | Owner / Team | Primary Module | Notes |
-|---|---|---|---|---|
-| {Context name} | {業務責任} | {owner} | `{module/project}` | {optional notes} |
+| Bounded Context | Responsibility | Subdomain Type | Owner / Team | Primary Module | Notes |
+|---|---|---|---|---|---|
+| {Context name} | {業務責任} | core / supporting / generic | {owner} | `{module/project}` | {optional notes} |
+
+> **Subdomain Type** — 判別問句:「這塊功能換成現成 SaaS / 套件,系統的差異化會消失嗎?」
+> (差異化不限商業競爭優勢;內部系統指獨特的營運優勢 / 任務成果。)會 → `core`;
+> 不會、但需要為自家流程客製 → `supporting`(必要、常需客製、非差異化);
+> 不會、且現成方案存在 → `generic`。多數 BC 是 supporting,`core` 通常只有 1–2 個;
+> 全標 core = 沒分類。分類是可修訂的初判,改判時更新本欄並在 Notes 留一行理由。
+> 它決定建模深度(見 `references/ddd-modeling-guide.md`
+> § Subdomain-Aware Modeling Depth),但**不**降低 BR 紀錄、Tier ceremony、
+> 或安全 / 測試 / 可靠性要求。
 
 ## Relationships
 
 | Upstream | Downstream | Relationship Type | Published Language | ACL | Events |
 |---|---|---|---|---|---|
-| {Upstream context} | {Downstream context} | {Customer/Supplier, Conformist, ACL, Shared Kernel, etc.} | {shared terms / contract} | {Yes/No + location} | {event names or n/a} |
+| {Upstream context} | {Downstream context} | {Customer/Supplier, Conformist, ACL, Shared Kernel, Separate Ways, Big Ball of Mud (BBoM), OHS, etc.} | {shared terms / contract} | {Yes/No + location} | {event names or n/a} |
 
 ## Integration Notes
 

package/templates/greenfield/templates/events.md

@@ -12,7 +12,10 @@
 
 ## Event Flow Notes
 
-- {事件發生時序、交易邊界、重試或一致性注意事項}
+- {事件發生時序、交易邊界、重試或一致性注意事項;跨 aggregate 的 async(eventual
+  consistency)event chain,handler 重試耗盡的最終失敗若造成 business-visible 後果
+  (補償/權益/金流/庫存/合規/人工對帳)→ 升級為 BR/EC 寫進 behavior.md 與 spec,
+  best-effort 副作用(通知/logging)記這裡或 tech-debt 即可}
 
 ## Open Questions
 

package/docs/migrating-to-dflow-v1.md

@@ -1,234 +0,0 @@
-# Migrating to Dflow V1
-
-> **Audience**: maintainers of an existing project that adopted an early
-> Dflow form (pre-`dflow-sdd-ddd@0.1.0`) and want to align it with the
-> V1 baseline that ships from npm.
->
-> **Stance**: V1 took a clean cut. Dflow does not perform automatic
-> migration. This guide is a manual checklist. The CLI only warns when
-> it detects legacy paths; it does not modify existing files.
-
-> **Audience reality (2026-05-15)**: To date, the only known user of
-> this guide has been the **OBTS** migration (a single, completed
-> one-off). Dflow has not had broad pre-V1 adoption; this guide is
-> maintained as a contingency endpoint for `dflow doctor` and
-> `dflow init` warning messages, not as documentation of an active
-> migration program. If you reach this page via those tool outputs
-> and your case isn't covered below, please open a docs feedback issue
-> so the guide can be extended.
-
-## When You Need This Guide
-
-Skip this guide if you started using Dflow at `dflow-sdd-ddd@0.1.0`
-or later. Your project is already on the V1 baseline.
-
-Read this guide if any of the following are true:
-
-- Your project has a top-level `specs/` directory that holds Dflow
-  spec material (not the V1 `dflow/specs/`).
-- Your project has `specs/_共用/` instead of `dflow/specs/shared/`.
-- Your spec headings are in Traditional Chinese rather than the
-  canonical English vocabulary documented in
-  `TEMPLATE-LANGUAGE-GLOSSARY.md`.
-- Your AI instructions point teammates to `/dflow:init-project`
-  instead of the Dflow CLI init command (`dflow init`, or
-  `npx dflow-sdd-ddd init` on the no-install path).
-- Your `CLAUDE.md` (or equivalent root instruction file) was generated
-  by an early Dflow variant that wrote a full Claude-only file rather
-  than the V1 multi-AI thin shim that points to
-  `dflow/specs/shared/AI-AGENT-GUIDE.md`.
-
-You may need only some of these steps; the five sections below are
-independent.
-
-## Before You Start
-
-- Work on a dedicated branch or a disposable copy. None of the steps
-  are destructive, but move-and-rename mistakes are easier to recover
-  from a clean branch.
-- Make sure the working tree is clean (`git status`).
-- Note your current Dflow version if you can identify it. Older
-  internal Dflow forms may not have been versioned at all.
-- Open these V1 reference files for cross-checking:
-  - `TEMPLATE-LANGUAGE-GLOSSARY.md` — canonical English headings.
-  - `TEMPLATE-COVERAGE.md` — V1 file layout and parity matrix.
-  - `docs/evaluating-dflow.en.md` — what a fresh V1 `init` produces, if
-    you want to spin up a sample project to compare against.
-- For an on-demand read-only summary of legacy artifacts in your
-  project, run `dflow doctor` (or `npx dflow-sdd-ddd doctor` on the
-  no-install path). The command lists detected legacy paths and missing
-  V1 fields; it never modifies files.
-
-## Migration Steps
-
-### 1. Move root `specs/` to `dflow/specs/`
-
-V1 puts every Dflow-managed spec under `dflow/specs/`, so the `dflow/`
-directory becomes a single Dflow namespace separate from any
-unrelated `specs/` directory another tool may own (PROPOSAL-014).
-
-If your project has top-level `specs/` containing Dflow content:
-
-```bash
-mkdir -p dflow
-git mv specs dflow/specs
-git status
-```
-
-Commit the rename in a single commit. Avoid mixing the rename with
-content edits in the same commit so reviewers can read the diff
-cleanly.
-
-If you also have an unrelated `specs/` directory used by another
-tool, move only the Dflow material into `dflow/specs/`. The CLI will
-warn when it sees a non-Dflow `specs/` directory but will not modify
-it.
-
-### 2. Rename `_共用/` to `shared/`
-
-V1 uses canonical English directory names (PROPOSAL-012). If your
-project has `dflow/specs/_共用/`:
-
-```bash
-git mv dflow/specs/_共用 dflow/specs/shared
-git status
-```
-
-Update any cross-references in spec files or AI instructions. A
-project-wide grep after the rename catches leftover references:
-
-```bash
-grep -rn "_共用" .
-```
-
-### 3. Translate Chinese headings to canonical English
-
-V1 templates use canonical English structure for section headings,
-field labels, anchors, and placeholders (PROPOSAL-013). Free prose
-inside those sections may stay in your team language.
-
-This is the most labor-intensive step. Recommended approach:
-
-1. Open `TEMPLATE-LANGUAGE-GLOSSARY.md` for the heading-by-heading
-   mapping.
-2. For each generated spec file, replace Chinese H2 / H3 headings,
-   table column labels, and bold inline labels with their canonical
-   English form.
-3. Leave free prose (descriptions, decision rationale, task text) in
-   the team language. The Prose Language convention recorded in
-   `dflow/specs/shared/_conventions.md` applies here — see also
-   step 6 below.
-
-An AI assistant can walk through each spec file heading-by-heading
-faster than a global search-and-replace, because earlier Dflow
-adoption may have used slightly different wording per team. After
-translation, run a project-wide search for the most common Chinese
-headings to catch missed files. Adjust the search list to match the
-templates your team actually used:
-
-```bash
-grep -rn "## 業務規則\|## 行為情境\|## 領域模型" dflow/specs/
-```
-
-### 4. Switch the init entry point
-
-Pre-V1 documentation may have instructed teammates to start a Dflow
-project by running `/dflow:init-project` from inside an AI agent. V1
-removed that runtime slash command (PROPOSAL-014). The init flow now
-runs as a shell command. Install Dflow globally and run:
-
-```bash
-npm install -g dflow-sdd-ddd
-dflow init
-```
-
-If you cannot or do not want to install globally, use the no-install path:
-
-```bash
-npx dflow-sdd-ddd init
-```
-
-If you already have an initialized project, you do not need to re-run
-`init`. The other `/dflow:*` workflow commands (`/dflow:new-feature`,
-`/dflow:modify-existing`, `/dflow:bug-fix`, `/dflow:new-phase`,
-`/dflow:finish-feature`, `/dflow:verify`, `/dflow:pr-review`) are
-unchanged and continue to work.
-
-Update any team documentation, runbooks, or onboarding notes that
-still reference `/dflow:init-project` so new project setups use the
-shell command instead.
-
-### 5. Adopt multi-AI thin shims
-
-V1 separates the canonical project guide from each per-tool
-instruction file (PROPOSAL-020). The canonical guide lives at
-`dflow/specs/shared/AI-AGENT-GUIDE.md`. Per-tool files (`AGENTS.md`,
-`CLAUDE.md`, `.github/copilot-instructions.md`) are thin
-shims pointing at the canonical guide.
-
-If your project's `CLAUDE.md` (or equivalent) was generated by an
-early Dflow form that wrote a full file rather than a thin shim:
-
-```bash
-dflow configure-agents
-```
-
-This command adds shims for any AI tools you select. `dflow configure-agents`
-does not overwrite custom content in an existing root instruction file. If it
-recognizes an older Dflow-generated shim, it refreshes that file to the current
-thin shim in place; a file that already points to the guide is left as-is;
-otherwise it shows the change in the preview and appends a marked Dflow block to
-the existing file. It writes a manual-merge snippet under
-`dflow/specs/shared/<tool>-md-snippet.md` only when the file contains
-conflicting or malformed Dflow markers.
-
-If you prefer a fully clean V1 layout, archive the existing root
-instruction file under another name first, then run
-`dflow configure-agents` so it can write the new shim from scratch.
-
-## After Migration
-
-Verify the migrated project:
-
-- Ask the AI agent to run `/dflow:status` and confirm it can locate
-  Dflow flow material and report the project's current state.
-- Open `dflow/specs/shared/_conventions.md` and confirm a `## Prose
-  Language` section exists. If your project predates the
-  prose-language convention (PROPOSAL-015), add the section manually
-  with the correct BCP-47 language tag, for example `zh-TW` or `en`.
-- Run a final grep to confirm no legacy paths or terms remain inside
-  `dflow/specs/`. Adjust the term list to match your earlier Dflow
-  adoption:
-
-```bash
-grep -rn "_共用\|/dflow:init-project" dflow/specs/
-```
-
-## Out of Scope
-
-This guide stays manual on purpose. The items below are not part of
-V1 and may or may not arrive in a later release; do not rely on them
-when planning a migration today.
-
-- Automatic migration of legacy paths or headings.
-- A `dflow doctor` health check command.
-- A `dflow migrate` subcommand that edits files.
-- Automated translation of free prose between languages.
-
-If any of these would help your team, open a docs feedback issue so
-the request is recorded. The maintainer position is not to refuse
-them, only to keep V1 a clean cut.
-
-## Where To Go Next
-
-- `docs/evaluating-dflow.en.md` for what a fresh V1 `init` produces, in
-  case you want to compare against your migrated project.
-- Per-tool walkthroughs under `docs/` for the AI tool you use:
-  - `docs/using-with-claude-code.en.md`
-  - `docs/using-with-codex.en.md`
-- `TEMPLATE-COVERAGE.md` for the V1 logical / generated file parity
-  between Greenfield and Brownfield tracks.
-
-If something in this guide does not match your project's actual
-pre-V1 state, open a docs feedback issue. The guide can be extended
-as new edge cases come in.