implementation-approach

Implementation Strategy Selection Framework (Meta-cognitive Approach)

Meta-cognitive Strategy Selection Process

Phase 1: Decision-Sufficient Current State Analysis

Core Question: "What does the existing implementation look like?"

Analysis Framework

Architecture Analysis: Responsibility separation, data flow, dependencies, technical debt
Implementation Quality Assessment: Code quality, test coverage, performance, security
Historical Context Understanding: Current form rationale, past decision validity, constraint changes, requirement evolution

Meta-cognitive Question List

• What is the true responsibility of this implementation?
• Which parts are business essence and which derive from technical constraints?
• What dependencies or implicit preconditions are unclear from the code?
• What benefits and constraints does the current design bring?

Stop when another current-state fact cannot change responsibility, reuse, option validity, total complexity, a contract, or verification.

Completion evidence: inspected paths, observed architecture/data-flow facts, known constraints, inferred historical rationale labeled as inferred, and unknowns that could change strategy selection.

Transition: proceed when every strategy-relevant claim is observed, explicitly inferred with evidence, or recorded as unknown.

Phase 2: Design Convergence

Core Question: "What is the smallest design that delivers the current required outcome, and what evidence forces each addition beyond it?"

Complete these steps in order before exploring implementation strategies:

1. Existing-Surface Baseline: Form the simplest end-to-end path that delivers the current outcome through existing responsibilities. Explicit requirements and accepted decisions are binding; suggested mechanisms remain candidates.
2. Evidence Check: Test that path against current requirements, verified constraints, observed in-scope problems, and evidence-backed material risks. Keep only the unmet conditions that can change the selected design.
3. Targeted Comparison: For each unmet condition, test reuse, derivation from existing data, on-demand computation, or responsibility at the current caller or boundary before adding design surface. Compare viable choices by total complexity across the dimensions that materially differ: user decisions, settings, modes, concepts, outputs, persistent state, implementation paths, UX, runtime, implementation, testing, documentation, and maintenance. Select the lowest-total-complexity choice that satisfies the condition.
4. Subtraction Check: Remove each proposed addition and re-test its governing condition. Retain it only when the confirmed outcome, a required boundary, or necessary proof becomes unmet.