What: make setup (which runs docker/setup.sh) builds images, starts containers, runs migrations, generates the app key, and caches config — but never runs php artisan db:seed. Seeding only happens via the separate make seed target. Both CLAUDE.md and README.md describe or imply that make setup alone leaves a working, loggable-in application.
Where:
docker/setup.sh (full script) — no db:seed step at any point.Makefile — db:seed only exists behind the separate make seed target, not called from the setup target.README.md:68-85 — the "Recommended" Quick Start runs make setup, then immediately documents "Default Login: test@example.com/password" as if it now exists.CLAUDE.md — make setup # first-time setup (builds images, runs migrations, seeds DB) explicitly (and incorrectly) claims seeding happens as part of setup.
Why it matters: A new developer following the documented "Recommended" path cannot actually log in with the credentials the same doc just told them exist, because the database was never seeded. This is a real onboarding-breaking gap between documented and actual behavior (CLAUDE.md's own description of make setup is factually wrong about what the script does).
Suggested fix: Either add docker-compose exec app php artisan db:seed --force to docker/setup.sh so make setup matches its documented behavior, or correct CLAUDE.md/README.md to state that seeding is a separate, manual step (make seed) before the default login works.
Update (2026-07-28): The first suggested fix option above (adding db:seed --force to docker/setup.sh) is now stale as written and needs adjustment before anyone acts on it.
PR #166 (commit 00d76c3) added a production guard to database/seeders/DatabaseSeeder.php: it now calls if (app()->isProduction()) { ...; return; } before creating the default test@example.com user (this was a legitimate fix for a real issue — a Laravel Cloud after_deploy hook was seeding that weak-credential account into real production deployments).
However, docker-compose.yml hardcodes APP_ENV=production on the app, worker, and scheduler services (overriding whatever .env/.env.example sets), so any docker-compose exec app php artisan db:seed run against the stack make setup/docker/setup.sh brings up will see app()->isProduction() === true and silently no-op with just a warning — it will not actually create the login the docs promise. Simply adding the db:seed call to docker/setup.sh as originally suggested would therefore look fixed but still leave a broken onboarding flow.
Fixing this now needs one more piece: either stop hardcoding APP_ENV=production for the local dev compose stack (e.g. let it come from .env as local), or have docker/setup.sh explicitly pass an environment override when seeding (e.g. APP_ENV=local docker-compose exec ...), before the originally suggested db:seed addition will actually work. The other suggested fix (correcting the docs instead of adding seeding) is unaffected by this and remains a valid, simpler option.
What:
make setup(which runsdocker/setup.sh) builds images, starts containers, runs migrations, generates the app key, and caches config — but never runsphp artisan db:seed. Seeding only happens via the separatemake seedtarget. BothCLAUDE.mdandREADME.mddescribe or imply thatmake setupalone leaves a working, loggable-in application.Where:
docker/setup.sh(full script) — nodb:seedstep at any point.Makefile—db:seedonly exists behind the separatemake seedtarget, not called from thesetuptarget.README.md:68-85— the "Recommended" Quick Start runsmake setup, then immediately documents "Default Login: test@example.com/password" as if it now exists.CLAUDE.md—make setup # first-time setup (builds images, runs migrations, seeds DB)explicitly (and incorrectly) claims seeding happens as part of setup.Why it matters: A new developer following the documented "Recommended" path cannot actually log in with the credentials the same doc just told them exist, because the database was never seeded. This is a real onboarding-breaking gap between documented and actual behavior (CLAUDE.md's own description of
make setupis factually wrong about what the script does).Suggested fix: Either add
docker-compose exec app php artisan db:seed --forcetodocker/setup.shsomake setupmatches its documented behavior, or correctCLAUDE.md/README.mdto state that seeding is a separate, manual step (make seed) before the default login works.Update (2026-07-28): The first suggested fix option above (adding
db:seed --forcetodocker/setup.sh) is now stale as written and needs adjustment before anyone acts on it.PR #166 (commit
00d76c3) added a production guard todatabase/seeders/DatabaseSeeder.php: it now callsif (app()->isProduction()) { ...; return; }before creating the defaulttest@example.comuser (this was a legitimate fix for a real issue — a Laravel Cloudafter_deployhook was seeding that weak-credential account into real production deployments).However,
docker-compose.ymlhardcodesAPP_ENV=productionon theapp,worker, andschedulerservices (overriding whatever.env/.env.examplesets), so anydocker-compose exec app php artisan db:seedrun against the stackmake setup/docker/setup.shbrings up will seeapp()->isProduction() === trueand silently no-op with just a warning — it will not actually create the login the docs promise. Simply adding thedb:seedcall todocker/setup.shas originally suggested would therefore look fixed but still leave a broken onboarding flow.Fixing this now needs one more piece: either stop hardcoding
APP_ENV=productionfor the local dev compose stack (e.g. let it come from.envaslocal), or havedocker/setup.shexplicitly pass an environment override when seeding (e.g.APP_ENV=local docker-compose exec ...), before the originally suggesteddb:seedaddition will actually work. The other suggested fix (correcting the docs instead of adding seeding) is unaffected by this and remains a valid, simpler option.