[masarray]

User-facing goal

Landing-page Download buttons must deliver the newest publicly released Windows installer EXE and portable ZIP, not permanently pinned RC.5, and must not advertise the stable release that is still being built in the other workstream.

Implementation

• Add one shared, lightweight release-download.js for English + Indonesian landing, Download and FAQ pages.
• Resolve GitHub REST public Releases on page load, selecting the most recently published non-draft, complete release containing a matching Windows installer, ZIP, SHA256 checksums and SPDX SBOM. Stable and prerelease are supported and kept distinct; a half-uploaded release is never promoted.
• Change the lower landing and FAQ primary Download buttons from release-page navigation to direct portable ZIP links; main hero buttons and Download page remain direct EXE/ZIP.
• Refresh release tag, stable link, displayed version, file names and SoftwareApplication metadata in-place. Preserve existing page visuals and language-specific controls.
• Keep actual published RC.5 asset URLs as working fallback if GitHub API is unavailable (no broken guesses).
• Synchronize the docs/ compatibility mirror with canonical site/; do not touch protocol engine or the in-progress stable packaging workflow.

Release isolation

This change does not create/publish v3.6.8, advance version numbers or modify the separate #185 stable packaging fix. As soon as stable v3.6.8 is successfully published with all required assets, the same deployed page will resolve it without another hard-coded URL update.

Verification

• Current public release asset inventory resolves v3.6.8-rc.5 (the newest complete published package at preflight).
• All five canonical HTML pages and mirrors contain the dynamic resolver; lower landing/FAQ CTAs use public binary ZIP, not source ZIP or Actions temporary artifact.
• Existing repository release-channel/fallback test continues to see the currently published RC.5; no false stable publication claim.
• CI/Pages workflows should validate this pages-only change without redundant manual Windows builds.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-12T04:49:36.060118Z	88fdac3	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 88fdac36cc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Apply the complete-package gate to stable release links

When a newly published stable release contains the ZIP, checksums and SBOM but its installer is still missing, inspect() includes it in packages, so this predicate selects it despite the completeness check used for current. Reproducing that response with v3.6.8 and a complete RC.5 leaves the primary downloads on RC.5 but changes the Download and FAQ stable links to advertise v3.6.8. Require the installer for the stable selection too, so an incomplete stable release is not promoted through the secondary release channel.

Useful? React with 👍 / 👎.