dflow-sdd-ddd 0.2.0 → 0.4.0

package/templates/brownfield/scaffolding/CLAUDE-md-snippet.md

@@ -5,9 +5,9 @@
 > This file is a **snippet**, not a standalone `CLAUDE.md`. Its purpose
 > is to be merged into your project's root `CLAUDE.md`:
 >
-> - New `npx dflow-sdd-ddd init` output uses
->   `dflow/specs/shared/AI-AGENT-GUIDE.md` as the canonical guide and
->   creates a thin `CLAUDE.md` shim that points back to it.
+> - New Dflow CLI init output (`dflow init`, or `npx dflow-sdd-ddd init` when
+>   using the no-install path) uses `dflow/specs/shared/AI-AGENT-GUIDE.md` as
+>   the canonical guide and creates a thin `CLAUDE.md` shim that points back to it.
 > - Use this legacy snippet only if you intentionally want the older
 >   Claude-specific two-H2 layout in your project's root `CLAUDE.md`.
 
@@ -21,7 +21,7 @@ when merging into an existing `CLAUDE.md`.
 ## Snippet to merge into `CLAUDE.md`
 
 ```markdown
-# Project: {系統名稱} — ASP.NET WebForms
+# Project: {系統名稱} — {Framework}
 
 **重要：所有開發工作都必須遵循本文件定義的流程。**
 
@@ -33,10 +33,12 @@ when merging into an existing `CLAUDE.md`.
 
 ### Background
 
-這是一個運行中的 ASP.NET WebForms 系統，{一句話描述業務領域：例如
+這是一個運行中的既有系統，使用 {Framework} / {Language}，{一句話描述業務領域：例如
 「提供員工費用報銷」/「處理 HR 人事流程」/「訂單管理」}。採用 Dflow
-（SDD/DDD workflow guardian skill）引導開發流程，同時為未來遷移到
-ASP.NET Core 做準備。
+（SDD/DDD workflow guardian skill）引導開發流程，逐步將 business logic
+embedded in delivery/entrypoint code（presentation/UI layer、controllers、
+handlers、jobs、message consumers、data pipelines、stored procedures）抽離，
+並朝 target architecture 前進。
 
 {選填：補上團隊規模、使用者規模、主要 stakeholders 等 context，
 1-3 行即可。完整內容放在 `dflow/specs/shared/_overview.md`。}
@@ -45,8 +47,8 @@ ASP.NET Core 做準備。
 
 ```
 dflow/specs/
-├── shared/                   # 專案級治理文件（由 npx dflow-sdd-ddd init 寫入）
-│   ├── _overview.md          # 系統現況與遷移策略
+├── shared/                   # 專案級治理文件（由 Dflow CLI init 寫入）
+│   ├── _overview.md          # 系統現況與 target architecture
 │   ├── _conventions.md       # 規格撰寫慣例
 │   └── Git-principles-*.md   # Git 規範（gitflow 或 trunk 版）
 ├── domain/                   # 領域知識
@@ -68,12 +70,20 @@ dflow/specs/
     └── tech-debt.md
 
 src/
-├── Domain/                   # 抽離的領域邏輯（純 C#）
+├── Domain/                   # 抽離的領域邏輯（framework-pure）
 │   ├── {BoundedContext}/
 │   └── SharedKernel/
