senior-dev: the chat can merge a program branch into the person's main, or edit after a declined proposal, on a new message #1684

What happened

On staging 494939749 (2026-09-30, the v0.5.0 candidate), with the interactive default approvals (allow, shown as YOLO) and a cheap chat model (deepseek/deepseek-v4-flash), the chat changed the person's checkout around a senior-dev request, although senior-dev.md says codeaf "never switches, resets, commits on or merges into your checkout or your branch" and that a declined proposal spawns nothing:

1. In a repo holding a task branch left by an earlier, stopped senior-dev run, a fresh conversation was asked fix slugify with senior-dev. No proposal was made; the model ran git merge --ff-only task/fix-slugify-with-senior-dev-… and answered Done. The fix is merged to main (main moved).
2. In another fresh repo, the model did propose senior-dev; the person declined; the model then fixed the bug itself with edit calls on the person's main checkout.

An explicit prompt (Propose the senior-dev task. Do not merge any branch or edit files in this checkout unless I ask later.) avoided both, so this is the model's judgment, not a code path that always fires. #1682 put a never-merge-unasked rule into the outcome prompt, which governs the turn a program's ending wakes; these were new messages from the person, which that prompt does not cover. Round one of the same pass (dev 461a43fb6) saw the wake-turn merge twice; after #1682 the wake turn offered the merge both times.

senior-dev is new in this release (not in v0.4.1); the chat's general ability to run git merge under YOLO predates it.

Replication

Field (real models, < $0.20). Default approvals, model.talk: deepseek/deepseek-v4-flash. A git repo on main with strutil.py (def slugify(s): return s.lower()) and a failing python3 -m unittest. /senior-dev make slugify lowercase, trim, and join words with '-'; python3 -m unittest must pass, stop it once its branch holds a fix. /new, then fix slugify with senior-dev. Check git log --oneline main before and after. Second road: fresh repo, same message, decline the proposal card, then git status.

Proposal

Prompt wording will not make this reliable on cheap models. An enforced guard at the pre-action seam (taskGitGuard.PreAction in internal/session/taskgit.go is the existing shape) could refuse git merge/rebase/cherry-pick/reset onto the person's current branch from a chat turn unless the person's latest message asks for it, and a declined senior-dev proposal could mark the turn so a direct edit of the same files is refused with a sentence the model can relay. Whether YOLO should cover bringing a branch into the person's branch at all is an owner call.

Acceptance

Through the real chat door with a scripted model that tries git merge --ff-only <program branch> on a new person message that did not ask for a merge: the call is refused, main does not move, and the chat says so; the same scripted model after a declined senior-dev proposal cannot edit the person's files without a new message asking for it.

Found by the 2026-09-30 staging re-check before v0.5.0 (lane 2, F-2.4).