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 · agent · 258.9 AIC · ⌖ 43.3 AIC · ⊞ 13K · ◷
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_requestas 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:push_to_pull_request_branchfor the diverged cells then failed for a second, independent reason: withsafe-outputs.push-to-pull-request-branch.target: '*', the tool requires an explicitrepoandpull_request_number. Sincecreate_pull_requestnever produced a PR number for these cells, no legitimatepull_request_numberwas available, and the sub-agents correctly declined to fabricate one.This is a run-level
create_pull_requestquota 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 freshcreate_pull_requestcall, 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
Git Cost Estimate (measured locally despite the rejection — none of this drove the failure)
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
push_to_pull_request_branchfailed twice: first missingrepo(target'*'), then missingpull_request_number(no PR existed to reference).--mergescheck confirmed the merge_msg commit is structurally single-parent/non-merge despite its message text — filename leak (0001-Merge-branch-...patch) reconfirmed. Same two-stagepush_to_pull_request_branchfailure (repo, then pull_request_number) as idx196.create_pull_requestreturned 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.git push/fetch/pullwas run directly against the real repo by any sub-agent; all real-repo writes were attempted exclusively through thesafeoutputsCLI, per the workflow's safety constraints.Exploration Coverage
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_requestcall in any run can succeed, any future batch containing more than one cell whose BRANCH dimension requires a freshcreate_pull_requestcall 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 thegeneral-purposeagent pivot noted in the strategy file) actually verified a real, successfulcreate_pull_requestresponse, 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.