fix(quick-dev): improve review trail mention in presentation step

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

src/bmm/workflows/bmad-quick-flow/bmad-quick-dev-new-preview/step-05-present.md

@@ -10,8 +10,38 @@
 
 ## INSTRUCTIONS
 
+### Generate Review Trail
+
+Before committing, append a `## Review Trail` section to `{spec_file}` **after the last existing section**. This is a post-implementation artifact — do not modify the Code Map.
+
+Read `{baseline_commit}` from `{spec_file}` frontmatter. Construct the diff of all changes since `{baseline_commit}`. If `{baseline_commit}` is missing or `NO_VCS`, use best-effort analysis of the working tree.
+
+Build the trail as an ordered sequence of **stops** — clickable `path:line` references with brief framing — optimized for a human reviewer reading top-down to understand the change:
+
+1. **Order by concern, not by file.** Group stops by the conceptual concern they address (e.g., "validation logic", "schema change", "UI binding"). A single file may appear under multiple concerns.
+2. **Lead with the entry point** — the single highest-leverage file:line a reviewer should look at first to grasp the design intent.
+3. **Inside each concern**, order stops from most important / architecturally interesting to supporting. Lightly bias toward higher-risk or boundary-crossing stops.
+4. **End with peripherals** — tests, config, types, and other supporting changes come last.
+5. **Every code reference uses `path:line` format** so editors auto-link them.
+6. **Each stop gets one ultra-concise line of framing** (≤15 words) — why this approach was chosen here and what it achieves in the context of the change. No paragraphs.
+
+Format:
+
+```markdown
+## Review Trail
+
+### {Concern Name}
+- `path/to/file.ts:42` — {one-line framing}
+- `path/to/other.ts:17` — {one-line framing}
+
+### {Next Concern}
+- `path/to/file.ts:88` — {one-line framing}
+```
+
+### Commit and Present
+
 1. Change `{spec_file}` status to `done` in the frontmatter.
 2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
-3. Display summary of your work to the user, including the commit hash if one was created. Advise on how to review the changes. Offer to push and/or create a pull request.
+3. Display summary of your work to the user, including the commit hash if one was created. Advise on how to review the changes — mention that `{spec_file}` now contains a Review Trail with clickable `path:line` stops sequenced by concern for easy top-down navigation. Offer to push and/or create a pull request.
 
 Workflow complete.