Nightly

One nightly.yml dispatch builds macOS, Windows and Linux ARM64/x86_64 by default (platform=all) from one SHA and UTC stamp. platform=macos, platform=windows or platform=linux selects one platform family. Legacy platform=both retains macOS+Windows only. One rolling public nightly prerelease serves macOS DMGs, a signed Sparkle appcast, Windows x64 installers, matching minisign signatures, and Linux architecture-labelled tar/deb packages. Linux packages have matching minisign signatures and support verified in-app updates. macOS and Windows each keep two builds by stamp, and Linux keeps one build per architecture, independently on that release. Production feeds and releases/latest stay separate. Contract: docs/arch/arch.md §14 and docs/arch/windows.md.

An explicit request to run authorizes that workflow dispatch. Reading or editing this skill and check do not authorize dispatch. Nightly is a rolling development channel identified by its commit; official version tags are separate, and no nightly crate-version bump is needed. Commit, push, merge, tagging, direct release mutation, app launch/restart, and installation require the user's explicit instruction. Record only observed results; never invent a successful cut or a PC smoke result.

Usage

/nightly [run [all|both|macos|windows|linux] [preview] | check [all|both|macos|windows|linux] [preview]] — no action means run; omitted platform means all; preview selects the preview nightly (see Preview nightly).

run [platform]

1. Preflight — stop on any failure and report it.
   • git fetch origin; require branch main, a clean tree (git status --short empty), and git rev-parse main origin/main equal. Capture the full origin/main SHA. Do not push local commits without instruction.
   • Check for any queued or running nightly of the same channel, including other platforms: gh run list --workflow nightly.yml --limit 30 --json databaseId,status,displayTitle,headSha. Stop if such a run is not completed; all platforms share their channel's concurrency group (nightly or preview-nightly), so a dispatch cancels the entire older run of that channel. A run of the other channel does not block.
   • main's CI is not a gate (Jason, 2026-10-25): code reaches main only through pull requests whose required checks passed, and the publish job does not wait for CI. A later push to main cancelling that commit's CI run therefore cannot block a cut.
   • If the Runner MCP is reachable, report running missions from mission_list_summary. A successful cut can produce a nightly update offer and a Windows background download. Installation/restart remains a separate user action and interrupts live PTYs.
2. Dispatch: gh workflow run nightly.yml --ref main for all platforms, or append -f platform=macos / -f platform=windows / -f platform=linux (both is the legacy Mac+Windows selection). Find the new run with gh run list --workflow nightly.yml --branch main --limit 5 --json databaseId,status,headSha,displayTitle,createdAt; require the selected Nightly (<platform>) title, creation after dispatch, and headSha equal to preflight. If the source changed during dispatch, report the mismatch and do not claim the intended cut succeeded.
3. Watch: gh run watch <id> --exit-status. On failure, inspect gh run view <id> --log-failed and report the failing step. A failed/cancelled selected build prevents publication of both platforms on a both run. Failure or cancellation during publication can leave some files uploaded; report the cut incomplete and do not automatically retry.
4. Verify: run check for the selected platform(s), using this run's exact commit-based identity, stamp, and SHA. The shared identity is in prepare's build-identity outputs/log and the successful publication job summary. Require the whole run to have succeeded, not just one build job.
5. Record: nothing in docs/. The workflow run, the nightly tag and the release's assets and notes are the record of a cut; docs/impls/archive/504-nightly-channel-unification.md is the archived program record and keeps only its own first-cut section. Report installed upgrade/PC results only after observing them or receiving them from Jason.
6. Report: shared identity, run result, download links, changes included, and any installed-upgrade checks still pending. macOS nightlies update through Sparkle; Windows and Linux nightlies use their in-app updaters. Do not install or restart any app from this skill without explicit instruction.

check [platform]

This is read-only and does not dispatch. Read recent nightly.yml runs with gh run list --workflow nightly.yml --branch main --limit 10 --json databaseId,status,conclusion,headSha,createdAt,displayTitle. An all run applies to every platform; a legacy both run applies to macOS and Windows; a later single-platform cut may mean their assets now have different stamps on the same release. The nightly tag points at the last published cut, so git fetch origin refs/tags/nightly:refs/tags/nightly then git log nightly..origin/main --oneline describes what a new cut would pick up; the release notes list what the current cut has beyond the latest official release. A single-platform cut moves the tag too, so an unselected platform’s assets can be older than the tag: read their stamps from the filenames.

Read gh release view nightly --json isPrerelease,isDraft,assets once; require isPrerelease=true, isDraft=false, every selected platform’s expected filenames, and at most two timestamped installers and two DMGs independently. Require the shared notes from script/nightly-release-notes.md when checking the publish workflow; release notes cover installation and updates on all platforms. Sort by trailing YYYYMMDD.HHMM stamp, not by the version prefix. All apps display Nightly (<sha>), independently of the crate version. The UTC stamp orders artifacts and updates; the short commit identifies their source. For example, a Windows artifact identity is nightly.abc1234.20260908.0100.

