[6.12.0] Sprint planning rejects Loop's awaiting-operator, undercounts stories and resets parked status during generation

Problem

With BMAD Method 6.12.0 and BMAD Loop 0.11.1, Loop can legitimately write awaiting-operator to sprint-status.yaml, but the Method sprint-planning script does not recognize it.

Three consequences are reproducible:

1. status excludes parked stories from its story counts and recommends a retrospective with the false reason all stories done.
2. validate reports the Loop status as illegal.
3. Ordinary generate replaces the parked status with backlog in this example, without --fresh or --set. This loses the external-acceptance distinction and makes the story eligible for dispatch again.

The third result was verified by applying generation only to a disposable copy. No live project's board needs to be modified to reproduce this.

Versions and provenance

• BMAD Method: 6.12.0.
• BMAD Loop: 0.11.1, official tag commit bb7cebec4ee4f0fa2783a56ffd0b1b8bc67c4ec5; operator parking enabled.
• Installed sprint_plan.py is byte-identical to the official Method v6.12.0 source.
• Script SHA-256: 4c30f62c261599fc1da3fd319ea6ce5092aa0332221cedee1763a1040627e6bc.
• No vendor patches or custom status aliases.

Minimal reproduction

Run from a project with the installed skill. All generated files below are in a new temporary directory; Loop execution and operator confirmation are not needed.

SPRINT_SCRIPT="$PWD/.agents/skills/bmad-sprint-planning/scripts/sprint_plan.py"
REPRO_DIR="$(mktemp -d)"
cd "$REPRO_DIR"
mkdir stories

cat > sprint-status.yaml <<'YAML'
generated: 09-14-2026 12:00
last_updated: 09-14-2026 12:00
project: status-compatibility-repro
development_status:
  epic-1: in-progress
  1-1-first-story: done
  1-2-second-story: awaiting-operator
  epic-1-retrospective: optional
YAML

cat > epics.md <<'MARKDOWN'
# Status compatibility reproduction
## Epic 1: Example
### Story 1.1: First Story
Completed work.
### Story 1.2: Second Story
Automatable work completed; external operator acceptance remains outstanding.
MARKDOWN

uv run "$SPRINT_SCRIPT" status --status-file sprint-status.yaml
uv run "$SPRINT_SCRIPT" validate --status-file sprint-status.yaml
uv run "$SPRINT_SCRIPT" generate \
  --epic-file epics.md --status-file sprint-status.yaml \
  --stories-dir stories --project status-compatibility-repro \
  --date '09-14-2026 12:00' --dry-run

# Optional: demonstrate the actual write on another disposable file.
cp sprint-status.yaml regenerated.yaml
uv run "$SPRINT_SCRIPT" generate \
  --epic-file epics.md --status-file regenerated.yaml \
  --stories-dir stories --project status-compatibility-repro \
  --date '09-14-2026 12:00'
cat regenerated.yaml

Actual results

Selected fields from status:

{
  "stories": {"done": 1},
  "illegal": [{"key": "1-2-second-story", "status": "awaiting-operator"}],
  "recommendation": {
    "skill": "bmad-retrospective",
    "story_key": null,
    "reason": "all stories done — epic-1-retrospective is still open"
  },
  "all_done": false
}

validate returns valid: false with one illegal-status problem. Both status and validate exit 0; this report does not assume that validate's exit code itself is a bug.

generate --dry-run reports changed: 1, in_sync: false, and:

illegal status 'awaiting-operator' on '1-2-second-story' replaced with 'backlog'

Applied generation leaves 1-1-first-story: done but changes 1-2-second-story: backlog. The input board has two stories; only one is counted by status.

Expected behavior

• Recognize Loop's parked status consistently in status reporting, validation and generation.
• Count the parked story as outstanding acceptance, not completed work.
• Preserve that status during ordinary generation.
• Do not infer complete work from a subset of recognized rows. If an unsupported status remains, report incomplete/unsupported accounting and avoid the false completion rationale; regeneration should preserve it or refuse safely.

Source-level cause and related work

In v6.12.0, STORY_RANK omits awaiting-operator; cmd_status appends it to illegal and skips the row before counting. The recommendation fallback then assumes all stories are done. _merge_status returns the computed default for an unknown existing status. Workflow customization does not provide a status-vocabulary extension.

Loop #335 explicitly describes the upstream Method support needed for this token. A contributor's August 7 comment records that the upstream request had not yet been filed at that point. This issue isolates the Method reporting/preservation defect, rather than the wider Loop parking feature.

Related history: #2553 was fixed with the preserve-existing-progress generator; this reproduction identifies a remaining interoperability case in that generator. No changes to epic aggregate status or automatic acceptance are requested here.