v1.91.60.0 fix(windows): setup degrades instead of dying on a CSO failure, detects Smart App Control, Consolas terminal font (#3079)

* Fix spaced-out terminal text on Windows: put a Latin monospace before the CJK fallbacks

On Windows none of the Mac/Linux monospace fonts in the stack are
installed, so the first font that resolves is Malgun Gothic (the Windows
Korean UI font). xterm.js sizes its character cell from that font's
advance width, and Malgun Gothic advances Latin glyphs in a full-width
CJK cell — doubling every cell and rendering the whole terminal (and the
sidepanel mono UI) as spaced-out text.

Insert Consolas (present on every Windows install) and the Cascadia
faces ahead of the CJK fonts in both the xterm fontFamily and the
--font-mono CSS var. The CJK fonts stay last for actual CJK coverage.
No bundled font, no user install needed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GKj8Nr8T4GvryTcWBJRMyC

* fix(windows): every compiled binary answers --version before any side effect

browse --version started a server and exited 1, pdf printed usage and
exited 1, gstack-global-discover rejected the flag, and find-browse ran
discovery. A launch probe for Smart App Control (#2595) needs one
side-effect-free command that exits 0 on a healthy build, so browse,
find-browse, make-pdf and gstack-global-discover now answer --version
first (design already did).

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

* test(extension): pin Consolas ahead of the CJK fallbacks in both mono stacks (#2287)

Regression test for @tomfluff's fix: the xterm fontFamily and --font-mono
must list Consolas before Noto Sans Mono CJK KR and Malgun Gothic, or
Windows renders the sidebar terminal double-width.

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

* fix(cso): record each CSO build's outcome and stop arming the parent trap across the native publisher exec (#3071)

scripts/build-cso.sh now writes bin/.gstack-cso-build-result: result,
failed stage (build or publish), reason, this revision, the revision of
the generation still installed, whether its launcher is usable, and the
diagnostic log. An 'interrupted' entry is written before each stage so a
killed run is visible. A failed publish that restores the old generation
records it as still installed.

Before exec'ing the native publisher, the parent re-checks the locker,
clears its EXIT trap and enables execfail: the locked child's own trap
owns the stage. On Git Bash an exec of a native program may not replace
the shell, so the parent's trap could otherwise delete the stage under
the running child (the vanishing files in #3071; root cause unproven).
If the exec itself fails the parent cleans the stage and records it.

The Windows build prefers PowerShell 7 (pwsh) over Windows PowerShell
5.1, which crashed outright on the reporter's machine.

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

* fix(setup): an optional CSO build or publish failure no longer aborts setup (#3071)

CSO was optional at probe time but fatal at build time: scripts/build.sh
ran build-cso.sh under set -e before the browse server bundle and the
completion stamp, and setup exited when the CSO artifact set was
incomplete. A failed CSO step now prints 'CSO unavailable: the <stage>
step failed' with its log (bin/.gstack-cso-build.log) and retry, and the
build and setup finish. GSTACK_STRICT_BUILD=1 keeps it fatal; the free-tests,
make-pdf-gate and windows-setup-e2e builds set it, so regressions still
fail CI.

setup's summary reads the build-result record instead of the pre-build
availability flag: probe failures keep their prerequisite instruction;
build and publish failures name the stage, the diagnostic and
'bun run build:cso && ./setup', and a restored earlier helper is
reported as 'previous CSO kept: <revision>'. setup records probe
failures in the same file.

The Windows prerequisite probe prefers pwsh, and a probe that fails for
any reason other than a missing toolchain or a compile error keeps its
exit status and first output line (windows-toolchain-probe) instead of
being labeled windows-msvc-toolchain. Reported and diagnosed by
@dviolante.

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

* feat(windows): detect Smart App Control-blocked binaries in setup and gstack-doctor (#2595, #2124)

Smart App Control refuses the five unsigned binaries gstack compiles
locally, and Git Bash reports it as 'Permission denied', so setup's
[ -x ] gate passed and skills failed later. bin/gstack-launch-probe.sh
runs each binary's side-effect-free --version and classifies it:
native, blocked (spawn error, exit 126/127, or an application-control
message), broken (launched, exited non-zero) or missing. It shows the
raw first output line, since the exact Windows text is unverified.

On Windows, setup names each blocked binary and the skills that need it,
cites #2595, says which shell ran setup and whether WSL is installed,
gives today's workarounds (WSL, or turning Smart App Control off), how to
undo, and the new troubleshooting section. gstack-doctor's browse row now
says 'blocked at launch' instead of passing, a binaries row covers the
other four, and a cso row reads the build-result record.

windows-setup-e2e builds with GSTACK_STRICT_BUILD=1, checks all five
binaries answer --version, and adds two forced CSO failures: fatal under
strict mode, and a completed setup that reports the failure and a doctor
cso warning under GSTACK_STRICT_BUILD=0.

No shim or launcher: it could not be called from PowerShell and would
load the caller's project .env/bunfig. Signing is the follow-up in
TODOS.md. Diagnosis credit: @knetics9000 (#2595, #2596), @smartjelic-sys
(#2595), @pstilwell90 (#2124), @cko32002 (#2265), @salluexez (#2127).

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

* docs: Windows Smart App Control known issue, optional CSO failures, doctor rows

README's Windows section says /cso failures no longer stop setup
(GSTACK_STRICT_BUILD=1 keeps them fatal), documents Smart App Control as
a known issue with today's workarounds (WSL, or turning it off) and the
Consolas fix. troubleshooting.md gains a Windows section for blocked
binaries and an entry for CSO build/publish failures. TODOS.md replaces
the Node CLI lane item with Windows code signing (needs a signing
account), the #3071 root-cause follow-up and SAC text verification.

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

* fix(setup): never write the CSO build record into a source checkout that needed no build

Setup wrote bin/.gstack-cso-build-result for every probe-stage outcome,
so a run that built nothing still changed the source checkout's bin/
(caught by setup-codex-scope's unchanged-source checks). A missing
prerequisite now comes from the run's own probe, as before, and setup
only removes a stale record alongside the removed helper.
scripts/build-cso.sh remains the only writer. The doctor's cso row
reports 'native helper not built' with no record.

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

* test(extension): move the Consolas font-stack check into sidebar-ux (#2287)

The standalone file read extension sources without importing product
code, which the test-of-test ratchet rejects; sidebar-ux already owns
the sidepanel.css structural checks.

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

* v1.91.43.0 fix(windows): setup degrades instead of dying on a CSO failure, detects Smart App Control, Consolas terminal font

Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

---------

Co-authored-by: Yotam <yotsurfing@gmail.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>

docs/troubleshooting.md

@@ -26,8 +26,9 @@ section has a stable link anchor; the reason codes and anchors come from
 Run `~/.claude/skills/gstack/bin/gstack-doctor` (other hosts: `./setup --status`
 in your gstack checkout prints the doctor's absolute path). It prints one row
 each for the install, state root, Bun, hooks, Codex, the cached Codex model
-check, artifacts sync, the browse bundle, Claude Code, the largest session
-journal and recent /autoplan guard codes. Each row is `ok`, `warn`,
+check, artifacts sync, the browse bundle, the other compiled binaries, the
+/cso native helper, Claude Code, the largest session journal and recent
+/autoplan guard codes. Each row is `ok`, `warn`,
 `not configured` or `fail` with its fix; only `fail` exits non-zero. It makes
 no paid call: the Codex rows report the cached model check and its age, and
 `--live` runs that check once. Paste its output into bug reports.
@@ -762,6 +763,35 @@ Visual Studio".
 
 **Fix.** Fix the printed compiler error, then re-run `./setup`.
 
+<a id="cso-build-or-publish-failed"></a>
+### `CSO unavailable: the native helper's <stage> step failed (...)` / `CSO publish step failed (...) for <revision>; previous CSO kept: <revision>`
+
+**Meaning.** The /cso native helper is optional. Its build prerequisites were
+present, but the `build` step (compiling the helper) or the `publish` step
+(swapping the new helper into `bin/` under a lock) failed. setup used to stop
+here (#3071); now it finishes everything else and says which step failed. When
+an earlier helper was installed and the failed publish restored it, setup
+prints `previous CSO kept` and /cso keeps using that helper; otherwise /cso
+reports `not assessed`. `interrupted` means the step was killed before it could
+record a result. The outcome is in `bin/.gstack-cso-build-result`, and
+`gstack-doctor`'s `cso` row reads the same record. The build output is in
+`bin/.gstack-cso-build.log`.
+
+**Fix.** Read the log, fix what it reports, then retry from your gstack checkout:
+
+```bash
+bun run build:cso && ./setup
+```
+
+On Windows, setup and the build use PowerShell 7 (`pwsh`) when it is installed
+and fall back to Windows PowerShell 5.1. The root cause of the staged files
+vanishing during publish in #3071 is still unknown; attach the log there if you
+hit it. CI sets `GSTACK_STRICT_BUILD=1`, which makes these failures fatal so
+build regressions cannot hide.
+
+**Expected result.** setup prints no CSO line, and the doctor's `cso` row is
+`ok`.
+
 <a id="cso-windows-docker"></a>
 ### `Docker found at <path>, but native Windows Docker transport is not supported yet; static assessment only.` / `docker.exe at <path> is outside the trusted install locations (...)`
 
@@ -927,6 +957,45 @@ killed.
 
 ---
 
+## Windows
+
+<a id="windows-smart-app-control"></a>
+### `Windows blocked compiled gstack binaries at launch (Smart App Control or another application-control policy, #2595)` / `bash: .../browse.exe: Permission denied`
+
+**Meaning.** Known issue (#2595, #2124). gstack compiles five binaries on your
+machine with Bun: `browse`, `find-browse`, `design`, `pdf` and
+`gstack-global-discover`. They are unsigned, and a binary built on one machine
+never earns the reputation Smart App Control accepts instead of a signature, so
+Windows 11 with Smart App Control on refuses to start them. Git Bash reports
+that as `Permission denied`, which looks like a file-permission problem but is
+code integrity (PowerShell says `An Application Control policy has blocked this
+file`). setup now runs each binary's `--version` and names the blocked ones and
+the skills that need them: the gstack browser fallback (`/browse`, `/qa`,
+`/qa-only`, `/design-review`, `/canary`, `/benchmark`, `/pair-agent`,
+`/scrape`, `/make-pdf`), the design binary (`/design-consultation`,
+`/design-shotgun`, `/design-html`, `/plan-design-review`) and `/retro global`.
+Every other skill works. `gstack-doctor` shows the same state in its
+`browse bundle` and `binaries` rows. The exact Windows error text has not been
+verified on a Smart App Control machine; setup prints the raw first line beside
+its classification.
+
+**Fix.** There is no per-file allowlist for Smart App Control. Today's options:
+
+- Run gstack inside WSL (`wsl --install`, then install gstack in the Linux
+  distro). WSL runs gstack's Linux build, which Smart App Control does not check.
+- Or turn Smart App Control off in Windows Security > App & browser control >
+  Smart App Control settings. On Windows 11 with the April 2026 update you can
+  turn it back on later without reinstalling Windows; on older builds turning it
+  off is permanent. gstack's binaries stay blocked whenever it is on.
+
+Signed release binaries are the real fix and are tracked in `TODOS.md`. After
+Windows allows the binaries, re-run `./setup`; the message goes away.
+
+**Expected result.** setup prints no "Windows blocked" line, and
+`gstack-doctor` shows `ok` for `browse bundle` and `binaries`.
+
+---
+
 ## Memory and gbrain
 
 Every message below is also in [docs/gbrain-sync-errors.md](gbrain-sync-errors.md)