Bring the framework's docblocks, docs and tests to the house style

.github/PULL_REQUEST_TEMPLATE.md

@@ -14,7 +14,7 @@
 
 - [ ] Tests added or updated (Unit and/or Integration as appropriate)
 - [ ] `composer quality-check` passes locally (PHPCS, PHPStan and the tests)
-- [ ] Public API changes are documented in the affected package's `README.md`
+- [ ] Changelog fragment added (`composer changelog:add`)
 - [ ] Breaking changes are explicitly justified below
 
 ## Breaking changes / migration notes

CHANGELOG.md

@@ -1,3 +1,5 @@
 # Changelog
 
-Notable changes to the five framework packages, which release together under one version.
+All notable changes to the five framework packages, which release together under one version, are documented in this file. Format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), versioning follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+Pending entries live in [`changelog/`](./changelog) — add via `composer changelog:add`. Aggregate into a release with `composer changelog:write`.

CONTRIBUTING.md

@@ -21,8 +21,32 @@ actionlint
 zizmor .github/
 ```
 
+## Changelog entries
+
+Each user-visible change adds one fragment, so pull requests never conflict on `CHANGELOG.md`:
+
+```sh
+composer changelog:add
+```
+
+The command asks for the change's significance, its type and its entry, and writes the fragment to `changelog/<branch-name>`, which the pull request commits. CI validates the fragments with `composer changelog:validate`.
+
 ## Filing changes
 
 - Keep one concern per pull request.
 - Fill in the template's breaking-changes section.
 - Follow the code, documentation and commit conventions in [AGENTS.md](AGENTS.md).
+
+## Releases
+
+The five packages release together under one version. A release writes the fragments into a new version block of `CHANGELOG.md`, whose version the fragments' significance sets:
+
+```sh
+composer changelog:write
+```
+
+Pushing the tag `v<version>` on that commit splits it to every mirror, where consumers' `vcs` repositories find the release.
+
+## WooCommerce floor
+
+The woocommerce package tracks the newest stable WooCommerce release until a tag. Raising the floor moves, in one commit, the manifest's `extra.requires-wc`, the root's and the fixtures' `wp-plugin/woocommerce` and `php-stubs/woocommerce-stubs` constraints, the fixtures' `WC requires at least` and `WC tested up to` headers, and the locks. The same commit re-checks that WooCommerce still uses each cache group `MetaTypes::DEFINITIONS` names, because the uninstall engine flushes them.

README.md

@@ -26,9 +26,7 @@ The packages form a stack: core builds on bootstrap and shared, settings on core
 ## Local development
 
 ```sh
-composer packages-install   # PHP deps (wraps composer install, ignoring only the PHP upper bound)
-npm install                 # Node deps (wp-env)
-npm run wp-env:start        # developer environment at http://localhost:8800, as local, with WooCommerce
+npm run setup               # PHP and Node deps, then the developer environment at http://localhost:8800, as local, with WooCommerce
 composer quality-check      # Validation, PHPCS, PHPStan, Unit and Integration tests (starts the tests environment)
 ```
 

SECURITY.md

@@ -2,9 +2,7 @@
 
 ## Reporting a vulnerability
 
-Please report security vulnerabilities privately via [GitHub's security advisory form](https://github.com/ahegyes/wordpress-framework/security/advisories/new). Do not open a public issue.
-
-You can expect an initial response within 7 days. Once the report is triaged, you'll receive updates as fixes land. Once a fix is released, credit is given in the advisory unless you request anonymity.
+Report it privately through [GitHub's security advisory form](https://github.com/ahegyes/wordpress-framework/security/advisories/new), never in a public issue. The first response comes within 7 days, and the advisory credits the reporter once a fix is released, unless they ask to stay anonymous.
 
 ## Supported versions