Review angle reference
The review lenses, automatic detection rules, and model tier for each angle.
Review lenses cover concerns such as correctness, security, SQL, and accessibility. Local bounded low-risk changes use one holistic reviewer; risk-bearing, broad, CI, audit, or explicitly configured reviews retain specialist workers. Every route uses independent adjudication and verified receipts.
Angle selection
The detector
owns the selection heuristics. It starts with general correctness and adds specialists from
changed-path, changed-line, or verified context signals. Before dispatch it may consolidate the
bounded local queue into general, which covers correctness, security/compatibility, simplicity,
project rules, acceptance, documentation, and tests.
Explicit force/skip settings preserve specialist selection. force wins a tie; the base bugs
pass cannot be skipped. See angle selection.
Angle catalog
The catalog describes each lens. Automatic path/token rules live only in the detector; prompt frontmatter owns the worker tier.
| Angle | Concern |
|---|---|
general | Holistic bounded local review, including applicable rules and approved intent |
acceptance | Approved acceptance criteria and contract claims |
aeo | AI-crawler access and structured answer-engine content |
api | Routes, public contracts, schemas, and wire compatibility |
architecture | Boundaries, coupling, and structural quality |
bugs | Evidence-backed correctness and broken behavior |
comments | Comment accuracy; findings are non-blocking |
conventions | The repository's own applicable rules |
database | Integrity, migrations, transactions, queries, and access control |
deps | Dependency compatibility and hygiene |
design | Visual design, UX, and accessibility |
docs | Accuracy of documentation affected by the change |
i18n | Translation catalogs and message usage |
infra | CI, containers, deployment, and infrastructure definitions |
observability | Logging, diagnostics, and silent failures |
production-readiness | Operational failure handling and resource limits |
security | Injection, authorization, secrets, and unsafe data flows |
seo | Search metadata, crawling, and indexing |
simplify | Unnecessary code, duplication, and needless abstractions |
skills | The validated changed Agent Skill package |
tests | Observable behavior coverage and test quality |
Three angles behave specially. comments is always non-blocking: it posts nits, never a blocking finding. conventions only runs when the repo carries a rule file (AGENTS.md, CLAUDE.md, .cursorrules, .windsurfrules, or GEMINI.md) along the changed paths. acceptance only runs when prefetch resolves governing woostack intent; a later-increment woostack-defer(<ref>) marker can demote matching missing work to a visible non-blocking nit, but never defers security.
Pre-flight use
The same angle vocabulary also applies before implementation. When
woostack-harden hardens a specification or plan, and when
woostack-plan reviews its own work, a specification and plan
pre-flight translates each relevant lens into questions to answer before implementation. A
separate premise lens always checks the problem at the earliest problem-bearing artifact. Plan
hardening also verifies that the linked source specification records the evidence. These checks do
not add an approval gate. Pull request review still applies the angles to each code increment.
Tiers
Each angle runs at a model tier matched to its work: fast for rubric and pattern checks, and
standard for reasoning-heavy passes. One evidence adjudicator filters every candidate at deep.
The tier-to-model mapping per provider is documented in
Context management. The
model selection reference lists the available overrides.