FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Rebuilding AI-organization execution permissions through narrow entry points
Aligning Task-first records, domain-lead delegation, guarded routine operations, and independent review in one operating model
Purpose
Separating the Executive Secretary from delivery work was not sufficient if a domain lead could not record a Task, hand work to the required specialists, and consolidate their results. Operational friction also remained because project settings fixed the secretary's model choice, Issue creation required another approval, the UI/UX role was narrowly Web-oriented, and review could be read as applying mainly to Pull Requests. These conditions risked moving practical work back into secretary-operated relays.
This Activity made Mako the top-level router and Yui and Ryoma the domain leads responsible for Task records, requirement clarification, specialist sequencing, and consolidation. It also combined narrowly scoped wrappers for routine operations, CEO approval gates for force operations and merges, and independent review of all non-Ritsu artifacts into one operating model designed to support autonomous execution and control together.
Implementation
Yui, the Organization Designer, replaced a model in which Mako continually selected individual specialists with one that chose a single primary domain lead according to the main outcome. Yui owned organization operations, AI organization governance, and Wiroh corporate-site work, while Ryoma owned product work. Cross-domain requests identified the dominant outcome, scope split, dependencies, and relay path before choosing one lead; that lead then owned specialist sequencing.
- Executive Secretary は specialist を個別に選び続ける orchestrator ではなく、dominant business outcome に基づいて primary domain lead を選び、relay path を示す top-level router として振る舞うこと
- 組織ルール、AI 組織設定、AI organization governance、Wiroh corporate site 関連は `yui` / `organization-designer` に routing すること
- gorillango product 関連は `ryoma` / `product-manager` に routing すること
- cross-domain または ambiguous な要求では、primary domain lead を 1 つ定め、scope split と依存関係を明示し、ownership choice が outcome を実質的に変える場合だけ CEO に確認することRendering diagram…
Substantive work moved to a Task-first flow in which a Japanese Task record was created before execution. After the CEO approved a domain request, its lead could create a requirements Task without another approval, clarify missing requirements, and split the work into an Epic or User Stories when needed. A requirements Task could stand without a parent User Story, while specialist and implementation Tasks had to link to a parent. Architecture, UI/UX, legal, and implementation work then followed dependency order. Parallel assignments had to share boundaries, inputs, dependencies, expected outputs, merge points, and stop conditions; work depending on unresolved output or editing the same files was not parallelized.
Mako's model and reasoning effort were removed from project-level settings and left to the CEO's choice and the execution environment. Seven custom agents were assigned GPT-5.6 Sol or Terra profiles with high reasoning according to their work, while the open-agent capacity was set to eight threads and maximum delegation depth to four. workspace-write remained in place, and network access was configured only for required destinations. max_depth = 4 allowed four direct handoffs across five subjects, from Mako at depth 0 through a domain lead, Solution Architect, Full-Stack Engineer, and Reviewer at depth 4; separate rules prohibited unbounded recursive delegation. This verified configuration consistency, not comparative model quality, speed, or runtime network enforcement.
Aya's role changed from web-designer to ui-ux-designer. Its scope expanded beyond Web screens to UX research, user journeys, information architecture, interaction, mobile UI, accessibility, design systems, and Figma. Non-trivial product User Stories used Product Manager, UI/UX Designer, and Solution Architect as the default trio. Small work could omit a design or architecture gate only when the reason for marking it not applicable was recorded.
Execution policy separated guarded routine operations from actions requiring CEO judgment. Creating a Task Issue for an approved domain request no longer needed another approval, while merging a Pull Request and force operations remained gated on CEO approval. Direct rm was prohibited. Dedicated wrappers validated arguments and targets for deleting generated artifacts, switching to an existing branch, and non-force pushing the current work branch.
Ritsu's review scope expanded from Pull Request code to non-Ritsu artifacts including Issue and Task drafts, architecture and design notes, legal drafts, workflow documents, agent definitions, and handoff packets. Each request included the artifact, originating role, requirement or completion criteria, dependencies, verification evidence, and review focus. For legal drafts, Ritsu reviewed only process, scope, consistency, evidence, and delivery risk; substantive legal judgment remained with Legal Counsel and CEO legal review.
Across successive independent review rounds, variations in direct rm and force-option spelling or order were found to bypass policy, a path could still push to protected or remote-default branches, incomplete review could appear in a completion report, and parent-Issue rules for requirements and implementation Tasks needed clarification. Mako applied Yui's exact correction packets as a disclosed mechanical relay, aligning rules, wrappers, role definitions, Skills, and operating documents. The work was treated as complete only after Ritsu explicitly passed the revised result.
The CEO finalized model choice, approval boundaries, the role change, and the proposed operating updates. Mako routed the work to Organization Designer, exposed blockers, mechanically relayed exact patch packets when runtime permissions prevented direct application, and consolidated progress and results. Yui designed the organization model, prepared correction packets, and checked cross-file consistency, while Ritsu performed the independent review and re-review.
What was confirmed
Verification results
The final change covered 26 files with 885 additions and 300 deletions. The operating source of truth, custom-agent definitions, repository-local Skills, execution policy, setup documentation, and narrowly scoped wrappers aligned on the same Task-first domain-lead model.
Verification covered parsing the project configuration and seven custom-agent definitions, matching agent count to thread and depth settings, searching for the old role ID and stale routing language, evaluating execution policy, checking wrapper syntax and executable modes, exercising major rejection paths and pre-push fail-closed behavior, and running git diff --check.
Safety and completion-gate findings from independent review were corrected, and the re-review confirmed that no findings remained unaddressed. The change was integrated after CEO approval and the related Task reached its completed state.
Fresh-session activation of the new settings, an actual ui-ux-designer spawn, Task creation by a domain lead, the depth-0-to-4 delegation chain, network allow and deny behavior, auto-review, model availability, and the successful path from remote-default discovery through an actual push were not exercised. The verified scope therefore covered configuration, documentation, policy evaluation, wrapper static and rejection checks, and independent review.
Basis for completion
This Activity was complete when Task-first delegation and consolidation by domain leads, execution-environment model selection for Mako, the expanded UI/UX role, narrowly scoped wrappers and approval gates, and independent review of all non-Ritsu artifacts were reflected consistently across 26 files, and both mechanical checks and the post-fix re-review succeeded.