Separate the Evidence Commit From the OSS Fix Before Model Output Runs

A maintainer declined a parser pull request after the diff rewrote three files and never preserved the original failure. The contributor had pasted a repository link into a coding model, accepted the generated patch, and pushed one squashed commit. Local checks passed on that laptop, yet reviewers could not replay the reported bug from any commit on the branch. The project wanted a failing case stored in history before anyone discussed the shape of the repair.

The scene above is a composite illustration, not a report from this account or a named maintainer. The rejection pattern still points to a missing contribution gate rather than a simple score of model quality. A careful open-source change records the failure in its own commit, then limits what a model may read and where its patch may run. The workflow below uses a red commit, a narrow packet, and a disposable runner, and it still works with no hosted model.

What reviewers can replay

Maintainers usually gain confidence when a failure replays on a clean tree that does not depend on the author's shell profile. The first commit stores the command, the fixture, and a captured non-zero result before production code changes. The second commit may repair the defect, but it should not rewrite, weaken, or delete that recorded evidence. A reviewer can move between those commits and watch the same command change from failing to passing.

This pattern fits a public issue, a license that permits sharing the selected files, and a command that fails for a known reason. It does not require write access on the upstream project, and it does not treat a model suggestion as already correct. Patch text stays untrusted until a clean runner executes it and a human compares the result with the red commit.

Land the evidence commit first

The contributor clones the upstream project, opens a topic branch, and adds only reproduction assets. Those assets may be a focused test, a tiny fixture, or a shell script kept under a clearly named directory. Formatting sweeps, lockfile refreshes, and drive-by refactors remain outside the evidence commit on purpose. If the command cannot fail on a clean upstream checkout, work stops until the fixture is honest.

The shell below is a proposed example, not a transcript from a real repository run:

git clone --depth 1 https://example.invalid/org/cli.git
cd cli
git checkout -b issue-1842-quoted-flag
mkdir -p repro
cat > repro/quoted-flag.sh << 'EOF'
#!/usr/bin/env bash
set -eu
# Proposed stand-in. Point this at the real project binary and fixture.
./bin/cli --config repro/quoted.toml run
EOF
chmod +x repro/quoted-flag.sh
set +e
./repro/quoted-flag.sh > repro/actual.txt 2> repro/stderr.txt
status=$?
set -e
printf 'exit=%s\nstderr_bytes=%s\n' "$status" "$(wc -c < repro/stderr.txt)" > repro/status.txt
git add repro
git commit -m "test: reproduce quoted flag drop from issue 1842"

The status note should record the exit code and the stderr size, not a dump of the local environment. Home-directory paths, access tokens, and internal hostnames do not belong in files that may later leave the laptop. A case that fails only inside one customized shell profile is not ready for a model or a maintainer.

Choose a packet, then choose a runner

A free model can read the reproduction and one suspected function, then propose an edit that leaves the evidence files untouched. That help is optional, and the boundary around execution matters more than the vendor behind the suggestion. Generated patch text should run first on a disposable runner, not beside developer credentials or private clones. A full-tree upload is unnecessary when the evidence commit already names the command and the fixture.

• The reproduction script and fixture may be sent when the license allows those files to be redistributed.
• A short status note may be sent after paths, tokens, and hostnames have been removed from the captured text.
• One suspected function may be sent, while an archive of the whole working tree should stay on the laptop.
• Environment files, keys, cookies, private logs, and unpublished vulnerability detail stay out of the packet.
• Unseen patch text should not run on a laptop that holds SSH keys, release tokens, or private clones.

Decision	Allowed default	Stop if this is false
Evidence is its own commit	Yes	The failure exists only in chat history
Model sees a narrow packet	Yes	The only prompt is a full-tree paste
First execution is disposable	Yes	The only runner holds personal credentials
Reproduction files stay unchanged	Yes	The patch edits the evidence to force green
Human edits the pull-request text	Yes	A model summary would be posted unchanged

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode is relevant only as one way to reach free model access and a free server for this bounded review step. The same checks remain valid in another editor, with another model, or with no hosted service in the loop. No model names, token quotas, hardware sizes, time limits, or permanent terms are stated here, because those details were not verified for this draft.

The operator-supplied claim is limited to free model access for the review note and a free server option for the first patch execution. The contributor still owns redaction, the evidence commit, and the later decision to open a pull request. Readers who skip the product name still have the commit split, the runner sequence, and the rejection rules.

