architect/_archive/2025-11-26-cleanup/cifra/archive/2025-11-10-restructure-v2/TECHNICAL_TOOLS.md

Технические средства платформы ЦИФРА

Версия: 1.0.0
Дата: 2025-11-10
Статус: Анализ инструментов


🎯 ЧТО НАМ НУЖНО УПРАВЛЯТЬ

1. ДОКУМЕНТЫ
   - Спецификации (DESIGN.md)
   - Документация проектов (PROJECT.md, ROADMAP.md)
   - Код агентов (Python файлы)
   - Конфигурация (YAML, JSON)

2. ПРОЕКТЫ
   - Создание из шаблонов
   - Жизненный цикл (active  archived)
   - Связи между компонентами
   - Метаданные (версия, дата, автор)

3. АГЕНТЫ
   - Регистрация агентов
   - Вызов агентов (Task очередь)
   - Состояние агентов (контекст)
   - Координация между агентами
   - Логирование действий

4. ЗНАНИЯ (Knowledge Base)
   - Templates библиотека
   - Components каталог
   - История решений (Git)
   - Метрики и аналитика

🛠️ ТЕХНИЧЕСКИЕ СРЕДСТВА ПО КАТЕГОРИЯМ


1️⃣ УПРАВЛЕНИЕ ДОКУМЕНТАМИ

1.1. Формат документов

Текущее решение: Markdown (.md)

Плюсы:
- ✅ Читаемость (человек и машина)
- ✅ Git friendly (text diff работает)
- ✅ Простота (не нужен парсер)
- ✅ Универсальность (GitHub, VS Code поддерживают)

Альтернативы:
- reStructuredText (сложнее)
- AsciiDoc (избыточно)
- LaTeX (для научных документов, не наш случай)

Решение: ✅ Остаёмся на Markdown


1.2. Шаблонизация документов

Проблема: Нужно генерировать DESIGN.md, PROJECT.md с переменными.

Варианты:

A. Jinja2 (шаблонизатор Python)

pip install jinja2

# Шаблон
template = """
# {{ project_name }} — Спецификация

**Версия:** {{ version }}
**Дата:** {{ date }}

## Описание
{{ description }}
"""

# Использование
from jinja2 import Template
tmpl = Template(template)
result = tmpl.render(
    project_name="DocumentAgent",
    version="1.0.0",
    date="2025-11-10",
    description="Агент документации"
)

Плюсы:
- ✅ Мощный (циклы, условия)
- ✅ Широко используется
- ✅ Поддержка наследования шаблонов

Минусы:
- ⚠️ Нужна установка библиотеки

B. f-strings Python (встроенные)

# Простые случаи
doc = f"""
# {project_name} — Спецификация
**Версия:** {version}
"""

Плюсы:
- ✅ Встроено в Python
- ✅ Просто для базовых случаев

Минусы:
- ⚠️ Нет логики (циклов, условий)
- ⚠️ Сложно для больших шаблонов

C. Python string.Template (встроенный)

from string import Template

tmpl = Template("# $project_name — Спецификация")
result = tmpl.substitute(project_name="DocumentAgent")

Плюсы:
- ✅ Встроено
- ✅ Безопаснее f-strings

Минусы:
- ⚠️ Очень ограниченный функционал

Рекомендация:
- Фаза 0-1: f-strings (простота)
- Фаза 2+: Jinja2 (когда шаблоны усложнятся)


1.3. Парсинг документов

Проблема: Нужно читать существующие DESIGN.md, извлекать структуру.

Варианты:

A. Python-Markdown

pip install markdown

import markdown
md = markdown.Markdown()
html = md.convert("# Header\n\nText")
# Результат: HTML

Плюсы:
- ✅ Конвертация Markdown → HTML
- ✅ Расширяемость

Минусы:
- ⚠️ Нам не нужен HTML, нужна структура

B. mistune (быстрый парсер)

