arrive-reviewability

<!-- ARRIVE: generated by `arrive sync agent-rules` — do not hand-edit. Edit the canonical source under `arrive/agent-rules/` or `arrive/agent-commands/` and re-run sync. --> <!-- canonical: arrive/agent-rules/reviewability.md -->

Reviewability Rules

Keep changes bounded and reviewable. TDD/Tidy First sequence: arrive-dev-practices.mdc. Budget thresholds: arrive-core.mdc.

Smaller, Bounded Edits

Prefer smaller, focused changes:

1. Isolate tidying - Refactoring commits separate from behavior changes
2. Isolate migrations - Database/schema changes in separate PRs
3. Isolate auth changes - Security-sensitive code separately
4. Separate interface from implementation - Public API changes vs internal refactors
5. Split by ARRIVE component - When touching multiple components

Review-Time Usage

• Treat review-time estimate as a planning signal, not a vanity metric.
• Use arrive score output to decide checkpointing:
  • Green: proceed, optional split
  • Yellow: split at natural tidy/test/feat boundaries
  • Red: split before continuing implementation
• Track estimated and actual review time in the Advance frontmatter and adjust future split strategy when estimates are consistently off.

Evidence Capture

Always run the fastest verification that matches change type:

Change Type	Required Evidence
Logic change	Unit tests (TDD)
API change	Integration tests (TDD)
UI change	Visual/E2E tests
Config change	Lint/validation
Tidying	Existing tests still pass

Attach evidence to the Advance.

Risk Signals

Watch for these risk flags:

• resident_touched - Resident component modified
• migration - Database/schema changes
• auth - Authentication/authorization changes
• concurrency - Threading/async changes
• caching - Cache invalidation changes
• public_api - Public interface changes
• new_dependency - New external dependency

Each flag increases reviewability score.