Good first issue — audit stale public-version references without rewriting historical evidence #124

Goal

Audit the public-facing documentation for stale statements that still describe Alpha.3/Alpha.4 as the current release after Alpha.5 publication.

Important boundary

Historical milestone, experiment, release, failure and outreach records must remain historically accurate. Do not rewrite a dated record merely because a later release exists.

Only change stale current-state wording where the document is intended to describe the present public product.

Scope

Review user-facing documentation and active issue templates for:

• stale current public release references;
• outdated install commands;
• stale stable-Action wording;
• links that bypass the current documentation index;
• text that could accidentally imply ARM64 support or independent external validation;
• duplicated current-state guidance that now belongs in docs/STATUS.md or docs/README.md.

Acceptance criteria

• Alpha.5 remains the current public release where current-state wording is intended;
• install examples use the exact prerelease version where required;
• stable Action remains AETHERXGLOBAL/execsurface@v0.1 and immutable Alpha.5 pin is documented accurately;
• Linux x86_64 remains the bounded public support scope;
• no historical failure, negative evidence or prior release chronology is deleted or rewritten;
• internal validation is not relabeled as independent external validation;
• all changed links resolve.

Suggested workflow

Before editing a stale-looking string, classify the file as either:

1. current operational guidance — update if stale; or
2. historical evidence — preserve, optionally add a clearly separated current-state note only when necessary.

Related: #118