Upgrade to 1.0.0-rc828

Concerns: pushword/core, pushword/installer, pushword/new

Contents

The pushword/installer bash script no longer touches your project

vendor/pushword/installer/src/installer hung off post-install-cmd. That hook is not what composer create-project fires, so on the documented install path the script never ran — vendor/pushword/core/install.php had quietly taken over the same work.

It did run on the next composer install, and there it was destructive: it truncated config/routes.yaml down to a single resource pointing at a file that no longer exists (@PushwordCoreBundle/Resources/config/routes/all.php), so the kernel could not build the router at all — admin, extensions and frontend alike. It also overwrote config/packages/pushword.yaml, re-ran doctrine:schema:create on an existing database, and then blocked forever on a read prompt with no terminal attached.

The script is now a no-op that deletes its own line from composer.json. You do not have to edit anything: the next composer install cleans it up. If you would rather not wait, drop this from scripts > post-install-cmd:

     "post-install-cmd": [
-      "bash ./vendor/pushword/installer/src/installer",
       "@auto-scripts"
     ],

If a past composer install already flattened your config/routes.yaml, restore it from Git — or re-add the resources your packages need, pushword last:

admin:
    resource: '@PushwordAdminBundle/AdminRoutes.yaml'
controllers:
    resource: routing.controllers
pushword:
    resource: '@PushwordCoreBundle/Resources/config/routes.yaml'

A fresh install creates its own super admin

install.php now runs pw:user:create admin@example.tld p@ssword ROLE_SUPER_ADMIN when it builds the database, and prints the credentials. Change them from /admin on first login. Only new installs are affected — an existing var/app.db is left alone.

The demo fixture user lost the maintainer's address along the way: it is john.doe@example.com instead of contact@piedweb.com. It has no password and only ROLE_USER, same as before — it is sample content, not an account.

pw:user:create fails instead of looping without a terminal

AskIfNotSettedTrait asked for a missing argument through QuestionHelper, which returns its default immediately when no terminal is attached, and the trait then asked again — forever. In CI or under an AI agent, pw:user:create and pw:user:delete spun until killed (23 million iterations and 719 MB of log in four minutes, measured).

Non-interactive runs now take the argument's default when it has one (role → ROLE_SUPER_ADMIN) and throw otherwise:

email is required: pass it as an argument when running non-interactively.

Scripts that relied on the prompt must pass the values: bin/console pw:user:create you@example.com 's3cret' ROLE_SUPER_ADMIN.

New projects ship an AGENTS.md and the docs package

pushword/new now requires pushword/docs, so vendor/pushword/docs/CLAUDE.md — the agent reference that file always claimed to ship — actually reaches your project.

The skeleton carries an AGENTS.md pointing at it, and install.php symlinks CLAUDE.md to it the way this monorepo does, so both agents read one file. The symlink is created at install time because Composer's zip extraction does not preserve it; it is skipped when CLAUDE.md already exists, so existing projects keep theirs untouched.

Fill in its About this site section — hosts, locales, deployment, editorial rules. That is the part an agent cannot infer from the code.