fix: harden /ddaro:go stage inference fallback (0.6.2)

.claude-plugin/marketplace.json

@@ -10,7 +10,7 @@
       "name": "ddaro",
       "source": "./",
       "description": "Worktree-based parallel workflow for Claude Code sessions. 6-tier worktree classification (main / owned / adopted / protected / unmanaged / external), /ddaro:adopt to bring existing worktrees under management, cwd-safe destructive commands (clear/abandon from main only), size-based merge review, crash-recoverable context logs, and plugin-native protective hooks (0.5.0: registered in hooks/hooks.json, active when ddaro is enabled, modes set via /ddaro:config - never written to .claude/settings.json). New in 0.6.0: a lifecycle conductor (/ddaro:spec design-doc scaffold + decision capture, /ddaro:review prism-all + triad fan-out with collated findings, /ddaro:check pre-merge prism + ship-checklist gate) that orchestrates the doc-template/prism-all/triad skills around the worktree cycle. New in 0.6.1: /ddaro:go - one conductor command that reads the worktree's lifecycle stage and auto-runs the next step (spec/review/check remain as manual gears), confirming before the heavy review/check stages. /ddaro:start uses a 6-step setup. /ddaro:abandon accepts adopted via --force. Korean triggers: 따로, 병렬로, 분리해서.",
