複数プロダクトのroutingとmerge責任を揃える

.codex/agents/product-manager.tomlと.agents/skills/software-delivery/SKILL.mdでは、Product Managerのdomainを、コーポレートサイトを除くWirohの全productへ一般化した。コーポレートサイトはOrganization Designerのdomainとして維持し、領域をまたぐ依頼では主要なbusiness outcome、scope分割、依存関係、返却経路を示してprimary domain leadを一人に定める構成にした。

• 新規productでは、対象user、business outcome、success metric、product boundary、既存productとのdependencyを定義する。
• 複数productでは、productごとのbacklogとportfolio横断の優先順位判断を分ける。resource、共通capability、release dependencyが競合する場合は、CEOへ選択肢、影響、推奨順位を提示する。
• 実装、設計、法務などのspecialistを並行で動かす場合は、担当境界、入力、依存関係、期待出力、合流点、停止条件を共有し、同じfile群へ書き込む作業は並列化しない。

.codex/config.tomlのmax_threadsは12へ変更し、静的な.codex/agents/*.tomlの件数とは独立した、同時にopenできるcustom-agent thread全体のglobal capとして定義した。7つのroleを各1 instanceずつ開く場合に限れば追加5 thread相当の余地があるが、12 threadの常時起動を推奨する値ではない。CPU、memory、network、tool quota、working treeのcontentionは別に監視し、依存関係のある作業やwrite-heavyな作業を並列化しない制約を残した。

[agents]
# Global cap for concurrently open custom-agent threads; static agent definitions do not consume slots.
# If all seven current roles run one instance each, 12 leaves capacity for five additional concurrent threads.
max_threads = 12
# Minimum depth for Mako depth 0 -> Yui/Ryoma depth 1 -> Manabu depth 2 -> Ikumi depth 3 -> Ritsu depth 4.
max_depth = 4
job_max_runtime_seconds = 1800

人向けの入口は読者向けの入口へまとめた。CEOは定型prompt、Skill名、agent_typeを覚えず、outcome、背景、制約、期限、避けたい操作を自由文でMakoへ伝える。Mako以降のmachine-facing handoffではrole id、入力、依存関係、期待出力、停止条件、review evidenceを明示する。handoff例にはこの内部handoffの例を移し、旧CEO prompt集と、運用対象になっていなかったplugin packaging guideを削除した。技術文書群は権限やgateを追加せず、AGENTS.md、agent TOML、Skills、rulesと食い違う場合はそれらのnormative ruleを優先する境界も明記した。

mergeの主体はAGENTS.md、software delivery Skill、.codex/rules/organization.rules、handoff例で揃えた。role agentはPR作成、検証、独立review対応までを担い、ready化、merge、linked Issue close、post-merge cleanupは実行しない。CEO本人がtrusted transcript上の現スレッドで対象とmerge methodを明示承認した後だけ、Makoが対象一致を検証して進める。過去や別スレッドの承認、domain requestの承認、独立reviewのpass、command risk reviewerの許可はmerge承認の代用にしない。

merge権限不足、connectorまたはrisk reviewerの拒否、conflict、承認証跡不足をrole agentが検出した場合は、別connector、CLI、別identity、手動Issue closeへfallbackせず、対象、希望method、承認証跡、拒否理由、未解決gate、返却先を含むMako relay packetを返して停止する。Mako自身の承認済みmergeが同じ理由で止まった場合は自分宛てのrelayを作らず、その場でblockerとして報告する。copy-ready文面へのfallbackはnon-merge操作だけへ限定した。

確認の途中では二段階のFAILが記録された。最初は特定productに残ったrouting、mergeにも読めるfallback、role間で揃っていないrelay項目、merge成功前にIssueをcloseできる余地を修正した。次の確認では、7つの静的role定義がthread slotを消費するように読める説明と、merge failureにもcopy-ready fallbackを許すように読める人向け文書が残ったため、global capの条件付き説明とnon-merge限定のfallbackへ改めた。

検証では、project設定と7つのcustom-agent定義をTOMLとしてparseし、agent inventoryが7、global capが12であることを確認した。rulesの構文、mergeとIssue closeがpromptになる判定、古いroutingとmerge文言の残存、全agent定義でrelay packetの必須項目が揃うこと、差分の空白errorも確認した。