-└── Pages/                    # 既有 WebForms 頁面
+└── Delivery/                 # delivery-layer code（entrypoints, controllers, handlers）
 ```
 
+> **目錄命名說明**：上方 `src/Domain/` / `src/Delivery/` 是 Clean
+> Architecture 通用示意，不限 stack。請依專案實際慣例對應（例：Java/Spring 用
+> `src/main/java/com/example/domain/`、Node/TS 用 `src/domain/` /
+> `src/routes/`、Python 用 `domain/` package、Go 用 `internal/domain/` /
+> `internal/handler/`、.NET 用 `src/{Project}.Domain/` + `.csproj` 分層）。
+> 完整 per-stack 範例見 `docs/examples-by-stack.md`。重點是
+> `src/Domain/`（或對應命名）保持與 delivery/entrypoint code 獨立。
+
 ---
 
 ## Development Workflow
@@ -83,9 +93,9 @@ src/
 ### Core Principles
 
 1. **Spec Before Code** — 沒有規格就不寫實作（依 Ceremony Scaling 調整嚴謹度）
-2. **Domain Extraction** — 業務邏輯屬於 `src/Domain/`，不屬於 Code-Behind
+2. **Domain Extraction** — 業務邏輯屬於 `src/Domain/`，不屬於 delivery/entrypoint code
 3. **Ubiquitous Language** — 使用 `dflow/specs/domain/glossary.md` 中定義的術語
-4. **Migration Awareness** — 每個決策都要考慮未來 ASP.NET Core 遷移
+4. **Migration Awareness** — 每個決策都要考慮 target architecture
 
 ### Dflow Skill — Canonical Decision Logic Lives in the Skill
 
@@ -97,7 +107,7 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 當你作為 AI assistant 被呼叫時，若偵測到使用者需要 SDD/DDD 工作流
 引導，請參考 Dflow entry points：
 
-- `npx dflow-sdd-ddd init` — 專案初始化（建立 `dflow/specs/` 結構）
+- Dflow CLI init command (`dflow init`, or `npx dflow-sdd-ddd init` when using the no-install path) — 專案初始化（建立 `dflow/specs/` 結構）
 - `/dflow:new-feature` — 新功能開發
 - `/dflow:new-phase` — 在 active feature 內新增階段
 - `/dflow:modify-existing` — 修改既有功能
@@ -114,7 +124,7 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 
 - **Git 分支策略**：見 `dflow/specs/shared/Git-principles-{gitflow|trunk}.md`
 - **規格撰寫慣例**：見 `dflow/specs/shared/_conventions.md`
-- **系統現況與遷移**：見 `dflow/specs/shared/_overview.md`
+- **系統現況與 target architecture**：見 `dflow/specs/shared/_overview.md`
 - {其他專案特有規則，例如「JPY 金額必須以最小貨幣單位（yen）儲存」/
   「所有費用報銷需主管審核」/「跨時區行程以 UTC 記錄」}
 
@@ -122,18 +132,18 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 
 此目錄中的程式碼必須遵守（與 Dflow skill 的 Domain Layer Rules 一致）：
 
-- ❌ 不可引用 `System.Web` 或任何 WebForms 命名空間
+- ❌ 不可引用任何 delivery-framework 命名空間（例：HTTP 請求/回應物件、Session/Cookie context、job runner context、CLI flag parser、ViewState 類等）
 - ❌ 不可直接存取資料庫（使用 interface + Repository pattern）
-- ❌ 不可使用 `HttpContext`、`Session`、`ViewState`
+- ❌ 不可使用 delivery-framework runtime context（例：HTTP request/response、session/cookie、job runner state、CLI args）
 - ❌ 不可有 UI 相關邏輯
-- ✅ 純 C# 類別，可直接搬到 ASP.NET Core 專案
-- ✅ 所有公開行為都能在沒有 Web 基礎設施的情況下測試
+- ✅ 語言純粹的 class（不依賴 delivery framework），可直接搬到 target architecture
+- ✅ 所有公開行為都能在沒有 delivery infrastructure 的情況下測試
 
 ### AI Collaboration Notes
 
 - 遇到開發需求時，優先引導使用 `/dflow:` 命令
 - 回答 Domain 相關問題時，優先參考 `dflow/specs/domain/` 中的文件
-- 發現 Code-Behind 中的業務邏輯時，建議抽離到 `src/Domain/`
+- 發現 delivery/entrypoint code 中的業務邏輯時，建議抽離到 `src/Domain/`
 - 建立分支前，確認命名符合規範且對應 spec 存在
 - 詳細 Git 操作規則見 `dflow/specs/shared/Git-principles-{gitflow|trunk}.md`
 ```
@@ -162,5 +172,5 @@ When merging this snippet into an existing `CLAUDE.md`:
    duplicate it.
 
 If you are starting from scratch (no existing `CLAUDE.md`), the
-`npx dflow-sdd-ddd init` flow will install this snippet as-is and you
-can refine from there.
+the Dflow CLI init flow (`dflow init`, or `npx dflow-sdd-ddd init` when using
+the no-install path) will install this snippet as-is and you can refine from there.

package/templates/brownfield/scaffolding/Git-principles-gitflow.md

@@ -170,7 +170,7 @@ before making key Git operations:
       `behavior.md` reflect the feature's net BR changes
 - [ ] `dflow/specs/domain/glossary.md` updated with any new terms
 - [ ] `dflow/specs/migration/tech-debt.md` updated with any debt discovered
