feat(providers): add GitHub Copilot community provider (@github/copilot-sdk)

.archon/workflows/defaults/archon-adversarial-dev.yaml

@@ -101,7 +101,9 @@ nodes:
         "status": "running"
       }
       STATEEOF
-      sed -i "s/SPRINT_COUNT_PLACEHOLDER/$SPRINT_COUNT/" "$ARTIFACTS/state.json"
+      STATE_TMP="$ARTIFACTS/state.json.tmp"
+      sed "s/SPRINT_COUNT_PLACEHOLDER/$SPRINT_COUNT/" "$ARTIFACTS/state.json" > "$STATE_TMP"
+      mv "$STATE_TMP" "$ARTIFACTS/state.json"
 
       echo "{\"totalSprints\": $SPRINT_COUNT, \"appDir\": \"$ARTIFACTS/app\", \"artifactsDir\": \"$ARTIFACTS\"}"
     timeout: 30000

.archon/workflows/e2e-copilot-smoke.yaml

@@ -0,0 +1,32 @@
+# E2E smoke test — GitHub Copilot community provider
+# Verifies: provider registration, SDK session start, simple prompt response.
+# Auth: run `copilot login`, or provide COPILOT_GITHUB_TOKEN / GH_TOKEN / GITHUB_TOKEN.
+name: e2e-copilot-smoke
+description: 'Smoke test for the GitHub Copilot community provider.'
+provider: copilot
+model: gpt-5-mini
+
+nodes:
+  - id: simple
+    prompt: 'Reply with exactly COPILOT_OK'
+    idle_timeout: 30000
+
+  - id: assert
+    bash: |
+      # The workflow engine substitutes $simple.output as a literal string
+      # before bash runs. Wrap in single quotes so command substitution
+      # (`$(...)`, backticks) inside a model response is treated as data,
+      # not executed. A literal `'` in the value would cause a syntax
+      # error, which fails the test loudly rather than running arbitrary
+      # shell — strict improvement over double-quoted interpolation.
+      output_raw='$simple.output'
+      if [ -z "$output_raw" ]; then
+        echo "FAIL: simple node returned empty output"
+        exit 1
+      fi
+      printf '%s\n' "$output_raw" | grep -F -q -- 'COPILOT_OK' || {
+        printf 'FAIL: expected COPILOT_OK, got: %s\n' "$output_raw"
+        exit 1
+      }
+      printf 'PASS: simple=%s\n' "$output_raw"
+    depends_on: [simple]

.claude/skills/release/SKILL.md

@@ -42,6 +42,67 @@ git fetch origin main
 
 If not on dev or working tree is dirty, abort with a clear message.
 
