spec(chrome-edge): Chrome/Edge Web Store parity, domain-separation guard, and PRD Milestone 9-10 scoping (no implementation)

[Kotmin]

Context

This is a scoping issue, not an implementation issue. Per project convention, no PR will be opened against any item here without K's explicit sign-off. Goal: gather enough specification that follow-up work can be scoped into atomic PRs.

What's already true (confirmed by code inspection, no action needed)

• All three editions (apps/firefox-extension, apps/chrome-extension, apps/edge-extension) are on manifest version 0.0.3, and scripts/check.sh already hard-fails CI if the three manifest version fields diverge.
• CI already packages all three unsigned zips on every dev push (scripts/package-extension.sh <edition>).
• Firefox already has a real signing/release pipeline (release-main.yml, AMO via web-ext). Chrome/Edge have none.
• Shared-source layout (ADR-0008) already separates each edition's checked-in files (manifest.json, README.md) from generated, gitignored files (src/, assets/, lib/, materialized by scripts/sync-extension-lib.sh). This is the existing domain-separation mechanism — see gaps below for what it doesn't cover.
• Edge's manifest is currently byte-identical to Chrome's (no Edge-specific fields yet).

Gaps / open questions to close before implementation

1. Domain-separation guard (hard requirement from K)

The gitignore+sync split prevents generated files from being committed, but nothing currently stops:

• Someone hand-editing apps/chrome-extension/manifest.json with a field that silently diverges from what apps/firefox-extension/manifest.json expects (beyond the fields check.sh already validates: manifest_version, name, version, permissions, content_scripts, action, host_permissions).
• A generated file accidentally getting committed into an edition dir (bypassing .gitignore via git add -f or similar).

Open question: should check.sh gain a stricter per-edition manifest-diff check (allowed-divergent-fields list, e.g. browser_specific_settings, minimum_chrome_version, vs. everything else must match), and should there be a pre-commit/CI check that fails if any edition dir has tracked files outside manifest.json/README.md?

2. No chrome-specific test directory; Firefox (source of truth) has the weakest shortcut coverage

• scripts/test-chrome-smoke.mjs (single file, not a directory) already exercises the tmux-style prefix chords and jump-label overlay in real Chromium (presses Control+a, o, Escape, y).
• scripts/test-extension-e2e.mjs (Firefox, web-ext + RDP) has zero coverage of the keyboard-shortcuts/jump-overlay feature.
• Since Firefox is the source of truth, this is inverted. Open question: add Firefox E2E coverage for prefix chords/jump-overlay, and/or formalize a tests/e2e/<edition>/ layout instead of loose top-level scripts.

3. Chrome Web Store publish pipeline (net new)

• Requires: one-time $5 Google developer registration, a Google Cloud project with OAuth client (Web application type), a refresh token minted once (chromewebstore scope), then hourly access tokens via plain oauth2.googleapis.com/token POST — no npm dependency needed, fits the existing zero-runtime-dep policy.
• New CWS API v2 (chromewebstore.googleapis.com/v2/publishers/{id}/items/{id}:{action}) supports upload/publish/fetchStatus/cancelSubmission — but the first-ever listing must be created manually in the Developer Dashboard (Store listing + Privacy tabs); the API only updates an existing item.
• Privacy-practices tab (single-purpose description + per-permission justification) is mandatory.
• Manifest "key" field (for a stable CI-build extension ID) must be stripped before the zip is uploaded to the Store — the Store assigns/owns the real key.
• Open question: who owns the Google Cloud project / billing identity for the OAuth client (K decision, not technical).

4. Edge Add-ons publish pipeline (net new)

• Partner Center API v1.1: simpler ApiKey + X-ClientID header auth, no OAuth dance, replicable with stdlib HTTP.
• Same constraint: first submission must be done manually in Partner Center; API only updates an existing product.
• Review turnaround up to 7 business days.
• Can likely reuse the Chrome-built zip as-is today (manifest is currently identical), pending confirmation Edge doesn't need a divergent field once a real listing exists.
• Open question: pursue Edge now, or defer given it's a second manual bootstrap + secret set for a byte-identical package (K go/no-go).

5. Versioning once real publishing exists

