exhibit

Exhibit release checklist

Prepared: 2026-07-30 · Evidence record: VERIFICATION.md

The internal Chrome workflow is accepted. Licence, legal owner, contacts, retention, and the compatibility claim are all settled, the store assets except the video are generated, and a clean artifact with no placeholders is recorded.

What remains is outside this repository: hosting the privacy policy at a public URL, the product video, independent review, and user validation.

The short list of what only the owner can supply is RELEASE_DECISIONS.md. This document keeps the ordered submission mechanics.


Part 1 — Evidence already collected

Area Evidence
Quality gate 2026-07-31 clean-tree pnpm release:artifact at c4c96d6 exit 0: 1,009 tests, 43 E2E, coverage above 90%
Package audit 0 remote scripts, 0 inline scripts, 0 unapproved network destinations
Dependency audit 0 known high or critical advisories
Manifest MV3, ["storage","scripting"], no required host permissions, optional origins only
Artifact Commit c4c96d6, clean tree — exhibit-0.1.0-chrome.zip, 224,836 bytes; ZIP SHA-256 d49f7568…1b2869, reproducible content hash c443c0b5…5c1dba
Promo tile 440×280 generated by pnpm promo-tile, byte-identical across runs
Icons 16 / 32 / 48 / 128 PNG present; no unreferenced assets ship
Screenshots Five 1280×800 light-theme PNGs regenerated from fixture data and visually inspected on 2026-07-30
Listing copy Name, summary, description, category, permission justifications — CHROME_WEB_STORE.md
Data-use preparation Behaviour mapped to the disclosure categories, same document
Compatibility floor Every API and platform feature audited against Chrome 120 — COMPATIBILITY.md
Privacy policy PRIVACY.md — contact and 2026-07-31 effective date applied; needs only a public URL
UX audit remediation All P1s, the P2 ledger defect, and the minor findings closed
Manual Chrome smoke User-reported pass on installed Chrome 150/macOS, recorded 2026-07-30 in VERIFICATION.md

Part 2 — Yours to do

Step 1 — Manual Chrome smoke (completed 2026-07-30)

The user reported every installed Chrome 150/macOS check passing, including panel registration, capture, grouping, Explain/Inspect, redaction, Clear, and sanitized HAR export. VERIFICATION.md owns that evidence. Use this table when repeating the smoke against a future release package:

# Step Expected
1 Panel registration An Exhibit tab appears in DevTools
2 Start/Stop Status pill goes live; Stop returns it to Not recording
3 Interaction grouping Rail lists the action you performed, with its request count and trust state
4 Explain/Inspect Explain gives one sentence with confidence; Inspect renders headers/body
5 Redaction Authorization header, query token, and password field all show [REDACTED]
6 Clear Ledger empties and the confirmation explains what is destroyed
7 Sanitized export Downloaded HAR contains no credential values

If a future package fails any step, treat it as a code defect, not paperwork.

Step 2 — Persistent-retention policy decision (settled 2026-07-31)

Resolved by removing on-disk evidence retention from the published build. The panel wires only chrome.storage.session, so captured evidence is held in browser-session memory and is never written to disk. The retention selector is gone, because there is no longer a choice to offer.

This is enforced rather than asserted: pnpm audit:package fails the release if an evidence-capable persistent storage API appears in the shipped bytes, and an integration test asserts the same against the built package.

chrome.storage.local still holds the theme and custom redaction field names — never captured evidence — and that is disclosed separately in the listing.

Step 3 — Compatibility claim (settled 2026-07-30)

The claim is narrowed to what was actually tested, and every user-facing surface now says so:

Built and manually checked against Chrome 150 on macOS. Declares Chrome 120 as its minimum supported version based on the platform features it uses.

minimum_chrome_version stays at "120", because it is a functional gate derived from the features the code uses rather than a support promise. Recording the full matrix later widens the claim with no code change; see COMPATIBILITY.md.

Note the one known cosmetic gap: scrollbar-color needs Chrome 121, so on Chrome 120 exactly the ledger scrollbars use Chrome’s default styling.

Decision Value
Legal owner name Kayumuzzaman, in LICENSE
Licence terms MIT, in LICENSE and package.json
Store publisher Chrome Web Store developer account exists

MIT is effectively irreversible once published: anyone who obtains the code under it keeps those rights permanently.

Step 5 — Monitored contacts (settled 2026-07-31)

File Route
SECURITY.md GitHub Security Advisories, 7-day acknowledgement
SUPPORT.md GitHub Issues, current release only, best effort
PRIVACY.md i.kayumuzzaman@gmail.com, effective 2026-07-31

The privacy contact is a personal address. It appears in a public listing and will be scraped; replacing it later means editing a published listing.

The policy still needs a public URL — the Web Store form requires one and it must stay reachable for as long as the item is listed. With the licence now MIT, making the repository public and enabling GitHub Pages is the straightforward route and costs nothing. This is the last item standing between the recorded artifact and submission.

Step 6 — Store assets and submission

The five tracked screenshots were regenerated in light theme and visually inspected on 2026-07-30, with the Server Action frame leading. The 440×280 small promo tile is generated and tracked. The only outstanding asset is the YouTube product video; the 1400×560 marquee tile is optional.

  1. Rerun pnpm screenshots and inspect all five 1280×800 images after any UI change.
  2. Rerun pnpm promo-tile after any identity or token change; it is deterministic, so an unchanged product produces an unchanged file.
  3. Record and publish a concise fixture-only product walkthrough video.
  4. Commit the intended release tree and confirm git status --short is empty.
  5. Run pnpm release:artifact — full gate, then package.
  6. Confirm the audit line reports exactly ["scripting","storage"].
  7. Record the clean commit, artifact size, both the ZIP SHA-256 and the reproducible package content hash in VERIFICATION.md. The ZIP hash changes on every rebuild of the same tree, so it identifies the uploaded file only; the content hash is what ties that file to the commit.
  8. Upload the exact .output/exhibit-0.1.0-chrome.zip whose ZIP hash you recorded. Do not rebuild between hashing and uploading — that invalidates the recorded hash.
  9. Paste the listing fields from CHROME_WEB_STORE.md.
  10. Upload the five screenshots in filename order, docs/promo/small-tile-440x280.png, and the video URL.
  11. Answer every data-use question against the behaviour recorded in that document, checking each answer against the form’s current wording
  12. Add the privacy policy URL from Step 5.
  13. Choose distribution visibility and regions, then submit for review.

Step 7 — After approval


What is deliberately not being done

These are open by choice, recorded so nobody assumes they were missed: