ReviewArmor V1.1 — what changed and why
V1.1 is a rubric release. The headline feature isn't a new finding or a new integration — it's a mental model for how severity is assigned, and a set of findings that finally honor it.
The framing
During V1.1 design, Suhaib (InfoBlend) gave us the line the whole rubric now hangs on:
"Severity tracks what the developer can actually do about it."
That collapses into three bands:
| Severity | What it means | What the dev does |
|---|---|---|
| HIGH | A code fix exists right now. | Edit the manifest / source. Drop the broad permission, fix the CSP, add the missing icons. |
| MEDIUM | No code fix — but a docs fix exists. | Explain it in reviewer notes or dashboard fields. The structure is correct; the reviewer just needs the why. |
| LOW | FYI. | Usually nothing. Be aware in case it interacts with something else. |
Pre-V1.1, ReviewArmor folded code-fixable issues and structurally-broad-but-legitimate ones under the same finding. A dictionary tool that legitimately needs content_scripts.matches to cover http://*/* and https://*/*would see a HIGH it couldn't honestly resolve, and the score wouldn't move when the dev did the right thing. V1.1 fixes that by making the finding ID itself carry the severity contract.
What's new in V1.1
- Broad URL scope split into 3 findings. Previously tracked under a single HIGH; V1.1 separates them by what the dev can actually do:
broad_host_permissions(HIGH, code — narrow it or drop it),broad_content_scripts_matches(MEDIUM, docs — justify the surface area in reviewer notes), andbroad_war_matches(LOW, FYI — confirm exposure is intentional). The redundancy findingpermission_redundancy_double_broadremains HIGH and fires only when both are broad. This is the first concrete proof point of the rubric. __MSG_*localized manifest handling. Extensions using_locales/no longer get garbage findings when the manifest references__MSG_*placeholders. When localized strings affect a finding's narrative, the UI surfaces a banner asking for the resolved description text.- Chromium multi-store framing.The same scan applies across Chrome Web Store, Edge Add-ons, Brave, and Opera, which share the same reviewer heuristics. We're explicit about this in the UI rather than implying a Chrome-only audience.
reviewer_notesmitigation language. Generated reviewer notes now use imperative voice, quote verbatim manifest values, and — where it matters — state which alternatives were considered and rejected. Reviewers asked for receipts; we give receipts.- FEATURE-IMPUTATION rule. Permission justifications no longer hallucinate user-facing features from technical mechanisms.
storagecan be asserted as "cache for performance" from the manifest alone; it cannot become "definition history view" unless the description, content scripts, commands, or overrides actually ground that feature. The rule keeps generated text honest. submission_ready_with_notesverdict label. The upper band (roughly 80–95) used to read as the ambiguousminor_issues. It now reads as a decisive action: submit, and read the notes before you do.
What V1.1 doesn't do
V1.1 is a manifest-only scan. It does not read your source code, does not execute your extension, and does not predict whether Chrome Web Store will approve your submission. It surfaces the signals a reviewer is statistically likely to flag and tells you which ones you can fix in code versus which ones you should explain in notes. The verdict is a self-check, not a verdict from Google.
What's next
V1.2 may revisit the full verdict ladder if user feedback indicates the bands aren't carving at the right places. nativeMessaging and debugger are on the watchlist for FEATURE-IMPUTATION: the standing rule currently applies to them, but both are cases where the user-facing-feature question gets genuinely hard, so the generated justifications may need exception handling once a real extension hits the scanner with one of them declared.