chrome-extension: split into coding + opt-in release pack; stop generating drift-prone files - #155
Merged
Conversation
…ssions to the privacy doc The release standard made every extension repo carry two prose files that only drift from state maintained elsewhere: - dev/build/release/releasing.md — a per-repo release doc duplicating this standard; its concrete facts already live in the stubs and manifest/package.json. - store_artifacts/STORE-LISTING.md — the "submission kit" duplicating Chrome Web Store dashboard state (listing copy + per-permission justifications). Both are removed. First publication becomes a one-time tracking issue (opened idempotently at setup, closed when done); the listing copy and per-permission justifications stay in the dashboard, where they actually live. Two checks replace cer/permission-justifications: - cer/privacy-permission-alignment (blocking, test-the-world): every manifest permission must be disclosed in PRIVACY.md — the one release artifact that genuinely belongs in the repo (it deploys as the public privacy page). - cer/permission-added-store-issue (advisory, test-the-work): when a change adds a permission, prompt opening the dashboard-justification issue — the manual step that can't be automated. Advisory because the fix lives entirely off-repo, so there is no in-repo artifact to block a fix against. cer/release-layout now requires only PRIVACY.md. A new ctx.readBase() helper lets the delta check compare permission sets against the base, immune to JSON trailing-comma line noise. Refs #153 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018zkPPQbDxA4kfF5bgDy3iD
…lease pack The chrome-extension pack bundled two unrelated concerns: MV3 coding gotchas (RULES.md, relevant whenever you write an extension) and the release/Chrome-Web- Store standard (RELEASE.md + 7 cer/* checks + stubs, relevant only when shipping). The check ids were already cer/ (chrome-extension-release) and DESIGN.md already named the pack chrome-extension-release — this realizes that intent. - New packs/chrome-extension-release/: RELEASE.md, the 7 checks, stubs/, support .mjs. Opt-in — declared when ready to ship, fingerprinted by the standard's "Release: *" workflow stubs (not the manifest). A manifest alone never arms the release checks; the drift guard auto-migrates a repo that already ships release. - packs/chrome-extension/: keeps only RULES.md (prose, no checks), fingerprinted by the manifest. Fixes premature enforcement: declaring the coding pack no longer forces four workflow stubs, PRIVACY.md, README release sections, etc. on a half-built extension. Docs (CLAUDE.md, packs/README.md, DESIGN.md, bump-version) and test imports updated; a fingerprint test asserts the opt-in behavior. Refs #156 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018zkPPQbDxA4kfF5bgDy3iD
missingbulb
changed the title
missingbulb
marked this pull request as ready for review
July 7, 2026 11:30
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #153. Closes #156.
Two related changes to the Chrome-extension corpus, in sequence.
1 — Stop generating drift-prone repo files (#153)
The release standard made every consuming repo carry two prose files that duplicate state maintained elsewhere:
dev/build/release/releasing.md— a per-repo release doc. The procedure lives once inRELEASE.md; the concrete facts already live in the stubs /manifest.json/package.json. Removed.store_artifacts/STORE-LISTING.md— the "submission kit" duplicating Chrome Web Store dashboard state. Removed. First publication becomes a one-time tracking issue (opened idempotently at setup, closed when done); listing copy + justifications stay in the dashboard, where they live.Replacing
cer/permission-justifications:cer/privacy-permission-alignment(blocking, test-the-world) — every manifest permission must be disclosed inPRIVACY.md, the one release artifact that belongs in the repo (it deploys as the public privacy page).cer/permission-added-store-issue(advisory, test-the-work) — a permission added in the change prompts opening the manual dashboard-justification issue. Advisory because the fix is entirely off-repo — no in-repo artifact to block against.cer/release-layoutnow requires onlyPRIVACY.md. Newctx.readBase()compares permission sets against the base, immune to JSON trailing-comma line noise.2 — Split the pack (#156)
chrome-extensionbundled two unrelated concerns. Audit confirmed a clean split (and thecer/ids +DESIGN.mdalready anticipated it):chrome-extension— MV3 coding gotchas (RULES.md), prose only, fingerprinted by the manifest. Applies whenever you code an extension.chrome-extension-release(new) —RELEASE.md, the 7 checks,stubs/. Opt-in: declared when ready to ship, fingerprinted by theRelease: *workflow stubs (not the manifest). Declaring it is the cue to scaffold the machinery + open the first-publication issue; the drift guard auto-migrates repos already shipping release.Payoff: fixes premature enforcement — wanting the coding gotchas no longer arms 7 blocking release checks on a half-built extension.
Verification
69 tests pass (incl. a fingerprint test asserting the opt-in behavior); repo self-run (reference-integrity across the cross-pack links) is clean.
Assumptions worth a look (the decision popup kept failing this session, so I took the recommended path — redirect any here)
Release: *stubs (opt-in + self-healing migration) vs. pure opt-in with no fingerprint.cer/privacy-permission-alignmentcurrently requires every permission inPRIVACY.md, including non-data ones likealarms(acceptable with a reason, or the check could be narrowed to privacy-relevant permissions).🤖 Generated with Claude Code