dflow-sdd-ddd 0.10.0 → 0.12.0

package/templates/brownfield/references/git-integration.md

@@ -37,9 +37,9 @@ main (or your project's base branch)
 ```
 feature/{SPEC-ID}-{slug}
   Examples:
-    feature/EXP-001-jpy-currency-support
-    feature/HR-003-leave-approval-workflow
-    feature/SHARED-002-audit-logging
+    feature/SPEC-20260424-001-jpy-currency-support
+    feature/SPEC-20260430-001-leave-approval-workflow
+    feature/SPEC-20260502-002-audit-logging
 
 bugfix/{BUG-ID}-{slug}
   Examples:
@@ -148,10 +148,30 @@ existing Step Gate prompt (it does not add a separate question):
 Tier sets how many checkpoints a change has: T1 three (spec / implementation /
 closeout), T2 two (spec+implementation merged / closeout), T3 a single commit.
 Whether you choose Y or N, the AI records one row in the feature `_index.md`
-Checkpoint Log. A commit hash is written only after the commit succeeds; a hook
-rejection or failed commit is recorded as `failed` (never a fake hash). After
-several consecutive skips in a project the AI mentions you can turn checkpoints
-off in config — it does not turn them off for you.
+Checkpoint Log — every checkpoint is accounted for (`committed` / `skipped` /
+`failed`), even when no commit happens. A commit hash is written only after the
+commit succeeds; a hook rejection or failed commit is recorded as `failed`
+(never a fake hash). **Exception — the closeout row**: the closeout commit
+cannot contain its own hash, so the closeout row is written before the commit
+as `closeout | committed` with **no hash** (see
+`references/finish-feature-flow.md` Step 4); trace that commit via
+`git log -1 -- dflow/specs/features/completed/{SPEC-ID}-{slug}` or the optional
+`Dflow-Checkpoint` trailer below. After several consecutive skips in a project
+the AI mentions you can turn checkpoints off in config — it does not turn them
+off for you.
+
+**Optional machine-greppable trailer.** Teams that want cross-flow checkpoint
+accounting can append a commit trailer at checkpoint commits:
+
+```
+Dflow-Checkpoint: {SPEC-ID} {spec|impl|closeout}
+```
+
+The `_index.md` Checkpoint Log **remains the source of truth**; the trailer is
+a cheap derived mirror (`git log --grep 'Dflow-Checkpoint: {SPEC-ID}'`). Use
+role names, not (k/N) counts — the checkpoint total can change mid-feature
+(tier escalation, follow-ups), and a role gap ("impl exists but no closeout for
+this SPEC-ID") is detectable without predicting N, even across flows.
 
 ### AI commits
 
@@ -325,8 +345,8 @@ Tie commits to specs:
 [SPEC-ID] Short description
 
 Examples:
-[EXP-001] Add JPY currency support to Money value object
-[EXP-001] Extract exchange rate logic to Domain service
+[SPEC-20260424-001] Add JPY currency support to Money value object
+[SPEC-20260424-001] Extract exchange rate logic to Domain service
 [BUG-042] Fix rounding inconsistency, extract to Money.Round()
 ```
 

package/templates/brownfield/references/modify-existing-flow.md

@@ -7,6 +7,8 @@ Step-by-step guide for when a developer triggers `/dflow:modify-existing` or `/d
 - Step 4 → Step 5 (extraction decision → start implementation)
 - Step 5 → Step 6 (implementation done → update artifacts)
 
+Crossing any step gate above also updates the host feature's `_index.md` Resume Pointer cursor (Active Workflow / Current Step / Gates Passed / Awaiting) once the host feature directory exists — fold it into that gate's existing `_index.md` / Resume Pointer edit, no separate ceremony (see the `_index.md` template's Resume Pointer notes).
+
 All other step transitions are **step-internal**: announce "Step N complete, entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow Transparency for the full transparency protocol and confirmation signals.
 
 **Ceremony adjustment when triggered by `/dflow:bug-fix`**: treat as lightweight — use the Lightweight Spec Template (see `templates/lightweight-spec.md`) instead of the full spec, and Step 4 (extraction) may default to "defer and record in tech-debt.md" unless the bug itself is in extractable logic. T2 still generates a concise `Implementation Tasks` checklist (see Step 4).
@@ -63,6 +65,16 @@ Walk through these in order:
    this is a new concern. For T1, use `/dflow:new-feature`. For T2 / T3
    on a standalone bug, see Step 1.5 — `/dflow:bug-fix` will create a
    minimal feature directory to host the lightweight-spec.
+4. **In-flight overlap scan (cross-branch)**: this branch's `active/` is not
+   everything in flight. Run the in-flight scan (classification and dedup
+   rules in `AI-AGENT-GUIDE.md` § Status / Control Commands) — `git fetch`
+   when the network allows, then
+   `git branch --all --list '*feature/*' --list '*bugfix/*'` — and also list
+   other unfinished features in this branch's `active/` (one cursor line
+   each). If a scanned branch classified as in flight elsewhere, closed out
+   awaiting integration, or unknown — or an unfinished feature — semantically
+   overlaps this change, surface it and wait for the developer to decide
+   before creating anything new (stale branches are non-blocking).
 
 > **Why scan completed too?** Completed features are frozen history
 > and **cannot accept** any T2 / T3 directly
@@ -282,8 +294,57 @@ Decision framework:
 - **Extract now** if: the logic is being significantly modified anyway
 - **Extract now** if: the logic is duplicated elsewhere and we need the single source of truth
 - **Defer extraction** if: the change is a one-line fix and the surrounding code is too tangled
+- **Consider not extracting at all** if: the context is `generic` (per the
+  context-map Subdomain Type) — a commodity capability's endgame is wholesale
+  replacement with an off-the-shelf package / service, so extracting its rules
+  one by one is wasted effort; record the replacement intent as the tech-debt
+  entry instead
 - **Always record** the extraction opportunity in tech-debt.md even if deferring
 
+If the target context has **no Subdomain Type** (not in `context-map.md`, or
+the column is absent), ask the developer once to classify it. If they'd rather
+not decide now, record it as an Open Question in the spec and run the
+extraction decision on the framework above — do **not** assume `generic`.
+
+**Aggregate emergence check.** Before extracting yet another rule onto an
+existing concept, look at what has already accumulated on it (in `models.md` /
+`rules.md`). The signal that it has stopped being a loose entity and is
+becoming an **Aggregate Root with a consistency boundary**: **2+ non-trivial
+state-transition rules on the same lifecycle identity, or any invariant that
+must check / update multiple fields or child records atomically.** (A
+*consistency boundary* means state that must hold or change **together,
+atomically** — not mere relatedness: same screen, related nouns, or local
+single-field input validation do **not** count.) When you see it, continuing
+to extract rules one by one as T2 will leave the boundary undrawn — surface it
+and **suggest escalating to T1** (`/dflow:new-phase` inside an active feature,
+else `/dflow:new-feature`) to model the Aggregate deliberately: its invariants,
+what must change atomically, what it protects. For *how* to model it —
+invariant classification, set-based / uniqueness rules, aggregate sizing — read
+`references/ddd-modeling-guide.md` (its **Edition note** maps each recording
+surface to brownfield's `models.md` / `rules.md`). In `models.md`, **mark the
+existing Entity row as the Aggregate Root and note the protected invariants /
+atomic-change scope in its Responsibility / Notes** — brownfield `models.md`
+has no separate Aggregates section, do not invent one; update the Repository
+row if one exists. If the developer defers, **record the emergence observation
+in `tech-debt.md`** so the boundary decision is not silently lost.
+
+**Established-model re-read (the emergence check's mirror).** When the rule
+you are extracting lands on an **already-modeled** Aggregate / concept,
+re-read what was recorded when it was shaped (its `models.md` row + Notes
+and the relevant `rules.md` entries) before extending it. If this change
+matches a recorded re-evaluation condition ("revisit when …") or trips a
+model-resistance signal, follow `references/ddd-modeling-guide.md`
+§ "Revising an Established Model": record one short passage in the spec's
+design decisions / open questions — proceed as-is, split, or rename, with
+the reason. Deciding to keep the current model, recorded, is a valid
+outcome; extending silently is not.
+
+If the context is **`generic`** (Subdomain Type), emergence is usually a
+*replacement / adapter-boundary* debt signal, not a cue for deep T1 modeling —
+record the replacement intent (consistent with the generic extraction fallback
+above) rather than escalating, unless the developer explicitly chooses to
+model it.
+
 ### Generate Implementation Tasks List
 
 For a phase-spec modification, AI generates a concrete task list and writes it into the spec's `Implementation Tasks` section using `[LAYER]-[NUMBER]：description` (DOMAIN / DELIVERY / DATA / TEST).

package/templates/brownfield/references/new-feature-flow.md

@@ -8,6 +8,8 @@ Step-by-step guide for when a developer triggers `/dflow:new-feature` (or natura
 - Step 6 → Step 7 (branch ready → start implementation)
 - Step 7 → Step 8 (implementation done → completion)
 
+Crossing any step gate above also updates the host feature's `_index.md` Resume Pointer cursor (Active Workflow / Current Step / Gates Passed / Awaiting) once the feature directory exists — fold it into that gate's existing `_index.md` / Resume Pointer edit, no separate ceremony (see the `_index.md` template's Resume Pointer notes).
+
 All other step transitions are **step-internal**: announce "Step N complete, entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow Transparency for the full transparency protocol and confirmation signals.
 
 **Ceremony**: this flow always defaults to **T1 Heavy** — the first phase of a brand-new feature is by definition a full SDD cycle. Tier judgement (T1 / T2 / T3) only applies to `/dflow:modify-existing` (see `references/modify-existing-flow.md` and AI-AGENT-GUIDE.md § Ceremony Scaling).
@@ -30,6 +32,27 @@ Then check existing assets:
 - Search `dflow/specs/features/` for related or overlapping features
 - Check `dflow/specs/domain/glossary.md` for relevant terms
 
+**In-flight overlap scan (cross-branch + other unfinished features)** — this
+branch's `dflow/specs/` does not show everything in flight. Run the in-flight
+scan (classification and dedup rules in `AI-AGENT-GUIDE.md` § Status / Control
+Commands):
+
+```bash
+git fetch   # when the network allows; skip gracefully offline
+git branch --all --list '*feature/*' --list '*bugfix/*'
+```
+
+- List other unfinished features already in this branch's `active/` (one
+  cursor line each, from their `_index.md` Resume Pointer).
+- Classify every listed branch by the guide's rules — in flight elsewhere /
+  closed out awaiting integration / stale (completed here) / unknown — do
+  not shortcut the classification. If a branch classified as **in flight
+  elsewhere, closed out awaiting integration, or unknown** has an ID / slug
+  that semantically overlaps this request, surface it and wait for the
+  developer to decide — continue there / integrate it first / treat as
+  related / unrelated — **before creating any new directory, spec, or
+  branch**. Only stale (completed here) branches are non-blocking.
+
 Share what you found: "I see we already have [X] documented. This new feature seems to extend
 that — is that right?"
 
@@ -50,6 +73,23 @@ If no matching context exists:
 2. Create `dflow/specs/domain/{new-context}/context.md` using the context-definition template
 3. Get developer confirmation before proceeding
 
+Once the BC is confirmed, classify and record its **Subdomain Type** as part
+of the same confirmation (not a separate gate):
+
+```
+"Is this capability core (差異化來源), supporting (必要但非差異化),
+or generic (可買 / 可套件 / 簡單 CRUD)? I'll record it in context-map.md."
+```
+
+If the BC already has a Subdomain Type, reuse it — don't re-ask unless the
+developer wants to reclassify. Record it in
+`dflow/specs/domain/context-map.md`:
+
+- If the file **does not exist** (the Brownfield track does not mandate it —
+  contexts emerge organically), create it from `templates/context-map.md`.
+- If it exists but the **Subdomain Type column is missing**, add the column
+  **preserving every existing row** — do not rewrite their content.
+
 **→ Transition (step-internal)**: Step 2 complete. Announce "Step 2 complete (BC identified). Entering Step 3: Domain Concept Discovery." and continue.
 
 ## Step 3: Domain Concept Discovery
@@ -62,6 +102,27 @@ Walk through these questions:
 - **What are the states/statuses?** → State machines to model
 - **What external data is needed?** → Interfaces to define
 
+If one concept gathers rules / invariants that must hold together — **a state
+machine over its lifecycle, or invariants spanning several of its fields /
+child records** — treat it as a candidate **Aggregate Root** (a consistency
+boundary = atomic, not mere relatedness), not just an Entity. Note its
+invariants and what must change atomically against its `models.md` Entity row,
+and confirm the boundary with the developer. (A state machine is one common
+signal, not a prerequisite.) For the tactical patterns — invariant
+classification, set-based / uniqueness rules, value objects, aggregate sizing —
+read `references/ddd-modeling-guide.md` (its **Edition note** maps recording
+surfaces to brownfield's `models.md` / `rules.md`).
+
+The mirror case — the concept is **already modeled**: when extending an
+existing Aggregate / modeled concept, re-read what was recorded when it was
+shaped (its `models.md` row + Notes and the relevant `rules.md` entries)
+before extending it. If this change matches a recorded re-evaluation
+condition ("revisit when …") or trips a model-resistance signal, follow
+`references/ddd-modeling-guide.md` § "Revising an Established Model":
+record one short passage in the spec's design decisions / open questions —
+proceed as-is, split, or rename, with the reason. Deciding to keep the
+current model, recorded, is a valid outcome; extending silently is not.
+
 For each new concept:
 1. Check glossary — add if missing
 2. Check if it already exists in models.md — extend if needed
@@ -142,7 +203,7 @@ dflow/specs/features/active/{SPEC-ID}-{slug}/
    - Current BR Snapshot: initialise from the first phase's planned BRs
      (will be refreshed when the phase-spec finalises)
    - Lightweight Changes: empty table at start
-   - Resume Pointer: "phase-1 in progress: drafting phase-spec." / "Next Action: finish phase-spec, then implement."
+   - Resume Pointer: "phase-1 in progress: drafting phase-spec." / "Next Action: finish phase-spec, then implement." / cursor fields: Active Workflow `new-feature`, Current Step `Step 4 — write the spec`, Gates Passed `3→3.5`, Awaiting `none (mid-step)`
 3. **Create the first phase-spec** at `phase-spec-{YYYY-MM-DD}-{slug}.md`
    using `templates/phase-spec.md`. The "Delta from prior phases" section
    is filled with "首 phase，無前置 Delta" (first phase has nothing to

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

@@ -19,6 +19,8 @@ adds a new phase to an in-progress feature only.
 - Step 5 → Step 6 (`_index.md` refreshed → start implementation)
 - Step 6 → Step 7 (implementation done → complete the phase)
 
+Crossing any step gate above also updates the feature's `_index.md` Resume Pointer cursor (Active Workflow / Current Step / Gates Passed / Awaiting) — fold it into that gate's existing `_index.md` / Resume Pointer edit, no separate ceremony (see the `_index.md` template's Resume Pointer notes).
+
 All other step transitions are **step-internal**: announce "Step N complete,
 entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow
 Transparency for the full transparency protocol and confirmation signals.
@@ -63,6 +65,11 @@ AI must locate the target feature and load its current state:
    - 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)
+   - Run the in-flight overlap scan (classification and dedup rules in
+     `AI-AGENT-GUIDE.md` § Status / Control Commands): list other unfinished
+     features in `active/` and any feature / bugfix branches whose work is
+     not visible on this branch — if the incoming phase scope overlaps one
+     of them, surface it before writing the phase-spec.
 
 4. **Branch gate — ensure you are on this feature's branch (before any commit)**
 
@@ -92,7 +99,18 @@ Walk the developer through what the new phase covers:
    BRs (ADDED), changed BRs (MODIFIED), removed BRs (REMOVED), renamed
    (RENAMED). Items not mentioned stay UNCHANGED implicitly.
 3. **Any Domain concepts introduced or changed?** New Entities / Value
-   Objects / Services touching `src/Domain/{context}/`?
+   Objects / Services touching `src/Domain/{context}/`? If this phase is an
+   **Aggregate-emergence escalation** (handed off from `/dflow:modify-existing`),
+   record the candidate Aggregate Root, the invariants it protects, and what
+   must change atomically — marking the Aggregate Root on its `models.md`
+   Entity row (no separate Aggregates section). For how to model it (invariant
+   classification, set-based / uniqueness rules, aggregate sizing), read
+   `references/ddd-modeling-guide.md` (its **Edition note** maps recording
+   surfaces to brownfield's `models.md` / `rules.md`). If the phase **extends
+   an already-modeled Aggregate / concept**, apply the established-model
+   re-read from `references/ddd-modeling-guide.md` § "Revising an Established
+   Model" (match recorded re-evaluation conditions; record proceed / split /
+   rename in the phase-spec).
 4. **Data structure impact?** New tables, columns, indices?
 5. **Why now?** Priority — informs sequencing relative to other phases.
 

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

@@ -139,7 +139,13 @@ for later?"
 ## Glossary Consistency
 
 - [ ] **New terms documented** — Any new business concept added to glossary.md?
-- [ ] **Consistent naming** — Do class/method/variable names match glossary terms?
+- [ ] **Naming matches the Ubiquitous Language** — for each **domain-facing**
+      class / method / variable the diff introduces (skip DTO / test / framework
+      names), is there a matching term in `glossary.md`? The `Code Mapping` column
+      maps each term to its `{Namespace/Class/Member}` — a domain name with no
+      glossary term, or a term whose Code Mapping is now stale, is the signal.
+- [ ] **No synonym drift** — is the code naming a concept with a different word
+      than the glossary? Align it. (Judgment call, not a string match.)
 - [ ] **No ambiguous terms** — Are domain-specific terms used precisely?
 
 Example check:

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

@@ -102,6 +102,12 @@ input like this (supporting files live in the workflow bundle at
   `dflow/specs/features/backlog/` and suggest work based on migration value.
 - **"I'm creating a branch"** → read `references/git-integration.md`; verify
   branch naming and ensure a spec exists before coding starts.
+- **"I'm designing a domain model" / "How should I model X?" / building or
+  reshaping an Aggregate** → read `references/ddd-modeling-guide.md` (DDD
+  tactical patterns: aggregates, invariants, value objects, domain events). It
+  is written with Greenfield artifact names; see its **Edition note** for where
+  Brownfield records the same decisions (`models.md` / `rules.md` /
+  `behavior.md` / `migration/tech-debt.md`).
 - **"Dflow seems wrong" / "this template is confusing"** (or you notice Dflow
   guidance drift) → suggest `/dflow:report-dflow-feedback`; never submit
   anything upstream automatically.
@@ -112,10 +118,43 @@ input like this (supporting files live in the workflow bundle at
 
 ## 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:status` reports in two parts.
+
+**Part 1 — in-flight overview (always shown, workflow active or not).**
+Aggregate every in-flight feature so unfinished work surfaces without anyone
+remembering to look:
+
+- Scan this branch's `dflow/specs/features/active/*/_index.md` and print one
+  line per feature: SPEC-ID / Active Workflow / Current Step / Awaiting / last
+  Checkpoint Log row (read from each Resume Pointer cursor).
+- Cross-branch: run `git fetch` when the network allows (skip gracefully
+  offline), then `git branch --all --list '*feature/*' --list '*bugfix/*'`,
+  deduplicating local and remote refs of the same branch (prefer local). For
+  each branch, classify in order: (1) its feature directory exists in this
+  branch's `active/` → already covered above; (2) exists in this branch's
+  `completed/` → a stale undeleted branch — list as "completed; branch can be
+  deleted", **not** in-flight; (3)
+  `git show {branch}:dflow/specs/features/active/{dir}/_index.md` is readable
+  → in flight on that branch, print its cursor line (no branch switching);
+  (4) the `completed/` path is readable on that branch → closed out there,
+  awaiting integration; (5) nothing readable → list the branch as unknown
+  state.
+- If `features/backlog/` is non-empty, append one count line.
+- Inherent limit: work never committed anywhere is invisible to any git scan.
+
+**Part 2 — current feature detail (when a workflow is active).** Read the
+Resume Pointer cursor as the **declared** state, then cross-check it against
+derived evidence (Checkpoint Log, phase-spec statuses, recent git log). On
+mismatch, report both sides explicitly and ask the developer to correct the
+cursor — the cursor is a claim; evidence wins. If the cursor fields are absent
+(an older `_index.md`), fall back to pure derivation. For readability you may
+expand the cursor into a step checklist (done / in progress / not started)
+derived live from the flow file — display only, never stored.
+
+Include these fields: workflow, step, completed, in-progress, remaining,
+pending decision, and next valid action. If no workflow is active, say so and
+list valid flow-entry or standalone commands (Part 1 still shows the
+in-flight overview).
 
 `/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
@@ -123,7 +162,9 @@ 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.
+workflow was cancelled. If the feature directory exists, set the Resume
+Pointer cursor's Active Workflow to `none` (keep Current Progress as a trace
+of where the cancellation happened).
 
 When no workflow is active, `/dflow:next` and `/dflow:cancel` must report that
 there is no active workflow to advance or cancel.
@@ -344,34 +385,6 @@ during the completion checklist, not via template section markers.
 - Direct SQL in delivery/entrypoint code? → Record
 - Magic numbers or undocumented statuses? → Record and add to glossary
 
-## Pre-V1 Artifacts Detection
-
-When working in a project that adopted Dflow before `dflow-sdd-ddd@0.1.0`,
-you may encounter layout or naming patterns that predate the V1 baseline.
-If any of the following appear, surface the observation to the developer
-and recommend manual migration; do not rewrite anything silently.
-
-Signals:
-
-- Top-level `specs/` directory containing Dflow-shaped content (V1 layout
-  uses `dflow/specs/`).
-- `_共用/` directory under `specs/` or `dflow/specs/` (V1 uses `shared/`).
-- Section headings in Traditional Chinese where V1 templates render
-  canonical English; compare against `TEMPLATE-LANGUAGE-GLOSSARY.md` if
-  available.
-- References to a runtime `/dflow:init-project` slash command (V1
-  replaced it with the Dflow CLI init command (`dflow init`, or
-  `npx dflow-sdd-ddd init` when using the no-install path)).
-- A root `CLAUDE.md`, `AGENTS.md`, or equivalent that holds the full
-  Dflow workflow text instead of being a thin shim pointing to this
-  file.
-- `dflow/specs/shared/_conventions.md` is missing the `> Dflow Version:`
-  front-matter line (V1 init writes it automatically).
-
-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**.

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

@@ -140,7 +140,7 @@ When applicable, prefix with a type (conventional commits-style):
 | test | tests only |
 | chore | build / tooling |
 
-Example: `[EXP-001] feat: add JPY currency support to Money VO`
+Example: `[SPEC-20260424-001] feat: add JPY currency support to Money VO`
 
 ---
 

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

@@ -95,8 +95,8 @@ adopted, the format is:
 | test | tests only |
 | chore | build / tooling |
 
-Example: `feat(expense): add JPY currency support` with `[EXP-001]` in
-the body.
+Example: `feat(expense): add JPY currency support` with
+`[SPEC-20260424-001]` in the body.
 
 ---
 

package/templates/brownfield/templates/_index.md

@@ -97,23 +97,42 @@ Template note (for AI):
 > T3 單一 commit。
 >
 > commit hash 只在 commit 實際成功後填入；pre-commit hook reject 或 commit
-> 失敗記 `failed`、不寫假 hash。
+> 失敗記 `failed`、不寫假 hash。**例外：closeout 列不填 hash**——closeout
+> commit 無法自含自身 hash，該列於 commit 前寫入、隨歸檔目錄一起進 commit；
+> 溯源用 `git log -1 -- completed/{SPEC-ID}-{slug}` 或選配的
+> `Dflow-Checkpoint` trailer（見 references/git-integration.md）。
 
 | Timestamp | Checkpoint | Result |
 |---|---|---|
 | {YYYY-MM-DD HH:MM} | spec-baseline | committed ({hash}) / skipped / failed |
 | {YYYY-MM-DD HH:MM} | implementation | committed ({hash}) / skipped / failed |
-| {YYYY-MM-DD HH:MM} | closeout | committed ({hash}) / skipped / failed |
+| {YYYY-MM-DD HH:MM} | closeout | committed / skipped / failed |
 
 ## Resume Pointer
 
-> 一句話：目前進展到哪？下一個動作是什麼？
-> 開新對話接續工作時，從這裡讀起。
+> 目前進展到哪？下一個動作是什麼？開新對話接續工作時，從這裡讀起。
+>
+> 下方四個 cursor 欄位是 workflow 進度的**存放層（宣告，claim）**：
+> 進入 flow 時設 Active Workflow；**每過一個 step gate** 更新 Current Step /
+> Gates Passed / Awaiting（與該 gate 既有的 `_index.md` 更新合併，不另加儀式）；
+> closeout / `/dflow:cancel` 時 Active Workflow 設回 `none`。
+> `/dflow:status` 讀 cursor 後會與推導證據（Checkpoint Log、phase-spec
+> status、git log）交叉，不一致會明確報 mismatch——cursor 是宣告、證據優先。
+> Phase 粒度進度由上方 Phase Specs 表承載；cursor 只補 workflow step / gate
+> 粒度，不展開成 per-step 全表（步驟線性，游標可推導每一步的完成/未做）。
 
 **Current Progress**: {one-line summary}
 
 **Next Action**: {suggested next action}
 
+**Active Workflow**: {new-feature | modify-existing | bug-fix | new-phase | finish-feature | none}
+
+**Current Step**: {Step N — short step name | n/a}
+
+**Gates Passed**: {e.g. "3→3.5, 4→5" | n/a}
+
+**Awaiting**: {step-gate description | none}
+
 <!--
 ## Follow-up Tracking
 >（選用段；只有當本 feature 衍生出 follow-up feature 時才填）

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

@@ -6,15 +6,23 @@
 
 ## Context List
 
-| Bounded Context | Responsibility | Owner / Team | Primary Code Area | Notes |
-|---|---|---|---|---|
-| {Context name} | {業務責任} | {owner} | `{project/path/or/namespace}` | {optional notes} |
+| Bounded Context | Responsibility | Subdomain Type | Owner / Team | Primary Code Area | Notes |
+|---|---|---|---|---|---|
+| {Context name} | {業務責任} | core / supporting / generic | {owner} | `{project/path/or/namespace}` | {optional notes} |
+
+> **Subdomain Type** — 判別問句:「這塊功能換成現成 SaaS / 套件,系統的差異化會消失嗎?」
+> (差異化不限商業競爭優勢;內部系統指獨特的營運優勢 / 任務成果。)會 → `core`;
+> 不會、但需要為自家流程客製 → `supporting`(必要、常需客製、非差異化);
+> 不會、且現成方案存在 → `generic`。多數 BC 是 supporting,`core` 通常只有 1–2 個;
+> 全標 core = 沒分類。分類是可修訂的初判,改判時更新本欄並在 Notes 留一行理由。
+> 它影響漸進抽離的取捨(`generic` 傾向整塊替換而非逐條抽離,見 modify-existing-flow
+> Step 4),但**不**降低 BR 紀錄、Tier ceremony、或安全 / 測試 / 可靠性要求。
 
 ## 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} |
+| {Source} | {Target} | {Customer/Supplier, Conformist, ACL, Shared Kernel, Separate Ways, Big Ball of Mud (BBoM), OHS, etc.} | {DB table, service call, file, manual process} | {optional notes} |
 
 ## Integration Notes
 

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

@@ -1,10 +1,10 @@
 ---
-id: BUG-{NUMBER}
+id: BUG-{NUMBER}    # bug-type T2 only; a non-bug T2 (lightweight-{date}-{slug}.md) carries no id — the filename identifies it
 title: {簡述問題}
-status: in-progress
+status: in-progress    # in-progress | completed
 bounded-context: {ContextName}
 created: {YYYY-MM-DD}
-branch: bugfix/BUG-{NUMBER}-{short-description}
+branch: bugfix/BUG-{NUMBER}-{slug}
 ---
 
 <!--

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

@@ -1,11 +1,11 @@
 ---
-id: {CONTEXT}-{NUMBER}
+spec-id: SPEC-{YYYYMMDD}-{NNN}    # the owning feature's SPEC-ID (matches the feature directory name)
 title: Feature title
-status: draft | in-progress | completed
+status: in-progress    # in-progress | completed
 bounded-context: {ContextName}
 created: {YYYY-MM-DD}
 author: {developer-name}
-branch: feature/{CONTEXT}-{NUMBER}-{short-description}
+branch: feature/{SPEC-ID}-{slug}
 ---
 
 # {Feature Title}