reverse-engineeringlisted

# Reverse Engineering ## Purpose Recover an evidence-backed engineering model from existing implementation without confusing observed behavior with confirmed user intent. ## Trigger Run for legacy/existing projects, code-to-model requests, missing architecture/Contract documentation, maintenance intake, or design-code drift analysis. ## Inputs - Scoped code revision, tests, schemas, configuration, build/deployment evidence, and runtime observations. - Existing Requirements, models, architecture, documentation, decisions, and target. - Project Constraints, known incidents, and terminology. ## Prerequisites - Define the reverse-engineering scope and desired output depth. - Confirm access and avoid executing unsafe/untrusted code without authorization. - Treat existing tests and behavior as evidence, not automatic truth. ## Procedure 1. Inventory the scoped implementation, entry points, packages, build/runtime boundaries, and dependencies. 2. Trace representative control flows, data flows, persistent state, errors, trust boundaries, and external integrations. 3. Derive structure: layers, modules, Components, ownership, dependencies, and coupling. 4. Recover observable Contracts: inputs, outputs, data structures, behavior, errors, boundaries, protocols, and versions. 5. Infer architecture styles, deployment topology, quality mechanisms, and material decisions; cite code/config evidence. 6. Create target-relevant UML/domain/behavioral models with confidence and source li