dflow-sdd-ddd 0.8.0 → 0.9.0

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

@@ -64,6 +64,17 @@ AI must locate the target feature and load its current state:
      left off (its Business Rules and Delta-from-prior-phases sections in
      particular)
 
+4. **Branch gate — ensure you are on this feature's branch (before any commit)**
+
+   This phase's commits must land on the active feature's
+   `feature/{SPEC-ID}-{slug}` branch. If you are not already on it (you
+   identified the feature by name, or are on a base / unrelated branch),
+   switch to the existing branch — or override and record it in the
+   `_index.md` Checkpoint Log. **Never create a new feature branch here:**
+   `new-phase` extends an existing active feature, it does not start one. See
+   `references/git-integration.md` § Commit Checkpoints, Branch Gate & AI
+   Commits.
+
 Share what you found:
 
 > "OK — `{SPEC-ID}-{slug}` has {N} prior phases. The most recent
@@ -158,6 +169,8 @@ Announce to developer:
 > Ready to refresh `_index.md` (add Phase Specs row, regenerate Current BR
 > Snapshot from the Delta)? `/dflow:next` to proceed."
 
+> Commit checkpoint (per `references/git-integration.md` § Commit Checkpoints, Branch Gate & AI Commits): with the Step 1 branch gate satisfied (you are on the feature's branch), offer to commit the phase-spec baseline and record the result in the `_index.md` Checkpoint Log.
+
 Wait for confirmation before entering Step 5.
 
 ## Step 5: Refresh `_index.md`
@@ -227,6 +240,8 @@ Announce to developer:
 > Ready to mark this phase completed and update `_index.md`? `/dflow:next`
 > to proceed."
 
+> Commit checkpoint (per `references/git-integration.md` § Commit Checkpoints, Branch Gate & AI Commits): offer to commit the phase implementation, then record the result in the `_index.md` Checkpoint Log.
+
 Wait for confirmation before entering Step 7.
 
 ## Step 7: Complete the Phase

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

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

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

@@ -72,8 +72,6 @@ Commits must tie back to a SPEC-ID:
 [{SPEC-ID}] {short description}
 
 {optional detailed body}
-
-Co-Authored-By: Claude <noreply@anthropic.com>   ← suggested, not mandatory
 ```
 
 ### Conventional Commits style (recommended, optional)
@@ -170,8 +168,6 @@ Related BR-IDs:
 - REMOVED: (none)
 
 Related SPEC-IDs: {SPEC-ID}{, follow-up SPEC-IDs if any}
-
-Co-Authored-By: Claude <noreply@anthropic.com>
 ```
 
 Example:
@@ -191,8 +187,6 @@ Related BR-IDs:
 - MODIFIED: BR-03
 
 Related SPEC-IDs: SPEC-20260421-001
-
-Co-Authored-By: Claude <noreply@anthropic.com>
 ```
 
 ### 4.2 Rebase + merge (preserve feature commits on `main`)
@@ -281,19 +275,22 @@ Three categories:
 | `git branch` (listing only) |
 | `git rebase` on a private (not-yet-pushed) branch |
 
-### AI commit authorship (suggested, not enforced)
+### AI commit authorship
 
-When an AI assists in producing a commit, appending a `Co-Authored-By`
-line is **suggested** but not mandatory. The canonical form for
-Claude is:
+How AI-made commits are marked is chosen once at `dflow init` and recorded in
+`dflow/specs/shared/_conventions.md` § AI Commit Policy:
 
-```
-Co-Authored-By: Claude <noreply@anthropic.com>
-```
+- `none` — AI commits carry no extra marker.
+- `co-authored-by` — a `Co-Authored-By: dflow-ai <noreply@dflow.local>` trailer
+  (teams may customize the name / email).
+- `prefix` — an `[ai-assisted]` commit-subject prefix.
 
-For other AI assistants, use the vendor-documented author line (or omit
-it). This is a project-level transparency convention, not a Dflow
-requirement.
+This recorded setting is authoritative and the runtime does not re-ask. The AI
+offers commits at lifecycle checkpoints (see `references/git-integration.md`
+§ Commit Checkpoints, Branch Gate & AI Commits) using your Git identity, and you
+can always decline. If your team also wants vendor attribution, appending the
+assistant's documented line (e.g. `Co-Authored-By: Claude
+<noreply@anthropic.com>`) is an independent, optional convention on top.
 
 ---
 

package/templates/brownfield/templates/_index.md

@@ -12,13 +12,14 @@ Template note (for AI):
   This is the **feature-level dashboard** (`_index.md`) for a feature
   directory. Place at `dflow/specs/features/active/{SPEC-ID}-{slug}/_index.md`.
 
-  Six required sections (see below):
+  Seven required sections (see below):
     1. Metadata (YAML front matter above)
     2. Goals & Scope (prose)
     3. Phase Specs (T1 list)
     4. Current BR Snapshot (feature-level cumulative state)
     5. Lightweight Changes (T2 outbound link + T3 inline)
-    6. Resume Pointer
+    6. Checkpoint Log (commit / skip timeline)
+    7. Resume Pointer
 
   Optional section (append at end if applicable):
     - Follow-up Tracking (when this feature has follow-up features derived)
@@ -87,6 +88,23 @@ Template note (for AI):
 | {YYYY-MM-DD} | T2 | bug fix XYZ — 見 [`lightweight-{date}-{slug}.md`](./lightweight-{date}-{slug}.md) | {hash} |
 | {YYYY-MM-DD} | T3 | 按鈕顏色從藍改綠 `[cosmetic]` | {hash} |
 
+<!-- dflow:section checkpoint-log -->
+## Checkpoint Log
+
+> 生命週期 checkpoint 的 commit / skip 時間線（讓三週後回溯不必手動重建）。
+> 每個 checkpoint 無論 commit 或 skip 都記一列。Tier 決定 checkpoint 數：
+> T1 三點（spec 完 / impl 完 / closeout）、T2 兩點（spec+impl 合併 / closeout）、
+> T3 單一 commit。
+>
+> commit hash 只在 commit 實際成功後填入；pre-commit hook reject 或 commit
+> 失敗記 `failed`、不寫假 hash。
+
+| Timestamp | Checkpoint | Result |
+|---|---|---|
+| {YYYY-MM-DD HH:MM} | spec-baseline | committed ({hash}) / skipped / failed |
+| {YYYY-MM-DD HH:MM} | implementation | committed ({hash}) / skipped / failed |
+| {YYYY-MM-DD HH:MM} | closeout | committed ({hash}) / skipped / failed |
+
 ## Resume Pointer
 
 > 一句話：目前進展到哪？下一個動作是什麼？

package/templates/greenfield/references/dflow-feedback-flow.md

@@ -2,7 +2,8 @@
 
 `/dflow:report-dflow-feedback` helps the developer turn a Dflow problem or
 improvement observed during real project work into a high-quality upstream
-feedback draft.
+feedback draft. The draft is rendered **field by field to match the upstream
+GitHub issue form**, so the developer pastes each field with no reformatting.
 
 This flow is **not** a project feature workflow and does not change the
 application being built. It is a standalone governance/support flow for Dflow
@@ -48,13 +49,16 @@ turn it into a PR, or discard it.
 
 ## Step 1: Classify the Feedback
 
-Classify the feedback as one of:
+Classify the feedback as one of the following. Each maps to one upstream issue
+form (see "Upstream Issue Forms" below):
 
-- Bug report
-- Workflow change request
-- Documentation feedback
-- Question / unclear usage
-- Maintainer release/process feedback
+| Classification | Upstream issue form | Title prefix |
+|---|---|---|
+| Bug report | Bug report | `[Bug]: ` |
+| Workflow change request | Workflow change request | `[Workflow]: ` |
+| Documentation feedback | Documentation feedback | `[Docs]: ` |
+| Question / unclear usage | Question | `[Question]: ` |
+| Maintainer release/process feedback | Workflow change request (closest form; the upstream repo disables blank issues) | `[Workflow]: ` |
 
 Capture:
 
@@ -88,92 +92,160 @@ Avoid:
 
 ## Step 3: Redaction Pass
 
-Before writing the issue body section, perform a redaction check and include it
-in the draft:
+Before writing any field content, run a redaction check and use it as your own
+gate. Confirm there are:
 
-```markdown
-## Redaction Checklist
+- No secrets, tokens, credentials, or auth headers
+- No customer, tenant, or private organization names
+- No proprietary business rules beyond a sanitized paraphrase
+- No private repository URLs or internal hostnames
+- No long proprietary source snippets
 
-- [ ] No secrets, tokens, credentials, or auth headers
-- [ ] No customer, tenant, or private organization names
-- [ ] No proprietary business rules beyond sanitized paraphrase
-- [ ] No private repository URLs or internal hostnames
-- [ ] No long proprietary source snippets
-- [ ] Developer reviewed before submission
-```
+The draft ends with a short submitter self-check (Step 5); leave its items
+unchecked unless the developer explicitly confirms them.
+
+## Step 4: Resolve the Target Issue Form
 
-Leave the final "Developer reviewed before submission" unchecked unless the
-developer explicitly confirms it.
+Submit upstream at: **https://github.com/weilung/dflow-sdd-ddd/issues/new/choose**
 
-## Step 4: Write the Feedback Draft
+Resolve the field schema for the chosen form using this priority chain (it
+avoids any network dependency at draft time):
 
-Use this structure:
+1. **Live upstream schema** — if you can read the target repo's
+   `.github/ISSUE_TEMPLATE/*.yml` (for example you are working inside a
+   `dflow-sdd-ddd` checkout), use that file; it is authoritative.
+2. **Bundled field map** — otherwise use the field map in "Upstream Issue
+   Forms" below. It is a snapshot of the upstream forms shipped with Dflow.
+3. **Generic fallback** — only if the feedback matches none of the forms, use
+   Step 6.
 
-```markdown
-# Dflow Feedback Draft: {short-title}
+## Step 5: Render the Draft Field by Field
 
-## Summary
+Write the draft as one block per upstream field, in the form's field order, so
+the developer copies each block straight into the matching field.
 
-{One or two sentences.}
+Per field-type rules:
 
-## Type
+| Field type | How to render |
+|---|---|
+| `input` | One short line inside a fenced block. |
+| `textarea` | Multi-line content inside a fenced block. If the field sets a non-empty `render:` attribute, do **not** add an extra fence (the form already code-blocks it). |
+| `dropdown` | State the **recommended option** plus a one-line reason. If `multiple: true`, list the chosen options. |
+| `checkboxes` | List every option as `- [x]` / `- [ ]`; mark any option whose schema sets `required: true`. |
+| `markdown` | Display-only text in the form — produce **no** field block for it. |
+| upload / attachment | Emit a manual step ("drag the relevant screenshot / log into the issue editor"); do not try to handle the file. |
 
-{Bug report | Workflow change request | Documentation feedback | Question | Maintainer process feedback}
+Always start with a **Title** block: the form's title prefix plus a concise
+one-line summary. GitHub pre-fills the prefix in the title box; the developer
+can paste the full line over it.
 
-## Observed While Using
+Attribute handling: bring `value` / `default` in as starting content; surface
+`placeholder` as a hint; append "(required)" to the block heading when the
+field sets `required: true`.
 
-- Dflow version: {version-or-unknown}
-- Command / flow: {command-or-flow}
-- Track: {Greenfield | Brownfield | both | unknown}
-- Project context: {sanitized generic context}
+**Fence escaping (dynamic).** Wrap each field's content in a backtick fence
+whose length is *(longest backtick run in the content) + 1*, minimum 3. The
+fence is only a local wrapper so the content survives in the draft file — when
+pasting into the issue form, the developer copies the **inner** content, not
+the fence. State this in the draft.
 
-## Affected Dflow Area
+Draft skeleton:
 
-- {CLI | template | scaffolding | skill reference | tutorial | docs | governance}
-- Files or concepts: {sanitized list}
+````markdown
+# {Issue form name} — {short title}
 
-## Problem
+## Where to submit
 
-{What happened, why it is confusing or harmful, and who is affected.}
+https://github.com/weilung/dflow-sdd-ddd/issues/new/choose → choose
+**"{Issue form name}"**. (A GitHub account is all you need; the title is
+auto-prefixed with `{prefix}`.)
 
-## Expected Behavior or Improvement
+## Title
+
+```
+{prefix}{concise one-line summary}
+```
 
-{What Dflow should do or explain instead.}
+## {Field label} (required)
 
-## Evidence
+```
+{field content; copy the inner text only, not this fence}
+```
 
-{Minimal sanitized observations.}
+... one block per field, in form order ...
 
-## Compatibility / Breaking-Change Risk
+## Before you submit (submitter self-check)
 
-{None | low | medium | high}, with reasoning.
+- [ ] Any real file names / customer names / internal project code names to redact?
+- [ ] If you attach screenshots, do they show sensitive content (internal systems, tokens, passwords)?
+- [ ] Is opening a public issue within what your organization allows?
+````
 
-## Suggested GitHub Issue Body
+Keep the draft **submitter-facing only**: no maintainer tracking notes, no
+internal references, no "for your friend / for yourself" audience switches.
 
-{Copy-ready issue body matching the closest issue template.}
+## Upstream Issue Forms (bundled field map)
 
-## Optional PR Plan
+> Snapshot of the `weilung/dflow-sdd-ddd` issue forms. If the live `.yml` is
+> reachable (Step 4 priority 1), prefer it. Resync this map when the upstream
+> forms change.
 
-{Only include if the change is small and concrete. Otherwise write "Not recommended yet; start with an issue."}
+### Bug report — title `[Bug]: `
 
-## Redaction Checklist
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| Dflow version | input | yes | placeholder `0.2.0` |
+| Node.js version | input | yes | from `node --version` |
+| Project track | dropdown | yes | Greenfield / Brownfield / Not sure |
+| Command or workflow | textarea | yes | the command or `/dflow:*` workflow used |
+| Expected behavior | textarea | yes | |
+| Actual behavior | textarea | yes | include relevant output |
+| Reproduction steps | textarea | yes | smallest steps that reproduce |
+| Additional context | textarea | no | screenshots / snippets / environment |
 
-- [ ] No secrets, tokens, credentials, or auth headers
-- [ ] No customer, tenant, or private organization names
-- [ ] No proprietary business rules beyond sanitized paraphrase
-- [ ] No private repository URLs or internal hostnames
-- [ ] No long proprietary source snippets
-- [ ] Developer reviewed before submission
-```
+### Workflow change request — title `[Workflow]: `
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| Problem | textarea | yes | |
+| Proposed change | textarea | yes | |
+| Affected track | dropdown | yes | Greenfield / Brownfield / Both / Not sure |
+| Affected area | checkboxes | no | CLI command / Generated template / Generated scaffolding / Skill workflow guidance / Tutorial or examples / Documentation only |
+| Compatibility risk | textarea | yes | |
+| Alternatives considered | textarea | no | |
+
+### Documentation feedback — title `[Docs]: `
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| Affected page or file | input | yes | placeholder `README.md` |
+| Reader goal | textarea | yes | what you were trying to understand or do |
+| What was confusing? | textarea | yes | the missing, unclear, or misleading part |
+| Suggested improvement | textarea | no | optional wording or structure |
+
+### Question — title `[Question]: `
+
+| Field | Type | Required | Notes |
+|---|---|---|---|
+| Project type | dropdown | yes | New project / Existing project / Not sure |
+| Dflow track you are considering | dropdown | yes | Greenfield / Brownfield / Not sure |
+| What are you trying to do? | textarea | yes | the workflow or decision you need help with |
+| Project context | textarea | no | framework, team workflow, AI agent, constraints |
+
+## Step 6: Generic Fallback
+
+Use this only when the feedback matches none of the forms above. The upstream
+repo disables blank issues, so direct the developer to pick the closest form at
+`https://github.com/weilung/dflow-sdd-ddd/issues/new/choose` and adapt. Emit
+two paste-ready blocks — a `Title` and a `Body` — plus the URL. Do **not** fall
+back to a generic `## Problem` / `## Evidence` Markdown draft.
 
-## Step 5: Present Submission Options
+## Step 7: Present Submission Options
 
-After writing the draft, summarize the options:
+After writing the draft, name the draft file path and whether any submitter
+self-check items remain unchecked, then summarize the options:
 
-- Copy the suggested issue body manually into GitHub.
-- Use the optional PR plan as implementation guidance in a Dflow source
-  checkout.
+- Open the chosen issue form and paste each field block.
 - Discard the draft if it was only a local observation.
 
-Do not submit anything automatically. End by naming the draft file path and
-whether any redaction checklist items remain unchecked.
+Do not submit anything automatically.

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

@@ -11,10 +11,18 @@ state, archives the feature directory, and emits a Git-strategy-neutral
 **Integration Summary** for the developer's PR / merge / push step.
 
 **Important boundaries**:
-- This command **does not auto-merge**. It does not push, does not open a
-  PR, does not run the project's merge strategy. Those decisions stay
-  with the developer / project's Git principles — Dflow keeps merge
-  strategy project-owned.
+- This command **does not auto-merge** and never pushes or opens a PR on its
+  own. Merge strategy follows the team's selected Git policy (`gitflow` /
+  `trunk`, recorded in `dflow/specs/shared/_conventions.md` § Git Policy).
+- Closeout is split into two gates so it works offline: a **Local-closeout
+  gate** (Steps 1–4: validation, status flip, BC sync, archive + an optional
+  commit checkpoint — all doable with no network) and an **Integration / PR
+  gate** (Step 5: push / merge / PR — needs network; the AI only runs
+  `git push` / `gh pr create` when you explicitly ask).
+- At the archive checkpoint the AI may offer to commit using your Git identity;
+  you can always decline. The commit marker mode is read from `_conventions.md`
+  § AI Commit Policy. This replaces Dflow's earlier "the AI never commits"
+  stance — the AI helps at natural checkpoints, you keep the final say.
 - The BC-layer sync in Step 3 **reuses the existing Step 5.3 mechanism**
   from `new-feature-flow` (Step 8.3) and `modify-existing-flow` (Step
   5.3) — it does not introduce a new sync flow. Treat it as "lift Step
@@ -42,8 +50,8 @@ AI runs mechanical checks first. Report `✓` / `✗` for every item; if any
 proceeding (do not flip status, do not archive, do not emit summary).
 
 - [ ] Locate the feature directory at `dflow/specs/features/active/{SPEC-ID}-{slug}/`
-- [ ] `_index.md` exists and parses (YAML front matter intact, six required
-      sections present)
+- [ ] `_index.md` exists and parses (YAML front matter intact, seven required
+      sections present, including the Checkpoint Log)
 - [ ] Every row in `_index.md` Phase Specs table has Status = `completed`
 - [ ] Every phase-spec file referenced in the Phase Specs table exists at
       the path the table claims
@@ -89,7 +97,7 @@ Also update the **Resume Pointer** to reflect closeout:
 
 ```
 **Current Progress**: feature completed ({date}); all phase-specs status = completed.
-**Next Action**: merge / push (per project Git-principles).
+**Next Action**: integration — push / merge / PR per the selected Git policy.
 ```
 
 **→ Transition (step-internal)**: Step 2 complete. Announce "Step 2 complete (status flipped). Entering Step 3: Sync BR Snapshot to BC layer." and continue.
@@ -187,11 +195,34 @@ 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.
-AI **does not commit** — the developer commits in their own preferred
-manner (and the project's Git-principles decide whether one commit or
-several).
 
-**→ Transition (step-internal)**: Step 4 complete. Announce "Step 4 complete (feature archived to completed/). Entering Step 5: Emit Integration Summary." and continue.
+**Closeout commit checkpoint** (completes the offline Local-closeout gate):
+
+```
+✓ Feature archived to completed/ and closeout files staged
+   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.
 
 ## Step 5: Emit Integration Summary (Git-strategy-neutral)
 
@@ -200,10 +231,10 @@ Produce a plain-text summary of what this feature did. The summary is
 developer adapts to whichever merge strategy their project uses
 (merge commit, squash, rebase, fast-forward — Dflow stays neutral).
 
-For projects that adopted the optional Dflow Git-principles scaffolding, the
-applicable `scaffolding/Git-principles-{gitflow|trunk}.md` "Integration
-Commit Message Conventions" section explains how to format the actual commit
-message from this summary.
+The selected Git policy's `Git-principles-{gitflow|trunk}.md` (seeded at init
+under `dflow/specs/shared/`) explains, in its "Integration Commit Message
+Conventions" section, how to format the actual commit / merge message from this
+summary.
 
 Format:
 
@@ -233,10 +264,11 @@ Phase List:
 - phase-2 ({date}): {phase-slug} — {1 line}
 - ...
 
-Next Steps (developer):
-- Per the project's Git-principles, choose a merge strategy (merge commit /
-  squash / rebase / fast-forward) and execute
-- Push to remote / open a PR
+Next Steps (developer) — Integration / PR gate (needs network):
+- Per the selected Git policy (`gitflow` / `trunk` in `_conventions.md`), choose
+  a merge strategy (merge commit / squash / rebase / fast-forward) and execute
+- Push to remote / open a PR — the AI can run `git push` / `gh pr create` for
+  you, but only when you explicitly ask; it never pushes on its own
 ```
 
 Print the summary to the conversation; do not write it to a file (it is
@@ -254,7 +286,9 @@ 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}/`.
-> Stage is set; commit / merge / push at your discretion."
+> 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."
 
 ## Step 6: Reverse-Update Follow-up Tracking (only if follow-up)
 
@@ -267,7 +301,7 @@ Follow-up Tracking table.
 3. Flip Status → `completed`
 
 ```bash
-# AI does the edit; commits stay with the developer
+# The AI makes the edit and may offer to commit it (Y / N), per the AI commit policy
 ```
 
 After the update: