fix(review-gate): require strict current-head review

[lamemustafa]

Summary

Root Cause / Decision Record

• What failed, changed, or was ambiguous?
• Why is this the smallest safe fix?
• Which review threads, issues, or release gates does this PR close?

Scope

• Runtime:
• Tests:
• Docs/governance:
• Explicitly out of scope:

Pack Workflow Preflight

• pnpm workflow:preflight was run before editing/push, or the skip reason is documented.
• This PR was opened from a Pack branch, not master.
• I checked latest master Pack AGENTS guidance or recorded the stale-guidance warning.
• PR body keeps the required Pack privacy/review/verification checklist visible.

Sanchika Adoption Gate

• If this PR consumes @sanchika/* packages or copied Sanchika guidance, I
  read sanchika/docs/adoption-pack.md in the coordinated parent worktree.
• If this PR consumes Sanchika, it links ComplyEaze and Axal completion evidence
  and records the Sanchika commit or copied guidance used.
• This PR does not import ../sanchika, sanchika/packages/*/src, or parent
  source paths.

Privacy And Data-Flow Impact

• No new browser permissions.
• No new host permissions.
• No new network calls.
• No analytics, telemetry, ads, or session replay.
• No credential, OTP, CAPTCHA, cookie, token, GST file, or taxpayer-data capture.
• Public copy and privacy declarations are updated if behaviour changed.

Sensitive Surface Review

• Current tab / portal target binding is preserved or intentionally changed.
• Download completion remains evidence-backed and fail-closed.
• Ambiguous side-effect delivery cannot be reported as confirmed success.
• Service-worker durability impact is understood and documented.
• Real taxpayer data, local paths, raw URLs/referrers, and portal HTML are absent from the diff.

Chrome Web Store Impact

• This PR does not expand beyond the existing Chrome Web Store V0 listing unless every gate in docs/PUBLICATION_READINESS.md is checked.
• Full fiscal year ships in the one binary but stays out of Store-advertised scope until its evidence gates are recorded.
• Store copy, README status, Privacy QA, and reviewer instructions were reviewed if user-facing behavior changed.
• CI ZIP creation, provenance, and protected publishing are treated as release evidence, not manual store-submission sign-off.
• PR title uses Conventional Commits so Release Please can bump Pack after merge.

Verification

• pnpm install --frozen-lockfile
• pnpm audit --audit-level high
• pnpm exec wxt prepare
• pnpm exec prettier --check .
• pnpm exec eslint . --max-warnings 0
• pnpm exec tsc --noEmit
• pnpm exec vitest run
• pnpm exec wxt build
• node scripts/verify-extension-package.mjs .output/chrome-mv3
• pnpm exec wxt zip
• node scripts/verify-extension-zip.mjs
• node scripts/write-release-provenance.mjs
• node scripts/verify-github-release-assets.mjs --tag <tag> --zip <zip> --checksum <sha256> --provenance <json> when release assets exist
• node scripts/publish-chrome-web-store.mjs --zip .output/<zip> --provenance .output/pack-release-provenance.v1.json --publisher-id <id> --dry-run true
• git diff --check
• pnpm review:gate -- --strict-head-review --wait-head-review-ms 180000 before merge/readiness claim; a missing Codex review blocks readiness:

Artifact Evidence

• CI run:
• ZIP artifact:
• ZIP SHA-256:
• Clean source/tag or head SHA:

PR Review Follow-Up

• GitHub Actions completed.
• Autogenerated Codex/bot review comments inspected after checks completed for the latest head SHA.
• Inline review threads are resolved, outdated, or answered with evidence.
• No commits were pushed after the last required human/bot review without re-review.
• Any follow-up PRs or issues are listed here instead of being left implicit.

Thread/comment	Disposition	Commit or evidence
	accepted / fixed / outdated / follow-up

Screenshots

Use synthetic data only.

DCO

• Commits include Signed-off-by: trailers.

[lamemustafa]