-- [ ] Domain layer (`src/Domain/`) has no `System.Web` references
+- [ ] Domain layer (`src/Domain/`) has no delivery-framework references
 
 ---
 

package/templates/brownfield/scaffolding/Git-principles-trunk.md

@@ -134,7 +134,7 @@ and circle the chosen one.
       `behavior.md` reflect the feature's net BR changes
 - [ ] `dflow/specs/domain/glossary.md` updated with any new terms
 - [ ] `dflow/specs/migration/tech-debt.md` updated with any debt discovered
-- [ ] Domain layer (`src/Domain/`) has no `System.Web` references
+- [ ] Domain layer (`src/Domain/`) has no delivery-framework references
 - [ ] CI green
 - [ ] PR has at least one review approval
 

package/templates/brownfield/scaffolding/_conventions.md

@@ -108,7 +108,7 @@ situations.
 |------------------------------|--------------------|-----|
 | {e.g. Year-end reporting tweak without BR change} | T2 | Touches logic path even though no new BR; extract to `lightweight-spec.md` for trace |
 | {e.g. Pure label / display text translation} | T3 | No BR change; inline row in `_index.md` |
-| {e.g. UI refresh across multiple pages} | T1 (project convention) | We treat multi-page UI refresh as T1 for this project even though Dflow default would be T2, because our WebForms UI changes often leak into Code-Behind |
+| {e.g. UI refresh across multiple entrypoints} | T1 (project convention) | We treat multi-entrypoint UI/API refresh as T1 for this project even though Dflow default would be T2, because these changes often leak into business logic embedded in delivery/entrypoint code (presentation/UI layer, controllers, handlers, jobs, message consumers, data pipelines, or stored procedures) |
 
 If the team disagrees on tier classification for a specific change,
 run through the T3 four-criteria checklist (in the Dflow skill) and

package/templates/brownfield/scaffolding/_overview.md

@@ -3,7 +3,7 @@
 # System Overview — {System Name}
 
 > Created: {YYYY-MM-DD}
-> Scope: current state and migration direction of {System Name}
+> Scope: current state and target-architecture direction of {System Name}
 > Audience: team members onboarding to the system + AI assistants reading
 > `dflow/specs/` for context.
 
@@ -30,33 +30,44 @@ delivers. Keep it non-technical enough that a new hire can skim it in
 
 ## Technical Architecture (Current)
 
-This project runs on ASP.NET WebForms. The SDD/DDD workflow is used to
-progressively prepare for migration (see "Migration Strategy" below).
+This project runs on {Framework}. The SDD/DDD workflow is used to
+progressively extract domain logic and prepare for the target architecture
+(see "Target Architecture Strategy" below).
 
 | Item | Current |
 |------|---------|
-| Framework | ASP.NET WebForms ({.NET Framework version}) |
-| Language | C# {version} |
+| Framework | {Framework} ({Framework version}) |
+| Language | {Language} |
 | Database | {e.g. SQL Server 2019, MySQL 8.0} |
-| ORM / data access | {e.g. Entity Framework 6, ADO.NET, stored procedures} |
-| UI | WebForms Pages + Code-Behind + {CSS framework if any} |
-| Auth | {e.g. Forms authentication, Windows auth} |
-| Hosting | {e.g. IIS on-prem, Azure App Service} |
+| ORM / persistence | {ORM / persistence} ({ORM version}) |
+| Delivery / entrypoint | {Framework} |
+| Auth | {e.g. session auth, OAuth/OIDC, API key, internal SSO} |
+| Hosting | {e.g. on-prem VM, container platform, managed app platform} |
 
 ### Code Layout (High Level)
 
+> **Note on directory naming**: The tree below uses generic Clean
+> Architecture folder names (`src/Domain/`, `src/Delivery/`). Adapt to your
+> stack's conventions — for example, Java/Spring `src/main/java/com/example/domain/`,
+> Node/TS `src/domain/` + `src/routes/`, Python `domain/` package, Go
+> `internal/domain/` + `internal/handler/`, PHP/Laravel `app/Domain/` +
+> `app/Http/`, .NET `src/{Project}.Domain/` + `src/{Project}.WebAPI/`
+> (separate `.csproj` per layer). For full per-stack examples see
+> `docs/examples-by-stack.md`.
+
 ```
 src/
-├── Domain/        # Extracted domain logic (pure C#; migration target)
+├── Domain/        # Extracted domain logic (framework-pure; target architecture)
 │   ├── {BoundedContext}/
 │   └── SharedKernel/
-└── Pages/         # WebForms pages (.aspx + Code-Behind)
+└── Delivery/      # delivery-layer code (entrypoints, controllers, handlers)
 ```
 
 The `src/Domain/` directory is where business logic lives **as it is
