dflow-sdd-ddd 0.1.0

package/templates/webforms/scaffolding/_conventions.md

@@ -0,0 +1,139 @@
+<!-- Scaffolding template maintained alongside Dflow skill. See proposals/PROPOSAL-010 for origin. -->
+
+# Spec Writing Conventions — {System Name}
+
+> Created: {YYYY-MM-DD}
+> Scope: how spec documents are authored and named in this project.
+> Audience: engineers writing specs; AI assistants producing spec drafts.
+
+This file captures **project-level** conventions only. Template shapes
+and Ceremony criteria are defined by the Dflow skill; here we just
+record how *this* project fills them in.
+
+---
+
+## Where Specs Live
+
+All spec documents live under `dflow/specs/`. The feature directory pattern
+and file names follow Dflow (see the Dflow skill § "Project Structure
+Reference" for the full tree):
+
+```
+dflow/specs/features/active/{SPEC-ID}-{slug}/
+├── _index.md                              # Feature dashboard
+├── phase-spec-{YYYY-MM-DD}-{slug}.md      # T1 Heavy (one per phase)
+└── lightweight-{YYYY-MM-DD}-{slug}.md     # T2 Light (or BUG-{NUMBER}-{slug}.md)
+```
+
+T3 Trivial changes do **not** produce a separate file — they are
+recorded as one row in `_index.md` Lightweight Changes.
+
+## Prose Language
+
+Project prose language: `{prose-language}`
+
+Dflow templates keep canonical English structural language: headings,
+table headers, fixed labels, placeholders, IDs, anchors, and code-facing
+terms remain English.
+
+Free prose written inside those sections should follow the project prose
+language:
+
+- `en`: write free prose in English.
+- `zh-TW`: write free prose in Traditional Chinese.
+- `{xx-XX}`: write free prose in that explicit BCP-47 language.
+
+Do not translate code identifiers, DDD pattern names, BR IDs, SPEC IDs,
+file paths, branch names, anchors, or inline code only to satisfy the
+prose-language setting.
+
+### SPEC-ID Format
+
+- Pattern: `SPEC-YYYYMMDD-NNN` (e.g. `SPEC-20260421-001`)
+- Per-day counter `NNN` resets daily, starts at `001`
+- Once assigned, the SPEC-ID is immutable — it appears in the feature
+  directory name, the first phase-spec filename, and the git branch
+  name (see `Git-principles-*.md`)
+
+### Slug Conventions (Project-Specific Fill-In)
+
+- **Language**: follow the language the feature is discussed in (Dflow
+  skill policy); no translation is forced. Both Chinese and English
+  slugs are valid.
+- **Project-specific term list**: {fill in project-specific abbreviation
+  conventions here, e.g. "payroll → pr", "expense report → exp-rpt"
+  if your team has house-style shortenings; otherwise leave this
+  section empty}
+- **Length target**: 2–4 English words or 2–6 Chinese characters
+  (Dflow skill guidance)
+
+---
+
+## Filling the Templates
+
+Dflow ships these templates (do **not** re-inline their content here
+— always read the canonical template from the skill):
+
+| Template | Used when |
+|----------|-----------|
+| `templates/_index.md`          | Creating a feature directory (every feature) |
+| `templates/phase-spec.md`      | T1 Heavy — new feature / new phase / architectural change |
+| `templates/lightweight-spec.md`| T2 Light — bug fix / small tweak with BR Delta |
+| `templates/context-definition.md` | When a new Bounded Context is introduced |
+| `templates/behavior.md`        | BC-level consolidated behavior spec |
+
+Project-specific guidance when filling these templates:
+
+- {e.g. "Always reference existing BRs in the BR Snapshot inherited
+  column if the feature extends existing rules. Check `dflow/specs/domain/
+  {context}/rules.md` first."}
+- {e.g. "For financial scenarios, currency and precision must be
+  explicit in every Given/When/Then."}
+- {e.g. "When a phase-spec touches the Expense context, mention
+  Payroll integration in Delta if the rule affects month-end
+  processing."}
+
+---
+
+## Ceremony Scaling (Project Application)
+
+The Dflow skill defines three tiers — **T1 Heavy / T2 Light / T3
+Trivial**. See the Dflow skill § "Ceremony Scaling" for the full
+criteria table. We do not re-define the tier criteria here; this
+section records how *this* project applies them in borderline
+situations.
+
+| Situation (project-specific) | Tier we default to | Why |
+|------------------------------|--------------------|-----|
+| {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 |
+
+If the team disagrees on tier classification for a specific change,
+run through the T3 four-criteria checklist (in the Dflow skill) and
+record the decision here the first time it arises.
+
+---
+
+## Glossary Consistency
+
+All business terms in spec documents must use names defined in
+`dflow/specs/domain/glossary.md`. When a new term appears:
+
+1. Check glossary first
+2. If missing, add it **before** using the term in a spec
+3. Cross-reference the BC the term belongs to
+
+This rule is enforced by the Dflow skill during `/dflow:new-feature`
+and `/dflow:new-phase` flows; the project-level convention is simply
+"don't bypass the glossary update."
+
+---
+
+## Related Documents
+
+- [System overview](_overview.md)
+- [Git principles](Git-principles-{gitflow|trunk}.md)
+- [Glossary](../domain/glossary.md)
+- Dflow skill SKILL.md — canonical source for Ceremony Scaling, flow
+  selection, and template shapes.

package/templates/webforms/scaffolding/_overview.md

@@ -0,0 +1,109 @@
+<!-- Scaffolding template maintained alongside Dflow skill. See proposals/PROPOSAL-010 for origin. -->
+
+# System Overview — {System Name}
+
+> Created: {YYYY-MM-DD}
+> Scope: current state and migration direction of {System Name}
+> Audience: team members onboarding to the system + AI assistants reading
+> `dflow/specs/` for context.
+
+This file is a **project-level starting point**. It does not duplicate
+Dflow's workflow rules (see `CLAUDE.md` and the Dflow skill for those) —
+it captures the unique context of *this* system so that new engineers (or
+AI) can quickly understand what they are working on.
+
+---
+
+## System Summary
+
+{One paragraph: what this system does, who uses it, what business value it
+delivers. Keep it non-technical enough that a new hire can skim it in
+30 seconds.}
+
+### Business Domain
+
+- **Primary domain**: {e.g. expense management, HR, order processing}
+- **Key stakeholders**: {e.g. finance team, HR admins, end-user employees}
+- **User scale**: {e.g. ~200 internal users, 5 countries}
+
+---
+
+## 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).
+
+| Item | Current |
+|------|---------|
+| Framework | ASP.NET WebForms ({.NET Framework version}) |
+| Language | C# {version} |
+| 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} |
+
+### Code Layout (High Level)
+
+```
+src/
+├── Domain/        # Extracted domain logic (pure C#; migration target)
+│   ├── {BoundedContext}/
+│   └── SharedKernel/
+└── Pages/         # WebForms pages (.aspx + Code-Behind)
+```
+
+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).
+
+---
+
+## Existing Issues / Known Pain Points
+
+{Optional but strongly recommended for brownfield adoption. List the
+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}
+3. {e.g. Magic numbers / undocumented statuses}
+
+---
+
+## Migration Strategy
+
+This system is being prepared for migration to ASP.NET Core. The
+migration 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?"
+- **Domain Extraction** — Business logic gradually moves from
+  Code-Behind 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
+  get touched only when they are being modified.
+- **Pragmatic First** — Migration does not block feature delivery. If
+  a deadline is tight, record the debt in `migration/tech-debt.md`
+  and continue.
+
+### Target Architecture (Post-Migration)
+
+{1-2 sentences describing where this system is heading: e.g. "ASP.NET
+Core 8 + Clean Architecture + EF Core, deployed to Azure App Service."
+Link to any ADR or migration plan doc if one exists.}
+
+---
+
+## Related Documents
+
+- [Spec conventions](_conventions.md)
+- [Git principles](Git-principles-{gitflow|trunk}.md) — choose the
+  branching-strategy-specific file that matches this project
+- [Glossary](../domain/glossary.md)
+- [Tech debt backlog](../migration/tech-debt.md)
+- Dflow skill: see `CLAUDE.md` and the `sdd-ddd-webforms-skill/` bundle
+  for the full AI workflow guidance.

package/templates/webforms/templates/CLAUDE.md

@@ -0,0 +1,157 @@
+# Project: {系統名稱} — ASP.NET WebForms
+
+**重要：所有開發工作都必須遵循本文件定義的流程。**
+
+---
+
+## System Context
+
+> 技術棧、業務領域、目錄結構
+
+### Background
+
+這是一個運行中的 ASP.NET WebForms 系統，目前持續新增與修改功能。
+未來將遷移至 ASP.NET Core。目前採用 SDD 流程，同時為 DDD 做準備。
+
+### Project Structure
+
+```
+dflow/specs/
+├── shared/                   # 專案級治理文件（由 npx dflow-sdd-ddd init 寫入）
+│   ├── _overview.md          # 系統現況與遷移策略
+│   └── _conventions.md       # 規格撰寫慣例與模板
+├── domain/                   # 領域知識
+│   ├── glossary.md           # 術語表（Ubiquitous Language）
+│   └── {context}/            # 按 Bounded Context 分
+│       ├── context.md        # Context 邊界與職責
+│       ├── models.md         # 領域模型定義
+│       └── rules.md          # 業務規則目錄
+├── features/
+│   ├── active/               # 進行中的 feature
+│   │   └── {SPEC-ID}-{slug}/ # 一個 feature 一個目錄
+│   │       ├── _index.md     # Feature dashboard：Goals & Scope / Phase Specs / Current BR Snapshot / Lightweight Changes / Resume Pointer
+│   │       ├── phase-spec-YYYY-MM-DD-{slug}.md   # T1 Heavy：每 phase 一份
+│   │       └── lightweight-YYYY-MM-DD-{slug}.md  # T2 Light（或 BUG-NNN-{slug}.md）
+│   ├── completed/            # 整個 feature 目錄 git mv 到這裡
+│   └── backlog/              # 待處理
+│   # SPEC-ID 格式：SPEC-YYYYMMDD-NNN；slug 跟隨討論語言（中文/英文皆可）
+│   # T3 無獨立檔，只在 _index.md Lightweight Changes 寫一列
+└── migration/
+    └── tech-debt.md          # 技術債與遷移備忘
+
+src/
+├── Domain/                   # 抽離的領域邏輯（純 C#）
+│   ├── {Context}/
+│   │   ├── Entities/
+│   │   ├── ValueObjects/
+│   │   ├── Services/
+│   │   └── Interfaces/
+│   └── SharedKernel/
+└── Pages/                    # 既有 WebForms 頁面
+```
+
+---
+
+## Development Workflow
+
+> SDD 流程、Git 整合、Domain 層規範、術語表、AI 協作
+
+### Core Principles
+1. **Spec Before Code** — 沒有規格就不寫實作
+2. **Domain Extraction** — 業務邏輯屬於 `src/Domain/`，不屬於 Code-Behind
+3. **Ubiquitous Language** — 使用 `dflow/specs/domain/glossary.md` 中定義的術語
+4. **Migration Awareness** — 每個決策都要考慮未來 ASP.NET Core 遷移
+
+### Three Ceremony Tiers
+
+不是每次修改都要跑完整流程。AI 依下列判準選 tier：
+
+- **T1 Heavy** — 新功能、新 phase、架構變動、新增 BR → 建獨立 phase-spec，
+  走 `/dflow:new-feature` 或 `/dflow:new-phase`
+- **T2 Light** — bug fix、UI 輸入驗證、流程分支修改（有 BR Delta 但無 Domain /
+  資料結構變動）→ 建獨立 lightweight spec 置於 feature 目錄內
+- **T3 Trivial** — 按鈕顏色、文案修正、typo、排版、純註解（無 BR 變動、
+  無 Domain 概念動、無資料結構動、只改 UI 表層 / 註解 / 格式化）→
+  只在 `_index.md` Lightweight Changes inline 寫一列
+
+純 typo / 純格式化 commit（`dotnet format` / `prettier` 自動整理）**低於 T3**：
+直接 `git commit`，不走 Dflow。
+
+### New Feature
+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 層處理邏輯
+6. 撰寫測試驗證 Domain 層行為符合規格
+
+### New Phase
+1. 在已啟動的 active feature 上新增一份 phase-spec（含 Delta-from-prior-phases）
+2. 更新 `_index.md` 的 Phase Specs 表 + regenerate Current BR Snapshot
+3. 嚴格只適用於 active feature；completed 的 feature 不接受新 phase
+
+### Modify Existing
+1. AI 依 T1 / T2 / T3 判準分流
+2. 若偵測到改動與 completed feature 相關，主動詢問是否為 follow-up
+   （follow-up 走新建 feature + `follow-up-of` 鏈回原 feature；不把 T2/T3
+   寫回 completed 目錄）
+3. 如果該功能的邏輯還在 Code-Behind 中，評估是否值得先抽離到 Domain 層
+4. 在 `dflow/specs/migration/tech-debt.md` 記錄發現的技術債
+
+### Bug Fix
+1. 建立輕量規格（問題 + 現有行為 + 預期行為 + 修復方式）
+2. 若 bug 不附掛既有 feature，先建最小 feature 目錄再放 lightweight-spec
+3. 修 Bug 時順便記錄發現的技術債
+
+### Feature Closeout
+1. 驗證 feature 目錄內所有 phase-spec `status: completed`
+2. 把 `_index.md` Current BR Snapshot 同步到 BC 層 `rules.md` / `behavior.md`
+3. `git mv` 整個 feature 目錄從 `active/` 搬到 `completed/`
+4. 產出 Integration Summary（Git-strategy-neutral；不自動 merge）
+
+### Git Integration
+
+> 本流程只規定 SDD 必要的最小 Git 耦合（feature branch per feature、
+> `git mv`、commit 對應 SPEC-ID）。實際採用的分支策略（Git Flow /
+> GitHub Flow / trunk-based / 單一 main）由專案決定，不在此強制。
+> 若採用 Git Flow，可參考 `scaffolding/Git-principles-gitflow.md` 範本。
+
+**分支命名**
+```
+feature/{SPEC-ID}-{short-description}    # 新功能（SDD 必須）
+bugfix/{BUG-ID}-{short-description}      # Bug 修復（SDD 必須）
+```
+
+**Commit Message**
+```
+[SPEC-ID] 簡述變更
+```
+
+**分支規則**
+- **feature/** — 必須先有 spec 才能開始編碼
+- **bugfix/** — 至少要有輕量 spec
+- **`/dflow:bug-fix`** 不綁定任何分支策略；採 Git Flow 的專案可選擇把
+  緊急修復放在 `hotfix/` 分支，但這是專案決策，Dflow 不代為規定
+
+### Domain Layer Rules (`src/Domain/`)
+
+此目錄中的程式碼必須遵守：
+- ❌ 不可引用 `System.Web` 或任何 WebForms 命名空間
+- ❌ 不可直接存取資料庫（使用 interface + Repository pattern）
+- ❌ 不可使用 `HttpContext`、`Session`、`ViewState`
+- ❌ 不可有 UI 相關邏輯（格式化顯示、Page 引用）
+- ✅ 純 C# 類別，可直接搬到 ASP.NET Core 專案
+- ✅ 所有公開行為都能在沒有 Web 基礎設施的情況下測試
+
+### Glossary
+
+所有業務術語必須使用 `dflow/specs/domain/glossary.md` 中定義的名稱。
+遇到新術語時，先新增到術語表再使用。
+
+### AI Collaboration Notes
+
+- 開發者提出任何功能需求時，先引導建立 spec
+- 在回答 Domain 相關問題時，優先參考 `dflow/specs/domain/` 中的文件
+- 發現 Code-Behind 中的業務邏輯時，建議抽離到 `src/Domain/`
+- 每次開發循環結束時，提醒更新術語表和技術債記錄
+- 建立分支前，確認命名符合規範且對應 spec 存在

package/templates/webforms/templates/_index.md

@@ -0,0 +1,110 @@
+---
+spec-id: SPEC-{YYYYMMDD}-{NNN}
+slug: {slug-following-discussion-language}
+status: in-progress    # in-progress | completed
+created: {YYYY-MM-DD}
+branch: feature/{SPEC-ID}-{slug}
+# follow-up-of: {原 SPEC-ID}    # 選用：本 feature 為某個已 completed feature 的 follow-up 時填入
+---
+
+<!--
+Template note (for AI):
+  This is the **feature-level dashboard** (`_index.md`) for a feature
+  directory. Place at `dflow/specs/features/active/{SPEC-ID}-{slug}/_index.md`.
+
+  Six required sections (see below):
+    1. Metadata (YAML front matter above)
+    2. Goals & Scope (prose)
+    3. Phase Specs (T1 list)
+    4. Current BR Snapshot (feature-level cumulative state)
+    5. Lightweight Changes (T2 outbound link + T3 inline)
+    6. Resume Pointer
+
+  Optional section (append at end if applicable):
+    - Follow-up Tracking (when this feature has follow-up features derived)
+
+  Refresh discipline for "Current BR Snapshot":
+    - Regenerate when /dflow:new-phase enters
+    - Regenerate when a phase-spec is finalized (completed)
+    - Regenerate when a T2 lightweight-spec is finalized
+    - This table is the feature-level CURRENT STATE (not history).
+      History lives in each phase-spec's "Delta from prior phases" section.
+      The system-level current state lives in the bounded context's
+      rules.md / behavior.md, synced at /dflow:finish-feature.
+
+  Minimal usage:
+    For a 1-commit / 1-phase feature this template can be ~30 lines —
+    fill metadata + a short Goals & Scope + one row in Phase Specs +
+    initial BR Snapshot + Resume Pointer. The other sections can stay empty.
+-->
+
+# {Feature Title}
+
+## Goals & Scope
+
+> 1-3 段：本 feature 解決什麼問題？為誰解決？邊界在哪？
+>
+> 若是 follow-up feature，AI 會在頂部自動加註：
+> 「本 feature 為 `{原 SPEC-ID}-{原 slug}` 的 follow-up，原 feature 完成於
+>  `{date}`，詳見 `completed/{原 SPEC-ID}-{原 slug}/_index.md`」
+
+## Phase Specs
+
+> T1 Heavy ceremony 產出的 phase-spec 列表（一份 phase-spec ≈ 一次完整
+> Kickoff → Domain → Design → Build → Verify 循環）。
+
+| Phase | Date | Slug | Status | File Link |
+|---|---|---|---|---|
+| 1 | {YYYY-MM-DD} | {phase-slug} | in-progress / completed | [phase-spec-{date}-{phase-slug}.md](./phase-spec-{date}-{phase-slug}.md) |
+
+<!-- dflow:section current-br-snapshot -->
+## Current BR Snapshot
+
+> Feature 層的 BR 當前狀態（不是歷史）。AI 在以下時機 regenerate 本表：
+> - `/dflow:new-phase` 進入時
+> - 完成一份 phase-spec 時
+> - T2 lightweight spec 定稿時
+>
+> 歷史由各 phase-spec 的「Delta from prior phases」段串接閱讀；feature
+> 完成時 `/dflow:finish-feature` 把本表推進到對應 BC 的 `rules.md` /
+> `behavior.md`（延續 Step 8.3 既有 sync 機制）。
+
+| BR-ID | Current Rule | First Seen (phase) | Last Updated (phase) | Status |
+|---|---|---|---|---|
+| BR-01 | {規則描述} | phase-1 / inherited from rules.md | phase-N | active / removed |
+
+<!-- dflow:section lightweight-changes -->
+## Lightweight Changes
+
+> T2 行：描述含「見 `lightweight-{date}-{slug}.md`」外連
+> T3 行：inline 完整描述一句話 + 標籤（如 `[cosmetic]` / `[text]` /
+>        `[format]`）；T3 不產獨立 spec 檔
+>
+> Tier 判準見 SKILL.md § Ceremony Scaling 三層表。
+
+| Date | Tier | Description | Commit |
+|---|---|---|---|
+| {YYYY-MM-DD} | T2 | bug fix XYZ — 見 [`lightweight-{date}-{slug}.md`](./lightweight-{date}-{slug}.md) | {hash} |
+| {YYYY-MM-DD} | T3 | 按鈕顏色從藍改綠 `[cosmetic]` | {hash} |
+
+## Resume Pointer
+
+> 一句話：目前進展到哪？下一個動作是什麼？
+> 開新對話接續工作時，從這裡讀起。
+
+**Current Progress**: {one-line summary}
+
+**Next Action**: {suggested next action}
+
+<!--
+## Follow-up Tracking
+>（選用段；只有當本 feature 衍生出 follow-up feature 時才填）
+> 由 `/dflow:new-feature` / `/dflow:modify-existing` 在新建 follow-up
+> feature 時自動更新；新 feature 完成時 `/dflow:finish-feature` 反向更新
+> 該列 Status 欄為 `completed`。
+> 連結權威是新 feature 的 `follow-up-of` 欄；本表為衍生索引。
+
+| SPEC-ID | slug | Created | Status |
+|---|---|---|---|
+| SPEC-{YYYYMMDD}-{NNN} | {slug} | {YYYY-MM-DD} | in-progress / completed |
+-->

package/templates/webforms/templates/behavior.md

@@ -0,0 +1,58 @@
+# {Bounded Context} — Behavior Specification
+
+> **Purpose**: Consolidated source of truth for this context's current behavior.
+> Unlike `dflow/specs/features/completed/` (historical archive), this file always reflects
+> the **current** system behavior — what the system does right now.
+>
+> **Maintenance**: AI updates this file during the completion flow (Step 8.3 / Step 6.3).
+> When a feature is completed, merge its Given/When/Then scenarios here.
+> When behavior is modified, update the corresponding section using the Delta result
+> (not the Delta markup — merge the final state).
+>
+> **Relationship to rules.md**: `rules.md` is the declarative index (BR-ID + one-line summary).
+> This file is the scenario-level detail. Each BR-ID in `rules.md` should have a
+> corresponding section here. If they drift, `/dflow:verify` will catch it.
+
+---
+
+<!-- dflow:section behavior-scenarios -->
+## {Feature Area 1}
+
+### BR-001: {Rule Name}
+
+Given {initial state}
+When {action}
+Then {expected result}
+
+### BR-002: {Rule Name}
+
+Given {initial state}
+When {action}
+Then {expected result}
+
+#### Edge cases
+
+- EC-001: Given {edge case state} When {action} Then {handling}
+
+---
+
+## {Feature Area 2}
+
+### BR-003: {Rule Name}
+
+Given {initial state}
+When {action}
+Then {expected result}
+
+---
+
+<!-- 
+Maintenance notes:
+- Organize by feature area, not by spec ID (specs are transient; behavior areas are stable)
+- When merging a completed spec, place its scenarios under the matching feature area
+- When a MODIFIED delta changes a rule, update the scenario here to reflect the NEW behavior
+  (git history preserves the old version — don't keep "原本/改為" pairs here)
+- When a REMOVED delta drops a rule, delete the corresponding section
+- When a RENAMED delta renames a concept, update all references in this file
+- Keep BR-IDs in sync with rules.md
+-->

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

@@ -0,0 +1,57 @@
+---
+context: {ContextName}
+chinese-name: {中文名稱}
+owner: {負責的開發者或團隊}
+created: {YYYY-MM-DD}
+---
+
+# {ContextName} Bounded Context
+
+## Responsibilities
+
+> 這個 Context 負責什麼？用 2-3 句話描述。
+
+## Boundaries
+
+### In Scope
+- {職責 1}
+- {職責 2}
+
+### Out of Scope
+- {排除項 1} → 由 {OtherContext} 處理
+- {排除項 2} → 由 {OtherContext} 處理
+
+## Core Domain Models
+
+> 詳細定義在 `models.md`，這裡只列出概覽。
+
+### Entities
+- **{EntityName}** — {一句話描述}
+
+### Value Objects
+- **{VOName}** — {一句話描述}
+
+### Domain Services
+- **{ServiceName}** — {一句話描述}
+
+## Interactions with Other Contexts
+
+| Other Context | Interaction Type | Description |
+|---|---|---|
+| {OtherContext} | 呼叫 / 事件 / 共享資料 | {描述} |
+
+## Key Business Rules
+
+> 規則索引在 `rules.md`（BR-ID + 一行摘要），完整 Behavior Scenarios 在 `behavior.md`（Given/When/Then）。這裡只列最重要的幾條。
+
+1. {最重要的規則}
+2. {第二重要的規則}
+
+## Code Mapping
+
+### Current WebForms
+- Pages: `src/Pages/{相關頁面}.aspx`
+- Domain: `src/Domain/{Context}/`
+
+### Future ASP.NET Core
+- 預計作為獨立模組/專案

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

@@ -0,0 +1,25 @@
+<!-- Template maintained by Dflow. See proposals/PROPOSAL-013 for origin. -->
+
+# Context Map
+
+> Optional bounded context relationship map for WebForms brownfield discovery.
+
+## Context List
+
+| Bounded Context | Responsibility | Owner / Team | Primary Code Area | Notes |
+|---|---|---|---|---|
+| {Context name} | {業務責任} | {owner} | `{project/path/or/namespace}` | {optional notes} |
+
+## Relationships
+
+| Source Context | Target Context | Relationship Type | Integration Mechanism | Notes |
+|---|---|---|---|---|
+| {Source} | {Target} | {Customer/Supplier, Conformist, ACL, Shared Kernel, etc.} | {DB table, service call, file, manual process} | {optional notes} |
+
+## Integration Notes
+
+- {跨 context 的資料流、權責邊界或 legacy coupling}
+
+## Open Questions
+
+- {尚未釐清的 context 邊界或整合責任}

package/templates/webforms/templates/glossary.md

@@ -0,0 +1,15 @@
+<!-- Template maintained by Dflow. See proposals/PROPOSAL-013 for origin. -->
+
+# Glossary
+
+> Ubiquitous Language for this project or bounded context.
+
+## Terms
+
+| Term | Definition | Bounded Context | Code Mapping | Notes |
+|---|---|---|---|---|
+| {Term} | {這個術語在業務中的定義} | {Context name} | `{Namespace/Class/Member}` | {optional notes} |
+
+## Open Questions
+
+- {需要和 domain expert 確認的術語或命名差異}