dflow-sdd-ddd 0.3.0 → 0.5.0

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

@@ -31,6 +31,45 @@ are not available in the current AI tool:
 | `/dflow:verify` | Specs, domain docs, implementation, and tests need consistency checks. |
 | `/dflow:pr-review` | A change is ready for SDD/DDD review. |
 | `/dflow:report-dflow-feedback` | You found a Dflow issue or improvement and want a sanitized upstream feedback draft. |
+| `/dflow:status` | You need the current workflow state, current step, completed work, in-progress work, remaining work, pending decision, and next valid action. |
+| `/dflow:next` | An active workflow is waiting at a step gate and the developer confirms continuing to the next step. |
+| `/dflow:cancel` | The developer wants to abort the current workflow and return to free conversation without rollback. |
+
+Machine-readable source for rendering tool-specific thin wrappers:
+
+<!-- dflow-command-registry:start -->
+| id | label | description | arg-hint | scope |
+|---|---|---|---|---|
+| new-feature | /dflow:new-feature | Start a new user-visible feature or business behavior. | feature request | workflow |
+| modify-existing | /dflow:modify-existing | Change existing behavior. | change request | workflow |
+| bug-fix | /dflow:bug-fix | Investigate a defect described by expected vs actual behavior. | expected vs actual | workflow |
+| new-phase | /dflow:new-phase | Add another implementation slice to an active feature. | feature id or phase goal | workflow |
+| finish-feature | /dflow:finish-feature | Close implementation with drift checks and archived feature state. | feature id | workflow |
+| verify | /dflow:verify | Check specs, domain docs, implementation, and tests for consistency. | area or feature id | workflow |
+| pr-review | /dflow:pr-review | Review a ready change for SDD/DDD alignment. | change or branch | workflow |
+| report-dflow-feedback | /dflow:report-dflow-feedback | Draft sanitized upstream feedback about Dflow. | issue or improvement | workflow |
+| status | /dflow:status | Report current workflow state and next valid action. | - | control |
+| next | /dflow:next | Confirm the active step gate and continue. | - | control |
+| cancel | /dflow:cancel | Abort the active workflow and return to free conversation. | - | control |
+<!-- dflow-command-registry:end -->
+
+## Status / Control Commands
+
+`/dflow:status` reports active workflow state. Include these fields: workflow,
+step, completed, in-progress, remaining, pending decision, and next valid action.
+If no workflow is active, say that no workflow is active and list valid flow-entry
+or standalone commands.
+
+`/dflow:next` is valid only at a step gate in an active workflow. Treat it as
+developer confirmation equivalent to "OK" or "continue", then move to the next
+workflow step.
+
+`/dflow:cancel` aborts the current workflow and returns to free conversation.
+Do not rollback changes, delete artifacts, or rewrite specs merely because the
+workflow was cancelled.
+
+When no workflow is active, `/dflow:next` and `/dflow:cancel` must report that
+there is no active workflow to advance or cancel.
 
 ## Source of Truth
 
@@ -85,9 +124,9 @@ review is required.
 ## Tool-Specific Notes
 
 This file is the canonical Dflow guide. Root-level files such as
