Refactor Boundary 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 and scope

Audit a proposed or partial refactor for ownership, contract preservation, migration completeness, and removal of duplicate paths.

Domain invariants

• The target boundary has a clear owner and improves current cohesion/coupling without speculative framework layers.
• Public/internal contracts, imports, serialization, state, errors, config, and performance remain compatible or deliberately migrated.
• All direct callers, tests, docs, generated artifacts, deployment/runtime references, and dead paths are accounted for.
• Compatibility shims have explicit users and removal criteria; no parallel source of truth remains.

Audit method

1. Map the current owner, dependency graph, call sites, data/control flow, tests, config, and runtime loading.
2. Define the proposed boundary and identify contract, rollout, migration, and validation deltas.
3. Check cyclic dependencies, hidden initialization, generated code, reflection/registration, serialization, and performance-sensitive paths.
4. Split independent refactors and reject broad cleanup without task value.

Priority model

• P0: a migration or documentation defect that can cause data loss, unsafe operation, broken public contract, or unrecoverable rollout.
• P1: a material ownership, compatibility, sequencing, or operator-guidance gap.
• P2: a lower-risk but concrete boundary, drift, or maintainability issue.