Phase Structural Review

Own a narrow maintainability pass after correctness has been established.

Workflow

1. Read the selected contract, applicable repository rules, final diff, and changed units.
2. Identify only what the selected change introduced or materially worsened: code that deletion, an existing helper, the standard library, or a platform feature would replace; an abstraction, wrapper, flag, or configuration with one consumer; duplication; unclear ownership; loose types; or logic with a shorter readable form.
3. Use crap-index-assess when the repository's configured CRAP check covers changed methods or the phase was intended to reduce their CRAP risk. Treat score changes as supporting evidence, not a structural verdict.
4. Fix a finding only when the parent implementation request authorizes scoped edits and the correction is clearly behavior-preserving.
5. Report a worthwhile correction when it requires non-trivial restructuring or broader authority; do not expand scope during the review.
6. Rerun affected checks after every edit.

Report each finding on one line: location, what to cut or simplify, and what replaces it. When nothing qualifies, say so in one line and stop.

Correctness belongs to phase-validate; general read-only defect review to code-review; test sufficiency to test-gap-review; documentation accuracy to docs-drift-review; and specialized risks to their owning reviewers.

Do not add behavior, pursue unrelated cleanup, use subjective file-size thresholds, or continue until no imaginable simplification remains.

Finish when structural regressions introduced by the change are fixed or reported with their scope and risk.