[BUG] Sprint tracker timestamps use US month-day-year, unlike every other date BMad writes

[dannyshisler]

Description

sprint-status.yaml stamps generated and last_updated as MM-DD-YYYY HH:MM. Every other date BMad writes is ISO YYYY-MM-DD — PRD frontmatter, agent-builder session logs and memory files, the eval runner's run stamps, deep recon's date parsing. The sprint tracker is the only place using US ordering.

Outside the US this is more than cosmetic: 08-09-2026 cannot be read without knowing the convention, and it sits in a file people read and hand-edit.

The sharper problem is that the two skills that touch this file disagree about whether an ISO stamp is legal:

• bmad-sprint-planning already tolerates ISO. Its STAMP_FORMATS tuple includes %Y-%m-%d %H:%M, with the comment "Hand-edited files drift toward ISO stamps; accept them rather than silently disabling the staleness check." An ISO-stamped tracker validates cleanly and the staleness check reads it correctly — confirmed on 6.11.0.
• bmad-retrospective does not. It parses --date with strptime(args.date, DATE_FORMAT) alone, so an ISO value is rejected outright; and when --date is omitted it writes datetime.now().strftime(DATE_FORMAT).

So a project can keep ISO stamps and pass every check, right up until its first retrospective, which silently converts them back to US ordering and cannot be told otherwise.

Separately: the installer already writes communication_language and document_output_language into the BMM config (mine are both British English), and nothing in the date handling consults them.

Steps to reproduce

1. npx bmad-method install, then run sprint planning to generate sprint-status.yaml.
2. Hand-edit both stamps to ISO, e.g. generated: "2026-08-24 22:20" and last_updated: "2026-08-26 15:34".
3. Run sprint planning's validate and status subcommands — both succeed, and the staleness check reads the ISO stamps correctly.
4. Run a retrospective for any epic. Either pass --date "2026-08-26 15:34", or omit the flag.

Expected behavior

ISO stamps accepted by both skills, and new stamps written in the same format the rest of BMad uses.

Actual behavior

Passing an ISO date to the retrospective fails before the file is touched:

{"ok": false, "error": "invalid --date '2026-08-26 15:34' (expected \"MM-DD-YYYY HH:MM\")", "restored": true}

Omitting the flag succeeds but rewrites last_updated to 08-26-2026 15:34, undoing the project's own convention with no way to opt out.

Where it lives

Two skills, six files at the current head of main:

File	What it does
src/bmm-skills/plan/bmad-sprint-planning/scripts/sprint_plan.py	DATE_FORMAT = "%m-%d-%Y %H:%M" (the tolerant one)
src/bmm-skills/ship/bmad-retrospective/scripts/sprint_status.py	DATE_FORMAT = "%m-%d-%Y %H:%M", the strict --date parse, and the datetime.now() stamp
src/bmm-skills/plan/bmad-sprint-planning/references/generate-tracking.md	tells the agent {date} must be MM-DD-YYYY HH:MM
src/bmm-skills/plan/bmad-sprint-planning/references/status-view.md	same
src/bmm-skills/ship/bmad-retrospective/references/retro-document.md	documents the strict parse
src/bmm-skills/plan/bmad-sprint-planning/sprint-status-template.yaml (and the retrospective's test fixture copy)	header comment plus example stamps in US ordering

I searched the repository for %m-%d-%Y and MM-DD-YYYY: those are all the occurrences. Nothing else in BMad is affected.

Suggested fix

The smallest change that resolves it is to make the retrospective's script behave like its sibling: parse --date through a tuple of accepted formats rather than a single one, and stamp new values as ISO.

Setting DATE_FORMAT = "%Y-%m-%d %H:%M" in both scripts, while keeping "%m-%d-%Y %H:%M" in the accepted-formats tuple, would make the tracker consistent with the rest of BMad and leave every file already on disk readable. The reference docs, both templates, and the retro-document reference would follow.

Worth knowing before anyone picks this up: the retrospective's test suite hardcodes US-format dates in roughly a dozen places, and the sprint-planning suite in several more, so the change is small but the test churn is not.

Workaround

For anyone hitting this now: sprint planning accepts ISO already, so the tracker can simply be written that way. Only a retrospective run needs the stamps repaired afterwards.

Environment

• Module: BMad Method (BMM) — Core Framework
• BMad version: 6.11.0
• IDE: Claude Code
• OS: macOS