3 Commits

Include renames

Author	SHA1	Message	Date
Neil	e217fdd10f	build(orcad): gate orcad's own graph, and prove it loads under plain Node (#16368) ... * fix(orcad): close the browser-provider gaps The providers landed without enforced coverage, so a regression in either path would have landed silently. - CI: the external-Chromium integration test was gated on ORCA_BROWSER_EXECUTABLE and nothing ever set it, so it skipped forever. It now runs in its own job against the runner's Chrome and FAILS when Chrome is absent rather than skipping, because an unset variable is exactly how it went uncovered. Timeout raised to 120s: a warm run is ~7s but the first launch against an unseeded profile took 30s and hit Vitest's default, and CI is always that cold case. - Electron provider had no test at all. It is the path anyone with the desktop app hits. - Browser unavailability reported one message for four causes, including telling an operator to set a variable they had already set. Fixes a live defect found while covering it: the runtime advertises browser.tabCreate.known-id.v1 unconditionally, so a web client sends a provisional page id for a page that does not exist yet — and the sidecar's generic requestedPageId branch ran require() on it first and threw. Every known-id create against the Electron provider failed. The adoption logic was already there; only the ordering was wrong. Also updates the workflow-parallelism guard, which correctly caught the new job missing from verify's required-check list, and asserts verify actually reads it. * build(orcad): gate orcad's own graph, and prove it loads under plain Node Two gaps the artifact's own comment asked for. The ratchet measured only orca-runtime + runtime-rpc, but orcad imports ipc/pty directly to install the PTY controller, so its graph is strictly larger. The gate could read zero while the shipped artifact regressed. orcad's entry is now a ratchet entry point, and the baseline stays empty with it included. orcad cannot join plain-node-entry-guard — that is a rollup plugin keyed on electron-vite input names, and orcad is an esbuild artifact. But the half that matters here is the guard's smoke-load: scanning the metafile proves no module NAMES electron, not that the graph resolves under plain Node. A dynamic require, a missing native or a top-level throw all pass the scan and fail at runtime. build-orcad now runs the bundle with a bogus flag and requires the argv rejection that only a fully loaded graph can produce. Verified: a bundle that builds but throws on load fails the gate.	2026-08-24 22:21:26 -07:00
Neil	03fcfdfb92	feat(orcad): boot the Orca runtime on plain Node (#15968) ... * refactor(host): resolve the app root through the port in fork-reachable modules `parcel-watcher-entry-path.ts` and `session-scanner-service-entry-path.ts` read the app root via `require('electron').app` inside a try/catch that already returns null when Electron is absent. They were therefore correct under plain Node at runtime and only failed the *static* text check — which is real, not pedantic: the comment in `ports/port-scan-command-client.ts:19` records that the plain-node-entry-guard fails on that literal text, try/catch or not. `hasAppEnvironment() ? getAppEnvironment() : null` gives the identical "no app root here" answer without the text. That restores `hasAppEnvironment`, which an earlier commit in this stack deleted as unused — it now has the caller it was waiting for. Ratchet baseline 27 → 25. Verified: 74 files / 458 tests; `pnpm typecheck` clean; `oxlint` clean. * feat(orcad): boot the Orca runtime on plain Node Closes the last two Electron couplings and makes `orcad` a working artifact: a 4.43 MB Node bundle that boots, pairs, registers a repo, creates a real git worktree and round-trips a PTY — with zero `require("electron")`. Ratchet 2 -> 0, so `config/runtime-electron-baseline.txt` is now empty and its test asserts exactly that: any reachable electron import is a regression. - speech: inject the service factories, so importing ModelManager for its type no longer drags Electron's streaming net.request into the graph - filesystem-watcher: add a WorktreeWatcherRemoval port. Every entry in those maps arrives through an ipcMain handler carrying a renderer sender, so a host with no renderer has nothing to close, restore or forget — the inert default is what the desktop code does against empty maps, not a stub hiding work - user-data-path / profile-storage-paths: resolve userData through AppEnvironment. These surfaced only once orcad pulled the store in Both host ports now anchor to a realm-global symbol. `vi.resetModules()` gives the re-imported graph a fresh module copy, so a binding installed before the reset silently read back as uninstalled. The acceptance smoke drives both hosts through one code path (`--target orcad|electron`) and seeds its own git repo, so it is hermetic and asserts the same contract of each. Wired into PR CI. * test(smoke): remove the seeded workspace container, not just the worktree * test(smoke): surface the server's stderr when it dies before ready * fix(smoke): build node-pty for Node before booting orcad in CI * fix(smoke): drive the CLI built from this checkout, not one on PATH * docs(ratchet): say the baseline must stay empty, not merely shrink * build(orcad): externalize only the native modules actually in the graph	2026-08-22 21:47:46 -07:00
Neil	cbea7530b4	build(runtime): gate new Electron imports reachable from the Orca runtime (#15919) ... * build(runtime): gate new Electron imports reachable from the Orca runtime The runtime is meant to become host-agnostic so it can also run on plain Node, but nothing enforced that. `orca-runtime.ts` reaches dozens of modules that import `electron`, and the count grows silently: the import that breaks portability is usually several hops away, so no reviewer sees the edge. Add a reachability ratchet, modelled on the existing max-lines one. It bundles the runtime and its RPC server with esbuild, reads the metafile for every module importing `electron`, and diffs that against a checked-in baseline. A new module fails; a removed one forces the baseline to tighten. The list may only shrink. A per-file lint rule cannot do this — the point is precisely the transitive edges — so this runs as a build gate in `pnpm lint`. Baseline starts at 36, down from 50 before the SecretStore and AppEnvironment ports landed, which is the migration made measurable. Verified: gate passes clean, fails with an actionable message when an `electron` import is added to a runtime module, and passes again when reverted. * fix(runtime-ratchet): resolve paths from the script, not the caller's cwd Run from anywhere but the repo root, the gate died with an unhandled ENOENT stack instead of a usable message. It failed closed, so it was never unsafe — just undebuggable. Anchor ROOT to import.meta.dirname and pass absWorkingDir to esbuild so metafile keys stay repo-relative. * ci(runtime-ratchet): actually run the gate in CI The ratchet was wired into the `lint` npm script, but CI's static-analysis job runs the individual checks rather than `pnpm lint`, so the gate would never have fired on a PR — it would have looked enforced while enforcing nothing. Runs on ubuntu-latest alongside the max-lines ratchet, so the checked-in baseline is only ever produced by one platform. * fix(runtime-ratchet): mark native addons external so CI can run the gate ssh2's optional cpu-features dep points at a prebuilt .node that only exists where a build toolchain has run. Loading it made the gate pass locally and hard-fail on CI with 'Could not resolve ../build/Release/cpufeatures.node'. The gate only reads the import graph, never the addon, so resolve every .node to an external stub instead. Verified by hiding the local prebuild — which is CI's state — and re-running: still 36 entries, exit 0. * fix(runtime-ratchet): stop the gate failing open on Windows The entry guard compared import.meta.url against a `file://${process.argv[1]}` template. On Windows argv[1] is a native path (C:\repo\...) while import.meta.url is file:///C:/repo/..., so they never match: main() never ran and `pnpm lint` exited 0 on Windows without bundling, reading the baseline, or enforcing anything. Use pathToFileURL, which is the idiom check-max-lines-ratchet.mjs:225 already uses. CI runs this on ubuntu so enforcement was never actually lost, but a Windows developer got a green gate that checked nothing.	2026-08-22 21:22:07 -07:00