v0.2.0-rc.3

v0.2.0-rc.3

Status

This file is a documentation-only readiness artifact. It records the next
proposed candidate channel named in RELEASING.md and #61, proposed after the
failed and unpublished v0.2.0-rc.1 canary and the v0.2.0-rc.2
duplicate-draft incident. As of this exact-head repository state:

• No v0.2.0-rc.3 tag, workflow run, draft, GitHub Release, or public asset
  set exists.
• The immutable v0.2.0-rc.1 tag remains failed, unpublished canary evidence,
  and the immutable v0.2.0-rc.2 tag remains duplicate-draft incident
  evidence. Both rc.2 drafts, all five of their assets, both annotated tags,
  and every existing release workflow run are untouched by this proposal. The
  exact disposition is recorded under "Canary and recovery evidence" in
  ../release-administration.md and under
  "Failure recovery and rollback" in RELEASING.md. Neither
  rc tag is ever moved, deleted, reused, rerun, or published; this proposal is
  the corrected successor channel that rule anticipates.
• The duplicate-draft and byte-drift defects that made rc.2 unrecoverable are
  landed on protected master via merged PR #60, closing #59. An rc.3 tag cut
  from a commit containing that fix would carry draft-visible exact-tag
  discovery, refusal before any write on duplicate candidates or an unstable
  release list, and same-run byte-provenance recovery. The immutable rc.2
  workflow cannot acquire that correction.
• Committing this file does not authorize creating the tag or running any
  release workflow. Tag creation and publication each require separate captain
  authorization, per RELEASING.md.
• The inert, fail-only exact-tag canary hooks remain hard-coded to
  v0.2.0-rc.2 and both of their repository variables remain absent. This
  proposal does not retarget them to rc.3, set either value, or authorize a
  canary; a successor canary is a separate focused change, per "Same-run
  recovery contract for a successor" in ../release-administration.md.

Scope of this proposal

This version bump and note are prepared under #61, which scopes only the
version/release-note proposal itself and the current-document surfaces that
must stay accurate for rc.3. Preparation (tagging, native packaging, draft
assembly) and publication remain separate, later, separately authorized steps.
No source, workflow, test, or dependency change is in scope.

Readiness evidence and remaining gates

The following verified facts apply to the rc.3 stream:

• Dependency remediation remains landed; npm audit reports no vulnerabilities
  at this head.
• Native-runner qualification has been dispatched twice from protected
  master, most recently
  run 31034089250
  at commit 682c6b8, where all four targets (linux/x64, win32/x64,
  darwin/arm64, darwin/x64) succeeded. That evidence covers those reviewed
  commits only and does not cover this head.
• GitHub private vulnerability reporting is enabled on the repository.
• The rc.1 and rc.2 incident dispositions are recorded in
  ../release-administration.md. The readiness and administration issues #43
  and #49 are closed, each with its own recorded disposition comment on the
  issue.
• The approved release-administration controls are documented in
  ../release-administration.md and remain separate from any release action.

The following boundaries still apply and must be preserved before any public
release:

• Verifying the private vulnerability-reporting route from the public
  repository experience, and any resulting SECURITY.md update, remain
  separate steps per ../release-administration.md.
• Runner qualification for the exact rc.3 commit is a separate authorized
  protected-master dispatch; earlier qualification evidence is not a claim
  about this head.
• Signing/notarization credentials and the protected release-signing
  environment are not part of this documentation step; macOS artifacts remain
  qualification-only until separately approved.
• Administrator rollout must stay aligned with ../release-administration.md.
  GitHub immutable releases remain disabled and, per "After recovery is
  proven", may be enabled only after a separately authorized successor canary's
  same-run recovery behavior is accepted.

Planned assets (never built)

v0.2.0-rc.3 has no tag, workflow run, or preparation attempt, so the assets
below, planned per RELEASING.md, do not yet exist:

• electris-v0.2.0-rc.3-linux-x64-portable.tar.gz (unsigned)
• electris-v0.2.0-rc.3-win32-x64-portable.zip (unsigned)
• electris-v0.2.0-rc.3-release-manifest.json
• electris-v0.2.0-rc.3-SHA256SUMS.txt
• Qualification-only electris-v0.2.0-rc.3-darwin-arm64.zip and
  electris-v0.2.0-rc.3-darwin-x64.zip, excluded from the public GitHub
  Release asset set while unsigned.

No npm or other package-registry publication is proposed, enabled, or
documented for this version.

Support and security status

Electris has no current supported release. This prerelease, once published,
would be an unsupported evaluation candidate with best-effort assistance and
no response-time SLA, consistent with SUPPORT.md. SECURITY.md's
disposition guidance applies unchanged.

Migration and rollback

No user-facing gameplay or data-format changes are proposed by this version
bump. Existing artwork and the Electris name are retained unchanged, with no
broader legal claim asserted. If this channel also fails to publish,
correction is a further new SemVer/tag via a corrected pull request, per
"Failure recovery and rollback" in RELEASING.md.

---

Known limitations of this prerelease

Recorded after publication, for transparency. Neither item changes the published bytes, which are
not replaced.

• The Windows archive cannot be independently verified from an LF checkout. The hashes and
  provenance of electris-v0.2.0-rc.3-win32-x64-portable.zip are valid: its SHA-256 matches
  SHA256SUMS.txt and the release manifest, and it passed matching-host qualification on a Windows
  x64 runner. However, npm run package:verify on the extracted archive fails from a checkout with
  LF line endings, because tracked text assets (app/css/main.css and LICENSE) were packaged with
  CRLF line endings by the Windows build host. This is a reproducibility limitation of the
  verification flow, not byte corruption of the archive and not a defect in the packaged
  application. A source fix is intended for a successor candidate.
• Post-publication smoke verification is incomplete. The bounded package smoke described in
  RELEASING.md has not been run against the downloaded public Linux x64 or Windows x64 assets. The
  equivalent bounded smoke did pass on matching hosts during preparation, and the published archives
  are byte-identical to those artifacts, but the post-publication check itself remains outstanding.

Treat v0.2.0-rc.3 as an unsupported evaluation prerelease while remediation is prepared for the
next release candidate.