pip install mistune

import mistune
ast = mistune.create_markdown(renderer=None)
tree = ast("# Header\n\nText")
# Результат: AST (Abstract Syntax Tree)

Плюсы:
- ✅ Быстрый
- ✅ Возвращает AST (можно обрабатывать)

Минусы:
- ⚠️ API сложноват

C. Регулярные выражения (простое извлечение)

import re

# Извлечь заголовки
headers = re.findall(r'^#+\s+(.+)$', markdown_text, re.MULTILINE)

# Извлечь метаданные
version = re.search(r'\*\*Версия:\*\*\s+(.+)', markdown_text)

Плюсы:
- ✅ Встроено в Python
- ✅ Достаточно для простых случаев

Минусы:
- ⚠️ Не подходит для сложной структуры

Рекомендация:
- Фаза 0-1: Регулярные выражения (для метаданных)
- Фаза 2+: mistune (если нужен полный парсинг)


1.4. Валидация документов

Проблема: Проверить что DESIGN.md содержит все обязательные разделы.

Варианты:

A. JSON Schema (для YAML frontmatter)

pip install jsonschema

schema = {
    "type": "object",
    "properties": {
        "version": {"type": "string"},
        "status": {"enum": ["draft", "approved"]}
    },
    "required": ["version", "status"]
}

from jsonschema import validate
validate(instance=data, schema=schema)

Плюсы:
- ✅ Строгая валидация
- ✅ Стандарт

Минусы:
- ⚠️ Только для YAML/JSON, не для Markdown

B. Pydantic (Python модели)

pip install pydantic

from pydantic import BaseModel
from datetime import datetime

class DesignSpec(BaseModel):
    version: str
    date: datetime
    status: str

# Валидация
spec = DesignSpec(
    version="1.0.0",
    date="2025-11-10",
    status="draft"
)

Плюсы:
- ✅ Type safety
- ✅ Автоматическая конвертация типов
- ✅ Хорошие сообщения об ошибках

Минусы:
- ⚠️ Нужна библиотека

C. Простые проверки (Python)

def validate_design_md(content):
    required_sections = [
        "# ОПРЕДЕЛЕНИЕ",
        "# КОНТЕКСТ",
        "# АНАЛИЗ"
    ]

    for section in required_sections:
        if section not in content:
            raise ValueError(f"Missing section: {section}")

    return True

Плюсы:
- ✅ Просто
- ✅ Контроль

Минусы:
- ⚠️ Хрупкое (зависит от форматирования)

Рекомендация:
- Фаза 0-1: Простые проверки
- Фаза 2+: Pydantic (если нужна строгая типизация)


2️⃣ УПРАВЛЕНИЕ ПРОЕКТАМИ

2.1. Создание из шаблонов

Проблема: Скопировать структуру из templates/ в projects/, заменить переменные.

Варианты:

A. shutil + os (встроенные Python)

import shutil
import os

# Копирование директории
shutil.copytree(
    'templates/streamlit-mvp-v1/structure',
    'projects/myapp'
)

# Замена переменных в файлах
for root, dirs, files in os.walk('projects/myapp'):
    for file in files:
        if file.endswith('.md') or file.endswith('.py'):
            path = os.path.join(root, file)
            with open(path, 'r') as f:
                content = f.read()

            # Замена
            content = content.replace('{{PROJECT_NAME}}', 'myapp')

            with open(path, 'w') as f:
                f.write(content)

Плюсы:
- ✅ Встроено в Python
- ✅ Простота

Минусы:
- ⚠️ Ручная обработка каждого файла
- ⚠️ Нет продвинутой логики

B. cookiecutter (генератор проектов)

pip install cookiecutter

# Структура шаблона с {{cookiecutter.project_name}}
cookiecutter templates/streamlit-mvp-v1/
# Интерактивно спрашивает переменные

