[Release] Prepare M5Authenticator v1.0.0

[miso-develop]

Goal

Prepare M5Authenticator for its first stable v1.0.0 production release.

The project is functionally at V1 release readiness, but the repository's canonical firmware version is still 0.1.0. The release preparation must update the canonical version sources and preserve the hardened production release contract before the protected v1.0.0 tag is created.

Current release-readiness context

At the time this request was created:

• no open Issues or PRs remain;
• V1 security hardening/release closeout is completed;
• the V1 physical-device E2E Human Gate is completed;
• the release supply-chain finding has independent Security closeout;
• SemVer tag protection, legacy Release workflow retirement, and immutable Releases have been completed;
• current production release profile is eligible (production_release_allowed: true);
• current main CI is green across firmware, Web, Windows Chrome QR, security scan, and Pages.

Specification must re-check current repository state before defining the final release-preparation task; this summary is context, not authority over newer GitHub state.

Known version sources that still require reconciliation

Current repository state includes at least:

• firmware/CMakeLists.txt: project(m5authenticator VERSION 0.1.0)
• firmware/release-profile.json: "firmware_version": "0.1.0"

The authorized release workflow requires the requested vX.Y.Z tag to match the canonical firmware version exactly, so v1.0.0 must not be created before the version-preparation change is integrated.

Specification request

Define the minimal, complete v1.0.0 release-preparation scope, including:

• all canonical version sources that must move from 0.1.0 to 1.0.0;
• generated/package/release metadata expectations;
• whether README/docs/changelog/release notes need any stable-version update;
• regression/CI expectations;
• exact pre-tag release gate;
• release sequence compatibility with the existing protected-tag + Authorized Release workflow;
• confirmation that no Product/Protocol/Storage Schema/Vault Format semantics are changed merely by the product SemVer bump.

Avoid broad feature work. This is a release-preparation task, not a new feature milestone.

Safety constraints

• Do not create or move the v1.0.0 tag during specification or implementation.
• Do not publish a Release as part of implementation verification.
• Do not weaken the existing release authorization, provenance, attestation, tag-protection, immutable-release, or secret-handling controls.
• Do not change Protocol / Storage Schema / Vault Format versions unless an independent product/compatibility requirement actually requires it.
• Release publication remains an Integration/Human-controlled operation after the preparation change is reviewed and integrated.

Expected workflow

1. Specification confirms the exact release-preparation contract and Acceptance Criteria.
2. Specification routes the implementation-ready work to the appropriate Implementation Agent/domain.
3. Implementation updates version/release-preparation sources and opens a PR.
4. Review and Integration verify and merge the exact change.
5. Only after the resulting exact main HEAD is green should the protected v1.0.0 tag be created and the Authorized Release flow invoked.

Specification resolution — 2026-09-19

State

BLOCKED_DEPENDENCY

Dependency sequence before the irreversible v1.0.0 tag:

1. [Task][Infra] Set canonical Product/Firmware version to 1.0.0 #214 — canonical Product/Firmware version -> 1.0.0 — implement/review/integrate first.
2. [Task][Infra] Add dependency-aware CI impact routing and release-oriented Pages deploys #216 — CI impact routing + release-oriented Pages cadence — implement/review/integrate second.
3. Human-approved exact-main manual candidate Pages deployment and production-host validation.
4. Remaining exact pre-tag gate.
5. Explicit Human approval for protected v1.0.0 tag creation.
6. Authorized Release + tag-triggered Pages production publication.

Current blocking dependency: #214.

#213 must remain open through #214, #216, the manual candidate Pages gate, protected tag creation, and final release verification.

Revalidated baseline

Specification rechecked current repository state rather than relying on the creation-time snapshot.

• current main: bc5c3b90f57952f04a80c8ddfcb55b6d384c882e
• open PRs: none
• current-main checks observed:
  • security:scan: SUCCESS
  • Foundation web: SUCCESS
  • Foundation web QR Windows Chrome: SUCCESS
  • Foundation firmware: SUCCESS
  • Pages build-pages: SUCCESS
  • Pages deploy-pages: SUCCESS
