Team Review

Arguments: <target> [--reviewers auto|security,performance,...] [--base-branch main] [--all] [--deep] [--no-context] [--fast] [--rigorous]. Wherever <arguments> appears below, substitute the text the user typed after the skill name.

team-review

Execution harness

Selected topology: parallel-subagents, with role delivery by inline-prompt. Start one isolated runtime subagent per dispatched worker. When role delivery is inline-prompt, paste that role's Markdown body into the dispatch prompt verbatim: the worker must receive the whole role, not a summary of it.

Harness obligations, none of them optional:

• Every dispatched worker runs in its own subagent context, and never reads another worker's result.
• Follow the dispatch plan below in phase order. A phase starts only after every phase it needs has closed, and a phase closes only when every worker it dispatched is recorded delivered or failed. A worker reports delivered or failed in its final message; there is no shared task list, so the coordinator keeps that record itself.
• Dispatch only roles from this set, and only as the plan says: api-contract-auditor, chicken-egg-detector, cleanup-auditor, code-auditor, data-integrity-auditor, distributed-flow-auditor, logic-integrity-auditor, premise-auditor, resource-lifecycle-auditor, security-auditor, temporal-resilience-auditor, ui-race-auditor
• Only the phase that declares the report artifact may write it.

Dispatch plan:

1. scope: runs in the orchestrating context; produces artifact:review-brief.
2. context-building: runs in the orchestrating context; needs scope; consumes artifact:review-brief; produces artifact:context-map.
3. dimension-detection: runs in the orchestrating context; needs context-building; consumes artifact:context-map; produces selection:reviewers.
4. independent-review: one worker per item of selection:reviewers, each bound to the role the selection names (any role this plugin declares), each in its own isolated context, in parallel where the host allows; barrier all-delivered; needs dimension-detection; consumes artifact:review-brief, artifact:context-map; produces artifact:reviewer-result.
5. delivery-accounting: runs in the orchestrating context; needs independent-review; consumes artifact:reviewer-result; produces artifact:delivery-ledger.
6. initial-consolidation: runs in the orchestrating context; needs delivery-accounting; consumes artifact:reviewer-result, artifact:delivery-ledger; produces artifact:initial-findings.
7. cross-examination: logic-integrity-auditor and premise-auditor, once each, each in its own isolated context, in parallel where the host allows; barrier all-delivered; needs initial-consolidation; consumes artifact:initial-findings; produces artifact:cross-examination.
8. consolidation: one code-auditor in an isolated context; needs cross-examination; consumes artifact:initial-findings, artifact:cross-examination, artifact:delivery-ledger; produces artifact:final-report.
9. report-delivery: runs in the orchestrating context; needs consolidation; consumes artifact:final-report.

Role bodies ship with this package under roles/, and the phase graph and record schemas under contracts/team-review.workflow.toml.

Method

Execution requirements

This workflow fans out over the dimensions its detection step selects. Dispatch, scheduling and result collection belong to the host harness, generated from contracts/team-review.workflow.toml. What this workflow requires of any harness is fixed, and none of it is optional:

• every reviewer runs in its own context and never reads another reviewer's result
• exactly the selected dimensions are dispatched, once each
• every expected reviewer is recorded delivered or failed before anything is consolidated
• cross-examination runs after that barrier, in fresh contexts
• only the consolidation phase writes the final report

If the host cannot run reviewers in isolated contexts, stop and say so. A review whose dimensions shared a context is not the artifact this workflow claims to produce.

Team Review (Pipeline)

Orchestrate a multi-dimensional code review as a 6-phase pipeline:

