dflow-sdd-ddd 0.10.0 → 0.12.0

package/templates/greenfield/references/drift-verification.md

@@ -4,18 +4,24 @@ Triggered by `/dflow:verify` or `/dflow:verify <bounded-context>`.
 
 ## Purpose
 
-The A+C structure (`rules.md` as index + `behavior.md` as scenario content) introduces a drift risk — the two files can fall out of sync. This command provides a mechanical verification safety net that developers can run at key moments: before a PR, after a refactor, or when onboarding to an unfamiliar Bounded Context.
+The A+C structure (`rules.md` as index + `behavior.md` as scenario content) introduces a drift risk — the two files can fall out of sync. This command's **core** is a mechanical safety net for that `rules.md` ↔ `behavior.md` correspondence, run at key moments: before a PR, after a refactor, or when onboarding to an unfamiliar Bounded Context. On top of the core it also runs **optional, non-blocking domain-doc hygiene checks** on the BC's other docs (`events.md`, `models.md`) — see Scope.
 
 ## Scope
 
-### This command does (mechanical layer)
+### This command does (core + optional hygiene)
 
-Three string-matching checks that AI can perform deterministically:
+A small **core** of three deterministic string-matching checks on the
+`rules.md` ↔ `behavior.md` correspondence:
 
 1. **BR-ID forward check**: Every `BR-*` declared in `rules.md` has a corresponding section in `behavior.md`
 2. **Anchor validity**: If `rules.md` links to `behavior.md#section`, that anchor exists
 3. **BR-ID reverse check**: Every `BR-*` referenced in `behavior.md` is declared in `rules.md`
 
+Plus **optional domain-doc hygiene** warnings (non-blocking — they never fail the
+command, only surface "confirm this is intentional" signals): the `events.md`
+cross-check (forward + reverse, see Core-Specific Notes) and the `models.md`
+Code-Mapping hygiene check (see Model Catalog Notes).
+
 ### This command does NOT do (semantic layer — explicitly excluded)
 
 Semantic verification (LLM reads the one-line summary in `rules.md` vs the Given/When/Then in `behavior.md` and judges whether they contradict) is **out of scope**. Reasons:
@@ -40,9 +46,9 @@ Reasons:
 - BC-level current state is already maintained by `rules.md` /
   `behavior.md` / `events.md`, written by the same
   `/dflow:finish-feature` Step 3
-- `/dflow:verify` keeps a small, mechanical scope: just the
-  `rules.md` ↔ `behavior.md` correspondence inside one BC, plus the
-  events.md bonus check below
+- `/dflow:verify` keeps a small core: the `rules.md` ↔ `behavior.md`
+  correspondence inside one BC, plus the optional domain-doc hygiene
+  checks below (events.md, models.md)
 - Cross-feature / cross-phase aggregation would mix `/dflow:verify`'s
   job with `/dflow:finish-feature`'s job and produce false positives
   during in-progress features
@@ -86,6 +92,10 @@ For each Bounded Context:
       - behavior.md → templates/behavior.md
       Or run the completion flow to populate it from existing completed specs
   ```
+- Also locate the **optional** hygiene inputs for this BC — `events.md` and
+  `models.md`. They feed the non-blocking hygiene checks (Core-Specific Notes /
+  Model Catalog Notes). If either is absent, **skip its hygiene check silently** —
+  do not report or stop; they are bonus, not part of the core.
 
 ### Step 2: Extract BR-IDs from rules.md
 
@@ -155,15 +165,52 @@ Issues:
      remove the stale scenario reference from behavior.md
 ```
 
+The optional domain-doc hygiene checks (below) append their non-blocking signals
+to this same report — the `events.md` cross-check as `⚠`, the `models.md`
+Code-Mapping check as `ℹ` — and never change the core pass / fail count.
+
 ## Core-Specific Notes
 