Плюсы:
- ✅ Популярный инструмент
- ✅ Поддержка Jinja2
- ✅ Hooks (pre/post генерации)

Минусы:
- ⚠️ Интерактивный (не для автоматизации)
- ⚠️ Нужна библиотека

C. Свой ProjectGenerator класс

class ProjectGenerator:
    def __init__(self, workspace):
        self.workspace = workspace

    def create_from_template(self, template_name, project_name, variables):
        template_path = f"{self.workspace}/templates/{template_name}"
        project_path = f"{self.workspace}/projects/{project_name}"

        # Копирование
        shutil.copytree(template_path, project_path)

        # Замена переменных через Jinja2
        self._replace_variables(project_path, variables)

        return project_path

Плюсы:
- ✅ Полный контроль
- ✅ Гибкость
- ✅ Интеграция с агентами

Минусы:
- ⚠️ Нужно писать сами

Рекомендация: ✅ Свой ProjectGenerator (максимальный контроль)


2.2. Метаданные проектов

Проблема: Хранить метаданные (версия, дата создания, статус, шаблон).

Варианты:

A. YAML frontmatter (в PROJECT.md)

---
version: 1.0.0
created_at: 2025-11-10
template: streamlit-mvp-v1
status: active
---

# Проект Marketplace

Описание...

Библиотека: python-frontmatter

pip install python-frontmatter

import frontmatter

# Чтение
with open('PROJECT.md') as f:
    post = frontmatter.load(f)

print(post['version'])  # 1.0.0
print(post.content)     # Markdown без frontmatter

Плюсы:
- ✅ Всё в одном файле
- ✅ Git friendly
- ✅ Читаемо

Минусы:
- ⚠️ Нужна библиотека

B. Отдельный project.yaml

# projects/marketplace/project.yaml
name: marketplace
version: 1.0.0
created_at: 2025-11-10
template: streamlit-mvp-v1
status: active

Плюсы:
- ✅ Просто парсить (PyYAML)
- ✅ Можно расширять

Минусы:
- ⚠️ Отдельный файл (может рассинхронизироваться)

C. SQLite база

import sqlite3

conn = sqlite3.connect('platform/.claude/projects.db')

CREATE TABLE projects (
    name TEXT PRIMARY KEY,
    version TEXT,
    created_at TIMESTAMP,
    template TEXT,
    status TEXT
)

Плюсы:
- ✅ Запросы (SQL)
- ✅ Индексы (быстро)
- ✅ Транзакции

Минусы:
- ⚠️ Не Git friendly
- ⚠️ Отдельное хранилище (риск рассинхронизации)

Рекомендация:
- Фаза 0-2: YAML frontmatter (простота + Git)
- Фаза 3+: SQLite (если нужны сложные запросы)


2.3. Жизненный цикл проектов

Проблема: Управление статусами (active → archived → deprecated).

Варианты:

A. Статус в метаданных (YAML)

status: active  # active | archived | deprecated

B. Директории по статусам

projects/
├── active/
│   └── marketplace/
├── archived/
│   └── old-project/
└── deprecated/
    └── legacy-app/

Плюсы:
- ✅ Визуальная ясность
- ✅ Просто перемещать

Минусы:
- ⚠️ Git history теряется при перемещении

C. State Machine (Python)

from transitions import Machine

class Project:
    states = ['draft', 'active', 'archived', 'deprecated']

    transitions = [
        {'trigger': 'activate', 'source': 'draft', 'dest': 'active'},
        {'trigger': 'archive', 'source': 'active', 'dest': 'archived'},
        {'trigger': 'deprecate', 'source': '*', 'dest': 'deprecated'},
    ]

Плюсы:
- ✅ Контроль переходов
- ✅ Валидация

Минусы:
- ⚠️ Усложнение

Рекомендация: ✅ Статус в YAML (простота)


3️⃣ УПРАВЛЕНИЕ АГЕНТАМИ

3.1. Регистрация агентов

Проблема: Агенты должны регистрироваться в системе.

Варианты:

A. AgentAPI (реестр в памяти)

class AgentAPI:
    def __init__(self):
        self.agents = {}  # name -> agent_instance

    def register_agent(self, agent):
        self.agents[agent.name] = agent
        print(f"✅ Registered: {agent.name}")

    def call_agent(self, name, task):
        return self.agents[name].execute(task)

Плюсы:
- ✅ Простота
- ✅ Быстро

Минусы:
- ⚠️ Только в памяти (не персистентно)
- ⚠️ При перезапуске теряется

B. Конфигурационный файл (agents.yaml)

# platform/config/agents.yaml
agents:
  DocumentAgent:
    enabled: true
    module: platform.agents.document_agent
    class: DocumentAgent

  CodeAgent:
    enabled: true
    module: platform.agents.code_agent
    class: CodeAgent

Динамическая загрузка:

import importlib

def load_agents_from_config():
    with open('platform/config/agents.yaml') as f:
        config = yaml.safe_load(f)

    agents = {}
    for name, cfg in config['agents'].items():
        if cfg['enabled']:
            module = importlib.import_module(cfg['module'])
            agent_class = getattr(module, cfg['class'])
            agents[name] = agent_class(workspace)

    return agents

Плюсы:
- ✅ Конфигурация вне кода
- ✅ Легко включать/выключать агентов
- ✅ Персистентность

Минусы:
- ⚠️ Сложнее

Рекомендация: ✅ Конфигурационный файл (гибкость)


3.2. Координация агентов

Проблема: CentralAgent вызывает других агентов, нужна очередь задач.

Варианты:

A. Синхронные вызовы (простые)

# CentralAgent
result1 = api.call_agent("DocumentAgent", task1)
result2 = api.call_agent("CodeAgent", task2)
result3 = api.call_agent("GitAgent", task3)

Плюсы:
- ✅ Просто
- ✅ Понятный поток

Минусы:
- ⚠️ Медленно (последовательное выполнение)
- ⚠️ Блокирующие вызовы

B. Асинхронные вызовы (asyncio)

import asyncio

async def workflow():
    task1 = api.call_agent_async("DocumentAgent", task1)
    task2 = api.call_agent_async("CodeAgent", task2)

    # Параллельное выполнение
    results = await asyncio.gather(task1, task2)

Плюсы:
- ✅ Быстрее (параллелизм)
- ✅ Эффективнее (I/O bound задачи)

Минусы:
- ⚠️ Сложнее код
- ⚠️ Отладка труднее

C. Task Queue (Celery / RQ)

# С Celery
from celery import Celery

app = Celery('cifra', broker='redis://localhost:6379')

@app.task
def run_agent(agent_name, task):
    return api.call_agent(agent_name, task)

# Использование
result = run_agent.delay("DocumentAgent", task)
result.get()  # Ждём результата

Плюсы:
- ✅ Распределённое выполнение
- ✅ Retry механизм
- ✅ Мониторинг (Flower)

Минусы:
- ⚠️ Нужен Redis/RabbitMQ
- ⚠️ Сложность инфраструктуры

Рекомендация:
- Фаза 0-2: Синхронные вызовы (простота)
- Фаза 3: asyncio (параллелизм)
- Фаза 4+: Celery (если нужно распределение)


3.3. Хранение состояния агентов

Проблема: Агенты имеют контекст (context: dict), нужно сохранять между вызовами.

Варианты:

A. В памяти (BaseAgent.context)

class BaseAgent:
    def __init__(self):
        self.context = {}  # В памяти

Плюсы:
- ✅ Быстро
- ✅ Просто

Минусы:
- ⚠️ Теряется при перезапуске

B. Файлы YAML

# platform/.claude/agents/DocumentAgent_context.yaml
last_project: marketplace
templates_used:
  - streamlit-mvp-v1
documents_created: 15

