Files
wt ff99ee7b62 S00-028: Document and verify the compatible Codex runner invocation
Changes: Document the coordinator-selected Codex 0.159.0 argv without conflicting sandbox flags; record parser and filesystem evidence plus QA handoff. Preserve existing local configuration and portable example.
Validation: Exact active argv help and approved host wrapper with inner workspace-write probe exited 0; project write/read/remove passed and outside write denied EROFS30. Final make check passed 72 tests after shortening the documentation to meet prompt budgets. No additional model or storage work ran.

Task: S00-028
Agent: auto-ci-cd-e3a716a94424
Role: ci-cd
Action: claim
Status: review

Task title: Repair conflicting Codex harness sandbox arguments
2026-10-15 17:52:47 +07:00

116 lines
11 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Автоматический цикл агентов
## Однократная настройка
Скопировать `runner.example.json` в `runner.local.json` и заменить `argv` на команду своего **агентного CLI с доступом к файлам и инструментам**. Обычный текстовый вызов модели без execution harness не сможет выполнять задачи.
Команда запускается без shell из project root; полный новый prompt поступает в stdin UTF-8. Дополнительно доступны placeholders `{root}`, `{task}`, `{role}`, `{agent}`, `{action}`, `{prompt_file}` в аргументах и environment variables `LUMA_PROJECT_ROOT`, `LUMA_TASK_ID`, `LUMA_ROLE`, `LUMA_AGENT_ID`, `LUMA_ACTION`, `LUMA_PROMPT_FILE`.
Пример формы настройки (имя/флаги заменить реальными для вашего harness):
```json
{"argv": ["your-agent-cli", "--prompt-file", "{prompt_file}"], "git_commits": true, "max_sessions": 1000, "timeout_seconds": 1800, "max_prompt_chars": 80000}
```
`commands_by_role` позволяет указать другую argv-array для отдельных ролей, например crypto/security. Не хранить secrets в аргументах/JSON; использовать безопасное окружение harness. Конкретная модель и команда не выдумываются автоматически.
Harness обязан запускать новую conversation/session для каждого процесса, исполнять file/tool commands, соблюдать project sandbox и завершаться после submit/review/escalate. Не использовать флаги resume/thread reuse и auto-next-task внутри harness.
Автоматические commits включены по умолчанию. Перед первым реальным запуском foundation должна быть сохранена начальным commit в Git checkout с активной веткой, настроенной identity и чистым index/working tree. Каждый agent transition заканчивается отдельным осмысленным commit перед следующим процессом. Executor и reviewer заранее пишут сообщения; Git выполняет runner. Правила, примеры и восстановление — `docs/GIT_WORKFLOW.md`.
## Codex 0.159.0: argv (S00-028)
Coordinator выбрал из project root:
```sh
codex -c sandbox_workspace_write.network_access=true exec --approve-for-me --ephemeral -
```
`--approve-for-me` включает workspace-write/auto-review и конфликтует с `--sandbox`.
`-` читает fresh prompt из stdin; resume/fork не использовать. Проверки без модели:
argv + `--help` и sandbox probe ниже, timeout20, exit0; project write passed,
outside denied EROFS30. Полное evidence: `state/evidence/S00-028-auto-ci-cd-e3a716a94424.md`.
## Запуск
```sh
python3 scripts/runner.py --dry-run
python3 scripts/runner.py --config runner.local.json
# Ограничить согласованным этапом:
python3 scripts/runner.py --config runner.local.json --stage S00
```
Dry run не назначает tasks, не пишет state и работает без настроенной модели. Он показывает первую задачу и размер prompt. После настройки один обычный запуск последовательно выполняет очередь: executor → новый reviewer → следующий executor. Каждый subprocess имеет новый agent id и читает master prompt заново.
## Blocker flow
1. Текущий агент записывает handoff/issue, `escalate`, заканчивает работу.
Runner сохраняет checkpoint незавершённой работы и причины; это не acceptance. Только после commit запускается resolver.
2. Оригинал blocked, resolver todo с ограниченным scope и исходными prerequisites. Resolver не зависит от blocked оригинала.
3. Runner приоритетно запускает нового resolver-агента.
4. Другой новый процесс проверяет resolver.
5. Только done resolver автоматически снимает блокировку оригинала. Оригинал возвращается в todo либо review, прежний reporter id retired.
6. Новый executor/reviewer читает исходную карточку и handoff; потом продолжается обычная очередь.
Nested blocker проходит тот же процесс. Глубина выше 3 или 6 remediation на одну root task автоматически переводит очередную remediation в ожидание внешнего решения. Так не возникает бесконечного создания одинаковых задач/процессов.
## Когда требуется пользователь
Credentials/оплата/неопределённое продуктовое решение/действие внешнего администратора, достигнутый blocker limit, нарушение scope или ненастроенный CLI. `requires_user_input` не означает автоматическое done; задача ждёт конкретного input.
После внешнего исправления:
```sh
python3 scripts/tasks.py release-external <RESOLVER-ID> --agent coordinator-new --role orchestrator \
--reason 'Конкретное условие выполнено; ссылка на безопасное подтверждение'
python3 scripts/runner.py --config runner.local.json
```
Release только делает resolver готовым к проверяемой реализации, не завершает его и не снимает блокировку оригинала.
## Остановка и безопасность исполнения
`max_sessions` ограничивает число новых процессов за invocation; exhaustion возвращает summary, не done. Runner наблюдает terminal transition: после escalate/submit/approve/reject прекращает старый process group на POSIX, даже если harness пытается продолжать. Новый процесс запускается только после завершения старого. Timeout также прекращает process group, затем создаётся remediation. На других ОС harness должен гарантировать остановку дочерних процессов. До завершения старого процесса новый не запускается.
`.runner.lock` запрещает два coordinator процесса в одном checkout. Не удалять lock живого runner; после сбоя проверить PID runner и возможного child agent, остановить только подтверждённо зависшие собственные процессы и восстановить запуск. Автоматического stealing чужой активной задачи нет.
Изменения исходников сравниваются со scope. Workflow metadata/generated files являются служебным исключением; проверка не заменяет OS sandbox и не доказывает отсутствие записи за пределами project root. Запускать harness в отдельном checkout, без параллельных ручных правок и с write sandbox только проекта. При scope violation runner сохраняет incident/remediation и останавливается, не откатывая потенциально чужие изменения автоматически.
Журналы: `state/runs/<agent-id>/run.json`, `prompt.md`, `output.log`; хранить без secrets. Каждый report содержит task/role, exit/status, timeout/violation и результат, не включает private command environment.
## Вложенный sandbox: проверенный host context (S00-031)
На этом Linux host с Codex 0.159.0 `/tmp/codex-daemon-1000` имеет uid 1000,
mode 0700; внутри workspace sandbox тот же путь виден с mode 000.
Ошибка вложенного запуска `app-server socket directory must be a user-owned directory
with mode 0700` сама по себе не доказывает неверные host permissions. Для S00-030
использовать проверенный ниже host context; исправление mode на host не требуется.
Проверенный способ: одобренный внешний host execution
(`sandbox_permissions: require_escalated`) запускает **внутренний workspace-write sandbox**
из корня проекта, с timeout 20 секунд:
```sh
codex -c 'sandbox_mode="workspace-write"' -c sandbox_workspace_write.network_access=true sandbox -- python3 /tmp/luma-filesystem-sandbox-probe.py
```
До запуска проверить host `stat`: directory, owner=current uid, mode 0700.
Script содержит только synthetic project write/read/remove и exclusive-create вне
проекта с обязательным отказом EROFS/EACCES/EPERM. Его полный текст и воспроизводимая
команда сохранены в `state/evidence/S00-031-auto-ci-cd-d45ccd3ee7d6.md`;
временный `/tmp` script нужно сначала прочитать или восстановить из evidence.
Executor получил exit 0: project probe passed, outside write denied EROFS 30,
outside file не создан. Ни модель, ни storage task не запускались.
Не менять socket permissions/mask, writable roots или environment location.
Если approved host execution недоступен, выполнить blocker protocol.
Результат относится к этому host/version и одной filesystem boundary; QA повторяет
проверку независимо. Это не app readiness. Общие понятия:
[официальная документация OpenAI](https://developers.openai.com/codex/security).
## Гарантии инструмента
Dependency/role guards, retired reporter, recovery journal definitions+state, fresh subprocess IDs, bounded prompts, separate reviewer, automatic unblocking only after done и stop на внешнем blocker. Истинность evidence/качество модели/OS sandbox обеспечиваются реальным harness и review, а не названием роли.
В поставляемой основе автоматизация проверяется fake tool-capable harness в isolated temporary project, включая реальные commits в временных Git repositories, независимое review и ошибки hooks/messages. Реальные 275 продуктовых задач не запускаются при обновлении основы.