{"id":48715639,"url":"https://github.com/dapi/ai-teamlead","last_synced_at":"2026-04-11T16:46:20.756Z","repository":{"id":344219639,"uuid":"1180888937","full_name":"dapi/ai-teamlead","owner":"dapi","description":"CLI-first local AI team lead for GitHub issue analysis and implementation with tmux/zellij-based agent workflows.","archived":false,"fork":false,"pushed_at":"2026-03-18T17:24:40.000Z","size":953,"stargazers_count":2,"open_issues_count":28,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-04-11T16:46:19.614Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dapi.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":"AGENTS.md","dco":null,"cla":null}},"created_at":"2026-03-13T14:18:29.000Z","updated_at":"2026-03-18T17:24:45.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/dapi/ai-teamlead","commit_stats":null,"previous_names":["dapi/teamlead"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/dapi/ai-teamlead","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dapi%2Fai-teamlead","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dapi%2Fai-teamlead/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dapi%2Fai-teamlead/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dapi%2Fai-teamlead/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dapi","download_url":"https://codeload.github.com/dapi/ai-teamlead/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dapi%2Fai-teamlead/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31687881,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-11T13:07:20.380Z","status":"ssl_error","status_checked_at":"2026-04-11T13:06:47.903Z","response_time":54,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-04-11T16:46:20.148Z","updated_at":"2026-04-11T16:46:20.746Z","avatar_url":"https://github.com/dapi.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"# ai-teamlead workflow\n\n[![CI](https://github.com/dapi/ai-teamlead/actions/workflows/ci.yml/badge.svg?branch=main)](https://github.com/dapi/ai-teamlead/actions/workflows/ci.yml)\n\nЭтот проект это набор локальных CLI-first скриптов для персонального workflow\nвокруг AI-driven анализа GitHub issue.\n\n## Статус README\n\nЭтот `README.md` является repo-level входной точкой и верхнеуровневым обзором\nпроекта.\n\nОн является каноническим источником для:\n\n- назначения продукта\n- границ MVP\n- общей карты документации\n- краткой архитектурной рамки уровня всего репозитория\n\nОн не является каноническим источником для:\n\n- flow-контрактов и статусных переходов\n- детальной схемы конфигурации\n- subsystem-level runtime-контрактов\n- порядка реализации и verification-деталей\n\nДля этих слоев `README.md` дает только summary и ссылки на профильные\nканонические документы.\n\n## Системные требования\n\n- **Rust** (edition 2024) и **Cargo**\n- **Git**\n- **GitHub CLI** (`gh`) с активной авторизацией\n- **zellij** для управления agent-сессиями\n- **Docker** — только для интеграционных тестов (`test-zellij`)\n\n## Ключевое требование\n\nПроект должен быть спроектирован так, чтобы его можно было легко подключить к\nлюбому GitHub-репозиторию без переписывания основной логики.\n\nТекущее репо одновременно является:\n\n- репозиторием самого инструмента\n- dogfooding-средой, в которой инструмент разрабатывается и используется на\n  самом себе\n\nИз этого следуют требования:\n\n- логика flow не должна быть жестко привязана к одному конкретному репозиторию\n- repo-specific настройки должны жить в конфиге, а не в коде\n- инструмент должен уметь работать как минимум в двух режимах:\n  на собственном репозитории и на внешнем подключенном репозитории\n- конфиг должен жить внутри самого целевого репозитория\n- каждый репозиторий должен иметь возможность запускать свой собственный\n  экземпляр `ai-teamlead` независимо от других репозиториев\n\n## Структура документации\n\nДокументация проекта строится по трем осям:\n\n1. Что строим\n2. Как строим\n3. Как проверяем\n\nЭто правило действует и на уровень проекта, и на уровень отдельных фич.\n\nБазовые документы:\n\n- `README.md` как repo-level overview и входная точка\n- [ROADMAP.md](./ROADMAP.md) как repo-level карта backlog, кластеров и\n  зависимостей\n- [docs/governance.md](./docs/governance.md)\n- [docs/code-quality.md](./docs/code-quality.md)\n- [docs/config.md](./docs/config.md)\n- [docs/documentation-structure.md](./docs/documentation-structure.md)\n- [docs/documentation-process.md](./docs/documentation-process.md)\n- [docs/terminology.md](./docs/terminology.md)\n- [docs/implementation-plan.md](./docs/implementation-plan.md)\n- [docs/templates/feature-spec-template.md](./docs/templates/feature-spec-template.md)\n- [docs/templates/implementation-plan-template.md](./docs/templates/implementation-plan-template.md)\n- [docs/issue-analysis-flow.md](./docs/issue-analysis-flow.md)\n- [docs/issue-implementation-flow.md](./docs/issue-implementation-flow.md)\n- [docs/untrusted-input-security.md](./docs/untrusted-input-security.md)\n- [docs/features/0001-ai-teamlead-cli/README.md](./docs/features/0001-ai-teamlead-cli/README.md)\n- [docs/features/0002-repo-init/README.md](./docs/features/0002-repo-init/README.md)\n- [docs/features/0003-agent-launch-orchestration/README.md](./docs/features/0003-agent-launch-orchestration/README.md)\n- [docs/features/0004-issue-implementation-flow/README.md](./docs/features/0004-issue-implementation-flow/README.md)\n- [docs/features/0005-agent-flow-integration-testing/README.md](./docs/features/0005-agent-flow-integration-testing/README.md)\n- [docs/features/0006-public-repo-security/README.md](./docs/features/0006-public-repo-security/README.md)\n- [docs/features/0007-default-issue-aware-tab-naming/README.md](./docs/features/0007-default-issue-aware-tab-naming/README.md)\n- [docs/adr/0034-default-issue-aware-tab-name-for-tab-launch.md](./docs/adr/0034-default-issue-aware-tab-name-for-tab-launch.md)\n- [docs/adr/](./docs/adr/) — Architecture Decision Records\n- [AURA.md](./AURA.md) как project-local доступ к\n  личному высокоуровневому инженерному видению разработчика\n\n## MVP\n\nПервая завершенная MVP-граница проекта покрывала только analysis stage и\nподготовку плана реализации.\n\nСледующий stage проекта добавляет отдельный implementation flow, но он остается\nотдельным каноническим contract layer и не смешивается с analysis SSOT.\n\n## Модель запуска\n\n`ai-teamlead` реализуется как foreground CLI-утилита с командами:\n\n- `init` — подключение репозитория, создание project-local contract layer\n- `poll` — один цикл просмотра project snapshot: выбирает подходящую issue из\n  `Backlog` и передает ее в общий issue-level `run`-path\n- `run` — канонический issue-level entrypoint: определяет текущий stage issue,\n  выбирает analysis или implementation flow, переводит статус, работает с\n  `session_uuid` и запускает или восстанавливает launcher path\n- `loop` — бесконечный foreground loop поверх `poll` с паузой из\n  `runtime.poll_interval_seconds`\n\nРазделение ответственности:\n\n- `poll` отвечает только за selection cycle\n- `run` отвечает за issue-level lifecycle\n- `loop` отвечает только за повторение `poll`\n\n## Источник истины\n\nИсточник истины по состоянию задачи это поле статуса в default GitHub Project.\n\nКанонические flow-контракты, модели статусов и правила переходов зафиксированы\nв:\n\n- [docs/issue-analysis-flow.md](./docs/issue-analysis-flow.md)\n- [docs/issue-implementation-flow.md](./docs/issue-implementation-flow.md)\n\nПостоянное локальное runtime state не используется как источник истины.\nЛокально могут существовать только временные рабочие файлы.\n\n## Отбор задач\n\nIssue подходит для запуска flow анализа, если:\n\n- issue state = `open`\n- issue находится в нужном GitHub Project\n- project status = `Backlog`\n\nТип задачи определяется:\n\n1. по GitHub labels\n2. по тексту issue, если labels не хватает\n\nПоддерживаемые типы:\n\n- `bug`\n- `feature`\n- `chore`\n\n## Flow анализа\n\nFlow анализа и CLI-контракт вынесены в отдельный SSOT:\n\n- [docs/issue-analysis-flow.md](./docs/issue-analysis-flow.md)\n\nКоротко:\n\n- если для реализации не хватает данных, агент задает вопросы в своей сессии\n- если данных хватает, flow формирует план реализации\n- для `feature` дополнительно обязательны `User Story` и `Use Cases`\n- у flow есть human gate на ответах на вопросы и на принятии плана\n\n## Flow реализации\n\nFlow реализации и handoff после принятия плана вынесены в отдельный SSOT:\n\n- [docs/issue-implementation-flow.md](./docs/issue-implementation-flow.md)\n\nКоротко:\n\n- оператор по-прежнему использует `run \u003cissue\u003e`;\n- `run` сам определяет, что issue уже находится в implementation lifecycle;\n- реализация опирается на approved analysis artifacts;\n- implementation stage ведет issue через `Implementation In Progress`,\n  `Waiting for CI`, `Waiting for Code Review`, `Done` и\n  `Implementation Blocked`.\n\n## Статусы проекта\n\nНиже приведен только summary для быстрого ориентирования.\n\nКанонический список статусов, их значения и допустимые переходы описаны в\n[docs/issue-analysis-flow.md](./docs/issue-analysis-flow.md).\n\nДля flow анализа используются следующие статусы в GitHub Project:\n\n- `Backlog`\n- `Analysis In Progress`\n- `Waiting for Clarification`\n- `Waiting for Plan Review`\n- `Ready for Implementation`\n- `Analysis Blocked`\n\nДля flow реализации используются следующие дополнительные статусы:\n\n- `Implementation In Progress`\n- `Waiting for CI`\n- `Waiting for Code Review`\n- `Done`\n- `Implementation Blocked`\n\n## Конфигурация\n\nОсновной конфиг проекта называется `settings.yml` и лежит в\n`./.ai-teamlead/` целевого репозитория.\n\nКоротко:\n\n- `ai-teamlead` всегда читает `./.ai-teamlead/settings.yml` из текущего\n  репозитория;\n- минимальный active override для MVP это `github.project_id`;\n- остальные поля могут приходить из runtime defaults и bootstrap template;\n- launcher contract для `zellij.session_name`, `zellij.tab_name`,\n  `zellij.launch_target`, `zellij.layout` и `launch_agent.*` вынесен в\n  отдельную документацию.\n\nКанонический документ по конфигурации:\n\n- [docs/config.md](./docs/config.md)\n\nСвязанные документы:\n\n- [docs/features/0001-ai-teamlead-cli/README.md](./docs/features/0001-ai-teamlead-cli/README.md)\n- [docs/features/0002-repo-init/README.md](./docs/features/0002-repo-init/README.md)\n- [docs/features/0003-agent-launch-orchestration/README.md](./docs/features/0003-agent-launch-orchestration/README.md)\n## Project contract layer\n\nVersioned project-local contract живет в рабочем дереве репозитория:\n\n```text\n.ai-teamlead/\n  README.md\n  settings.yml\n  init.sh\n  launch-agent.sh\n  flows/\n    issue-analysis-flow.md\n    issue-analysis/\n      README.md\n      01-what-we-build.md\n      02-how-we-build.md\n      03-how-we-verify.md\n```\n\nКлючевые launcher templates в `settings.yml`:\n\n```yaml\nlaunch_agent:\n  analysis_branch_template: \"analysis/issue-${ISSUE_NUMBER}\"\n  worktree_root_template: \"${HOME}/worktrees/${REPO}/${BRANCH}\"\n  analysis_artifacts_dir_template: \"specs/issues/${ISSUE_NUMBER}\"\n  implementation_branch_template: \"implementation/issue-${ISSUE_NUMBER}\"\n  implementation_worktree_root_template: \"${HOME}/worktrees/${REPO}/${BRANCH}\"\n  implementation_artifacts_dir_template: \"specs/issues/${ISSUE_NUMBER}\"\n```\n\nНиже показана ожидаемая shape project-local contract layer.\n\nКанонический контракт по составу и роли этих файлов раскрыт в\n[docs/features/0002-repo-init/README.md](./docs/features/0002-repo-init/README.md)\nи\n[docs/features/0003-agent-launch-orchestration/README.md](./docs/features/0003-agent-launch-orchestration/README.md).\n\nBootstrap default для [./.ai-teamlead/launch-agent.sh](./.ai-teamlead/launch-agent.sh):\n\n- подготавливает analysis branch/worktree по templates из `settings.yml`\n- создает каталог versioned analysis-артефактов\n- запускает `codex`, если он доступен\n- иначе оставляет shell внутри подготовленного worktree\n\nТекущий контракт `launch_agent.*` в реализации:\n\n- поддерживаются placeholder-переменные `${HOME}`, `${REPO}`,\n  `${ISSUE_NUMBER}`\n- для `worktree_root_template` и `analysis_artifacts_dir_template`\n  дополнительно доступна `${BRANCH}`\n- интерполяция выполняется простым string replace внутри `ai-teamlead`\n- неизвестные placeholder-переменные в MVP не валидируются и остаются как есть\n  в результирующей строке\n- `worktree_root_template` должен давать абсолютный путь к worktree root\n- `analysis_artifacts_dir_template` интерпретируется как путь относительно\n  analysis worktree\n\nProject-local agent assets:\n\n- [./.claude/README.md](./.claude/README.md) для\n  Claude-specific материалов\n- [./.codex/README.md](./.codex/README.md) как project\n  convention для Codex-specific материалов\n\nИнициализация этого слоя оформляется отдельной ручной командой:\n\n- `ai-teamlead init`\n\nТребование к `init`:\n\n- команда запускается внутри git-репозитория\n- в репозитории уже должен быть настроен `origin`, указывающий на GitHub\n  repository\n- `init` использует этот `origin` как repo context текущего проекта\n\nПосле `init` оператор должен вручную завершить bootstrap:\n\n1. раскомментировать и заменить `github.project_id` на реальный GitHub Project\n   id\n2. при необходимости раскомментировать и скорректировать `zellij.session_name`,\n   `zellij.launch_target`, `zellij.layout` или `launch_agent.*` templates под\n   layout проекта\n4. только после этого запускать `poll`, `run` или `loop`\n\nЕсли `github.project_id` оставлен placeholder-значением или указывает на\nневалидный проект, текущая реализация падает на чтении project snapshot до\nвыбора issue.\n\nRuntime state и временные артефакты при этом живут отдельно в:\n\n```text\n.git/.ai-teamlead/\n```\n\nЕсли в корне репозитория отсутствует `./init.sh`, bootstrap может дополнительно\nсоздать симлинк:\n\n```text\n./init.sh -\u003e ./.ai-teamlead/init.sh\n```\n\nBootstrapped `./.ai-teamlead/init.sh` рассчитан на запуск уже внутри worktree:\n\n- он копирует отсутствующие `.env*` из primary worktree\n- не перезаписывает уже существующие `.env*`\n- определяет default branch без перебора `git worktree list`\n\nОграничение MVP:\n\n- целевое значение `runtime.max_parallel = 1`\n- если используется одна фиксированная `zellij` tab, значения больше `1` пока\n  не поддерживаются корректно\n\n## Как проверяем\n\nПроект считается собранным корректно, если одновременно выполняются условия:\n\n- `poll` выбирает первую подходящую issue в порядке snapshot GitHub Project\n- `poll` и `run` используют один и тот же issue-level launcher contract\n- `loop` переиспользует тот же `poll` cycle и не вводит отдельный issue-level\n  path\n- для каждой запущенной issue создается durable binding `issue \u003c-\u003e session_uuid`\n- `launch-agent.sh` подготавливает worktree и versioned analysis artifacts до\n  старта агента\n- при отсутствии `codex` launcher честно деградирует в shell внутри уже\n  подготовленного analysis worktree\n\nМинимальный ручной smoke для MVP:\n\n- `ai-teamlead init` в чистом git-репозитории с настроенным `origin`\n- ручная замена `github.project_id` в `./.ai-teamlead/settings.yml`\n- успешный `poll` для issue в `Backlog`\n- успешный `run` для issue в одном из разрешенных waiting-статусов\n- проверка, что `loop` переживает пустой cycle и ошибку одного cycle\n- проверка runtime-артефактов в `.git/.ai-teamlead/`\n- проверка независимого запуска на втором репозитории с другим\n  `zellij.session_name`\n\n## Тестирование `zellij`\n\nИнтеграционные тесты launcher выполняются в Docker.\n\nПравила:\n\n- pinned версия `zellij` хранится в `ZELLIJ_VERSION`\n- CI скачивает release из `dapi/zellij-main`\n- внутри контейнера бинарь сохраняется как обычный `zellij`\n- launcher-тесты гоняются headless через `script`\n\nЛокальный запуск:\n\n- `mise run test-zellij`\n\n## Полный локальный test suite\n\nКанонический локальный entrypoint для полного прогона, включая live AI smoke:\n\n- `./test-local.sh`\n\nЭтот скрипт последовательно запускает:\n\n- `cargo test`\n- `run-happy-path` в `stub`-режиме\n- `live-codex-smoke`\n- `live-claude-smoke`\n\nДля успешного прогона локально нужны:\n\n- Docker\n- локально доступный `codex`\n- локально доступный `claude`\n- активная авторизация для обоих live-агентов на хосте\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdapi%2Fai-teamlead","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdapi%2Fai-teamlead","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdapi%2Fai-teamlead/lists"}