Плюсы:
- ✅ Персистентность
- ✅ Git friendly
- ✅ Читаемость

Минусы:
- ⚠️ Медленнее (I/O)

C. SQLite

CREATE TABLE agent_context (
    agent_name TEXT PRIMARY KEY,
    context JSON,
    updated_at TIMESTAMP
)

Плюсы:
- ✅ Быстрые запросы
- ✅ Транзакции

Минусы:
- ⚠️ Не Git friendly

Рекомендация: ✅ YAML файлы (персистентность + Git)


3.4. Логирование действий агентов

Проблема: Нужно видеть что делали агенты (для отладки и аналитики).

Варианты:

A. Python logging

import logging

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(name)s - %(levelname)s - %(message)s',
    handlers=[
        logging.FileHandler('platform/.claude/agents.log'),
        logging.StreamHandler()
    ]
)

logger = logging.getLogger('DocumentAgent')
logger.info("Created PROJECT.md for marketplace")

Плюсы:
- ✅ Встроено в Python
- ✅ Уровни (DEBUG, INFO, WARNING, ERROR)
- ✅ Форматирование

Минусы:
- ⚠️ Простой текст (сложно парсить)

B. Structured logging (structlog)

pip install structlog

import structlog

log = structlog.get_logger()
log.info(
    "document_created",
    agent="DocumentAgent",
    project="marketplace",
    file="PROJECT.md",
    duration=1.5
)

# Вывод: JSON
# {"event": "document_created", "agent": "DocumentAgent", ...}

Плюсы:
- ✅ Структурированные логи (JSON)
- ✅ Легко парсить и анализировать
- ✅ Интеграция с аналитикой

Минусы:
- ⚠️ Нужна библиотека

C. Session журналы (текущее решение)

# platform/.claude/session-2025-11-10.md

## 14:30 - DocumentAgent
- Создан PROJECT.md для marketplace
- Использован шаблон: streamlit-mvp-v1
- Время: 1.5s

Плюсы:
- ✅ Читаемо для человека
- ✅ Git friendly

Минусы:
- ⚠️ Сложно парсить программно

Рекомендация:
- Фаза 0-1: Python logging (встроено)
- Фаза 2+: structlog (для аналитики)


4️⃣ УПРАВЛЕНИЕ ЗНАНИЯМИ (Knowledge Base)

4.1. Индексация компонентов

Проблема: Cascade Search нужно быстро находить компоненты.

Варианты:

A. Файловый каталог (catalog.yaml)

# components/catalog.yaml
formatters:
  - name: format_price
    path: components/shared/lib/formatters.py
    description: "Форматирование цены в рубли"
    usage_count: 45
    tags: [formatting, price, currency]

validators:
  - name: validate_inn
    path: components/shared/lib/validators.py
    description: "Валидация ИНН"
    usage_count: 23
    tags: [validation, inn, business]

Поиск:

import yaml

with open('components/catalog.yaml') as f:
    catalog = yaml.safe_load(f)

# Поиск по тегам
results = [c for c in catalog['formatters'] if 'price' in c['tags']]

Плюсы:
- ✅ Просто
- ✅ Git friendly
- ✅ Читаемо

Минусы:
- ⚠️ Линейный поиск (медленно для 1000+ компонентов)

B. SQLite FTS (Full-Text Search)

CREATE VIRTUAL TABLE components_fts USING fts5(
    name,
    path,
    description,
    tags
);

-- Поиск
SELECT * FROM components_fts WHERE components_fts MATCH 'price';

Плюсы:
- ✅ Быстрый поиск
- ✅ Полнотекстовый поиск
- ✅ Ranked results

Минусы:
- ⚠️ Отдельная БД (не Git friendly)

C. Whoosh (Python полнотекстовый поиск)

pip install whoosh

from whoosh.index import create_in
from whoosh.fields import Schema, TEXT, ID

