oversee: planner pre-seeds a look-alike APPROVED FOR EXECUTION checkbox with no provenance

[carlos-alm]

Found while running /oversee 2088 (the run that produced [Plan] PR #2612).

What happens

The planner agent writes its own "## Approval gate" section, ending in a
- [ ] **APPROVED FOR EXECUTION** checkbox, into the [Plan] PR body it opens.
That checkbox is a look-alike: it carries none of the provenance the real gate has.

Observed on PR #2612 before the skill's gate install ever ran:

• The PR body contains - [ ] **APPROVED FOR EXECUTION**.
• gh pr view 2612 --json body -q .body | grep 'oversee:approval-gate' -> no match.
  The <!-- oversee:approval-gate id=... issue=... planRef=... --> sentinel is absent.
• gh api repos/optave/ops-codegraph-tool/commits/2b8e8b7b8884d93f84378c041213b3879a7bd9b3/status
  -> {"state":"pending","statuses":[]}. No oversee/plan-gate=success status.

Why it matters

.claude/skills/oversee/SKILL.md is explicit that this shape must never exist:

A copied or pre-seeded gate must never become the authorization boundary, so append only
when no sentinel exists

The skill's install refuses duplicate, foreign, or pre-ticked sentinels precisely to stop a
body-authored gate from becoming the authorization boundary. Here the planner produces exactly
that artifact on every run, as a matter of course.

The EXECUTE-side parser is not fooled — it anchors on the sentinel
(awk '/oversee:approval-gate/{f=1} f') and then takes the first checkbox after it, and it
verifies the non-forgeable oversee/plan-gate commit status regardless. So this is not an
authorization bypass.

It is a human-facing trap:

1. Before the skill installs the real gate (e.g. any run that dies between the planner and the
   gate install), the PR shows a tickable approval box that authorizes nothing. A reviewer can
   tick it, believe the plan is approved, and only discover otherwise when EXECUTE refuses.
2. After the real gate is installed, the body carries two identical
   - [ ] **APPROVED FOR EXECUTION** checkboxes. The parser reads the correct one; a human
   reading top-to-bottom hits the planner's decoy first.

Likely cause

planPrompt in .claude/workflows/oversee-dispatch.js has no approval-gate template — grep -n "Approval gate\|APPROVED FOR EXECUTION" .claude/workflows/oversee-dispatch.js returns nothing,
and docs/plans/task-plan.template.md has none either. The planner appears to infer it from this
instruction near the end of the prompt:

Do NOT merge anything. A HUMAN reviews this plan and approves it with a checkbox before any
execution — so make it complete and self-explanatory to someone who has not read this prompt.

Describing the checkbox invites the agent to render one helpfully.

Suggested fix

Add an explicit prohibition to planPrompt, e.g.:

Do NOT write an approval gate, an approval checkbox, or any APPROVED FOR EXECUTION line into
the plan doc or the PR body. /oversee installs the gate itself with a provenance sentinel and
a commit status; a body-authored checkbox is a decoy and is rejected.

Optionally, harden the skill's install step to detect a sentinel-less APPROVED FOR EXECUTION
line already present in the body and strip it (or refuse) before appending the real gate, so the
two-identical-checkboxes state cannot arise.