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.