• Parity is already enforced pre-publish. Not yet decided: on a needs-changes submission from either store, do we bump the shared version immediately or resubmit the same version? (Unconfirmed in either store's docs — needs a K decision, not a technical answer.)

6. Existing open questions this issue should resolve/close

From docs/ai/questions-for-K.md:

• Q1: AMO extension id is still videodefaults@dev — must be finalized before first AMO upload (id is permanent once used).
• Q3: this issue is the explicit trigger for the "Chrome/Edge distribution targets" question — deferred pending store credentials, which is exactly what's being scoped here.

7. PRD milestone this continues

docs/PRD.md — Milestone 9 (AMO Release Readiness, VD-901..905) and Milestone 10 (VD-1004 Chromium build adapter — done; VD-1005 Edge packaging notes — manifest exists, no CI yet).

Non-goals for this issue

• No pull requests / code changes without K's explicit sign-off per item.
• No actual store developer account creation — blocked on K's identity/ownership decision (Google Cloud project, Microsoft Partner Center account).

Next step

K to answer: (a) who owns the Google/Microsoft developer identities, (b) go/no-go on Edge now vs later, (c) how strict the domain-separation CI guard should be (warn vs hard-fail), (d) same-version-resubmit policy for a needs-changes response.

Relates to #5 (icon placeholder — same Milestone 9 readiness area, filed separately since it's independently actionable).

[Kotmin]

Status update 2026-08-06: Edge pipeline built, then paused

K gave the go-ahead on item 4 (Edge Add-ons pipeline) directly in
conversation, which doubles as the go/no-go this issue's "Next step"
section asked for. Built, then paused for delivery timing — not blocked
on any remaining open question from this issue.

What was built (commits 6491ea0..548c2fe on dev)

• docs/release/edge-api-contract-findings.md — Partner Center Submission
  API v1.1 contract, verified against current Microsoft docs before writing
  any workflow code (same debug-strategy rule that caught the CWS contract
  bug after a failed live run — this time checked first).
• docs/release/edge-developer-setup.md — one-time setup guide, mirrors
  docs/release/cws-developer-setup.md.
• .github/workflows/edge-store-bootstrap.yml — temporary manual zip-only
  workflow for the first Partner Center listing, mirrors
  chrome-store-bootstrap.yml.
• .github/workflows/release-edge.yml — full pipeline: check → test →
  package → changelog → async upload+poll → async submit+poll → GitHub
  release.

This also resolves this issue's item 4 open question ("pursue Edge now, or
defer") and Q3 in docs/ai/questions-for-K.md.

Why paused (commit 222f6fa)

release-edge.yml's original push: branches: [main] trigger watched
apps/shared/**, src/**, scripts/** — paths any ordinary dev→main
promotion touches. With no EDGE_CLIENT_ID/EDGE_API_KEY/EDGE_PRODUCT_ID
secrets set, GitHub Actions would substitute empty strings (not a syntax
error) and the curl call would hit the live Microsoft API with blank auth,
fail non-202, and the workflow explicitly exit 1s on that — i.e. every
main promotion would have gone red for a store we haven't set up yet.

Current state

• release-edge.yml trigger is workflow_dispatch only (push trigger
  removed, kept commented in the workflow file's header for a one-step
  restore).
• A "Check Edge Add-ons credentials are configured" step gates every
  publish/release step (including tag + GitHub Release creation, to avoid a
  stuck edge-v* tag) — even a manual dispatch stays green until the three
  secrets exist.
• edge-store-bootstrap.yml was never a risk (already workflow_dispatch
  only, no secrets touched) — untouched.

Restore point — what unblocks this

This issue's original item 4 open question, unchanged: who creates/owns
the Microsoft Partner Center developer account. Concretely, to resume:

1. K completes docs/release/edge-developer-setup.md §1–3: register Partner
   Center, mint EDGE_CLIENT_ID/EDGE_API_KEY, do the one-time manual
   first listing (upload via edge-store-bootstrap.yml's artifact), copy
   the product GUID.
2. Set EDGE_CLIENT_ID, EDGE_API_KEY, EDGE_PRODUCT_ID as repo secrets.
3. In .github/workflows/release-edge.yml, uncomment the push: block
   documented in the file's header comment (restores the main-promotion
   trigger). No code changes needed beyond that — the credentials guard
   means restoring the trigger early (before secrets exist) is also safe.

Tracked follow-up questions (account ownership, certification-notes
content, resubmission-versioning policy) are Q9–Q11 in
docs/ai/questions-for-K.md. Opera/Safari were split out as their own
scoping issue, #12, per this issue's own suggestion to track them
separately.