mirror of
https://github.com/stablyai/orca.git
synced 2026-09-22 16:02:32 +00:00
stack-final
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  
|
81c3d188a4 |
build(macos): parallelize native helpers with complete cancellation (#19651)
* build(macos): run native module builds concurrently
* fix(build): terminate sibling native builds when one fails
Address coderabbit review: concurrent builds kept writing native
artifacts after a sibling reported failure. Track spawned children,
kill remaining siblings on first nonzero exit, and forward SIGINT/
SIGTERM to all children.
* fix(build): process-group teardown and prefixed output for parallel native builds
Address second coderabbit round:
- Detached process groups + negative-pid kill so SIGTERM reaches swift/
swiftc descendants, not just the direct pnpm child (they could keep
writing artifacts after fail-fast)
- Signal handlers preserve the received signal (SIGINT no longer becomes
SIGTERM for children) and are removed before re-raising, so the parent
actually dies instead of looping through terminateAll
- runPnpmScript settles only on close, never on error alone, so
Promise.all cannot exit while children are still running
- Per-module output prefixes ([computer]/[keyboard-layout]/[notification-
status]) match what the PR description always claimed; interleaved
swiftc errors are now attributable
- Windows path untouched (early return before any of this runs)
execa/p-limit were considered and rejected: no new runtime deps for a
build script, and detached process groups give strictly stronger cleanup
than execa's direct-child kill.
* fix(build): memoized handler removal and external-vs-sibling signal split
Second-round coderabbit findings on
|
||
 Neil
|
df8467247d |
fix(ci): stop hourly/adhoc mac builds from executing native pnpm via node (#17331)
pnpm 12's npm_execpath is a Mach-O/PE binary. build-native-for-platform.mjs still launched it with `node $npm_execpath`, which throws SyntaxError on the binary header and fails every signed macOS dev-channel build. |
||
|
Neil
|
9f3a912c1e |
fix(terminal): type Option-composed ASCII instead of reporting it as a chord (#14743)
* fix(terminal): preserve Option-composed ASCII input * fix(terminal): preserve Option keyboard protocol semantics * fix(terminal): complete Option keyboard event encoding * fix(terminal): harden Option input encoding * fix(terminal): close keyboard protocol fallback gaps * test(terminal): prove Option-composed ASCII reaches the pty end to end The Option-compose fix had unit coverage only. This drives a live Electron pane whose kitty flags are armed by the application's own CSI > 1 u and asserts the bytes at the pty boundary: composed `@` and Shift-layer `\` arrive as text, configured Option-as-Alt still reports the layout-resolved chord, and a non-ASCII glyph still reaches the app as its alt hotkey. Restoring the pre-fix policy fails exactly the two composed-text scenarios. Also records the ASCII rule's rationale where the rule lives, not only in a test comment. * refactor(terminal): drop the unread Option layers from the layout snapshot The native helper computed an Option and Option+Shift character for every key, shipped both over IPC, validated them in the parser and cached them in the renderer — but no production caller ever asked for them. Only the base and Shift layers are read, and Shift is the one the web layout map cannot supply, which is why the helper exists at all. Removing them halves the helper's UCKeyTranslate work per key and drops the option parameter that six signatures were threading through for nobody. |
||
|
Neil
|
ee82d66a35 |
fix(cli): preserve multiline arguments on Windows (#8374)
* fix(cli): preserve multiline Windows arguments * test(cli): run Windows launcher regression in CI * fix(cli): support Windows Framework C# compiler |
||
 NeilandOrca
|
25ea2bbfd1 |
onboarding: seamless macOS notification permission step with live state detection (#7684)
* feat(onboarding): state-aware macOS notification permission step The Set up notifications step showed a one-size-fits-all 'Open Mac Settings' button that simultaneously fired the macOS permission prompt and opened System Settings — two competing system UIs, with System Settings unnecessary for the common fresh-install case. Electron exposes no API to read macOS notification authorization, but scheduling outcomes do reveal it: a silent probe notification's 'show' event means permission is granted, 'failed' means delivery is blocked. A new notifications:probeDelivery IPC runs that probe (cached via passive delivery evidence and a persisted confirmation flag), and the onboarding card now renders the real state: - fresh install: the probe itself pops the native Allow dialog the moment the step opens; the card flips to 'Notifications are enabled' automatically when the user clicks Allow (silent 2.5s re-probes) - blocked: amber card with an Open System Settings deep-link, which also self-heals once the user flips the toggle - granted: green confirmation card The test-notification button now feeds the same card instead of the ambiguous 'if no banner appeared…' toast during onboarding. Co-authored-by: Orca <help@stably.ai> * fix: don't log expected probe rejections while polling for permission Co-authored-by: Orca <help@stably.ai> * fix: amber warning styling + single stable dev bundle id for notifications - Blocked card now uses the app's shipped amber idiom (tinted surface with amber title/body) instead of white-on-amber-wash, which read muddy in dark mode; macOS permission card split into its own module to stay under the max-lines budget. - Dev instances previously minted a unique macOS bundle id per branch x Electron version, registering a new Notification Settings entry every time ('Orca: <branch>' rows piling up forever) and pointing the settings deep-link at ids System Settings can't resolve. All dev instances now share com.stablyai.orca.dev: one Notification Center entry, one permission grant covering every dev build. Co-authored-by: Orca <help@stably.ai> * fix: tighten macOS permission card copy Body copy was one long sentence; now a single short instruction with 'Updates automatically.' as a separate dimmer line. Also repairs locale catalog parity for keys introduced by commits rebased into this branch. Co-authored-by: Orca <help@stably.ai> * fix: drop 'Updates automatically.' line; ad-hoc sign dev app copies The extra line read as confusing filler — the cards now carry one short instruction each. Dev Electron copies had broken code signatures (the Info.plist identity edits invalidate the ad-hoc seal), which macOS punishes by refusing Notification Center registration outright: every dev notification failed with UNErrorDomain error 1, the app never appeared in System Settings > Notifications, and the settings deep-link had nothing to land on. The dev runner now ad-hoc re-signs the copied bundle after the plist edits (bundleLayoutVersion bumped so stale unsigned copies are recreated). Verified end-to-end: runner-built copy passes codesign --verify --deep, probe delivery returns delivered, the onboarding card flips green in dev, and the deep link opens the dev app's own notifications pane. Co-authored-by: Orca <help@stably.ai> * fix: drop confusing copy line; session-only permission evidence Removes the 'Updates automatically.' line from both permission cards. Also drops the persisted notificationDeliveryConfirmed flag: OS-level permission changes between sessions, and a stale positive rendered a false green card. Delivery evidence is now session-scoped only. Documented detection ceiling (verified empirically on macOS 26): while the permission dialog is unanswered — and when notifications are toggled off in System Settings after being authorized — macOS accepts requests and silently swallows them, with no public API (Notification Center delivered-history and legacy ncprefs both included) able to distinguish that from real delivery. 'failed' remains definitive for unsigned builds and dialog-level denials. Co-authored-by: Orca <help@stably.ai> * feat: real macOS notification permission readout via native helper Electron has no API for UNUserNotificationCenter authorization, and every observable fallback lies: scheduling succeeds (and getHistory lists the notification) even while macOS silently swallows display because the permission dialog is unanswered or notifications were toggled off in System Settings. The onboarding card therefore showed 'enabled' after the user disabled notifications. Adds native/notification-status-macos: a tiny Swift binary that prints the app's real authorization status. It runs from inside the app bundle (NSBundle resolves the bundle by walking up from the executable) and embeds the app's CFBundleIdentifier in a __TEXT,__info_plist section so every codesign --force pass — electron-builder's signing or the dev runner's ad-hoc deep sign — derives the identifier macOS keys notification records to. Spawning it from the app returns authorized / denied / not-determined exactly matching System Settings. notifications:probeDelivery now prefers this readout (authoritative, silent), firing at most one dialog-trigger probe per session while the decision is pending, and falls back to the previous delivery-probe heuristics when the helper is unavailable. The card polls the readout silently in every state, so toggling Allow notifications in System Settings flips the card within a poll — both directions, verified live. Test notifications also consult the readout so 'delivered' is no longer claimed for swallowed notifications. Packaged builds ship the helper via extraResources and sign it in afterPack like the computer-use helper; dev copies compile it on demand (swiftc, non-fatal when missing) with the shared dev bundle id. Co-authored-by: Orca <help@stably.ai> * feat: in-app fallback for swallowed notifications + permission card in Settings - Dispatch now consults the authorization readout before creating a native notification: when macOS would silently swallow it (denied or prompt unanswered) it returns reason 'blocked-by-system' instead of piling invisible notifications into Notification Center. The terminal notification path surfaces that as a once-per-session in-app toast with an Open System Settings action. Mobile fan-out is unaffected. - Settings > Notifications now shows the same live permission card as onboarding (moved to components/notifications/), polling the readout so System Settings changes reflect within seconds, and the test button updates it inline. - Test sends that are blocked at the OS level now show the settings-pointing failure toast instead of a generic error. Co-authored-by: Orca <help@stably.ai> * fix: hide macOS permission card while Orca notifications are disabled A green 'Notifications are enabled' card next to a disabled Enable Notifications toggle read as a contradiction — the card now renders (and the readout polls) only while Orca's own notifications setting is on. Also single-flights the authorization helper so simultaneous agent completions share one readout process. Co-authored-by: Orca <help@stably.ai> --------- Co-authored-by: Orca <help@stably.ai> |
||
 Jinjing
|
b8ad7e6bf7 | fix: harden packaging installers (#3878) |