Apply the suggestion away from the laptop

After the evidence commit exists, the contributor may ask for a minimal production change that makes the reproduction return zero. The reply is saved as patch text and is not executed on the laptop that holds SSH keys or browser sessions. A disposable free server, or any other clean virtual machine, receives a fresh clone and that patch file. The runner has no maintainer credentials, no personal tokens, and no extra repositories beyond the public topic branch.

# Proposed sequence for a clean runner. Do not target a production host.
git clone --depth 1 --branch issue-1842-quoted-flag https://example.invalid/you/cli.git
cd cli
git apply --check /tmp/model-fix.patch
git apply /tmp/model-fix.patch
set +e
./repro/quoted-flag.sh
echo "post-patch:$?"
set -e
git diff --exit-code -- repro

Stop conditions

Three observable results are enough to stop the trial before a pull request is opened at all. Each result is a reason to keep the evidence commit and to discard the current suggestion entirely. None of these results should be patched over by sending a larger private context to the model.

• The patch fails git apply --check, so the next request stays narrow instead of adding private files for context.
• The reproduction command still fails, so the suggestion is discarded and the evidence commit remains authoritative.
• A non-empty diff under the reproduction path means the patch mixed repair with evidence and should be rejected.

When the same command passes and the reproduction diff is empty, a second commit may hold only the production change. The branch history then shows the miss first and the attempted repair second, which is easier to review than a squash. A model may draft the pull-request summary from those two diffs, but a human must edit every factual claim. The maintainer should be able to replay both commits without trusting the tool that wrote the second one.

Check the branch shape before upload

Proposed checker

The script below is a proposal for the fix commit, and it has not been executed against a real upstream project here. Path names, branch names, and the reproduction directory must be adapted before anyone relies on the result. A passing shape check still does not replace the reproduction command or the project's own test target.

#!/usr/bin/env bash
# Proposed shape check. Run while HEAD is the fix commit.
set -eu
base="${1:-HEAD~1}"
git diff --exit-code "$base" -- repro
if git diff --quiet "$base" -- . ':!repro'; then
  echo "fix commit has no production change" >&2
  exit 1
fi
if git diff --name-only "$base" | grep -E '(^|/)\.env$|id_rsa|credentials\.json'; then
  echo "sensitive-looking path in the fix diff" >&2
  exit 1
fi
echo "commit shape accepted; still rerun the reproduction command"

Manual replay

The numbered checks below are the human gate between a green runner and a public pull request. These steps remain proposed checks for the contributor, not measured results from an executed upstream trial. A skipped check leaves the branch unready, even when the shape script prints an acceptance line.

1. The contributor checks out the evidence commit on a clean tree and confirms a non-zero status.
2. The contributor checks out the fix commit and confirms a zero status from the same command.
3. The contributor confirms that the reproduction path did not change between the evidence commit and the fix.
4. The contributor runs the repository's own targeted test and records that exact command in the pull request.
5. The contributor searches the diff for home paths, tokens, and private hostnames before any upload.
6. If a model remains in the loop, it may only hint at callers outside the suspected function, and project tests must confirm that hint.

Limits, and who should skip this

This gate suits small, replayable defects in projects that accept external pull requests and can tolerate a failing test beside a fix. It is a poor fit for races that vanish on a clean runner and for failures that require private production data. Security reports that belong in a private disclosure channel should not be turned into a public reproduction commit. A free server is also the wrong place for customer logs, licensed corpora, or any tree the contributor may not upload.

Model assistance stays optional here and is easy to overrate once the reproduction already looks clean. A free model can suggest a narrow edit, yet it cannot certify license fit, maintainer preference, or timing stability. If the failing command cannot be published, sending a richer private log to a hosted model is not an acceptable workaround. The honest alternatives are a purely local fix, a question to the maintainers, or no patch until the fixture is shareable.

Teams that already require a paired regression test can adopt the commit split without subscribing to any hosted service. The disposable runner matters most when the patch text came from a model and has not been read line by line. Contributors who cannot isolate a public fixture should pause rather than widen the packet to force progress.

A single open issue is a better trial than a batch of generated pull requests across unrelated repositories. The contributor can land the evidence commit locally, then use free model access only on the redacted packet and a free server only for the first apply. The resulting pull request should stay small enough that replay, not the drafting tool, carries the review.