Independent validation at cd7bd12, in my own worktree. One finding, and two corrections in your favour.

The full suite passes for me: Tests 2080 passed (2080), Test Files 124 passed (124), 164s, zero failures. Your failing run was the #200 flake, and I can show the cause rather than assume it: my lane poller recorded vitest=9 at 16:29–16:31, which is when your full run was executing. The peer lane was running its own suite concurrently. The staggering rule I wrote into both prompts did not hold — worth noting because it was my mechanism, not your mistake.

Also re-ran your remaining gates independently: tsc, eslint, prettier, wxt build, package verification and workflow:preflight all clean.

FINDING — package.json:51 still waives the requirement your docs now forbid.

verify:pr is:

pnpm workflow:preflight && pnpm review:gate -- --strict-head-review \
  --required-review-author chatgpt-codex-connector --wait-head-review-ms 180000 \
  --poll-interval-ms 10000 --allow-missing-head-review

Your AGENT_REVIEW_RECTIFY.md change now says, correctly, that for local PR readiness a timeout "does not waive the current-head review requirement; otherwise the wait is a timer rather than a gate." But verify:pr is the packaged local PR-readiness command — the one-liner an agent is most likely to reach for — and it still passes --allow-missing-head-review.

So the repository now documents the rule in one place and ships the waiver in another, which is the same shape #211 exists to close: four call sites, four different forms, and the convenient one is the unsafe one. You flagged this as outside the stated scope and you were right to flag it; I think it is in scope, because it is a documented review-gate call site and I simply failed to name it.

Suggested: drop --allow-missing-head-review from verify:pr, and with the strict default now in place you can drop the explicit --required-review-author too, so it matches the short form your docs prescribe.

Correction 1 — you were right about the workflow and I was wrong. .github/workflows/review-gate.yml does already pass strict mode, the required author, the wait and the waiver. My "neither flag" claim came from grepping a YAML folded scalar (>-) and matching only its first line. Leaving that file unchanged was correct.

Correction 2 — the strict-only default is the right shape. requiredReviewAuthor defaults only under --strict-head-review, so non-strict callers are untouched and CI keeps working because it passes the author explicitly. Keeping prFindingAuthor on the old unconditional default is the detail I would have got wrong: the findings author and the head-review author are different questions that happened to share a value.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c6d6e7e2e5

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[lamemustafa]

Closeout, per docs/AGENT_REVIEW_RECTIFY.md — and for once there is no audit gap to record.

This is the first PR today merged with a genuine bot review of its merged head. chatgpt-codex-connector reviewed c6d6e7e, which is the commit that merged. #210 merged with reviews only on earlier heads, #212 and #213 the same, and #214 merged with no bot review at all. Fitting that the exception is the PR which fixed the gate that makes this checkable.

Verified on merged master 78b74d1, clean worktree: Tests 2080 passed (2080), Test Files 124 passed (124), plus tsc, eslint, prettier, wxt build and package verification. Reconciles against the 2079/124 baseline at dbcd0cb, +1 for the test added here.

The fix demonstrated end to end. Running the short documented form against a PR whose head has no review:

pnpm review:gate -- --strict-head-review
No review was found for current head 04541a84...

That is the defect closed. Before this change the same command passed on reviews that were my own thread replies.

A correction to my own earlier report on this PR. I said it was clean and mergeable when the strict gate passed and threads were clear — but a Review gate CI check was red at the time, from a run predating the thread resolutions. I checked two of the three signals and reported the third by omission. Re-running the workflow turned all six checks green, and only then was the claim true. The failure was stale rather than real, but the claim was not sound when I made it.

Five call sites, in the end. I filed #211 naming three, one of which turned out to be wrong: .github/workflows/review-gate.yml already passed every flag, and my claim came from grepping a YAML folded scalar and reading only its first line. Codex found the fourth (package.json's verify:pr) and the fifth (the PR template) after I asked it to assume my list was incomplete.