I'm not actually touching Seed's code, but I wanted to work through some ideas that won't be in the prototype, in case they bring in design considerations. The big idea is support for collaboration.
Existing collaboration paradigms I know of: sending patches to other people directly, and coordinating through a central server. In the central server case, the PR logic would probably want to be handled against the central repo, and disallow bringing commits into master on clients. This case would be checked for by the presence of a (default?) remote. For the "sending patches manually" case, the recipient would pull the patches into their own branch and work with them using the normal no-remote flow.
The biggest implication here is that Seed should probably have e.g. the test_green functionality done as a library so it can be called from a webhook. Even if this doesn't prove to be necessary for this specific use case (like if the webhooks available can just use the command-line interface), it still seems like generally a good idea.
I had another idea, but when I tried to describe it, I realized it was just a heavily rephrased version of red-green. Good that I realized that, since it means that supporting the flow is more a question of some way to make convenient tags, or something like that. Like, maybe independent of branches there could be "topic tags" that represent a subset of tags that can be added to, and used as a basis for reds and greens and refactors. That kind of ergonomic thing would be nice, but I don't know ahead of time how necessary it would be, so I think I should try to get by without it and see if that's intolerable.
This was some helpful planning. I'm tired. Good night.