FIX_PROBLEMS

[Payel-git-ol]

План фикса Octra — проблемы и решения

Философия Octra: AI — гениальный, но ненадёжный мозг. Система — жёсткая оболочка с предсказуемым конвейером. AI не творит — он исполняет строго поставленную задачу, а каждый шаг проверяется.

---

1. Новый task type: github

Проблема: GitHub issue URL обрабатывается как обычная задача. Ссылка детектится regexp внутри detectGitHubIssueTask, issue body тупо приклеивается к Description. Нет явного паспорта issue, нет комментариев, нет скриншотов, нет анализа существующего репозитория перед планированием.

Решение: Добавить task type github наравне с code, research, document, presentation.

[Input: Title + Description]
    ↓
AnalyzeTaskInput():
  - Сканирует вход по паттернам (полный URL, owner/repo#N, #N)
  - GH API: тело issue + все комментарии + структура репозитория
  - GH API: проверка открытых PR на этот issue
  - Сохраняет скриншоты
  - Возвращает TaskInstruction (структурированный паспорт)
    ↓
ExecuteTask():
  - Если TaskInstruction != nil → task_type = "github"
  - Кладет паспорт в Meta, НЕ мутирует Description
  - Boss получает отдельную инструкцию, а не засорённый Description

Что появляется:

• internal/service/github/analyze.go — анализатор входа
• internal/service/github/types.go — IssueInstruction структура
• internal/prompts/boss.go — отдельный промпт PlanGitHubWork

Как меняется Boss: Получает задачу с типом github, видит паспорт issue в Meta. Промпт говорит: «работаем с реальным репозиторием, клонируй, сохраняй структуру, минимальное изменение».

---

2. Сбор полного контекста issue (до пайплайна)

Проблема: Только тело issue, обрезанное до 4000 символов. Нет комментариев, скриншотов, меток, информации о том, есть ли уже PR.

Решение: При детекте github-ссылки собирать:

IssueInstruction:
  - Owner, Repo, Number
  - Issue Title (полный)
  - Issue Body (весь, без обрезания)
  - All Comments: [ { author, body, created_at, attachments } ]
  - Labels: [bug, enhancement, ...]
  - State: open/closed
  - Existing PRs: [{ number, state, url }]
  - Screenshots: [{ filename, url }] — скачаны локально
  - Repository:
      - Default Branch
      - File tree (первые 200 файлов)
      - Key files (README, package.json, Cargo.toml и т.д.)

Данные сохраняются в Meta["github_context"] как JSON. При передаче от Boss к Manager к Worker этот блок не пересобирается и не дрифтует — передаётся как есть.

---

3. Изменение порядка: клонирование → планирование

Сейчас: thinkAboutTask (Boss) → setupProject (клон)
Проблема: AI планирует архитектуру, не видя кодовой базы. Планирует вслепую.

Решение: Для github-задач:

detectGitHubIssueTask()
  ↓
setupProject() — клонирование репозитория, ветка issue-{number}-{slug}
  ↓
appendRepositoryContent() — передача списка файлов + содержимого ключевых файлов в Meta
  ↓
thinkAboutTask() — Boss видит реальный проект

Boss получает не только список файлов (summarizeRepository), но и содержимое ключевых файлов: README, конфиги, точки входа, недавние diff'ы.

---

4. Git-ветки для воркеров в Group Chat

Сейчас: Все воркеры пишут в одну папку. Конкуренция за файлы, нет изоляции.

Решение: Каждый агент в Group Chat работает в своей git-ветке:

Boss:     issue-42-fix-login  (от main)
Manager:  manager-backend     (от issue-42-fix-login)
Worker1:  worker-backend-db   (от manager-backend) → коммитит → пушит
Worker2:  worker-backend-api  (от manager-backend) → коммитит → пушит
  ↓
Manager мёржит worker-ветки → резолвит конфликты через AI
  ↓
Boss мёржит manager-ветки → создаёт PR

Group Chat решает:

• Воркеры видят в чате, что делают другие
• Если конфликт — AI обсуждает разрешение
• Каждый воркер изолирован git-веткой
• При прерывании — коммиты сохраняются

Что меняется:

• worker/agent.go — при старте git checkout -b worker-{role}, при завершении git add + commit + push
• manager/assign.go — mergeWorkerBranches с AI-разрешением конфликтов
• boss/project.go — мерж manager-веток в boss-ветку

---

5. Draft PR до старта AI

Сейчас: pushToGitHub вызывается после validateSolution.

Проблема: Пользователь не видит прогресс. При прерывании — PR нет, работа потеряна.

Решение: После клонирования репозитория и до запуска Boss:

setupProject() → клон + ветка issue-42
  ↓
createDraftPR():
  - gh pr create --draft
  - Title: "[WIP] Fix #42: ..."
  - Body: "Fixes owner/repo#42"
  ↓
Boss → Manager → Worker → коммиты →
  ↓
gh pr ready     ← когда всё готово

Каждый коммит AI летит в ту же ветку — PR обновляется автоматически. Пользователь видит живой прогресс.

---

6. Обратная связь из PR-комментариев

Сейчас: Нет мониторинга комментариев. Если пользователь написал в PR — AI не видит.

Решение: После завершения основного цикла — watch-режим:

Основной цикл завершён (PR открыт)
  ↓
WatchPR():
  - Каждые N минут проверяет новые комментарии
  - Если есть:
      - Передаёт текст комментария Manager → Worker как доработку
      - Worker делает новый коммит
      - PR обновляется
  ↓
Если approve → gh pr merge (опционально)

Достаточно простого polling-цикла. Не нужен Webhook.

---

7. Обход пайплайна для простых issue

Сейчас: Любая задача проходит Boss → Manager → Worker → Review → Validate.

Решение: Если issue тривиальный (опечатка, однофайловый фикс, typo), не гонять через весь пайплайн.

Детекция тривиальности:

• Issue body < 500 символов
• Нет labels: enhancement, feature
• Title содержит: "typo", "fix typo", "rename", "спасибо", "please"
• Изменение только в README или документации

Действие: Один AI-запрос с промптом "read the issue, make the fix, commit, push".

---

8. Улучшение гайдов (skill fragments)

Сейчас: 46 фрагментов с размытыми советами. Бесполезны.

Решение: Гайды должны давать конкретику:

Плохо:

API design: consistent, versioned endpoints; validate all input.

Хорошо:

В этом проекте для REST API используем:

• go-chi/chi роутер
• render.JSON для ответов
• Валидация через go-playground/validator
• Ошибки через render.StatusJSON + internal/errors
• Контроллер → Service → Repository

Форматы гайдов:

• Шаблоны файлов (пустой main.go, boilerplate handler)
• Правила «можно/нельзя» под конкретный проект
• Примеры структуры директорий
• Ссылки на внутренние пакеты и их API

---

9. Provider fallback с адаптацией промпта

Сейчас: Слабая модель получает тот же промпт, что и сильная.

Решение: При fallback на gpt-4o-mini или haiku — промпт автоматически сокращается. Убираются: расширенные примеры, развёрнутые инструкции, секция скиллов.

Можно хранить «ранг» промпта (light / full) и выбирать под модель.

---

10. Мониторинг качества

Добавить метрики по каждому AI-вызову:

• Количество невалидных JSON
• Количество fallback'ов парсинга
• Количество отказов валидации
• Token usage
• Provider fallback chain

Хотя бы логи в структурированном виде, чтобы можно было понять, где что ломается, и чинить промпты точечно.

---

Порядок реализации

Шаг	Что делаем	Сложность
1	analyze_issue.go + TaskInstruction (детекция + паспорт)	Средняя
2	task_type "github" в classify.go + prompts/boss.go	Маленькая
3	Клонирование до thinkAboutTask для github-задач	Средняя
4	Ветки для воркеров в Group Chat	Большая
5	Draft PR до старта	Средняя
6	Гайды — переписать на конкретные шаблоны	Средняя
7	Обход пайплайна для тривиальных issue	Маленькая
8	Watch PR feedback	Средняя
9	Provider fallback с адаптацией	Маленькая
10	Мониторинг качества	Маленькая