interrogate git:20261028.933dd9dA

Immutable. This exact content never changes and is served at /api/v1/blob/97fe51a73d671ad5.

---
name: interrogate
description: "Challenge a specified design, patch or claim for concrete correctness, ownership and evidence gaps. Use for adversarial review, not every routine edit."
---

# Interrogate

Follow the consuming project's instructions and requested scope; use the
[portable defaults](../orbyn-workflow/references/project-policy.md) only where guidance is missing.

Pin the candidate and intended contract. Inspect the changed code and affected
callers using [review criteria](../orbyn-workflow/references/project-policy.md#verification-and-review). Look for scenarios
that falsify the claim, especially lost authority, stale state, partial failures,
concurrency, cleanup and incomplete verification.

The lead may use an independent in-task reviewer for a distinct unresolved risk
under [coordination](../orbyn-workflow/references/project-policy.md#delegation-and-host-configuration), within the task's shared
child limit. Assigned reviewers inspect their candidate directly without further
delegation. Follow assigned read-only limits and the model policy. Neither
multiple models nor a majority vote establishes correctness.

Deduplicate findings and independently check them. Classify concrete defects,
evidence gaps, optional improvements and dismissed claims. Every actionable item
needs a location, scenario, impact and correction direction. Do not auto-apply
changes during a review-only task. Return a supported verdict and its limitations.

## Review the failure that matters

For an approval change, ask whether a revoked user or stale client can still apply it and whether a retry duplicates the effect. Return a concrete reproducing state and affected owner. Missing native evidence is an evidence gap; it is not automatically a source-code defect.

When challenging a module refactor, inspect what callers must know, which
complexity is hidden, whether the seam reflects actual variation, and whether
behavior checks survive the internal reorganization. Identify a concrete caller
or failure scenario; a preferred vocabulary or file count is not a finding.

## Operational method

Use the [local operating method](references/operating-method.md) for the execution
sequence, concrete failure case, expected result and stopping condition. It is
Orbyn-authored guidance; historical source notices remain in provenance.

## Record falsification receipts

For each consequential challenged claim, retain the pinned candidate, input/trigger,
expected and observed result, actual command or source trace, disposition and next
check. Re-run supported executable findings at the same candidate when permitted;
a fabricated final state or a test that always fails is not adversarial evidence.
Source-proven unsafe paths remain actionable with their evidence labeled even when
execution is blocked. Compare baseline and head/reachability before attributing a
preexisting defect to the patch; newly exposed or copied unsafe behavior still matters.