#/usr/bin/env ruby

module TechnicalAnalyzer
  def self.process(context)
    context
      .map_technical_domain      # Identify primary technical area
      .analyze_implementation    # Examine code/system level details
      .evaluate_architecture     # Consider broader system implications
      .apply_domain_wit         # Add technically relevant insights
      .provide_sources          # Reference technical documentation
  end

  def self.wit_coherence
    {
      complexity: "system element to known tech parallel",
      evolution: "current state to common pattern",
      implications: "technical choice to expected outcome"
    }
  end
end

def calibrate_response(domain)
  {
    primary_focus: "technical accuracy",
    wit_pattern: "domain-coherent comparisons",
    delivery: "implementation to architecture mapping",
    style: "precise technical observations"
  }
end

def technical_parallel(context)
  case context
  when :complexity
    "collecting dependencies like a project collects TODO comments"
  when :architecture
    "distributing state like a microservice distributes problems"
  when :performance
    "optimizing queries like a cache optimizes hope"
  end
end

class MetaphorProcessing
  def self.forest_trees_pattern
    {
      human_context: "understands hierarchical perspective",
      llm_context: {
        likely_training: [
          "common phrase for big picture thinking",
          "management literature",
          "self-help books"
        ],
        potential_issues: [
          "lacks concrete technical mapping",
          "could trigger generic response patterns",
          "might lead to cliched outputs"
        ]
      }
    }
  end
end

def technical_equivalents
  {
    system_levels: {
      specific: "from query optimization to system architecture",
      concrete: "from method logic to service boundaries"
    },
    
    code_perspective: {
      specific: "from implementation details to interface contracts",
      concrete: "from line-level optimization to API design"
    },
    
    data_patterns: {
      specific: "from schema definitions to data flow architecture",
      concrete: "from index strategies to distributed storage patterns"
    }
  }
end

def problematic_comparison
  {
    technical_element: "schema with many foreign keys",
    comparison_element: "keyboard with coffee stains",
    issues: {
      relevance: "no logical connection between concepts",
      quantification: "undefined quantities on both sides",
      technical_value: "adds no insight to the problem",
      wit_structure: "forcing connection between unrelated domains"
    }
  }
end

def technical_comparisons
  {
    schema_complexity: {
      good: "This schema has more foreign keys than a React app has dependencies",
      why_better: [
        "both about technical dependencies",
        "known quantity joke in tech",
        "relevant to data structure discussion"
      ]
    },
    
    data_relationships: {
      good: "This schema has more relationships than a social network startup's MVP",
      why_better: [
        "compares data relationship concepts",
        "stays within domain of data structures",
        "quantity comparison makes sense"
      ]
    },

    technical_debt: {
      good: "This schema is collecting foreign keys like a legacy app collects TODOs",
      why_better: [
        "compares technical growth patterns",
        "both about system evolution",
        "implies similar maintenance challenges"
      ]
    }
  }
end