source-control:babysit-prs: --apply helpers need mechanically-validated wrappers like the merge gate and thread resolver

[kyle-sexton]

The babysit-prs helpers that take --apply perform their mutations inside their own process. A host permission classifier decides on the outer shell command only, so nothing downstream can reconsider the individual operation:

• refresh_pr_branch.py --apply issues PUT repos/{repo}/pulls/{n}/update-branch. No host rule governing gh sees that call.
• prune_babysit_worktrees.py --apply runs git worktree remove. No host rule governing git sees that either.
• manage_babysit_lease.py and manage_feedback_ledger.py write state files.
• request_review.py --apply posts a comment — the one exception, because the comment body arrives in argv and is therefore visible to whatever reads the command line.

The consequence is that a host grant covering these scripts is necessarily a grant of whatever the script does, not of the operation the operator had in mind. Two of this skill's own components already solve exactly this and are the model:

• babysit_merge.py is check-only unless --merge is passed, so the mutating mode is selected by a flag readable from the command text.
• source-control-babysit-resolve-thread enforces bot-only participation and the outdated check in code, and refuses a bulk resolve with no thread pin.

Both make the permitted operation a property the invocation can be checked against. The --apply helpers do not.

Ask

Give each mutating mode a wrapper (or an in-script guard) that mechanically validates the single operation it is permitted, matching the merge gate's and the resolver's shape — so a host grant can name a wrapper whose behavior is bounded rather than a script whose --apply branch is unbounded.

Worth noting that two of the four are already structurally safe by accident of implementation, and locking that in is part of the ask rather than new work:

• refresh_pr_branch.py pins expected_head_sha and validate_current_candidate refuses when headRefOid != expected_head_sha. Server-side and head-pinned, so it cannot force-push or rewrite history.
• prune_babysit_worktrees.py calls git worktree remove without --force and classifies a dirty worktree as keep_dirty, so it cannot discard uncommitted work.

Those are properties of the current implementation with no test asserting them, which is the gap: a future refactor could add --force and nothing would notice.

Context

Found by the Codex reviewer on melodic-software/dotfiles#315, which hardens the host-side autoMode prose that grants these scripts. That PR removed the sentence claiming the nested actions stayed governed by its gh and git entries, because the claim is not checkable. It now records the structural properties above as properties of today's installed code rather than as guarantees, and points at this issue as the real fix.

Related: #843 (plugin bin/ not on the Bash tool PATH, which is why host grants still name raw script paths).

[kyle-sexton]

This was generated by AI during triage.

Verified

Confirmed the helper inventory against plugins/source-control/skills/babysit-prs/scripts/ at this commit — refresh_pr_branch.py, prune_babysit_worktrees.py, manage_babysit_lease.py, manage_feedback_ledger.py, and request_review.py all exist as described, alongside the two components the item names as the model (babysit_merge.py and the source-control-babysit-resolve-thread wrapper, whose in-code refusals are confirmed at babysit_resolve_thread.py:189/193/325/345).

The structural point holds: a host permission classifier sees only the outer shell command, so a grant naming a script with an unbounded --apply branch is a grant of whatever that branch does.

Classification

• Work class: C4 structural — a security-surface contract change across five entry points, defining what a host grant can rely on.
• Priority: medium. Recorded reasoning for not raising it: the item itself establishes that the two riskiest helpers are structurally safe today (refresh_pr_branch.py pins expected_head_sha and uses the server-side update-branch endpoint, so it cannot force-push; prune_babysit_worktrees.py omits --force and classifies dirty worktrees as keep_dirty, so it cannot discard uncommitted work). The gap is the absence of any test asserting those properties against a future refactor — a real durability gap, but latent rather than live. Sibling source-control:babysit-prs: babysit_resolve_thread.py --autonomous does not enforce severity or own-PR conditions its callers rely on #1287 is rated priority: high because its gap is exploitable now.

Per the admission gate, security-surface work routes to the frontier capability tier always; C4 is human-gated and human-merge.

Note for whoever picks this up

The item's own framing — "properties of the current implementation with no test asserting them" — is now directly actionable. PR #1285 (Closes #1265) is open and lands scripts/tests/guard_contract.py, an executable table where each row binds a prose claim to an assertion and fails naming the downstream claim. Locking in the two accidental-safety properties is a pair of rows there, not new scaffolding. Sequence after #1285.

Related and still open: #843 (plugin bin/ not on the Bash tool PATH), which is why host grants still name raw script paths rather than wrappers — relevant to whether the fix is a wrapper or an in-script guard.

[kyle-sexton]

Frontier disposition (drain session)

Ruling: Close as not planned for this drain wave (frontier consensus).

Dual-panel drain ruling: advisory, superseded, folded into a program umbrella, or blocked on a host/design carrier without an actionable in-repo slice this session. Re-open with a concrete acceptance brief if a consumer needs the work.

KEEP set for this wave: standing telemetry; host-physical Class C (#631 family); program umbrellas #530/#531/#532/#535; live design carriers #1500/#1553/#1668/#1695/#1716/#1681/#1718; #1360.