-      "version": "0.6.1",
+      "version": "0.6.2",
       "homepage": "https://github.com/minwoo-data/ddaro",
       "license": "MIT",
       "author": {

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "ddaro",
-  "version": "0.6.1",
+  "version": "0.6.2",
   "description": "Worktree-based parallel workflow for Claude Code sessions with a lifecycle conductor (new in 0.6.0: /ddaro:spec scaffolds a design doc + captures decisions, /ddaro:review fires prism-all + triad and collates findings, /ddaro:check is a pre-merge prism + ship-checklist gate - pure orchestration over the doc-template/prism-all/triad skills, filling the design->review front half before the existing commit->CI-merge back half; 0.6.1 adds /ddaro:go, a single conductor that reads the worktree's lifecycle stage and runs the next step - spec/review/check stay as the manual gears), plugin-native protective hooks (new in 0.5.0) and dev-cycle orchestration (0.4.0). The seven hooks (main_protection, branch_naming, cross_worktree_check, branch_worktree_match, evidence_check + the two SessionStart reporters) ship in hooks/hooks.json and activate automatically when ddaro is enabled - config-gated and fail-open, so non-ddaro projects see zero noise and nothing is written to .claude/settings.json (run /ddaro:config migrate once to clean up pre-0.5.0 installs). 6-tier classification (main / owned / adopted / protected / unmanaged / external), /ddaro:adopt, cwd-safe destructive commands (clear/abandon from main only). /ddaro:commit opt-in --verify flag (verify.json + CLAUDE.md fallback discovery). /ddaro:merge drives the PR path through CI: state machine, polling, hard-capped fix loop (default 3, configurable), CI_STUCK detection, idempotency guard, confirm gate, sync-main content-diff preview, --force-with-lease invariant. Korean triggers: /ddaro, 따로, 병렬로. English: /ddaro, parallel, isolated.",
   "author": {
     "name": "haroom",

CHANGELOG.md

@@ -6,6 +6,28 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+## [0.6.2] - 2026-06-05
+
+### Fixed
+
+- **`/ddaro:go` stage inference (fallback path) hardened.** When `.ddaro/lifecycle.json` is
+  absent (adopted or pre-0.6.1 worktrees), `/ddaro:go` infers the stage - and two heuristics
+  were too literal, surfaced by dogfooding on a real worktree:
+  - **Review-findings detection** matched only a literal `## Review findings` heading, so a
+    hand-written doc using a numbered heading (`## 14. Review findings (...)`) read as "not
+    reviewed" and would re-fire the 8-agent review on an already-reviewed doc. Now any h2
+    whose text contains "Review findings" (with or without a section number/date) counts as
+    reviewed.
+  - **Implementation detection** used a two-dot `git diff origin/main` (tip vs tip), so a
+    branch merely *behind* origin/main showed origin's newer files as "changes" and falsely
+    inferred `check` on a stale branch with no real work. Now it uses the merge-base diff
+    `git diff --name-only origin/main...HEAD` (three dots) plus working-tree edits, excluding
+    doc/planning paths (`docs/**`, `*.md`, `.planning/**`, `.ddaro/**`).
+  - The conductor now also flags a LOCK-vs-checked-out branch mismatch or a far-behind branch
+    and prefers asking the operator over guessing. Both heuristics only affect the inference
+    fallback; the normal `/ddaro:go`-driven flow records the stage in `lifecycle.json` and
+    never relies on them, and the cost-confirm gate already prevented a silent re-review.
+
 ## [0.6.1] - 2026-06-05
 
 ### Added

skills/ddaro/SKILL.md

@@ -1481,15 +1481,28 @@ the operator types ONE thing instead of recalling spec vs review vs check.
   (`{"stage": "spec|review|implement|check|done", "doc": "<path>", "updated": "<date>"}`) if
   present. If absent (e.g. an adopted worktree, or a pre-0.6.1 one), INFER it - in order:
   1. No design doc found (no `docs/design/<topic>.md`, topic from the LOCK file) -> `spec`.
-  2. Doc exists but has no `## Review findings` section -> `review`.
-  3. Doc reviewed but the only changes are to the doc itself (no code diff vs `origin/main`)
-     -> `implement` (human writes code; nothing to run yet).
-  4. Code changes exist vs `origin/main` (commits ahead or working-tree edits beyond the
-     doc) -> `check`.
-  5. A check already PASSED (recorded stage `done`, or a `## Review findings` + a clean
+  2. Doc exists but has NO review-findings section -> `review`. Match the heading loosely:
+     any `## ` (h2) line whose text contains "Review findings", with or without a leading
+     section number/date - e.g. `## Review findings (2026-06-05 ...)` AND `## 14. Review
+     findings (...)` both count as reviewed. (A literal `^## Review findings` match misses
+     the numbered form that hand-written docs use; that false "needs review" would re-fire
+     the 8-agent review on an already-reviewed doc.)
+  3. Doc reviewed but the branch added NO implementation beyond docs -> `implement` (human
+     writes code; nothing to run yet).
+  4. The branch added real implementation -> `check`. Compute the branch's OWN changes as the
+     merge-base diff `git diff --name-only origin/main...HEAD` (THREE dots) plus any
+     uncommitted working-tree edits, then EXCLUDE doc/planning paths (`docs/**`, `*.md`,
+     `.planning/**`, `.ddaro/**`). Non-empty after exclusion -> `check`; only the doc left ->
+     stay `implement`. Do NOT use a plain two-dot `git diff origin/main` (tip vs tip): a
+     branch merely BEHIND origin/main shows origin's newer files as "changes" and would
+     falsely infer `check` on a stale branch that has no real work of its own.
+  5. A check already PASSED (recorded stage `done`, or a review-findings section + a clean
      prior `/ddaro:check`) -> `done` -> hand off to `/ddaro:commit` + `/ddaro:merge`.
-  Show the operator the detected stage and the evidence ("doc exists, no findings section ->
-  stage=review") so a wrong inference is visible and correctable.
+  Show the operator the detected stage and the evidence ("doc has '## 14. Review findings' +
+  no non-doc files in origin/main...HEAD -> stage=implement") so a wrong inference is visible
+  and correctable. If the LOCK branch and the checked-out branch disagree, or the branch is
+  far behind origin/main, SAY SO - inference is least reliable there, so prefer asking the
+  operator over guessing the stage.
 - **Forced stage:** if `$1` is `spec` / `review` / `check`, run THAT stage's section
   directly (manual override / re-run), skipping detection. Anything else after auto-detect
   is unknown-arg.