Sprint board is read from the main repo but advanced in the worktree

[Pawel-N-pl]

Corrected after a closer read of the current code — see the comment below.

The sprint board has a reader/writer split under worktree isolation:

• engine.py:661 (_backlog_hint) and engine.py:725 (_pick_next) load it from
  self.paths.sprint_status — the main repo.
• engine.py:2116 (_post_dev_sync) advances it via self.workspace.paths.sprint_status — the
  worktree.

For a tracked board this is merely surprising: the advance rides the story commit and reaches
main at merge, so scheduling sees a board that lags by one merge.

For a gitignored board it is silent loss — add -A skips the file and
worktree_remove(force) deletes it, so _post_dev_sync's advance never happens at all. Unlike
the deferred-work ledger, I can find no comment or changelog entry stating that the board's write
is meant to squash into the story commit, so I am not sure which behavior is intended here.

A second consequence, independent of gitignore: with max_parallel > 1, worktrees that do carry
a board turn shared orchestrator state into cross-worktree merge conflicts.

Expected

The board is read and written consistently — one location, whichever you consider canonical.

Actual

Read from the main repo, written to the worktree.

Question for maintainers

Is _post_dev_sync's worktree write deliberate (mirroring the ledger's squash-into-the-commit
design), or an oversight given the two reads use self.paths? I have a patch that routes the
write to the main repo and threads a board_path through the verify gate so the check reads the
same board, but I would rather match your intent than guess.

Environment

bmad-loop 0.9.0, claude adapter, Linux (WSL2), worktree isolation on.

[coderabbitai]

🔗 Related PRs

#86 - feat(resolve): intent-gap patch-restore re-drive + inline-review-layer preflight (re-cut) [merged]
#152 - fix(worktree): detach kept worktree so branch_per=run survives a kept failure (#138) [merged]
#182 - fix(worktree): degrade post-merge teardown failures instead of crashing the run (#139) [merged]
#284 - feat: auto-resolve deferred-work entries a story declares (closes #234) [open]
#300 - feat: story-declared deferred-work closure — the advisory contract (#234) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Pawel-N-pl]

Correction: my original description asserted the worktree write was simply a bug. Having read the deferred-work ledger's deliberate squash-into-the-story-commit design (#234), I can no longer tell whether the board's write is meant to follow the same pattern. Rewritten as a question about intent rather than a bug report, with the gitignored-board case — where the write is definitely lost — called out separately.