WORK-002: work-view get button mutates the LAUNCH tree, not the row's worktree

Now: DONE

Input

Context

2026-07-18, live: in the WORK-001 work view (launched from work/WORK-001), gritzko clicked [get] on the //bro-why row; the get executed against the LAUNCH tree instead — one wrong-tree mutation row, same class as the day's main-tree hijack: launched from the project root it would have re-pointed the MAIN tree.

Evidence: 26718LFvB_ get ///be#43a754a0 appended to work/WORK-001/.be (the launch tree), re-pinning its track ade2448b→43a754a0; work/bro-why/.be UNTOUCHED (last row Jul 13).
No file bytes were rewritten (all mtimes predate the row) — the damage was the track re-pin + phantom status/diff against the older base.
The pager in that tree DOES carry BRO-025: the button minted the three-part invite //bro-why/: get ///be, the click site parses it (SPELL.parseOspell) and calls _actSpell(o.spell, "//bro-why") — yet the mutation still ran in the pager's own tree.
The [diff] button (a U nav spell, diff //KEY) errs on EVERY wt row: no hunks: diff //beagle-ext-tests //: work — the resolved spell has the view's own address (//: work) glued onto the tail, so the diff verb gets a mangled arg line and returns no hunks (_runSpell's no-hunks report).

Goals

An O-invite mutation runs IN the invite's recorded context, full stop: [get] on //bro-why appends to bro-why's wtlog and touches nothing else; a run whose context cannot be anchored refuses loudly (no fallback to cwd/launch tree).

Red-first repro: fixture forest, press [get] on a row whose context ≠ launch tree; assert the row's wt got the get row and the launch tree's .be is byte-identical.
Root-cause where the context is dropped: _actSpell(spell, ctxOverride) → driveSpell(s, ctx) — does driveSpell's ctx only scope ARG resolution (nav) while the verb's TARGET wt stays the process cwd? The BRO-025 spec is chdir/serialize/restore — the recorded-call path — the verb must run AS IF cwd were the context.
Fix in the shared drive path, not per-button.

Constraints

Rulings in force: verbs resolve args via resolve(context,base,rel) — the pager is arg-blind (BE-030 family); //authority is consumed from arg0 ONLY (authorityRepo); context changes ONLY by navigation (BRO-024).
Distinct from the day's OTHER wrong-tree writes: the be/.be hijack rows (26718KcF3v/KhW83) were a poisoned-code cascade (pre-DIS-062 code) — THIS misfire ran current WORK-001 code, so it is a live tip bug in the O-context execution path.
Related: POST-032 (conflict handling on the same landing), the unfiled GET-050 draft (same-pin no-op + wtlog-write-before-checkout atomicity) staged in work/GET-REPOINT.

WIP

Design decisions

TODOs

repro test: pager press on a foreign-context O invite → mutation lands in the CONTEXT wt only; launch tree .be unchanged
[diff] repro + root cause: where _resolveSpell welds the view address (//: work) onto diff //KEY — the U follow path must hand the verb diff //KEY alone
trace driveSpell(s, ctx): what the ctx actually scopes; add the chdir/serialize/restore leg (or context→target-wt plumbing) for mutation verbs
refuse loudly when the O-context anchors no worktree (no cwd fallback — the NAVESCAPE spirit)
recovery note: the stray row in WORK-001/.be (26718LFvB_) — strip or supersede once the landing settles

Blockers and bummers

The WORK-001 landing itself is stalled on POST-032; this bug makes every work-view mutation button unsafe until fixed — buttons should be considered ARMED AND WRONG on any row whose wt ≠ the launch tree.