Verified against the Dockerfile's actual COPY instructions -- src/,
bin/, migrations/, public/, docker/, composer.json/lock, and web/'s
own build inputs are the only things either stage touches. Everything
else that COPY . . would otherwise sweep in now excluded: tests/,
phpunit.xml, docker-compose.yml, .env.example, and web/'s own
non-build files (README.md, .env.example, .gitignore, .dockerignore).
web/.dockerignore itself is dead either way -- the build context is
the repo root (docker-compose.yml's `build: .`), not web/, so it was
never actually consulted by anything -- but there's no harm leaving it
for a hypothetical standalone frontend build.
Verified: rebuilt the image, confirmed the excluded paths are genuinely
absent from it, app still serves and 401s correctly unauthenticated,
and PHPUnit (run from the host, unaffected either way) still 88/88.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The Dockerfile is now multi-stage: a Node stage runs `npm run build`, and the
PHP/Apache stage copies the result into public/. Apache + public/.htaccess route
/api* to the Slim front controller, serve real files, and fall back to
index.html for client-side routes.
docker-compose.yml loses the `web` service, its volume, and the source
bind-mount -- the image is the artifact now (rebuild to pick up changes).
Frontend dev moves to `npm run dev` on the host; APP_URL defaults to :8080 since
the one container serves both halves.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PHP 8.3 + Apache image serving public/ on port 8080, with pdo_sqlite and
mbstring built in. The container entrypoint applies migrations as www-data
before starting Apache; the SQLite database and generated JWT signing key
persist in a named "storage" volume. `docker compose up -d` is now the
primary way to run the project without a local PHP toolchain.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
aneurinandClaude Sonnet 5