• [Security][Release] Bind SemVer tags/releases to protected main and make published release immutable #127 release supply-chain finding: closed / completed / SECURITY_CLEAR
• [Task][Infra] Enforce protected-main release authorization and signed artifact provenance #164 hardened Authorized Release publisher: closed / completed
• [Human Task][Repository] Protect SemVer tags and enable immutable Releases #165 repository Human Gate: closed / completed
• [Decision][Release] Move production publication authority off tag-push workflow definitions #199 / [Decision][Release] Retire deleted legacy workflow via disabled tombstone identity #200 release trust-root / legacy-workflow decisions: closed / completed
• historical legacy Release workflow ID 354596449: durable Human/API evidence records disabled_manually; tombstone remains on main
• SemVer tag creation + immutability rulesets: durable [Human Task][Repository] Protect SemVer tags and enable immutable Releases #165/[Security][Release] Bind SemVer tags/releases to protected main and make published release immutable #127 evidence records active
• immutable Releases: durable Human/API evidence records enabled: true
• existing v0.1.0 tag: present at historical commit cbb30802896e9bde81f26c12a0e3255d1436c2b7
• existing published Release: v0.1.0
• refs/tags/v1.0.0: does not exist (GitHub ref lookup returned 404)
• no v1.0.0 Release exists

Release identity decision

The stable release target is exactly:

Product/Firmware SemVer = 1.0.0
Git tag                 = v1.0.0
Release title           = M5Authenticator v1.0.0

This SemVer bump expresses product/release maturity. It does not itself change compatibility/security formats.

The following current compatibility identities remain unchanged:

PROTOCOL_VERSION       = 2
STORAGE_SCHEMA_VERSION = 2
VAULT_FORMAT_VERSION   = 1
security profile       = encrypted-vault-ram-only-vmk / v1

Do not increment any of those solely because the Product/Firmware SemVer becomes 1.0.0.

Canonical product-version sources

Exactly these current repository sources are authoritative for the firmware/product release version and must move together from 0.1.0 to 1.0.0:

1. firmware/CMakeLists.txt

   project(m5authenticator VERSION 1.0.0)

   This is the ESP-IDF/CMake application-project version.

2. firmware/components/m5auth_core/include/m5auth/core/metadata.hpp

   inline constexpr char kFirmwareVersion[] = "1.0.0";

   This is the Device/runtime firmware metadata surfaced through the canonical product protocol.

3. firmware/release-profile.json

   "firmware_version": "1.0.0"

   This is the release/package/Pages/Authorized Release identity source.

All three must agree before a release-capable build is valid.

Close the existing consistency gap

Current scripts/validate_release.py already requires release-profile firmware_version to equal kFirmwareVersion, but it does not currently validate the CMake project(... VERSION ...) value.

The release-preparation implementation must extend deterministic validation so:

• CMake project version is parsed;
• CMake version == kFirmwareVersion;
• CMake version == release-profile firmware_version;
• malformed/missing/divergent values fail closed.

This check must run through the existing Foundation / release-validation path and therefore also protect the Authorized Release path.

Do not solve this by introducing a fourth hand-maintained product-version source.

Explicitly non-canonical 0.1.0 values

The implementation must perform a repository-wide audit for literal/current-version-like 0.1.0 references and classify them. The following known occurrences are not Product/Firmware release sources and do not need to move merely for this release:

• web/package.json / root package entry in web/package-lock.json
  • package is private: true;
  • this is npm package-manager metadata;
  • production Web build identity does not read it.
• web/vite.config.ts firmware-layout/QR smoke fixture values
  • test-only fixture;
  • not used as production release identity.
• historical v0.1.0 references that truthfully refer to the already-published historical release.

Production Pages Web identity is intentionally derived from firmware/release-profile.json through VITE_M5AUTH_WEB_VERSION, so the Web user-facing release baseline will become v1.0.0 + <commit> on ordinary post-merge main builds and v1.0.0 only when the exact release tag points at that source SHA.

If the audit finds another current production/user-facing canonical source still asserting 0.1.0, Implementation must not silently classify it away; record it and return to Specification if its semantic ownership is unclear.

Generated package / metadata expectations

