devtools-extension: publish to Chrome Web Store (icons, listing, CI)

Spun out of #1747 (DevTools protocol + extension built, tested, and closed). The remaining work is the store-publishing chore, which needs maintainer accounts/assets rather than more engineering.

What's done (in #1747)

packages/devtools-extension/ is a complete, loadable MV3 extension — protocol (v4: tree · scope · stores · store · graph · mutations · queries · ifTrace · stats), page bridge ↔ content-script ↔ background relay, all panel views, live refresh, drill-down, graph filter, mutation log. Unit-tested + a real-runtime↔bridge integration test. bun run build → loadable dist/.

What's left (this issue)

• Icons (16/32/48/128) + icons in manifest.json
• Store listing: name, description, screenshots (use bun run preview for clean shots), privacy note (the extension reads page devtools state only; no network/telemetry)
• A zip/package step in CI for releases
• Chrome Web Store submission (maintainer account)
• Optional: Firefox (browser_specific_settings) + Edge listings

No blocker — purely packaging + submission.

Everything on the checklist that doesn't need a Chrome Web Store account is done, in f8c77c3132.

• Icons (16/32/48/128) + icons in manifest.json — the package had none, which is a hard submission blocker.
• Store listing — packages/devtools-extension/STORE_LISTING.md, ready to paste.
• A zip/package step in CI — bun run package, and the release workflow attaches the artifact.
• Chrome Web Store submission — needs your account.
• Firefox / Edge — noted as follow-ups; both accept this package.

Notes

The icons are generated, not drawn. A dependency-free PNG encoder (scripts/gen-icons.ts) — Bun.deflateSync supplies the zlib stream an IDAT needs and CRC32 is a dozen lines. That keeps them deterministic and diffable rather than binary blobs nobody can regenerate. Verified as real PNGs by an independent decoder, not just by writing the right magic bytes.

The mark is deliberately plain geometry — brackets around a bar, reading as a template expression, in the runtime's own cyan. Anything with interior detail turns to mud at 16px in the toolbar. Easy to replace if you have something better; regenerate with bun run icons.

bun run package fails loudly if the manifest is missing an icon. Finding that out at submission time is a slow way to find out. It also passes -X so macOS extended attributes don't become the __MACOSX entries the store flags.

The listing includes the privacy-practices answers, including a written justification for why a DevTools extension matches <all_urls> — that's the part that usually stalls a first submission.

Verified end to end: bun run package → release/stacks-devtools-0.2.70.zip, 7.4 KB, all four icons present. 53 extension tests still green.

Reverted in a4ffb6c014 — disregard my previous comment. The icons, packaging script, store listing and CI step are all gone; the extension is back to exactly its prior state (verified: the diff against the pre-commit tree is empty, and 53 extension tests still pass).

Reopening, since nothing on the checklist is done now.

Everything is recoverable from f8c77c313246977f198235ec341443f7c954147f if any of it turns out to be wanted later — git revert a4ffb6c014 restores the lot, or individual pieces can be cherry-picked out of it.

Everything except the account is done — 5890a2c360

• Icons (16/32/48/128) + icons in manifest.json — generated from the project logo, and pinned by a test that reads each PNG's IHDR and asserts it is actually the size it claims. An icon that is really 800px scaled down looks correct in the browser and is rejected by review.
• Store listing — packages/devtools-extension/STORE_LISTING.md: name, summary (95 chars, under the 132 limit), description, category, the single-purpose and data-use answers, the <all_urls> justification, and the screenshot shot-list. Written down so the wording is identical across the Chrome, Edge and Firefox listings.
• Zip step in CI — bun run package → stacks-devtools-<version>.zip, built by the release workflow and attached to the GitHub release.
• Chrome Web Store submission — yours; needs the developer account.
• Firefox / Edge listings (see below).

One thing that would have failed, and not on the first try

public/manifest.json hardcoded "version": "0.2.70" while the package was at 0.2.170, drifting a little with every release since. The store rejects an upload whose version does not exceed the published one — so the first submission would have gone through fine and the second would have been refused over a number that matches nothing in the repo.

It is now stamped from package.json at build time. Keeping two version strings in sync by hand is the kind of sync that stops happening, so the test asserts the build does the stamping rather than asserting the two files happen to agree today.

Also: the archive has manifest.json at its root rather than inside dist/. Uploading the wrapper directory is the standard first-attempt rejection.

What the submission now looks like

Download the zip from the release, drag it into the dashboard, paste from STORE_LISTING.md, capture the five screenshots (bun run preview renders the panel against fixture data for clean shots). No local build, no reinvented copy.

No store token is wired into the workflow — there is none in this repo, and adding one is a decision about where a publishing credential lives rather than a packaging step.

Firefox is deliberately left alone: it needs browser_specific_settings.gecko.id in the manifest, which buys nothing in a shared manifest with no Firefox listing to point at yet. Edge takes the same package and the same copy as Chrome.

Leaving this open, since the submission is the thing it is named for.