2 Commits

Include renames

Author	SHA1	Message	Date
Garry Tanandcapy-ai[bot]	4b8c03bea9	v1.91.294.0 fix(doctor): cut Git Bash process starts so the doctor tests fit Windows CI (GSTA-138) (#3540) ... * perf(doctor): cut Git Bash process starts in doctor, hook-check and launch probe (GSTA-138) Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * fix: pre-landing review fixes The doctor's in-process config read reselected the state root after the doctor set GSTACK_STATE_ROOT, so --check and --json printed 'selected by GSTACK_STATE_ROOT' whatever selected the root. cfg now keeps _gstack_sr_var. Adds the regression test, a CRLF/blank/200-byte launch-probe detail test, and corrects the clamp comment. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * test: check the doctor cores row's test_backend by behavior, not the reader's spelling test/owner-brief-contributor-banned.test.ts pinned the literal 'gstack-config" get test_backend' in bin/gstack-doctor-check.sh, which the in-process cfg read removed (CI: quick-bun-default, free-suite 14). It now runs gstack-doctor --check --require cores against a state root holding test_backend: ubicloud and expects test_backend=ubicloud, with an empty state root as the negative control (test_backend=local). The under-8-cores wording pin stays. Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * chore: CHANGELOG [Unreleased] entry for the doctor's Windows process cuts Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> * chore: stamp v1.91.294.0 for #3540 Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com> --------- Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>	2026-10-28 13:05:02 +00:00
4 people	4dfd83bf8c	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>	2026-10-08 15:43:32 +00:00