release-ci-guardrailslisted

# Release and CI Guardrails Use this skill before creating a release/tag and whenever GitHub Actions reports a platform-only failure. ## Release Checklist 1. Run release checks after the final edit, not before: - `python3 scripts/testing/check_release_version_consistency.py` - `python3 scripts/testing/check_release_docs_freshness.py` - `python3 scripts/testing/check_public_release_safety.py` - `python3 scripts/testing/check_release_commit_shape.py --range origin/master..HEAD` 2. Run the host Python suite after the final edit: - `scripts/testing/run_host_python_tests.sh` 3. If docs/site files changed, run: - `scripts/testing/run_site_ui_checks.sh` 4. Clean generated artifacts before staging: - `node_modules`, `__pycache__`, `playwright-report`, `test-results` 5. Land the work and the release as separate commits. A release is never one commit. - One or more **work commits**: the product change with its tests and the documentation that describes it, each self-contained, each describing itself under `## Unreleased` in the changelog. A work commit must not bump any version. - Then exactly one **release commit** whose subject starts with `release:`, carrying only what `scripts/tools/sync_release_version.py` writes plus the changelog section it opens: package and lock metadata, both package manifests, the `SERVER_INFO` version line, the release docs, and the retro registry or design-plan history when their release b