The targets are user-provided direct dependencies and version tolerances. The lock file contains the exact versions and the full resolution of the graph, which can be rather massive. I wouldn't want to be hand-editing that lock file as then the burden lays on me to manage those dependencies right. It also complicates things quite a lot from a tooling perspective if you let people mess around with what is essentially your serialised dependency graph. Having those things go one way, from Gopkg.toml to Gopgk.lock is much simpler. The first one states intent, the second one is the actual computed result of that intent, at a specific point in time.

Many other package managers do the same thing, bundler and cargo are two of those for example. There's a small entry about it too in dep's FAQ: https://github.com/golang/dep/blob/master/docs/FAQ.md#what-is-the-difference-between-gopkgtoml-the-manifest-and-gopkglock-the-lock