dflow-sdd-ddd 0.9.0 → 0.11.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,12 +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. The only effect of feature directory layout on this
-command is ensuring `last-updated` dates in `behavior.md` are bumped at
-`/dflow:finish-feature` time (so verify's mechanical drift guard stays
-useful).
+(`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

@@ -35,7 +35,7 @@ state, archives the feature directory, and emits a Git-strategy-neutral
 - Step 5 → Step 6 (Integration Summary emitted → optional follow-up reverse-link)
 
 All other step transitions are **step-internal**: announce "Step N complete,
-entering Step N+1" and proceed without waiting. See SKILL.md § Workflow
+entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow
 Transparency for the full transparency protocol and confirmation signals.
 
 ## Step 1: Validate Phase Specs and `_index.md`
@@ -127,6 +127,8 @@ For each row in Current BR Snapshot where Status = `active`:
   `rules.md` (REMOVED rule)
 - For any RENAMED BR-ID → rename the BR-ID in `rules.md` and update
   `glossary.md` if the term itself changed
+- For every BR-ID added, modified, or renamed above, set its `Last updated`
+  date in `rules.md`'s Rule Index to today
 
 For `behavior.md`:
 
@@ -136,7 +138,6 @@ For `behavior.md`:
   transitions and Domain Events as appropriate
 - For REMOVED BR-IDs, delete the corresponding scenario section from
   `behavior.md`
-- Update the BR-ID anchor's `last-updated` date in `behavior.md` to today
 
 For `events.md`:
 - Add any new Domain Events introduced by phase-specs in this feature

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

@@ -182,7 +182,6 @@ diff. That breaks:
 - `git blame` on lines that crossed the rename boundary
 - PR diff quality (reviewers see two unrelated big-blob changes
   instead of one rename + small content diff)
-- `/dflow:verify` and other tools that walk feature history
 
 This is a known weakness of OpenSpec's directory-rename pattern; Dflow
 deliberately avoids it by mandating `git mv`.

package/templates/greenfield/references/init-project-flow.md

@@ -54,8 +54,8 @@ Report findings plainly:
 >  - `src/`: contains `MyApp.Domain`, `MyApp.Application`,
 >    `MyApp.Infrastructure`, `MyApp.WebAPI` → Clean Architecture layout
 >    detected
->  - `CLAUDE.md`: present → will not overwrite; I'll offer a snippet
->    to merge into it"
+>  - `CLAUDE.md`: present → I'll append a marked Dflow block (shown in
+>    the preview); a merge snippet only if there's a marker conflict"
 
 Or:
 
@@ -173,9 +173,10 @@ Wait for answers.
 >
 > If you select any agent, Dflow will create
 > `dflow/specs/shared/AI-AGENT-GUIDE.md` as the canonical guide. Root-level
-> tool files stay thin and point back to that guide. Existing tool files are
-> never overwritten; Dflow writes merge snippets under `dflow/specs/shared/`
-> instead."
+> tool files stay thin and point back to that guide. Existing user content is
+> never overwritten; Dflow appends a marked Dflow block (shown in the preview)
+> and refreshes it in place on re-run. Merge snippets under
+> `dflow/specs/shared/` are used only if Dflow markers conflict."
 
 **→ Transition (step-internal)**: Step 2 complete. Announce
 > "Step 2 complete (project information captured). Entering Step 3:
@@ -246,16 +247,17 @@ vendored workflow bundle). Compute the destination path:
 | `scaffolding/Git-principles-trunk.md` | `dflow/specs/shared/Git-principles-trunk.md` |
 | `scaffolding/AI-AGENT-GUIDE.md` | `dflow/specs/shared/AI-AGENT-GUIDE.md` when at least one AI agent is selected |
 | generated tool shim | `AGENTS.md`, `CLAUDE.md`, or `.github/copilot-instructions.md` when selected and missing |
-| generated merge snippet | `dflow/specs/shared/*-snippet.md` when the selected tool file already exists |
+| marked Dflow block | appended to a selected existing tool file unless it already points to `AI-AGENT-GUIDE.md`; refreshed in place on re-run |
+| fallback merge snippet | `dflow/specs/shared/*-snippet.md` only when the selected tool file has conflicting or malformed Dflow markers |
 
 ### 3.3 Present the preview
 
-Present the complete file list as two tables, separating create vs
+Present the complete file list as two tables, separating create / update vs
 skip, and wait for developer confirmation:
 
 > "Based on Step 1 inventory + Step 2 answers, here is what I'll do:
 >
-> **Will create ({N} files):**
+> **Will create / update ({N} files):**
 >
 > | Path | Source |
 > |---|---|
@@ -270,7 +272,7 @@ skip, and wait for developer confirmation:
 > | `dflow/specs/shared/_overview.md` | optional (you picked it) |
 > | `dflow/specs/shared/Git-principles-trunk.md` | mandatory (selected Git policy) |
 > | `dflow/specs/shared/AI-AGENT-GUIDE.md` | selected AI agent guide |
-> | `CLAUDE.md` | selected tool shim because repo has no CLAUDE.md |
+> | `CLAUDE.md` | marked Dflow block appended to existing CLAUDE.md (shown in preview) |
 >
 > **Will skip ({M} files — already present):**
 >
@@ -346,11 +348,24 @@ guide.
 For each selected tool-specific file (`AGENTS.md`, `CLAUDE.md`,
 `.github/copilot-instructions.md`):
 
+(checked in this order — the first matching rule wins):
+
 - if the target file does not exist, create a small shim at the target
   path that points to `dflow/specs/shared/AI-AGENT-GUIDE.md`
-- if the target file already exists, do not overwrite it; write a merge
-  snippet under `dflow/specs/shared/` and report that the developer
-  should merge it manually
+- if the target file contains conflicting or malformed Dflow markers, do not
+  edit it; write a fallback merge snippet under `dflow/specs/shared/` and
+  report that the developer should merge it manually
+- if the target file already contains a single well-formed Dflow marked block,
+  replace that block in place (idempotent refresh) and keep the rest of the
+  file unchanged
+- if the target file is an existing whole-file Dflow-generated shim, refresh it
+  in place
+- if the target file already points to the guide through the developer's own
+  pointer (and has no Dflow marked block), leave it untouched
+- otherwise preserve the existing content and append a marked Dflow block at
+  the end of the file, keeping the file's dominant line ending; show that block
+  in the preview, and refresh that same block on re-run. If the developer later
+  deletes the block, a later `init` / `configure-agents` run appends it again
 
 ### 4.4 Directory-only entries
 
@@ -380,7 +395,7 @@ Summarise what actually happened and point at the next command.
 ```
 Init complete. Summary:
 
-  Created ({N} files):
+  Created / Updated ({N} files):
     ✓ dflow/specs/features/active/.gitkeep
     ✓ dflow/specs/features/completed/.gitkeep
     ✓ dflow/specs/features/backlog/.gitkeep
@@ -391,7 +406,7 @@ Init complete. Summary:
     ✓ dflow/specs/architecture/decisions/README.md
     ✓ dflow/specs/shared/_overview.md
     ✓ dflow/specs/shared/Git-principles-trunk.md
-    ✓ CLAUDE.md (seeded from scaffolding snippet)
+    ✓ CLAUDE.md (marked Dflow block appended)
 
   Skipped ({M} files already present):
     - (none this run)
@@ -445,10 +460,9 @@ Remind the developer to review files that have `{placeholder}` tokens
 still in them:
 
 > "A few files still have `{placeholder}` tokens that need your input:
->  - `dflow/specs/shared/_overview.md`: `{業務領域}`, `{團隊}`,
->    `{使用者規模}`
+>  - `dflow/specs/shared/_overview.md`: the Business Domain and Technical
+>    Architecture fields (e.g. primary domain, stakeholders, user scale, stack)
 >  - `dflow/specs/domain/context-map.md`: context list and relationships
->  - `CLAUDE.md`: `{業務領域}`
 >
 >  These are fine to leave for now; fill them in during your next
 >  review pass."

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

@@ -2,14 +2,14 @@
 
 Step-by-step guide for changing or fixing existing functionality.
 
-Triggered by `/dflow:modify-existing` or `/dflow:bug-fix` (or natural language implying a modification task — see SKILL.md § Workflow Transparency for the auto-trigger safety net).
+Triggered by `/dflow:modify-existing` or `/dflow:bug-fix` (or natural language implying a modification task — see AI-AGENT-GUIDE.md § Workflow Transparency for the auto-trigger safety net).
 
 **Step Gates** in this flow (stop-and-confirm before proceeding):
 - Step 2 → Step 3 (baseline captured → assess DDD impact)
 - Step 3 → Step 4 (DDD impact decision → implement)
 - Step 4 → Step 5 (implementation done → update documentation)
 
-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.
+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
 6) because Clean Architecture's layered structure already separates
@@ -29,7 +29,7 @@ This step has three parallel concerns:
 
 **Part A — Determine the Ceremony Tier (T1 / T2 / T3)**
 
-Dflow runs three ceremony tiers (full table in SKILL.md § Ceremony Scaling).
+Dflow runs three ceremony tiers (full table in AI-AGENT-GUIDE.md § Ceremony Scaling).
 For a modification, AI judges which tier fits before deciding what to
 produce:
 
@@ -147,7 +147,7 @@ add a row:
 | {新 SPEC-ID} | {新 slug} | {today} | in-progress |
 ```
 
-This update is **part of the same change set** (the developer commits
+This update is **part of the same change set** (offer to commit
 both at once; commit message should mention "Add follow-up reference to
 `{新 SPEC-ID}`"). The reverse link is a derived index — the new
 feature's `follow-up-of` field is the authoritative source.
@@ -158,8 +158,6 @@ phase's content).
 
 ## Step 2: Check Documentation
 
-## Step 2: Check Documentation
-
 - Spec in `dflow/specs/features/completed/`?
 - Domain model in `dflow/specs/domain/{context}/models.md`?
 - Business rules in `rules.md`?
@@ -305,7 +303,7 @@ Items marked *(post-5.3)* are re-verified after the documentation merge in 5.3 l
 - [ ] ORM / persistence mapping is kept outside Domain entities (no persistence attributes/annotations on Domain entities)
 - [ ] `Implementation Tasks` section (`phase-spec.md` or `lightweight-spec.md`): all tasks checked, or unchecked items explicitly labelled as follow-up
 - [ ] *(post-5.3)* `dflow/specs/domain/{context}/behavior.md` has a section anchor for every `BR-*` in ADDED / MODIFIED entries; REMOVED entries' anchors have been deleted (mechanical input for `/dflow:verify`)
-- [ ] *(post-5.3)* `dflow/specs/domain/{context}/behavior.md` `last-updated` is later than this spec's `created` date (mechanical drift guard)
+- [ ] *(post-5.3)* every ADDED / MODIFIED / RENAMED BR's `Last updated` in `dflow/specs/domain/{context}/rules.md` is later than this spec's `created` date (mechanical drift guard)
 
 If any item fails, report the gap and pause — don't proceed to 5.2.
 

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

@@ -2,7 +2,7 @@
 
 Step-by-step guide for adding a new feature with full DDD and Clean Architecture.
 
-Triggered by `/dflow:new-feature` (or natural language implying a new-feature task — see SKILL.md § Workflow Transparency for the auto-trigger safety net behavior).
+Triggered by `/dflow:new-feature` (or natural language implying a new-feature task — see AI-AGENT-GUIDE.md § Workflow Transparency for the auto-trigger safety net behavior).
 
 **Step Gates** in this flow (stop-and-confirm before proceeding):
 - Step 3 → Step 3.5 (Aggregate / VO / Events identified → confirm slug + directory + branch names)
@@ -10,9 +10,9 @@ 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)
 
-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.
+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 SKILL.md § Ceremony Scaling).
+**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).
 
 ## Step 1: Intake — Understand the Request
 
@@ -42,7 +42,7 @@ Check `dflow/specs/domain/context-map.md`:
 [Context] bounded context. Does that match your understanding?"
 ```
 
-If new context needed → use context-definition template.
+If a new context is needed → create `dflow/specs/domain/{new-context}/context.md` using the context-definition template (`templates/context-definition.md`).
 
 If it crosses contexts:
 ```
@@ -52,13 +52,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:
 
@@ -174,12 +197,17 @@ dflow/specs/features/active/{SPEC-ID}-{slug}/
    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
@@ -201,7 +229,7 @@ Scenario: Submit expense report
 Announce to developer:
 > "Spec is drafted — behavior scenarios, Aggregate state transitions, Domain Events, and CQRS split are captured. Ready to plan the layer-by-layer implementation (Domain → Application → Infrastructure → Presentation)? `/dflow:next` or reply 'OK' to continue, or tell me if the spec needs another iteration first."
 
-Wait for confirmation (`/dflow:next`, verbal OK, or implicit — see SKILL.md § Confirmation Signals) before entering Step 5.
+Wait for confirmation (`/dflow:next`, verbal OK, or implicit — see AI-AGENT-GUIDE.md § Confirmation Signals) before entering Step 5.
 
 ## Step 5: Plan the Implementation (Layer by Layer)
 
@@ -352,7 +380,7 @@ AI reports `✓` / `✗` for every item before touching docs. Items marked *(pos
 - [ ] Aggregate invariants still hold after the change (all state changes go through methods, no public setters)
 - [ ] ORM / persistence mapping is kept outside Domain entities (no persistence attributes/annotations on Domain entities)
 - [ ] *(post-8.3)* `dflow/specs/domain/{context}/behavior.md` contains a section anchor for every `BR-*` introduced by this spec (mechanical input for `/dflow:verify`)
-- [ ] *(post-8.3)* `dflow/specs/domain/{context}/behavior.md` `last-updated` is later than this spec's `created` date (mechanical drift guard)
+- [ ] *(post-8.3)* `dflow/specs/domain/{context}/rules.md` `last-updated` is later than this spec's `created` date (mechanical drift guard)
 
 If any item fails, report the gap and pause — don't proceed to 8.2.
 
@@ -384,12 +412,14 @@ Ask these one-by-one; do not dump all six at once.
 
 ### 8.4 Archival
 
-For a single-phase feature, this is the closeout point. For a multi-phase
-feature, the developer typically reaches this point at the end of the
-final phase — at which time `/dflow:finish-feature` is the recommended
-trigger (it bundles steps 8.1 / 8.2 verification, BC sync, and archival
-into one explicit ceremony). Either path is acceptable; pick the one
-that matches the developer's habit.
+For a single-phase feature, this is the closeout point. If the feature has
+later phases still ahead, this phase is complete but the feature is not —
+don't archive yet; run `/dflow:new-phase` to start the next phase, not
+`/dflow:finish-feature` yet. For a multi-phase feature, the developer
+typically reaches this point at the end of the final phase — at which time
+`/dflow:finish-feature` is the recommended trigger (it bundles steps 8.1 /
+8.2 verification, BC sync, and archival into one explicit ceremony). Either
+path is acceptable; pick the one that matches the developer's habit.
 
 - [ ] `_index.md` `status` field changed to `completed`
 - [ ] All `phase-spec-*.md` files in the feature directory have `status:

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

@@ -20,7 +20,7 @@ adds a new phase to an in-progress feature only.
 - 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
+entering Step N+1" and proceed without waiting. See AI-AGENT-GUIDE.md § Workflow
 Transparency for the full transparency protocol and confirmation signals.
 
 ## Step 1: Read Active Feature Context
@@ -95,7 +95,10 @@ 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.
 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