security(automation): bound PR iteration fan-out and require human merges

[groupthinking]

Canonical problem

The merged PR iteration loop is operational, but its first observed executions produced concurrent fan-out, duplicate work, a deterministic push failure, and an automation path that can merge to main.

Primary implementation: PR #1821, merged as 82f26125 on 2026-09-09.

Verified evidence

Current source triggers on every opened issue, opened/ready PR, push to main, and two schedules. Selection records an event target but then selects only:

recentFailingRuns[0] || stalePulls[0] || staleIssues[0] || null

Safe outputs currently include:

• push-to-pull-request-branch.target: "*"
• required-title-prefix: "[ai] "
• merge-pull-request for pr-iteration/* branches carrying ready-to-merge

Five distinct generated runs are visible in repository artifacts:

Run	Reported AIC	Visible result
34389224551	247.4	#1838 plus failure #1841; existing PR #1608 rejected because its title lacks [ai]
34389712159	163.0	#1833 after PR creation/rebase failure
34389768878	165.9	#1834 and #1835
34390299480	88.5	#1836 and #1837
34390424650	98.5	#1839

Minimum reported total: 763.3 AIC. These runs created eight issue artifacts (#1833–#1839 and #1841); #1833/#1834/#1836/#1839 describe the same stale-batch problem, while proposed fixes conflict over adding versus removing the stale mode.

The existing skip-if-match marker did not prevent concurrent duplicate selection.

Why this matters

This is the exact “see → act → record → review → repeat” substrate Agent Factory needs, but uncontrolled self-triggering converts deployment speed into repository noise, conflicting work, and usage cost. Allowing an unattended workflow to merge also exceeds the standing approval boundary.

Required hardening

1. Human-only merge: remove merge-pull-request from safe outputs. The loop may prepare a draft and request review, never merge.
2. Bound triggers: replace broad issue/PR triggers with explicit labeled/command dispatch, and coalesce main-push/scheduled runs with one repository-level concurrency group.
3. Atomic problem fingerprint: before model/dependency startup, derive a stable key from workflow/failure signature or canonical issue. If an open receipt/issue/PR owns it, comment once or no-op.
4. Compatible mutation target: push only to automation-owned pr-iteration/* branches. Never make existing human PR progress depend on a title prefix it cannot satisfy.
5. Selection honesty: honor the explicit triggering item when authorized; otherwise select one candidate. Record why all others were skipped.
6. Cost ceiling: select/deduplicate before full Python/npm/Playwright installation; add per-run usage and wall-time ceilings plus a circuit breaker after one failed safe-output mutation.
7. Output discipline: one problem may create at most one canonical issue and one draft PR. A failed PR creation must not create a second competing issue when a canonical item already exists.
8. Evaluation: fail the operational-value evaluation when mutation fails, duplicate artifacts are created, or only a narrative claims progress.

Required tests

• Simultaneous main pushes select one fingerprint once.
• Existing unprefixed PR cannot enter the push path.
• Existing canonical issue/PR produces comment-or-noop, not a duplicate.
• Rebase conflict produces one blocking receipt.
• No-candidate run exits before heavy dependency installation.
• No path can merge to main.
• Two identical failure signatures cause one pause receipt, not two new attempts.

Scope and approval boundary

Draft hardening only. Do not merge, delete generated issues, change billing, run paid providers, or alter production. Preserve the useful code-review skill added by #1684; this issue concerns orchestration controls.

Acceptance artifact

Provide a fixture/replay receipt showing: input events, selected fingerprint, dedupe decision, exact mutation, usage, verification result, and next queued action. Compile workflow changes through gh aw compile; never hand-edit the generated lock file.

[linear-code]

GRV-522

[github-actions]

👋 Thanks for opening this issue! It has been automatically labeled for triage.

[groupthinking]

Evaluation defect confirmed

The evaluation job for run 34389712159 returned:

• operational_value: YES
• bounded_checkpoint: YES
• verified_outcome: YES
• memory_updated: YES
• visualized_status: YES

Yet the same run failed its intended create_pull_request mutation during rebase and emitted issue #1833 as fallback. The grader only asks whether the narrative shows evidence; it does not reconcile the claimed outcome with the safe-output manifest or resulting GitHub state.

Add a deterministic postcondition grader before accepting a run:

1. Resolve the selected fingerprint.
2. Read the safe-output manifest and resulting GitHub artifact.
3. Require exactly the declared mutation, tied to the selected canonical item.
4. Reject if the intended mutation failed, a fallback duplicated an existing item, or the final artifact cannot be fetched.
5. Record claimed_outcome, observed_outcome, and their match result.

This is direct evidence for required-hardening item 8; it is not a model-quality inference.