opencode-config/docs/handoff/pr-61-drop-hardcoded-repo-in-review-tools.md

---

pr: 61 title: fix(tools): drop hardcoded --repo in post-review/post-docs-review

Что сделано

• Убран хардкод ,"--repo","slaid098/opencode-config" из tools/post-review.ts:16 и tools/post-docs-review.ts:16. Теперь gh pr comment N --body <comment> без --repo — gh auto-detect'ит репо из context.worktree (cwd), симметрично с create-pr.ts/merge-pr.ts/commit.ts.
• run-pipeline/SKILL.md Template B (docs-review) и Template C (code_review) синхронизированы с промптами агентов: raw gh pr comment M --body "## ... Summary\n..." заменён на вызовы post_docs_review/post_review tool. Устранено расхождение skill-шаблон ↔ промпт (code smell, модель могла выбрать любой путь).
• В agents/reviewer.md и agents/docs-reviewer.md добавлена секция "Tool failure handling": если tool вернул ⚠️ ...failed — СООБЩИ оркестратору и STOP, не fallback на raw gh pr comment. Раньше инструкции не было (см. memory post-review-post-docs-review-tool-vs-skill-discrepancy.md — "Fallback instructions — НЕТ").
• Тесты обновлены: test_spawnsync_args в tests/test_post_review_tool.{py,ts} и tests/test_post_docs_review_tool.{py,ts} теперь утверждают --repo НЕ в args (было args[repo_idx] == "slaid098/opencode-config") и что args заканчиваются на --body <comment>. Docstring обновлены. Все 24 Python теста проходят.
• ADR-019 (docs/decisions/019-pr-46-review-posting-tools.md) дополнен секцией "Superseding note (PR#60)": зафиксировано убирание хардкода, пересмотр rejected alternative "Параметризовать --repo", устранение расхождения skill-шаблонов, добавление инструкции обработки сбоя.

Почему

post-review.ts/post-docs-review.ts хардкодили --repo slaid098/opencode-config в spawnSync("gh", [..., "--repo", "slaid098/opencode-config"]). Флаг --repo перегружает auto-detect — gh игноряет cwd (context.worktree) и всегда постит в slaid098/opencode-config, независимо от репо в котором идёт работа.

Симптомы (из issue #60):

1. При работе в репо ≠ opencode-config (например voice-dictation) коммент постится в opencode-config PR (по номеру), а не в целевой репо.
2. При коллизии номеров PR (PR#29 существует в обоих репо) gh возвращает exit 0 даже на MERGED PR — tool рапортует успех без верификации.
3. pipeline-status.py (который правильно деривит репо из git remote) видит 0 комментов на целевом PR → pipeline застревает на DOCS/REVIEW phase.
4. Подтверждено: 5 misrouted "Docs Review" комментов найдено на opencode-config PR#29, предназначавшихся voice-dictation PR#29 (cross-post incident).

Асимметрия: create-issue.ts, create-pr.ts, merge-pr.ts НЕ передают --repo — полагаются на auto-detect. Только post-review/post-docs-review хардкодили — legacy/oversight из ADR-019 (rejected alt "out of scope. Сейчас tools специфичны для slaid098/opencode-config").

Расхождение skill ↔ промпт: промпты reviewer.md:218, docs-reviewer.md:198 предписывали tool, а run-pipeline/SKILL.md Template B/C предписывали raw gh pr comment. Оба пути разрешены (gh pr comment* в allow-list), но расхождение — code smell.

Pending

— (после мерджа: обновить memory notes technical/post-docs-review-silent-failure-pr-29.md и technical/post-review-post-docs-review-tool-vs-skill-discrepancy.md — пометить resolved, importance high → medium. Делается в этом же PR, шаг 6 спеки issue #60.)

Watch out

• Tool'зы теперь требуют, чтобы context.worktree указывал на git-репо с origin remote. Из не-git директории /root/workspace gh упадёт с явной ошибкой (лучше тихого misroute). Это ожидаемое поведение — см. ADR-019 superseding note п.5.
• gh pr comment* остался в allow-list reviewer.md/docs-reviewer.md — raw bash путь технически разрешён, но промпт + SKILL.md теперь однозначно говорят "используй tool". Если захотеть strict tool-only — отдельный PR с deny правилом (см. ADR-019 rejected alt "Запретить raw gh pr comment в allow-list").
• TS-тесты (test_post_review_tool.ts, test_post_docs_review_tool.ts) — документационные, запускаются под bun test (bun runtime недоступен на CI). Реальные assertions в Python-зеркалах, которые запускаются через tests/_ts_loader.mjs.
• Pipeline-status.py regex'ы НЕ изменены — tools генерируют ровно тот формат (## Code Review Summary + ### Verdict: <V>, ## Docs Review Summary), который парсят REVIEW_VERDICT_RE и DOCS_REVIEW_RE.