dflow-sdd-ddd 0.14.0 → 0.16.0

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

@@ -59,7 +59,32 @@ AI must locate the target feature and load its current state:
    completed = frozen-history semantic and produces confusing dir-rename
    history. The follow-up path is the only correct route.
 
-3. **Load context for the new phase**
+3. **Refuse if the target is a minimal (zero-phase) host**
+
+   Decide this from the **persisted shape** — the same selector closeout
+   uses: an **empty Phase Specs table and no `phase-spec-*` file** in the host
+   directory. Such a host records a small standalone or follow-up change and
+   is *defined* by carrying no phase. Adding one does not extend it; it turns
+   the host into a phase-bearing feature, and closeout will then check it as
+   one. Refuse with:
+
+   ```
+   "`{SPEC-ID}-{slug}` is a minimal (zero-phase) host — it records a
+   lightweight change and carries no phase-specs, so a phase cannot be
+   added to it.
+
+   If this is genuinely new T1 work, run /dflow:new-feature. If it is
+   another small change, run /dflow:modify-existing — its Step 1 decides
+   the tier and finds or opens the right host for it."
+   ```
+
+   Do NOT create a first phase-spec here to "make the host usable", and do
+   not jump into `modify-existing-flow.md` Step 1.6, 1.7 or 1.8 from here:
+   each of those assumes Step 1's tier decision and host-linkage scan have
+   already run, and entering one directly skips both. Send the developer to
+   Step 1, exactly as `new-feature-flow.md` Step 4's guard does.
+
+4. **Load context for the new phase**
    - Read the feature's `_index.md` — Metadata, Goals & Scope, Phase Specs,
      Current BR Snapshot, Resume Pointer
    - Read the most recent phase-spec to understand where the prior phase
@@ -74,7 +99,7 @@ AI must locate the target feature and load its current state:
      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)**
