PR review follow-up — countryos/global/* pull requests

You are in the cms monorepo clone. Humans review the draft PRs that Country OS tasks open. Your job: find review comments nobody has answered yet, act on them, and turn any general guidance into durable memory. Reviews are the main channel where humans teach this system — losing that feedback is the worst failure mode of this task.

Step 0 — Load context

Read memory/review-feedback.md in the _global workspace (create it from the format below if missing). You will apply and update it.

Step 1 — Find unanswered feedback

List every open Country OS PR, whatever workspace opened it:

gh pr list --state open --json number,title,headRefName,isDraft \
  --jq '.[] | select(.headRefName | startswith("countryos/"))'

You act only on countryos/global/* PRs. A PR on another prefix (countryos/tn/*, countryos/de/*, …) belongs to that country's workspace, whose memory/review-feedback.md you cannot write from here — touching its code while filing the lesson in the wrong memory is how a rejected pattern comes back. For those: read the threads, and if any is unaddressed, name the PR and what it asks for in your final report so a human routes it. Change nothing.

Before 2026-08-11 this task's own PRs used the countryos/fr/* prefix (all three are merged). Nothing open uses it, but if an old one resurfaces, treat it as ours.

For each PR you own, fetch inline review comments (threaded via in_reply_to_id) and top-level reviews/comments:

gh api repos/{owner}/{repo}/pulls/{n}/comments
gh pr view {n} --json reviews,comments

A thread is unaddressed when its last comment is not ours (ours = the git author configured in this clone / the PR author account). Our reply is the "handled" marker — always reply when you act, or the next run will redo it.

If there is nothing unaddressed, report that and stop.

Step 2 — Act on each unaddressed thread

Classify and act; reply in the reviewer's language:

Change request — check out the PR branch, implement exactly what was asked, commit (fix(review): <what> (per @reviewer)), push, then reply summarizing what changed. Stay within the comment's scope.
Rejection ("this hides the problem", "don't do this kind of fix", "revert this") — revert the relevant commit(s) on the branch (git revert, or rewrite the change to what the reviewer describes if they proposed a direction), push, reply. Then ALWAYS distill a rule (step 3).
Question — answer it factually in a reply (reference the Sentry issue, code, or run journal as evidence). No code change unless the answer reveals one is needed.
Approval / "ok" — no reply needed; nothing to do.
Ambiguous — do not guess. Reply with one precise clarifying question and move on; the next run picks up the answer.

Never argue. If you believe the reviewer is mistaken, state your reasoning once in the reply, make no code change, and defer — the human decides.

If every substantive commit of a PR ends up reverted, say so in a PR comment and leave the PR open for the human to close — never close, merge, or mark ready yourself.

Step 3 — Distill durable rules into memory

For every piece of feedback that generalizes beyond the specific line — especially rejections — add an entry to memory/review-feedback.md:

## <short imperative rule>
- **Date / source:** <YYYY-MM-DD>, @<reviewer> on <PR link or comment link>
- **What happened:** <one sentence: what we did, what the reviewer said>
- **Rule:** <the general rule, stated so a future run can obey it without
  reading the original thread>
- **How to apply:** <concrete guidance: what to do instead, or when the
  pattern IS acceptable>

Update an existing entry instead of duplicating when the same rule comes up again (append the new source). These rules are binding for every future run in this workspace (CLAUDE.md enforces this) — write them precisely enough to be obeyed, and narrowly enough not to ban legitimate fixes.

Do not record one-off, line-specific requests as rules — those are handled by the commit and reply alone.

Step 4 — Record