To avoid that, the code should have ways to override default ports or paths for testing. Then, when testing, ask the OS for a free port or temporary file, and tell the tested code to use that instead of its default. This also allows running tests concurrently.

In what case would talking to an external DB be a problem? Databases support parallel queries.

On your last point, imagine worktree A talks to a database assuming some specific schema. If worktree B changes the schema (let’s day, we remove a column from a table), then worktree A can run into some errors.

all schema changes should always be addition only

Maybe ideally, sure. In practice, in an org with multiple engineering teams: good luck enforcing that rule!

no database user has drop rights - very easily enforced

I just have a handful of ‘hot desks’ I assign different agents to - each desk is numbered, and the numbers inform the ports. So my first agent (001, because it’s an agent after all) uses 8081 for the web server, 3001 for the database, 8001 for the api service, etc - and 002 would use —2 for all the same.

Nice and neat, nobody’s toes get stepped on.

Easy: each worktree starts services on new ports. https://termic.dev goves you ENV variables for this, oir you definee your own custom named variables, and termic assigns ports for each wotktree.

Or if the stack is too complex to start it in parallel, use spotlight to sync changes to main checkout from a single worktree at a time. You can only test one at a time, let's be serios. https://termic.dev/docs/spotlight/