After the version-preparation PR changes the canonical sources, normal candidate packaging on the exact PR/main SHA must derive 1.0.0 without hard-coded output rewriting.

Expected properties:

• factory-manifest.json.version == "1.0.0"
• update-manifest.json.version == "1.0.0"
• firmware-target.json.version == "1.0.0"
• release-metadata.json.firmware_version == "1.0.0"
• generated firmware asset names use the v1.0.0-<build_commit> candidate identity currently defined by package_firmware.py
• candidate/pre-tag package has exact_release: false
• Protocol = 2, Storage Schema = 2, Vault Format = 1 in release metadata
• production_release_allowed == true
• First install / state-preserving Update partition and security contracts remain unchanged
• SHA256SUMS covers the normal generated package as before.

The implementation should add/adjust deterministic release-package assertions so 1.0.0 is verified as current repository release identity rather than relying only on indirect equality checks.

Web/Pages expectation during the preparation interval

#214 is integrated first while the current Pages cadence is still in effect.

Then #216 is intentionally integrated before the protected v1.0.0 tag. #216 changes Pages to release-oriented cadence:

• ordinary main pushes no longer deploy public Pages;
• protected SemVer tag pushes deploy Pages automatically;
• an explicit Human-approved manual candidate deployment remains available for pre-release production-host validation.

After #216 integration, the ordinary merge push to main is expected not to run Pages.

Before the v1.0.0 tag is created, one manual candidate Pages deployment must be run from the exact current main SHA. Because no matching release tag exists yet, its public build identity must remain non-exact, e.g.:

v1.0.0 + <short-main-commit>

and candidate package assets may carry the commit-qualified v1.0.0-<commit> identity.

That manual candidate deployment is not the official immutable GitHub Release. Exact-release identity remains false until the protected v1.0.0 tag points at the approved source SHA.

Do not pre-create the tag merely to obtain an exact-release Pages identity.

README / documentation / changelog decision

No broad documentation rewrite is required for the SemVer bump.

Current README does not declare v0.1.0 as the current release, and durable V1 documentation intentionally describes compatibility boundaries independently from Product SemVer.

Therefore:

• no README version badge/current-version line is required;
• no new CHANGELOG.md is required solely for this release;
• no V1 architecture/security doc version rewrite is required;
• docs/DISTRIBUTION.md remains valid because it uses generic v<version> release identities and current release mechanics.

If implementation finds a current user-facing statement that specifically claims 0.1.0 is the current version, update only that stale statement.

Release notes decision

The current hardened publisher uses:

gh release create ... --title "M5Authenticator $REQUESTED_TAG" --generate-notes

Keep this behavior for v1.0.0; no repository release-notes file is required by this preparation Task.

Because future Releases are immutable, the Human/Integration release gate must accept the generated-notes policy before publication. If curated/custom v1.0.0 notes are desired instead, that is a pre-publication Specification change; do not plan to edit the Release after publication.

Implementation verification

The release-preparation PR must demonstrate on its exact head:

• all three canonical version sources are exactly 1.0.0;
• new consistency validation rejects divergence between CMake / runtime metadata / release profile;
• python scripts/validate_release.py --require-production succeeds;
• release/package tests succeed and explicitly observe 1.0.0;
• generated candidate manifests/metadata have the expected version and unchanged compatibility values;
• Foundation is green;
• Security is green;
• no protected-tag creation or Release publication occurs;
• no product behavior, Protocol, Storage Schema, Vault Format, crypto, persistence, or release-authority change is included.

Independent Review remains required.

Exact pre-tag gate

After both #214 and #216 are independently reviewed and integrated, do not create v1.0.0 immediately from stale handoff data.

Integration/Human must establish one exact current protected main SHA and require all of the following:

1. exact current protected main SHA is recorded;
2. canonical CMake / runtime metadata / release-profile versions all equal 1.0.0;
3. production_release_allowed: true;
4. Protocol = 2 / Storage Schema = 2 / Vault Format = 1 unchanged;
5. exact-main security:scan is successful;
6. exact-main Foundation impact routing is correct for the [Task][Infra] Add dependency-aware CI impact routing and release-oriented Pages deploys #216-integrated state, with every heavy job required by that change classification successful;
7. the ordinary main push after [Task][Infra] Add dependency-aware CI impact routing and release-oriented Pages deploys #216 integration does not run Pages build/deploy and creates no Pages staging artifact; this is the expected success condition, not a missing gate;
8. one Human-approved manual candidate Pages deployment is executed from the exact same current-main SHA before tag creation;
9. that manual candidate deployment succeeds through production firmware packaging, production Web build, staging artifact upload, public Pages deploy, and exact-ID artifact cleanup;
10. production-host validation on that candidate Pages deployment is completed and recorded, at minimum confirming:
    • GitHub Pages loads Provisioner, Firmware, and Help from the production /m5authenticator/ base path;
    • production CSP does not break required local QR/image/WASM behavior covered by the hosted application;
    • Firmware route can load the same-origin firmware target/manifest assets;
    • displayed Web build identity corresponds to v1.0.0 + <short exact-main commit> (non-exact release before tag);
    • deployed firmware/package metadata identifies build commit as the same exact main SHA;
    • no broken/stale asset, unexpected cross-origin dependency, or release-blocking production-host regression is observed;
11. after the manual candidate deploy/validation, current main is re-read and must still equal the candidate SHA. If main moved, the candidate gate is stale and must be rerun on the new exact main;
12. no unresolved release/security blocker exists;
13. refs/tags/v1.0.0 still does not exist;
14. hardened .github/workflows/release-authorized.yml remains the sole production GitHub Release publisher and its authorization/attestation contract is unchanged;
15. legacy Release workflow identity remains retired/disabled per [Decision][Release] Retire deleted legacy workflow via disabled tombstone identity #200/[Human Task][Repository] Protect SemVer tags and enable immutable Releases #165;
16. SemVer creation and immutability rulesets remain active;
17. immutable Releases remains enabled;
18. Human explicitly approves creation of the irreversible protected v1.0.0 identity at that exact SHA.

A failure in any item blocks tag creation.

The manual candidate Pages deployment is a required pre-tag Human Gate for this first stable release under the new cadence. It intentionally replaces the former requirement that an ordinary main push itself produce a successful Pages deployment.

Production release sequence after the pre-tag Human Gate

Use the already-approved #199 / docs/DISTRIBUTION.md pre-existing protected-tag sequence after the exact-main manual candidate Pages Human Gate has passed:

1. Human/Integration confirms the exact protected-main SHA.
2. Create v1.0.0 at that exact SHA through the authorized tag-creation path.
3. Immediately re-read refs/tags/v1.0.0 and require that it resolves/peels to the exact approved SHA.
4. Do not move/delete/recreate the tag if anything is wrong; the immutability control is intentional. Escalate instead.
5. Submit repository_dispatch:

   event_type=publish_semver_release
   client_payload.tag=v1.0.0
   

6. Let the default-branch-owned Authorized Release workflow independently re-authorize exact main/tag/checks/profile, build in the pinned isolated ESP-IDF environment, verify, attest, and publish the exact verified bytes.
7. Require the Authorized Release workflow to succeed.
8. Verify the resulting immutable Release is M5Authenticator v1.0.0, its assets identify firmware version 1.0.0, and signed attestation verification succeeds per docs/DISTRIBUTION.md.
9. Verify the tag-triggered production Pages deployment succeeds and identifies the exact release as v1.0.0 rather than the manual candidate identity v1.0.0 + <commit>.
10. Verify the final public Pages deployment corresponds to the same exact release/source identity as the immutable GitHub Release.

Tag creation, Authorized Release dispatch, and tag-triggered production Pages publication are not part of #214 or #216 Implementation.

Safety boundary

This release bump changes only Product/Firmware SemVer and deterministic consistency coverage.

It must not change:

• Protocol vocabulary/version;
• Storage Schema;
• Vault Format or migration behavior;
• cryptographic algorithms/keys/KDF parameters;
• Trusted Browser / recovery / Lock semantics;
• firmware Flash layout/update semantics;
• production eligibility;
• ESP-IDF version/digest;
• release privilege separation / attestation authority;
• SemVer tag Rulesets;
• immutable Releases;
• legacy workflow retirement;
• any secret-handling boundary.

[miso-develop]

HANDOFF
FROM: general
TO: specification
ISSUE: #213
STATE: ROUTE_TO_SPECIFICATION

[miso-develop]

Specification routing complete

Specification revalidated the current repository and fixed the v1.0.0 preparation contract in this Issue.

Implementation dependency:

• [Task][Infra] Set canonical Product/Firmware version to 1.0.0 #214 — canonical Product/Firmware version reconciliation + fail-closed version consistency validation + package regression coverage.

Key disposition:

• Product/Firmware SemVer -> 1.0.0;
• Protocol / Storage Schema / Vault Format remain 2 / 2 / 1;
• no README/changelog rewrite is required merely for the version bump;
• existing Authorized Release --generate-notes behavior remains;
• [Task][Infra] Set canonical Product/Firmware version to 1.0.0 #214 must not create the tag or publish a Release;
• protected v1.0.0 creation is a separate post-merge Integration/Human operation under the exact pre-tag gate recorded above.

Parent state: BLOCKED_DEPENDENCY on #214.

[miso-develop]

CI optimization sequencing note

#215/#216 has been specified to change routine Foundation/Pages routing, including removing automatic Pages deployment from ordinary main pushes.

To avoid mutating the active v1.0.0 exact pre-tag gate mid-flight, #216 is explicitly blocked until #213 is closed/completed.

Therefore the current #213 release contract remains unchanged for v1.0.0. After the release is complete, #216 may re-bootstrap against the then-current Rulesets/workflows and implement the new release-oriented Pages cadence.

[miso-develop]

Specification sequencing revision — Human decision

The previous sequencing that deferred #215/#216 until after v1.0.0 Release is superseded.

Authoritative sequence is now:

1. [Task][Infra] Set canonical Product/Firmware version to 1.0.0 #214 implement/review/integrate canonical Product/Firmware version 1.0.0.
2. [Task][Infra] Add dependency-aware CI impact routing and release-oriented Pages deploys #216 implement/review/integrate CI impact routing and release-oriented Pages cadence.
3. On the resulting exact current main SHA, verify Security + Foundation routing and verify that the ordinary main push does not deploy Pages.
4. With explicit Human approval, run one manual candidate Pages deployment bound fail-closed to that exact current-main SHA.
5. Complete candidate production-host validation and confirm main has not moved.
6. Complete the remaining [Release] Prepare M5Authenticator v1.0.0 #213 pre-tag controls.
7. Human explicitly approves protected v1.0.0 tag creation.
8. Run Authorized Release and the tag-triggered production Pages deployment.

#213's exact pre-tag gate has been revised accordingly. A routine main-push Pages success is no longer required after #216; absence of that deployment is expected. The manual exact-main candidate deployment replaces it as the pre-tag hosted-production gate.

Current #213 state remains BLOCKED_DEPENDENCY, first on #214 and then #216 / the Human candidate gate.

[miso-develop]

#214 dependency integrated

• [Task][Infra] Set canonical Product/Firmware version to 1.0.0 #214 / PR release: prepare canonical v1.0.0 identity (#214) #217: integrated
• current main: 49de696f3a75a1afa100606bce2b072ec5148c98
• canonical Product/Firmware versions on main: 1.0.0 / 1.0.0 / 1.0.0
• Protocol / Storage / Vault remain 2 / 2 / 1
• production_release_allowed: true
• v1.0.0 tag: absent
• v1.0.0 Release: absent

#213 remains open. The next dependency is #216; protected tag creation remains prohibited until #216 integration plus the exact-main manual candidate Pages Human Gate and the remaining pre-tag controls complete.

[miso-develop]

#216 dependency integrated and post-merge gate passed

Exact current main: 6f008c6864d3b080106f53d51eb7cbe1f2b4c150

Post-merge evidence:

