Этот Репозиторий AI Software Factory описывает путь от миссии продукта и задачи до запроса на слияние, созданного Archon. Установка и проверки процессов — только начало. В руководстве на первый час сопровождающий пишет, что реальная сквозная проверка ещё предстоит. Этот материал следует коммиту фабрики 9e2d85298b45497031009597a6ae0811b66fe6d6 и закреплённой ревизии Archon fad09169ea1b43512bc7ee88470d47f960a3e0f8. Он основан на чтении документации и кода, а не на установке или запуске BIG CHANGE.

Процесс предназначен команде, контролирующей репозиторий приложения или PRD, разрешения GitHub и учётную запись поставщика моделей. Сопровождающий прямо описывает клонирование и установку фабрики в собственный репозиторий. В дереве закреплённой фабрики нет файла лицензии или уведомлений; это руководство не устанавливает более широких прав на повторное использование или распространение. MIT-лицензия Archon относится к отдельному исходному коду Archon. Не помещайте секреты поставщика в задачи, запросы, журналы и записи проверки.

Большая перемена

  • Что изменилось: Реализация связывает объём продукта, планирование задач, программирование, независимую проверку и контроль выполнения через закреплённый пакет процессов Archon. Фабрика даёт входы проекта и запускатель; общий пакет содержит шаги ИИ.
  • Почему это важно: Команда может проследить предложение от задачи до конкретных изменений, результата CI и работающего кандидата до решения о слиянии. Одни проверки установки оставляют эту цепочку неполной; сопровождающий говорит, что реальную интеграцию ещё нужно проверить.
  • За чем следить: Первое полезное доказательство — реальная задача, чья поставленная ревизия проходит содержательные пользовательские сценарии и независимые отложенные проверки, с видимыми команде затратами и записью проверки. Расписание и развёртывание остаются отдельными последующими решениями.

1. Проверьте репозиторий, разрешения и закреплённый источник

Документ Инструкция сопровождающего требует Git, Python 3.10 или новее, gh с авторизацией в области workflow, удалённый репозиторий GitHub, агента программирования, Bun и uv. Git также должен уметь отправлять файлы процессов (gh auth setup-git). Перед запуском агента проверьте существующие команды тестирования, запуска и CI, защиту ветвей, доступ GitHub, авторизацию поставщика и оплату моделей. Выдавайте только необходимые права на репозиторий и процессы.

Клонируйте фабрику вне репозитория приложения и переключитесь на указанный коммит. Документированная установка выполняется из корня приложения:

Terminal
git clone https://github.com/coleam00/ai-software-factory ~/ai-software-factory
git -C ~/ai-software-factory checkout 9e2d85298b45497031009597a6ae0811b66fe6d6
python ~/ai-software-factory/bin/factory.py init

При необходимости используйте python3. Установщик копирует шаблоны фабрики и проекта и устанавливает исходный код Archon, указанный в pack.json. README и пакет этого коммита оба указывают fad09169ea1b43512bc7ee88470d47f960a3e0f8. Установщик не авторизует поставщика, не выбирает уровни моделей и не включает расписание. Прежде чем принять изменения в репозитории, просмотрите изменённые файлы.

Настройте выбранного поставщика и поддерживаемые идентификаторы моделей по установленному руководству Archon. Укажите реальные команды статического анализа и модульных тестов в harness/harness.config.json. Если GitHub не сообщает защиту ветвей, перечислите необходимые для слияния задания CI в required_checks. Проверьте protected_paths, чтобы изменения миссии, проверочной среды и политики фабрики требовали человека. В шаблоне обычные команды проверки и required_checks пусты: одно копирование не создаёт пригодный барьер приёмки.

2. Опишите миссию и проверки существующего продукта

Запишите в MISSION.md назначение продукта, жёсткие ограничения и правдоподобные запросы вне объёма работ. В harness/END-TO-END.md опишите от двух до пяти сценариев, которые приложение уже выполняет, включая видимую пользователю пользу. Сценарий с ещё не созданной функцией заблокировал бы первую поставку. В .factory/holdout/HOLDOUT.md запишите отдельные случаи, объединяющие поведения или проверяющие границы. Название каталога не скрывает их от разработчика с доступом к той же рабочей копии; действительно закрытые случаи храните вне неё и передавайте только проверяющей стороне.

Для репозитория только с PRD README требует извлечь из документа миссию, планируемые сценарии и проверочные команды. Первая предложенная задача должна сделать продукт запускаемым и указать команду запуска, пути проверки состояния и идентичности сборки, тесты и CI. Проверьте предложение до разрешения публиковать задачи.

