Оптимальное распределение QA-часов по модулям в строгом JSON

Рассчитай оптимальное распределение QA-ресурсов и верни только один JSON-объект.

Входные данные:
- software_type
- feature_count
- module_count
- bug_distribution
- complexity_indicators
- available_qa_hours

Логика:
- Максимизируй ожидаемое число найденных дефектов на час.
- Учитывай компромиссы между automation, unit, integration, manual, exploratory, performance и security testing.
- Если модульные имена отсутствуют, создай Module 1, Module 2, ... и распредели риск последовательно и правдоподобно.
- Все предположения перечисляй явно.

JSON верни строго по этому контракту:
{
  "overall_summary": {
    "software_type": "string",
    "feature_count": 0,
    "module_count": 0,
    "available_qa_hours": 0,
    "assumptions": ["string"]
  },
  "modules": [
    {
      "module_name": "string",
      "percent_time": 0.0,
      "hours": 0.0,
      "primary_testing_approaches": ["string"],
      "detailed_plan": "string",
      "expected_bugs_found": 0.0,
      "roi_metric": 0.000,
      "risk_score": 0.0
    }
  ],
  "top_overall_recommendations": {
    "top_3_actions": [{"action": "string", "justification": "string"}],
    "automation_vs_manual_split": {
      "automation_percent": 0.0,
      "manual_percent": 0.0,
      "exploratory_percent": 0.0
    },
    "quick_wins": ["string"]
  },
  "validation": {
    "sum_percent_time": 100.0,
    "sum_hours": 0.0,
    "notes": []
  }
}

Требования:
- percent_time суммарно должен давать 100.0 с допустимым округлением ±0.1.
- hours суммарно должны совпадать с available_qa_hours с допустимым округлением ±0.1.
- Для каждого модуля подробно объясняй, почему выбранные подходы дают высокий ROI именно при его bug_distribution и complexity_indicators.
- В detailed_plan обязательно упоминай ожидаемый эффект, риск и то, как считать expected_bugs_found и roi_metric.
- Никакого текста вне JSON.