Announcement readiness: focused preview and broad launch #5

Goal

Take Markover from its current early state through a candid focused macOS preview and, later, a trustworthy broad public announcement.

This issue is the single go/no-go checklist. The linked GitHub Project is the operational source of truth for status, gate, workstream, priority, and delivery shape.

Focused-preview gate

The focused preview may be announced when:

• A new user on Apple Silicon can complete the public workflow without maintainer intervention.
• The public preview release comes from the exact tested commit and is visibly labeled as an early preview.
• Packaged-app capabilities, Electron boundaries, and the loopback review API meet the documented preview security baseline.
• Representative handoffs correctly distinguish requested revisions from questions and discussion.
• Pull requests and main are protected by continuous automated checks.
• Privacy, local storage, deletion, support, limitations, and Apple Silicon compatibility information are easy to find.
• Public repository metadata and the initial announcement assets accurately describe the product.

Broad-announcement gate

In addition to the focused-preview gate:

• Downloaded builds pass Developer ID signing and notarization checks.
• Native Intel release activation and physical Intel/Sonoma validation are complete under issue Ship and validate native Intel releases for the broad announcement #80.
• Release provenance and update/rollback behavior are documented and exercised.
• Keyboard and VoiceOver workflows have passed a focused accessibility review.
• Review-history controls and supported-Markdown boundaries are user-facing.
• Contributor and security-reporting surfaces are ready for outside participation.
• Launch operations include support coverage, rollback criteria, and a known-good previous release.

Working agreements

• Sub-issues own independently verifiable outcomes.
• Short stacked PRs are used only when later code slices genuinely depend on earlier ones.
• Independent work remains in ordinary PRs so it can land in parallel.
• Closing a sub-issue requires evidence in its acceptance checklist, not merely an open PR.