-extracted** from Code-Behind. Everything in `src/Domain/` must be pure
-C# with no `System.Web` dependencies (see `CLAUDE.md` and the Dflow
-skill for the full rule set).
+extracted** from delivery/entrypoint code (presentation/UI layer, controllers,
+handlers, jobs, message consumers, data pipelines, or stored procedures).
+Everything in `src/Domain/` must be framework-pure with no delivery-framework
+dependencies (see `CLAUDE.md` and the Dflow skill for the full rule set).
 
 ---
 
@@ -66,34 +77,34 @@ skill for the full rule set).
 top 3–5 known issues the team wants to address as part of migration.
 Link each to `migration/tech-debt.md` entries if they exist.}
 
-1. {e.g. Business logic scattered across Code-Behind; duplicated
-   calculations in multiple pages}
-2. {e.g. Direct SQL in Code-Behind; inconsistent error handling}
+1. {e.g. Business logic embedded in delivery/entrypoint code; duplicated
+   calculations across multiple flows}
+2. {e.g. Direct SQL in delivery/entrypoint code; inconsistent error handling}
 3. {e.g. Magic numbers / undocumented statuses}
 
 ---
 
-## Migration Strategy
+## Target Architecture Strategy
 
-This system is being prepared for migration to ASP.NET Core. The
-migration follows four principles; expand / adapt each to this project:
+This system is being prepared for the project's target architecture. The
+strategy follows four principles; expand / adapt each to this project:
 
-- **Migration Awareness** — Every feature decision considers future
-  migration. We ask "does this make the migration harder or easier?"
+- **Migration Awareness** — Every feature decision considers the target
+  architecture. We ask "does this make the target architecture harder or easier?"
 - **Domain Extraction** — Business logic gradually moves from
-  Code-Behind to `src/Domain/`. Each feature is an opportunity to
-  extract a little more.
+  delivery/entrypoint code to `src/Domain/`. Each feature is an
+  opportunity to extract a little more.
 - **Dual-Track Parallel** — We do not force-rewrite existing code; new
-  development preferentially uses the Domain layer, and legacy pages
+  development preferentially uses the Domain layer, and legacy entrypoints
   get touched only when they are being modified.
-- **Pragmatic First** — Migration does not block feature delivery. If
+- **Pragmatic First** — Target-architecture work does not block feature delivery. If
   a deadline is tight, record the debt in `migration/tech-debt.md`
   and continue.
 
-### Target Architecture (Post-Migration)
+### Target Architecture
 