-When verifying a Core context, also check:
-- `events.md` references in `behavior.md`: if a scenario says "And {DomainEvent} is raised", confirm the event is listed in `events.md`
-- This is a **bonus check**, not a blocking failure — report as a warning:
+When verifying a Core context, also run the `events.md` cross-check — **both
+directions, bonus only** (warnings, never a blocking failure):
+
+- **Forward** — `events.md` referenced from `behavior.md`: if a scenario says
+  "And {DomainEvent} is raised", confirm the event is listed in `events.md`:
   ```
   ⚠ BR-001 scenario references ExpenseReportSubmitted event,
     but events.md does not list it
   ```
+- **Reverse** — an `events.md` event with no scenario: for each Event Catalog row
+  that is **locally produced** (Producer is this BC's Aggregate / Application
+  Service) **and business-significant**, confirm at least one `behavior.md`
+  scenario references it; warn if none:
+  ```
+  ⚠ events.md lists OrderCancelled (produced by Order) but no behavior.md
+    scenario references it — confirm intentional (orphan / not yet specced)
+  ```
+  Exclude (else noisy): the `{EventName}` seed row, and best-effort side-effect
+  events (notification / logging) that the modeling guide lets live in
+  `events.md` / tech-debt without a BR. The reverse check is deterministic name
+  matching **plus** this applicability judgment — not a pure string match.
+
+## Model Catalog Notes
+
+A non-blocking **informational** hygiene check on `models.md`:
+
+- For each row whose **primary name cell** holds a real value, if the
+  `Code Mapping` column is empty or still a `{Namespace.Class}` placeholder,
+  surface it:
+  ```
+  ℹ models.md: Entity "ExpenseReport" has no Code Mapping yet — link it if the
+    code exists; if it is deliberately deferred, this is expected
+  ```
+- **Skip untouched seed rows by the name cell only**: a row whose name is still a
+  `{...}` placeholder is seed scaffolding. But a row with a **real name** and a
+  placeholder / empty Code Mapping is exactly the one to surface — do not skip it
+  just because that one cell still holds `{...}`.
+- This is **informational, not drift** — a recorded model with no Code Mapping is a
+  normal state before the code is written. An explicit "planned / deferred" note on
+  the row counts as accounted for; do not surface it.
 
 ## When to Run
 
