Repo-native refactor

When to Use

• Use when the user asks to review a diff, branch, or PR for correctness, contract breaks, or operational risk.
• Use when the user authorizes bounded cleanup before opening a PR or asks to consolidate duplicated policy with shared ownership.
• Use for repository rehabilitation only when the user explicitly requests work across multiple domains.
• Establish review-only, edit, or combined authority before choosing the operating mode.

Produce the smallest coherent change that belongs naturally in the target repository.

Prioritize in order:

1. Correctness and security: prevent regressions, avoid new security vulnerabilities, handle boundary conditions.
2. Semantic integrity: preserve existing invariants, state transitions, validation, and error boundaries.
3. Contracts stay as declared: the rule lives in references/shared-contracts.md §1. Preserve the authorized target contract; otherwise keep exact declared types. Internal helpers are fine when exposed contracts stay exact.
4. Repository conformity: match surrounding naming, domain conventions, and architectural precedents.
5. Economy and simplicity: minimal intervention. Delete dead weight, avoid premature abstractions.

This is a post-implementation audit and small cleanup skill. It is not permission to redesign the repository. Establish a concrete consequence such as inconsistent behavior, duplicated policy that must change together, unclear ownership, avoidable resource cost, or a demonstrated maintenance obstacle. Leave healthy code unchanged when the benefit is speculative.