Преобразуйте пользовательские сценарии во входные данные, ожидаемые процессами выполнения Archon. Следуйте установленному factory/RUNTIME_HOST.md: снимок приложения из поставленного коммита, чистое состояние, проверки состояния и идентичности сборки, допустимые команды Python или Node. Документированный хост не управляет удалёнными базами данных, контейнерами или облачными ресурсами как собственными ресурсами выполнения. Для приложения с ними нужна отдельно обоснованная схема проверки; успешная локальная проверка не доказывает их изоляцию.

Прежде чем доверять оценщику, получите успешный эталонный результат на реальной пользовательской ценности, покажите, что подходящая намеренная ошибка приводит к провалу, и убедитесь, что неверная идентичность кандидата даёт неопределённый вердикт. Руководство хоста указывает входы набора и точные поля, включая expectations_passed: true и baseline_verified: true. Сохраните фактический исходный ответ и идентичность кандидата как доказательства. Проверка только загрузки страницы или тест, напрямую создающий конечное состояние, слишком слабы.

3. Проверьте установку и выберите одну задачу

Выполните из корня приложения:

Terminal
python factory/consumer.py doctor
python factory/consumer.py list

doctor проверяет закреплённый источник, возможности команд и доступные процессы. list показывает найденные процессы. Ни одна команда не доказывает, что поставщик завершит задачу, CI пройдёт или приложение запустится. Исправьте сообщённые ошибки до поставки; расписание оставьте выключенным.

Для существующей кодовой базы напишите небольшую задачу с ясным результатом и критериями приёмки. README документирует эту команду для разбора, поставки и проверки до запроса на слияние:

Terminal
python factory/consumer.py run archon-ship --input target=https://github.com/OWNER/REPO/issues/1 --input discovery_publication=preview --detach --json

Замените URL задачей под вашим контролем. Явное discovery_publication=preview не публикует сопутствующие находки проверки как задачи; иначе закреплённый процесс archon-ship использует auto. Применяйте archon-lifecycle только с готовыми входами сценария выполнения и отложенных контрольных случаев. Передайте задачу как target, пути как scenario и holdout, а также merge_mode=approve и discovery_publication=preview. Укажите одобренный проектом merge_method: merge, squash или rebase. Например, merge_method=squash допустим только при разрешении репозитория. Процесс включает выполнение, отложенные проверки, исправление и контроль слияния. Режим одобрения сохраняет решение человека перед слиянием; отметка готовности процесса этим решением не является. Документированная опция хоста фабрики --runtime-host работает только на переднем плане и несовместима с --detach и --resume.

Для PRD документирована команда подготовки очереди задач:

Terminal
python factory/consumer.py run archon-backlog --input 'prd=docs/PRD.md' --input publication=approve

Замените заключённый в кавычки docs/PRD.md фактическим путём PRD относительно рабочей копии приложения. Проверьте предлагаемый порядок задач до публикации. Настройте хост выполнения по запуску приложения и контракту идентичности, указанным в первой задаче, затем проведите её через archon-lifecycle с подготовленными сценариями и отложенными проверками. Первую задачу проверяйте столь же тщательно, как последующие.

4. Оцените изменения и работающий результат до одобрения

Сохраните возвращённый идентификатор запуска. Управляющая программа предоставляет get <run-id> --json --events и status --all --json для прогресса и доказательств. Сопоставьте задачу и план с MISSION.md; прочитайте фактические изменения запроса и независимую проверку текущей ревизии; проверьте обязательные результаты CI и отчёт защищённых путей. Выполните пользовательские сценарии на поставленной ревизии и просмотрите исходные результаты выполнения и отложенных проверок, включая идентичность кандидата. Сравните наблюдаемый результат пользователя с критериями приёмки. Недостаточный запрос следует вернуть на исправление; README описывает archon-deliver --adopt <run id> для поставки, удерживаемой очередью слияния.

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

Документ Указания сопровождающего о стоимости не дают фиксированной цены запуска. Они советуют считать токены с первого дня и наблюдать вызовы моделей на небольшой задаче перед включением цикла. Плата зависит от поставщика, моделей и условий учётной записи. BIG CHANGE не измеряла расходы этой фабрики.

Активному запуску нужно и явное решение об остановке. В коде управляющей программы команда halt блокирует новые запуски и продолжения, а cancel <run-id> обращён к активной работе. pause останавливает запуски таймера, но допускает пробуждения уже выполняемой работы. Ни одна команда не заменяет проверку текущего состояния запуска и изменений удалённого репозитория.

Источники и дополнительное чтение