Keeping a project current

When you pick a project up after a while, or the user asks to keep it safe:

• project_scan: its security checks, and known vulnerabilities in the dependencies with the version that fixes each. Fix high ones first. Findings come grouped by rule and folder, and other people's code (WordPress core, plugins and default themes, installed packages, minified files) is left out and said so: don't edit it, keep WordPress and its plugins updated instead.
• Outdated dependencies: exec uv tree --outdated or pnpm outdated. Take patch and minor releases a few at a time, run the tests, then deploy preflight and publish; deploy rollback if anything breaks. New versions wait a week before they install here; a security fix younger than that can be taken early for that one package (project_scan's fix says how), and the exemption taken out again afterwards.
• Restart the services after a dependency change (service restart).
• The project's template may have moved on since it was made (project get says so). Nothing changes by itself: compare what's new (README-for-AI.md, services.json, the template's own files) and bring over what fits, as ordinary changes.
• A published site keeps the platform version it was built on: publishing again picks up the platform's own improvements (the preview gets them when it next wakes). project get says when a newer one is there, and the owner sees it on the project's Overview: check the preview, then tell the user that publishing brings it to the live site; it's their call when.