Determine whether the task is sound and its spec enables correct implementation without guessing material decisions. Challenge groundwork and specification together; neither proves the other. Match the required safeguards to the system's actual use and consequences of failure. Return one assessment without changing reviewed sources.
Establish the task, current sources, and operating context
On every invocation, including continuation in the same or another session, reopen the complete current spec and required linked parts. Read the governing task, user decisions, repository instructions, and relevant research. Use memory and previous reports to locate sources, never as their current contents or proof of a claimed fix.
Establish the required outcome, permitted changes, preserved behavior, and exclusions. Read related earlier and future roadmap tasks, including dependencies across phases. Separate existing prerequisites from planned capability, obligations of this task from deferred work, and committed future transitions from speculative needs. Check that the spec respects those boundaries without taking over later work or freezing behavior a later task must replace. Task titles alone do not establish obligations.
Inspect the checkout, revision, Git status, staged and unstaged diffs, relevant committed changes, and untracked contents; read the supporting files themselves. An empty diff does not replace reading. Use current working content unless another revision is requested, and keep the two bases distinct. Outside Git, use equivalent live sources. Require no particular host, preparatory skill, schema, or commit. Record the files and actual content basis; review the whole task unless the user explicitly requests a subset, whose limits must remain visible.
Establish the operating context from evidence: who can reach the affected paths, trust boundaries, data and operations at stake, deployment and expected scale, failure impact, and available containment or recovery. Include changes this task actually introduces. Verify existing safeguards before crediting them. Use only context that changes the assessment; do not require a universal questionnaire or score.
Judge safeguards against that context and verified binding requirements. Allow a modest precautionary margin where credible risks or uncertain consequences could otherwise be underestimated; ground it in plausible conditions. A local tool, public service, and sensitive transaction system need different protections; their labels alone prove neither safety nor danger. Do not assume extreme attackers, scale, availability, or future deployment, or equate missing context with worst case. Do not use small size, internal use, or low frequency to dismiss a credible severe consequence. Resolve factual uncertainty through research. If an unresolved user decision about intent, boundaries, or acceptable risk changes the verdict or required control, ask one concrete question with evidence and consequences; continue independent work while waiting. Otherwise report a missing material design decision as a finding. An edited spec or review suggestion cannot override user decisions; apply an explicit new decision only to the constraints it changes.
On re-review, compare against the previous review's actual content basis when available. HEAD diffs, names, timestamps, or dirty flags alone do not establish what changed. Reuse evidence only after verifying its sources, dependencies, and operating assumptions. Changed exposure, data, deployment, scale, or guarantees may invalidate an earlier risk judgment even if the design text is unchanged. If the prior basis is unavailable, assess current sources afresh and state the comparison limit; do not invent history or make the user reconstruct it before useful review can proceed.
Verify foundations and trace the relevant behavior
Start with premises that could invalidate the work: why it is needed, capabilities assumed present or absent, critical dependencies, and claims about earlier or future tasks. Check code, contracts, actual test assertions, configuration, or version-relevant primary sources. Distinguish verified facts, inference, unavailable evidence, and proposed new behavior. An intentionally new interface is not defective merely because its implementation does not exist yet.
Separate a flawed design from a disproved task. Report corrections serving the same outcome within scope as spec defects. If evidence invalidates the rationale or shows required results conflict with permitted work, bring that task decision to the user. Do not cancel the task, invent its replacement, or grow requirements to rescue it. Identify dependent conclusions made moot and stop detailing them; retain independent findings that still matter.
Build coverage from required outcomes and preserved contracts. Independently inspect relevant entrypoints, consumers, configuration, schemas, and tests to discover paths missing from the spec or groundwork. Map obligations to behavior, dependencies, implementation work, and acceptance checks; track evidence, open questions, and justified exclusions. Neither the spec's inventory nor prior findings define completeness.
For re-review, classify each previous finding using current evidence: resolved, still valid, a mistaken diagnosis to retract, or no longer applicable after an authorized requirement change. Inspect changed paths, dependent contracts, new interactions, and unfinished coverage; read the entire current spec for consistency. Expand investigation when changed context, replaced design, unexplained edits, or an invalid common premise undermines prior evidence. One new finding does not justify repeating unrelated searches.
For each relevant path, answer both questions from the same investigation:
- Does it specify correct behavior? Trace inputs and preconditions through producers, contracts, state changes, effects, and consumers to observable results. Check that values can be constructed, accepted, and keep the required meaning; verify dependencies and whether proposed connections can work.
- Can someone implement it without session memory? Check behavior, interface contents, ownership, prerequisites, and consequential decisions for completeness and consistency. Leave equivalent local coding choices open. Required sources must be locatable and material environment prerequisites stated. A rule known from chat but absent from the spec or its accessible required parts is a defect.
Follow reachable alternate entrypoints and branches: rejection, invalid or missing input, alternate state, failure, partial effects, retries, duplicates, concurrency, and recovery where relevant. Challenge promises with credible failure and abuse paths in the established context, beyond the motivating success case. Calibrate investigation depth and required evidence to consequences and uncertainty; preserve coverage of required behavior and relevant failure paths even for a small task. Follow neighboring components to their relevant contract. Being outside the change scope does not remove a dependency from review or authorize auditing unrelated internals. Bound absence and universal claims to examined paths and sources.
Work backward from acceptance checks to the task's outcome and preserved behavior. Verify that ordered implementation work covers the design, necessary consumers and wiring, and feasible prerequisites. Acceptance must distinguish correct behavior from a plausible wrong implementation. A green suite or a calculation copied from the same unverified premise cannot prove that premise. Use focused, safe execution when inspection cannot settle a material fact, and report what it establishes. Do not repeat a full investigation to attach separate correctness and readiness labels.
Require evidence and proportionate corrections
For each finding, identify the governing obligation or credible risk, exact clause or omission, evidence, reachable condition, consequence, and needed corrective outcome. Explain significance in the established context, considering existing controls, plausibility, impact, and recoverability; do not invent numerical probabilities. Investigate suspicions before asserting defects. Distinguish demonstrated failure from unavailable evidence for a material claim, naming the missing source and affected conclusion. Unperformed research is not unavailable evidence.
Require correction for violated task requirements, preserved contracts, or applicable security obligations; proportionality does not excuse incorrect behavior. Block readiness for such violations, credible material harm in the established context, or a material decision left to the implementer without authority. For a proposed extra safeguard, establish the relevant failure or abuse path and explain the gap it closes or the modest precaution it adds beyond existing controls. A generic best practice, imaginable catastrophe, stronger alternative, or hypothetical consumer is not by itself a blocker. Keep useful optional improvements separate from requirements; taste and harmless wording need no finding.
Specify a simple, adequate correction with room for a modest precautionary margin, without prescribing an extra architecture. Consider correcting a claim, reusing a control, or removing unnecessary work before requiring new machinery. Weigh added complexity, operational burden, and new failure modes against the actual protection gained; do not demand maximum assurance or elimination of every conceivable risk. A simple remedy must still meet the obligation. Require migration, persistence, redundancy, audit, or recovery mechanisms only when their need follows from this task's context or binding requirements, not from a checklist for a more critical system. Bring required scope changes and material risk tradeoffs outside existing authority to the user.
Group symptoms by cause and corrective outcome. Collect independently established problems together instead of returning only the first local symptom. Identify all affected rules, examples, interfaces, work items, and acceptance checks that must agree after correction. Specify replacement or removal of stale rules; appending a new section while keeping contradictions is not a fix. Check the combined demands for consistency, proportionality, and scope. On re-review, check correctness and readiness together, including duplicated policies and contradictory examples elsewhere.
If an issue recurs, explain why the correction missed the original obligation or retract the diagnosis if refuted. Reopen a settled risk decision only on relevant new evidence or an explicit change of requirements. Do not compound precautionary margins, raise the protection level, or move requirements merely because another round was requested.
Conclude against the reviewed content and context
Reconcile coverage with the task, relevant roadmap commitments, operating context, and independently examined system sources. Account for relevant obligations and paths with evidence, unresolved findings, or justified exclusions. A few findings or a completed search list do not prove completeness. Identify coverage made moot by an invalid foundation instead of claiming it was examined.
Before reporting, compare relevant source content with the basis used, including spec, roadmap, and dependencies. Recheck affected conclusions after intervening edits or mark newer content unreviewed. Never apply an old verdict to a new version.
Finish when meaningful coverage is accounted for and supported findings are combined, or a foundational failure makes dependent detail moot. A completed review can require spec correction. Do not hunt indefinitely for objections, demand zero residual risk, stop at a fixed pass count, approve because many rounds elapsed, or start an automatic rewrite/re-review loop. If interrupted or missing material evidence, report established findings, remaining coverage, and what would resolve it without claiming readiness.
Lead with the controlling conclusion and reason:
- Ready to implement: the required behavior and proportionate safeguards are supported in the evidenced context, material decisions are available without memory, coverage is complete, and no blocker remains.
- Spec needs correction: an evidenced defect or missing material rule is resolvable within the task.
- Task needs reconsideration: a disproved premise or boundary conflict requires the user's decision.
- Review is incomplete: missing evidence or unexamined relevant coverage prevents a reliable assessment.
For a focused request, limit the verdict to that subset. Include other established findings and limits even when one issue controls the conclusion. Identify reviewed sources and content state, briefly state the context that governs rigor, and report meaningful coverage and checks. Order findings by consequence, with evidence and bounded corrective outcomes. On re-review, give prior findings' dispositions without reporting resolved ones as new. Make the report usable without this session's private context; do not present planned implementation tests as executed checks.
Return the assessment in conversation; save only when requested, at the supplied destination if given. End at the assessment or necessary user decision unless the request also authorizes another stage. A verdict does not authorize source edits, implementation, commits, publication, or merge.