[🔥AUDIT🔥] review: bump installed reviewer to review-v1.11.0

[jwbron]

🖍 This is an audit! 🖍

Summary:

Why

The reviewer installed on this repo (.github/workflows/review.md) has been
pinned at review-v1.7.0 since #276 (2026-07-21), four releases behind the
shared source. Everything the shared package has shipped since then runs in
consuming repos but not here, including one change that makes an existing
setting in our own ROUTING inert:

• v1.8.0 patch 034181f: gh-aw's safe-output sanitizer strips XML/HTML
  comments, so the hidden fingerprint stamp a review body carries never
  reached the PR; every re-review planned no-prior-fingerprint and
  escalated to full depth. Our ROUTING has said re-review scoped since
  review: enable scoped re-reviews (follow-up to the v1.7.0 bump) #277, and on v1.7.0 that dial does nothing. The plan CLI now falls back to
  the Step 9 cache-memory record and reports stampSource.
• v1.8.0: the deterministic-orchestrator slices land. Staging becomes a
  pre-agent-steps: step (lib/stage-pr.ts), scripted dispatch becomes the
  only mode (the ROUTING dispatch dial is retired; we never set it),
  Steps 4-6 become code (lib/submission-plan.ts), and the
  dispatch-conformance gate blocks a verdict whose sub-agent outputs do not
  exist (the v1.7.0 acceptance trial caught the orchestrator submitting a
  REQUEST_CHANGES after dispatching zero sub-agents).
• v1.9.0/v1.10.0: open-thread suppression actually fires (it was
  unreachable on every conforming run, so re-reviews re-posted findings an
  open bot thread already tracked), threads.json / human-threads.json are
  staged by code, and a suppression is attributed to its best-matching thread
  rather than the first one it clears.
• v1.11.0: a sub-agent the provider blocks is named as a refusal rather
  than "malformed output", failure detail and per-agent tool-call counts are
  kept, and a refused reviewer falls back to claude-opus-4-8 instead of
  silently costing coverage.

Also picked up: Gerald .github/NOTIFIED support, the per-lens consumer
payload seam, and the documentation reviewer (opt-in; not enabled here).

Why not gh aw update

Same as #276: gh-aw's resolveLatestRef rejects changesets-style prefixed
tags (review-v1.11.0) as non-semver, falls through to branch resolution, and
404s. Updates of this workflow stay manual.

What this PR does

• Replicates gh aw update's 3-way merge by hand: base = review-v1.7.0
  source, ours = installed copy, theirs = review-v1.11.0 source (identical
  to current main), then gh aw compile review.
• Two local overrides retire, because upstream now carries them.
  timeout-minutes: 40 is the shared default as of v1.8.0 (82af000), and the
  sandbox.agent.version: v0.27.27 pin plus the models: claude-fable-5
  pricing block were removed at source in 98f686f. Both override comments
  said they went away at this bump; they do.
• The remaining differences are the documented overrides and nothing
  else, enforced by review-pins.test.ts: the same-repo fork guard in
  if: and its roles: all comment (public-repo hardening), the
  commented-out observability: block (the GH_AW_OTEL_SENTRY_* secrets
  still exist neither on this repo nor at org level), max-ai-credits: 2500
  with its REVIEW_MAX_AI_CREDITS mirror, and the comment on the lib
  checkout ref:.
• source: and the lib checkout ref: both move to review-v1.11.0 in
  lockstep, and the recompiled lock picks up the new pre-agent staging step,
  the dispatcher's npm ci, the dispatch-conformance gate post-steps step,
  and BASH_MAX_TIMEOUT_MS: 1200000 (the blocking dispatcher call).
• No consumer-config change is needed: .github/aw/review/ROUTING carries no
  retired dispatch line, no correctness-checks.md alias to migrate, and
  the new documentation reviewer stays off until a repo adds
  enable documentation.

Verification

• pnpm test: 1618 tests across 69 files pass, including
  review-pins.test.ts (source/ref/lock literals all review-v1.11.0, and
  every hunk against the pinned source carries a KHAN/ACTIONS LOCAL OVERRIDE marker) and version-sync.test.ts.
• pnpm typecheck: clean.
• gh aw compile review: 0 errors, 0 warnings.
• No changeset needed: both files are under .github/, the check's default
  exclusion, and the shared workflows/review package is untouched.

[github-actions]

Review Guidance

github-actions (1 file)

File	Reason
review.md	The installed shared PR-reviewer workflow; its frontmatter is this repo's real permission, secret, and network surface, so a human should confirm nothing is loosened.

Excluded from review (1 file)

Not individually reviewed — generated, formatting-only, or
fully explained by a common pattern above:

• .github/workflows/review.lock.yml — generated

[github-actions]

suggestion (non-blocking): This is the second manual bump for the same gh-aw limitation — the process is now automatable and could live in CI instead of a hand-merged audit PR. Both #276 and this PR replicate gh aw update by hand because upstream resolveLatestRef rejects changesets-style tags. But the constraint that made this manual has weakened: this repo hosts both the source and the install, and review-pins.test.ts (which I read) now requires every local override to carry a KHAN/ACTIONS LOCAL OVERRIDE marker adjacent to its hunk — meaning the overrides are machine-locatable and the merge is mechanically reproducible (checkout tagged source, re-apply marked hunks, gh aw compile). A small script or release-triggered workflow could open this PR automatically whenever a review-v* tag lands, with the existing tests as the gate.

A sketch, not a committable replacement:

As a follow-up, either (a) script the bump (re-apply marker-tagged override hunks onto the tagged source and recompile, opening a PR on each `review-v*` release), or (b) file/track an upstream gh-aw issue for `resolveLatestRef` rejecting prefixed tags so `gh aw update` can take this over — and link whichever from the 'Why not gh aw update' section so the third bump doesn't re-derive this.