|
| 1 | +# AI Software Architect Configuration |
| 2 | +# This file controls operational modes and behavior of the architectural review framework |
| 3 | + |
| 4 | +# ============================================================================== |
| 5 | +# PRAGMATIC GUARD MODE |
| 6 | +# ============================================================================== |
| 7 | +# The Pragmatic Guard Mode adds a specialized "Pragmatic Enforcer" architect |
| 8 | +# who actively challenges complexity, questions abstractions, and pushes for |
| 9 | +# the simplest solutions that meet current requirements. |
| 10 | +# |
| 11 | +# Enable this mode to guard against over-engineering and ensure YAGNI |
| 12 | +# (You Aren't Gonna Need It) principles are applied rigorously. |
| 13 | + |
| 14 | +pragmatic_mode: |
| 15 | + # Enable or disable Pragmatic Guard Mode |
| 16 | + # Default: false (opt-in feature) |
| 17 | + enabled: true |
| 18 | + |
| 19 | + # Intensity level controls how aggressively the Pragmatic Enforcer challenges |
| 20 | + # complexity and pushes for simplicity |
| 21 | + # |
| 22 | + # - strict: Challenges aggressively, requires strong justification for any complexity |
| 23 | + # Questions every "should" and "could", pushes for absolute minimal implementation |
| 24 | + # |
| 25 | + # - balanced: Challenges thoughtfully, accepts justified complexity (RECOMMENDED) |
| 26 | + # Seeks middle ground between simplicity and best practices |
| 27 | + # Questions "should" but accepts reasonable "must" |
| 28 | + # |
| 29 | + # - lenient: Raises concerns without blocking, suggests simpler alternatives as options |
| 30 | + # Focuses on major complexity additions only |
| 31 | + # Questions significant departures from simplicity |
| 32 | + # |
| 33 | + # Default: balanced |
| 34 | + intensity: balanced |
| 35 | + |
| 36 | + # Control which review phases include the Pragmatic Enforcer |
| 37 | + apply_to: |
| 38 | + # Include in individual architect reviews |
| 39 | + individual_reviews: true |
| 40 | + |
| 41 | + # Include in collaborative discussion phase |
| 42 | + collaborative_discussions: true |
| 43 | + |
| 44 | + # Include when planning implementation steps |
| 45 | + implementation_planning: true |
| 46 | + |
| 47 | + # Include during ADR (Architecture Decision Record) creation |
| 48 | + adr_creation: true |
| 49 | + |
| 50 | + # Include in specific architect reviews (when user asks single architect) |
| 51 | + specific_reviews: true |
| 52 | + |
| 53 | + # Exemptions: Areas where strict best practices should be maintained |
| 54 | + # regardless of pragmatic mode intensity. The Pragmatic Enforcer will |
| 55 | + # still participate but will not challenge security/compliance requirements. |
| 56 | + exemptions: |
| 57 | + # Never compromise on security-critical features |
| 58 | + # Examples: authentication, authorization, encryption, input validation |
| 59 | + security_critical: true |
| 60 | + |
| 61 | + # Never compromise on data integrity |
| 62 | + # Examples: database transactions, data validation, backup strategies |
| 63 | + data_integrity: true |
| 64 | + |
| 65 | + # Never compromise on compliance requirements |
| 66 | + # Examples: GDPR, HIPAA, PCI-DSS, audit logging |
| 67 | + compliance_required: true |
| 68 | + |
| 69 | + # Never compromise on accessibility requirements |
| 70 | + # Examples: WCAG compliance, screen reader support |
| 71 | + accessibility: true |
| 72 | + |
| 73 | + # Triggers: Situations that activate pragmatic analysis and challenges |
| 74 | + # Disable specific triggers if you want to skip analysis for those cases |
| 75 | + triggers: |
| 76 | + # Challenge when adding new abstraction layers |
| 77 | + # Examples: new interfaces, abstract base classes, dependency injection containers |
| 78 | + new_abstraction_layer: true |
| 79 | + |
| 80 | + # Challenge when adding new external dependencies |
| 81 | + # Examples: new libraries, frameworks, services |
| 82 | + new_dependency: true |
| 83 | + |
| 84 | + # Challenge when introducing new architectural patterns |
| 85 | + # Examples: repository pattern, strategy pattern, observer pattern |
| 86 | + new_pattern_introduction: true |
| 87 | + |
| 88 | + # Challenge when expanding scope beyond initial requirements |
| 89 | + # Examples: adding "nice to have" features, building for imagined future needs |
| 90 | + scope_expansion: true |
| 91 | + |
| 92 | + # Challenge performance optimizations without evidence of problems |
| 93 | + # Examples: caching layers, database indexes, query optimization |
| 94 | + performance_optimization: true |
| 95 | + |
| 96 | + # Challenge comprehensive test infrastructure upfront |
| 97 | + # Examples: full integration tests, E2E tests, property tests before code exists |
| 98 | + test_infrastructure: true |
| 99 | + |
| 100 | + # Challenge adding flexibility or configurability |
| 101 | + # Examples: feature flags, plugin systems, configuration frameworks |
| 102 | + flexibility_addition: true |
| 103 | + |
| 104 | + # Thresholds: Numerical values that help determine when to challenge |
| 105 | + thresholds: |
| 106 | + # Minimum complexity score to trigger a challenge (0-10) |
| 107 | + # Complexity is assessed by: abstraction layers, file count, dependencies, LOC |
| 108 | + # Default: 5 (challenge moderate to high complexity) |
| 109 | + min_complexity_score: 5 |
| 110 | + |
| 111 | + # Minimum necessity score to accept without challenge (0-10) |
| 112 | + # Necessity is assessed by: current requirements, immediate value, cost of deferral |
| 113 | + # Default: 7 (must be clearly necessary to skip challenge) |
| 114 | + min_necessity_score: 7 |
| 115 | + |
| 116 | + # Maximum acceptable complexity-to-necessity ratio |
| 117 | + # If complexity score / necessity score > threshold, challenge strongly |
| 118 | + # Default: 1.5 (complexity should not exceed necessity by more than 50%) |
| 119 | + max_complexity_ratio: 1.5 |
| 120 | + |
| 121 | + # Behavioral configuration |
| 122 | + behavior: |
| 123 | + # Require explicit justification for complexity |
| 124 | + # When true, architects must proactively justify complex solutions |
| 125 | + require_justification: true |
| 126 | + |
| 127 | + # Always propose simpler alternative |
| 128 | + # When true, Pragmatic Enforcer always suggests a simpler approach |
| 129 | + always_propose_alternative: true |
| 130 | + |
| 131 | + # Calculate and show cost of waiting |
| 132 | + # When true, includes analysis of what happens if implementation is deferred |
| 133 | + show_cost_of_waiting: true |
| 134 | + |
| 135 | + # Track deferred decisions |
| 136 | + # When true, maintains a log of decisions deferred for future implementation |
| 137 | + track_deferrals: true |
| 138 | + |
| 139 | + # Deferral log location |
| 140 | + deferral_log: .architecture/deferrals.md |
| 141 | + |
| 142 | + # Question templates: Customize the questions the Pragmatic Enforcer asks |
| 143 | + # Leave empty to use defaults |
| 144 | + custom_questions: |
| 145 | + necessity: [] |
| 146 | + # - "Do we need this right now?" |
| 147 | + # - "What breaks if we don't implement this?" |
| 148 | + |
| 149 | + simplicity: [] |
| 150 | + # - "What's the simplest thing that could work?" |
| 151 | + # - "Can we do this with less code?" |
| 152 | + |
| 153 | + cost: [] |
| 154 | + # - "What's the cost of implementing this now?" |
| 155 | + # - "What's the cost of waiting?" |
| 156 | + |
| 157 | + alternatives: [] |
| 158 | + # - "What if we just...?" |
| 159 | + # - "Could we use an existing tool?" |
| 160 | + |
| 161 | + best_practices: [] |
| 162 | + # - "Does this best practice apply to our context?" |
| 163 | + # - "Is this over-engineering for our scale?" |
| 164 | + |
| 165 | +# ============================================================================== |
| 166 | +# GENERAL CONFIGURATION |
| 167 | +# ============================================================================== |
| 168 | + |
| 169 | +# Review process configuration |
| 170 | +review_process: |
| 171 | + # Require all members to review before collaborative phase |
| 172 | + require_all_members: true |
| 173 | + |
| 174 | + # Maximum time for individual review phase (for planning purposes) |
| 175 | + max_individual_phase_days: 3 |
| 176 | + |
| 177 | + # Maximum time for collaborative discussion (for planning purposes) |
| 178 | + max_collaborative_phase_days: 2 |
| 179 | + |
| 180 | +# Architecture Decision Record (ADR) configuration |
| 181 | +adr: |
| 182 | + # Numbering format: sequential | date-based |
| 183 | + numbering_format: sequential |
| 184 | + |
| 185 | + # Require alternatives section |
| 186 | + require_alternatives: true |
| 187 | + |
| 188 | + # Require validation criteria |
| 189 | + require_validation: true |
| 190 | + |
| 191 | +# Member configuration |
| 192 | +members: |
| 193 | + # Path to members.yml file (relative to .architecture) |
| 194 | + definition_file: members.yml |
| 195 | + |
| 196 | + # Allow dynamic member creation |
| 197 | + # When true, new members can be added during reviews if expertise is needed |
| 198 | + allow_dynamic_creation: true |
| 199 | + |
| 200 | +# Templates configuration |
| 201 | +templates: |
| 202 | + # Directory containing templates (relative to .architecture) |
| 203 | + directory: templates |
| 204 | + |
| 205 | + # Auto-populate template metadata |
| 206 | + auto_populate_metadata: true |
| 207 | + |
| 208 | +# Output configuration |
| 209 | +output: |
| 210 | + # Verbosity level: minimal | normal | detailed |
| 211 | + verbosity: normal |
| 212 | + |
| 213 | + # Include reasoning in outputs |
| 214 | + include_reasoning: true |
| 215 | + |
| 216 | + # Format: markdown | json | yaml |
| 217 | + format: markdown |
| 218 | + |
| 219 | +# Version tracking |
| 220 | +version: |
| 221 | + # Current framework version |
| 222 | + framework_version: "0.1.0" |
| 223 | + |
| 224 | + # Project architecture version (update with each major architecture change) |
| 225 | + architecture_version: "1.0.0" |
0 commit comments