-`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, and `.github/copilot-instructions.md`
+`AGENTS.md`, `CLAUDE.md`, and `.github/copilot-instructions.md`
 should stay thin and point back here.
 
 If a tool does not support Dflow slash commands, treat the command names as
-plain workflow names and execute the matching process from the Dflow skill
-source in this repository.
+plain workflow names. This guide contains the installed runtime behavior
+contract; execute the workflow semantics defined here directly.

package/templates/brownfield/scaffolding/CLAUDE-md-snippet.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`。}
@@ -46,7 +48,7 @@ ASP.NET Core 做準備。
 ```
 dflow/specs/
 ├── shared/                   # 專案級治理文件（由 Dflow CLI init 寫入）
-│   ├── _overview.md          # 系統現況與遷移策略
+│   ├── _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
 
@@ -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`
 ```

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/                   # 專案級治理文件（由 dflow init 寫入）
-│   ├── _overview.md          # 系統現況與遷移策略
+│   ├── _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

@@ -131,9 +131,11 @@ Then {新的預期結果}
 
 ## 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
 
@@ -143,13 +145,13 @@ 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: Activity 4: Implementation Planning -->
 
@@ -178,13 +180,13 @@ Then {新的預期結果}
 > 格式：`[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

@@ -31,6 +31,45 @@ are not available in the current AI tool:
 | `/dflow:verify` | Specs, domain docs, implementation, and tests need consistency checks. |
 | `/dflow:pr-review` | A change is ready for SDD/DDD review. |
 | `/dflow:report-dflow-feedback` | You found a Dflow issue or improvement and want a sanitized upstream feedback draft. |
+| `/dflow:status` | You need the current workflow state, current step, completed work, in-progress work, remaining work, pending decision, and next valid action. |
+| `/dflow:next` | An active workflow is waiting at a step gate and the developer confirms continuing to the next step. |
+| `/dflow:cancel` | The developer wants to abort the current workflow and return to free conversation without rollback. |
+
+Machine-readable source for rendering tool-specific thin wrappers:
+
+<!-- dflow-command-registry:start -->
+| id | label | description | arg-hint | scope |
+|---|---|---|---|---|
+| new-feature | /dflow:new-feature | Start a new user-visible feature or business behavior. | feature request | workflow |
+| modify-existing | /dflow:modify-existing | Change existing behavior. | change request | workflow |
+| bug-fix | /dflow:bug-fix | Investigate a defect described by expected vs actual behavior. | expected vs actual | workflow |
+| new-phase | /dflow:new-phase | Add another implementation slice to an active feature. | feature id or phase goal | workflow |
+| finish-feature | /dflow:finish-feature | Close implementation with drift checks and archived feature state. | feature id | workflow |
+| verify | /dflow:verify | Check specs, domain docs, implementation, and tests for consistency. | area or feature id | workflow |
+| pr-review | /dflow:pr-review | Review a ready change for SDD/DDD alignment. | change or branch | workflow |
+| report-dflow-feedback | /dflow:report-dflow-feedback | Draft sanitized upstream feedback about Dflow. | issue or improvement | workflow |
+| status | /dflow:status | Report current workflow state and next valid action. | - | control |
+| next | /dflow:next | Confirm the active step gate and continue. | - | control |
+| cancel | /dflow:cancel | Abort the active workflow and return to free conversation. | - | control |
+<!-- dflow-command-registry:end -->
+
+## Status / Control Commands
+
+`/dflow:status` reports active workflow state. Include these fields: workflow,
+step, completed, in-progress, remaining, pending decision, and next valid action.
+If no workflow is active, say that no workflow is active and list valid flow-entry
+or standalone commands.
+
+`/dflow:next` is valid only at a step gate in an active workflow. Treat it as
+developer confirmation equivalent to "OK" or "continue", then move to the next
+workflow step.
+
+`/dflow:cancel` aborts the current workflow and returns to free conversation.
+Do not rollback changes, delete artifacts, or rewrite specs merely because the
+workflow was cancelled.
+
+When no workflow is active, `/dflow:next` and `/dflow:cancel` must report that
+there is no active workflow to advance or cancel.
 
 ## Source of Truth
 
@@ -85,9 +124,9 @@ review is required.
 ## Tool-Specific Notes
 
 This file is the canonical Dflow guide. Root-level files such as
-`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, and `.github/copilot-instructions.md`
+`AGENTS.md`, `CLAUDE.md`, and `.github/copilot-instructions.md`
 should stay thin and point back here.
 
 If a tool does not support Dflow slash commands, treat the command names as
-plain workflow names and execute the matching process from the Dflow skill
-source in this repository.
+plain workflow names. This guide contains the installed runtime behavior
+contract; execute the workflow semantics defined here directly.