schema = Schema(
    name=ID(stored=True),
    path=TEXT(stored=True),
    description=TEXT,
    tags=TEXT
)

# Индексация
ix = create_in("indexdir", schema)
writer = ix.writer()
writer.add_document(
    name="format_price",
    path="components/shared/lib/formatters.py",
    description="Форматирование цены",
    tags="formatting price currency"
)
writer.commit()

# Поиск
from whoosh.qparser import QueryParser
with ix.searcher() as searcher:
    query = QueryParser("tags", ix.schema).parse("price")
    results = searcher.search(query)

Плюсы:
- ✅ Быстрый поиск
- ✅ Полнотекстовый
- ✅ Python native

Минусы:
- ⚠️ Нужна библиотека
- ⚠️ Индекс отдельно от Git

Рекомендация:
- Фаза 0-2: YAML catalog (простота)
- Фаза 3+: Whoosh (если компонентов >100)


Проблема: Cascade Search по ключевым словам не всегда находит релевантное.

Пример:
- Запрос: "нужно форматировать деньги"
- Существующий компонент: "format_price" (нет слова "деньги")
- Обычный поиск: НЕ НАЙДЁТ

Решение: Embeddings + Vector Search

Варианты:

A. OpenAI Embeddings + FAISS

pip install openai faiss-cpu

import openai
import faiss
import numpy as np

# 1. Создать embeddings для всех компонентов
descriptions = [
    "Форматирование цены в рубли",
    "Валидация ИНН",
    # ...
]

embeddings = []
for desc in descriptions:
    response = openai.Embedding.create(
        input=desc,
        model="text-embedding-ada-002"
    )
    embeddings.append(response['data'][0]['embedding'])

embeddings = np.array(embeddings)

# 2. Создать FAISS индекс
dimension = embeddings.shape[1]  # 1536 для ada-002
index = faiss.IndexFlatL2(dimension)
index.add(embeddings)

# 3. Поиск
query = "нужно форматировать деньги"
query_embedding = openai.Embedding.create(
    input=query,
    model="text-embedding-ada-002"
)['data'][0]['embedding']

distances, indices = index.search(
    np.array([query_embedding]),
    k=5  # топ-5 результатов
)

# indices[0] содержит индексы наиболее похожих компонентов

Плюсы:
- ✅ Находит семантически похожие (не только по ключевым словам)
- ✅ ОЧЕНЬ точно

Минусы:
- ⚠️ Стоимость (OpenAI Embeddings API)
- ⚠️ Нужна библиотека (FAISS)
- ⚠️ Сложность

B. Sentence Transformers (локальные embeddings)

pip install sentence-transformers

from sentence_transformers import SentenceTransformer
model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2')

# Embeddings
embeddings = model.encode(descriptions)

# Поиск (cosine similarity)
from sklearn.metrics.pairwise import cosine_similarity
query_embedding = model.encode(["нужно форматировать деньги"])
similarities = cosine_similarity(query_embedding, embeddings)

# Топ-5
top_indices = similarities[0].argsort()[-5:][::-1]

Плюсы:
- ✅ Локально (бесплатно)
- ✅ Быстро после загрузки модели

Минусы:
- ⚠️ Нужна библиотека + модель (~500MB)
- ⚠️ Менее точно чем OpenAI

Рекомендация:
- Фаза 0-3: Простой поиск (ключевые слова)
- Фаза 4+: Semantic Search (если компонентов >500)


4.3. Git как база знаний

Проблема: Git история — это знания (что было сделано, почему).

Инструменты:

A. GitPython (работа с Git из Python)

pip install gitpython

from git import Repo

repo = Repo('/opt/claude-workspace')

# История коммитов
commits = list(repo.iter_commits('master', max_count=100))
for commit in commits:
    print(f"{commit.hexsha[:7]} - {commit.message}")

# Поиск в истории
commits_with_agent = [
    c for c in commits
    if 'DocumentAgent' in c.message
]

