Opus checklist

# Opus Tier — Deep Analysis Checklist (extended reference)

This is the extended reference the Tier 3 (Opus) agent loads when a deep check needs more context than the inline agent definition. For the canonical flow + RESULT block schema, see `../../../agents/opus-reviewer.md`.

## Scope

Opus is the architectural pass. It catches:

- Architectural misfit (new module violates the layering pattern in use)
- Governance drift (Tier A checkbox batching against commit cadence)
- Null propagation across the full codebase (not just the diff)
- Factual claims without provenance in documentation
- Overengineering (premature abstractions, unnecessary complexity)
- Dead code at the module / endpoint / migration level

## Governance drift — two-tier cadence rule

When auditing checkbox close-out cadence, classify every `[x]` box into one of two tiers BEFORE judging:

**Tier A — Phase-deliverable checkboxes**: items in Acceptance Criteria Phases 1..N that describe a concrete deliverable (a file edit, commit, function, section, table, example). STRICT interleaving required — Proof of Work entry order MUST interleave with git-log commit order within the same phase's commit window.

**Tier B — Cross-cutting meta-checkboxes**: Triple-Check Gate items, Engineering Requirements meta-items like "Fix Everything", Cleanup Requirements, Verification Loop self-gates, PREREQUISITE CHECKPOINT, Expected Behavior post-condition items. Batched-at-end is acceptable because these describe conditions observable ONLY after all phases complete. Closing them mid-phase would be dishonest.

**Classification heuristic**: if the checkbox text names a specific file / commit / section / function / table to build or change, it is **Tier A**. If it describes a cross-cutting condition requiring the WHOLE implementation to evaluate, it is **Tier B**. When in doubt, inspect the checkbox's section in the issue template: Acceptance Criteria sub-phases = Tier A; Triple-Check Gate / Engineering Requirements meta / Cleanup Requirements / Verification Loop self-gates / PREREQUISITE CHECKPOINT / Expected Behavior = Tier B.

**Rule**:

- Flag Tier A batching as governance drift.
- Do NOT flag Tier B batching as drift.

A Tier-B-only batch is acceptable and expected.

## Governance evidence signal (canonical)

The canonical audit signal for verifying that checkbox-close invocations actually happened is the `## Proof of Work` section in the issue body — NOT the GitHub timeline `edited` events.

Why: GitHub's timeline API does not emit `edited` events for an issue author's own body edits on their own issue. Since solo-workflow agents ARE the issue author in almost all cases, timeline-based audits false-negative every honored invocation. The body content itself, however, is always externally readable.

Verification procedure:

1. Fetch the issue body via the project's governance MCP tool, or a plain GitHub API call.
2. Parse the `## Proof of Work` section. Each entry starts with `- **<checkbox text>**: <evidence>`.
3. For every `[x]` box in the body, there MUST be a matching entry in Proof of Work. Missing entry = drift.
4. For each entry, spot-check the cited evidence:
   - file:line claims → open the file on the branch
   - commit hashes → `git show <hash>`
   - subagent RESULT blocks → fetch the cited comment
   - command output → reproducible via the same command

Ordering of Proof of Work entries is authoritative — the section appends in invocation order. Cross-reference the entry order against `git log --oneline` to confirm Tier A items closed within the same phase's commit window.

## Factual claims audit

Every numeric assertion added by the implementation (counts, ratios, durations, capacities, percentages) must have a verifiable source:

- **Reproducible command** (e.g. `git log --oneline | wc -l` → "10,385 commits")
- **API query** (e.g. `gh issue list --state all` → "1,309 issues")
- **Code reference** (e.g. `grep -c "def test_" tests/` → "N test functions")
- **Calculation** (e.g. `(total - open) / total = 99.4% close rate`)

"Seems reasonable" is not a source. If the number cannot be reproduced, it must be sourced or removed before OPUS_PASS.

## Bash output discipline

- Any command producing > 200 lines → capture to file, report path + verdict in RESULT.
- Do NOT paste full pytest output, unfiltered git diffs, or log tails back to the main agent.

## When graph is unavailable

Opus tier has the deepest graph requirements — dead-code detection via `large_functions` + orphan scan, impact scope validation via `impact(max_depth=2)`, large-function audit. When graph is unavailable or unsupported-language, an Explore-style subagent MUST perform the equivalent manual architectural audit and the RESULT must include the subagent's RESULT block. Documenting only `[graph unavailable]` = silent skip = FAIL.