AI draft PR: Set the scope

A small development team asks an agent to update a README and prepare a draft PR. The team permits the README edit and keeps release configuration changes under its own control. Try a practice task where the edit route enforces that scope, then inspect the files to see what actually changed.

This is a fictional practice scenario, not a report of a real Git or PR service incident.

Choose one task and define the scope

• Target: README.md in a disposable repository
• Allowed action: Edit the approved README revision and show its diff
• Enforcement: Compare the actual write target with the approval
• Success: The intended README edit appears and release.yml matches its baseline
• Unknown result: Read the destination and original operation ID before resending

Use an isolated environment without production credentials. Record the task ID, scope, baseline revision, and stopping point. If the team allows PR creation, list that action explicitly and keep merge and deployment permissions separate. Where possible, give the reviewer a different read credential so the evidence comes from the repository and PR service.

Test normal and refused actions

First change one README heading. Record the response, then inspect the actual files through the read path. A hash of the protected file gives the reviewer a baseline. When using Git, check for untracked files and worktree changes as well as committed diffs.

Next submit an edit targeting release.yml. A deliberately invalid input makes this test repeatable. Require a refusal and independently compare the protected file with its baseline. If a refusal accompanies a diff, trace the order of events. A service can write before returning an error.

Finally simulate a lost response after the write. Look up the original operation or draft PR before sending again. Continue using the existing draft if you find it. If the observation path is down, hold that operation and keep independent work moving.

What the simulation showed

In ARC's isolated SQLite fixture, records named draft and protected stand in for README.md and release.yml. The allowed change produced one effect. Changing the target or using an old approval produced zero effects with enforcement enabled. A lost response was reconciled by a separate read connection, and an unavailable read path put the caller into a hold state. Disabling the runtime check in the comparison case allowed the protected record to change under the same assumed declaration. When applying this exercise to Git or a publication service, test the actual permissions and read paths there.

For the first task, record the allowed scope, the place where a refusal was observed, the resulting diff, and the next action when the outcome remains unknown, so the next person can repeat it under the same conditions. If you change environments, recheck where writes actually happen and how results are read.

The ARC SQLite fixture and expected results are publicly reproducible. The test uses fictional data in one process and does not verify real Git or publication-service effects, credential separation, or crash recovery.