architecture-design

Design a working solution, then make it smaller

Use for a selected architecture task or when a wrong structural choice would make implementation expensive to redo. A clear bounded change can proceed through the existing implementation route. Scale design effort to the uncertainty that could change the solution; do not fill out stages merely because this skill exists.

Recover current inputs and applicable learning

Begin with the latest objective and corrections, actual project state and constraints, and relevant tested lessons, skills and outcomes from the existing indexes. Retrieve the few records that could change this decision before redesigning; do not scan the full history or load every skill. Verify freshness against current source, runtime and user intent. Keep project facts, proposed product improvements and reusable LHC method changes distinct. Prior guidance is evidence to assess, not authority over the current request.

Establish what must work

Start with the accepted user outcome and the actual consumer path. Describe a coherent solution that can achieve it before distributing implementation tasks. Identify the properties that matter for this use: observable behavior, boundaries, data ownership and lifecycle, integration contracts, and relevant failure behavior. Distinguish required properties from desirable extensions. An ideal target helps expose dependencies; it does not authorize features outside the selected scope.

Trace existing components and constraints before introducing new ones. State the costly assumptions: which wrong choice would force a migration, invalidate an interface or prevent the user from reaching the goal? Compare practical alternatives against those properties and the cost of changing course. Preserve a useful existing design when evidence supports it.

Three-pass design

Use this sequence when designing a solution, before committing to its implementation:

1. Working solution. Describe an ordinary, coherent way to solve the actual task end to end with current components and constraints. First establish how it works; do not start by cutting the scope of a solution that does not exist yet.
2. Ideal version. Improve that same solution into the best version for the stated purpose. Identify what better behavior, reliability, UX or architecture buys and what it costs. This is a design reference, not permission to build every extension.
3. 80%-value MVP. Reduce the ideal to the smallest complete working version that retains roughly 80% of the useful result, not 80% of the implementation. Keep the essential path and architecture-critical boundaries. State the selected value, deferred improvements and a real acceptance check.