Classify Prototype Reuse
REVIEW-CLASSIFY-PROTOTYPE-REUSE
Summary
Classify whether a rebuild is reusing behavior, evidence, replaceable internal shape, or load-bearing boundaries. That separation helps preserve proven compatibility while discarding prototype scaffolding.
Rule
Classify what a rebuild reuses from a prototype or prior implementation.
Why
Prototype rebuilds can blur four different kinds of reuse: externally visible behavior, evidence from tests or production use, replaceable internal shape, and load-bearing boundaries. Treating all prototype details as either disposable or authoritative makes review harder. A name, helper layout, crate boundary, or document shape may be accidental, while a protocol behavior, migration path, or integration boundary may be the reason the prototype worked.
Classifying reuse lets reviewers preserve the parts that carry evidence or compatibility while replacing the parts that were only scaffolding.
Helps
- Prevents rewrites from discarding proven behavior or preserving accidental structure.
- Makes load-bearing boundaries visible before a smaller local API removes needed growth room.
Limits
Do not turn every small cleanup into architecture archaeology. Use this rule when a change rebuilds, ports, replaces, or extracts behavior from an existing prototype, spike, prior implementation, or legacy component. Record uncertain classifications as inferred or unknown instead of overstating evidence.
Agent Instruction
Classify prototype reuse as behavior, evidence, replaceable shape, or load-bearing boundary before
changing the boundary.Mechanisms
Supported by issue notes, ADRs for durable boundaries, comparison tests, migration plans, review packets, and explicit non-goals for prototype-only shape.