Reader Protocol PR Review

Use this when reviewing a PR in the Reader's social/atmosphere/mastodon territory — slice work for the protocol-adapter pattern, optimistic mutations, or the shared post-card components. The recurring findings are concrete enough to be a checklist; the rubric below comes from the CM-658/CM-660 cycle where the same issues appeared in both PRs.

Rubric

For each finding write:

| Severity | File:line | Issue (1-2 sentences) | Suggested fix |

• Severity tags: blocker (PR can't merge), important (real bug, would cause user-visible issues), nit (cleanup or hardening).
• File:line: anchor with absolute path or repo-relative path so the comment can be left inline on GitHub. Use gh api repos/Automattic/wp-calypso/pulls/{n}/comments to post inline replies (not top-level PR comments) when the line is in the diff.
• In-PR vs follow-up: explicitly call this out. Architectural changes that span multiple slices belong in a follow-up issue. Defensive hardening, missing default arms, etc. are cheap to fold in.
• Verdict line: Approve / Request changes / Needs more discussion. If approve, list any follow-ups worth filing as separate tickets.

Cap reviews at ~700 words. The reviewer's signal-to-noise ratio matters — detailed prose drowns out the actual blockers.