• [Task][Infra] Add dependency-aware CI impact routing and release-oriented Pages deploys #216 / PR ci: add dependency-aware impact routing and release-oriented Pages (#216) #218 integrated
• Security #950: SUCCESS
• Foundation #947: SUCCESS with classify + Web + Windows Chrome + Firmware all successful
• ordinary main push created no Pages workflow run
• ordinary main push produced no Pages staging artifact
• canonical CMake/runtime/profile Product/Firmware versions remain 1.0.0
• Protocol / Storage / Vault remain 2 / 2 / 1
• production eligibility remains true
• Authorized Release workflow remains unchanged
• retired Release tombstone remains present
• v1.0.0 tag: absent
• v1.0.0 Release: absent

Next mandatory pre-tag gate is the explicit Human-approved manual Pages candidate deployment from this exact main SHA.

Manual Pages workflow inputs:

• candidate_sha = 6f008c6864d3b080106f53d51eb7cbe1f2b4c150
• candidate_ack = true

This candidate deployment overwrites the public Pages site and is not the immutable v1.0.0 Release.

HANDOFF
FROM: integration
TO: human
ISSUE: #213
STATE: HUMAN_GATE_REQUIRED

[miso-develop]

Human approval — manual Pages candidate

Human explicitly approved the pre-tag manual public Pages candidate deployment.

Approved exact candidate SHA:
6f008c6864d3b080106f53d51eb7cbe1f2b4c150

Pre-dispatch recheck:

• current main still equals the approved SHA
• Security #950: SUCCESS
• Foundation #947: SUCCESS
• v1.0.0 tag: absent
• v1.0.0 Release: absent
• no prior Pages run exists for this exact main push

Authorized manual workflow inputs:

• candidate_sha=6f008c6864d3b080106f53d51eb7cbe1f2b4c150
• candidate_ack=true

The manual candidate overwrites the public Pages site and remains pre-release/mutable. It is not the immutable v1.0.0 GitHub Release.

STATE: HUMAN_APPROVED

[miso-develop]

Manual candidate run result — deployment PASS, pre-tag gate remains BLOCKED

Run: 35449129354
Deployed source: 6f008c6864d3b080106f53d51eb7cbe1f2b4c150

Passed:

• exact-main/manual acknowledgement authorization
• production release-profile validation
• non-exact candidate identity (M5AUTH_EXACT_RELEASE=false)
• production firmware/package/Web build
• Pages staging upload
• public Pages deployment
• exact staging artifact-ID deletion (10586563104); no run artifact remains

Blocking finding:

• the candidate GitHub Step Summary fails to record exact source/build identity correctly because Markdown backticks in double-quoted Bash echo strings execute as command substitution.
• [Task][Infra] Add dependency-aware CI impact routing and release-oriented Pages deploys #216 has therefore been reopened for rework.

Do not create v1.0.0 yet.
After the fix is integrated, current main will change and this candidate becomes stale; rerun the exact-main Human-approved candidate deployment and production-host validation on the new SHA.

STATE: BLOCKED_DEPENDENCY

[miso-develop]

Fresh exact-main candidate gate required after #216 rework

Exact current main: 996378b07d8587c0d11e43362590e5d1062ad8c2

The #216 summary-rendering correction is integrated and its post-merge checks are green:

• Security #952: SUCCESS
• Foundation #949: SUCCESS
• ordinary main push created no Pages workflow run/artifact
• Product/Firmware remains 1.0.0
• v1.0.0 tag/Release remain absent

The prior Human-approved candidate at 6f008c6864d3b080106f53d51eb7cbe1f2b4c150 is stale because main changed.

A new manual public Pages candidate must be explicitly approved and dispatched with:

• candidate_sha = 996378b07d8587c0d11e43362590e5d1062ad8c2
• candidate_ack = true

The fresh run must additionally verify the corrected Step Summary renders source ref/SHA/candidate/current-main/version/build-commit/exact-release literally and correctly.

HANDOFF
FROM: integration
TO: human
ISSUE: #213
STATE: HUMAN_GATE_REQUIRED

[miso-develop]

Human approval — fresh manual Pages candidate

Human explicitly approved rerunning the pre-tag public Pages candidate deployment after the #216 summary-rendering fix.

Approved exact candidate SHA: 996378b07d8587c0d11e43362590e5d1062ad8c2

