ci: unify Validate proof across gates (#541)

Issue: #541
User-Visible: no

docs/DEVELOPMENT.md

@@ -430,10 +430,15 @@ publisher of installable assets (#540). Run it with `workflow_dispatch` on
 `main` with the exact tag: when the tag does not exist yet it is created on the
 `main` tip; when it exists, its commit is the candidate. The workflow resolves
 the tag to its exact commit, requires the `Release: <tag>` trailer on it,
-checks the release contract (`release-contract.mjs --stable`), waits for the
-latest non-cancelled Validate run of the
-SHA to complete successfully (#511: a cancelled run is not a verdict, a later
-re-run or another-baseline comparison refreshes an older result), requires Full
+checks the release contract (`release-contract.mjs --stable`) and requires a
+complete Validate proof for the exact candidate SHA and Git tree (#541). The
+proof is tied to the workflow run ID and attempt and lists both the requested
+checks and the jobs that actually executed. A skipped heavy job counts only
+when its content-addressed reuse marker names an independently verified
+successful source job. Review, merge and release use the same `missing` /
+`pending` / `cancelled` / `stale` / `failed` state machine. A cancelled or light
+run is not a release verdict and cannot hide an older full failure; a later
+complete full proof can refresh it (#511). The release also requires Full
 Performance and a green E2E run on a
 real Home Assistant — `e2e-gate.mjs --ref=<sha>` dispatches `e2e.yml` in
 `Matysh/houseplan-e2e` on the **candidate commit**, whose
@@ -461,7 +466,7 @@ everywhere in sync: `src/houseplan-card.ts` (CARD_VERSION), `package.json`,
 Validate intentionally runs on branch pushes, not tag pushes, so an annotated
 release tag does not duplicate the expensive browser/performance matrix. Every
 tagged SHA must therefore already be pushed to a branch and have a completed
-green exact-SHA Validate run. For an owner-approved emergency hotfix, push a
+green full exact-SHA Validate proof. For an owner-approved emergency hotfix, push a
 temporary `hotfix/*` branch and wait for Validate before creating the tag;
 never tag a detached or otherwise unpushed commit, because the release gate
 will wait for a run that cannot exist and then fail closed after one hour.

docs/STATUS.md

@@ -26,7 +26,7 @@ metadata). Only an explicit owner-approved emergency hotfix may skip this gate.
 | Hidden Alpha Stage | #89 Stage 1 ships in v1.63.0-beta.1, #122 Stage 2 in v1.64.0 and #160 Stage 3 in v1.73.0-beta.1. The same hidden `iso` view uses the fixed 4° camera, raised/tethered device-room-lock overlays, deeper openings and bounded theme materials; #471 removes the overlay plates from paint while retaining their safety geometry. Since #448 the experiment is enabled only through the single indefinite browser-local `hp_alpha` gate; it is not expiring and has no per-stage key. Flat remains default; editors, `houseplan-space-card`, floor effects, stored coordinates and HA actions remain unchanged. Stage 3 stays internal and is absent from public changelog/user documentation. |
 | Workflow | Superseded 2026-08-12: the pre-1.62 rule of "local edits without tests or commits" is **dead** — since release 1.62 every product change follows `PROCESS.md` (issue in `S5-ready`+, branch `issue/<NN>-slug`, trailers on every commit, review pipeline; `AGENTS.md` is the summary). Release mechanics below remain current. A requested pre-release gets a production build plus the smallest targeted unit/smoke set covering the changed surfaces, one tested `dev` commit/tag and a GitHub Release with `prerelease=true`; `main` stays untouched. The complete local frontend/backend/smoke gate runs only before a stable release, after which `main` is fast-forwarded to the exact tested `dev` SHA and the stable release is produced by `release.yml` (`workflow_dispatch` on `main` with the tag) — the only publisher of installable assets since #540: gates on the exact SHA (Validate, Full Performance, E2E on the candidate commit), one build, `houseplan.zip` archived from the committed tree, `SHA256SUMS`, draft → publish → read-back verification; a release published by hand in the GitHub form is turned back into a draft and walked through the same path, and a re-dispatch on a public tag is a repair that adds only missing assets. Release bodies are short and bilingual (Russian first); every bullet links its GitHub issue (#NN) so the #328 rules stay machine-checkable. A STABLE body aggregates the changelog since the PREVIOUS STABLE release (never since the last beta): features/fixes described across the line's beta changelogs must appear, while bugs that were introduced and fixed strictly inside the beta line (never shipped in any stable) are excluded — draft with `npm run release:notes -- <tag>`, curate by hand, then `npm run release:notes -- <tag> --verify` must pass. `Мелкие исправления и улучшения` / `Small fixes and improvements` is allowed only when the range really contains user-visible work not itemised in the body; a single-issue hotfix ships without it (the verifier enforces this). Every body ends with separate links to the Russian and English changelogs. Open or partially delivered issues are never presented as shipped. Telegram announcements are sent only for stable releases; beta and RC publication is silent. `docs/RELEASE-NOTES.md` is the current canonical body instance; `npm run release:prerelease -- <tag> --issues=… --yes` is the primary local publication path and the manual `Publish prerelease` workflow is its GitHub-only equivalent once present on `main`. Nothing is copied to the home instance by hand |
 | GitHub | https://github.com/Matysh/houseplan-card — [Issues](https://github.com/Matysh/houseplan-card/issues) are the canonical task records; their labels carry priority and workflow status (`PROCESS.md` §9). GitHub Projects is no longer used. `main` carries stable releases; pre-release tags may point directly at `dev`. Work lands on `dev` and is merged into `main` for a stable release, so `dev` is normally equal to or ahead of `main`, never behind. Push via SSH key `ha_jb` (remote git@github.com:…); API releases via the fine-grained PAT in `~/.git-credentials` (Contents R/W, issued 2026-07-23) |
-| CI | Prerelease publication requires a green exact-SHA Validate: frontend/backend, smoke (including the #73 rAF frame sampler), golden, HACS/Hassfest and a short absolute-ceiling performance smoke. Obsolete same-ref Validate runs are cancelled. Full seven-sample base/candidate performance moved to `performance.yml` (`main` push, weekly, manual); stable release assets fail closed unless Validate and Full Performance are green for the exact tagged SHA and the stable-only CDP compositor screencast finds no empty/black presented frame. |
+| CI | #541 replaces three incompatible meanings of “green” with one machine-verifiable Validate proof: candidate SHA/tree, run ID/attempt, requested checks, actually executed jobs and independently checked content-addressed reuse. Review, merge and release share the same closed state machine; a light green dispatch cannot hide a full red run, and a dispatch without six executed mutant jobs cannot authorize review or merge. Prerelease publication requires a green full exact-SHA proof covering frontend/backend, smoke (including the #73 rAF frame sampler), golden, HACS/Hassfest and the short absolute-ceiling performance smoke. Obsolete same-ref Validate runs are cancelled. Full seven-sample base/candidate performance remains in `performance.yml` (`main` push, weekly, manual); stable release assets fail closed unless Validate and Full Performance are green for the exact tagged SHA and the stable-only CDP compositor screencast finds no empty/black presented frame. |
 | Local toolchain | #557 removes ambient-PATH claims from the owner's workstation: `scripts/windows-toolchain.ps1` keeps verified portable Node 22 and a dedicated Python 3.14 `.venv-ci` without changing system defaults; `toolchain:check` reports exact executable/package/browser paths. The WSL entrypoint uses its own nvm + `.venv-ci`, and `--verify` runs a real HA subset and one Linux golden capture from an ext4 clone. These are early-feedback paths only; exact-SHA Linux CI remains canonical. |
 | HACS | **In the default catalog since 2026-08-25** (hacs/default#9004 merged). Install = plain HACS search. `houseplan.zip` is attached to stable tags automatically (verified on v1.72.0); forum/4pda announcement still pending |
 | Home instance | ha.jbstudio.pro (SSH port **22222**, key `ha_jb`; HA config root is `/mnt/data/supervisor/homeassistant` — `/config` does NOT exist in this SSH environment), last direct copy was **v1.57.0**; from v1.58.0 on it updates itself through HACS by tag (no scp) |

docs/TESTING.md

@@ -2466,9 +2466,9 @@ The dedicated `Full Performance` workflow builds the candidate and base SHA,
 then captures seven measured samples for each sequentially on the same Node 22,
 Playwright Chromium and hosted runner. It runs on `main`, weekly and by manual
 dispatch. `demo/performance/compare.mjs` applies the tighter of the approved
-absolute ceiling and baseline-relative allowance. Stable release assets need
-an exact-SHA green full run; prereleases need the fast exact-SHA `Validate`
-only. Raw reports and comparisons are uploaded as CI artifacts, and the check
+absolute ceiling and baseline-relative allowance. Stable release assets additionally need
+an exact-SHA green Full Performance run; every release, including a prerelease,
+needs the full exact-SHA `Validate` proof. Raw reports and comparisons are uploaded as CI artifacts, and the check
 tables are written to the job summary. Local measurements remain diagnostic.
 See `demo/performance/README.md` for commands and the budget-review contract.