Conversation
…ols + fork-origin migration Three Windows install fixes surfaced by a live operator install: 1. Build-tools detection: `where cl.exe` only succeeds inside a "Developer PowerShell for VS" — a normal PowerShell reports the tools missing even when installed, causing false mid-install failures. Fall back to vswhere (fixed installer location) to detect the VC++ toolset regardless of PATH; a vswhere hit is what node-gyp uses too. 2. AUTO_BUILD_TOOLS auto-install: replace the deprecated, Node-24-broken `npm install -g windows-build-tools` with the supported `winget install Microsoft.VisualStudio.2022.BuildTools --add VCTools`. Manual instructions updated to match. 3. Fork-origin migration: an in-place re-run of a manually forked+cloned tree (origin = <you>/ascendops-install) was not recognized — only canonical origins were. Detect a fork by repo-name and add canonical as "upstream" (keeping origin = fork), matching the gh-fork end state so pulls and contribute-back work. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…— 0 windows-build-tools refs The post-install C++-compilation-error fallback still recommended the deprecated `npm install -g windows-build-tools` (broken on Node 24) — the same dead package this PR replaced on the active detection/auto-install path. Switch that hint to the winget VS 2022 Build Tools / VCTools command so the installer never points a failing user at the abandoned package anywhere. No windows-build-tools references remain. node --check clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
noogalabs
added a commit
that referenced
this pull request
Jun 14, 2026
…concile fork-origin onto post-rename repo name (#3) Reconciles the field-proven Windows installer fix (PR #1, fix/windows-install-mjs, which got Foothills PM running) onto current main, and adds the Windows guide (PR #2, docs/windows-install-guide). install.mjs: - Replace the dead `npm install -g windows-build-tools` path (package deprecated/ removed) with vswhere DETECTION + `winget install Microsoft.VisualStudio.2022. BuildTools` install. vswhere finds the toolset even when cl.exe isn't on PATH (the false "build tools missing" failure mid-install). - Drop the redundant `cl.exe /?` probe; keep `where cl.exe` + vswhere fallback. - Update the final C++-error hint (was L613) to the winget command. - Adopt PR #1's richer isCanonicalOrigin / isForkOrigin fork-migration logic, reconciled to the POST-RENAME canonical name noogalabs/ascendops (PR #1 was authored pre-rename and referenced noogalabs/ascendops-install). Guides (WINDOWS-INSTALL.md, PRE-CALL-CHECKLIST.md): install URLs updated to the canonical noogalabs/ascendops name. Mac and Linux code paths are byte-untouched (verified: outside the Windows build-tools hunk and the fork-origin hunk, the file is identical to main). node --check passes. Co-authored-by: David Hunter <davidhunter@Davids-Mac-mini.local> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
noogalabs
added a commit
that referenced
this pull request
Jun 16, 2026
…x overnight CI flake) (#8) Two fixtures hardcoded absolute early-UTC timestamps for events meant to sit BEFORE the build cutoff (which is `now`): - 'consume archives event-only candidates' used ${today}T08:00:00Z - TOCTOU sibling used ${today}T01:00:00Z When CI runs before those hours (00:00-08:00Z window), the event is future-of-now, so the cutoff filter (ev.timestamp <= now, forge-candidates.mjs:322) excludes it, the archive/queue comes back empty, and the assertions fail — a time-bomb that red-flags every overnight PR (e.g. #7 tonight). 156/158 pass; only these 2. Make both fixtures `new Date(Date.now() - 60_000).toISOString()` — strictly past of the cutoff at every wall-clock hour, hour-independent. Incident labels (PR #9/#1 ${today}) are unchanged; the assertions key on those. Mirrors the relative-time discipline the racing-event fixture (L234) already uses. Validated: vitest forge-candidates.test.ts now 19/19 (was 17/19), run inside the 00:00-08:00Z failure window. Co-authored-by: David Hunter <davidhunter@Davids-Mac-mini.local> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DRAFT — HOLD MERGE, review-gated to David. Overnight sprint item #2.
Three Windows install fixes from the live operator install:
where cl.exeonly works inside Developer PowerShell for VS; a normal PowerShell falsely reported tools missing mid-install. Now falls back to vswhere (detects the VC++ toolset regardless of PATH, same mechanism node-gyp uses).npm install -g windows-build-toolswith supportedwinget install Microsoft.VisualStudio.2022.BuildTools --add VCTools.<you>/ascendops-install) wasn't recognized; now detected by repo-name and wired with canonical asupstream.Validation:
node --checkpasses; leak-gate clean (0 markers). Not Windows-runtime-tested in this session — recommend one live Windows re-run before merge.🤖 Generated with Claude Code