fix(bmad-dev-story): unify review findings handoff between code-review and dev-story

[oneby-wang]

What

Unifies the code review rework loop around the Review Findings section so bmad-dev-story consumes the same findings that bmad-code-review writes. Code review now sends unresolved patch action items back to ready-for-dev instead of in-progress.

Why

Senior Developer Review (AI) and Review Follow-ups (AI) overlapped with Review Findings, creating a fragile CR -> DS handoff. This makes the flow simpler and keeps decision-needed findings in the existing code-review decision path.

How

• Updated bmad-code-review Step 4 to return stories with unresolved review work to ready-for-dev and clarify the next-step prompt.
• Updated bmad-dev-story to detect Review Findings, halt on unresolved [Review][Decision], and prioritize unchecked [Review][Patch] findings.
• Updated the dev-story checklist and allowed story-edit wording to cover Review Findings checkboxes.

Testing

Ran npm run validate:skills and npm run lint:md. Also verified old Senior Developer Review, Review Follow-ups, and [AI-Review] markers no longer remain in bmad-dev-story.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 87aad82f-3f75-4286-b40b-11f0d26ae4c0

📥 Commits

Reviewing files that changed from the base of the PR and between fae7015 and 13fa255.

📒 Files selected for processing (3)

• src/bmm-skills/4-implementation/bmad-code-review/steps/step-04-present.md
• src/bmm-skills/4-implementation/bmad-dev-story/SKILL.md
• src/bmm-skills/4-implementation/bmad-dev-story/checklist.md

---

📝 Walkthrough

Walkthrough

This PR transitions the code-review and dev-story workflow from handling "AI-Review"/"Review Follow-ups (AI)" tasks to an explicit "Review Findings" approach marked with [Review][Patch] and [Review][Decision] tags. It updates Step 4 presentation, status outcomes, allowed modifications, continuation logic, and completion handling across three workflow documents.

Changes

Review Findings Workflow Transition

Layer / File(s)	Summary
Code Review Step 4 Status and Presentation Changes src/bmm-skills/4-implementation/bmad-code-review/steps/step-04-present.md	Step 4 conditional wording for decision-needed findings is adjusted, story status is set to ready-for-dev instead of in-progress when patch findings remain unresolved, and the dev-story continuation option is relabeled from "Start the next story" to "Continue development".
Review Findings Workflow Rules and Continuation src/bmm-skills/4-implementation/bmad-dev-story/SKILL.md, src/bmm-skills/4-implementation/bmad-dev-story/checklist.md	Allowed story-file modifications now explicitly include "Review Findings checkboxes". Review-continuation detection replaces "Senior Developer Review (AI)" logic with explicit checks for unresolved [Review][Decision] (halt) and [Review][Patch] (resume) items. Task-completion handling changes from "Review Follow-ups (AI)" to extracting review details from [Review][Patch] findings, recording them in resolved-tracking lists, writing standardized completion notes, and marking checkboxes when validation gates and tests pass.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• bmad-code-org/BMAD-METHOD#2074: Modifies the same Step 4 {new_status} computation and story status updates based on resolved finding outcomes, plus adjusts next-step workflow presentation.
• bmad-code-org/BMAD-METHOD#2403: Updates bmad-dev-story/SKILL.md status-transition logic around ready-for-dev/in-progress, overlapping with the main PR's status-outcome changes.
• bmad-code-org/BMAD-METHOD#2055: Also modifies Step 4 "Present and Act" flow around patch findings, story status updates, and user interaction options.

Suggested reviewers

• pbean
• cecil-the-coder
• muratkeremozcan

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: unifying the review findings handoff between code-review and dev-story workflows.
Description check	✅ Passed	The description is directly related to the changeset, providing clear context about what changed, why, and how through the What/Why/How framework.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[bmadcode]

why move it back to ready instead of in progress @oneby-wang ?

[oneby-wang]

Hi @bmadcode, thanks for reviewing. I think this is a good topic to discuss.

I moved the story back to ready-for-dev because I believe we're currently missing a dedicated state for stories that require changes after review.

In this case, the review findings require fairly significant updates, so I wanted to make it clear that additional development work is needed before the story is ready for another review cycle.

Keeping the story in in-progress introduces some ambiguity, as there is no clear distinction between:

• a story that is actively being developed, and
• a story that has been reviewed, received change requests, and is awaiting rework.

We could keep such stories in in-progress, but that would likely require additional logic (for example, "in-progress + unresolved review findings") to identify them correctly. Even then, it would still be difficult to distinguish between stories actively being worked on and stories that failed review but have not yet been picked up for rework.

Also, even without introducing a new state, moving the story back to ready-for-dev while retaining the review findings provides a fairly clear signal that the review did not pass and that further development work is required. In my view, that is still more explicit than leaving the story in in-progress.

If we conclude that a dedicated workflow state is needed for this scenario, I think it would be better to address that separately in a dedicated PR.