Version Packages

[khan-actions-bot]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

review@1.18.0

Minor Changes

• 8c678cb: A prose judge now runs inside every sub-agent's submit_result path, the way plain-prose runs it: a pinned judge model (claude-opus-4-8; five calibration runs moved it up from haiku, whose verdicts flickered between runs and re-flagged carved-out idioms) judges each finding's prose against the vendored plain-prose rubric (verbatim from the reference implementation, plus a per-label loose length tier), and a failing finding is rejected back to its own AUTHOR, who rewrites it in-session with its repo context intact and resubmits. No fresh-context rewrite exists (an earlier shape's rewriter confabulated a flag name on the live fixtures, which is why the author does it). Enforcement is structural rather than eval-gated: bounces are capped at 2 per agent and then the submission posts as-is; a judge error or unparseable verdict accepts immediately; a Stop hook redirects an agent ending without calling the tool back to it (capped at 2), so the free-text fallback path shrinks instead of bypassing the gate; and the run records four states (skipped/pass/fail/error; pass/fail/error per finding, skipped per fallback agent or per finding dropped between attempts) in judge-prose-verdicts.json plus the dispatch result's proseJudge block, so a broken judge reads as errors, not clean prose. Bounces are monotonic: a finding that passed is never re-judged on a resubmission (the bounce asks the author to rewrite only the failures, so a flickery judge cannot flip an untouched finding to fail and spend bounce budget), and a resubmission that drops a finding is recorded in the artifact. The judge's reply is parsed with agent-json.ts's shared leniency, not a greedy brace slice, and the dispatch runner retains the last assistant text so a free-text agent the Stop hook redirected into error_max_turns still delivers its final instead of shedding the dimension. The judge call goes through the Agent SDK (the sandbox strips ANTHROPIC_API_KEY and proxy-injects auth, so a raw fetch would fail-open the judge into a silent no-op). The sub-agent discussion field contracts carry the same shape line (at most one claim, one line of evidence, at most one question), so findings are born short and the judge stays a backstop. Calibrated on the three Khan/webapp#41609 comments ("still as poetic as before"); eval/judge-prose-live.ts pins that the named complaint fails the judge.
• 7d9b6d6: Run 32390393344 (webapp#41609) posted one finding twice: two sources filed it on the same line of moderation_helpers.go, the claim-clusterer correctly proposed the pair as one cluster, and the grounding tripwire vetoed the merge as "ungrounded" because the cluster's evidence spoke in the hunk's identifiers (_configIncludesModeration, shouldModerateDuringMainCompletion) while both claims spoke config-side (pre_flight_moderation_check, config_files), zero shared salient tokens. The evidence is model prose with free word choice, so that check was grading the clusterer's phrasing rather than the identity it asserted. Two changes: an exactly shared anchor (the member sits on the survivor's own line; paths already match structurally) now grounds a proposed member with no vocabulary needed, and salient tokens fold casing styles (PreFlightModerationCheck and pre_flight_moderation_check are one token) so the vocabulary path tests names, not spellings. Grounding a member against the survivor's own text was considered and rejected: run 30587343777's cap survivor names staleAfter in a while-here aside, and the distinct staleAfter finding would falsely ground against it (that counterexample stays pinned in the tests). The 41609 pair is replayed verbatim as a regression fixture and now merges to one comment. Each clusterer-absorbed copy in dispatch-result.json now records which path grounded it (groundedBy: "anchor" | "evidence"), so the planned audit of "ungrounded" rejections can tell the two apart, and the clusterer prompt no longer promises the unconditional mechanical discard the code stopped making.
• 8c7736d: The PR's linked Jira ticket is now staged deterministically as ticket-context.json (new lib/stage-ticket.ts, run from stage-pr.ts): when a consumer configures REVIEW_JIRA_BASE_URL (variable) plus REVIEW_JIRA_EMAIL/REVIEW_JIRA_API_TOKEN (secrets), the staging collects every issue key the PR references (title, head branch, description; known key-shaped noise like UTF-8 or SHA-256 sinks below plausible keys before the cap of 5 applies) and fetches each read-only on the host, before the agent starts; every degradation (unconfigured, no key, 404, fetch failure) stages {available: false, reason} and never fails the run. This replaces the completeness reviewer's in-prompt Jira/Confluence read grant, which was dead text: no consumer ever provided the token it promised and the firewall egress never included the Jira host, so its fallback clause fired on every run. The agent sandbox needs no Jira egress and never sees the credentials. The first-principles reviewer gets the staged ticket too (its whole mandate is the stated rationale, which it previously read only via the author's summary), plus two prompt rules minted from webapp#41609: a finding that pushes against a stated, rationale-backed decision must rebut the rationale with new evidence or not post (an observation your own prose concedes is not a finding), and several observations sharing one premise merge into one finding.

Patch Changes

• a0a6d8a: Raise the sub-agent turn cap from 30 to 100. The correctness pass on large diffs (review: security-auth workflow-security hunts and pwn-request corpus case #295, runs 32422547351 and 32491692754) hit the old cap on two consecutive runs, ending each in error_max_turns and a HOLD_FOR_HUMAN at $11.74-$13.45 of wasted sub-agent spend per run. The turn cap is a loop guard; credit spend, per-finding tool calls, and wall clock are metered separately, so agents that finished under the old cap (8-37 reported turns) are unaffected. The eval producer's cap is bumped in lockstep so trials keep reproducing prod behavior.

  Also raise the dispatcher's Bash ceiling from 20 to 30 minutes (BASH_MAX_TIMEOUT_MS 1200000 to 1800000, and the prompt's dispatcher timeout with it) and the job's timeout-minutes from 40 to 50. The dispatcher awaits four sequential agent stages (triage, finder fan-out in waves of 4, the clusterer, claim validation), each sub-agent capped at 15 minutes and re-dispatched once on a parse failure, so 30 minutes is a pragmatic cap sized to observed runs, not a bound; run 32418662895 (review: a prose judge on every posted finding #362) was killed mid-claim-validation at the 20-minute line and posted nothing, and longer-running agents under the new turn cap make that more likely, not less.