amadan
native/3 — DECISION: signing, notarization, and Sparkle vs the App Store Question open
No code dependency. Needs answering early, because it constrains everything native.
AGENTS.md decision 6 says this choice gets made at slice 2 rather than slice 3, and the reason is that the AutoFill Credential Provider extension — the thing that stops CONTRA being a website — drags its distribution model backwards into the app it ships inside.
What needs deciding:
- Mac App Store, or direct download with Sparkle? The App Store gives painless AutoFill entitlement and update trust; direct download gives control, no review latency, and no 30% question if paid tiers ever move through it. The family has Sparkle precedent in Eleven.
- Paid Apple Developer account — required either way for the entitlement. Whose, and on which account of record?
- Notarization in CI, and where the signing key lives. Note the family rule from Eleven's secrets inventory: release and Sparkle signing keys stay out of any shared vault, used only at publish time, because aggregating them turns one key compromise into a ship-code-to-the-fleet compromise. That constraint applies to us and is slightly awkward, since we are the password manager.
- The passkey RP origin. Passkey relying parties pin to a hostname, renaming one later is a multi-phase drill, and it must never be shared with an origin carrying third-party or account-authored content. Pick it deliberately and early — this is the cheapest moment.
Deliverable: a short design record in docs/ with a Status line, the decision dated and attributed, and the rejected alternative recorded — then the matching lines in AGENTS.md's settled decisions.
This one wants a human. Post the options and the recommendation here and wait for Paul rather than picking; it commits money and an account of record.