Raise the language version. Updates the go directive so modernizers can use features from that release.
Preview. Prints the modernizer changes as a diff without writing files.
Apply. Rewrites every package under the current directory, skipping generated files.
Gate. Static checks plus the full test suite with the race detector.
Commit the output of each step separately. Because the tool is deterministic, a reviewer can rerun `go fix` on the parent commit and compare. When the base branch moves, the fix commit can be regenerated rather than rebased by hand.
## Where Go modernization with go fix stops
Modernizers update idioms within the language and standard library. Most migration effort sits elsewhere.
Dependency upgrades come first. `go get -u ./...` raises dependencies to their latest minor and patch versions, but a new major version is a different module path, such as `/v2`. Moving to it means changing imports and adapting to whatever API the maintainers changed. Deprecated functions in third-party packages rarely carry an inline directive yet, so their callers need manual edits.
Behavior is the second boundary. The Go team excluded a modernizer that rewrote `append([]string{}, s...)` to `slices.Clone(s)` from the `go fix` suite after finding that `Clone` returns nil for an empty slice, a difference that can break callers in rare cases. An agent writing the same rewrite by hand would face the same trap. Every change, mechanical or not, goes through the build and the tests.
Generated code is the third. Because `go fix` discards edits to generated files, code produced by `stringer`, protocol buffer plugins, or mock generators keeps its old idioms until the generator changes. The Droid updates the generator version or its templates, reruns `go generate`, and commits the regenerated output as its own tool commit. Hand edits to generated files would disappear on the next generation run.
This residue is the Droid's work. It reads compiler errors and test failures after each tool commit, updates import paths and call sites for new major versions, and writes the reasoning for each API choice into the pull request. Where a package has thin coverage, it adds table-driven tests against the old code before upgrading, so behavior changes show up as failing cases.
## How Factory runs the go fix loop
Factory is a platform for running a software factory, where Droids take work from a signal to a reviewed pull request. For Go, the loop keeps the toolchain in charge of every change it can make.
Toolchain pass