• macOS / nightly: require Runner-Nightly-<sha>.<stamp>-arm64.dmg and appcast.xml. Check anonymous DMG access with curl --silent --show-error --fail --head --location <asset-url>; download and parse the appcast. Its single signed enclosure must point to that DMG at https://github.com/yicheng47/runner/releases/download/nightly/, with the expected stamp, seven-character commit as its short version, and arm64 hardware requirement. Sparkle supplies the app name in its native alert; Runner’s own update display is Nightly (<sha>). The release page is https://github.com/yicheng47/runner/releases/tag/nightly.
• Windows / nightly: require Runner-Setup-nightly.<sha>.<stamp>-x64.exe and its exact .sig; anonymous access must succeed for both at https://github.com/yicheng47/runner/releases/download/nightly/. Installers/signatures prune together. Portable ZIPs are retired. The release page is https://github.com/yicheng47/runner/releases/tag/nightly.
• Linux / nightly: require Runner_nightly.<sha>.<stamp>_linux-<x64|arm64>.tar.gz and .deb with an exact matching .sig for each package on both architectures; verify anonymous access for all four packages and four signatures. Keep only the newest stamp per architecture, pruning both formats and their signatures together. Linux-only cuts leave appcast and Windows installer/signatures untouched. Packages are signed with the updater trust key; validate package metadata/ELF architecture and consult docs/arch/linux.md for native validation gaps.
• Stable isolation: verify gh api repos/yicheng47/runner/releases/latest --jq .tag_name still identifies the current production release (0.8.2 when #502 was implemented), not a nightly. Do not report a real installed update or production Sparkle check as tested merely because release metadata is correct.

Preview nightly

An umbrella branch, which reaches main only when its program lands, gets installable test builds from the separate rolling preview-nightly release, so nightly keeps tracking main. The channel is reused by every umbrella; the current list is on.push.branches in .github/workflows/preview-nightly.yml, which holds the placeholder no-umbrella-branch while no umbrella is running. A new umbrella's branch replaces it.

• Automatic cut: every push to a listed branch that changes more than docs/** and **/*.md dispatches nightly.yml on that branch with channel=preview-nightly and platform=all. Missions land on an umbrella by fast-forward, so there is no merge commit to test as on main. A push event runs the workflow file of the pushed commit, so an umbrella is cut only once it contains preview-nightly.yml and the channel-aware nightly.yml: catch it up with main first.
• Opt in or out: add or remove the branch in that one list, in a pull request to main that the umbrella then picks up. The pull request that lands an umbrella on main removes its branch from the list in the same change; when it was the last one, that pull request deletes preview-nightly.yml instead, and the next umbrella restores it from history with its own branch. The workflow tests check the list's shape, not its entries, and skip the trigger checks while the file is absent, so neither change touches them. The prepare job reads the list from the dispatched commit and refuses preview-nightly from any branch not in it, including every branch when the file is absent or the list empty, and nightly from any branch but main. List exact branch names, not patterns: the guard matches names exactly.
• Manual run preview: the preflight captures git rev-parse origin/<umbrella> instead of requiring main; no local checkout of the umbrella is needed. Dispatch gh workflow run nightly.yml --ref <umbrella> -f channel=preview-nightly, plus -f platform=… for one platform family, and find the run with --branch <umbrella> and the title Preview Nightly (<platform>).
• Check: release and tag preview-nightly; macOS Runner-Preview-Nightly-<sha>.<stamp>-arm64.dmg and appcast.xml, Windows Runner-Setup-preview-nightly.<sha>.<stamp>-x64.exe and its .sig, Linux Runner_preview-nightly.<sha>.<stamp>_linux-<x64|arm64>.tar.gz and .deb with their .sigs, all under https://github.com/yicheng47/runner/releases/download/preview-nightly/, with the same retention as nightly. The notes end with script/preview-nightly-release-notes.md, the apps display Preview Nightly (<sha>), and git log preview-nightly..origin/<umbrella> --oneline describes what a new cut would pick up.
• Switching: preview builds share the app identity and data with every other channel and update only from preview-nightly. Installing a nightly or stable build by hand moves an install to that channel; on Linux, APT sees a nightly deb of the same release as a downgrade from a preview deb.

Notes

• nightly.yml is dispatch-only. nightly-on-merge.yml dispatches an all-platform nightly for each pull request merged into main that changes more than docs/ and Markdown files; a direct push to main runs CI alone, so a directly pushed code change needs a manual run. Nightlies need no crate-version bump or relationship to the next official version. One publish job validates selected artifacts, uploads the DMG before its appcast and the installer before its signature, checks public downloads, then prunes. All uploads target nightly, and one public verification reads that release before any platform prunes. A single-platform cut leaves the other platform’s assets/feed and retention untouched. An upload or download failure reports the cut incomplete and prevents all pruning.
• Nightly and production use com.wycstudios.runner / Runner.app on macOS and retain ~/Library/Application Support/com.wycstudios.runner/. Installing a nightly over Runner switches it to the nightly feed; installing a stable DMG switches it back. Windows and Linux follow the same install-to-switch rule. Public prereleases can be found by browsing, while production installs read their separate stable feed.
• One-time transition: Jason installs the first unified Mac DMG over Runner.app, then deletes Runner Nightly.app by hand; its old bundle id cannot update through Sparkle to the new one. The PC also needs a manual install because its existing build reads nightly-win. After the PC reads nightly, Jason deletes the old nightly-win release and tag by hand. There is no transition mirror; neither run nor check reads or writes that release. Dormant Windows installs reinstall from nightly after it is deleted. These manual steps still require explicit authorization.
• Production releases remain a different path: tag vX.Y.Z at a bare X.Y.Z crate version → release.yml builds a draft; publishing is the human's switch. Do not tag from this skill.