Nightly

One nightly.yml dispatch builds both platforms by default from one SHA and UTC stamp. platform=macos or platform=windows selects one. One rolling public nightly prerelease serves macOS DMGs, a signed Sparkle appcast, Windows x64 installers, and matching minisign signatures. Each platform keeps ten builds by stamp 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 [both|macos|windows] | check [both|macos|windows]] — no action means run; omitted platform means both.

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, including other platforms: gh run list --workflow nightly.yml --limit 30 --json databaseId,status,displayTitle,headSha. Stop if a run is not completed; all platforms share concurrency group nightly, so a dispatch cancels the entire older run.
   • CI for the SHA: gh run list --commit <sha> --workflow ci.yaml --limit 1 --json status,conclusion. Missing or completed without success → stop. Queued/in-progress is fine: the single publish job waits for CI and verifies its successful conclusion. Both macOS and Windows CI must pass even for a single-platform 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 both, or append -f platform=macos / -f platform=windows. 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: after successful verification, add a dated cut record to docs/impls/archive/504-nightly-channel-unification.md: selected platforms, commit-based identity, UTC stamp, run id, source SHA, and exact asset filenames/URLs. The release notes already carry the commits since the latest official release, so the record needs only a one-line summary. Keep prior records intact. Record installed upgrade/PC results only after observing them or receiving them from Jason. Follow AGENTS.md branch rules before editing; leave the record uncommitted unless the user explicitly requests commit/push.
6. Report: shared identity, run result, download links, changes included, and any installed-upgrade checks still pending. macOS nightlies can update through Sparkle; Windows nightlies use the in-app updater. Do not install or restart either 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. A both run applies to both platforms; 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 ten timestamped installers and ten DMGs independently. Require the shared notes from script/nightly-release-notes.md when checking the publish workflow; release notes cover installation and updates on both platforms. Sort by trailing YYYYMMDD.HHMM stamp, not by the version prefix. Both 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.
• 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.

Notes

• Nightlies are dispatch-only: a push to main runs CI alone. Nightlies need no crate-version bump or relationship to the next official version. One publish job validates selected artifacts, gates on CI once, 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 either 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 follows 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.