+### Step 1.5: Pre-flight compiled-binary smoke test (MANDATORY before any other step)
+
+> **Why this is first**: releases have ended up with zero working binaries because a module-init crash or bundler bug only surfaces in `bun build --compile` output, not in `bun run`. CI catches it — but only AFTER the tag is pushed and a GitHub Release is created. By then the damage (empty release, broken `releases/latest`, broken `install.sh`) is already live. Failing here, before any user-visible change, keeps the blast radius at "no release was cut."
+
+Run locally on the native target. This takes ~15-30s and is cheaper than discovering the problem after tag+release.
+
+```bash
+# Guard: only run this for Node/Bun projects with a CLI entry point + build-binaries script.
+if [ -f scripts/build-binaries.sh ] && [ -f packages/cli/src/cli.ts ]; then
+  TMP_BINARY=$(mktemp)
+  trap "rm -f $TMP_BINARY" EXIT
+
+  # Compile for the native target only (not full cross-compile — that's CI's job).
+  # Match the real release flags so any bundler quirk reproduces locally.
+  bun build \
+    --compile \
+    --minify \
+    --target=bun \
+    --outfile="$TMP_BINARY" \
+    packages/cli/src/cli.ts
+
+  # Smoke test: the binary must start and exit 0 on a safe, non-interactive command.
+  # Use `--help` (NOT `version`). The `version` command's compiled-binary code
+  # path depends on BUNDLED_IS_BINARY=true, which is set by scripts/build-binaries.sh
+  # — but we're doing a bare `bun build --compile` here to keep the smoke fast,
+  # so BUNDLED_IS_BINARY is still `false`. That sends `version` down the dev
+  # branch of version.ts which tries to read package.json from a path that only
+  # exists in node_modules, producing a false-positive ENOENT. `--help` has no
+  # such dev/binary branch and exercises the same module-init graph we're
+  # actually testing. Must NOT touch network, database, or require env vars.
+  if ! "$TMP_BINARY" --help > /tmp/archon-preflight.log 2>&1; then
+    echo "ERROR: compiled binary crashed at startup"
+    cat /tmp/archon-preflight.log
+    echo ""
+    echo "This usually means a dependency has a module-init-time side effect that"
+    echo "fails in a compiled binary context (readFileSync of a path that only"
+    echo "exists in node_modules, etc.). Fix before cutting the release — do NOT"
+    echo "proceed to version bump."
+    exit 1
+  fi
+
+  # Also grep for known crash markers that exit 0 but print a fatal error
+  # (some module-init errors are caught by top-level try/catch but still log).
+  if grep -qE "Expected CommonJS module|TypeError:|ReferenceError:|SyntaxError:" /tmp/archon-preflight.log; then
+    echo "ERROR: compiled binary emitted a runtime error despite exit 0"
+    cat /tmp/archon-preflight.log
+    exit 1
+  fi
+
+  echo "Pre-flight binary smoke: PASSED"
+fi
+```
+
+If this fails, **abort the release entirely** — do not bump version, do not modify CHANGELOG, do not create a PR. Surface the error to the user, point at the failing output, and stop. Recovery is: fix the bundler / dependency issue on a feature branch, merge to dev, re-run `/release`.
+
+**Common failure modes this catches:**
+- Bun `--bytecode` flag producing broken bytecode for the current module graph
+- A dependency (e.g. an SDK) reading `package.json` or other files at module top level via paths that resolve fine in `node_modules/` but not next to a compiled binary
+- Circular imports that break under minification but work under plain `bun run`
+- A newly added package that ships CJS with an unusual wrapper shape
+
 ### Step 2: Detect Stack and Current Version
 
 Detect the project's package manager and version file:
@@ -211,21 +272,53 @@ After the tag is pushed, `.github/workflows/release.yml` builds platform binarie
 
 ```bash
 echo "Waiting for release workflow to finish uploading binaries..."
+WORKFLOW_FAILED=0
 for i in {1..30}; do
   ASSET_COUNT=$(gh release view "vx.y.z" --repo coleam00/Archon --json assets --jq '.assets | length')
   # Expect 7 assets: 5 binaries (darwin-arm64, darwin-x64, linux-arm64, linux-x64, windows-x64.exe) + archon-web.tar.gz + checksums.txt
   if [ "$ASSET_COUNT" -ge 7 ]; then
     echo "All $ASSET_COUNT assets uploaded"
     break
   fi
+
+  # Short-circuit: if the release workflow itself has failed, stop waiting.
+  # Hanging for 15 min when CI already crashed just delays the recovery path.
+  WORKFLOW_STATUS=$(gh run list --workflow release.yml --event push --limit 1 --json conclusion,status --jq '.[0] | "\(.status)|\(.conclusion)"')
+  if [[ "$WORKFLOW_STATUS" == "completed|failure" ]]; then
+    echo "Release workflow FAILED — no point waiting longer"
+    WORKFLOW_FAILED=1
+    break
+  fi
+
   echo "  Assets so far: $ASSET_COUNT/7 — waiting 30s (attempt $i/30)..."
   sleep 30
 done
 
-if [ "$ASSET_COUNT" -lt 7 ]; then
-  echo "ERROR: Release workflow did not finish uploading assets after 15 minutes"
-  echo "Check https://github.com/coleam00/Archon/actions for the release workflow run"
-  exit 1
+if [ "$WORKFLOW_FAILED" -eq 1 ] || [ "$ASSET_COUNT" -lt 7 ]; then
+  # Triage: rerun once in case it's transient, then check again.
+  RUN_ID=$(gh run list --workflow release.yml --event push --limit 1 --json databaseId --jq '.[0].databaseId')
+  echo "Release workflow failed on run $RUN_ID. Rerunning failed jobs once to confirm..."
+  gh run rerun "$RUN_ID" --failed
+  gh run watch "$RUN_ID" --exit-status --interval 30 || true
+
+  # Re-check asset count + run status after rerun.
+  ASSET_COUNT=$(gh release view "vx.y.z" --repo coleam00/Archon --json assets --jq '.assets | length')
+  if [ "$ASSET_COUNT" -ge 7 ]; then
+    echo "Rerun succeeded — all assets now present"
+  else
+    echo ""
+    echo "===== DETERMINISTIC CI FAILURE ====="
+    echo "The release workflow failed on two consecutive runs. This is NOT a flake."
+    echo "The tag and release exist but have no (or incomplete) assets."
+    echo ""
+    echo "install.sh and similar 'releases/latest' paths are now 404-ing."
+    echo "Proceeding with Homebrew/tap sync would publish a formula pointing at"
+    echo "missing or inconsistent binaries."
+    echo ""
+    echo "Jump to the 'Recovery: deterministic release CI failure' section at the"
+    echo "bottom of this skill and execute it. Do NOT continue past this point."
+    exit 1
+  fi
 fi
 ```
 
@@ -376,9 +469,81 @@ Also run `/test-release curl-mac x.y.z` to cover the curl install path. The two
 
 If you have a VPS available, also run `/test-release curl-vps x.y.z <vps-target>` to verify the Linux binary.
 
