producer_edit_last_vectors_pin_consumer_wire_request_and_refusals cannot pass in a fork — the pinned vector hardcodes cortexkit/aft while the value under test is derived from the checkout's git origin

[iceteaSA]

gh_shim::tests::producer_edit_last_vectors_pin_consumer_wire_request_and_refusals (new in v0.54.0, added by 6a2b1791, re-pinned by d719ed87) compares a live-canonicalized wire request against a pinned producer vector. The vector hardcodes the repository; the live value is derived from the checkout's git remote. The two agree only when origin happens to be cortexkit/aft.

In a fork it fails deterministically:

assertion `left == right` failed: consumer request drifted from producer shape
  left: … "repository": String("iceteasa/aft") …
 right: … "repository": String("cortexkit/aft") …

Why it is environment-dependent

crates/aft/tests/fixtures/gh_shim/edit-last-vectors-v1.json pins "repository": "cortexkit/aft", while the value under test comes from repository_key_from_origin(&project_root) (gh_shim.rs:466, :1021), which shells out to git to read the origin URL. Any checkout whose origin is not cortexkit/aft produces a different string and fails the comparison.

That includes every fork, and any clone using an SSH remote or a mirror host.

Verification

git remote get-url origin
# https://github.com/<you>/aft.git

grep -o '"repository": *"[^"]*"' crates/aft/tests/fixtures/gh_shim/edit-last-vectors-v1.json | sort -u
# "repository": "cortexkit/aft"

cargo test -p agent-file-tools --lib gh_shim::tests::producer_edit_last_vectors_pin_consumer_wire_request_and_refusals
# FAILED. 0 passed; 1 failed

It fails in isolation, so it is not a contention artifact.

Why this is worth fixing rather than working around

The test's actual subject is the shape of the consumer wire request and the refusal set — that is what "producer edit-last vectors" is pinning, and it is a valuable thing to pin. The repository string is incidental to that subject but is currently load-bearing in the comparison, so a fork sees a red gate for a reason unrelated to what the test is protecting.

It also fails in the direction that trains people to ignore it: a contributor running the suite before opening a PR gets a failure that has nothing to do with their change, and the cheap response is to learn to skip it.

Possible fixes

Any of these keeps the pinned shape intact:

• normalize the repository field out of the comparison (assert its presence and format, not its value), keeping every other field byte-pinned;
• inject the repository via the same test seam that supplies the rest of the fixture, so the canonicalizer reads a fixed value rather than the ambient remote;
• have the test derive the expected repository from repository_key_from_origin as well, so it compares like with like and still catches shape drift.

I would suggest the first — the repository is the one field in that vector whose value is a property of the checkout rather than of the code, and excluding it costs no coverage of the thing the test exists to pin.

Happy to send a patch for whichever shape you prefer.

Environment

• v0.54.0, Linux, cargo 1.98.0
• Reproduced on a fork checkout (origin = a non-cortexkit remote)
• Not tested on macOS or Windows, though nothing in the path looks platform-specific