FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Making the parent workspace the entry point for organizational governance
Separating organizational rules, child-specific technical information, and repository-specific Git state in documentation
Purpose
The AI organization's rules were managed in a parent workspace that also contained independent child repositories. Opening only a child as the workspace could leave the parent project's settings and organizational rules unapplied, so the starting point for organizational work needed to be unambiguous.
The work also aimed to keep organization-wide governance separate from each child's configuration, commands, environment variables, and deployment procedures, while aligning the rule that branches, working trees, diffs, commits, and remotes must be checked per repository.
Implementation
Three standing rules were added to AGENTS.md: use the parent as the Codex workspace root, treat each child as an independent Git repository, and keep child-specific technical information in each child's project guide and docs/. This separated the entry point for organizational governance from the location of technical specifications and avoided duplicating child-level technical details in the parent instructions.
- Use the parent workspace's
AGENTS.md,.codex/, and.agents/as the entry point for organizational and agent governance. - Consult each child's project guide and
docs/for its configuration, commands, environment variables, and deployment procedures. - Do not treat
git statusorgit diffat the parent root as an aggregate of child changes; inspect branches, working trees, commits, and remotes for each repository.
The same boundary was synchronized into the the root project guide, setup guide, and operating model. Setup instructed readers to open the parent as the workspace root and reload project-scoped settings, rules, hooks, Custom Agents, and Skills after trust was established. The operating model documented the possibility that parent governance would not apply when starting from a child alone and directed AI-organization workflows to begin from the parent.
brand workspace guide and product workspace guide removed the previous instruction to treat a child-level AGENTS.md as supplementary rules. They instead directed technical information to the child's project guide and docs/ and required parent and child Git state to be inspected separately before and after changes, separating location guidance from governance content.
Verification searched the changed documentation for the previous policy, obsolete repository wording, and absolute paths, then used git diff --check to check the patch for whitespace errors. Parent and child branches, working trees, and diffs were inspected separately, and the size of the parent instructions was compared with the configured limit.
The following excerpt from AGENTS.md was checked against the primary Commit diff, with prohibited public identifiers removed or generalized.
## Standing Rules
- Codex は `<workspace-root>` を workspace root として使い、配下の child repository 単体を organization / agent governance の入口にしないこと
- child repository は独立した Git repository として扱い、親子それぞれの branch、working tree、diff、commit、remote、PR を個別に確認すること
- child 固有の構成、コマンド、環境変数、deploy 手順は child の reader-facing and technical guides を参照し、親 `AGENTS.md` に技術詳細を重複させないことRendering diagram…
What was confirmed
Verification results
Across six documents, the parent-workspace entry point for organizational governance, the location of child-specific technical information, and the per-repository Git boundary were aligned to the same policy.
The search for the previous child-AGENTS.md policy and git diff --check succeeded. The parent instructions were 28,279 bytes, within the configured limit of 65,536 bytes.
A final check of the six changed documents confirmed that the parent workspace, child-specific information, and per-repository Git state had consistent responsibility boundaries.
Verification in this work covered the documentation diff, residual searches, instruction size, and repository-specific Git state. It did not test runtime behavior in a fresh Codex session opened from a child alone or any product runtime behavior.
Basis for completion
The documentation work was considered complete when all six documents agreed on the organizational-governance entry point, the location of child-specific technical information, and the method for checking Git state per repository, and when the residual searches, patch check, and instruction-size check succeeded.