0. Phase 0 -- Scope and Discovery: resolve the target (0), detect which dimensions the change warrants (0b), and discover independently what evidence this review needs (0c), reading no X-ray output at all.
1. Phase 1 -- Context Building: X-ray analysis (1a) runs in parallel with a blind second derivation of the same premises (1c); the two are joined into 01-knowledge-provenance.md (1d); an interconnect map is built last (1b), covering contracts, invariants, assumptions, domain rules and integration hot-spots. Output goes to .team-review/.
2. Phase 2 -- Adversarial Review (parallel): specialized reviewers read the context files and hunt for violations within their dimension. Every finding declares the load-bearing premise it stands on and where that premise came from. Each reviewer writes structured findings to .team-review/findings-<dim>.md.
3. Phase 3 -- Monitor and Collect: every spawned reviewer delivers findings or an explicit no-findings report before consolidation starts.
4. Phase 4 -- Consolidation and Gates: findings are deduplicated and organized by severity, with agreement weighted by premise provenance; then the verification panel runs (4b, Lens 0's premise veto first) and the completeness critic asks what the review missed (4c).
5. Phase 5 -- Report & Cleanup.

The pipeline lets reviewers find problems that are invisible from local-only inspection: broken implicit contracts, invariant drift, bypass paths to business rules, non-idempotent retry paths, terminal state mutations. Two derivations run side by side in Phase 1 so that the review has a second observer, rather than one observer consulted N times.

Raw mode: pass --no-context to run the old parallel-only behavior (no Phase 0c, no context phase, no logic-integrity-auditor, no premise-auditor in either mode).

Skills to Load

Before starting, invoke these skills to inform the review process:

• senior-review:review-quality-gates -- context-sharing pattern, adversarial verification panel, completeness critic
• senior-review:defect-taxonomy -- 140+ defect subcategories with CWE/OWASP mappings (includes logic-integrity.md)

Pre-flight Checks

1. Confirm the harness can dispatch isolated reviewers; stop if it cannot.

2. Parse <arguments>:

   • <target>: file path, directory, git diff range (e.g., main...HEAD), or PR number (e.g., #123)
   • --reviewers: comma-separated dimensions OR auto (default: auto)
   • --base-branch: base branch for diff comparison (default: main)
   • --all: force all dimensions regardless of auto-detection
   • --deep: run Phase 1a codebase-xray in full mode (default: --depth=lite)
   • --no-context: skip Phase 0c and Phase 1 entirely and run reviewers with raw code only (raw mode; logic-integrity-auditor and premise-auditor are also skipped)
   • --fast: skip the verification + completeness-critic gate entirely (Phase 4b and 4c)
   • --rigorous: verify every finding above the confidence floor, ignoring the cost-guard cap

3. Check for existing .team-review/state.json:

   • If present with status: "in_progress": ask user whether to resume or start fresh (archive to .team-review-<ISO-timestamp>/).
   • If present with status: "complete": ask whether to archive and start fresh.
   • If absent: proceed to new session.

4. Initialize .team-review/ with state.json:

   {
     "target": "<arguments>",
     "status": "in_progress",
     "flags": {
       "reviewers": "auto",
       "all": false,
       "deep": false,
       "no_context": false,
       "fast": false,
       "rigorous": false
     },
     "current_phase": 0,
     "phases": {
       "phase_0_resolution": "pending",
       "phase_0b_detection": "pending",
       "phase_0c_evidence_discovery": "pending",
       "phase_1c_premise_audit": "pending",
       "phase_1d_reconciliation": "pending",
       "phase_1a_xray": "pending",
       "phase_1b_interconnect": "pending",
       "phase_2_review": "pending",
       "phase_3_consolidation": "pending",
       "phase_4b_verification": "pending",
       "phase_4c_critic": "pending",
       "phase_4_report": "pending"
     },
     "files_created": [],
     "xray": {
       "run_id": null,
       "run_dir": null,
       "target": null,
       "depth": null
     },
     "started_at": "ISO_TIMESTAMP"
   }
   

Phase 0: Target Resolution

1. Determine target type:
   • File/Directory: use as-is for review scope
   • Git diff range: git diff {range} --name-only to get changed files
   • PR number: gh pr diff {number} --name-only to get changed files
2. Collect the full diff content for later distribution to reviewers.
3. Collect the list of changed file paths and extensions for Phase 0b.
4. Write .team-review/00-scope.md with target, files, flags. Append a ## Pre-review work tree section containing the output of git status --porcelain at this moment: the Phase 5 workspace hygiene check diffs against it. Mark phase complete in state.json.

Phase 0b: Context Detection (when --reviewers auto or omitted)

Analyze changed files and codebase to determine which review dimensions are relevant. Skip if explicit --reviewers list was provided.

Always-on dimensions (run for every review)

Conditional dimensions (auto-detected from context)

Run these checks against the changed files and codebase to decide which extra reviewers to spawn.

Five of these dimensions live in other plugins: React performance (react-development), platform / runtime integration (platform-engineering), structural entropy (abstraction-architect), testing quality (testing), and TypeScript type safety (typescript-development). All five are hard dependencies of senior-review, so the marketplace installs them with it and no dimension can go missing at runtime. A dimension is skipped only when its signal did not match the codebase, which is a statement about the code and never about the install. If a spawn fails with "Agent type not found", the install is broken: stop and report it rather than continuing with a silently reduced review.

Detection implementation

Run these bash commands to gather signals:

# 1. Classify changed file extensions
echo "$CHANGED_FILES" | sed 's/.*\.//' | sort | uniq -c | sort -rn

# 2. Check for React
cat package.json 2>/dev/null | grep -q '"react"' && echo "REACT=true"

# 2b. Check for a TypeScript project
echo "$CHANGED_FILES" | grep -qE '\.tsx?$' && [ -f tsconfig.json ] && echo "TS_PROJECT=true"

# 3. Check for fullstack signals (count matches)
FULLSTACK_SIGNALS=0
[ -f package.json ] && grep -qE '"(react|vue|svelte|angular|next|nuxt)"' package.json && FULLSTACK_SIGNALS=$((FULLSTACK_SIGNALS+1))
grep -rql 'fastapi\|django\|flask\|express\|nest\|hono\|actix\|axum' pyproject.toml Cargo.toml package.json 2>/dev/null && FULLSTACK_SIGNALS=$((FULLSTACK_SIGNALS+1))
ls -d */routes */api */endpoints 2>/dev/null && FULLSTACK_SIGNALS=$((FULLSTACK_SIGNALS+1))
[ -f docker-compose.yml ] && grep -c 'image:\|build:' docker-compose.yml | awk '$1>1{print "MULTI_SERVICE"}' && FULLSTACK_SIGNALS=$((FULLSTACK_SIGNALS+1))

# 4. Check for multi-service / messaging patterns in diff
echo "$DIFF_CONTENT" | grep -qiE 'rabbitmq\|amqp\|kafka\|grpc\|pubsub\|queue\|celery\|dramatiq' && echo "MESSAGING=true"
echo "$CHANGED_FILES" | grep -qiE 'routes?\b|api/|endpoints?/|handlers?/' && echo "API_FILES=true"
# Formal contract files. Kept separate from API_FILES on purpose: a change to
# openapi.yaml or schema.graphql matches none of the path patterns above, and
# it is the single strongest signal for the api-contract-auditor dimension.
echo "$CHANGED_FILES" | grep -qiE '\.proto$|\.graphql$|\.gql$|openapi.*\.(ya?ml|json)$|swagger.*\.(ya?ml|json)$|asyncapi.*\.(ya?ml|json)$|schema.*\.json$' && echo "CONTRACT_FILES=true"

# 5. Check for init/startup patterns in diff
echo "$DIFF_CONTENT" | grep -qiE 'def main\b|if __name__|app\.on_startup|@app\.on_event|lifespan|create_app|bootstrap|init_' && echo "STARTUP=true"

# 5b. Check for long-running / scheduled execution patterns (temporal resilience)
echo "$DIFF_CONTENT" | grep -qiE 'setInterval|setTimeout|cron|schedule|\bretry|reconnect|backoff|watchdog|heartbeat|keepalive|\bpoll(ing)?\b|background.?(task|worker|job)|daemon|updater' && echo "TEMPORAL=true"

# 5c. Check for persistence code (data integrity)
echo "$DIFF_CONTENT" | grep -qiE '\btransaction\b|\bcommit\b|rollback|UPDATE |INSERT |upsert|\bunique\b|constraint|ON CONFLICT|FOR UPDATE|select_for_update|session\.add|\.objects\.|prisma\.|typeorm|sqlalchemy|redis|cache\.(get|set|del)' && echo "PERSISTENCE=true"

# 5d. Check for resource acquisition (resource lifecycle)
echo "$DIFF_CONTENT" | grep -qiE 'open\(|createReadStream|createWriteStream|\bsocket\b|getConnection|acquire|addEventListener|subscribe\(|\block\b|mutex|semaphore|new Worker|subprocess|Popen|spawn\(|go func|tokio::spawn|asyncio\.create_task|createObjectURL' && echo "RESOURCES=true"

# 6. Check for test and migration files
echo "$CHANGED_FILES" | grep -qiE 'test_|_test\.|\.spec\.|\.test\.|conftest|__tests__' && echo "TEST_FILES=true"
echo "$CHANGED_FILES" | grep -qiE 'migrat|alembic|versions/' && echo "MIGRATION_FILES=true"

Display detected dimensions

After detection, display the plan:

Context detection complete:
  - Always: security, architecture, logic-integrity, codebase-hygiene, workspace-hygiene
  - Detected: ui-races (6 .tsx files), react-perf (React project), ts-safety (TypeScript project), distributed-flows (API routes + RabbitMQ), temporal-resilience (retry + scheduler code), data-integrity (ORM writes + transactions), abstraction (diff adds 4 units)
  - Skipped: platform (not fullstack), chicken-egg (no startup code)

Pipeline plan:
  Phase 0c: review evidence discovery (inline)
  Phase 1a: codebase-xray (--depth=lite)   |  Phase 1c: premise-auditor (parallel, blind)
  Phase 1d: knowledge reconciliation (inline)
  Phase 1b: codebase-xray:semantic-interconnect-mapper
  Phase 2:  {N} reviewers in parallel
  Phase 3:  consolidation
  Phase 4:  report

Every reason on the Skipped line is a statement about the code, never about the install: "not fullstack" means the code did not need the dimension. Every agent this command can spawn comes from a plugin senior-review declares as a hard dependency, so there is no "plugin not installed" reason and no generic fallback. If a spawn fails with "Agent type not found", stop and report the broken install instead of continuing with a silently reduced review.

Mark phase_0b_detection complete in state.json.

Phase 0c: Review Evidence Discovery

Runs inline in the orchestrating context, on every invocation except raw mode (--no-context). That flag means "give me the raw mode", and a normally-on phase does not override it: 01a-review-knowledge-leads.md distributed to N reviewers is itself shared context, so keeping this phase alive under the flag would make findings legitimately shared-context, let Lens 0 fire, and stop the mode reproducing the pre-pipeline behaviour it exists to provide.

This phase owns discovery of what evidence is relevant to this review. X-ray owns discovery of how the repository documents itself. The two are different jobs and the division is deliberate.

This phase MUST NOT read .codebase-xray/ in any form, including the mirror and the output of previous runs. A previous X-ray run is still an X-ray derivation, and admitting one would contaminate the single artifact that has to be demonstrably independent of X-ray. X-ray's leads enter at the Phase 1d join and nowhere earlier.

1. Read CLAUDE.md, AGENTS.md and equivalent project instruction files, and follow any navigation rule they state. If the project says a specific file is where to look first to find where a concept lives, open that file before opening any code. Discover the conventions from the repository itself, never from a prior X-ray run.
2. Extract the concepts, domains and symbols the diff touches. Names of changed functions, classes, modules and config keys are the starting set; add the domain nouns that appear in the diff's own strings and comments.
3. For each concept, search the project's indexes and documentation for a relevant entry, and search the tests for behaviour that encodes it.
4. Write .team-review/01a-review-knowledge-leads.md.

This file is immutable once written. No later phase appends to it. X-ray's own leads are joined into a separate derived artifact in Phase 1d, precisely so that the snapshot Phase 1c consumes cannot change underneath it.

Output: .team-review/01a-review-knowledge-leads.md

# Review Knowledge Leads

> Leads, not truth. Immutable once written.
> Discovered by senior-review independently of any X-ray output.

## Navigation rules followed
| Source | Rule |
|--------|------|

## Concepts touched by this diff
| Concept | Where it appears in the diff |
|---------|------------------------------|

## Leads
| Concept | Document / test | Anchor | Status |
|---------|-----------------|--------|--------|

## Concepts with no lead found
[One line each. This list is the honest statement of what nobody documented.]

Mark phase_0c_evidence_discovery complete in state.json.

Phase 1: Context Building

The sub-phases below are listed in execution order, not in label order: 1a and 1c start together, 1d joins them, 1b runs last on the joined result. Nothing named here is missing.

Skip this phase entirely if --no-context was passed. Mark phase_1a_xray, phase_1c_premise_audit, phase_1d_reconciliation, phase_1b_interconnect, and phase_0c_evidence_discovery as skipped in state.json. Jump to Phase 2 with raw target files only.

Phase 1a: X-Ray Analysis

codebase-xray:analyze is a workflow of the codebase-xray plugin, not an agent. Nothing dispatches it as a worker: it runs in this context, the way a user would invoke it, with its arguments. The host lists it under the codebase-xray plugin as analyze (a host that renders workflows as skills suffixes it -workflow). The codebase-xray:xray-method skill is the method that workflow applies; loading the method alone runs no phase and creates no run directory. The distinction matters because the rest of this command (Phase 1b, Phase 2) dispatches many plugin:name workers and the same shape names workflows and skills; treat Phase 1a as running a workflow, full stop.

1. Run the codebase-xray:analyze workflow against the target, in this context:
   • Default mode: --depth=lite (structure + interfaces + risks only)
   • If --deep flag: full analysis
   • Target scope: the files from Phase 0
2. Read .codebase-xray/runs.json to resolve the run the workflow just created, and record it in state.json -> xray as run_id, run_dir, target and depth. Every later phase derives its paths from this block and never from the .codebase-xray/ root. $XRAY_RUN_DIR below always means state.json -> xray.run_dir. If the run cannot be resolved, halt: an unresolvable provenance is a broken pipeline, not a reason to fall back to the mirror.
3. Verify on completion that at minimum 01-structure.md, 02-interfaces.md, and 05-risks.md exist.
4. Mark phase_1a_xray complete.

If the workflow is unavailable (plugin not installed) or produces no output, halt the pipeline and report the error. Do not fall back to spawning a general-purpose agent to fake the X-ray output -- the file naming and section anchors that Phase 1b/Phase 2 depend on come from the workflow itself, and a freelance fallback breaks the contract for logic-integrity-auditor.

Phase 1c: Independent Premise Derivation (parallel with 1a)

Spawn immediately when Phase 1a starts. Do not wait for X-ray. The whole point of this phase is that it derives without seeing what X-ray derived.

1. Spawn one teammate with subagent_type: senior-review:premise-auditor.

2. Prompt:

   Mode 1: independent derivation.
   
   Target scope: [contents of .team-review/00-scope.md]
   Knowledge leads: .team-review/01a-review-knowledge-leads.md
   Diff: {diff content}
   
   Derive independently what is true about the concepts this diff touches.
   Write .team-review/01b-independent-claims.md in the format your agent
   definition prescribes.
   
   You have NO access to .codebase-xray/ or to .team-review/02-interconnect.md.
   Neither exists for you. Do not look for them, and report contamination if
   anything in this prompt paraphrases an X-ray conclusion.
   

3. Wait for both 1a and 1c before starting Phase 1d. Mark phase_1c_premise_audit complete.

Under raw mode (--no-context) this phase does not run, because there is no shared derivation for it to be independent of.

Phase 1d: Knowledge Reconciliation (join)

Runs inline once both 1a and 1c have completed. The premise auditor never compares its own derivation: comparison is done by others, downstream, which is what makes its blindness verifiable rather than merely asserted.

Read .team-review/01a-review-knowledge-leads.md, $XRAY_RUN_DIR/knowledge/documentation-leads.md and .team-review/01b-independent-claims.md. Write:

Degradation when X-ray produced no leads. If $XRAY_RUN_DIR/knowledge/documentation-leads.md does not exist, record Inherited from X-Ray: not produced under that heading and suppress the asymmetry diagnostic described below for this run. An absent file is not a discovery gap, and treating it as one would report an X-ray gap on every row: a systematically false signal from the mechanism built to stop false signals. A reused older run, a Phase 0 that failed, and an X-ray version predating Phase 0 all land here. Everything else in this phase proceeds normally: Missing and Disputed are still computed from 01a and 01b.

Output: .team-review/01-knowledge-provenance.md

# Knowledge Provenance

> Derived view, produced after both discovery branches completed.
> The canonical artifact consumed downstream. 01a and 01b are its sources.

## Independently discovered by Senior Review
[rows from 01a-review-knowledge-leads.md]

## Inherited from X-Ray
[rows from $XRAY_RUN_DIR/knowledge/documentation-leads.md]

## Missing
| Concept | In scope because |
|---------|------------------|
| [concept] | [where it appears in the diff] |

## Disputed
| Claim | Independent derivation says | X-ray says |
|-------|------------------------------|------------|
| [claim] | [X at file:line] | [Y at file:line] |

Missing and Disputed are different states and must never collapse into one section. Absence of evidence is not contradictory evidence.

Collapsing them would drain disputed of the precise meaning the rest of this work depends on, which is that two derivations reached incompatible conclusions and a reviewer must settle it.

The duty of autonomous rediscovery. X-ray's documentation leads are an input, never a completeness guarantee. Any concept 01a carried that X-ray's leads missed stays under Independently discovered by Senior Review; a concept neither branch found goes to Missing. Neither is downgraded because the other branch was silent. Without this duty, the completeness of X-ray's discovery becomes the next shared premise, which is the failure this pipeline exists to prevent.

Two asymmetries here are diagnostics worth reading, not noise. A row present in Independently discovered by Senior Review and absent from Inherited from X-Ray means X-ray's discovery had a gap. The reverse means Phase 0c had one. Both are recorded and neither is silently reconciled. Neither is reportable when X-ray produced no leads file at all: the degradation rule above governs that case.

Mark phase_1d_reconciliation complete.

Phase 1b: Semantic Interconnect Mapping

1. Spawn a single teammate with subagent_type: codebase-xray:semantic-interconnect-mapper.

2. Prompt:

   Build the interconnect map for this review.
   
   Target scope: [contents of .team-review/00-scope.md]
   X-ray output: $XRAY_RUN_DIR (files: 01-structure.md, 02-interfaces.md, 05-risks.md, knowledge/documentation-leads.md, ...)
   Independent claims: .team-review/01b-independent-claims.md
   Knowledge provenance: .team-review/01-knowledge-provenance.md
   
   Read $XRAY_RUN_DIR and the target files. Produce .team-review/02-interconnect.md
   following the exact output format in your agent definition (Call Graph,
   Contracts formal/structural/implicit, Invariants, Domain Rules, Assumptions,
   Integration Hot-Spots, Change Impact Radius, Reviewer Hints).
   
   Every claim must cite file:line. No recommendations, no fixes.
   
   Compare the independent claims against your own derivation. Every
   contradiction becomes a `disputed` row citing both sides. Do not resolve
   contradictions and do not prefer your own derivation by default.
   

3. Wait for completion. Verify .team-review/02-interconnect.md exists and contains the required anchors (## Contracts, ## Invariants, ## Domain Rules, ## Assumptions, ## Integration Hot-Spots, ## Reviewer Hints). Empty sections are acceptable but the anchors must exist.

4. Mark phase_1b_interconnect complete.

Phase 2: Adversarial Review (parallel)

1. The team forms implicitly when the first teammate is spawned (no TeamCreate step; the team name is session-derived and any team_name passed to the Agent tool is ignored).
2. For each selected dimension (always-on + detected conditional), use Agent tool to spawn a teammate using the most specialized agent.

Dimension-to-agent mapping

Reviewer prompt template (context-aware)

Every reviewer receives the same structural prompt. The key addition vs the old parallel-only mode is the context paths.

You are reviewing for the {dimension} dimension.

## Target
[Insert contents of .team-review/00-scope.md]

## Diff
{diff content}

## Context files (read these before analyzing code)
- X-ray output: $XRAY_RUN_DIR (see 01-structure.md, 02-interfaces.md, 05-risks.md)
- Interconnect map: .team-review/02-interconnect.md
- Knowledge provenance: .team-review/01-knowledge-provenance.md

### Epistemic status of the shared context

The shared context is NOT ground truth. It is an index of hypotheses produced by
one upstream observer.

- Claims marked `verified` may be reused directly.
- Claims marked `documented`, `unverified` or `disputed` are hypotheses. You MUST
  independently re-derive any such claim before using it as the premise of a finding.
- Actively search for code paths, tests or documents that contradict the context.
  Finding one is a result, not a failure.
- Silence in the context is not evidence of absence. A concern the map does not
  mention may still be real; look anyway.

Per `## Reviewer Hints` in the interconnect map, focus your reading on these anchors:
{anchors-for-this-dimension from the map's Reviewer Hints section}

## Instructions
Follow your agent definition's analysis phases, knowledge-base loading, output format, and severity classification. Cite file:line for every finding.

## Premise declaration (required on every finding)

Every finding carries two extra fields:

- **Load-bearing premise:** the single proposition whose falsity collapses this
  finding. It must be minimal, falsifiable and scoped.
    Bad:  "The implementation is broken."
    Bad:  "Heartbeat handling is incorrect."   (a paraphrase of your finding)
    Good: "No credential-bearing response path exists after registration."
- **premise_provenance:** one of `independent`, `shared-context`, `mixed`.
  This records CAUSAL DEPENDENCE, not citation. If you absorbed the premise from
  the X-ray output or the interconnect map, it is `shared-context`, even if
  your finding never cites an anchor. `mixed` means part of the premise rests on
  shared context and part on evidence you derived yourself. Declare `independent`
  only when you re-derived the whole premise from code, tests or documents you
  read yourself.

Write your output to .team-review/findings-{dimension}.md using the structured format your agent prescribes.

If --no-context was set, omit the "Context files" and "Reviewer Hints" sections and do NOT spawn the logic-integrity-auditor.

Structural entropy dimension addendum. abstraction-architect:abstraction-architect takes named inputs rather than a free-form dimension prompt. Append this block to its prompt:

mode: diff
codebase_path: {target root}
xray_path: {$XRAY_RUN_DIR when Phase 1a ran and produced output, otherwise "none"}
concept_index_path: {target root}/.abstraction-architect/concept-index.json
changed_files: {the same file list used to build the diff above}
report_path: .team-review/findings-abstraction.md
severity_floor: medium

Four things about this reviewer, because they invert the default reviewer contract:

• Its search space is the whole codebase, not the diff. The diff is only the anchor; the existing representation it is hunting for is by definition in files that did not change. Do not scope it to the changed files.
• It runs fine on --depth=lite output, since it consumes only 01-structure.md and 02-interfaces.md. Do not force --deep on its account.
• --no-context does NOT skip it (that rule removes only logic-integrity-auditor). It runs with xray_path: none and degrades to Glob plus Grep, reporting the reduced confidence in its Gaps section.
• It reads a concept index at .abstraction-architect/concept-index.json when one exists, which is what makes its knowledge-track dimensions (duplicated domain knowledge, competing sources of truth, redundant representation, duplicated state) worth running on a diff. The index is produced by /abstraction-architect:audit in global mode. When it is absent or stale the reviewer degrades to diff-anchored discovery and declares the reduced coverage; it never blocks. This reviewer never writes the index.

Testing dimension addendum. testing:test-suite-auditor partly inverts the default reviewer contract. Append this to its prompt:

Scope: run D2 to D8 only on tests owned by the changed modules; keep D1/D9
statistics suite-wide for context. Do NOT run the full suite inside this
review (no-run semantics): reuse metrics from CI history or existing report
artifacts, and mark anything unmeasured as such. Findings in this command's
severity format. Write your output to .team-review/findings-testing.md.

Two notes on why: a review is diff-anchored, so a whole-suite execution would dominate the phase's wall clock for findings mostly outside the diff; and suite-wide inventory statistics still matter because parallel-file and cross-layer-duplicate findings are invisible when only the changed test file is read.

The workspace-hygiene dimension

This dimension is not a senior-review agent. Spawn one teammate with subagent_type: repo-hygiene:workspace-auditor, which owns every check the filesystem and git decide without reading a symbol.

You are auditing workspace hygiene for a team review of {target}.

Load the repo-hygiene:repo-hygiene skill and run its catalog at the FULL
profile: C1 filesystem garbage, C2 generated artifacts tracked in git,
C3 .gitignore completeness, C4 .gitignore archaeology, C5 scratch and
pipeline-output directories, C6 orphan doc-assets, C7 git auxiliary state.

Report only. Remove nothing, and never run a destructive git command: C7 is
detection-only because a dropped stash or a removed worktree leaves no diff
for any commit to revert.

Anything that needs source comprehension is not yours. Put it under "Not
mine" and name senior-review:cleanup-auditor. The two dimensions are disjoint
by construction, so a finding either of you could have raised means one of
you widened.

Write your output to .team-review/findings-workspace-hygiene.md.

Its perimeter and cleanup-auditor's do not overlap, so Phase 4 consolidation has nothing to deduplicate between them. A finding appearing in both reports is a boundary violation to investigate, not an echo to fold.

Spawn and task creation

• name: {dimension}-reviewer (e.g., "security-reviewer", "logic-integrity-reviewe

…(truncated)