Audit: mutation wiring ground truth

[aksOps]

Question

Why is the shipped TUI read-only in practice? For each mutation domain - card moves (lift/drop/reorder, keyboard and mouse), create/edit editor, ship/delete flows, AI drafting/ADR split, forge import, settings - establish against origin/main: does the code implement it, is it reachable (keybindings bound, mode transitions wired, help discoverable), does it write through the store, and does teatest actually exercise it end-to-end or only its pure functions? Compare against what the closed tickets from map #80 claimed (their PRs: #88-#94 range and #108-#110). Also verify against a real PTY run if achievable. Deliver: per-domain verdict (works / unreachable / broken write / unimplemented), with file:line evidence, as the resolution comment, plus a proposed gap-ticket list with fix/accept/defer dispositions.

Part of #114.

[aksOps]

Resolution: mutation wiring ground truth (origin/main, v1.0.0 era)

Audited the code, cross-checked the closed PRs, and drove the built binary under a real PTY (tmux, 140x35) against a fresh SQLite board. Headline: the read-only report does not reproduce. Every mutation domain is implemented, reachable, and writes through the store when driven.

Per-domain verdicts

Domain	Verdict	Evidence
Moves - keyboard lift/drop	works	internal/tui/model.go:379-385 (space lift), :314-337 (lifted-mode keys), internal/tui/move_store.go:26-69 -> store.UpdateAndMoveTask (internal/store/store.go:1149). PTY: lifted #1 todo->doing, "Dropped Alpha task, Doing, position 1 of 1", DB row confirmed via kb list + sqlite3
Moves - mouse	works	model.go:414-448 (pointer down/move/up), model.go:700-706 (MouseModeCellMotion + OnMouse). PTY: raw SGR click opened detail; SGR press/motion/release dragged #2 todo->doing, DB confirmed
Card editor create + edit	works	model.go:370-378 (n/e), cardeditor/model.go:38-43 Store interface satisfied by *store.Store (AddTask store.go:951, UpdateTaskIfFieldsMatch store.go:1035), ctrl+s save cardeditor/model.go:430. PTY: created #4 "Delta from TUI", renamed #2; both in DB
Ship guard / delete / restore / purge	works	ship_actions.go:153-175 (t/x/r/D). PTY: blocked card dragged to Done raised the guard dialog ("Cancel / Ship anyway"), Ship anyway wrote done; x-kill with reason wrote cancelled; r-restore wrote todo. Auto-ship (ship_actions.go:199-205) and armed purge (:236-243) test-covered, not PTY-driven
AI story draft + ADR split	works (reachable; write path test-verified)	Runner always constructed (run.go:37), wired via configureAI (model.go:96-108), a opens split (model.go:356-358). PTY: ADR overlay opens; editor shows the Draft-with-AI panel. Batch add via adrsplit/model.go:41 AddTask. Live-model run needs a configured endpoint - unverifiable offline
Forge import + drift	works (reachable; write path test-verified)	i (model.go:359-361), backend wired model.go:103-107 via forge.New. PTY: import overlay opens (source "none" with no integrations - correct). Network path unverifiable offline
Settings + integrations	works	run.go:38-40 wires settingsNew, s (model.go:350-354). PTY: pane opens with AI settings + forge integrations sections; settings_test.go:84 runs against a real store.Open

Reachability cross-checks: bare kb on a TTY runs the TUI (dispatch.go:55-59); compile-time assertions var _ taskMoveStore = (*store.Store)(nil) and var _ taskActionStore = (*store.Store)(nil) pass, so no silent type-assertion downgrade to read-only is possible. Bonus: an external CLI write (kb update 3 --blocked) appeared on the running board within ~1s - the data-version watcher works.

Does teatest exercise the real paths?

Not helper-only. Two true terminal-emulation tests (model_test.go:1199 golden; move_model_test.go:494 full lift/drop asserting the store write). The remaining ~220 tui tests drive Model.Update with real key/mouse messages through full routing, several against real SQLite (move_model_test.go:217,470,996, settings_test.go:84). Coverage: tui 95.4%, cardeditor 96.4%, carddetail 96.6%, adrsplit 97.6%, issueimport 97.6%, formview 100% - above the 90% floor.

Claims vs reality

PRs #103, #104, #105, #107, #108, #109, #110 claims all reproduce against origin/main. No diff between description and behavior found. The dogfood report of a read-only TUI is most plausibly a stale binary in PATH (pre-#104 build; kb version distinguishes) or a different data dir/user, not a wiring gap.

What IS broken

1. TestEmptyBoardGolden fails at origin/main in a clean local run: the renderer emits ECH/CUP erase sequences (\x1b[31X\x1b[5;40H) where the golden recorded literal spaces. Environment-dependent renderer output - same behavior class as the flicker/redraw complaints; belongs to the render audit.
2. Space (lift) and Enter (open detail) appear in no footer-help variant (board_view.go:393-414). The primary mutation gesture is undiscoverable from the running UI; the spec's "lift teaches the keys" only helps after you know Space.

Proposed gap tickets (none created)

#	Scope (one line)	Disposition
1	Footer help teaches the move gesture: add "space move" / "enter open" to the help candidates	fix
2	Golden/renderer divergence: normalize or pin ANSI erase-optimization output so TestEmptyBoardGolden is environment-stable (fold into render/flicker fix wave)	fix
3	Dogfood repro protocol: capture kb version + data dir in the planned dogfood pass before filing mutation bugs; re-drive on a fresh v1.0.0 build	fix (process)
4	Scripted PTY coverage for auto-ship and armed purge (currently model-test only)	accept
5	Live end-to-end AI draft / forge import against real credentials	defer