Pre-dispatch recheck:

• current main still equals the approved SHA
• Security #952: SUCCESS
• Foundation #949: SUCCESS
• Protect main, SemVer tag creation, and SemVer tag immutability Rulesets remain active
• Authorized Release workflow remains unchanged
• retired Release tombstone remains present
• v1.0.0 tag: absent
• v1.0.0 Release: absent

Authorized manual workflow inputs:

• candidate_sha=996378b07d8587c0d11e43362590e5d1062ad8c2
• candidate_ack=true

This candidate overwrites the public Pages site and remains mutable/pre-release. It is not the immutable v1.0.0 GitHub Release.

STATE: HUMAN_APPROVED

[miso-develop]

Fresh manual Pages candidate — automated/deployment evidence PASS

Run: 35451983153 (Pages #81)
Exact source/current main: 996378b07d8587c0d11e43362590e5d1062ad8c2

Verified:

• workflow event: workflow_dispatch on main at the exact approved SHA;
• build-pages: SUCCESS;
• deploy-pages: SUCCESS;
• exact-main authorization step: SUCCESS;
• summary helper ci_pages_summary.py candidate-authorization executed successfully with the approved candidate SHA;
• summary helper ci_pages_summary.py candidate-build-identity executed successfully;
• no command not found / No such file or directory errors remain in the build log;
• release validation reports M5StickS3 v1.0.0 protocol=2 storage=2 vault=1 ... production-eligible;
• runtime build environment records VITE_M5AUTH_WEB_BUILD_COMMIT=996378b07d8587c0d11e43362590e5d1062ad8c2;
• runtime build environment records M5AUTH_EXACT_RELEASE=false;
• generated firmware/package filenames carry v1.0.0-996378b07d8587c0d11e43362590e5d1062ad8c2;
• Pages deployment payload used artifact ID 10587356867 and pages_build_version=996378b07d8587c0d11e43362590e5d1062ad8c2;
• deployment succeeded for the exact SHA;
• artifact ID 10587356867 was deleted by exact ID after deployment;
• workflow-run artifact listing is now empty;
• deployment environment URL is https://miso-develop.github.io/m5authenticator/.

Remaining Human-visible production-host checks:

• GitHub Actions Step Summary visibly renders the corrected literal source/candidate/current-main/version/build identity fields;
• public Pages Provisioner, Firmware, and Help load correctly under /m5authenticator/;
• hosted Firmware surface can load same-origin firmware metadata/assets;
• displayed candidate build identity corresponds to v1.0.0 + <short 996378b...> and is non-exact/pre-release;
• no broken/stale asset, CSP-visible failure, or unexpected cross-origin dependency is observed.

Protected v1.0.0 tag creation remains blocked until these Human-visible checks pass and current main is re-read unchanged.

STATE: HUMAN_GATE_REQUIRED

[miso-develop]

Fresh exact-main Pages Human Gate — PASS

Validated exact current main: 996378b07d8587c0d11e43362590e5d1062ad8c2
Candidate run: 35451983153 (Pages #81)

Human-visible production-host validation: PASS

• corrected Actions Step Summary renders source ref as refs/heads/main;
• source SHA, candidate SHA, and current-main SHA render as 996378b07d8587c0d11e43362590e5d1062ad8c2;
• Product/Firmware identity renders as v1.0.0;
• build commit renders as 996378b07d8587c0d11e43362590e5d1062ad8c2;
• exact release renders as false;
• public Provisioner / Firmware / Help routes load correctly under /m5authenticator/;
• hosted Firmware surface loads same-origin firmware metadata/assets;
• displayed build identity is the expected non-exact v1.0.0 + <commit> candidate identity;
• no broken/stale assets, CSP-visible failure, or unexpected cross-origin dependency observed.

Automated/deployment evidence is already recorded on this Issue:

• build/deploy SUCCESS;
• exact source binding;
• non-exact release identity;
• exact artifact-ID cleanup;
• no remaining run artifact.

The manual candidate gate is complete for this exact main SHA. Protected v1.0.0 creation still requires the remaining exact pre-tag repository-control recheck and a separate explicit Human approval.

STATE: HUMAN_GATE_PASS

[miso-develop]

Exact pre-tag gate — COMPLETE

Approved release source SHA: 996378b07d8587c0d11e43362590e5d1062ad8c2

All #213 pre-tag requirements are now satisfied on this exact current main:

1. current protected main re-read and still equals the approved SHA;
2. canonical CMake/runtime/release-profile Product/Firmware versions are all 1.0.0;
3. production_release_allowed: true;
4. Protocol / Storage Schema / Vault Format remain 2 / 2 / 1;
5. exact-main Security #952 / security:scan: SUCCESS;
6. exact-main Foundation #949: SUCCESS with required shared-impact routing;
7. ordinary main push created no Pages build/deploy run and no Pages staging artifact;
8. Human-approved exact-main manual Pages candidate run [Defect] Web Serial connect consumes ESP-IDF startup log as Protocol 2 JSON response #81 executed;
9. candidate production firmware/package/Web build, staging upload, deploy, and exact-ID cleanup succeeded;
10. Human production-host validation passed for Provisioner/Firmware/Help, same-origin firmware metadata/assets, CSP-visible behavior, and non-exact v1.0.0 + <commit> identity;
11. current main was re-read after candidate validation and is unchanged;
12. no unresolved release/security blocker exists; [Security][Release] Bind SemVer tags/releases to protected main and make published release immutable #127 and [Human Task][Repository] Protect SemVer tags and enable immutable Releases #165 are closed/completed; [CI] Avoid unnecessary heavy CI and Pages artifact generation for non-impacting changes #215 remains only a Specification closeout parent and is not a release blocker;
13. refs/tags/v1.0.0: absent;
14. hardened .github/workflows/release-authorized.yml remains unchanged (blob d126d260b05c56556cb2e83017ee21086a362490);
15. legacy Release workflow identity 354596449 was re-verified by Human/API as:

• name Release
• path .github/workflows/release.yml
• state disabled_manually;

16. SemVer creation and immutability Rulesets remain active;
17. Immutable Releases was re-verified by Human/API as:

• enabled: true
• enforced_by_owner: false;

18. final irreversible protected-tag creation still awaits an explicit Human approval for this exact SHA.

v1.0.0 GitHub Release is still absent.

STATE: HUMAN_GATE_REQUIRED

Next action after explicit Human approval:

• create protected tag v1.0.0 at exactly 996378b07d8587c0d11e43362590e5d1062ad8c2;
• immediately re-read the tag and require it to resolve/peel to that exact SHA;
• then invoke the Authorized Release publish_semver_release dispatch;
• verify immutable Release publication, attestation, and tag-triggered production Pages deployment.

[miso-develop]

Human approval — protected v1.0.0 tag

Human explicitly approved creation of the protected v1.0.0 tag at exactly:

996378b07d8587c0d11e43362590e5d1062ad8c2

Immediately before this approval was recorded, Integration re-read current main and confirmed it still resolves to the same exact SHA. refs/tags/v1.0.0 and the v1.0.0 Release were still absent, and the SemVer tag creation / immutability rulesets remained active.

The irreversible tag identity is therefore Human-approved for this exact SHA under the completed #213 pre-tag gate.

Tag creation remains pending until the authorized Git ref creation operation is executed. Do not create the tag at any other SHA.

[miso-develop]

Protected v1.0.0 tag — VERIFIED

Integration independently re-read the protected release identity after Human tag creation.

• refs/tags/v1.0.0 exists.
• Tag object type: commit (lightweight tag).
• Tag commit: 996378b07d8587c0d11e43362590e5d1062ad8c2.
• Current main: 996378b07d8587c0d11e43362590e5d1062ad8c2.
• Exact tag/main identity match: PASS.
• v1.0.0 GitHub Release: still absent at this checkpoint.

The irreversible protected tag was created at the exact Human-approved SHA and has been independently verified.

Next authorized release step: submit repository_dispatch with event_type=publish_semver_release and client_payload.tag=v1.0.0, then verify the hardened Authorized Release workflow, immutable Release assets/attestations, and tag-triggered production Pages deployment.