+## Recovery: deterministic release CI failure
+
+Reached here because Step 10 detected two consecutive workflow failures. The tag `vx.y.z` is pushed, the GitHub release exists, but assets are missing or incomplete. Every `install.sh` run currently resolves `releases/latest` to this broken release and 404s on download. Homebrew users are safe because Step 10's atomic formula update was blocked.
+
+**Do not re-run the release workflow a third time hoping it succeeds.** If the failure was reproducible twice, it's a code bug — you need to ship code to fix it.
+
+### Immediate mitigation (restore `install.sh`)
+
+Delete the GitHub Release so `releases/latest` falls back to the previous version. Keep the git tag — tag immutability matters and there are no shipped artifacts pointing at it anyway.
+
+```bash
+gh release delete "vx.y.z" --yes
+# Do NOT delete the tag:
+#   git push --delete origin vx.y.z   ← do not run
+# Tag stays so git history records the attempt; no release means no assets
+# means releases/latest resolves to the prior working release.
+```
+
+Verify:
+
+```bash
+gh api repos/coleam00/Archon/releases/latest --jq '.tag_name'
+# should now print the prior version (e.g. v0.3.6), not vx.y.z
+```
+
+### Diagnose
+
+The release workflow logs tell you which target failed and at what stage (compile vs. smoke-test vs. upload):
+
+```bash
+gh run list --workflow release.yml --limit 2 --json databaseId,conclusion
+gh run view <RUN_ID> --log-failed
+```
+
+Common causes:
+- **Bundler/bytecode bug** — Bun `--bytecode` produces invalid output for the current module graph. Symptom: `TypeError: Expected CommonJS module to have a function wrapper` at binary startup. Historically caused by a new dependency's CJS/ESM shape interacting with `--bytecode` — dropping the flag or lazy-importing the offending module has been the fix.
+- **Module-init crash** — a dependency does `readFileSync('package.json')` or similar at module top level via a path that exists in `node_modules/` but not next to a compiled binary. Symptom: every binary subcommand crashes immediately; error typically mentions a missing file adjacent to `process.execPath`. Fix by lazy-importing the dependency behind the code path that actually uses it.
+- **Smoke-test timeout on Windows** — not actually a bug in the code; the Windows runner is slow. Rerun once; if it recurs, bump the test timeout.
+
+Step 1.5 now runs a local compiled-binary smoke test before any user-visible step. If the failure mode above reproduces locally, you've found it. If it doesn't, the bug is platform-specific (Windows cross-compile, Linux glibc, etc.) and you need the CI logs.
+
+### Fix and re-release as the NEXT patch
+
+**Do not reuse `vx.y.z`.** Cut `vx.y.(z+1)` (or next-minor if warranted) with the fix. Rationale:
+- Tag immutability: `vx.y.z` is already recorded in git history and release cache
+- Semver clarity: users and tooling should see a new version number when the bits change
+- Audit trail: "v0.3.7 was cut but had no shipped binaries; v0.3.8 is the first release with <fix>" is cleaner than rewriting v0.3.7
+
+Steps:
+
+1. Cut a fix branch off dev, implement the fix, PR to dev, merge.
+2. Re-run `/release` (it will bump to the next patch — e.g. `0.3.8` — automatically).
+3. Step 1.5's pre-flight smoke will catch the same bug locally if the fix didn't actually fix it. Iterate until it passes before tagging.
+
+### CHANGELOG note for the hotfix release
+
+Include a line in the new release's CHANGELOG that references the broken prior version so users understand why there's no binary artifact under that tag:
+
+```markdown
+### Fixed
+
+- **First release with working compiled binaries after vx.y.z's <bug>.** vx.y.z was tagged but its binary smoke test failed deterministically (see RUN_ID in CI history). The tag is preserved for history; this release (vx.y.(z+1)) is the first with shipped binaries. `install.sh` and Homebrew were never updated to vx.y.z, so users were not exposed to the broken state.
+```
+
+### What NOT to do
+
+- **Do not force-push or rewrite the tag.** Once a tag exists, it's a public promise of that SHA. Deleting and re-creating to a different SHA is tag-spoofing and breaks any downstream that cached the original.
+- **Do not skip this recovery path to "just push more binaries to the broken release".** The release exists with a specific commit SHA; uploading binaries built from a newer SHA creates binary/source drift that is hard to diagnose later.
+- **Do not update the Homebrew formula before v0.3.(z+1) is fully shipped.** The formula should always point at a version with all 7 assets uploaded and `/test-release brew` passing.
+
 ## Important Rules
 
 - NEVER force push
+- **NEVER skip Step 1.5 (pre-flight compiled-binary smoke).** If the stack is a Bun/Node project with a build-binaries script, the `bun build --compile` smoke test runs before version bump, PR, or tag. Skipping it means every bundler regression or module-init crash only surfaces after the tag is pushed — by which point `releases/latest` is already 404-ing for every user. The ~30s cost is paid to keep the failure mode local.
+- If Step 1.5 fails, **abort the release** and fix the underlying issue on a feature branch. Do not "just skip it" and hope CI doesn't repro the problem.
 - NEVER skip the review step — always show the changelog before committing
 - NEVER include "Co-Authored-By: Claude" or any AI attribution in the commit
 - NEVER add emoji to changelog entries unless the user asks

.claude/skills/test-release/SKILL.md

@@ -79,6 +79,8 @@ About to test:
   Path:     brew (Homebrew tap on macOS)
   Version:  0.3.1 (expected)
   Cleanup:  will uninstall after tests (brew uninstall + untap)