+5. **Branch gate — ensure you are on this feature's branch (before any commit)**
 
    This phase's commits must land on the active feature's
    `feature/{SPEC-ID}-{slug}` branch. If you are not already on it (you
@@ -113,9 +138,20 @@ Walk the developer through what the new phase covers:
 4. **Cross-context impact?** Does this phase introduce / change Domain
    Events that other contexts consume? (If yes, plan for `context-map.md`
    updates at finish-feature time.)
-5. **Data structure impact?** New tables, columns, indices, EF
+5. **System-level knowledge?** Does this phase add, change, or uncover an
+   ordered cross-context flow (always the domain-root copy), the lifecycle a
+   status field moves through, a figure computed rather than stored, a
+   mechanism no single rule explains, or which roles reach a function (always
+   the domain-root copy) — or work around a spot in one of them that only a
+   domain decision will settle (in the copy that holds the knowledge it is
+   stuck on)? If yes, record it in
+   `dflow/specs/domain/{context}/analysis.md` when one context owns what it
+   describes and in `dflow/specs/domain/analysis.md` when no one context does,
+   creating the file from `templates/analysis.md` the first time there is
+   something to record.
+6. **Data structure impact?** New tables, columns, indices, EF
    configuration changes?
-6. **Why now?** Priority — informs sequencing relative to other phases.
+7. **Why now?** Priority — informs sequencing relative to other phases.
 
 This is also the moment to ask: "Should this be its own follow-up feature
 instead of a phase here?" — useful when the scope drift suggests a
@@ -126,7 +162,7 @@ separate concern (different Aggregate, different BC, etc.).
 ## Step 3: Phase Slug Confirmation
 
 AI proposes the new phase-spec filename and asks the developer to confirm
-before any file is written.
+before the phase-spec is written.
 
 > "Proposed phase-spec for `{SPEC-ID}-{slug}`:
 >
@@ -169,6 +205,8 @@ frontmatter `status` to `in-progress`. Phase-2-onward specs **must** fill
 in the **Delta from prior phases** section (the first phase typically has
 just "首 phase，無前置 Delta"; this is phase 2+, so the section is required).
 
+> **Table-cell formatting**: keep table cells concise — separate multiple short items with `<br>` (never chain them into one line with ；/; separators), and move long narrative detail out of the cell into a document section (full convention: the formatting comment at each spec doc's head).
+
 Walk the developer through each section, in the same way `new-feature-flow`
 Step 4 does — Behavior (with Aggregate state transitions and Domain
 Events) / Business Rules / Delta / Edge Cases / Domain Events / layer-by-
@@ -200,6 +238,8 @@ Wait for confirmation before entering Step 5.
 
 Update the feature's `_index.md`:
 
+> **Table-cell formatting**: keep table cells concise — separate multiple short items with `<br>` (never chain them into one line with ；/; separators), and move long narrative detail out of the cell into a document section (full convention: the formatting comment at each spec doc's head).
+
 1. **Phase Specs table** — add a new row for this phase:
    ```
    | {N+1} | {YYYY-MM-DD} | {phase-slug} | in-progress | [phase-spec-{date}-{phase-slug}.md](./phase-spec-{date}-{phase-slug}.md) |
@@ -256,6 +296,14 @@ During implementation, continuously verify:
 - [ ] No business logic leaks into Application handlers, Infrastructure queries,
       or Presentation controllers
 - [ ] Test failures have been resolved or explicitly recorded as follow-up
+- [ ] Every entry Step 2 recorded in `analysis.md`, at either of its two
+      paths, still holds. An entry for what this phase was to add or change
+      matches what it built — corrected where the build differs, removed
+      where nothing was built for it. An entry for something Step 2
+      uncovered in the existing system matches the system as it now stands —
+      corrected where this phase changed it, never removed because this
+      phase built nothing for it. Read the entries in the file, not in a
+      diff: a checkpoint may already have committed them.
 
 If implementation changes the agreed Delta, update the phase-spec before
 continuing. Do not let code and spec diverge silently.
@@ -293,10 +341,11 @@ Update the feature artifacts:
 
 The bounded context's `rules.md` / `behavior.md` / `events.md` and the
 feature directory move to `completed/` remain `/dflow:finish-feature`
-responsibilities. Do not sync BC-level current state or archive the whole
-feature from `/dflow:new-phase`.
+responsibilities; Step 2 records into `analysis.md` directly, at whichever of
+its two paths the entry belongs to. Do not sync any other BC-level current
+state or archive the whole feature from `/dflow:new-phase`.
 
 After completion, summarize for the developer:
 > "Phase {N+1} is implemented and marked completed. `_index.md` is refreshed.
-> If another slice is needed, run `/dflow:new-phase`; if the feature is done,
-> run `/dflow:finish-feature`."
+> If another slice is needed, run `/dflow:new-phase`; if there is no further
+> phase, run `/dflow:finish-feature` to close the feature out."

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

@@ -37,20 +37,42 @@ touches and read them all.
       `/dflow:finish-feature` time)
 - [ ] Only then proceed to the code-review sections below
 
-If the PR has no spec or no `_index.md`:
+If the PR records its change in neither a spec nor an `_index.md` row (a T3
+inline row is such a record, and a host that carries one needs no spec), first
+check whether it only records existing behaviour or a decision in Domain
+documents, without changing output. That PR is observation-only and wants no
+host: answer it with the reply under "If the spec is missing or incomplete" at
+the end of Spec Compliance, not with the one below. For any other PR with no
+such record:
 ```
 "I don't see a feature directory or _index.md for this PR. Before I
-review the code, can you point me to it, or run /dflow:new-feature
-(or /dflow:bug-fix for a small fix) to create the feature directory
-and at least a lightweight spec? SDD relies on the spec being the
-review anchor."
+review the code, can you point me to the host feature? SDD relies on
+the recorded change being the review anchor.
+
+If this change belongs to a feature that already exists, run
+/dflow:modify-existing or /dflow:bug-fix against it — the cascade
+decides what gets recorded (a T2 lands a lightweight spec; a T3 lands
+one inline row in that feature's _index.md and no spec file). If it is
+genuinely new work, run /dflow:new-feature.
+
+If no feature exists to host it at all, that is the standalone case and
+it has a defined route: /dflow:modify-existing opens a minimal
+(zero-phase) host for it — Step 1.7, or Step 1.6's minimal variant when
+the change is a follow-up on a completed feature. Send it there rather
+than inventing a home by hand."
 ```
 
 ## Spec Compliance
 
 Per-feature checks:
 - [ ] **Feature directory exists** with `_index.md` + at least one
-      phase-spec (or one lightweight-spec for a T2-only feature)
+      phase-spec (or one lightweight-spec for a T2-only feature).
+      **Exception — a host whose whole record is inline.** A **T3-only**
+      minimal host has no spec file by design: a T3 never produces one.
+      What it must have instead is at least one `_index.md` Lightweight
+      Changes row. Check for that, and do **not** ask the author to add a
+      spec to satisfy this line — that manufactures the artifact the tier
+      forbids and the flow refuses to write.
 - [ ] **`_index.md` Current BR Snapshot is up to date** — reflects
       the cumulative effect of all phase-specs / lightweight-specs in
       the directory
@@ -58,7 +80,9 @@ Per-feature checks:
       phase-spec file exists and its `status` matches the row's claim
 - [ ] **For follow-up features**: `_index.md` Metadata has `follow-up-of:
       {原 SPEC-ID}` AND the original feature's `_index.md`
-      Follow-up Tracking row references this feature
+      Follow-up Tracking row references this feature. **`follow-up-of` may
+      be a YAML array** — when it names several originals, *each* of them
+      must carry the row; checking the first one is not checking the field.
 
 Per-phase-spec / lightweight-spec checks (run for **each** spec file the
 PR touches, not just one):
@@ -67,6 +91,23 @@ PR touches, not just one):
       Aggregate state transitions and Domain Events)
 - [ ] All business rules (BR-*) in this spec implemented
 - [ ] Edge cases (EC-*) in this spec handled
+- [ ] **No-BR family evidence** — for a lightweight-spec whose Behavior
+      Delta is a `BR:` / `BR Delta:` none line, check that family's
+      evidence instead: (a) `Output Footprint`; (b) `Contract Delta` +
+      `**Downstream consumers**`; (c) `Operational Rationale` +
+      `**Trace**`; (d) `Performance Delta` + `**SLA / resource
+      context**`; (e) `Governing BR-IDs` + root cause + a regression
+      check; (f) `Change Rationale` with `**Before**` / `**After**` +
+      `**Regression**`. The BR / scenario / Domain items above are
+      **N/A** for these specs — record them as N/A rather than passing
+      them on an empty rule set, and never fabricate a BR or a
+      `behavior.md` anchor to make one pass. Domain documents are not
+      automatically N/A: an added event field still belongs in
+      `events.md`. A spec in the
+      classic BR-delta form, or a bug spec with the older single `BR:`
+      line, is accepted as-is. A change matching more than one family
+      must carry **every** matching family's evidence, not just the one
+      its BR line names
 - [ ] **Delta integrity** (phase 2+ only) — the Delta-from-prior-phases
       section's ADDED / MODIFIED / REMOVED / RENAMED entries actually
       match the diff against the prior phase-spec's BR set
@@ -75,11 +116,272 @@ If the closeout commit is in this PR (`/dflow:finish-feature` was run):
 - [ ] **BC layer sync landed** — `dflow/specs/domain/{context}/rules.md` /
       `behavior.md` / `events.md` / `context-map.md` reflect the
       feature's net effect (compare against `_index.md` Current BR
-      Snapshot)
+      Snapshot). **N/A for a no-BC host** — one whose Goals & Scope
+      declares no bounded context has nothing to sync, and a `{context}`
+      document invented to satisfy this line is a fiction, never a pass.
+      ⚠ **Do not read that as "closeout already blocks it" without qualifying
+      where.** Closeout blocks it in the commits it actually reads — checkpoint
+      1, and only on a **minimal** host, plus the closeout commit on any host.
+      A fiction committed by a **phase-bearing** no-BC host anywhere in between
+      passes every closeout check. That range is the *"A no-BC host committed no
+      BC-scoped Domain material"* item in the delegated block below, and it is
+      yours to run. **N/A for a T3**, which does no Domain work at all.
+      Record the N/A rather than ticking it against an empty comparison — but
+      note `glossary.md` and the tech-debt file belong to no bounded context
+      and stay in a no-BC host's sweep, so this N/A does not reach them.
 - [ ] **Whole feature directory `git mv`'d** to `completed/` — git
       shows `renamed:` (not `deleted:` + `new file:`)
 - [ ] **Integration Summary** was emitted to the conversation (not
       written to a file — it's ephemeral)
+- [ ] **Every Lightweight Changes row now carries a `Commit` hash.**
+      Before closeout an empty cell can be legitimate: on a **hosted** row
+      the cell is filled by the host's *next* commit, and closeout is
+      allowed to be that commit. (A **minimal** host is stricter — its rows
+      are written before checkpoint 1, and closeout already refuses an empty
+      cell there.) After closeout there is no next commit, so an empty cell
+      will never be filled. That is why closeout does not assert this for a
+      phase-bearing host, and why it is checkable here.
+      ⚠ **A placeholder is not a hash.** `{hash}`, `{pending}`, `（待 commit）` —
+      anything that is not a resolvable commit — counts as **unfilled**, not as
+      carrying one. It is the harder case to catch precisely because the cell is
+      **non-empty**: every rule downstream is written against empty / non-empty,
+      so a placeholder reads as filled to all of them. Resolve each value
+      (`git cat-file -t {value}`) rather than checking the cell is populated.
+
+**Delegated to review by `finish-feature-flow.md`.** Closeout states at each
+of these sites that it does *not* prove them. They are not optional extras:
+skip one and the boundary is a hole rather than a division of labour.
+
+- [ ] **Whole history — no stray host-open commit.** Closeout validates the
+      hashes the record names and cannot see the rest of the branch. List
+      this branch's commits that touch the host directory:
+      `git log --oneline {base}..HEAD -- 'dflow/specs/features/active/{SPEC-ID}-{slug}/' 'dflow/specs/features/completed/{SPEC-ID}-{slug}/'`
+      For a **minimal (zero-phase) host** there must be exactly two —
+      checkpoint 1 and closeout. A third, typically a host opened in its own
+      commit before the work landed, breaks the two-commit lifecycle while
+      every closeout check still passes, because those read only the hashes
+      the record points at. A third that comes **after** checkpoint 1 and
+      changes only the host's record text — no implementation path, no new
+      host file — may instead be a correction committed on its own once
+      checkpoint 1 was pushed (`references/finish-feature-record-correction.md`
+      sends the developer that way and asks for it to be named in the PR
+      description). Report which it is: the count still fails, and
+      accepting a correction commit is your call after reading its full
+      diff and the PR description. A correction that touches only a record
+      outside this directory — a follow-up's original `_index.md` — is not in
+      this walk; the PR description is where it is named.
+      **This count applies to a minimal host only**: a
+      phase-bearing feature has no fixed number of host commits, so there is
+      nothing to count there and this item is N/A.
+      This is also where closeout's minimal-host **selector** boundary is
+      settled: that selector reads the host's persisted shape today and
+      cannot know it was opened minimal and *stayed* minimal. The commit walk
+      is what shows that.
+- [ ] **Hotfix identity — confirm it against the cited source** (post-hoc
+      host only). Closeout tests **plausibility only**, and says so: which
+      commit was *the* merged hotfix is not derivable from inside the flow,
+      so the developer asserts it and cites what the claim rests on —
+      `hotfix-identity:` beside `hotfix-branch:` in a **T2**'s
+      lightweight-spec frontmatter, or in the row Description for a **T3**.
+      **Open that source** — PR, incident, or tracker — and confirm that it
+      names **this fix** and the recorded commit: one of the fix's own
+      commits, or the squash commit when the fix was squashed
+      (`references/modify-existing-post-hoc-hotfix.md` item 3). A fix merged
+      without a PR is identified by the source and the base branch's history
+      instead — the hotfix branch's name or the source's number in commit
+      messages.
+      **When the fix landed as a copy** — a rebase merge or a cherry-pick —
+      the recorded commit is that copy, and the source may not name it. Git
+      cannot prove that one commit is a copy of another: ancestry does not
+      follow copies, and patch comparison (`git cherry`, `git patch-id`)
+      cannot tell apart two changes that differ only in whitespace. A
+      `(cherry picked from commit …)` line or a matching subject is a clue,
+      not proof — settle it with the author from the source, and do not
+      report the identity as confirmed from command output alone.
+      Closeout already checked that a citation is *present*; only review can
+      check that it *matches*.
+- [ ] **Hosted `Commit` cell identity — confirm each hash is *that row's own*
+      implementation commit** (phase-bearing host only). `finish-feature-flow.md`
+      Step 4 instruction 1 orders the value ("each row's own implementation
+      hash, never the closeout hash") and its post-commit verification **states
+      that it cannot decide it**: the hash-evidence test is minimal-host-only
+      and lives in `finish-feature-minimal-host.md`, so on a phase-bearing host
+      no closeout check reads the value at all. The presence item above asserts the cell is **non-empty**;
+      this one asserts it is **right**, and the two are not interchangeable.
+      For each Lightweight Changes row, take its `Commit` hash and run
+      `git show --stat {hash}`. **Take the row's declaration if it has one and
+      require the commit to touch it** — a **T2**'s own spec file
+      (`lightweight-*.md` / `BUG-*.md`), a **T3**'s Description implementation
+      paths.
+      **If the row declares nothing, that is by design on a hosted row — with
+      one exception.** A **T2** links to its own spec file on *every* host shape:
+      `finish-feature-flow.md` Step 1 carries two `Tier = T2` checks that no
+      host shape escapes — one of them says so in as many words — and
+      `finish-feature-minimal-host.md`'s phase-bearing exemption note confirms
+      those hosts keep them. A T2 row with
+      no such link is **malformed, not exempt** — find the spec file or flag the
+      row. For a **T3** the absence is the sanctioned state.
+      ⚠ The record then gives you nothing to compare against, and that is
+      deliberate: `finish-feature-minimal-host.md` exempts phase-bearing hosts
+      from its `Commit` cell path check for exactly this reason
+      (`references/flow-rationale-registry.md`, `R-FF-COMMITCELL-02`:
+      "demanding it would reject every hosted T3"), and `templates/_index.md`
+      calls declaring them good
+      practice with no gate behind it. **Do not read "touches nothing declared"
+      as a pass.** What remains checkable is weaker and is worth stating as
+      such: the hash is **not** the closeout commit, is **not** any other row's
+      hash, and is a commit on this host's branch — or on a branch this host
+      recorded a `branch-override` for. Past that, ask the developer which
+      commit carried the row. If identity matters for this change, say so and
+      have the row declare its paths — that is what makes the comparison above
+      available.
+      ⚠ **Do not let tier decide that a declaration must exist.** Tier says what
+      the declaration would have been; the one hosted row required to carry one
+      is a T2, and that requirement lives in Step 1, not here. Keying this check
+      on tier produced three successive versions that each named an input some
+      row was not required to carry.
+      A cell holding the **closeout** hash, or another row's hash, is what this
+      exists to catch: both are non-empty, both pass every closeout check, and
+      neither is what instruction 1 ordered.
+      **N/A for a minimal host** — there `finish-feature-minimal-host.md`'s
+      hash-evidence test already runs (a)–(c) against every row before closeout
+      may proceed.
+- [ ] **A recorded branch override still matches where the closeout landed**
+      (only when the host carries a `branch-override` row). Closeout passes its
+      branch check on any such row naming the branch it ran on, and **states
+      that it cannot decide** whether that override was still the current
+      intent — nothing expires a row once the developer returns to the host's
+      own branch. You can see what closeout cannot: which branch the closeout
+      commit sits on, and whether the work had already been integrated by then.
+      Two cases to reject, both instances of one rule — **the branch this
+      closeout landed on is not where this host's work was finished**: a closeout
+      committed onto the **base** branch *after* the feature branch was merged
+      (that puts the closeout commit outside the review this checklist is part
+      of), and a closeout committed onto a branch an override named earlier but
+      which the work has since **left** — a superseded spike, say. Closeout
+      distinguishes neither, because it accepts any branch this host ever
+      recorded an override for.
+- [ ] **The closeout commit carries only this host's delta.** Closeout's spill
+      check derives its permitted set from Step 4 instruction 2, which defines
+      one for **every** host shape — so there is a permitted-file list to read
+      against on a phase-bearing feature too. What that does not change is what
+      the check proves: it is a **path-level spill check**, so it proves no
+      unpermitted *file* entered the commit, never that the permitted ones carry
+      only this change. An unrelated BR edit inside `rules.md`, or another
+      feature's term in `glossary.md`, passes it untouched. Read each
+      permitted file's diff against the intended delta in the spec / row.
+- [ ] **A follow-up's reverse link was opened, not only closed.** The
+      original's Follow-up Tracking row must have existed as `in-progress`
+      before the flip to `completed` — `absent → in-progress → completed`,
+      never created straight as `completed`. Closeout verifies this for a
+      **minimal** host only, from checkpoint 1's committed blob; a
+      **phase-bearing** follow-up has no single commit required to carry the
+      row, so closeout has nothing equivalent to read and the opening half
+      arrives here unchecked. Confirm it from the branch history
+      (`git log -p {base}..HEAD -- <original feature>/_index.md`), for
+      **each** SPEC-ID in `follow-up-of`.
+- [ ] **A no-BC host committed no BC-scoped Domain material** — **every no-BC
+      host, not only phase-bearing ones.** Closeout inspects only **checkpoint
+      1's** diff on a minimal host, and a phase-bearing host has no single
+      checkpoint to inspect at all. **Neither is a branch-range proof**, and
+      closeout cannot take a range — it needs a base branch and Dflow
+      deliberately does not know yours. **You have it.** Run
+      `git diff --name-status {base}..HEAD -- 'dflow/specs/domain/'` and confirm
+      no BC-scoped Domain document — **the set this track's own no-BC closeout
+      check names**, `context-map.md` included — was **added, modified, deleted
+      or renamed**. A no-BC host is one whose Goals & Scope declares no bounded
+      context, the same identification the BC-layer-sync item above uses.
+      ⚠ **The path filter is deliberately wider than the prohibited set, so read
+      the output before flagging.** `context-map.md` sits at `domain/` top level
+      rather than under `{context}/`, and the filter has to reach up there to
+      catch it — which means it also lists `domain/glossary.md` and
+      `domain/analysis.md`. Both belong to no bounded context and stay
+      legitimate for a no-BC host: **seeing either here is not a finding.** The
+      tech-debt file is outside the filter entirely and never appears.
+
+If the spec is missing or incomplete:
+```
+"I notice this PR doesn't have a matching feature directory / _index.md.
+Can you describe what this change does? If it only records existing
+behaviour or a decision without changing output, it is observation-only
+and wants no host at all — it is captured in the relevant Domain
+document (models.md / rules.md / behavior.md / events.md / analysis.md)
+and stops
+there. Otherwise: if it belongs to a feature we already have, we can
+record it there retroactively — the tier decides what gets written
+(T2: a lightweight spec; T3: one inline _index.md row). If it's
+genuinely new work, it wants /dflow:new-feature. If
+there's no feature it could belong to, that's the standalone case and
+it has a defined route: /dflow:modify-existing opens a minimal
+(zero-phase) host for it — Step 1.7, or Step 1.6's minimal variant when
+it's a follow-up on a completed feature. Let's send it there rather
+than inventing a home by hand."
+```
+
+## Risk-Triggered Modeling Review
+
+Use the spec and diff to identify these risks; do not use a keyword-only scan.
+Only when a signal matches, read the named section in
+`dflow/specs/shared/dflow-workflows/references/ddd-modeling-guide.md`. If no
+signal matches, skip this section's guide lookup, create no artifact, and
+continue with the existing checklist below.
+
+| Risk signal | Read in the modeling guide |
+|---|---|
+| One use case mutates / saves multiple Aggregate roots, or adds a multi-root Unit of Work | Aggregate Design Rules; Domain Services |
+| The diff crosses Bounded Contexts or changes an event payload, handler, or delivery expectation | Domain Events; Event Handling Guidelines |
+| Deadline, retry, out-of-order callback, compensation, business-visible progress, or a claim that local persistence and an external provider / service fact form one atomic outcome | Aggregate Design Rules; Long-Running Processes; failure-path guidance under Event Handling Guidelines |
+| `unique`, `only one active`, or another set-based invariant | Set-Based / Uniqueness Invariants |
+| A Domain Service is added or changed | Domain Services; Long-Running Processes when the flow has state |
+
+For every matched risk, record one disposition in the review:
+
+- **Finding** — identify the violated guarantee at the boundary named by the
+  matched risk, its severity, and merge disposition. For a match involving an
+  external provider / service fact, state that a local transaction cannot make
+  that fact atomic with local state; implementing or repairing a local
+  transaction / Unit of Work alone is not sufficient closure.
+- **Accepted with rationale** — state why the boundary / transaction / service
+  role is sound and when to revisit it. For such an exception, the rationale
+  must already exist or be added to the feature's `aggregate-design.md` Design
+  Decisions; the PR conversation points to that decision and is not its only
+  home. This disposition evaluates the rationale's adequacy, not only its
+  existence: it must explain how it answers every matched risk. For a
+  match involving an external provider / service fact, acknowledge that a local
+  transaction cannot make that fact atomic with local state and explain how the
+  outcome progresses across the boundary, including idempotency and retry /
+  compensation (or a justified equivalent). For a Domain Service match, name
+  the actual domain rule or decision the accepted operation carries; an
+  operation that only orders root calls is Application-layer orchestration and
+  remains a Finding, even when another operation of the same service holds a
+  real rule. If the rationale does not cover the matched risk, use Finding
+  rather than this disposition.
+- **Not applicable** — explain from the spec and diff why the match is only
+  superficial.
+
+Multiple signals for the same design decision may share one disposition, but
+every matched risk must have an auditable disposition. This is not a per-signal
+form.
+
+### Closing a blocking modeling finding
+
+A DDD / domain-correctness blocker must state:
+
+- the code boundary or enforcement needed to restore the guarantee;
+- the existing durable surfaces that must change, as applicable — the spec,
+  `aggregate-design.md`, domain `context-map.md` / `events.md` / `behavior.md`,
+  or `architecture/tech-debt.md`;
+- the automated tests or observable evidence that re-verify the guarantee; and
+- that the unimplemented guarantee must not remain marked `completed` before
+  re-review.
+
+If the review offers defer as an option, it must list the owner, known risk,
+exit criteria, and `architecture/tech-debt.md` landing surface as closure
+conditions. If the team defers the finding, record those items on that surface;
+rationale, a re-evaluation condition, or "future refactor" alone is not
+closure. The reviewer defines the evidence needed to unblock, not the author's
+implementation. Use the existing PR comment / conversation surface; do not
+create a separate review report.
 
 ## Domain Layer Quality
 
@@ -127,6 +429,7 @@ If the closeout commit is in this PR (`/dflow:finish-feature` was run):
       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?
+- [ ] **analysis.md updated** — did this change touch a status transition, an ordered cross-context flow, which roles reach a function, or the way a figure is computed? If so, is the matching entry in `analysis.md` updated? Open one Evidence source it cites and confirm it still says what the entry claims. An entry whose Evidence is `inferred` names what its conclusion was drawn from: confirm instead that the conclusion still follows from it. An entry whose Evidence is `assumed` has no source to open: confirm instead that it says what it rests on and that the question of confirming it is recorded where the Evidence convention at the top of `analysis.md` says, and report it as unverified rather than blocking on it.
 - [ ] **Tests cover invariants** — not just happy path
 
 ## Architecture Score