Compose derives its project name from the directory and will hijack a running stack

Extracting a distribution bundle into a directory whose name matches an existing compose project makes every subsequent compose command target THAT project. Running up in a freshly extracted folder recreated the containers of a stack that had been running for a week, and the api then crash-looped on password authentication failed because the surviving pgdata volume was initialised with a different password than the new env file -- postgres only applies POSTGRES_PASSWORD at initdb, so a volume outliving its env can never be re-bootstrapped. Always pass an explicit project flag when bringing up a bundle you did not create the directory for. Two related findings from the same attempt: scaling a service to zero does NOT stop compose resolving and pulling its image, so a missing image still aborts the whole up -- you must name the services you want instead; and the default port may already be bound by an unrelated container, which returns a plausible healthy response from the wrong process.