dflow-sdd-ddd 0.7.0 → 0.9.0

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

@@ -0,0 +1,288 @@
+# New Phase Workflow — Greenfield Clean Architecture
+
+Step-by-step guide for when a developer triggers `/dflow:new-phase` —
+adding a new phase-spec to an **active** feature directory.
+
+A phase-spec captures one full "Kickoff → Domain → Design → Build → Verify"
+cycle. A feature can have N phase-specs over its lifetime; together they
+build up the feature in iterations. The `_index.md` dashboard aggregates
+their state.
+
+**Distinction from `/dflow:new-feature`**: this command does NOT create a
+branch and does NOT create a feature directory. Both must already exist
+(produced by the original `/dflow:new-feature` invocation). This command
+adds a new phase to an in-progress feature only.
+
+**Step Gates** in this flow (stop-and-confirm before proceeding):
+- Step 3 → Step 4 (phase scope confirmed → write the phase-spec)
+- Step 4 → Step 5 (phase-spec drafted → refresh `_index.md`)
+- Step 5 → Step 6 (`_index.md` refreshed → start implementation)
+- Step 6 → Step 7 (implementation done → complete the phase)
+
+All other step transitions are **step-internal**: announce "Step N complete,
+entering Step N+1" and proceed without waiting. See SKILL.md § Workflow
+Transparency for the full transparency protocol and confirmation signals.
+
+## Step 1: Read Active Feature Context
+
+Before producing any spec prose, read `dflow/specs/shared/_conventions.md`
+and apply the `## Prose Language` setting. If the setting is missing or not
+an explicit language tag, ask the developer to update `_conventions.md`
+before continuing.
+
+AI must locate the target feature and load its current state:
+
+1. **Identify the target feature**
+   - If the developer is on a `feature/{SPEC-ID}-{slug}` branch → infer the
+     feature directory at `dflow/specs/features/active/{SPEC-ID}-{slug}/`
+   - Otherwise → ask the developer which feature this phase is for
+
+2. **Refuse if the feature is in `completed/`**
+
+   `/dflow:new-phase` strictly applies to **active features only**. If the
+   target feature directory is found at `dflow/specs/features/completed/...`
+   instead of `dflow/specs/features/active/...`, refuse with:
+
+   ```
+   "Feature `{SPEC-ID}-{slug}` is in completed/ — completed features are
+   frozen history and cannot accept new phases.
+
+   If you need to extend this feature's behavior, run /dflow:modify-existing
+   and choose the 'follow-up' branch — that creates a new follow-up feature
+   with a fresh SPEC-ID and a `follow-up-of: {SPEC-ID}` link back to this
+   one."
+   ```
+
+   Do NOT offer to `git mv` the feature back to `active/` — that breaks the
+   completed = frozen-history semantic and produces confusing dir-rename
+   history. The follow-up path is the only correct route.
+
+3. **Load context for the new phase**
+   - Read the feature's `_index.md` — Metadata, Goals & Scope, Phase Specs,
+     Current BR Snapshot, Resume Pointer
+   - Read the most recent phase-spec to understand where the prior phase
+     left off (its Business Rules and Delta-from-prior-phases sections in
+     particular)
+   - Cross-reference the bounded context's `dflow/specs/domain/{context}/rules.md`
+     and `behavior.md` if the new phase is likely to touch system-level
+     state (BC-level current state lives there, not in `_index.md`)
+
+4. **Branch gate — ensure you are on this feature's branch (before any commit)**
+
+   This phase's commits must land on the active feature's
+   `feature/{SPEC-ID}-{slug}` branch. If you are not already on it (you
+   identified the feature by name, or are on a base / unrelated branch),
+   switch to the existing branch — or override and record it in the
+   `_index.md` Checkpoint Log. **Never create a new feature branch here:**
+   `new-phase` extends an existing active feature, it does not start one. See
+   `references/git-integration.md` § Commit Checkpoints, Branch Gate & AI
+   Commits.
+
+Share what you found:
+
+> "OK — `{SPEC-ID}-{slug}` has {N} prior phases in BC `{context}`. The
+> most recent (phase-{N}) ended with {一句話 from Resume Pointer}. Current BR
+> Snapshot has {count} active BRs. Ready to scope the new phase."
+
+**→ Transition (step-internal)**: Step 1 complete. Announce "Step 1 complete (active feature context loaded). Entering Step 2: Confirm Phase Scope." and continue.
+
+## Step 2: Confirm the Phase Scope
+
+Walk the developer through what the new phase covers:
+
+1. **What does this phase add or change?** Plain-language description.
+2. **Which BRs are touched?** Compare against the current BR Snapshot. New
+   BRs (ADDED), changed BRs (MODIFIED), removed BRs (REMOVED), renamed
+   (RENAMED). Items not mentioned stay UNCHANGED implicitly.
+3. **Any Aggregate / Domain concepts introduced or changed?** New
+   Aggregates, Value Objects, Domain Events, or invariants?
+4. **Cross-context impact?** Does this phase introduce / change Domain
+   Events that other contexts consume? (If yes, plan for `context-map.md`
+   updates at finish-feature time.)
+5. **Data structure impact?** New tables, columns, indices, EF
+   configuration changes?
+6. **Why now?** Priority — informs sequencing relative to other phases.
+
+This is also the moment to ask: "Should this be its own follow-up feature
+instead of a phase here?" — useful when the scope drift suggests a
+separate concern (different Aggregate, different BC, etc.).
+
+**→ Transition (step-internal)**: Step 2 complete. Announce "Step 2 complete (phase scope agreed). Entering Step 3: Phase Slug Confirmation." and continue.
+
+## Step 3: Phase Slug Confirmation
+
+AI proposes the new phase-spec filename and asks the developer to confirm
+before any file is written.
+
+> "Proposed phase-spec for `{SPEC-ID}-{slug}`:
+>
+>     phase-spec-{YYYY-MM-DD}-{phase-slug}.md
+>
+> Phase slug follows our discussion language (中文/英文皆可). Do you want
+> to keep `{phase-slug}`, or use a different slug?"
+
+Slug rules (matches the feature-level slug rule):
+- Follows the language the developer / AI discuss the phase in (no forced
+  translation)
+- Keep it short (2–4 words / 2–6 中文字)
+- Avoid characters that would break filesystems on the developer's
+  platform (slashes, colons, etc.)
+
+Wait for the developer to confirm before proceeding.
+
+**→ Step Gate: Step 3 → Step 4**
+
+Announce to developer:
+> "Phase slug confirmed as `{phase-slug}`. Ready to draft the phase-spec
+> (`phase-spec-{date}-{phase-slug}.md`) — I'll cover problem / domain
+> modeling / behavior (with Aggregate transitions + Events) / business
+> rules / Delta-from-prior-phases / edge cases / layer-by-layer
+> implementation plan? `/dflow:next` to proceed, or adjust the scope
+> first."
+
+Wait for confirmation before entering Step 4.
+
+## Step 4: Write the Phase Spec
+
+Create the file at:
+
+```
+dflow/specs/features/active/{SPEC-ID}-{slug}/phase-spec-{YYYY-MM-DD}-{phase-slug}.md
+```
+
+Use the `templates/phase-spec.md` template and set the phase-spec
+frontmatter `status` to `in-progress`. Phase-2-onward specs **must** fill
+in the **Delta from prior phases** section (the first phase typically has
+just "首 phase，無前置 Delta"; this is phase 2+, so the section is required).
+
+Walk the developer through each section, in the same way `new-feature-flow`
+Step 4 does — Behavior (with Aggregate state transitions and Domain
+Events) / Business Rules / Delta / Edge Cases / Domain Events / layer-by-
+layer implementation plan — but only list NEW or MODIFIED BRs in Business Rules;
+UNCHANGED BRs from prior phases stay in the Current BR Snapshot table on
+`_index.md` and are NOT re-copied here. The Delta section uses the same
+ADDED / MODIFIED / REMOVED / RENAMED + optional UNCHANGED format defined
+in `references/modify-existing-flow.md` (Aggregate state transitions and
+Domain Events go in the Given/When/Then within each Delta entry).
+
+After the spec body is drafted, generate the `Implementation Tasks` section
+(format `[LAYER]-[NUMBER]：description` with Core layer tags
+DOMAIN / APP / INFRA / API / TEST — see `new-feature-flow.md` Step 5 for
+the detailed list, recommended order: DOMAIN → APP → INFRA → API).
+
+**→ Step Gate: Step 4 → Step 5**
+
+Announce to developer:
+> "Phase-spec drafted at
+> `dflow/specs/features/active/{SPEC-ID}-{slug}/phase-spec-{date}-{phase-slug}.md`.
+> Ready to refresh `_index.md` (add Phase Specs row, regenerate Current BR
+> Snapshot from the Delta)? `/dflow:next` to proceed."
+
+> Commit checkpoint (per `references/git-integration.md` § Commit Checkpoints, Branch Gate & AI Commits): with the Step 1 branch gate satisfied (you are on the feature's branch), offer to commit the phase-spec baseline and record the result in the `_index.md` Checkpoint Log.
+
+Wait for confirmation before entering Step 5.
+
+## Step 5: Refresh `_index.md`
+
+Update the feature's `_index.md`:
+
+1. **Phase Specs table** — add a new row for this phase:
+   ```
+   | {N+1} | {YYYY-MM-DD} | {phase-slug} | in-progress | [phase-spec-{date}-{phase-slug}.md](./phase-spec-{date}-{phase-slug}.md) |
+   ```
+
+2. **Current BR Snapshot table** — regenerate to reflect the new phase's
+   Delta:
+   - **ADDED** entries → new rows (First Seen = `phase-{N+1}`, Last Updated =
+     `phase-{N+1}`, Status = `active`)
+   - **MODIFIED** entries → update Current Rule + bump Last Updated to `phase-{N+1}`
+   - **REMOVED** entries → flip Status to `removed`, bump Last Updated to
+     `phase-{N+1}` (do NOT delete the row — keep the audit trail)
+   - **RENAMED** entries → update BR-ID / Current Rule as appropriate; bump
+     Last Updated
+
+3. **Resume Pointer** — update to "phase-{N+1} in progress:
+   {one-line about what's actively being worked on}" and "Next Action:
+   implement DOMAIN-1 / write Aggregate ... / etc."
+
+The Snapshot is the feature-level CURRENT STATE, not history. Do not let
+it grow into a cumulative log; the per-phase Delta sections are the
+historical audit trail. The bounded context's `rules.md` / `behavior.md`
+remain the system-level current state and are NOT updated here — that
+synchronisation happens at `/dflow:finish-feature`.
+
+After the refresh, summarize for the developer:
+> "Phase-spec ready, `_index.md` refreshed. Snapshot now shows
+> {n_active} active BRs ({n_added} added in this phase, {n_modified}
+> modified, {n_removed} removed). Ready to enter Step 6 —
+> follow the phase-spec's Implementation Tasks list (DOMAIN → APP → INFRA → API)?
+> `/dflow:next` to proceed, or adjust the plan first."
+
+**→ Step Gate: Step 5 → Step 6**
+
+Wait for confirmation before entering Step 6.
+
+## Step 6: Implement and Verify the Phase
+
+Follow the phase-spec's `Implementation Tasks` in the recommended layer order:
+DOMAIN → APP → INFRA → API, with TEST tasks interleaved where they prove the
+layer behavior.
+
+During implementation, continuously verify:
+
+- [ ] `Implementation Tasks` are checked off as they complete, or unchecked
+      items are explicitly labelled as follow-up
+- [ ] Every ADDED / MODIFIED / REMOVED / RENAMED Delta entry is covered by
+      implementation or tests
+- [ ] Every affected `BR-*` business rule is covered by implementation or tests
+- [ ] Every affected Given/When/Then scenario is covered by implementation or tests
+- [ ] New or changed Domain Events are raised in the implementation
+- [ ] Aggregate invariants still hold after the change
+- [ ] Domain layer remains framework-pure; EF configuration stays in Infrastructure
+- [ ] No business logic leaks into Application handlers, Infrastructure queries,
+      or Presentation controllers
+- [ ] Test failures have been resolved or explicitly recorded as follow-up
+
+If implementation changes the agreed Delta, update the phase-spec before
+continuing. Do not let code and spec diverge silently.
+
+**→ Step Gate: Step 6 → Step 7**
+
+Announce to developer:
+> "Phase implementation appears complete and verified against the phase-spec.
+> Ready to mark this phase completed and update `_index.md`? `/dflow:next`
+> to proceed."
+
+> Commit checkpoint (per `references/git-integration.md` § Commit Checkpoints, Branch Gate & AI Commits): offer to commit the phase implementation, then record the result in the `_index.md` Checkpoint Log.
+
+Wait for confirmation before entering Step 7.
+
+## Step 7: Complete the Phase
+
+Update the feature artifacts:
+
+1. **Phase spec status** — change this phase-spec's frontmatter `status`
+   from `in-progress` to `completed`.
+2. **Implementation Tasks** — keep completed tasks checked. If any task is not
+   done, mark it explicitly as follow-up and link to the relevant future
+   phase, issue, or tech-debt entry.
+3. **Phase Specs table** — update this phase's `_index.md` row from
+   `in-progress` to `completed`.
+4. **Current BR Snapshot** — reconcile the snapshot against the implemented
+   Delta. If implementation changed the Delta, update the phase-spec first,
+   then regenerate the snapshot.
+5. **Resume Pointer** — update to one of:
+   - "phase-{N+1} completed; next action: run `/dflow:new-phase` for the next
+     slice"
+   - "phase-{N+1} completed; next action: run `/dflow:finish-feature` if the
+     feature is ready to wrap up"
+
+The bounded context's `rules.md` / `behavior.md` / `events.md` and the
+feature directory move to `completed/` remain `/dflow:finish-feature`
+responsibilities. Do not sync BC-level current state or archive the whole
+feature from `/dflow:new-phase`.
+
+After completion, summarize for the developer:
+> "Phase {N+1} is implemented and marked completed. `_index.md` is refreshed.
+> If another slice is needed, run `/dflow:new-phase`; if the feature is done,
+> run `/dflow:finish-feature`."

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

@@ -0,0 +1,130 @@
+# PR Review Checklist — Greenfield Clean Architecture
+
+`/dflow:pr-review` enters this checklist starting from **Step 0**. Do not skip Step 0 — reviewing code without first understanding spec intent breaks the SDD feedback loop (all the upstream spec work loses its verification mechanism).
+
+## Step 0: Understand the Change Intent (before code review)
+
+Ground yourself in the spec *before* looking at the diff. A feature
+directory may contain multiple spec files; identify which ones this PR
+touches and read them all.
+
+- [ ] Locate the feature directory at
+      `dflow/specs/features/active/{SPEC-ID}-{slug}/` (or
+      `dflow/specs/features/completed/{SPEC-ID}-{slug}/` if the PR is the
+      closeout commit and the dir was already `git mv`d)
+- [ ] Read `_index.md` first — it gives you the feature-level overview,
+      Current BR Snapshot, list of phase-specs, and Resume Pointer (where the
+      author left off)
+- [ ] Identify which **phase-spec(s)** and / or **lightweight-spec(s)**
+      this PR diff touches. There may be:
+      - A new phase-spec being introduced (T1) — read in full,
+        including Aggregate state transitions and Domain Events
+      - An existing phase-spec being marked `completed` — verify its
+        Delta-from-prior-phases section reads correctly relative to the
+        prior phase
+      - A new lightweight-spec (T2) — read in full
+      - Just T3 inline rows added to `_index.md` Lightweight Changes (no
+        spec file changed) — confirm the row description is precise
+- [ ] If a `Behavior Delta` / Delta-from-prior-phases section exists,
+      read **ADDED / MODIFIED / REMOVED / RENAMED** — pay attention to
+      any Aggregate state transitions and Domain Events listed in the
+      Delta; note any **UNCHANGED** scope declaration
+- [ ] State in one sentence: "This PR intends to {change} because
+      {reason}." (If you can't, pause and ask the author.)
+- [ ] Cross-reference `dflow/specs/domain/{context}/behavior.md` if it exists
+      — confirm the Delta has been reflected or is scheduled to be
+      (draft vs finalized; finalisation usually happens at
+      `/dflow:finish-feature` time)
+- [ ] Only then proceed to the code-review sections below
+
+If the PR has no spec or no `_index.md`:
+```
+"I don't see a feature directory or _index.md for this PR. Before I
+review the code, can you point me to it, or run /dflow:new-feature
+(or /dflow:bug-fix for a small fix) to create the feature directory
+and at least a lightweight spec? SDD relies on the spec being the
+review anchor."
+```
+
+## Spec Compliance
+
+Per-feature checks:
+- [ ] **Feature directory exists** with `_index.md` + at least one
+      phase-spec (or one lightweight-spec for a T2-only feature)
+- [ ] **`_index.md` Current BR Snapshot is up to date** — reflects
+      the cumulative effect of all phase-specs / lightweight-specs in
+      the directory
+- [ ] **`_index.md` Phase Specs table** — every row's referenced
+      phase-spec file exists and its `status` matches the row's claim
+- [ ] **For follow-up features**: `_index.md` Metadata has `follow-up-of:
+      {原 SPEC-ID}` AND the original feature's `_index.md`
+      Follow-up Tracking row references this feature
+
+Per-phase-spec / lightweight-spec checks (run for **each** spec file the
+PR touches, not just one):
+- [ ] Spec matches code
+- [ ] Implementation matches Given/When/Then scenarios (including
+      Aggregate state transitions and Domain Events)
+- [ ] All business rules (BR-*) in this spec implemented
+- [ ] Edge cases (EC-*) in this spec handled
+- [ ] **Delta integrity** (phase 2+ only) — the Delta-from-prior-phases
+      section's ADDED / MODIFIED / REMOVED / RENAMED entries actually
+      match the diff against the prior phase-spec's BR set
+
+If the closeout commit is in this PR (`/dflow:finish-feature` was run):
+- [ ] **BC layer sync landed** — `dflow/specs/domain/{context}/rules.md` /
+      `behavior.md` / `events.md` / `context-map.md` reflect the
+      feature's net effect (compare against `_index.md` Current BR
+      Snapshot)
+- [ ] **Whole feature directory `git mv`'d** to `completed/` — git
+      shows `renamed:` (not `deleted:` + `new file:`)
+- [ ] **Integration Summary** was emitted to the conversation (not
+      written to a file — it's ephemeral)
+
+## Domain Layer Quality
+
+- [ ] **Zero external dependencies** — check the Domain package/module manifest; no external dependencies beyond the language/runtime baseline
+- [ ] **No ORM attributes** — no [Table], [Column], [Key] on domain classes
+- [ ] **No serialization attributes** — no [JsonProperty], [JsonIgnore]
+- [ ] **Private setters** — state changes through methods only
+- [ ] **Invariants enforced** — constructor and methods reject invalid state
+- [ ] **Value Objects immutable** — using `record` or readonly properties
+- [ ] **Domain Events raised** — significant state changes produce events
+- [ ] **Other Aggregates referenced by ID** — not by direct object reference
+
+## Application Layer Quality
+
+- [ ] **No business logic** — handlers only orchestrate, not decide
+- [ ] **CQRS respected** — Commands for writes, Queries for reads
+- [ ] **Validation in Validator** — not in handler or controller
+- [ ] **No Domain objects in DTOs** — proper mapping between layers
+- [ ] **Event handlers are idempotent** — safe to replay
+
+## Infrastructure Layer Quality
+
+- [ ] **EF config in Fluent API** — not attributes on Domain entities
+- [ ] **Repository only for Aggregate Roots** — not for child entities
+- [ ] **No business logic in SQL/LINQ** — complex filtering via Specifications
+- [ ] **External service behind interface** — mockable for tests
+
+## Presentation Layer Quality
+
+- [ ] **Thin controllers** — parse, dispatch, respond
+- [ ] **No domain objects exposed** — only DTOs/ViewModels in API
+- [ ] **Proper status codes** — 201 Created, 404 Not Found, 422 Unprocessable
+- [ ] **No business logic** — not even validation beyond format checking
+
+## Cross-Cutting
+
+- [ ] **Glossary consistency** — new terms documented?
+- [ ] **Context boundaries respected** — no reaching into another context's internals
+- [ ] **Domain Events documented** — events.md updated?
+- [ ] **Tests cover invariants** — not just happy path
+
+## Architecture Score
+
+- **A**: Clean layer separation, Domain-first design, full spec, comprehensive tests
+- **B**: Mostly clean, minor layer bleed, spec exists, good test coverage
+- **C**: Some business logic in wrong layer, spec exists
+- **D**: Working code but architecture concerns, needs refactoring
+- **F**: Business logic in controller/infrastructure, no spec — push back

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

@@ -121,12 +121,39 @@ Recommend `docs/migrating-to-dflow-v1.md` for the manual migration
 checklist. Migration affects every spec the team has written; manual
 review is required.
 
+## Workflow Steps
+
+This guide is the **command registry, routing rules, and project context**.
+Executable workflow steps (Step 1→N, step gates, completion checklists) are
+**not** defined here. They live in the vendored workflow bundle projected into
+this project at:
+
+- `dflow/specs/shared/dflow-workflows/`
+
+When executing a `/dflow:*` command, read the matching flow file from that
+directory first. For example:
+
+| Command | Flow file |
+|---|---|
+| `/dflow:new-feature` | `dflow/specs/shared/dflow-workflows/references/new-feature-flow.md` |
+| `/dflow:modify-existing` | `dflow/specs/shared/dflow-workflows/references/modify-existing-flow.md` |
+| `/dflow:bug-fix` | `dflow/specs/shared/dflow-workflows/references/modify-existing-flow.md` (lightweight-ceremony branch) |
+| `/dflow:new-phase` | `dflow/specs/shared/dflow-workflows/references/new-phase-flow.md` |
+| `/dflow:finish-feature` | `dflow/specs/shared/dflow-workflows/references/finish-feature-flow.md` |
+| `/dflow:verify` | `dflow/specs/shared/dflow-workflows/references/drift-verification.md` |
+| `/dflow:pr-review` | `dflow/specs/shared/dflow-workflows/references/pr-review-checklist.md` |
+| `/dflow:report-dflow-feedback` | `dflow/specs/shared/dflow-workflows/references/dflow-feedback-flow.md` |
+
+Supporting files (templates, domain modeling guide, drift checklist) are also
+in `dflow/specs/shared/dflow-workflows/` under the same relative paths used
+by the flow files.
+
 ## Tool-Specific Notes
 
-This file is the canonical Dflow guide. Root-level files such as
-`AGENTS.md`, `CLAUDE.md`, and `.github/copilot-instructions.md`
+This file is the canonical Dflow guide (registry + rules + router). Root-level
+files such as `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. This guide contains the installed runtime behavior
-contract; execute the workflow semantics defined here directly.
+plain workflow names and follow the matching flow file from the workflow bundle
+at `dflow/specs/shared/dflow-workflows/`.

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

@@ -1,14 +1,16 @@
-<!-- Scaffolding template maintained alongside Dflow skill. See archive/proposals/PROPOSAL-010 for origin. -->
+<!-- Seeded by Dflow. -->
 
 # CLAUDE.md Snippet — Dflow Adoption (Greenfield track)
 
 > Source: `scaffolding/CLAUDE-md-snippet.md`
 > Purpose: a minimal block you paste into (or replace with) your
 > project's root `CLAUDE.md` when adopting Dflow.
-> For the Greenfield track, the full reference template lives at
-> `sdd-ddd-greenfield-skill/templates/CLAUDE.md` — if you want the complete
-> legacy Claude-specific version, use that instead. New CLI init output uses
-> `AI-AGENT-GUIDE.md` plus a generated `CLAUDE.md` shim.
+> For the Greenfield track, the full reference template lives in the
+> in-project bundle at
+> `dflow/specs/shared/dflow-workflows/templates/CLAUDE.md` (projected by
+> `dflow init`) — if you want the complete legacy Claude-specific version,
+> use that instead. New CLI init output uses `AI-AGENT-GUIDE.md` plus a
+> generated `CLAUDE.md` shim.
 
 ---
 
@@ -91,14 +93,14 @@ dflow/specs/
 
 > SDD 流程、Git 整合、Domain 層規範、AI 協作
 
-### Dflow Skill — Canonical Decision Logic Lives in the Skill
+### Dflow Skill — Canonical Decision Logic Lives in the Project
 
 AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 （T1 Heavy / T2 Light / T3 Trivial）、所有 slash command 的 step-by-step
-流程 **不在此重述**，請以 Dflow skill 本體為準：
+流程 **不在此重述**，請以本專案內的 Dflow 工件為準（init 時投影）：
 
-- `sdd-ddd-greenfield-skill/SKILL.md`（決策樹 + Slash Commands 總表）
-- `sdd-ddd-greenfield-skill/references/` 內各 flow 文件
+- `dflow/specs/shared/AI-AGENT-GUIDE.md`（決策樹 + Slash Commands 總表 + 路由規則）
+- `dflow/specs/shared/dflow-workflows/references/` 內各 flow 文件（執行步驟定義）
 
 本專案採用的 Dflow entry points：
 - Dflow CLI init command (`dflow init`, or `npx dflow-sdd-ddd init` when using the no-install path) — 專案初始化（一次性，已執行過）
@@ -159,10 +161,10 @@ AI 的完整決策樹、Workflow Transparency、Ceremony Scaling 三層判準
 
 ## Notes
 
-- This snippet is intentionally lighter than
-  `sdd-ddd-greenfield-skill/templates/CLAUDE.md`. If you want the full version
-  (with detailed flow descriptions per slash command), use that
-  template instead
+- This snippet is intentionally lighter than the in-project bundle
+  template at `dflow/specs/shared/dflow-workflows/templates/CLAUDE.md`. If
+  you want the full version (with detailed flow descriptions per slash
+  command), use that template instead
 - The snippet does NOT re-copy the Dflow decision tree, Ceremony
   Scaling criteria, or per-flow step details — those live in the
   skill and change when the skill evolves

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

@@ -1,4 +1,4 @@
-<!-- Scaffolding template maintained alongside Dflow skill. See archive/proposals/PROPOSAL-010 for origin. -->
+<!-- Seeded by Dflow. -->
 
 # Git Principles — Git Flow edition
 
@@ -125,8 +125,6 @@ Commits must tie back to a SPEC-ID:
 [{SPEC-ID}] {short description}
 
 {optional detailed body}
-
-Co-Authored-By: Claude <noreply@anthropic.com>   ← suggested, not mandatory
 ```
 
 ### Type prefix (recommended)
@@ -309,19 +307,22 @@ Three categories:
 | `git stash` (local-only) |
 | `git branch` (listing only) |
 
-### AI commit authorship (suggested, not enforced)
+### AI commit authorship
 
-When an AI assists in producing a commit, appending a `Co-Authored-By`
-line is **suggested** but not mandatory. The canonical form for
-Claude is:
+How AI-made commits are marked is chosen once at `dflow init` and recorded in
+`dflow/specs/shared/_conventions.md` § AI Commit Policy:
 
-```
-Co-Authored-By: Claude <noreply@anthropic.com>
-```
+- `none` — AI commits carry no extra marker.
+- `co-authored-by` — a `Co-Authored-By: dflow-ai <noreply@dflow.local>` trailer
+  (teams may customize the name / email).
+- `prefix` — an `[ai-assisted]` commit-subject prefix.
 
-For other AI assistants, use the vendor-documented author line (or omit
-it). This is a project-level transparency convention, not a Dflow
-requirement.
+This recorded setting is authoritative and the runtime does not re-ask. The AI
+offers commits at lifecycle checkpoints (see `references/git-integration.md`
+§ Commit Checkpoints, Branch Gate & AI Commits) using your Git identity, and you
+can always decline. If your team also wants vendor attribution, appending the
+assistant's documented line (e.g. `Co-Authored-By: Claude
+<noreply@anthropic.com>`) is an independent, optional convention on top.
 
 ---
 

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

@@ -1,4 +1,4 @@
-<!-- Scaffolding template maintained alongside Dflow skill. See archive/proposals/PROPOSAL-010 for origin. -->
+<!-- Seeded by Dflow. -->
 
 # Git Principles — Trunk-based / GitHub Flow edition
 
@@ -77,8 +77,6 @@ recommended but not strictly required:
 {type}({scope}): {short description}
 
 [{SPEC-ID}] {longer description, optional}
-
-Co-Authored-By: Claude <noreply@anthropic.com>   ← suggested, not mandatory
 ```
 
 ### Type prefix (Conventional Commits)
@@ -106,8 +104,6 @@ feat(expense): add ExpenseReport submission invariants
 [SPEC-20260421-001] Introduce ExpenseReport Aggregate with submission
 state machine; enforces non-negative Amounts and requires at least one
 ExpenseItem before submission.
-
-Co-Authored-By: Claude <noreply@anthropic.com>
 ```
 
 ---
@@ -183,7 +179,6 @@ Related BR-IDs:
 Domain Events introduced / modified: {Event names, or "(none)"}
 
 Related SPEC-IDs: {SPEC-ID}{, follow-up SPEC-IDs if any}
-Co-Authored-By: Claude <noreply@anthropic.com>
 ```
 
 GitHub PR editor can be pre-filled with this body; the merge button
@@ -210,8 +205,6 @@ feat({scope}): {Phase N title} — closes {SPEC-ID}
 Change Scope: ... (as in §4.1)
 Related BR-IDs: ...
 Domain Events: ...
-
-Co-Authored-By: Claude <noreply@anthropic.com>
 ```
 
 ### 4.3 Fast-forward (feature has 1 commit total)
@@ -288,19 +281,22 @@ Three categories:
 | `git branch` (listing only) |
 | `gh pr status` / `gh pr view` |
 
-### AI commit authorship (suggested, not enforced)
+### AI commit authorship
 
-When an AI assists in producing a commit, appending a `Co-Authored-By`
-line is **suggested** but not mandatory. The canonical form for
-Claude is:
+How AI-made commits are marked is chosen once at `dflow init` and recorded in
+`dflow/specs/shared/_conventions.md` § AI Commit Policy:
 
-```
-Co-Authored-By: Claude <noreply@anthropic.com>
-```
+- `none` — AI commits carry no extra marker.
+- `co-authored-by` — a `Co-Authored-By: dflow-ai <noreply@dflow.local>` trailer
+  (teams may customize the name / email).
+- `prefix` — an `[ai-assisted]` commit-subject prefix.
 
-For other AI assistants, use the vendor-documented author line (or omit
-it). This is a project-level transparency convention, not a Dflow
-requirement.
+This recorded setting is authoritative and the runtime does not re-ask. The AI
+offers commits at lifecycle checkpoints (see `references/git-integration.md`
+§ Commit Checkpoints, Branch Gate & AI Commits) using your Git identity, and you
+can always decline. If your team also wants vendor attribution, appending the
+assistant's documented line (e.g. `Co-Authored-By: Claude
+<noreply@anthropic.com>`) is an independent, optional convention on top.
 
 ---
 

package/templates/greenfield/scaffolding/_conventions.md

@@ -1,4 +1,4 @@
-<!-- Scaffolding template maintained alongside Dflow skill. See archive/proposals/PROPOSAL-010 for origin. -->
+<!-- Seeded by Dflow. -->
 
 # Spec Writing Conventions — {System Name}
 

package/templates/greenfield/scaffolding/_overview.md

@@ -1,4 +1,4 @@
-<!-- Scaffolding template maintained alongside Dflow skill. See archive/proposals/PROPOSAL-010 for origin. -->
+<!-- Seeded by Dflow. -->
 
 # System Overview — {System Name}
 
@@ -179,5 +179,7 @@ Initial ADRs that typically exist:
 - [Glossary](../domain/glossary.md)
 - [Tech debt backlog](../architecture/tech-debt.md)
 - [Architecture decisions](../architecture/decisions/)
-- Dflow skill: see `CLAUDE.md` and the `sdd-ddd-greenfield-skill/` bundle
-  for the full AI workflow guidance.
+- Dflow workflow guidance: see `CLAUDE.md` (project-level AI rules) and the
+  in-project vendored bundle at `dflow/specs/shared/AI-AGENT-GUIDE.md` +
+  `dflow/specs/shared/dflow-workflows/references/` for the full AI workflow
+  decision tree, slash commands, and step-by-step flow definitions.