fix(tui,runs): anchor the paused-spec read and confine the replan write on the run's tree

CHANGELOG.md

@@ -161,6 +161,92 @@ breaking changes may land in a minor release.
 
 ### Fixed
 
+- Anchor the TUI's paused-spec read and its `Request replan` write on the tree the run
+  owns. Under isolation both resolved against the main checkout, so the review modals
+  showed that copy of the spec and the replan reset it — reporting success while the run's
+  real spec kept its terminal status, so the next dispatch did not re-plan.
+- Anchor a spec's confinement root on a tree that can actually contain it, so the status
+  flip, the result strip and the baseline re-stamp no longer fall back to an unguarded
+  write, and the re-arm's undo no longer fails outright.
+- Re-anchor spec ownership and the attempt baseline before a discarded worktree is dropped,
+  in both the engine and sweep. A later resume could otherwise probe the main checkout —
+  deleting untracked files the operator already had, or restoring a dead attempt's spec
+  over their own copy.
+- Release spec ownership when a half-built worktree is discarded for a restart, so the
+  replacement mount can bind the spec. The attempt's binding is cleared and the accepted
+  spec returns to its mount-relative spelling; left absolute into the deleted tree it
+  resolved to nothing, and the restarted attempt ran unbound with the repair prompt naming
+  a path that no longer existed.
+- Release a mount's state when a resumed run stops treating it as isolated. Flipping
+  `[scm] isolation` to `none` left the re-anchored spec absolute inside a mount the resume
+  neither reopens nor discards, so the in-place attempt ran unbound; worse, it carried the
+  unit's `baseline_commit`/`baseline_untracked` into an in-place rollback of the main
+  checkout, where a unit's empty untracked snapshot marks every untracked file in the
+  operator's own tree as attempt debris — deleted outright under an auto-recovering cause.
+  The task also stops CLAIMING the mount: `worktree_path` doubles as the record of which
+  tree owns a task's persisted state, so keeping it set made the spec and stories-root
+  helpers answer for the unit while execution used the project checkout. Every
+  non-isolated leg releases, not only the restart: the spec-approval, recorded-result and
+  commit-finalizer continuations each finish their work and return without ever reaching
+  it, so they went on consuming a spec absolutized into the orphan. The directory itself is
+  left standing and the orphan is journaled, and a later flip back to `worktree` now
+  reclaims it — the mount path is deterministic, so the leftover checkout made that second
+  flip fail outright. The shared run branch is spared by the reclaim, keeping the commits
+  earlier units landed on it.
+- Fall back to the project when a task's recorded worktree is gone. Successful integration
+  retires a task without clearing `worktree_path`, so the TUI's story-checkpoint card
+  looked for `stories.yaml` under a deleted mount and lost the committed story's title and
+  description.
+- Tell the resolve session where an unreachable correction has to land. `context.json` now
+  carries `redrive_base_ref` beside the reachability verdict, and the skill spells out that
+  committing from the main checkout cannot include a file in a linked worktree and that the
+  unit's own branch is not what the replacement mount is cut from.
+- Locate the stories folder from the workspace root rather than from the spec's confinement
+  root, so one modal can no longer read its spec from the run's tree and its sentinel from
+  the project.
+- Anchor pause notifications and the `checkpoint-pause` journal on the run's tree, sprint
+  mode included. The dev-session prompt keeps the raw path — that session runs in the mount.
+- Keep the dashboard up on a spec that is absent or undecodable: an absent spec reads as an
+  explicit read failure rather than an empty body, and a bad byte degrades in place instead
+  of losing the document.
+- Refuse `Re-arm & resume` on a spec that could not be read, and report its blocking
+  condition as unknown rather than absent. `Resolve` stays offered — it writes nothing and
+  is what repairs a bad anchor.
+- Report in `context.json` whether an edit to the spec survives to the re-drive, and teach
+  the resolve skill to act on it: under isolation the mount is discarded first, so an edit
+  to a worktree-local spec is lost unless it is committed.
+- Decide whether the re-drive will run isolated from live policy instead of from the mount
+  the escalated attempt recorded. `resolve` builds `context.json` in a separate process
+  before the resume, so editing `[scm] isolation` while a story sat escalated made its
+  advice wrong in opposite directions: switched to `none`, the session was told to commit
+  the correction on the run's pinned branch, which an in-place re-drive never reads;
+  switched to `worktree`, it was told a working-tree edit was safe when the replacement
+  mount reads only committed content. The re-arm's unreachable-write record now says which
+  of the two remedies applies, and the resolve skill spells out that a `HEAD` base means
+  re-applying the correction in the main checkout rather than committing it anywhere. The
+  TUI's re-arm refuses when `policy.toml` cannot be read rather than guessing a mode — a
+  re-arm consumes the escalation, so a wrong guess is unrecoverable.
+- Hold a re-armed SENTINEL until its upstream correction reaches the re-drive. A
+  pre-planning sentinel is cleared by deletion, so that arm dropped the spec and returned
+  before the reachability gate the status-flip arm runs — no gate was ever computed for it.
+  The correction that stops the sentinel recurring is upstream (`SPEC.md` / `stories.yaml`,
+  where the resolve skill sends the agent instead of the sentinel), and an isolated re-drive
+  re-plans from the committed tree of a fresh mount, so an uncommitted upstream edit was
+  invisible and the re-plan minted the same sentinel again, spending the escalation. The
+  re-arm now records `rearm-upstream-write-unreachable`, names the folder and the branch to
+  commit on, and stops the re-arm-and-resume gesture. Narrowed by proof rather than by
+  configuration: the record fires only while the ref the re-drive mounts from does not
+  already hold this checkout's copy of those two files, so a correction already committed
+  there resumes in one gesture as before. An in-place re-drive never records — it reads the
+  main checkout, which is where the resolve session runs.
+- Re-read `[scm] isolation` after the interactive resolve session, before the re-arm.
+  `resolve` loaded policy, then blocked on a human conversation of unbounded length, then
+  keyed the re-arm on that stale answer while the engine it arms re-read policy for itself.
+  Editing isolation while the agent was open therefore split the two readers: `none` to
+  `worktree` re-armed treating the main-checkout correction as reachable, emitted no hold,
+  then mounted a fresh worktree cut from git that could not see it. A change across the
+  session is now reported on stderr.
+
 - **`resume` re-stamps the run's recorded code root** (#716). Resume arms the engine against the
   `repo_root` it re-reads from `_bmad/bmm/config.yaml` but left the `state.json` copy at its launch
   value, so after an edit the engine worked in one tree while the out-of-process re-arm advanced the

