dflow-sdd-ddd 0.3.0 → 0.4.0

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/CLAUDE-md-snippet.md

@@ -29,7 +29,7 @@ keeps every project's `CLAUDE.md` scannable for AI in the same shape.
 ## Snippet to merge into `CLAUDE.md`
 
 ```markdown
-# Project: {系統名稱} — ASP.NET Core + DDD
+# Project: {系統名稱} — Clean Architecture + DDD
 
 **重要：所有開發工作都必須遵循本文件定義的流程。**
 
@@ -45,8 +45,8 @@ keeps every project's `CLAUDE.md` scannable for AI in the same shape.
 - **Users / Customers**: {使用者 / 客戶描述}
 - **Team**: {團隊組成；e.g. "全端工程團隊，3-5 人；DDD 經驗中等"}
 - **Dflow Adoption Context**: {新專案 greenfield / 既有系統導入 / 遷移等}
-- **Tech Stack**: ASP.NET Core {版本}；EF Core / MediatR / {其他};
-  .NET {版本}
+- **Tech Stack**: {Framework} {Framework version}；{ORM / persistence} {ORM version} / {Mediator} / {其他};
+  {Language}
 
 ### Architecture (Clean Architecture)
 
@@ -60,7 +60,7 @@ Presentation → Application → Domain ← Infrastructure
 |---|---|---|
 | Domain | 業務規則、Aggregate、Value Object、Domain Event | 依賴外部套件、存取資料庫、處理 HTTP |
 | Application | 編排領域操作、CQRS、驗證、DTO | 包含業務邏輯、直接存取資料庫 |
-| Infrastructure | EF Core、外部 API、檔案存取 | 包含業務邏輯 |
+| Infrastructure | {ORM / persistence}、外部 API、檔案存取 | 包含業務邏輯 |
 | Presentation | HTTP 端點、Request/Response | 包含業務邏輯、直接操作 Domain 物件 |
 
 ### Project Structure
@@ -120,7 +120,7 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 
 ### Domain Layer Rules (Hard Invariants)
 
-- ❌ 不可有任何 NuGet 套件依賴（純 .NET 類型）
+- ❌ 不可有任何外部套件依賴（語言純粹 types）
 - ❌ 不可有 ORM 屬性（`[Table]`、`[Column]` 等）
 - ❌ 不可有序列化屬性（`[JsonProperty]` 等）
 - ❌ 不可有 `DbContext`、`IConfiguration`、`HttpClient`
@@ -133,7 +133,7 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 
 {此段由專案自行填入。例如：}
 
-- **本專案使用 MediatR 做 Command / Query dispatch**，Application 層
+- **本專案使用 {Mediator} 做 Command / Query dispatch（若適用）**，Application 層
   Command / Query Handler 命名為 `{Name}CommandHandler` /
   `{Name}QueryHandler`
 - **整合測試使用 {Testcontainers / WebApplicationFactory / 其他}**；

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

@@ -174,7 +174,7 @@ Before making key Git operations:
       `context-map.md` reflect the feature's net changes
 - [ ] `dflow/specs/domain/glossary.md` updated with any new terms
 - [ ] `dflow/specs/architecture/tech-debt.md` updated with any debt discovered
-- [ ] Domain project has zero external NuGet dependencies
+- [ ] Domain project has zero external package dependencies
 - [ ] No ORM / serialization attributes on Domain entities
 - [ ] Domain unit tests pass (invariants + value object equality)
 
@@ -334,7 +334,7 @@ exists, e.g. `.github/workflows/ci.yml` or `azure-pipelines.yml`.}
 
 ### Suggested CI gates for Clean Architecture
 
-- Verify Domain project has zero (or allow-listed) NuGet deps
+- Verify Domain project has zero (or allow-listed) external package deps
 - Run Domain unit tests + Application tests on every PR
 - Run Integration tests on `develop` and `release/*` branches
 - Verify EF migrations build cleanly

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

@@ -249,7 +249,7 @@ Before making key Git operations:
       `context-map.md` reflect the feature's net changes
 - [ ] `dflow/specs/domain/glossary.md` updated with any new terms
 - [ ] `dflow/specs/architecture/tech-debt.md` updated with any debt discovered
-- [ ] Domain project has zero external NuGet dependencies
+- [ ] Domain project has zero external package dependencies
 - [ ] No ORM / serialization attributes on Domain entities
 - [ ] Domain unit tests pass (invariants + value object equality)
 - [ ] CI is green (all required checks passing)
@@ -359,7 +359,7 @@ exists, e.g. `.github/workflows/ci.yml` or `azure-pipelines.yml`.}
 
 ### Suggested CI gates for Clean Architecture
 
-- Verify Domain project has zero (or allow-listed) NuGet deps
+- Verify Domain project has zero (or allow-listed) external package deps
 - Run Domain unit tests + Application tests on every PR
 - Run Integration tests on `main` and pre-deploy
 - Verify EF migrations build cleanly

package/templates/greenfield/scaffolding/_overview.md

@@ -30,19 +30,18 @@ delivers. Keep it non-technical enough that a new hire can skim it in
 
 ## Technical Architecture
 
-This project is an ASP.NET Core application built with **Clean
-Architecture** and **Domain-Driven Design (DDD)**. Dependencies flow
-inward only — the Domain layer is the core and depends on nothing.
+This project follows **Clean Architecture** and **Domain-Driven Design
+(DDD)**. Dependencies flow inward only — the Domain layer is the core
+and depends on nothing.
 
 ### Stack
 
 | Item | Choice |
 |------|--------|
-| Runtime | .NET {version, e.g. 8} |
-| Language | C# {version, e.g. 12} |
-| Web framework | ASP.NET Core (Web API / Minimal API — {which}) |
-| ORM | Entity Framework Core {version} |
-| Mediator | {e.g. MediatR, internal CQRS dispatcher, or none} |
+| Language | {Language} |
+| Framework | {Framework} {Framework version} |
+| ORM / persistence | {ORM / persistence} {ORM version} |
+| Mediator | {Mediator} (or none) |
 | Validation | {e.g. FluentValidation} |
 | Database | {e.g. PostgreSQL 16, SQL Server 2022} |
 | Auth | {e.g. JWT bearer, OIDC via Azure AD, cookie auth} |
@@ -57,13 +56,32 @@ Presentation  →  Application  →  Domain  ←  Infrastructure
 
 | Layer | Responsibilities | Must NOT |
 |-------|------------------|----------|
-| Domain | Aggregates, Entities, Value Objects, Domain Events, Domain Services, repository interfaces | Depend on any NuGet package outside allowed list; know about EF Core, HTTP, DI containers |
+| Domain | Aggregates, Entities, Value Objects, Domain Events, Domain Services, repository interfaces | Depend on package-manager libraries outside the project's allow-list; know about ORM/persistence frameworks, HTTP, DI containers |
 | Application | Commands / Queries (CQRS), Validators, DTOs, Event Handlers, orchestration | Contain business logic; access database directly |
-| Infrastructure | EF Core `DbContext` + configurations, repository implementations, external API clients | Contain business logic |
+| Infrastructure | ORM / persistence configuration, repository implementations, external API clients | Contain business logic |
 | Presentation | HTTP endpoints, Request / Response mapping, auth + middleware | Contain business logic; expose Domain objects directly |
 
 ### Project Layout
 
+> **Note**: The project layout below uses .NET/C# conventions —
+> project-level namespaces like `{Project}.Domain` and a separate `.csproj`
+> per layer. This is shown as a concrete example so you can see "what a
+> real Clean Architecture layout looks like".
+>
+> If this project's stack is **not** .NET, this layout does **not**
+> literally apply — translate to the conventions of your stack:
+>
+> - Java/Spring: `com.example.domain` / `com.example.application` packages, often a multi-module Maven/Gradle build
+> - Node/TypeScript: `src/domain/` / `src/application/` folders, monorepo workspaces optional
+> - Python: `domain/` / `application/` packages
+> - Go: `internal/domain/` / `internal/application/`
+> - PHP/Laravel: `app/Domain/` / `app/Application/`
+>
+> For full per-stack examples, see `docs/examples-by-stack.md`. If the
+> convention for your stack is unclear, consult authoritative sources
+> for the stack (e.g., its official project structure guide) or ask the
+> developer before placing code.
+
 ```
 src/
 ├── {Project}.Domain/
@@ -147,7 +165,7 @@ format / MADR / other}.
 Initial ADRs that typically exist:
 
 - **ADR-0001** — Choice of ORM / persistence approach
-- **ADR-0002** — CQRS + MediatR vs direct handlers
+- **ADR-0002** — CQRS + mediator/dispatcher vs direct handlers
 - **ADR-0003** — Auth strategy
 
 ---

package/templates/greenfield/templates/CLAUDE.md

@@ -1,4 +1,4 @@
-# Project: {系統名稱} — ASP.NET Core + DDD
+# Project: {系統名稱} — Clean Architecture + DDD
 
 **重要：所有開發工作都必須遵循本文件定義的流程。**
 
@@ -10,7 +10,7 @@
 
 ### Background
 
-這是一個使用 Clean Architecture 和 Domain-Driven Design 的 ASP.NET Core 系統。
+這是一個遵循 Clean Architecture 與 Domain-Driven Design 的新建專案；具體 stack 詳見 `dflow/specs/shared/_overview.md`。
 採用 SDD 流程，所有開發工作必須遵循本文件定義的流程。
 
 ### Architecture (Clean Architecture)
@@ -27,7 +27,7 @@ Presentation → Application → Domain ← Infrastructure
 |---|---|---|
 | Domain | 業務規則、Aggregate、Value Object、Domain Event | 依賴外部套件、存取資料庫、處理 HTTP |
 | Application | 編排領域操作、CQRS、驗證、DTO | 包含業務邏輯、直接存取資料庫 |
-| Infrastructure | EF Core、外部 API、檔案存取 | 包含業務邏輯 |
+| Infrastructure | {ORM / persistence}、外部 API、檔案存取 | 包含業務邏輯 |
 | Presentation | HTTP 端點、Request/Response | 包含業務邏輯、直接操作 Domain 物件 |
 
 ### Project Structure
@@ -35,7 +35,7 @@ Presentation → Application → Domain ← Infrastructure
 ```
 dflow/specs/
 ├── shared/                   # 專案級治理文件（由 dflow init 寫入）
-│   ├── _overview.md          # 系統現況與遷移策略
+│   ├── _overview.md          # 系統概覽與架構方向
 │   └── _conventions.md       # 規格撰寫慣例
 ├── domain/
 │   ├── glossary.md
@@ -154,7 +154,7 @@ bugfix/{BUG-ID}-{short-description}      # Bug 修復（SDD 必須）
 
 ### Domain Layer Rules
 
-- ❌ 不可有任何 NuGet 套件依賴（純 .NET 類型）
+- ❌ 不可有任何外部套件依賴（語言純粹 types）
 - ❌ 不可有 ORM 屬性（[Table], [Column] 等）
 - ❌ 不可有序列化屬性（[JsonProperty] 等）
 - ❌ 不可有 DbContext、IConfiguration、HttpClient