# Release Readiness Notes

## Chrome Web Store prep

- Product-facing name: **Time-2-Notion**.
- Current manifest version: `0.1.12`.
- Current permissions: `identity`, `storage`.
- Current host permissions: `https://api.notion.com/*`, `https://*/*`, and `http://localhost/*`.
  - `https://*/*` exists because beta users can configure any HTTPS OAuth relay URL. This will need a clear Chrome Web Store justification or a narrower production relay host before launch.
  - `http://localhost/*` is useful for local relay testing, but should be removed or moved to a development-only manifest before public submission.
- Draft release artifacts now live in this folder:
  - [Chrome Web Store listing draft](chrome-web-store-listing-draft.md)
  - [Privacy policy draft](privacy-policy-draft.md)
  - [Screenshot checklist](screenshot-checklist.md)
  - [Permission rationale](permission-rationale.md)
- Add final hosted store assets before launch: 1280x800 screenshots, 440x280 small promo tile, 920x680 marquee/promo assets if desired, published listing description, privacy policy URL, and support/contact URL.
- Keep the permission justification single-purpose and focused on saving user-reviewed timer entries into the Notion workspace the user authorizes.

## UX/store-readiness blockers to resolve before public launch

1. **Configurable OAuth relay**: the beta asks users for a Client ID and relay URL. A public paid product should hide this behind a first-party relay or a hosted onboarding flow.
2. **Broad host permissions**: narrow host permissions for production if possible, or document why arbitrary HTTPS relay URLs are required.
3. **Development host permission**: remove `http://localhost/*` from the submitted build.
4. **Privacy policy**: publish one that describes local Chrome storage, Notion OAuth tokens, optional setup backups, and relay token exchange behavior.
5. **Support/onboarding**: add user-facing setup screenshots or a short guided setup page for Notion database sharing and field mapping.
6. **Manual browser smoke test**: verify install, OAuth connect, data-source discovery, project/task load, start/stop timer, manual elapsed entry, save to Notion, backup export/import, disconnect, and token refresh. Include the Notion existing-session matrix in [Notion OAuth session-conflict repro](notion-oauth-session-conflict-repro.md).
7. **Final review metadata**: replace support and privacy URL placeholders in the listing draft before submission.

## Monetization notes

- Chrome extensions cannot rely solely on Chrome Web Store Payments; plan an external entitlement service if monetized.
- Low-friction options:
  - one-time license key validated by a small backend;
  - subscription via Stripe Customer Portal;
  - team/workspace license tied to a Notion workspace ID returned by OAuth.
- Do not put payment secrets or privileged license-bypass flags in extension code.
- Gate premium behavior at a server-controlled entitlement check, but keep core data handling transparent and privacy-preserving.
- Decide the packaging model early: free beta, free trial, freemium with limits, or paid unlock.

## Future Firefox portability concerns

Do not build Firefox yet, but keep these in mind:

- Firefox Manifest V3 support differs from Chrome; service worker behavior, persistent background alternatives, and review requirements should be tested separately.
- Chrome's `chrome.identity.launchWebAuthFlow` has a Firefox counterpart under `browser.identity.launchWebAuthFlow`, but redirect URL formats and extension IDs differ.
- Prefer a small browser API wrapper if portability work begins (`globalThis.browser ?? chrome`) and avoid Chrome-only assumptions in shared logic.
- Host permission UX and optional permissions differ between stores; broad relay permissions may be harder to justify.
- Store listing, privacy, and signing processes are separate for Mozilla Add-ons.
- If production OAuth uses an extension-specific redirect allowlist, Firefox will need its own redirect URI and likely separate Notion OAuth app configuration.