docs/FEATURES.md

@@ -78,9 +78,18 @@ See [README.md](../README.md) for the narrative overview and [setup-guide.md](se
   spec and task never silently agree on a stale sha (#640). A re-stamp that does overwrite a differing
   claim records what it replaced, and warns on either leg: the record fires only when the spec claimed
   a baseline the run never recorded, which is the only remaining trace of a divergence the gate can no
-  longer report. `spec_file` is persisted relative to a worktree for an isolated task, so re-arm re-anchors it on
-  that worktree before writing — resolved against the process cwd it named the main checkout's copy
-  of the same story spec, and both writes landed on a file the run never used. A spec re-arm still
+  longer report. `spec_file` is persisted relative to a worktree for an isolated task, so every out-of-process reader
+  re-anchors it on the tree the run owns before reading or writing — resolved against the process cwd it named the main checkout's copy
+  of the same story spec, and both writes landed on a file the run never used. The same
+  anchor backs the dashboard's review modals and their replan write, `context.json`'s
+  `spec_file`, and the paths the pause notifications print. The fields beside it (the sentinel
+  indicator, the stories block) take a DIFFERENT root by design: they resolve against the
+  workspace stories root, not the spec's confinement root, whose out-of-mount arm falls back to
+  the project so a `confine_root` can always contain the path it validates — borrowing that
+  answer for a READ would look the stories folder up in the main checkout while the dev session
+  answered the worktree. Each names the tree the run owns, so a single surface cannot describe
+  two trees. The dev session's own prompt keeps the relative spelling,
+  because that session runs inside the mount. A spec re-arm still
   cannot read has its baseline re-stamp skipped rather than silently no-oped
   (`rearm-baseline-restamp-skipped`), and a status flip that quietly changed nothing is reported
   too (`rearm-spec-flip-skipped`) — though not when the spec was simply already at the target status,
@@ -108,6 +117,15 @@ Result` section. Every other spec keeps warn-and-continue, and the record says w
   escalation on a session that halts blocked. They now stop after the re-arm — the story stays armed,
   `bmad-loop resume <run-id>` picks it up once the fix is committed, and `--resume` does not override
   it, since the record is written on proof rather than suspicion. The advisory warnings do not hold.
+  A pre-planning **sentinel** gets the same treatment on its own artifacts. It is cleared by
+  deletion rather than a status flip, so there is no spec write to measure — but the correction that
+  stops it recurring is upstream (`SPEC.md` / `stories.yaml`, where the resolve skill sends the agent
+  instead of the sentinel), and an isolated re-drive re-plans from the committed tree of a fresh
+  mount. Re-arm now says so (`rearm-upstream-write-unreachable`), names the folder and the branch,
+  and holds the resume the same way. Narrowed on the same principle: it fires only while the branch
+  the re-drive mounts from does not already hold this checkout's copy of those two files, so a
+  correction already committed there resumes in one gesture, and an in-place re-drive never records
+  at all — it reads the main checkout, which is where the resolve session runs.
   All of these warnings reach the TUI's re-arm as well as `resolve`'s — both route every
   kind through one shared table, so neither surface can silently learn a kind the other drops,
   though each still owns where it calls the echo from and the TUI drops the trailing "before

docs/tui-guide.md

@@ -470,7 +470,11 @@ artifacts the engine already wrote.
 
 - **Plan checkpoint** (`spec_checkpoint`, stories mode) — a read-only viewer of
   the planned `ready-for-dev` spec at its id-keyed path (shown prominently, with a
-  copy-path action). **Approve & resume** resumes straight to implementation;
+  copy-path action). Under worktree isolation the path is anchored on the tree the
+  run owns, not on the directory the dashboard was launched from, so the viewer and
+  the replan write both act on the run's own copy rather than the main checkout's
+  twin. A spec that cannot be read at that path says so explicitly and its actions
+  are disabled — an unreviewable gate is not approvable. **Approve & resume** resumes straight to implementation;
   **Request replan** resets the spec to `draft` and strips its Auto Run Result
   (via the same `devcontract` primitives the engine's repair path uses), then
   resumes so the next dispatch re-plans. Edit the markdown in your own editor — the
@@ -482,13 +486,24 @@ artifacts the engine already wrote.
 - **Escalation** — the escalation view enriched with story context: the story
   entry's title/description (from `stories.yaml`), the blocking condition parsed
   from the spec's `## Auto Run Result`, and a sentinel indicator when the matched
-  spec is a fixed-slug pre-planning-halt sentinel. **Resolve** launches the same
-  interactive agent as `R`; **Re-arm & resume** (offered once the resolve agent has
-  recorded a resolution) re-arms and resumes — deleting a sentinel with a preserved
-  copy for a clean re-dispatch. Both refuse a still-live engine.
+  spec is a fixed-slug pre-planning-halt sentinel. Both of those answer from the
+  tree the run owns: under isolation the spec text and the sentinel live in the
+  unit's mount, and reading either from the launch directory let one modal
+  contradict itself. A spec that cannot be read reports its blocking condition as
+  unknown rather than absent — the two are otherwise indistinguishable — and
+  refuses **Re-arm & resume**, which would flip the spec's frontmatter, strip its
+  result and re-stamp the baseline on evidence nobody could read. **Resolve** stays
+  offered: it neither re-arms nor rewrites the spec — it writes the resolver's
+  `context.json` and starts the repair session, which is what repairs a bad anchor — and
+  gating it would have left `close` as the modal's only action while the `R` binding
+  reached the same agent anyway. **Resolve** launches the same interactive agent as `R`;
+  **Re-arm & resume** (offered once the resolve agent has recorded a resolution)
+  re-arms and resumes — deleting a sentinel with a preserved copy for a clean
+  re-dispatch. Both refuse a still-live engine.
 - **Spec-approval / epic / story gate** — a spec-approval gate reuses the spec viewer
   (view the finalized spec, then **Approve & resume**), so the pre-existing sprint-mode
-  gate inherits the same richer surface. Story-gate and epic-boundary pauses have no
+  gate inherits the same richer surface — including the anchored read and the refusal
+  of **Approve & resume** on a spec that cannot be read. Story-gate and epic-boundary pauses have no
   spec to show — a story gate fires before the story is recorded, an epic boundary has
   no story at all — so they open a compact pause-reason viewer instead: the reason names
   the blocking entries and the remedy, and **Resume** re-picks the story and re-asks the

src/bmad_loop/cli.py

@@ -2917,6 +2917,28 @@ def cmd_resolve(args: argparse.Namespace) -> int:
                 f"no resolution recorded for {story_key} (agent did not write resolution.json)",
                 file=sys.stderr,
             )
+        # `pol` was read BEFORE a session that blocks on a human conversation of
+        # arbitrary length, and everything below keys the re-arm on its isolation mode
+        # while `_resume_paused_run` at the bottom of this function re-reads policy for
+        # the engine. An edit made while the agent was open would therefore re-arm under
+        # the old answer and re-drive under the new one — `none -> worktree` re-arms
+        # treating the main-checkout edit as reachable, emits no hold, and then mounts a
+        # fresh worktree cut from git that cannot see it: the escalation is spent and the
+        # story re-wedges. Re-read so the re-arm and the engine agree, which is also what
+        # lets the reachability gate below fire against the mode actually in force.
+        # Unguarded, exactly like the first load above: nothing has been mutated yet, so
+        # an unreadable policy aborts before the re-arm rather than guessing a mode — and
+        # `resolution.json` is already on disk, so `--no-interactive` resumes the work.
+        isolation_before_session = pol.scm.isolation
+        pol = policy_mod.load(_policy_path(project))
+        if pol.scm.isolation != isolation_before_session:
+            print(
+                f"warning: [scm] isolation changed "
+                f"{isolation_before_session} -> {pol.scm.isolation} during the resolve "
+                "session; re-arming against the new mode (the agent was told where the "
+                "correction had to land under the old one)",
+                file=sys.stderr,
+            )
 
     # resolution.json restore latch: only exists after the session ran, so this
     # arm of the validation cannot be hoisted above it.
@@ -2989,7 +3011,12 @@ def cmd_resolve(args: argparse.Namespace) -> int:
     before_entries = runs.journal_entries_or_none(run_dir)
     hold_resume = False
     try:
-        runs.rearm_escalation(run_dir, story_key, restore_patch=restore_patch)
+        runs.rearm_escalation(
+            run_dir,
+            story_key,
+            restore_patch=restore_patch,
+            isolated_redrive=pol.scm.isolation == "worktree",
+        )
     except runs.RearmError as e:
         print(f"error: {e}", file=sys.stderr)
         return 1