# Diff между версиями
diff = repo.git.diff('HEAD~1', 'HEAD')

Плюсы:
- ✅ Полный доступ к Git из Python
- ✅ Анализ истории

Минусы:
- ⚠️ Нужна библиотека

B. git log через subprocess

import subprocess

# История
result = subprocess.run(
    ['git', 'log', '--oneline', '-10'],
    capture_output=True,
    text=True
)
print(result.stdout)

Плюсы:
- ✅ Встроено (subprocess)
- ✅ Просто

Минусы:
- ⚠️ Парсинг текста

Рекомендация: ✅ GitPython (удобнее для анализа)


📊 СВОДНАЯ ТАБЛИЦА РЕКОМЕНДАЦИЙ

Категория Задача Фаза 0-1 Фаза 2+ Фаза 3+
Документы Шаблонизация f-strings Jinja2 Jinja2
Парсинг regex mistune mistune
Валидация Простые проверки Pydantic Pydantic
Проекты Создание shutil ProjectGenerator ProjectGenerator
Метаданные YAML frontmatter YAML SQLite
Статусы YAML YAML State Machine
Агенты Регистрация AgentAPI (память) agents.yaml agents.yaml
Координация Синхронные вызовы asyncio Celery
Состояние В памяти YAML файлы YAML + SQLite
Логирование Python logging structlog structlog
Знания Индексация YAML catalog Whoosh Whoosh
Semantic Search - - Sentence Transformers
Git анализ subprocess GitPython GitPython

🎯 МИНИМАЛЬНЫЙ СТЕК (Фаза 0)

Что устанавливаем:

# Обязательно
pip install anthropic          # Claude API
pip install pyyaml             # Конфигурация

# Опционально (полезно)
pip install python-frontmatter # Метаданные в Markdown
pip install pytest             # Тестирование
pip install click              # CLI

Что НЕ нужно сразу:
- ❌ Jinja2 (пока f-strings)
- ❌ SQLite (пока YAML)
- ❌ Celery (пока синхронно)
- ❌ Whoosh (пока простой каталог)
- ❌ Semantic Search (рано)


🚀 ИТОГО

Что используем СЕЙЧАС (Фаза 0-1):

Документы:
  - Markdown
  - f-strings (шаблоны)
  - regex (парсинг метаданных)

Проекты:
  - shutil + os (копирование)
  - YAML frontmatter (метаданные)
  - Статус в YAML

Агенты:
  - AgentAPI (реестр в памяти)
  - agents.yaml (конфигурация)
  - Синхронные вызовы
  - Python logging
  - YAML (состояние агентов)

Знания:
  - YAML catalog
  - Git (через subprocess или GitPython)
  - Простой поиск (линейный)

Что добавим ПОТОМ (Фаза 2+):

Фаза 2:
  - Jinja2 (шаблоны)
  - Pydantic (валидация)
  - structlog (логирование)
  - GitPython (анализ истории)

Фаза 3:
  - asyncio (параллелизм)
  - Whoosh (полнотекстовый поиск)
  - SQLite (метрики)

Фаза 4:
  - Celery (распределённое выполнение)
  - Semantic Search (Sentence Transformers)
  - State Machine (сложные переходы)

❓ ВОПРОСЫ ДЛЯ ОБСУЖДЕНИЯ

Q1: Согласны с минимальным стеком (Фаза 0)?
- anthropic, pyyaml, python-frontmatter, pytest, click

Q2: Нужно ли сразу GitPython?
- Или пока через subprocess?

Q3: Semantic Search добавлять сразу?
- Или подождать пока компонентов наберётся?

Q4: Какие инструменты вы бы добавили?
- Что я упустил?

Q5: Начинаем с этим стеком?
- Или ещё что-то нужно обсудить?


Версия: 1.0.0
Дата: 2025-11-10
Статус: Готов к обсуждению