agent couldn't tell which side of a go.sum conflict was newer, so it ran go mod tidy and committed the result blind

TL;DR: Merge go.mod by hand first, then run go mod tidy and actually read the go.sum diff before committing. go.sum conflicts look scary but they are mechanical: once go.mod is merged correctly, tidy regenerates the sums deterministically. The mistake was not running tidy, it was committing the result without checking it.

couldn't tell which side of a go.sum conflict was newer, so it ran go mod tidy and committed the result blind

1. Resolve the go.mod conflict by hand so the module list and versions are correct.

Expected: one coherent go.mod that both sides agree on; this is the step that decides correctness.

1. Run go mod tidy to regenerate go.sum from the merged go.mod.

Expected: conflict markers gone, sums regenerated deterministically from the merged module set.

1. Read the go.sum diff: it should only add or change entries for modules the PR touched.

Expected: no unexpected removals or version shifts hiding in the regenerated file.

1. Build and run the tests before committing.

Expected: the merged module set actually compiles and passes, proving the merge was sound.

Use this when

• A go.sum merge conflict left the agent unsure which side was newer
• go mod tidy was run and committed without reviewing the diff
• go.sum contains conflict markers or was regenerated blindly
• "Committed the result blind" after tidy

Not for this skill when

• go.sum is merely out of sync with no conflict (just tidy and commit)
• The checksum database reports errors on a good download
• The project vendors dependencies and modules.txt is the actual problem

Variant phrasings

• go.sum conflict, which side is newer
• go mod tidy committed blind
• go.sum merge conflict markers
• resolved go.sum by running tidy

Why it happens

go.sum is a generated file, so "just regenerate it" feels right, and usually it is. The failure was skipping verification: a bad go.mod merge produces a tidy go.sum for the wrong module set, and committing blind locks that wrong set in. Tidy was fine; the blind commit was the bug.

Edge cases

• If both sides added the same module at different versions, the go.mod merge decides the winner; review that hunk carefully.
• Tidy can drop sums for modules still needed by tests; the build-and-test step catches that before it ships.
• Never hand-edit go.sum entries; always regenerate from a correct go.mod.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DW74c8sMgI87CDBofxZ3lA