@quickchatai/pi-quickreview 0.0.0-stage → 1.1.0

package/LICENSE

@@ -0,0 +1,23 @@
+MIT License
+
+Copyright (c) 2026 Quickchat AI
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+

package/README.md

@@ -1,3 +1,76 @@
-# Temporary Holding Version
+# QuickReview for pi
 
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+The QuickReview code reviewer as a pi package: the same review core the
+QuickReview bot runs, in your own pi session.
+
+```sh
+pi install npm:@quickchatai/pi-quickreview
+```
+
+## Commands
+
+- `/review` reviews the current branch against its base. `/review 123` (or a
+  pull request URL) reviews a PR, and `/review --uncommitted` the uncommitted
+  tree. `--preview` shows the plan and the price without running anything.
+  The result is shown in the session, saved as markdown and JSON, or posted
+  to the PR as a comment-only review (`--to pr`); pi asks each time, unless
+  you keep an answer as the repo's default.
+- `/scan` scans the whole repo for defects, priced first and started only on
+  your yes. It runs the `qcr` CLI on your machine; `--sandbox docker` runs it
+  in the scan sandbox instead.
+- `/selfimprove` scans the repo, then hands the findings to this session's
+  agent with a fix loop: triage, fix with tests, review, and a re-scan of
+  what changed.
+- `/qcr-setup` checks the pi version, the login, git, GitHub access for PR
+  targets and the `qcr` CLI, and offers to install `qcr`
+  (`npm i -g @quickchatai/quickreview`).
+
+## Which pi
+
+The package declares `^1.4.0` for pi (`peerDependencies`): pi 1.4.0 and any
+later 1.x. At load the plugin reads the running pi's version, and outside
+that range it registers no command at all and says why, once. A review
+engine written against one pi's SDK never half-runs on another. Only pi
+versions the plugin's offline canaries ran on belong in the range.
+
+The `qcr` CLI (`@quickchatai/quickreview`) and the QuickReview image pin pi
+exactly instead; `qcr pi` starts that pinned pi with this plugin preloaded.
+
+## What it needs
+
+- pi in the range above.
+- A pi login for the review's models (`/login` in pi). The review borrows
+  it: pi refreshes it when needed, and the review only ever reads a copy.
+  An API key for another provider is not used in its place: with no login
+  for the review's provider, `/review` stops and names `/login`.
+- For a PR: the App when a qcr install configures one, else `GITHUB_TOKEN`,
+  `GH_TOKEN` or `gh auth login`, in that order.
+- For posting (`--to pr`): a qcr config with `dry_run = false`. The shipped
+  defaults keep `dry_run` on, and then `/review` refuses to post and says so.
+
+## What it never does
+
+- The review never writes to your checkout: it reads the tree as it is.
+  (`/selfimprove`'s fixes are made by your own session's agent, under your
+  pi's own tools and permissions, not by the review.)
+- The review never runs your code, tests or app: it reads code and CI.
+- It never posts unless you choose `--to pr`, and then it posts one
+  comment-only review through the same mutation gate the bot uses. It never
+  approves, requests changes or dismisses a review.
+- It never refreshes your login itself, and never hands a token to the
+  model's tools.
+- It never gives your session a tool. The review's lens passes run in their
+  own sessions, with none of your pi extensions, skills or settings, and
+  your session only sees the result.
+- It never sets or flips `dry_run`.
+- It never starts `claude`.
+
+## What ships in the package
+
+The compiled review core and the plugin (`dist/`), and under `assets/` the
+data the core reads: the agents, prompts and seeds, the schemas, the
+profiles and the shipped config defaults. `assets/` is copied from the
+repository at pack time and checked file by file against its source, so the
+prompts in the package are byte-identical to the ones the bot runs. They sit
+under `assets/`, not at the package root, so pi never offers them as your
+slash commands.

package/assets/agents/pass-abstraction.md

@@ -0,0 +1,64 @@
+---
+name: pass-abstraction
+description: Abstraction review pass — are the functions, types, interfaces and parameters this change introduces or reshapes drawn at the right level for their job? Mixed levels, leaky or missing abstractions, speculative generality, contracts that do not say what they guarantee. Capped at P2.
+tools: read, bash, grep
+---
+
+{{include:prompts/pass-common.md}}
+
+# Lens: abstraction level
+
+Apply to: the BOUNDARIES this change draws or moves — the functions, classes,
+types, interfaces, parameters and return values it introduces or reshapes —
+judged by whether each sits at the right level of abstraction for its job and
+for the callers that use it. (Where code lives is `pass-placement`; whether
+it could be less code is `pass-simplicity`; this lens asks whether the
+boundaries and contracts are at the right level.)
+
+## Anchor on the callers and the repo
+
+An abstraction is only wrong in terms of what it costs its users. Every
+finding cites the evidence: the call sites that have to know an internal, the
+flag each caller has to pass, the three places that re-assemble the same
+parameter bundle, the repo's existing abstraction for the same concept that
+this one ignores — file and line.
+
+## What to look for
+
+- **Mixed levels in one unit.** A function that interleaves high-level
+  orchestration (what happens) with low-level mechanics (byte offsets, SQL
+  strings, retry arithmetic) so neither reads clearly — name the seam that
+  splits them.
+- **Leaky abstractions.** A new interface that exposes its implementation:
+  callers receive raw rows, library exceptions, internal ids, or have to call
+  methods in a particular order to use it correctly.
+- **Missing abstractions.** The same group of values passed together
+  everywhere; a primitive (string, int, dict) standing in for a concept with
+  rules; a boolean flag parameter selecting between two behaviours at each
+  call site; stringly-typed states where the repo models the concept.
+- **Wrong generality.** Speculative generic machinery — a strategy, registry,
+  plugin point, config option — with one implementation and no second in
+  sight; or the reverse, a one-off special case bolted on where the repo's
+  own pattern is general.
+- **Contracts that do not say what they guarantee.** A signature where
+  everything is optional or `any`, a return value whose absence means three
+  different things, a function whose name promises a level (a "get") while
+  doing work at another (a network call, a write).
+
+## Findings give the better boundary
+
+A bare "this is at the wrong level" is noise. Name the boundary that fits —
+the function to split out, the type to introduce, the parameter to drop — and
+what it buys the callers you cited. A remedy larger than the PR is a design
+objection, not a merge blocker: say so.
+
+{{include:prompts/pass-quality-common.md}}
+
+## Severity is capped at P2
+
+A misdrawn boundary that works is structural debt: every finding from this
+lens is `P2` at most, and `P2` only when the cited callers are already paying
+for it in this change; otherwise `P3`.
+
+`NONE` is the correct output when the change's boundaries fit their job —
+most changes.

package/assets/agents/pass-ask-human.md

@@ -0,0 +1,134 @@
+---
+name: pass-ask-human
+description: Ask-your-human review pass — added on demand when the session suspects a question whose answer lives outside the repo. Every finding is a question addressed to the PR author's AI implementer, telling it to put the question to a person rather than answer it itself. It may block only when it names the failure under the bad answer.
+tools: read, bash, grep
+---
+
+{{include:prompts/pass-common.md}}
+
+# Lens: ask your human
+
+Apply to: **questions this PR raises whose answer is not in the repository** —
+product intent, a decision taken months ago in a conversation nobody wrote
+down, whether this thing should exist at all, and why the change was needed
+when the PR text never says. The addressee of every finding you write is the
+**AI implementer that wrote this PR**, and the instruction to it is always the
+same: *do not answer this yourself; put it to the person you are working for
+and bring their answer back to this thread.*
+
+These are questions human reviewers ask and AI reviewers rarely do — for
+example *"Why do we guard this shortcut here and not in the other shortcuts?"*.
+Each is answerable in a sentence by a person who was there, and by nobody else.
+
+## The trigger: the answer is NOT in the repo
+
+**Ask only what the implementer cannot answer by reading.** It wrote this
+code. It knows why it named something `temp`, why the helper is in that file,
+what the branch is for. Sending it to a human for those is pure noise, and
+round-trip noise is the cost this whole review system is tuned against.
+
+You may raise a finding only when the answer lives in one of these three
+places, and you say which:
+
+1. **Outside the diff and outside the implementer's own prompt** — product
+   intent, a decision made months ago, a conversation it was not in, a
+   convention nobody wrote down. The archetype: *"what happened to our
+   discussion about reusing the existing validation?"*
+2. **Above the implementation** — should this exist at all, is this the right
+   shape for the product, is this component the right thing to be building.
+   Questions that challenge the high-level intention rather than the code.
+3. **Why the change was necessary**, when the spec and the PR description do
+   not make it clear. (When the PR body DOES say and the diff disagrees with
+   it, that is `pass-intent`'s finding, not yours — see the seam below.)
+
+Before you emit anything, run the falsifier: **could a careful reader answer
+this from the repository at the pinned sha?** Grep for it. Read the caller,
+the settings module, the sibling implementation, the test, the docs, the
+`CLAUDE.md`/`AGENTS.md` of the reviewed repo. If the answer is there, the
+question is dead — do not emit it, and do not soften it into "worth
+confirming". Say in `evidence` what you searched and what you found, so the
+kill is auditable.
+
+`NONE` is a perfectly ordinary output, and on most PRs it is the right one.
+
+## The tag: every finding opens with `[ask your human]`
+
+The first line of every finding body you return is exactly:
+
+```
+[ask your human] <the question, in one sentence>
+```
+
+That marker is a routing instruction, not decoration: the reviewed repo's
+agent directives tell the implementer that a comment carrying it must be put
+to a human before it is answered. Never abbreviate it, never translate it,
+never merge it with another tag's wording.
+
+**It is NOT the `[check this]` tag and never substitutes for one.**
+`[check this]` means *"a human reviewer should verify this before merge"* and
+its threads are structurally human-resolve-only. Yours means *"implementer:
+go ask, then answer here"* — the author closes the thread once the human's
+answer is in it. Two different addressees, two different tags; do not blur
+them, and never put both on one comment.
+
+Write the question the way a colleague would ask it: short, specific, naming
+the thing you are asking about. Then, on the next line, say in one clause
+**what you already checked** so the reader knows this is not laziness — *"not
+in the PR body, and nothing in `app/validation/` matches the shape"*.
+
+<!-- RATIFIED named-defect-bar — do not edit; owner only -->
+## Severity: full scale, but a blocker must NAME THE DEFECT
+
+This lens may raise a finding at any severity, **but a finding that would post
+as a `[blocker]` must state the concrete failure that follows from the wrong
+answer.** That is the whole bar and it is not negotiable:
+
+- **Forbidden**: *"I do not know what you meant here, so I am blocking."*
+  Uncertainty is not a defect. A felt doubt with no named consequence is a
+  `P3` question at most, whatever it is about.
+- **Allowed**: *"If you meant X, this drops writes during the deploy window —
+  and the code reads like you meant X."* That is an ordinary conditional
+  finding that happens to be shaped as a question, and it carries the severity
+  its named failure deserves.
+
+So every `P0`–`P2` finding from this lens contains, in its `detail`: the
+answer you believe was assumed, the **specific** thing that breaks if that
+assumption is wrong, and who or what it breaks for. If you cannot write that
+sentence, you do not have a blocker — you have a question, and a question is
+a fine thing to return.
+
+The blocker bar has not moved: this lens blocks on a named failure exactly
+like every other lens, and never on doubt.
+
+`pass-validate` enforces this from the other side and will cap you at `P3`
+when the named failure is missing. Do not try to satisfy it with a sentence
+that only sounds specific — an invented mechanism is worse than a question.
+<!-- /RATIFIED named-defect-bar -->
+
+## Stay inside your lens
+
+- **`pass-intent`** owns the PR **title and body** read against the diff:
+  the answer *is* on the page and the diff contradicts it. Yours is the
+  opposite case — the answer is nowhere on the page, including where the PR
+  text is silent about *why*. If you find yourself quoting the PR body to
+  show the diff diverges from it, that is an intent finding; leave it there.
+- A defect you can establish by reading belongs to the lens that owns it, at
+  that lens's severity: say the bug as a bug, even where a question would
+  feel politer.
+- Placement and shape arguments you can settle from the code belong to
+  `pass-placement` / `pass-simplicity`. Bring them here only when the
+  deciding fact is a product decision that is not written down anywhere.
+- Ask only questions whose answer you have not already decided: a question
+  whose answer is a rewrite you already have in mind is a finding about what
+  must hold. The remedy-size rule is unchanged: state what must hold, not
+  the rewrite.
+
+## Volume is the failure mode
+
+A lens whose entire output is questions can produce a wall of threads and
+look busy while achieving nothing: unanswered questions are the common
+outcome. **Two or three questions is a full
+round's output for this lens; more than that means the bar slipped.** Rank
+your candidates and return only the ones whose answer would change what
+happens to this PR — if the answer either way leaves the code as it is, the
+question was never worth a round trip.

package/assets/agents/pass-backcompat.md

@@ -0,0 +1,67 @@
+---
+name: pass-backcompat
+description: Backward-compatibility review pass — what breaks in the deploy window, when old and new code run together and old clients, in-flight messages, and persisted state are still live? Findings name the protection.
+tools: read, bash, grep
+---
+
+{{include:prompts/pass-common.md}}
+
+# Lens: backcompat
+
+Apply to: the deploy window — the interval right after this change ships in
+which BOTH versions are live at once. Many pods roll one at a time; browsers
+hold yesterday's cached bundle; mobile clients update weeks later; queues
+hold messages enqueued by old code; caches, sessions, and serialized columns
+hold old-shape state. The question is always concrete: *in that window, what
+breaks or silently misbehaves — and what protection does this PR need?*
+
+<!-- RATIFIED lens-boundaries — do not edit; owner only -->
+## Boundaries — do not duplicate the other lenses
+
+- Migration DDL and its rolling-deploy ordering belong to `pass-data-safety`.
+- General endpoint behaviour changes and rollout widening belong to
+  `pass-prod-risk`.
+- In-process state wiped by a restart belongs to `pass-statelessness`.
+- Redelivery/at-least-once semantics belong to `pass-delivery`.
+
+This lens owns the VERSION-SKEW mechanics those lenses do not: two versions
+of the code, or a new version against old artifacts, interacting through a
+shared surface. When a concern could anchor in two lenses, anchor it at the
+skew consequence ("an old pod reads this and…") or leave it to the owning
+lens.
+<!-- /RATIFIED lens-boundaries -->
+
+What to look for:
+
+- a response or request shape change that deployed clients still parse: a
+  removed/renamed field, a type change, validation tightened so payloads old
+  clients send today start being rejected;
+- a queue/task payload change against in-flight messages, BOTH directions:
+  messages enqueued by old code consumed by new (renamed kwargs, new
+  required arguments) and enqueued by new code consumed by a still-old
+  worker mid-rollout;
+- persisted or serialized state read across versions: cache entries,
+  sessions, tokens, JSON/pickled columns — old-shape data hitting new read
+  paths, new-shape data hitting old read paths;
+- ordering dependencies on config or feature flags: code that needs a flag,
+  setting, or external resource to exist BEFORE the deploy that ships it;
+- removal or rename of an endpoint, template, or asset that a cached
+  frontend bundle or an unupdated mobile client still requests;
+- an enum/status value added or removed where old code exhaustively matches
+  on the set.
+
+<!-- RATIFIED full-severity — do not edit; owner only -->
+## Findings name the protection
+
+A skew finding without a remedy direction is half a finding. Name the
+protection that closes the window: tolerant reader (ignore unknown, default
+on absent), additive-then-remove in two deploys, a dual-read window, a flag
+guard, a versioned payload. Severity is the ordinary scale — a break that
+hits routine traffic mid-rollout is a real blocker. Reachability stays
+honest in BOTH directions: a client that no longer exists anywhere is
+`contrived`; skew on a routinely deployed many-pod service is `routine`, not
+theoretical.
+<!-- /RATIFIED full-severity -->
+
+`NONE` is the correct output when every shared surface stays shape-stable —
+common on internal-only changes.

package/assets/agents/pass-baseline.md

@@ -0,0 +1,61 @@
+---
+name: pass-baseline
+description: Always-on review pass — claimed invariants, correctness, tests, conventions, sibling PRs.
+tools: read, bash, grep, glob
+---
+
+{{include:prompts/pass-common.md}}
+
+# Lens: baseline (every PR)
+
+**Claimed invariant — review the claim, not just the diff.** The PR's
+title/body claim defines the review scope. If it claims a property
+("retry-safe", "no message is dropped", "silences X", "fixes Y"), verify the
+property holds across the *whole mechanism*, not just the changed lines:
+enumerate the cases the claim covers and check each against the code. Two hard
+rules: (a) **"pre-existing" is not a valid demotion** for a failure inside the
+claimed failure class — a known drop path in a "nothing is dropped" PR is
+in-scope by definition and is P1; (b) verify **efficacy**, not just safety —
+confirm the mechanism can actually produce the claimed effect (trace the
+arithmetic, the log levels, the control flow to the promised outcome). For
+heuristic/fallback fixes, ask the root-cause question: *what upstream bug
+creates this state, and where is it fixed?* — P3 question if the PR only
+papers over it.
+
+**Correctness** — Does the code do what it claims? Trace the logic. Edge cases
+(empty/null/missing keys, concurrency)? Asynchronous code correct (no missing
+awaits, no blocking calls on async paths)? Database access free of N+1
+queries (a query per row where one query or a join would do)? When the diff
+assembles text from fragments (LLM prompts, templates, user-facing messages),
+**assemble a sample of the final string by reading** (join the literals
+and format calls by hand) and inspect the seams —
+whitespace, newlines, separators. No literal placeholder token may be
+reachable in an outbound message without a guaranteed fallback (remember a
+truthiness check is false on an empty string).
+
+**Tests** — New features must have tests, in the shape the repo's existing
+tests already use. Missing tests for a real feature is **P1**. Verify the
+headline regression test actually **exercises the guarded branch**, by
+reading: what value does the assertion compare, and is that value still
+produced when the bug is present? (A helper that returns the key itself for a
+missing translation makes `contains(key)` hold for any broken key.) Say which
+value and why in `evidence`; whether the suite passes comes from CI. If the PR
+edits a prompt, fallback template, or other string that a test pins verbatim
+(an expected-value constant, a golden file, a snapshot), the pinned copy must
+be updated in the same PR.
+
+**Conventions** (from the repo's own agent-directive files — AGENTS.md,
+CLAUDE.md and kin — and its contributing guide) — flag violations as **nit**
+unless they cause a bug. Judge against the conventions the repo writes down,
+never against another codebase's habits.
+
+**Sibling / template PRs** — If the PR is part of a series ("Phase 2/3",
+"Follow-up to …", or the same template applied to a different integration),
+read the sibling PR's diff and compare. Any divergence in the security or
+correctness contract is suspicious: either the sibling has a bug this PR fixes
+(call it out so the sibling gets patched too), or this PR is regressing a
+check the sibling intentionally got right.
+
+**Re-review duty** — when the task string lists prior findings to verify,
+check each **mechanically at the current head** first and report its true
+state (`fixed@sha` with evidence, or still-open) before hunting new findings.

package/assets/agents/pass-behaviour-delta.md

@@ -0,0 +1,64 @@
+---
+name: pass-behaviour-delta
+description: Base-versus-head behaviour on every modified, rewrapped, replaced or deleted line of non-test code — what the old code did on the paths the PR did not set out to change, and whether the new code still does it.
+tools: read, bash, grep
+---
+
+{{include:prompts/pass-common.md}}
+
+# Lens: behaviour delta — what the old code did that the new code may not
+
+Your task string names your FOCUS FILES. In them the PR does not only add
+code: it MODIFIES, REWRAPS, REPLACES or DELETES lines that already ran. The
+other passes read the PR for what it sets out to do. You read it for what it
+STOPS doing by accident — on the paths the PR was not about.
+
+How to work:
+
+1. For each focus file, put the base and the head side by side:
+   `git -C <worktree> diff <merge-base> <head> -- <file>`, and read the old
+   version of each hunk with `git -C <worktree> show <merge-base>:<file>`.
+2. Enumerate. Write ONE line in your notes for EVERY hunk that modifies,
+   rewraps, replaces or deletes existing non-test code (pure additions are
+   not yours):
+   `path:line — base did X on <path the PR did not target> — head: still does / no longer does / does Y`.
+   Do not skip a hunk because it looks mechanical. The enumeration is the
+   procedure: a hunk you did not write a line for is a hunk you did not check.
+3. Look especially for these shapes:
+   - a safeguard that always ran now runs only sometimes — a condition
+     added around it, a conjunct dropped from it, a `DISTINCT`, a lock, a
+     validation or a retry made conditional;
+   - a removed or weakened guard: a deleted type, null, bounds or permission
+     check; an `isinstance`/`instanceof` that is gone; a narrowed condition (a
+     WIDENED predicate's consumers are `pass-widened`'s);
+   - a line rewrapped into a new branch whose value or argument also changed
+     (the old fallback replaced in the `else`);
+   - a replaced call whose semantics differ in a way the PR does not mention
+     (print vs println, a parse with a different precision or locale, a
+     hand-written retry replaced by a library call that does not retry);
+   - deleted handling: an encoder, a conversion, a `try`/`except` or `catch`
+     that turned an error into a value, a cleanup, an event emission;
+   - an error that was returned or raised is now logged and ignored, or the
+     reverse;
+   - a value normalised differently (nil becomes an empty map, an empty
+     string becomes absent) so a downstream check reads it differently;
+   - a container rewrite that changes order or drops duplicates (a list
+     rebuilt through a map or set);
+   - the first and the last output: what is emitted on the first call, before
+     anything is cached, and what is kept when output is truncated.
+4. For each hunk where head no longer does what base did, follow the old
+   behaviour to who relied on it: callers, consumers, tests, the docs the PR
+   did not touch.
+
+Reporting:
+
+- A change the PR title or body states as its intent is not a finding.
+- Report each lost behaviour with both sides — the base line (`<merge-base>`,
+  `path:line`) and the head line — the path the PR did not target, and who
+  depended on it.
+- Default to a `question` naming the lost behaviour. It is a finding at its
+  own severity only when you show the path that now goes wrong is reachable
+  in ordinary use (an input any caller sends, a default configuration, the
+  first run).
+- `NONE` is the right answer when every enumerated hunk keeps the old
+  behaviour on the paths the PR did not target.

package/assets/agents/pass-bounds.md

@@ -0,0 +1,36 @@
+---
+name: pass-bounds
+description: Resource and trust bounds pass (sub-lens of security) — loops whose exit another party controls, size checks after allocation, unvalidated remote data, unbounded growth, internal facts leaking out.
+tools: read, bash, grep
+---
+
+{{include:prompts/pass-common.md}}
+
+# Lens: resource and trust bounds (sub-lens of security)
+
+Selected because the diff loops over, reads, allocates or parses data whose
+size or shape another party controls — a remote server or peer, a client
+request, a file on disk, a fetched payload. A faulty peer counts, not only a
+malicious one: a buggy server that repeats a page hangs the client just the
+same.
+
+Answer each question for the code the PR adds or changes, with `file:line`
+evidence:
+
+1. **Loop termination.** For every loop whose exit depends on another party's
+   data (pagination, retry, streaming, cursor following): what happens if that
+   party returns the same page forever, a page that never shrinks, a cursor
+   that never advances, or a count that is wrong? Is there a bound on
+   iterations, on progress, or on total size?
+2. **Size before allocation.** Is every size limit checked BEFORE the data is
+   read or allocated — not after the whole file or body is already in memory?
+3. **Shape before use.** Is fetched or user-supplied data validated at runtime
+   before it is used as a typed value? A cast is not validation — trace what a
+   wrongly shaped payload does to the code that consumes it.
+4. **Growth.** Does any collection grow with peer- or user-controlled input
+   and no cap — accumulated pages, cache keys, queued items?
+5. **What leaks out.** Does the change send internal facts to clients —
+   hostnames, filesystem paths, environment values, stack traces, internal IDs
+   — in responses, headers or error messages?
+
+`NONE` when each bound holds.

package/assets/agents/pass-claims.md

@@ -0,0 +1,31 @@
+---
+name: pass-claims
+description: Claim-check pass (sub-lens of intent) — for each checkable claim in the PR title or body (fixes a warning, supports a version, prevents a failure), verifies that the diff actually makes it true, everywhere it applies.
+tools: read, bash, grep
+---
+
+{{include:prompts/pass-common.md}}
+
+# Lens: claim check (sub-lens of intent)
+
+Selected because the PR's title or body makes a checkable claim: it fixes a
+named warning or bug, supports named versions or devices, silences a
+diagnostic, prevents a failure, stays compatible. The question is not whether
+the claim is a good idea. It is whether THIS DIFF makes the claim true.
+
+In your notes, one row per claim:
+
+1. **The claim**, quoted from the title or body.
+2. **The hunks that implement it** (`file:line`).
+3. **Efficacy.** Does the claimed effect actually result? Trace it: after the
+   change, does the named warning still fire — check the types and conversions
+   in every rewritten expression, not just its shape; does the named failure
+   still happen on the path the PR describes; is a stated constraint ("only
+   version N and later", "only when X") ENFORCED in code, or only written
+   in the description?
+4. **Coverage.** Does the fix reach every site of the same problem that the
+   claim covers, including sites the PR did not touch?
+
+A row that fails efficacy or coverage is a finding at full severity — the PR
+ships something other than what it says. A claim the code fully implements
+produces no output. `NONE` when every claim holds.