develop
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 james.maes
|
c7242ed64c |
fix(app,wizard,scripts): suppress wizard-redundant banners + wire DevOverlay menu + add camera entitlement
User reported four issues clustered around setup UX and missing
features after the previous round of fixes:
1. 'No API key configured' banner pops up DURING the wizard's API-key
stage. Same for 'Limited hotkey mode' during the TCC stage. AppDelegate
was enqueuing both banners at startup BEFORE deciding whether the
wizard would open, so the wizard's own apiKey / TCC stages stacked
on top of redundant banners covering the same prerequisites.
2. AppDelegate called hidProbe.requestListenEventAccess() at launch (the
prompting variant), so on first launch macOS could fire a TCC dialog
OUTSIDE the wizard's TCC stage flow — surprising the user with a
permission prompt before they'd seen any explainer copy.
3. 'Show Dev Overlay' menu item was a stub that enqueued a 'Dev Overlay
lands in Phase 4' banner. The DevOverlay package has been fully
implemented for some time (DevOverlayWindow with show/hide/toggle);
nobody had wired the menu item to it.
4. Camera entitlement (com.apple.security.device.camera) was missing from
BOTH Jarvis.Debug.entitlements and Jarvis.Release.entitlements. macOS
non-sandboxed apps don't strictly require it, but having it acts as a
hint to the system and is required if sandboxing is ever enabled.
Without it, NSCameraUsageDescription alone may surface camera prompts
in some macOS versions but not be reliably honored.
Fixes:
- AppDelegate.applicationWillFinishLaunching:
* Compute apiKeyStored/inputMonitoringGranted but DON'T enqueue
banners until after the wizard's open/closed decision is made.
* Switched the launch-time TCC probe from requestListenEventAccess
(prompts) to isListenEventAccessGranted (IOHIDCheckAccess — query
only). The wizard's TCC stage owns the actual prompt now.
* After the wizard decision: enqueue keychainEmpty/inputMonitoringDenied
ONLY if the wizard isn't going to address them.
- AppDelegate menu wiring:
* devOverlayToggleAction now calls toggleDevOverlay() which lazily
constructs a DevOverlayWindow on first toggle and routes the menu
item to its toggle() primitive.
* Removed the showDevOverlayStubBanner placeholder.
* Added 'import DevOverlay' (project.yml + Package wiring also updated).
- project.yml:
* Added DevOverlay package declaration (path: packages/DevOverlay).
* Added DevOverlay product to the Jarvis target's dependencies.
* Re-ran xcodegen to regenerate Jarvis.xcodeproj.
- App/Jarvis.{Debug,Release}.entitlements:
* Added com.apple.security.device.camera. Doesn't violate the
MAIN_FORBIDDEN list in verify-entitlements.sh.
Verified: check-app-builds clean; codesign reflects the new camera
entitlement; relaunched (PID 43128); 'Show Dev Overlay' now toggles
the actual DevOverlayWindow; banner spam during wizard is gone.
|
||
|
james.maes
|
0517926f61 |
fix(01): split entitlements per-config + address AMFI rejection on ad-hoc Debug
The debugger agent diagnosed the JarvisAppTests xctest launch failure (Runningboard error 5 / Launchd job spawn failed). Root cause: AMFI rejected the ad-hoc signed Debug bundle because it carried the managed `com.apple.developer.speech-recognition-assets` entitlement. The kernel logged `AMFI: Code has restricted entitlements, but the validation of its code signature failed` → `load code signature error 4` → spawn failure → Runningboard error 5. **Changes:** - Split `App/Jarvis.entitlements` → `Jarvis.Debug.entitlements` (no `speech-recognition-assets`; adds `get-task-allow` for XCTest attach) + `Jarvis.Release.entitlements` (full managed set, unchanged). - `project.yml`: per-config `CODE_SIGN_ENTITLEMENTS`; Debug gets `ENABLE_HARDENED_RUNTIME=NO` + `OTHER_CODE_SIGN_FLAGS=""` + `ONLY_ACTIVE_ARCH=YES`; `DEVELOPMENT_TEAM` moved from base → Release only (avoids Team ID leaking into the Xcode 26 debug dylib). - `scripts/codesign.sh`: resolves entitlements via $CODE_SIGN_ENTITLEMENTS env, falls back to config-specific file, then to the legacy path. Also signs `Contents/MacOS/*.debug.dylib` now that Xcode 26 emits it. - `scripts/verify-entitlements.sh`: per-config `MAIN_REQUIRED` + `MAIN_FORBIDDEN` lists — Debug forbids `speech-recognition-assets` (wrong for ad-hoc) and requires `get-task-allow`; Release enforces the shipping posture with all 3 managed keys. **Residual known issue** (documented in `.planning/debug/xctest-launch-runningboard-error-5.md` and `01-HUMAN-UAT.md` §4): Xcode 26 still emits `Jarvis.debug.dylib` with a code signature whose Team ID context diverges from our ad-hoc outer sign, producing a dyld "different Team IDs" rejection when xctest tries to load the bundle. Multiple workarounds attempted (SWIFT_ENABLE_DEBUG_DYLIB=NO, resigning the dylib, stripping it post-build). `xcodebuild test -scheme Jarvis -only-testing:JarvisAppTests` fails bootstrap; SPM package tests (56, all passing) and `xcodebuild build` both succeed. Actual code quality is unaffected — this is a harness/tooling boundary issue. Verified: 56 SPM tests pass; `xcodebuild build -configuration Debug` BUILD SUCCEEDED; `scripts/test-verify-entitlements.sh` self-test PASS=3 FAIL=0. |