FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Aligning multi-product routing and merge responsibility
Synchronizing product ownership, thread capacity, operator guidance, and CEO-gated merges in one operating model
Purpose
After execution permissions for the AI organization had been reorganized, the Product Manager scope could still be read as centered on one product, without a sufficiently general owner for priorities and dependencies across multiple products. At the same time, the custom-agent thread limit was described in relation to the number of static role definitions, and the boundary between operator documentation and rules followed by agents was dispersed.
Merge operations also needed one consistent control spanning CEO approval, the handoff from delivery roles to Mako, readiness, Issue closure, and failure stop conditions. This Activity aligned product-wide domain routing, thread capacity, operator documentation, and merge authorization within the same operating model.
Implementation
.codex/agents/product-manager.toml and .agents/skills/software-delivery/SKILL.md generalized the Product Manager domain to every Wiroh product except the corporate site. The corporate site remained with Organization Designer. Cross-domain requests selected one primary domain lead by identifying the dominant business outcome, scope split, dependencies, and return path.
- A new product defined its target user, business outcome, success metric, product boundary, and dependencies on existing products.
- Multi-product work separated each product backlog from portfolio-level prioritization. When resources, shared capabilities, or release dependencies conflicted, the CEO received options, effects, and a recommended order.
- Parallel specialist work shared boundaries, inputs, dependencies, expected outputs, merge points, and stop conditions. Work writing to the same file group was not parallelized.
max_threads in .codex/config.toml was changed to 12 and defined as the global cap on concurrently open custom-agent threads, independent of the number of static .codex/agents/*.toml definitions. If all seven roles opened one instance, five additional threads would remain, but the value did not recommend keeping twelve threads active. CPU, memory, network, tool-quota, and working-tree contention still required monitoring, and dependent or write-heavy work remained non-parallel.
[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 = 1800The operator-facing entry point moved to the reader-facing guide. The CEO could describe an outcome, background, constraints, deadline, and actions to avoid in free-form language without memorizing prompt templates, Skill names, or agent_type. Machine-facing handoffs after Mako still named the role ID, inputs, dependencies, expected outputs, stop conditions, and review evidence. Internal examples moved to the handoff examples; the former CEO prompt collection and an unused plugin-packaging guide were removed. The documentation also stated that technical documentation did not add or override permissions and that AGENTS.md, agent TOMLs, Skills, and rules took precedence when wording diverged.
Rendering diagram…
The merge subject was aligned across AGENTS.md, the software-delivery Skill, .codex/rules/organization.rules, and handoff examples. Role agents handled Pull Request creation, verification, and independent-review responses but did not mark a Pull Request ready, merge it, close its linked Issue, or perform post-merge cleanup. Only after the CEO explicitly approved the target and merge method in the current trusted transcript did Mako verify the match and proceed. Approval from an earlier or different thread, approval of the domain request, an independent-review pass, or permission from a command risk reviewer could not substitute for merge approval.
When a role agent detected insufficient merge permission, connector or risk-reviewer rejection, a conflict, or missing approval evidence, it stopped without falling back to another connector, the CLI, another identity, or manual Issue closure. It returned a Mako relay packet containing the target, desired method, approval evidence, rejection reason, unresolved gates, and return destination. If Mako's own approved merge stopped for the same reasons, Mako did not create a relay to itself and reported the blocker in place. Copy-ready fallback was limited to non-merge operations.
Two failed review stages were recorded during verification. The first led to corrections for product-specific routing, fallback language that could include merge, inconsistent relay fields, and Issue closure before confirmed merge success. The next check found that the thread-capacity explanation could imply seven static roles consumed slots and that operator documentation could still allow copy-ready fallback for merge failure. Those points were revised to a conditional global-cap explanation and a non-merge-only fallback.
Verification parsed the project configuration and seven custom-agent definitions as TOML, recorded an agent inventory of seven and a global cap of twelve, checked rule syntax and prompt decisions for merge and Issue closure, searched for stale routing and merge language, confirmed the required relay fields across agent definitions, and checked the diff for whitespace errors.
What was confirmed
Verification results
The final change covered 24 files with 302 additions and 239 deletions, aligning product-wide Product Manager routing, thread capacity, operator documentation, and merge authorization across configuration, agent definitions, Skills, rules, and operating documents.
max_threads = 12 was documented as a global concurrency cap independent of static role definitions, together with the conditional five-thread margin after one instance of each of seven roles and the constraints around resource contention and write-heavy parallelism.
The ordinary role-agent handoff was separated from readiness, merge, Issue updates, and post-merge cleanup performed by Mako only after current-thread CEO approval. Blocked merges also shared a stop condition that prohibited switching connectors, CLI, identities, or manual closure.
The routing, capacity wording, fallback, relay, and Issue-closure inconsistencies raised across two failed checks were corrected. The final record confirmed an explicit independent-review pass, successful TOML, rule, stale-text, and diff checks, and completion of the Task after incorporation.
The Activity did not test twelve simultaneous threads, establish that resource contention had been eliminated, or exercise every merge-failure path at runtime. The verified scope ended with configuration and documentation consistency, policy decisions, static checks, review, and the final integration record.
Basis for completion
The Activity was complete when product-wide domain routing, the global thread cap, the boundary between operator documentation and normative rules, and Mako-only merge authorization and failure handling were consistent across 24 files, and the record showed successful TOML, rule, stale-text, and diff checks plus independent review after both rounds of findings were corrected.