Feature/sprint status reload

[dickymoore]

What

• Add a critical instruction to every Phase 4 workflow that touches docs/sprint-artifacts/sprint-status.yaml.

Why

I was having trouble with agents proceeding based on a stale sprint-status file that another workflow had already updated. This change enforces a guardrail so every workflow reloads the file from disk before reading or writing, preventing inconsistent story/epic state.

How

• Updated these instruction files with the same reminder: dev-story, create-story, story-context, story-ready, story-done, code-review, epic-tech-context, and retrospective.
• The note explicitly tells agents to reload the file (docs/sprint-artifacts/sprint-status.yaml by default) before assuming any status.

Testing

• npm run test (schema + install suite)
• npm run validate:bundles
• npm run validate:schemas
• npm run lint
• npm run format:check

[alexeyv]

This PR has two unrelated changes:

1. "ALWAYS reload {{sprint_status}}" rule.
2. @{bmad_folder}/core/tasks/workflow.xml -> @{bmad_folder}/core/tasks/workflow.xml

Both look like plausibly good changes, dealing with problems that I don't have. To click "Approve" on this PR I need to understand what exactly said problems are and what does it take to experience them firsthand.

[alexeyv]

If I wanted parallel workflows working on the same epic, I'd probably put docs/ into version control and run those workflows in separate worktrees, using git merge to sync them up. Get it into Git and squash the epic into a single commit before pushing if you don't want them in origin.

The "ALWAYS reload {{sprint_status}}" rule probably solves most of the problem in practice, but not ALL of it - you can still have parallel agents clash on writes to other files, or even on writes to this one, if they happen in the same second. Claude Code etc are not designed for this kind of concurrency.

[bmadcode]

@dickymoore still draft FYI - will review once draft is removed