-{1-2 sentences describing where this system is heading: e.g. "ASP.NET
-Core 8 + Clean Architecture + EF Core, deployed to Azure App Service."
+{1-2 sentences describing where this system is heading: e.g. "{Framework}
++ Clean Architecture + {ORM / persistence}, deployed to {hosting platform}."
 Link to any ADR or migration plan doc if one exists.}
 
 ---

package/templates/brownfield/templates/CLAUDE.md

@@ -1,4 +1,4 @@
-# Project: {系統名稱} — ASP.NET WebForms
+# Project: {系統名稱} — {Framework}
 
 **重要：所有開發工作都必須遵循本文件定義的流程。**
 
@@ -10,15 +10,15 @@
 
 ### Background
 
-這是一個運行中的 ASP.NET WebForms 系統，目前持續新增與修改功能。
-未來將遷移至 ASP.NET Core。目前採用 SDD 流程，同時為 DDD 做準備。
+這是一個運行中的既有系統，使用 {Framework} / {Language}，目前持續新增與修改功能。
+目前採用 SDD 流程，同時為 DDD 與 target architecture 做準備。
 
 ### Project Structure
 
 ```
 dflow/specs/
-├── shared/                   # 專案級治理文件（由 npx dflow-sdd-ddd init 寫入）
-│   ├── _overview.md          # 系統現況與遷移策略
+├── shared/                   # 專案級治理文件（由 dflow init 寫入）
+│   ├── _overview.md          # 系統現況與 target architecture
 │   └── _conventions.md       # 規格撰寫慣例與模板
 ├── domain/                   # 領域知識
 │   ├── glossary.md           # 術語表（Ubiquitous Language）
@@ -40,16 +40,24 @@ dflow/specs/
     └── tech-debt.md          # 技術債與遷移備忘
 
 src/
-├── Domain/                   # 抽離的領域邏輯（純 C#）
+├── Domain/                   # 抽離的領域邏輯（framework-pure）
 │   ├── {Context}/
 │   │   ├── Entities/
 │   │   ├── ValueObjects/
 │   │   ├── Services/
 │   │   └── Interfaces/
 │   └── SharedKernel/
-└── Pages/                    # 既有 WebForms 頁面
+└── Delivery/                 # delivery-layer code（entrypoints, controllers, handlers）
 ```
 
+> **目錄命名說明**：上方 `src/Domain/` / `src/Delivery/` 是 Clean
+> Architecture 通用示意，不限 stack。請依專案實際慣例對應（例：Java/Spring 用
+> `src/main/java/com/example/domain/`、Node/TS 用 `src/domain/` /
+> `src/routes/`、Python 用 `domain/` package、Go 用 `internal/domain/` /
+> `internal/handler/`、.NET 用 `src/{Project}.Domain/` + `.csproj` 分層）。
+> 完整 per-stack 範例見 `docs/examples-by-stack.md`。重點是
+> `src/Domain/`（或對應命名）保持與 delivery/entrypoint code 獨立。
+
 ---
 
 ## Development Workflow
@@ -58,9 +66,9 @@ src/
 
 ### Core Principles
 1. **Spec Before Code** — 沒有規格就不寫實作
-2. **Domain Extraction** — 業務邏輯屬於 `src/Domain/`，不屬於 Code-Behind
+2. **Domain Extraction** — 業務邏輯屬於 `src/Domain/`，不屬於 delivery/entrypoint code（presentation/UI layer、controllers、handlers、jobs、message consumers、data pipelines、stored procedures）
 3. **Ubiquitous Language** — 使用 `dflow/specs/domain/glossary.md` 中定義的術語
-4. **Migration Awareness** — 每個決策都要考慮未來 ASP.NET Core 遷移
+4. **Migration Awareness** — 每個決策都要考慮 target architecture
 
 ### Three Ceremony Tiers
 
@@ -81,8 +89,8 @@ src/
 1. 建 feature 目錄 `dflow/specs/features/active/{SPEC-ID}-{slug}/`
 2. 建 `_index.md`（feature dashboard）+ 第一份 `phase-spec-YYYY-MM-DD-{slug}.md`
 3. 識別涉及的領域概念，更新 `dflow/specs/domain/` 下的對應文件
-4. 盡可能將業務邏輯實作在 `src/Domain/` 中（純 C# class，不依賴 WebForms）
-5. Code-Behind 僅負責 UI 綁定，呼叫 Domain 層處理邏輯
+4. 盡可能將業務邏輯實作在 `src/Domain/` 中（語言純粹的 class，不依賴 delivery framework）
+5. Delivery/entrypoint code 僅負責輸入解析、協調流程與輸出綁定，呼叫 Domain 層處理邏輯
 6. 撰寫測試驗證 Domain 層行為符合規格
 
 ### New Phase
@@ -95,7 +103,7 @@ src/
 2. 若偵測到改動與 completed feature 相關，主動詢問是否為 follow-up
    （follow-up 走新建 feature + `follow-up-of` 鏈回原 feature；不把 T2/T3
    寫回 completed 目錄）
-3. 如果該功能的邏輯還在 Code-Behind 中，評估是否值得先抽離到 Domain 層
+3. 如果該功能的邏輯還在 delivery/entrypoint code 中，評估是否值得先抽離到 Domain 層
 4. 在 `dflow/specs/migration/tech-debt.md` 記錄發現的技術債
 
 ### Bug Fix
@@ -136,12 +144,12 @@ bugfix/{BUG-ID}-{short-description}      # Bug 修復（SDD 必須）
 ### Domain Layer Rules (`src/Domain/`)
 
 此目錄中的程式碼必須遵守：
-- ❌ 不可引用 `System.Web` 或任何 WebForms 命名空間
+- ❌ 不可引用任何 delivery-framework 命名空間（例：HTTP 請求/回應物件、Session/Cookie context、job runner context、CLI flag parser、ViewState 類等）
 - ❌ 不可直接存取資料庫（使用 interface + Repository pattern）
-- ❌ 不可使用 `HttpContext`、`Session`、`ViewState`
-- ❌ 不可有 UI 相關邏輯（格式化顯示、Page 引用）
-- ✅ 純 C# 類別，可直接搬到 ASP.NET Core 專案
-- ✅ 所有公開行為都能在沒有 Web 基礎設施的情況下測試
+- ❌ 不可使用 delivery-framework runtime context（例：HTTP request/response、session/cookie、job runner state、CLI args）
+- ❌ 不可有 UI / entrypoint 相關邏輯（格式化顯示、controller/page/handler 引用）
+- ✅ 語言純粹的 class（不依賴 delivery framework），可直接搬到 target architecture
+- ✅ 所有公開行為都能在沒有 delivery infrastructure 的情況下測試
 
 ### Glossary
 
@@ -152,6 +160,6 @@ bugfix/{BUG-ID}-{short-description}      # Bug 修復（SDD 必須）
 
 - 開發者提出任何功能需求時，先引導建立 spec
 - 在回答 Domain 相關問題時，優先參考 `dflow/specs/domain/` 中的文件
-- 發現 Code-Behind 中的業務邏輯時，建議抽離到 `src/Domain/`
+- 發現 delivery/entrypoint code 中的業務邏輯時，建議抽離到 `src/Domain/`
 - 每次開發循環結束時，提醒更新術語表和技術債記錄
 - 建立分支前，確認命名符合規範且對應 spec 存在

package/templates/brownfield/templates/context-definition.md

@@ -49,9 +49,9 @@ created: {YYYY-MM-DD}
 
 ## Code Mapping
 
-### Current WebForms
-- Pages: `src/Pages/{相關頁面}.aspx`
+### Current Delivery/Entrypoint Mapping
+- Delivery/entrypoint code: `{project/path/or/namespace}`
 - Domain: `src/Domain/{Context}/`
 
-### Future ASP.NET Core
-- 預計作為獨立模組/專案
+### Target Architecture
+- 預計作為 target architecture 中的獨立模組、服務、套件或 bounded context

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

@@ -2,7 +2,7 @@
 
 # Context Map
 
-> Optional bounded context relationship map for WebForms brownfield discovery.
+> Optional bounded context relationship map for Brownfield discovery.
 
 ## Context List
 

package/templates/brownfield/templates/lightweight-spec.md

@@ -69,7 +69,9 @@ Template note (for AI):
 
 > Keep T2 Light tasks concise. If the fix scope starts to expand, AI should pause and ask the developer whether to keep this as T2 or upgrade it to T1. Do not auto-upgrade based on task count alone.
 >
-> Recommended layer tags (WebForms): `DOMAIN` / `PAGE` / `DATA` / `TEST` / `DOC`
+> Recommended layer tags (Brownfield): `DOMAIN` / `DELIVERY` / `DATA` / `TEST` / `DOC`
+> (`DELIVERY` covers delivery/entrypoint code: presentation/UI layer, controllers,
+> handlers, jobs, message consumers, data pipelines, or stored procedures)
 
 - [ ] {LAYER}-1: {minimal required change}
 - [ ] TEST-1: {minimal verification / regression test}

package/templates/brownfield/templates/models.md

@@ -36,4 +36,4 @@
 
 ## Code Mapping Notes
 
-- {domain concept} maps to `{existing WebForms / EF / service code}`.
+- {domain concept} maps to `{existing delivery/entrypoint, persistence, or service code}`.

package/templates/brownfield/templates/phase-spec.md

@@ -19,30 +19,33 @@ Template note (for AI):
   `phase-spec-YYYY-MM-DD-{slug}.md` placed at
   `dflow/specs/features/active/{SPEC-ID}-{slug}/`.
 
-  Each section below carries an HTML comment indicating its fill-in phase (Phase 1-4).
-  These phase markers let /dflow:status and the completion checklist track progress.
-  Phases correspond to SKILL.md § Guiding Questions by Phase:
-    Phase 1 - Understanding (What & Why)
-    Phase 2 - Domain Analysis (Where does it live?)
-    Phase 3 - Spec Writing (Behavior + Rules + Edge Cases)
-    Phase 4 - Implementation Planning
-  The "Implementation Tasks" section at the end is generated by AI after Phase 4 planning is done
+  Each section below carries an HTML comment indicating its fill-in activity (Activity 1-4).
+  These activity markers let /dflow:status and the completion checklist track progress.
+  Activities correspond to SKILL.md § Guiding Questions by Activity:
+    Activity 1: Understanding (What & Why)
+    Activity 2: Domain Analysis (Where does it live?)
+    Activity 3: Spec Writing (Behavior + Rules + Edge Cases)
+    Activity 4: Implementation Planning
+  The "Implementation Tasks" section at the end is generated by AI after Activity 4 (Implementation Planning) is done
   (see new-feature-flow.md Step 5 end / new-phase-flow.md Step 4 end /
    modify-existing-flow.md Step 4 end).
 
+  Note: "phase 2+ specs" / "Phase 2+" in the BR and Delta sections below refers to
+  the N-th phase-spec of this feature (i.e. iteration unit), NOT an activity number.
+
   For phase 2+ specs in the same feature: only list BRs that are NEW or
   MODIFIED in this phase under "Business Rules"; do not re-copy unchanged BRs from
   prior phases. The cumulative state lives in the feature's `_index.md`
   Current BR Snapshot table.
 -->
 
-## Problem Description <!-- Fill timing: Phase 1 -->
+## Problem Description <!-- Fill timing: Activity 1: Understanding -->
 
 這個功能要解決什麼問題？誰需要它？
 
 > 用使用者的角度描述，避免技術用語。
 
-## Domain Concepts <!-- Fill timing: Phase 2 -->
+## Domain Concepts <!-- Fill timing: Activity 2: Domain Analysis -->
 
 涉及的 Domain 概念（引用 `dflow/specs/domain/{context}/models.md`）：
 
@@ -55,7 +58,7 @@ Template note (for AI):
 - [ ] `dflow/specs/domain/{context}/models.md` — 新增模型定義
 
 <!-- dflow:section behavior-scenarios -->
-## Behavior Scenarios <!-- Fill timing: Phase 3 -->
+## Behavior Scenarios <!-- Fill timing: Activity 3: Spec Writing -->
 
 ### Main Success Scenario
 
@@ -75,7 +78,7 @@ Scenario: {替代情境}
   Then {不同的預期結果}
 ```
 
-## Business Rules <!-- Fill timing: Phase 3 -->
+## Business Rules <!-- Fill timing: Activity 3: Spec Writing -->
 
 > Phase 2+ 注意：本段僅列**本 phase 新增 / 修改到的 BR**；未變動的 BR 不重抄
 > （它們的當前狀態見 feature 的 `_index.md` Current BR Snapshot 表）。
@@ -85,7 +88,7 @@ Scenario: {替代情境}
 | BR-01 | {規則描述} | |
 | BR-02 | {規則描述} | |
 
-## Delta from prior phases <!-- Fill timing: Phase 3; skip for the first phase -->
+## Delta from prior phases <!-- Fill timing: Activity 3: Spec Writing; skip for the first phase -->
 
 > 本段僅記**本 phase 相對前一 phase 的變化**，不累積歷史。歷史由 feature 目錄下
 > 各 phase-spec 的本段串接閱讀；feature 層的當前累積狀態見 `_index.md` 的
@@ -119,18 +122,20 @@ Then {新的預期結果}
 - BR-003 金額上限
 - BR-005 提交後不可修改
 
-## Edge Cases <!-- Fill timing: Phase 3 -->
+## Edge Cases <!-- Fill timing: Activity 3: Spec Writing -->
 
 | ID | Case | Expected Handling |
 |---|---|---|
 | EC-01 | {邊界描述} | {處理方式} |
 | EC-02 | {邊界描述} | {處理方式} |
 
-## Implementation Notes <!-- Fill timing: Phase 4 -->
+## Implementation Notes <!-- Fill timing: Activity 4: Implementation Planning -->
 
-### Current WebForms Implementation
+### Current Delivery-Layer Implementation
 
-> 在現有架構下如何實作？哪些 Code-Behind 會被修改？
+> 在現有架構下如何實作？哪些 business logic embedded in delivery/entrypoint code
+> （presentation/UI layer、controllers、handlers、jobs、message consumers、data
+> pipelines、stored procedures）會被修改？
 
 ### Domain Layer Design
 
@@ -140,15 +145,15 @@ Then {新的預期結果}
 // 關鍵 Domain 類別草稿
 ```
 
-### Keep Code-Behind Thin
+### Keep Delivery/Entrypoint Code Thin
 
-> Code-Behind 只負責：解析 UI 輸入 -> 呼叫 Domain 層 -> 顯示結果
+> Delivery/entrypoint code 只負責：解析輸入 -> 呼叫 Domain 層 -> 回傳或顯示結果
 
-### Future ASP.NET Core Migration Considerations
+### Target Architecture Considerations
 
-> 遷移時需要注意的事項，或者現在的設計如何幫助未來遷移。
+> target architecture 需要注意的事項，或者現在的設計如何幫助後續演進。
 
-## Data Structure Changes <!-- Fill timing: Phase 4 -->
+## Data Structure Changes <!-- Fill timing: Activity 4: Implementation Planning -->
 
 > 涉及的資料表與欄位變更（如有）
 
@@ -156,7 +161,7 @@ Then {新的預期結果}
 |---|---|---|---|
 | {Table} | {Column} | 新增/修改/刪除 | |
 
-## Test Strategy <!-- Fill timing: Phase 4 -->
+## Test Strategy <!-- Fill timing: Activity 4: Implementation Planning -->
 
 > Domain 層的單元測試應驗證哪些行為？
 
@@ -164,24 +169,24 @@ Then {新的預期結果}
 - [ ] {測試案例 2}
 
 <!-- dflow:section open-questions -->
-## Open Questions <!-- Fill timing: Phase 1-4 -->
+## Open Questions <!-- Fill timing: Activity 1-4; any time during planning -->
 
 - {尚未釐清的需求、規則、資料或實作問題}
 
 <!-- dflow:section implementation-tasks -->
-## Implementation Tasks <!-- Fill timing: generated by AI after Phase 4; all items should be checked at completion -->
+## Implementation Tasks <!-- Fill timing: generated by AI after Activity 4: Implementation Planning; all items should be checked at completion -->
 
-> AI 在 Phase 4 實作規劃完成後，根據「Implementation Notes」產生的具體任務清單。
+> AI 在 Activity 4 (Implementation Planning) 完成後，根據「Implementation Notes」產生的具體任務清單。
 > 格式：`[LAYER]-[NUMBER]: 任務描述`
 > 分類標籤（Brownfield track）：
 >   - `DOMAIN`  — Domain 層類別、VO、Service、Interface
->   - `PAGE`    — Code-Behind / ASPX 變更
+>   - `DELIVERY` — Delivery-layer code（entrypoints, controllers, handlers, UI/API adapters）
 >   - `DATA`    — 資料表 schema 或 Repository 實作
 >   - `TEST`    — 測試案例
 > 本段在 spec 歸檔（搬到 `completed/`）前應確認全部勾選，或明確標註未完成項的 follow-up。
 
 - [ ] DOMAIN-1: {任務描述}
 - [ ] DOMAIN-2: {任務描述}
-- [ ] PAGE-1: {任務描述}
+- [ ] DELIVERY-1: {任務描述}
 - [ ] DATA-1: {任務描述}
 - [ ] TEST-1: {任務描述}

package/templates/brownfield/templates/tech-debt.md

@@ -2,13 +2,13 @@
 
 # Migration Tech Debt
 
-> WebForms migration debt backlog discovered during SDD/DDD work.
+> Target-architecture debt backlog discovered during SDD/DDD work.
 
 ## Debt Items
 
 | Item | Location | Description | Severity | Migration impact | Status |
 |---|---|---|---|---|---|
-| {Debt item} | `{file/path/or/namespace}` | {問題描述} | {Low/Medium/High/Critical} | {對 WebForms -> Core 遷移的影響} | {open/planned/in-progress/done} |
+| {Debt item} | `{file/path/or/namespace}` | {問題描述} | {Low/Medium/High/Critical} | {對 target architecture 的影響} | {open/planned/in-progress/done} |
 
 ## Follow-up Notes
 

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

@@ -70,7 +70,8 @@ Signals:
   canonical English; compare against `TEMPLATE-LANGUAGE-GLOSSARY.md` if
   available.
 - References to a runtime `/dflow:init-project` slash command (V1
-  replaced it with the shell command `npx dflow-sdd-ddd init`).
+  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.