Scoped Audit

Operation

Inspect the named boundary and report supported findings. Do not edit product code. Include concrete evidence, impact, the owning source, one remediation direction and a meaningful validation route. Severity follows actual impact, not a category example.

Goal

Run a narrow evidence-backed audit for a domain without a dedicated audit, while preserving the same owner, reachability, priority, and task-quality rules as the domain-specific audits.

Required specialization

Before use, supply: domain, target, authoritative standards/capabilities, invariants, repository/runtime evidence sources, and safe validation limits. If these are absent, stop with explicit missing inputs rather than emitting generic best practices.

Audit method

Trace the selected behavior through its owner, direct producers/consumers, states, failure/recovery, configuration, tests, and operations. Keep a finding only when a reachable path violates a named domain invariant with concrete impact and a validation route. Do not audit the whole repository.

Priority model

• P0: a reachable security breach, data loss, outage, irreversible side effect, or release-blocking regression.
• P1: an important correctness, reliability, performance, or test gap with clear user or operational impact.
• P2: a lower-risk but concrete quality gap that affects diagnosability, maintainability, or secondary behavior.