@@ -178,9 +225,10 @@ Recommended trigger points (not enforced — developer's judgment):
 ## Path Assumptions
 
 This command operates entirely within `dflow/specs/domain/{context}/` files
-(`rules.md`, `behavior.md`, and the `events.md` bonus check). It does
-**not** read from `dflow/specs/features/active/{SPEC-ID}-{slug}/` directories
-— the feature directory layout is not part of verify's input.
+(`rules.md` and `behavior.md` for the core check; `events.md` and `models.md`
+for the optional hygiene warnings). It does **not** read from
+`dflow/specs/features/active/{SPEC-ID}-{slug}/` directories — the feature
+directory layout is not part of verify's input.
 
 ## Interaction with Other Commands
 

package/templates/greenfield/references/finish-feature-flow.md

@@ -56,6 +56,10 @@ proceeding (do not flip status, do not archive, do not emit summary).
 - [ ] Every phase-spec file referenced in the Phase Specs table exists at
       the path the table claims
 - [ ] Every phase-spec file's frontmatter has `status: completed`
+- [ ] Every Tier = T2 row in `_index.md` Lightweight Changes references an
+      existing `lightweight-*.md` / `BUG-*.md` file in the feature directory
+- [ ] Every such lightweight / BUG spec file's frontmatter has
+      `status: completed`
 - [ ] `_index.md` has no obvious open items in Resume Pointer (e.g. "phase-N
       drafting" / "implementation pending" / "TODO" markers)
 - [ ] Current BR Snapshot table is non-empty (or feature is intentionally
@@ -66,6 +70,7 @@ If any check fails:
 > found:
 >   ✗ phase-spec-2026-04-15-foo.md status is still `in-progress`
 >   ✗ Phase Specs table row 3 references missing file phase-spec-...
+>   ✗ lightweight-2026-06-20-rounding.md frontmatter status is still `in-progress`
 >
 > Address these (run `/dflow:new-phase` to add missing work, or fix the
 > stale status manually), then re-run `/dflow:finish-feature`."
@@ -93,11 +98,17 @@ branch: feature/{SPEC-ID}-{slug}
 ---
 ```
 
-Also update the **Resume Pointer** to reflect closeout:
+Also update the **Resume Pointer** to reflect closeout — this writes the
+cursor's terminal state (after closeout no workflow is active on this
+feature; do not edit the cursor again after the Step 4 closeout commit):
 
 ```
 **Current Progress**: feature completed ({date}); all phase-specs status = completed.
 **Next Action**: integration — push / merge / PR per the selected Git policy.
+**Active Workflow**: none
+**Current Step**: n/a
+**Gates Passed**: n/a
+**Awaiting**: none
 ```
 
 **→ Transition (step-internal)**: Step 2 complete. Announce "Step 2 complete (status flipped). Entering Step 3: Sync BR Snapshot to BC layer." and continue.
@@ -184,7 +195,8 @@ AI runs:
 ```bash
 git mv dflow/specs/features/active/{SPEC-ID}-{slug} \
        dflow/specs/features/completed/{SPEC-ID}-{slug}
-git status   # confirm rename detection
+git status   # confirm rename detection AND check for `RM` — an `M` next to
+             # a rename means unstaged edits you must re-add before committing
 ```
 
 `git mv` is mandatory — never use plain `mv` + `git add`. This preserves
@@ -193,37 +205,75 @@ PR diff quality stays intact across the move. See
 `references/git-integration.md` § "Directory Moves Must Use git mv" for
 the full rule set.
 
-After the move, also `git add` any modified files from Step 3 (the
-updated `rules.md`, `behavior.md`, `events.md`, `context-map.md`,
-`glossary.md`, `architecture/tech-debt.md`, etc.) into the same stage.
-
 **Closeout commit checkpoint** (completes the offline Local-closeout gate):
 
 ```
-✓ Feature archived to completed/ and closeout files staged
+✓ Feature archived to completed/ and closeout ready to stage
    Commit this closeout now?
    [Y] Yes — the AI commits with your Git identity (marker per _conventions.md § AI Commit Policy)
    [N] No — skip; you commit yourself
 ```
 
-Whether you choose Y or N, record one row in the feature `_index.md`
-Checkpoint Log (`closeout | committed ({hash})` or `closeout | skipped`). Only
-write a hash after the commit actually succeeds; if a pre-commit hook rejects it
-or the commit fails, record `failed` and surface the error — never write a fake
-hash.
-
-The Local-closeout gate is satisfied **only when the closeout is committed**:
-closeout complete, Checkpoint Log updated, and the working tree clean (no
-uncommitted changes). If you declined the commit (chose N) or it failed,
-Local-closeout is **not** satisfied yet — commit the staged closeout yourself
-before continuing; do not enter the Integration / PR gate with uncommitted
-changes. Once committed, the gate stands on its own offline; integration happens
-in Step 5 when you have network.
-
-**→ Transition (step-internal)**: Step 4 complete. Branch on whether the closeout commit landed:
-
-- **Closeout commit landed (working tree clean)** → announce "Step 4 complete (feature archived; Local-closeout gate satisfied). Entering Step 5: Integration / PR gate." and continue.
-- **Closeout commit was declined (N) or failed** → **stop here.** Announce "Step 4 complete (feature archived), but the Local-closeout gate is not satisfied yet — the closeout is staged but uncommitted. Commit those changes (or address the failure), then resume to Step 5." Do **not** enter Step 5 with uncommitted closeout changes.
+Then, in this order:
+
+1. **Record the checkpoint row first.** Write one row in the moved
+   `_index.md` Checkpoint Log — `closeout | committed` for Y, `closeout |
+   skipped` for N. The closeout row carries **no commit hash**: the closeout
+   commit cannot contain its own hash. Trace it later via
+   `git log -1 -- dflow/specs/features/completed/{SPEC-ID}-{slug}` (or the
+   optional `Dflow-Checkpoint` trailer). The "hash only after success" rule
+   still applies to spec / implementation rows — closeout is the documented
+   exception (see `references/git-integration.md` § Commit Checkpoints,
+   Branch Gate & AI Commits).
+2. **Stage the whole archived feature directory:**
+
+   ```bash
+   git add dflow/specs/features/completed/{SPEC-ID}-{slug}
+   ```
+
+   This is required, not optional: `git mv` stages the rename with the
+   **last-committed** content, so working-tree edits made earlier in this
+   flow to the moved files — the Step 2 status flip and Resume Pointer
+   update, plus the checkpoint row you just wrote — stay **unstaged** until
+   this `git add`. In `git status`, the moved `_index.md` showing `RM`
+   instead of plain `R` is exactly this signal. Then also `git add` the
+   files updated in Step 3 (the updated `rules.md`, `behavior.md`,
+   `events.md`, `context-map.md`, `glossary.md`,
+   `architecture/tech-debt.md`, etc.) into the same stage.
+3. **Commit (Y) or stop (N).** For Y the AI commits. If a pre-commit hook
+   rejects it or the commit fails, flip the checkpoint row to `failed` (the
+   row is not committed yet — edit it directly), surface the error, and
+   treat the gate as unsatisfied.
+
+**Post-commit closeout verification** — after a successful commit, and before
+declaring the Local-closeout gate satisfied, AI runs and reports `✓` / `✗` for
+every item:
+
+- [ ] `git show HEAD:dflow/specs/features/completed/{SPEC-ID}-{slug}/_index.md`
+      — one blob read verifying **two** things: frontmatter `status: completed`
+      **and** the Checkpoint Log contains the closeout row. This reads the
+      **committed** content, not the working tree — the former catches "rename
+      carried stale content", the latter catches "row never made it into the
+      commit".
+- [ ] `dflow/specs/features/active/{SPEC-ID}-{slug}/` no longer exists (the
+      directory was moved, not copied)
+- [ ] `git status --short` shows no leftovers related to this feature
+      (working tree clean; identify any unrelated dirty files explicitly)
+
+If any item fails, do **not** declare closeout complete — fix it (re-add and
+amend, or a follow-up commit; the developer chooses) and re-verify.
+
+The Local-closeout gate is satisfied **only when the closeout is committed and
+the verification above passes**. If you declined the commit (chose N) or it
+failed, Local-closeout is **not** satisfied yet — commit the staged closeout
+yourself before continuing; do not enter the Integration / PR gate with
+uncommitted changes. Once committed and verified, the gate stands on its own
+offline; integration happens in Step 5 when you have network.
+
+**→ Transition (step-internal)**: Step 4 complete. Branch on the verification result:
+
+- **Closeout commit landed and post-commit verification passed** → announce "Step 4 complete (feature archived; Local-closeout gate satisfied). Entering Step 5: Integration / PR gate." and continue.
+- **Closeout commit was declined (N), failed, or verification reported `✗`** → **stop here.** Announce "Step 4 complete (feature archived), but the Local-closeout gate is not satisfied yet — the closeout is staged but uncommitted, or the committed content failed verification. Commit the staged changes (or fix the failure), then resume to Step 5." Do **not** enter Step 5 with uncommitted or unverified closeout changes.
 
 ## Step 5: Emit Integration Summary (Git-strategy-neutral)
 
@@ -286,10 +336,17 @@ the developer:
 
 If no `follow-up-of` field, skip Step 6 and announce closeout complete:
 > "`/dflow:finish-feature` complete for `{SPEC-ID}-{slug}`. Feature
-> directory is now at `dflow/specs/features/completed/{SPEC-ID}-{slug}/`.
-> If you skipped the closeout commit, commit the staged changes first to
-> finish the Local-closeout gate. Then integration — merge / push / PR —
-> follows the selected Git policy, at your discretion."
+> directory is now at `dflow/specs/features/completed/{SPEC-ID}-{slug}/`,
+> with the Local-closeout gate satisfied (closeout committed and verified).
+> Integration — merge / push / PR — follows the selected Git policy, at
+> your discretion."
+
+**In-flight reminder** — after the closeout announcement (with or without
+Step 6), run the in-flight overview scan (see `AI-AGENT-GUIDE.md` § Status /
+Control Commands) and list any other unfinished features in `active/` and any
+in-flight feature / bugfix branches. Surfacing them at closeout is deliberate:
+attention is about to move elsewhere, and this is exactly where half-done work
+sinks.
 
 ## Step 6: Reverse-Update Follow-up Tracking (only if follow-up)
 

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

@@ -43,8 +43,8 @@ bugfix/{BUG-ID}-{slug}
 Examples:
 
 ```
-feature/EXP-001-expense-submission-aggregate
-feature/HR-003-leave-approval-workflow
+feature/SPEC-20260424-002-submit-expense-report
+feature/SPEC-20260430-001-leave-approval-workflow
 bugfix/BUG-042-money-rounding
 ```
 
@@ -149,10 +149,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
 
@@ -312,9 +332,9 @@ with the rule.
 ```
 [SPEC-ID] Short description
 
-[EXP-001] Define ExpenseReport Aggregate with submission invariants
-[EXP-001] Add CreateExpenseReport command and handler
-[EXP-001] Implement persistence configuration for ExpenseReport
+[SPEC-20260424-002] Define ExpenseReport Aggregate with submission invariants
+[SPEC-20260424-002] Add CreateExpenseReport command and handler
+[SPEC-20260424-002] Implement persistence configuration for ExpenseReport
 [BUG-042] Fix rounding in Money value object
 ```
 

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

@@ -9,6 +9,8 @@ Triggered by `/dflow:modify-existing` or `/dflow:bug-fix` (or natural language i
 - Step 3 → Step 4 (DDD impact decision → implement)
 - Step 4 → Step 5 (implementation done → update documentation)
 
+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.
 
 **Note on step count**: Greenfield edition has 5 steps (Brownfield has
@@ -61,6 +63,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
@@ -237,6 +249,17 @@ Changes that require Aggregate redesign:
 boundary still make sense, or do we need to split/merge?"
 ```
 
+**Established-model re-read.** When the change extends an existing
+Aggregate, re-read that Aggregate's recorded Design Decisions — its
+`aggregate-design.md` worksheet in the feature directory that introduced it
+(usually under `features/completed/`). 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.
+
 ### Do we need new Domain Events?
 
 If the behavior change means other parts of the system need to react differently:

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

@@ -10,6 +10,8 @@ Triggered by `/dflow:new-feature` (or natural language implying a new-feature ta
 - 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).
@@ -31,6 +33,27 @@ Check existing assets:
 - Search `dflow/specs/features/` for related features
 - Check `dflow/specs/domain/glossary.md` and `context-map.md`
 
+**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.
+
 **→ Transition (step-internal)**: Step 1 complete. Announce "Step 1 complete (intake). Entering Step 2: Identify the Bounded Context." and continue.
 
 ## Step 2: Identify the Bounded Context
@@ -52,13 +75,36 @@ If it crosses contexts:
 - Do we need an Anti-Corruption Layer?"
 ```
 
+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 in `context-map.md`, reuse it — don't
+re-ask unless the developer wants to reclassify. Record it in
+`dflow/specs/domain/context-map.md`:
+
+- If the **Subdomain Type column is missing** (an older context-map), add the
+  column **preserving every existing row** — do not rewrite their content.
+- The greenfield context-map is created at init, so the file normally exists;
+  if for any reason it is absent, create it from `templates/context-map.md`.
+
+The classification sets the modeling depth used in Step 3 (see
+`references/ddd-modeling-guide.md` § Subdomain-Aware Modeling Depth).
+
 **→ Transition (step-internal)**: Step 2 complete. Announce "Step 2 complete (BC identified). Entering Step 3: Domain Modeling." and continue.
 
 ## Step 3: Domain Modeling
 
 This is where the Greenfield Clean Architecture workflow diverges
 significantly from the Brownfield edition.
-Read `references/ddd-modeling-guide.md` for detailed patterns.
+Read `references/ddd-modeling-guide.md` for detailed patterns. Apply the
+modeling depth set by this BC's Subdomain Type from Step 2 (see that guide's
+§ Subdomain-Aware Modeling Depth): a `generic` context gets a thin model, not
+the full tactical treatment below.
 
 Walk through:
 
@@ -73,6 +119,17 @@ Those things form an Aggregate. Everything else is eventually consistent."
 - What entities belong inside this Aggregate?
 - What Value Objects can we extract?
 
+**Established-model re-read (when the feature reuses an existing
+Aggregate).** Re-read that Aggregate's recorded Design Decisions — its
+`aggregate-design.md` worksheet in the feature directory that introduced it
+(usually under `features/completed/`) — 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
+phase-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.
+
 ### Domain Events
 ```
 "After this happens, what else in the system needs to know?"
@@ -169,17 +226,22 @@ 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 Domain layer."
+   - Resume Pointer: "phase-1 in progress: drafting phase-spec." / "Next Action: finish phase-spec, then implement Domain layer." / 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
    delta against).
-4. **If this feature introduces a new Aggregate**, also create an
-   `aggregate-design.md` from `templates/aggregate-design.md` **inside this
-   feature directory** as the per-Aggregate design worksheet. It is a working
-   artifact scoped to the feature; the Aggregate's durable, long-lived catalog
-   entry still lives in `dflow/specs/domain/{context}/models.md`.
-   `aggregate-design.md` complements `models.md`, it does not replace it.
+4. **If this feature introduces a new Aggregate**, whether to create an
+   `aggregate-design.md` worksheet from `templates/aggregate-design.md`
+   **inside this feature directory** follows the BC's Subdomain Type (Step 2;
+   see `references/ddd-modeling-guide.md` § Subdomain-Aware Modeling Depth):
+   **core** → create it; **supporting** → create it but keep it lean;
+   **generic** → skip by default (a thin wrapper needs no design worksheet)
+   unless the developer explicitly opts into deeper modeling and records why.
+   When created, it is a working artifact scoped to the feature; the
+   Aggregate's durable, long-lived catalog entry still lives in
+   `dflow/specs/domain/{context}/models.md` — `aggregate-design.md`
+   complements `models.md`, it does not replace it.
 
 Key additions compared to Brownfield edition:
 - **Aggregate State Transitions**: Document how Aggregate state changes

package/templates/greenfield/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.
@@ -66,6 +68,11 @@ AI must locate the target feature and load its current state:
    - 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`)
+   - 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)**
 
@@ -95,7 +102,14 @@ 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 Aggregate / Domain concepts introduced or changed?** New
-   Aggregates, Value Objects, Domain Events, or invariants?
+   Aggregates, Value Objects, Domain Events, or invariants? Model new concepts
+   at the depth set by the BC's Subdomain Type (see
+   `references/ddd-modeling-guide.md` § Subdomain-Aware Modeling Depth) — don't
+   bypass the classification just because this is a phase, not a new feature.
+   If the phase **extends an existing Aggregate**, 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. **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.)

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

@@ -116,7 +116,15 @@ If the closeout commit is in this PR (`/dflow:finish-feature` was run):
 
 ## Cross-Cutting
 
-- [ ] **Glossary consistency** — new terms documented?
+- [ ] **Glossary consistency** — any new business concept added to `glossary.md`?
+- [ ] **Naming matches the Ubiquitous Language** — for each **domain-facing** type
+      or member 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 in the diff 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 (e.g. "reimbursement" in code vs "報銷 / Expense Claim" in the
+      glossary)? Align it. (Judgment call, not a string match.)
 - [ ] **Context boundaries respected** — no reaching into another context's internals
 - [ ] **Domain Events documented** — events.md updated?
 - [ ] **Tests cover invariants** — not just happy path