Цель

Сделать следующий уровень совместной работы с ИИ: пользователь формулирует рабочую цель на естественном языке, например:

«Разберись, почему проект X не работает»

После этого агент самостоятельно проходит путь от поиска проекта и сбора контекста до проверки гипотез и фиксации результата в fi1osof.ru.

Целевой сценарий

Пример желаемого workflow:

1. Найти проект по имени или ID.
2. Получить его текущий контекст.
3. Прочитать связанные задачи.
4. Прочитать последние worklog'и.
5. Посмотреть последние события/изменения по проекту.
6. Проверить доступность сайта/API/сервисов, если это применимо.
7. Получить данные о последних деплоях, ошибках, логах и состоянии окружений.
8. Сформулировать несколько гипотез причины проблемы.
9. Проверить те гипотезы, которые можно проверить доступными инструментами.
10. Создать новую задачу или обновить существующую.
11. Записать в задачу результат расследования, доказательства, ссылки и следующие действия.

Условно:

найти проект
→ собрать последние изменения
→ посмотреть открытые задачи
→ прочитать последние worklog'и
→ проверить доступность сайта/API
→ посмотреть ошибки и деплои
→ сформулировать гипотезы
→ проверить доступные гипотезы
→ создать/обновить задачу
→ записать результат расследования

Что уже есть

В GraphQL API уже доступны базовые сущности, необходимые для начала такого процесса:

• проекты;
• задачи;
• task worklogs;
• skills;
• timers/activity;
• executeSkill;
• readWebPage;
• другие GraphQL query/mutation.

Это уже позволяет реализовать часть агентного контура без отдельной внешней оркестрации.

Чего не хватает

1. Стандартизированный технический контекст проекта

Нужно иметь возможность однозначно получить связанные с проектом технические источники:

• репозитории;
• сервисы;
• production/staging/dev окружения;
• публичные и внутренние URL;
• API endpoints;
• deployments;
• CI/CD runs;
• логи;
• ошибки;
• мониторинг;
• конфигурацию;
• документацию.

Без этого агент может хорошо анализировать задачи и историю работы, но не всегда способен установить техническую причину инцидента.

2. Явные связи между сущностями

Желательно иметь машиночитаемый граф связей, например:

Project
├─ Repository
├─ Service
│  ├─ Environment
│  ├─ Endpoint
│  ├─ Deployment
│  └─ LogSource
├─ Task
│  └─ TaskWorkLog
└─ Documentation

Важно, чтобы агент не определял принадлежность объектов только по похожим названиям.

3. Activity feed / история изменений

Нужен единый способ ответить на вопрос:

«Что изменилось непосредственно перед тем, как возникла проблема?»

Полезные события:

• изменение задачи;
• новый worklog;
• deployment;
• commit/release;
• изменение конфигурации;
• падение health-check;
• новая ошибка;
• изменение DNS/SSL;
• restart сервиса;
• действия пользователя/агента, влияющие на проект.

Желательно иметь единый query последних событий проекта с фильтрацией по времени и типу.

4. Безопасные инструменты проверки гипотез

Агенту нужны read-only или контролируемые диагностические действия, например:

• HTTP health-check;
• чтение web-страницы;
• проверка API endpoint;
• получение HTTP status/headers/body fragment;
• DNS lookup;
• SSL certificate check;
• чтение логов;
• проверка статуса сервиса;
• чтение последних deployment'ов;
• запуск теста;
• выполнение диагностического skill.

Часть этого может быть построена поверх существующих readWebPage и executeSkill.

5. Политика автономности

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

Можно без дополнительного подтверждения

• читать данные;
• искать проект и связанные сущности;
• выполнять read-only диагностику;
• формулировать гипотезы;
• читать логи и monitoring;
• создавать диагностический worklog;
• создавать обычную задачу, если это является естественным результатом расследования;
• дополнять задачу результатами диагностики.

Только по явной команде пользователя

• production deploy;
• restart production-сервисов;
• изменение production-конфигурации;
• удаление данных;
• массовые изменения;
• финансовые операции;
• административные действия;
• изменение прав доступа;
• любые другие потенциально разрушительные операции.

Skills высокого уровня

Нужны не только низкоуровневые skills вида «получи список задач», но и процедуры уровня рабочей цели.

Возможные skills:

• investigate_project
• check_project_health
• analyze_recent_failures
• summarize_project_state
• investigate_incident
• analyze_recent_changes

Например, investigate_project может задавать воспроизводимую процедуру:

resolve project
→ collect context
→ collect recent activity
→ inspect tasks/worklogs
→ run health checks
→ inspect deployments/errors/logs
→ produce hypotheses
→ test hypotheses
→ persist findings

Skill должен описывать не конкретный ответ, а алгоритм расследования, правила безопасности и формат фиксации результата.

Формат результата расследования

Результат желательно сохранять в Task.content или worklog в Markdown.

Пример структуры:

# Результат расследования

## Симптом
...

## Что проверено
- ...
- ...

## Наблюдения
- ...

## Гипотезы
1. ...
2. ...

## Подтверждённая причина
...

## Доказательства
- [лог / URL / deployment / commit](...)

## Что сделано
- ...

## Следующие действия
- [ ] ...
- [ ] ...

Важный принцип хранения задач

Для задач в fi1osof.ru соблюдать разделение:

• description — короткое описание сути задачи, буквально несколько предложений;
• content — вся основная постановка, детали, Markdown, ссылки, чеклисты, примеры, технический контекст и результаты анализа.

Не использовать description как основное длинное поле задачи.

Первый практический этап

Перед реализацией полного workflow провести аудит текущей GraphQL-схемы и доступных skills:

1. Определить, какие из перечисленных источников данных уже существуют.
2. Проверить существующие связи между Project, Task, TaskWorkLog, skills и другими сущностями.
3. Найти доступные операции для диагностики web/API.
4. Определить, есть ли уже модели deployments, logs, environments, repositories, events/activity.
5. Составить gap analysis: что уже можно сделать сейчас / чего не хватает в API / чего не хватает в skills.
6. На основе этого спроектировать минимальный investigate_project workflow.

Критерий готовности

Задачу можно считать реализованной, когда команда вида:

«Разберись, почему haih.net сегодня не работает»

может быть обработана агентом как рабочая цель, а не как серия ручных GraphQL-команд, и в результате агент:

• самостоятельно собирает релевантный контекст;
• показывает, что именно проверил;
• различает факты и гипотезы;
• проверяет доступные гипотезы;
• не выполняет опасных действий без разрешения;
• сохраняет итог расследования в fi1osof.ru.