+            If `archon-stable` symlink is detected in Phase 2, it will be
+            restored at the end of Phase 5 by reinstalling the tap formula.
 
 Proceed? (y/N)
 ```
@@ -112,6 +114,18 @@ gh release view v<version> --repo coleam00/Archon --json tagName,assets --jq '{t
 
 If the release does not exist or has no assets, abort with a clear message. Do not proceed to install a non-existent release.
 
+4. **Detect persistent `archon-stable` install (brew path only).** If the user has renamed a prior brew install to `archon-stable` (the dual-homebrew pattern — see `~/.config/fish/functions/brew-upgrade-archon.fish`), Phase 5's `brew uninstall` will wipe it. Capture the state so Phase 5b can restore it:
+
+```bash
+ARCHON_STABLE_WAS_INSTALLED=""
+if [ -L /opt/homebrew/bin/archon-stable ] || [ -L /usr/local/bin/archon-stable ]; then
+  ARCHON_STABLE_WAS_INSTALLED="yes"
+  echo "Detected persistent archon-stable — will restore after Phase 5 uninstall."
+fi
+```
+
+Export `ARCHON_STABLE_WAS_INSTALLED` into the environment used by Phase 5b. Only applies to the `brew` path — `curl-mac` and `curl-vps` don't go through brew and don't disturb `archon-stable`.
+
 ## Phase 3 — Install
 
 ### Path: brew
@@ -352,6 +366,25 @@ archon version | head -1
 # should match the dev version captured in Phase 2
 ```
 
+**Restore `archon-stable` if it existed before the test** (dual-homebrew pattern — see Phase 2 item 4):
+
+```bash
+if [ -n "$ARCHON_STABLE_WAS_INSTALLED" ]; then
+  echo "Restoring archon-stable (detected before test)..."
+  brew tap coleam00/archon
+  brew install coleam00/archon/archon
+  BREW_BIN="$(brew --prefix)/bin"
+  if [ -e "$BREW_BIN/archon" ]; then
+    mv "$BREW_BIN/archon" "$BREW_BIN/archon-stable"
+    echo "archon-stable restored: $(archon-stable version 2>/dev/null | head -1)"
+  else
+    echo "WARNING: brew install succeeded but $BREW_BIN/archon missing — check formula"
+  fi
+fi
+```
+
+> **Note on the restored version**: this reinstalls from whatever the tap currently ships, which is typically the release you just tested (so `archon-stable` ends up at the newly-tested version). That's usually what the operator wants — you just verified the new release works, and you want `archon-stable` pointed at it. If you were testing an older version for back-version QA, the restored `archon-stable` will be the *current* tap formula, not the pre-test version. For that rare case, the operator should re-run `brew-upgrade-archon` manually after the test.
+
 ### Path: curl-mac
 
 ```bash

.github/workflows/release.yml

@@ -138,8 +138,12 @@ jobs:
 
           # Run without CLAUDE_BIN_PATH set. Expect a clean resolver error.
           # Capture both stdout and stderr; we only care that the resolver message is present.
+          # --no-worktree skips isolation: this test exercises the Claude resolver
+          # path, not worktree setup. Without it we hit the worktree auto-sync added
+          # in #1310 first and fail on "neither origin/HEAD nor origin/main exist"
+          # because the fresh `git init` tmp repo has no origin configured.
           set +e
-          OUTPUT=$(env -u CLAUDE_BIN_PATH "$BIN" workflow run archon-assist "hello" 2>&1)
+          OUTPUT=$(env -u CLAUDE_BIN_PATH "$BIN" workflow run archon-assist --no-worktree "hello" 2>&1)
           EXIT_CODE=$?
           set -e
           echo "$OUTPUT"
@@ -181,8 +185,10 @@ jobs:
           git init -q
           git -c user.email=ci@example.com -c user.name=ci commit --allow-empty -q -m init
 
+          # --no-worktree: same rationale as the negative-case test above — this
+          # test exercises the Claude subprocess spawn path, not worktree setup.
           set +e
-          OUTPUT=$(CLAUDE_BIN_PATH="$CLI_PATH" "$BIN" workflow run archon-assist "hello" 2>&1)
+          OUTPUT=$(CLAUDE_BIN_PATH="$CLI_PATH" "$BIN" workflow run archon-assist --no-worktree "hello" 2>&1)
           EXIT_CODE=$?
           set -e
           echo "$OUTPUT"