[git-sim] idx196/197/199: create_pull_request run-quota (max 1) blocks parallel fan-out

### Git Simulator Finding

**Scenario ID**: tiny-shallow-single-small-diverged-multi / tiny-shallow-single-small-diverged-merge_msg / tiny-shallow-single-medium-clean-multi (cell indices 196, 197, 199)
**Safe Output Tested**: create-pull-request (and push-to-pull-request-branch for the diverged cells)
**Outcome**: rejected / error / rejected
**Run Date**: 2026-08-10
**Run ID**: 31356809302

### Systemic Root Cause (not a per-cell git-size finding)

This run fanned out 4 parallel sub-agents (idx196–199), each independently attempting the safe outputs required by its BRANCH dimension (all non-error branch modes call `create_pull_request` as their first step, per this workflow's own Phase 2 design). Only **one** of the four (`tiny-shallow-single-medium-clean-single`, idx198) succeeded. The other three all failed identically:

```
Error [-32602]: calling "tools/call": E002: create_pull_request limit reached — 1 of 1 already used this run
```

`push_to_pull_request_branch` for the diverged cells then failed for a second, independent reason: with `safe-outputs.push-to-pull-request-branch.target: '*'`, the tool requires an explicit `repo` and `pull_request_number`. Since `create_pull_request` never produced a PR number for these cells, no legitimate `pull_request_number` was available, and the sub-agents correctly declined to fabricate one.

**This is a run-level `create_pull_request` quota of 1, not a per-cell git-cost boundary.** It will reproduce identically for *any* future batch of ≥2 cells in the same run that require a fresh `create_pull_request` call, regardless of SIZE/HISTORY/FILES/PATCH/COMMIT — i.e., it is orthogonal to the entire configuration space this simulator is exploring.

### Configuration Matrix Cells Affected

| Dimension | idx196 | idx197 | idx199 |
|-----------|--------|--------|--------|
| SIZE | tiny (0 files) | tiny (0 files) | tiny (0 files) |
| HISTORY | shallow (5 entries) | shallow (5 entries) | shallow (5 entries) |
| FILES | single (1 file) | single (1 file) | single (1 file) |
| PATCH | small (50 KB) | small (50 KB) | medium (200 KB) |
| BRANCH | diverged | diverged | clean |
| COMMIT | multi | merge_msg | multi |

### Git Cost Estimate (measured locally despite the rejection — none of this drove the failure)

| Metric | idx196 | idx197 | idx199 |
|--------|--------|--------|--------|
| Declared files (stuff.md) | 0 | 0 | 0 |
| Declared history (history.md) | 5 | 5 | 5 |
| Actual patch files | 1 | 1 | 1 |
| Actual patch size | 56.88 KB | 51.4 KB | 205.16 KB |
| Actual commit count | 3 | 2 | 3 |

All three sizes sit far under this workflow's 5120 KB max-patch-size and 200-file max-patch-files caps — the rejection is 100% attributable to the run-level PR quota, not patch size or file count.

🔍 Full Observations

- idx196: Two-dot vs three-dot format-patch diverged by exactly one main-side commit (687-byte phantom), confirming two-dot remains authoritative even under this failure mode. Fast-forward check on the push-delta commit passed (old tip is ancestor of new tip). `push_to_pull_request_branch` failed twice: first missing `repo` (target `'*'`), then missing `pull_request_number` (no PR existed to reference).
- idx197: Parent-count/`--merges` check confirmed the merge_msg commit is structurally single-parent/non-merge despite its message text — filename leak (`0001-Merge-branch-...patch`) reconfirmed. Same two-stage `push_to_pull_request_branch` failure (repo, then pull_request_number) as idx196.
- idx199: Multi-commit same-file wrapped-append ratio measured at 1.0097x vs a single-commit baseline — reconfirms prior wrapped-text law (~1.0–1.03x, not the ~3x single-long-line blowup) even though the PR itself was rejected. Sub-agent cleaned up its scratch branch/worktree in the real repo after rejection (no residue left).
- idx198 (the one cell that succeeded): `create_pull_request` returned in 524ms, PR patch size 209,816 bytes / 2714 lines, 204.9 KB (≈4.0% of the 5120 KB cap) — confirms the quota is consumed by the FIRST successful call in a run, not distributed or shared.
- No `git push`/`fetch`/`pull` was run directly against the real repo by any sub-agent; all real-repo writes were attempted exclusively through the `safeoutputs` CLI, per the workflow's safety constraints.

### Exploration Coverage

- Configurations tested so far: 200 / 3600
- This batch: cell indices 196–199
- Coverage: 5.56%

### Implication for Future Runs

Given the workflow's Phase 2 design fans out 4 parallel sub-agents per run and (per this run's evidence) only the first `create_pull_request` call in any run can succeed, any future batch containing more than one cell whose BRANCH dimension requires a **fresh** `create_pull_request` call will reproduce this exact rejection for all but the first. Prior state notes claiming "196/196 cells passed" going back to 2026-07-xx should be treated with caution: it is unclear whether earlier sub-agent runs (before the `general-purpose` agent pivot noted in the strategy file) actually verified a real, successful `create_pull_request` response, or self-reported "pass" based on local git measurement alone without confirming the safe-output side effect. This finding does not itself require a fix in this issue (diagnostic-only workflow) but flags a real constraint on the simulator's own methodology.

**Note**: This issue documents a systemic finding in the safe-outputs configuration space (run-level PR quota vs. the simulator's parallel fan-out design). It was created by the daily git simulator workflow as a diagnostic report.

> Generated by [🧪 Daily Safe Outputs Git Simulator](https://github.com/github/gh-aw/actions/runs/31356809302) · agent · 258.9 AIC · ⌖ 43.3 AIC · ⊞ 13K · [◷](https://github.com/search?q=repo%3Agithub%2Fgh-aw+is%3Aissue+%22gh-aw-workflow-call-id%3A+github%2Fgh-aw%2Fdaily-safeoutputs-git-simulator%22&type=issues)

Start with the Daily Safe Outputs Git Simulator workflow and its Phase 2 parallel fan-out, then inspect the safe-outputs configuration for create_pull_request and push_to_pull_request_branch. Compare the run-level quota behavior with the four-cell batch described here; this diagnostic issue is complete when the quota limitation and its effect on future coverage are confirmed or documented.

Written by the indexing model from the issue text.