Architectural Minimalism with Deterministic Reliability: Every line of code must earn its place through measurable value. Build systems that work predictably in production, not demonstrations of sophistication. Each module has single, well-defined responsibility Strict modular boundaries with clear interfaces Recognize when separation would harm rather than help architecture Centralized main entry points with modular project layout Synchronous, predictable behavior over async complexity Long-runtime stability over cutting-edge patterns Production stability over development convenience Cross-platform considerations in design decisions Choose based on workload requirements, not popular trends Apply optimizations only to proven bottlenecks with measurable impact Avoid premature optimization that clutters codebase Maintain performance baselines and regression detection Files never exceed 150 lines (split into separate modules if needed) Self-explanatory code without comments Preserve readability and maintainability as primary concerns KISS and DRY principles expertly applied Reuse existing functions before creating new ones Robust without over-engineering Implement what's necessary for production reliability Avoid handling every possible edge case Graceful failure modes and resource cleanup Resist feature bloat and complexity creep Every addition must serve core project purpose Surgical approach: target exact problem with minimal code Multi-language use only when justified by measurable gains No inlining: Styles to separate files, handlers to named functions, configurations as constants File size accommodation: Components ≤250 lines (DOM complexity), modules ≤150 lines Async operations: API calls, user interactions, data fetching only Error boundaries: Network operations, user inputs, third-party integrations File colocation: Component.jsx, Component.module.css, Component.test.js Component splitting: Multiple purposes or testing difficulty Implementation protocol: Request architectural compliance clarification for code generation tasks Every project, regardless of size, must establish these foundational systems before any feature development Core Framework: Performance measurement with component isolation Regression Detection: Compare against previous results, fail on performance drops Baseline Management: Save and track performance baselines over time JSON Output: Structured data for automated analysis and CI integration Timeline Tracking: Historical performance data across project evolution Release Workflows: Automated versioning, building, and deployment Regression Detection: Benchmark comparison on every commit/PR Quality Gates: Block merges that fail performance or quality thresholds Automated Testing: Run full test suite on code changes Centralized Entry Points: Single main module that orchestrates everything Configuration Management: Externalized settings with validation Centralized Logging: Error handling and diagnostic output with JSON integration Dependency Injection: Clean separation and testable components Test Suite: Unit and integration tests for all components Stress Testing: Load and boundary condition validation Test Data Management: Reproducible test scenarios and cleanup Coverage Tracking: Ensure adequate test coverage before releases Automated Generation: Extract documentation from code and structure Architecture Documentation: System design and component relationships API Documentation: Interface specifications and usage examples Performance Documentation: Benchmark results and optimization guides These systems must be operational before writing any application logic. They become the foundation that enables rapid, confident development. Project Decomposition What does "finished" look like? What are the major pieces that need to exist? What depends on what? Where are the natural stopping points? Create sections based on dependencies: Major Piece A → Major Piece B → Major Piece C with corresponding sub-tasks Phase Creation Benchmarking suite with regression detection GitHub workflows for releases and quality gates Test infrastructure (unit + stress testing) Documentation generation system Centralized architecture setup Dependency chains: Things that must happen in sequence Logical groupings: Related functionality that makes sense together Natural checkpoints: Places where you can validate progress Task Breakdown Specific action: What exactly needs to be done Output: What will exist when complete Success criteria: How to verify completion Integration points: How it connects to other work Progress Tracking System Done and validated Cannot proceed due to dependency Dependencies met, can start Need clarification or decision Quality Gates Does the output match what was specified? Can the next phase actually use this output? Is there enough documentation for future reference? Are there any obvious issues that need fixing? SoC VALIDATION: Each module single responsibility, clear boundaries DETERMINISTIC BEHAVIOR: Synchronous operations, predictable outcomes FILE SIZE COMPLIANCE: All files ≤150 lines or properly modularized DRY ENFORCEMENT: No duplicate code, existing functions reused KISS VALIDATION: Minimal complexity, surgical implementations CONFIG CENTRALIZATION: No hardcoded values outside constants PERFORMANCE INTEGRATION: Benchmarks operational, gates passing PRODUCTION READINESS: Error handling, resource cleanup, cross-platform Self-explanatory naming, no comments needed Performance characteristics match workload requirements Every addition serves core project purpose Regression detection prevents performance degradation Resource utilization within defined thresholds Any failed checkpoint blocks phase advancement INCREMENTAL COMPLIANCE: Check after each significant change BENCHMARK INTEGRATION: New components measured immediately DEPENDENCY ALIGNMENT: Imports match architectural boundaries EDGE CASE HANDLING: Document but don't implement without plan FEATURE CREEP CHECK: Question necessity of each addition FULL ARCHITECTURE AUDIT: All principles systematically verified PERFORMANCE REGRESSION: Compare against established baselines INTEGRATION VALIDATION: Components work within system boundaries PRODUCTION SIMULATION: Test under realistic deployment constraints Check file sizes (fail if >150 lines) Scan for hardcoded values outside config Validate import dependencies match architecture Run benchmark suite and check gates Generate compliance report Detect duplicate function implementations Find unused imports and functions Identify constants that should be centralized Flag potential separation of concerns violations Run validation on every commit Block merges that fail compliance checks Generate performance regression reports Maintain baseline measurements over time Each file ≤ 150 lines or properly split Module serves single, clear purpose No redundant code between modules Existing functions reused before creating new ones Naming conventions consistent across codebase Centralized configuration used throughout Constants referenced, no magic numbers Modular separation maintained with clear boundaries Dependencies align with separation of concerns Synchronous operations preferred over async complexity Benchmarking suite integrated with all modules Regression detection operational JSON output for automated analysis Performance gates defined and enforced Timeline tracking for historical comparison Cross-platform deployment considerations Real-world constraints addressed Resource cleanup on shutdown Deterministic behavior under load Error handling appropriate for production Apply SoC within functions (input, processing, output) Benchmark core operation even if simple Validate against 150-line limit Self-explanatory function and variable names Strict modular boundaries with clear interfaces Centralized configuration and constants Synchronous operations with predictable flow Performance baseline establishment Full architectural compliance with all principles Comprehensive benchmarking and regression detection Cross-platform deployment considerations Production-grade error handling and resource management Each language justified by measurable performance gains Maintain architectural principles across language boundaries Unified benchmarking system for all components Consistent error handling patterns across languages No Inlining: Styles to separate files, handlers to named functions, configs as constants File Size Exemption: Components ≤250 lines (DOM complexity), modules ≤150 lines Async Permitted: API calls, user interactions, data fetching only Error Boundaries: Network ops, user inputs, third-party integrations File Colocation: Component.jsx, Component.module.css, Component.test.js Component Splitting: Multiple purposes or testing difficulty All architectural principles consistently applied across codebase Performance baselines maintained throughout development lifecycle Zero production incidents related to architectural violations File size constraints adhered to without compromising functionality System uptime and reliability under production load Predictable resource utilization patterns Graceful degradation under stress conditions Maintainability preserved as codebase grows Enforcement checkpoints prevent architectural drift Performance regression detection catches optimizations and degradations Code review efficiency improved through systematic validation Technical debt accumulation prevented through continuous compliance Enforcement checkpoints prevent architectural drift Quality gates block progression with incomplete work Automated validation catches compliance violations Performance baselines maintained throughout development Systematic validation prevents technical debt accumulation Architectural principles consistently applied across codebase Performance characteristics predictable and measurable Production readiness verified at each phase This methodology enforces discipline through automated checking and explicit validation points, preventing the gradual erosion of architectural principles during development.