Worktree isolation silently discards ledger writes when the ledger is gitignored

[Pawel-N-pl]

Corrected after a closer read of the current code — the original text of this issue
misdescribed the problem. See the comment below.

Ledger edits are deliberately written inside the story's worktree so they squash into the story
commit — engine.py:1484-1485 and engine.py:1654-1657 both say so explicitly, and the #234
changelog entry confirms it ("an in-repo ledger carries it in the story's own commit, worktree
isolation included"). A ledger outside the repo is handled too, and journaled
(deferred-close-external-ledger).

That leaves a third configuration with no defined behavior: an in-repo but gitignored ledger.

• The write lands in the worktree copy.
• finalize_commit's add -A skips it, because it is ignored.
• worktree_remove(force) deletes it at teardown.

The entry is silently lost. Concretely: a review-budget-followup entry meant to survive to a
later sweep never reaches the sweep, and a bundle's mark_done marks are lost, so the next
sweep cycle re-reads the ids as open and rebuilds work that was already resolved.

Expected

Either the gitignored-ledger case is supported (writes route to the main repo, as the reads at
engine.py:661/:725 already do for the sprint board), or it is rejected at validate time.

Actual

Writes are silently discarded at teardown.

Question for maintainers

Is a gitignored ledger a supported configuration? It is what an operator gets by gitignoring
their bmad output wholesale, which is a natural thing to do. If it is supported, I have a patch
routing these writes to the main repo, but it needs to be conditional on the ledger being
ignored — an unconditional redirect would break the intended squash-into-the-story-commit
behavior for a tracked ledger. Happy to shape it whichever way you prefer.

Environment

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

[coderabbitai]

🔗 Related PRs

#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]
#298 - fix(adapters,engine): pin the read-back to the spec the session owes (#261) [merged]
#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 claimed five sites were simply using the wrong path. That was wrong — I derived it from a grep rather than from the code. The worktree write is deliberate and correct for a tracked in-repo ledger (the edit squashes into the story commit). I have rewritten the issue to describe the case that actually has no defined behavior: an in-repo but gitignored ledger. Apologies for the noise.