Комплекс инженерного синтеза «Прогресс»

«Прогресс» — проект автономного инженерно-вычислительного комплекса для обработки внешних событий, структурного анализа, принятия решений, инструментального исполнения и верификации результатов.

Назначение

Комплекс предназначен для координации вычислительных контуров, обеспечивающих выполнение инженерных задач в управляемой конфигурации. В составе комплекса языковые модели, интеграционные модули и исполнительные подсистемы рассматриваются как элементы единой вычислительной среды.

Ключевые идеи

Комплекс развивается вокруг цикла разработки в компаниях: задача должна проходить через воспроизводимый маршрут, который можно гибко настроить. Например: постановка, исполнение, запрос на слияние, ревизия, доработка и завершение.

Основные принципы:

• задача является базовым объектом обработки;
• рабочий цикл должен быть предсказуемым и проверяемым;
• языковая модель выполняет содержательный синтез внутри заданных границ, но не владеет всем маршрутом процесса;
• контекст подбирается по задаче, стадии, модели и исполнительному профилю;
• внешние действия выполняются управляющими контурами после проверки структурированного результата;
• каждый шаг должен поддерживать ручной запуск, dry-run, объяснение выбора и запись запуска;
• разные модели и исполнительные модули выбираются по стоимости, качеству и классу задачи;
• автоматизация должна сосуществовать с инженерами и постепенно расширять охват рабочего цикла.

Подробное изложение причин и целевой модели работы приведено в документах docs/MOTIVATION.md, docs/OPERATING_MODEL.md и docs/DEVELOPMENT_MODEL.md.

Архитектурная схема

Базовая схема комплекса включает четыре ключевых контура:

• контур реакции на внешние события;
• контур интеграции с внешними системами;
• контур принятия решения;
• контур исполнения.

Внешний сигнал поступает в комплекс, проходит нормализацию и передаётся в контур принятия решения. Для согласования дальнейших действий используются данные интеграционных подсистем, оперативный контекст и проектное состояние. На первом прикладном треке контур должен уметь принять номер задачи, запустить кодирование, провести задачу через запрос на слияние и ревизию, вернуть замечания на доработку и довести цикл до слияния.

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

Предполагаемые подсистемы

• подсистема опроса внешних систем и приёма сигналов;
• интеграционные модули поиска и получения данных;
• подсистема оперативного контекста;
• подсистема проектного состояния;
• координатор контуров;
• подсистема исполнения;
• подсистема верификации;
• подсистема конфигурации и журналирования;
• контекстный архив.

Общий CLI

Комплекс имеет общий CLI, который выполняет две роли:

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

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

В сквозном виде CLI должен поддерживать:

• dry-run для режима, в котором внешние побочные действия не выполняются;
• --explain для вывода оснований, по которым были выбраны маршрут, профиль, ограничения и отдельные параметры;
• обязательное журналирование факта запуска каждого контура и модуля с их ключевыми параметрами.

Пример CLI-вызова

progress decision start --task 123

Примерный режим вызова: запуск контура принятия решения по номеру задачи.

С чего начать

Раздел будет подготовлен позже.

Текущий статус

Проект находится на стадии первичного архитектурного оформления и начального прикладного проектирования. Ближайший практический приоритет состоит в фиксации рабочего цикла по задаче разработки: запуск по номеру задачи, кодирование, запрос на слияние, ревизия, доработка, повторная ревизия и слияние.

Документация

• CONCEPT.md — общая концепция комплекса;
• docs/MOTIVATION.md — мотивация комплекса, причины существования и ключевые идеи;
• docs/TARGET_ARCHITECTURE.md — целевое общее описание архитектуры, канонической задачи, маршрутов и контуров;
• docs/OPERATING_MODEL.md — модель работы комплекса на уровне прикладного цикла разработки;
• docs/DEVELOPMENT_MODEL.md — модель развития комплекса, вложенных рабочих циклов, профилей и исполнительных модулей;
• docs/UI_CONCEPT.md — первичный концепт интерфейса наблюдения и навигационного модуля;
• STYLE.md — точка входа в стилистический регламент;
• docs/styleguide/ — канонические документы по языку проекта, словарю терминов и таблицам соответствия между кодом и документацией;
• AGENTS.md — обязательные инструкции для агентских контуров;
• docs/styleguide/agent-workflows.md — прикладные правила подготовки агентских текстов, коммитов, запросов на слияние и ревизионных материалов;
• docs/public-contract-checklist.md — единый чеклист изменения публичного контракта;
• docs/operations-guide-template.md — короткий шаблон эксплуатационного руководства для новой возможности;
• docs/ARCHITECTURE.md — целевая архитектурная схема;
• docs/contours/CONTRACTS.md — проверяемая карта межконтурных контрактов;
• docs/contours/reactivity/README.md — контур реакции на внешние события;
• docs/contours/reactivity/TARGET_ARCHITECTURE.md — целевое архитектурное состояние контура реакции на внешние события;
• docs/contours/integration/README.md — контур интеграции с внешними системами;
• docs/contours/integration/TARGET_ARCHITECTURE.md — целевое архитектурное состояние контура интеграции;
• docs/contours/decision/README.md — контур принятия решения;
• docs/contours/decision/TARGET_ARCHITECTURE.md — целевое архитектурное состояние контура принятия решения;
• docs/contours/decision/PLAN.md — прикладной план развития контура решения по циклу задачи;
• docs/contours/execution/README.md — контур исполнения;
• docs/contours/execution/TARGET_ARCHITECTURE.md — целевое архитектурное состояние контура исполнения;
• docs/contours/execution/STRUCTURED_IO.md — структурированный ввод и вывод контура исполнения;
• docs/contours/execution/CLI.md — изолированный и полный запуск исполнительного контура;
• docs/contours/methodology/README.md — контур методик;
• docs/contours/methodology/CLI.md — управление каталогом методик через CLI;
• docs/contours/settings-resources/README.md — контур настроек и ресурсов;
• docs/contours/observability/README.md — контур журналирования и наблюдаемости;
• docs/contours/user-interface/README.md — контур пользовательского интерфейса;
• docs/contours/authorization/README.md — контур авторизации;
• docs/contours/execution-queue/README.md — очередь исполнения задач;
• docs/contours/analytics/README.md — контур аналитики и статистики;
• docs/contours/task-bank/README.md — банк задач;
• docs/contours/research/README.md — контур исследований;
• docs/PLAN.md — поэтапный план архитектурного развития.

Принципы терминологии

Документация проекта использует язык системной инженерии, автоматизированных контуров управления и вычислительных комплексов.

Принятые ориентиры:

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

Проект сознательно не описывается как чат, бот, copilot или потребительское AI-приложение. Его предметная форма — автономный комплекс инженерного синтеза.

Документы docs/styleguide/ являются обязательным нормативным источником для ручной документации и для текстов, формируемых агентскими и исполнительными контурами. Если термин закреплён в словаре регламента, в документации и рабочих артефактах используется именно это наименование.