fix: make the working directory the working directory

[refsz]

Found by reading the Sputnik migration in the consuming project. exec() has always run commands in the project root, while PHP file I/O inside a task resolved against whatever directory the binary was called from. Measured with the released 0.2.1 PHAR, invoked from /tmp with --working-dir pointing elsewhere:

PHP:    file_exists('.sputnik.dist.neon') = false
exec(): sees the file                     = yes

docs/cli.md promised "All paths (config files, task directories, templates) are resolved relative to this directory". True for config, tasks and templates — not for a task's own file access.

The consuming project hit this and worked around it. Its wrapper has to cd before calling the binary, with a comment saying that --working-dir alone would leave relative file I/O resolving against the caller's cwd. Its tasks do exactly that kind of access — is_dir('.ddev'), file_get_contents('dev-ops/ddev/config.yaml'), scandir('.ddev'). So the two halves of one directory notion disagreed, and every consumer had to know it.

The fix

bin/sputnik enters the directory before the Kernel is built.

Not in the Kernel. A library class that changes the process working directory would move the cwd of every test that constructs one — including the regression tests from #36 that assert a directory stays empty. The binary owns the process; the Kernel does not.

Resolved to an absolute path first, which is not cosmetic:

• a relative --working-dir would otherwise be looked up inside itself after the chdir, wd/.sputnik.dist.neon becoming wd/wd/.sputnik.dist.neon
• the container cache key contains this path, so relative and absolute forms used to compile two separate containers for the same project

A missing directory now says which one

Before, it surfaced as a raw PHP warning about a cache directory, quoting a phar:// internal path — complaining about the symptom:

PHP Warning:  mkdir(): Permission denied in phar:///…/sputnik.phar/src/DependencyInjection/ContainerFactory.php
 Error: Could not create cache directory: /gibt/es/nicht/.sputnik/cache

Now:

Working directory does not exist: /does/not/exist

Tests

Three E2E tests against the real binary, each of which failed before the change:

• a task doing file_exists() on a relative path under --working-dir, run from a different cwd, and asserting getcwd() === $ctx->getWorkingDir()
• a relative --working-dir, which is the case the absolute resolution exists for
• the missing-directory message, asserting the word mkdir is absent — the cache was a symptom, not the problem

Verified against the reporting project too: sputnik --working-dir=/home/.../drupal.z list from /tmp finds the config, and so does the relative form from the parent directory — neither needs a cd.

vendor/bin/phpunit                        768 tests, 1318 assertions, OK (3 new)
vendor/bin/phpstan analyse                [OK] No errors
vendor/bin/php-cs-fixer fix --dry-run     0 of 156 files
vendor/bin/rector --dry-run               [OK]
mkdocs build --strict                     clean

Docs: the --working-dir section now states what it does instead of a claim that was half true, and tasks.md says relative paths in a task resolve against the project root.

Their wrapper's cd becomes redundant with this, but it stays harmless — worth telling them once this ships.

🤖 Generated with Claude Code

https://claude.ai/code/session_018CTvnzcNYmFgm2HQcm821A