v0.2.0-rc.4

v0.2.0-rc.4

Status

This file is a documentation-only readiness artifact. It records the next
proposed candidate channel named in RELEASING.md and #75, proposed as the
plain successor to published v0.2.0-rc.3. As of this exact-head repository
state:

• No v0.2.0-rc.4 tag, workflow run, draft, GitHub Release, or public asset
  set exists.
• v0.2.0-rc.3 is published, immutable, and a prerelease; it is retained, not
  withdrawn. v0.1.2 remains the latest release. Committing this file does
  not change rc.3's published bytes, its known-limitation notice, or its
  status in any way.
• 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.
• 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.

Scope of this proposal

This version bump and note are prepared under #75, which proposes
v0.2.0-rc.4 as a plain successor candidate, not a canary. It scopes only
the version/release-note proposal itself and the current-document surfaces
that must stay accurate as a result. Preparation (tagging, native packaging,
draft assembly) and publication remain separate, later, separately authorized
steps. No source, workflow, or dependency change is in scope beyond what is
already on the default branch.

The inert, fail-only exact-tag canary hooks in scripts/release-canary.cjs
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.4, set either
value, add fault injection, or authorize a canary; a successor canary is a
separate focused change, per "Same-run recovery contract for a successor" in
../release-administration.md. A clean v0.2.0-rc.4 run therefore does
not satisfy the canary precondition in "After recovery is proven" in
../release-administration.md, and the GitHub immutable-releases rollout
gate stays open after rc.4.

What rc.4 closes that rc.3 could not

rc.3's tag is immutable, and every release workflow executes the code as of
the tag it was triggered from, so two real defects that shipped in published
rc.3 can never be fixed on that tag. Both corrections already landed on the
default branch and will be inside rc.4's tag:

• Cross-platform package verification. rc.3's Windows archive embeds CRLF
  copies of tracked text assets (app/css/main.css and LICENSE), so
  package:verify fails against it from a normal LF checkout, as recorded in
  rc.3's published known-limitation notice. .gitattributes normalization
  landed on the default branch and will be inside rc.4's tag, so a future
  rc.4 archive built from a normalized checkout is expected to verify from an
  LF checkout without that CRLF mismatch.
• Hosted post-publication verification. rc.3's tag predates
  scripts/release-verify-published.cjs and its workflow entirely, so that
  hosted verification path can never run against rc.3, also recorded in
  rc.3's known-limitation notice. v0.2.0-rc.4 will be the first candidate
  whose tag actually contains that script, so once rc.4 is separately
  tagged and published, the hosted post-publication verification workflow
  will be able to run against it for the first time.

Three further fixes are also on the default branch and will be inside rc.4's
tag, but they are failure-path guards that a clean run does not exercise, so
a clean rc.4 run does not prove them:

• retrying a stale post-create release list instead of failing closed on it;
• judging prepare-run success per attempt, rather than only by the latest
  attempt, when publication consults it; and
• refusing concurrent tag preparation and publication for the same tag.

This proposal does not claim any of those three behaviors as demonstrated;
demonstrating them requires the failure conditions they guard against, which
a plain successor candidate does not induce on purpose.

Readiness evidence and remaining gates

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

• The corrections described above are landed on protected master and are
  therefore available to a future rc.4 tag; they were not available to rc.3.
• The rc.1 and rc.2 incident dispositions, and rc.3's publication record, are
  recorded in ../release-administration.md.
• 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, and none of them is discharged by committing this file:

• Runner qualification for the exact rc.4 commit is a separate authorized
  protected-master dispatch; earlier qualification evidence for other
  commits 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.
• rc.4's own qualification, tag preparation, publication, and hosted
  post-publication verification are all still ahead of this proposal and each
  requires separate captain authorization; none of them has run for rc.4.
• 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; a plain rc.4 does not
  supply that evidence.
• Extracting a published Windows .zip archive needs a zip-capable archive
  tool: native Windows and macOS ship one, while a Linux host needs
  libarchive-tools/bsdtar installed as tar, since a stock GNU tar
  cannot read zip.

Planned assets (never built)

v0.2.0-rc.4 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.4-linux-x64-portable.tar.gz (unsigned)
• electris-v0.2.0-rc.4-win32-x64-portable.zip (unsigned)
• electris-v0.2.0-rc.4-release-manifest.json
• electris-v0.2.0-rc.4-SHA256SUMS.txt
• Qualification-only electris-v0.2.0-rc.4-darwin-arm64.zip and
  electris-v0.2.0-rc.4-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.

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.

Electris v0.1.2

Packaged using electron-packager with the package.json script package (e.g., by executing yarn package).

Electris v0.1.1

Packaged using electron-packager with the package.json script package (e.g., by executing yarn package).

Electris v0.1.0

Packaged using electron-packager.