Idea
Today several permissions are only discovered to be missing at the moment they are needed — often mid-recording or post-recording, when the cost of failure is highest and the user cannot act. Parley should establish, at first launch and on every launch, that every mandatory permission is granted, and say so plainly before any recording is attempted.
The principle: never be surprised by a permission at runtime. A permission problem discovered while recording is a lost meeting; discovered at launch it is a ten-second fix.
Scope to work out
Which grants are genuinely mandatory vs optional-degraded, and what each blocks:
| Permission |
Needed for |
Mandatory? |
| Microphone |
local side of every recording |
yes |
| Screen Recording |
system audio via ScreenCaptureKit |
yes for sck source |
| System Audio Recording (TCC) |
Core Audio tap |
yes for core_audio_tap source |
| Calendar (EventKit) |
meeting-title suggestion |
no — degrade quietly |
| Notifications |
failure surfacing, crash recovery prompts |
arguably yes: without it, failures are silent |
| Output folder write access |
writing transcripts/audio to a user-chosen directory |
yes if the folder is outside the default |
PermissionManager + SystemPermissionChecker + SetupView already cover part of this; the gap is (a) the launch-time sweep on every launch rather than only first-run/uncached-model, (b) the source-dependent ones (tap vs SCK), and (c) anything folder-related once the output directory is user-configurable.
Why now
Raised after a summary failure was initially read as a permission problem (it was a timeout — see #173). The specific incident did not involve permissions, but the underlying complaint stands on its own: the app currently has no single moment where it asserts "everything I need, I have."
Acceptance sketch
- A launch-time check that runs regardless of first-run state, cheap enough not to delay the menu bar appearing.
- A clear, non-nagging surface when something mandatory is missing (the existing setup window is the obvious home).
- Distinguishes "missing and blocking" from "missing and degrading" so we do not train the user to dismiss it.
- Never silently proceeds into a recording that cannot succeed.
Idea
Today several permissions are only discovered to be missing at the moment they are needed — often mid-recording or post-recording, when the cost of failure is highest and the user cannot act. Parley should establish, at first launch and on every launch, that every mandatory permission is granted, and say so plainly before any recording is attempted.
The principle: never be surprised by a permission at runtime. A permission problem discovered while recording is a lost meeting; discovered at launch it is a ten-second fix.
Scope to work out
Which grants are genuinely mandatory vs optional-degraded, and what each blocks:
scksourcecore_audio_tapsourcePermissionManager+SystemPermissionChecker+SetupViewalready cover part of this; the gap is (a) the launch-time sweep on every launch rather than only first-run/uncached-model, (b) the source-dependent ones (tap vs SCK), and (c) anything folder-related once the output directory is user-configurable.Why now
Raised after a summary failure was initially read as a permission problem (it was a timeout — see #173). The specific incident did not involve permissions, but the underlying complaint stands on its own: the app currently has no single moment where it asserts "everything I need, I have."
Acceptance sketch