Thanks for opening this. All of the individual PRs in this series have looked good to me, but before we ship this package I want to figure out the api vs locking package situation. Both of them have Lock structs, and api knows how to interact with HTTP stuff. I think locking should own everything up until making a network request.

I'm having the same concerns about my work in the tq package, so I am just about to start 🍐-ing with @technoweenie to figure out where things should go moving forward.

Yeah I knew I needed to have a Lock struct in locking, and I pared it down to the fields I know we need (client-facing), whereas internally there may be more info we need to deal with edge cases - you had a stab at that in the api package but right now I don't know if those will be the exact ones we'll have in the end. Perhaps we just standardise on the locking version for the moment and accept that the api fields will change (and can be implemented via composition or conversion as fits best) once we've fully explored what's needed for the full workflow.