//WT/KEY/: verb instead of //WT/: todo KEYSuperseded by BE-053 — the SAME _runSpell weld, root-caused and fixed at the _isNavAddr seam, staged in //BE-053 on base #82ef082f. This page stays as evidence of the second live variant: the arg welded onto a //WT context (//WORK-010/STATUS-008/: todo, red bar), not just the ///KEY/ climb BE-053 pinned. Remaining work (weave onto the moved //WORK/ tip + pin this variant) runs under BE-053.
Reported by gritzko 2026-07-19, live: a WORK-010 [?] click (O-invite //: todo STATUS-008) shows the ticket fine, but the address bar goes RED: //WORK-010/STATUS-008/: todo. Expected //WORK-010/: todo STATUS-008 — context kept (empty O context = current), verb todo, arg STATUS-008.
_runSpell tail — _splitSpell(s) takes the whole arg as the view ADDRESS, _fillAuth grafts the previous //authority onto the bare KEY, then the BRO-024 "click IS navigation" leg this.ctx = this._ctxFrom(this.view.uri) reduces that non-path into the context.todo KEY click (the todo board's own list links) — pre-dates WORK-010, [?] just surfaced it on wt rows; flagged in the WORK-010 worker report.//WT/dir/: verb args, context is $PWD-like, mutated ONLY by navigation. BRO-025 owns the three-part call (context · verb · args); view.call = {verb, spell, context} is already recorded at the weld site.A ticket-link click keeps the pager context; the address bar reads //WT/: todo KEY (BRO-024 prompt form), not red.
_runSpell tail / _ctxFrom leg), not the link mints — the WORK-010 mint is correct and test-proven.[?] mint + view test); the generic todo-link repro must not depend on it.//WT/: todo KEY, context unchanged, no red_ctxFrom; nav targets still reduce