@danmoisan/drm-copilot-mcp 0.0.5 → 0.0.6

package/resources/codex-and-agents-customizations/.agents/skills/feature-promotion-lifecycle/SKILL.md

@@ -29,7 +29,10 @@ If the required MCP tools are unavailable, stop before potential-entry creation,
 
 ## Agent-Session Promotion Execution Rule
 
-Execute the lifecycle only through the MCP tool forms listed above. The MCP path is the sole authoritative execution path for agent sessions.
+Execute MCP-backed lifecycle operations only through the MCP tool forms listed
+above. The MCP path is the sole authoritative execution path for potential
+entry creation, issue promotion, and active feature folder creation in agent
+sessions.
 
 After each successful promotion operation, persist the raw MCP receipt payload under the matching checkpoint key in `artifacts/orchestration/orchestrator-state.json`:
 - `delegation_receipts.promotion.potential_entry`
@@ -38,6 +41,11 @@ After each successful promotion operation, persist the raw MCP receipt payload u
 
 Each `delegation_receipts.promotion.*` field stores the raw MCP receipt payload returned by the corresponding promotion operation without lossy normalization.
 
+Branch creation and branch rename are required lifecycle sequencing evidence,
+but they are not `surface: "mcp"` lifecycle operations unless a future MCP tool
+exists for those branch operations. Record branch creation and branch rename as
+branch/checkpoint evidence in `artifacts/orchestration/orchestrator-state.json`.
+
 Note: VS Code command-palette commands may exist for interactive extension use, but this note is non-authoritative for agent sessions.
 
 ## Canonical Variables
@@ -51,6 +59,8 @@ Note: VS Code command-palette commands may exist for interactive extension use,
 - `${plan-path}`: single canonical plan file path reused across planning and preflight revisions
 - `${work-mode}`: `minor-audit`, `full-feature`, or `full-bug` (legacy `full` is accepted only as an alias for `full-feature`)
 - `${short-path-flag}`: `--work-mode minor-audit` (mandatory for short-path promotion/folder creation)
+- `${pre-issue-branch}`: `${promotion-type}/${short-name}`, created or verified before issue creation
+- `${final-branch}`: `${promotion-type}/${short-name}-${issue-num}`, created by branch rename after promotion returns a numeric issue number
 
 `${relativeFile}` MUST resolve to a real potential markdown path before promotion begins. If the path is missing, invalid, or non-markdown, stop. Do not infer or synthesize the missing value.
 
@@ -62,37 +72,44 @@ Lifecycle guardrails:
 - `${relativeFile}` MUST resolve to a real potential markdown path before promotion.
 - `${issue-num}` MUST be numeric after promotion and before branch or folder creation.
 - Do not infer or synthesize the missing value.
-- If `${relativeFile}` or `${issue-num}` is missing, placeholder text, or unverified, stop before branch creation, active-folder creation, or active-folder authoring.
+- If `${relativeFile}` or `${issue-num}` is missing, placeholder text, or unverified, stop before final branch rename, active-folder creation, or active-folder authoring.
 
 1) Use the same MCP tool-availability preflight described above and continue only when the required promotion tools are available.
 
-2) Promote the potential document through `mcp__drm-copilot__potential_to_issue` with `work_mode=minor-audit`.
+2) Verify route metadata readiness in `artifacts/orchestration/orchestrator-state.json`, including selected `route_id`, required route metadata, and `${work-mode}`.
+
+3) Create or verify the pre-issue branch:
+- `${pre-issue-branch}`
+
+4) Create the potential entry through `mcp__drm-copilot__new_potential_entry` or `mcp__drm-copilot__new_potential_bug_entry`.
+
+5) Promote the potential document through `mcp__drm-copilot__potential_to_issue` with the selected `${work-mode}` and capture the numeric `${issue-num}`.
 
-3) Create branch:
-- `${promotion-type}/${short-name}-${issue-num}`
+6) Rename the branch to the final branch:
+- `${final-branch}`
 
-4) Create the active feature folder through `mcp__drm-copilot__new_active_feature_folder` with `work_mode=minor-audit`.
+7) Create the active feature folder through `mcp__drm-copilot__new_active_feature_folder` with the selected `${work-mode}`.
 
-4a) Verify minor-audit folder integrity before proceeding:
+7a) Verify minor-audit folder integrity before proceeding:
 - `${feature-folder}/issue.md` exists and contains `- Work Mode: minor-audit`
 - `${feature-folder}/issue.md` contains an explicit `## Acceptance Criteria` section
 - `${feature-folder}/spec.md` does not exist
 - `${feature-folder}/user-story.md` does not exist
 - if any check fails, stop and remediate before planning
 
-5) Delegate minimal-audit plan creation to `atomic_planner` with directive:
+8) Delegate minimal-audit plan creation to `atomic_planner` with directive:
 - `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
 
-5a) Resolve and persist `${plan-path}` before delegation:
+8a) Resolve and persist `${plan-path}` before delegation:
 - reuse the earliest existing `plan*.md` in `${feature-folder}` when present
 - otherwise create exactly one canonical plan file path and reuse it for all revisions
 
-6) Require preflight validation via `atomic_executor` until:
+9) Require preflight validation via `atomic_executor` until:
 - `PREFLIGHT: ALL CLEAR`
 
-7) Execute plan Phase 0 only via executor and checkpoint evidence.
+10) Execute plan Phase 0 only via executor and checkpoint evidence.
 
-8) Branch:
+11) Branch:
 - manual bootstrap: save state and stop ONLY when the initial user request explicitly opted into manual orchestration from the beginning,
 - non-bootstrap: continue with constrained small-path development.
 
@@ -100,7 +117,7 @@ Automation rule:
 - do not introduce manual bootstrap, human-operator validation, or any other manual handoff later in orchestration unless that initial explicit opt-in exists
 - if automation cannot proceed, record blocked automated state instead of asking for manual intervention
 
-9) Validate delivery via executor against `issue.md`, then run reduced audit/remediation loop until ready-to-merge.
+12) Validate delivery via executor against `issue.md`, then run reduced audit/remediation loop until ready-to-merge.
 
 ## Required Outputs for Downstream Handoffs
 

package/resources/codex-and-agents-customizations/.agents/skills/orchestrate/SKILL.md

@@ -8,6 +8,17 @@ argument-hint: "[objective]"
 
 This skill frames work for the already-active main session, which serves as the orchestrator runtime for end-to-end feature or bug delivery.
 
+## Entry-Point Contract
+
+The already-active main session is the canonical orchestrator runtime for this
+skill. Optional orchestrator profiles, agent configuration files, or named
+profiles are configuration aids only; they do not replace the active
+main-session orchestration contract.
+
+The main session owns route selection, checkpoint updates, lifecycle sequencing,
+delegation decisions, and completion gating unless a required workflow step is
+explicitly delegated by this skill or by `orchestrator-workflow`.
+
 ## Prerequisites
 
 Before proceeding, the orchestrator must:
@@ -27,6 +38,94 @@ On every invocation, the main session must:
    selected route's required agents, skills, and MCP tools into checkpoint
    state.
 
+## Read-Only Intake and Route Selection Gate
+
+Before any lifecycle MCP call, the main session must complete a read-only scope
+assessment. This gate is the read-only scope assessment for orchestration
+intake. It includes policy reads, checkpoint reads, route config reads,
+objective and scope assessment, language/file assessment, route selection, and
+route metadata persistence.
+
+The route-selection gate must be complete before calling any of:
+
+- `new_potential_entry`
+- `new_potential_bug_entry`
+- `potential_to_issue`
+- `new_active_feature_folder`
+
+Until this gate is complete, the main session may read repository files and
+checkpoint state, but must not create lifecycle entries, promote issues, create
+active feature folders, edit implementation files, run formatters or tests,
+stage files, commit files, or delegate implementation.
+
+## Route-Derived Work Mode
+
+The main session must derive `${work-mode}` from the selected route before
+lifecycle automation starts:
+
+- small route -> `minor-audit`
+- large feature route -> `full-feature`
+- large bug route -> `full-bug`
+
+The selected `route_id`, exact route metadata, and derived `${work-mode}` must
+be persisted in `artifacts/orchestration/orchestrator-state.json` before any
+lifecycle MCP call or implementation action. Route metadata must include the
+selected route's `required_agents`, `required_skills`, and
+`required_mcp_tools` copied from `config/orchestration-routing.json`.
+
+## Lifecycle Branch Sequencing
+
+After route metadata is persisted and before potential entry creation, the main
+session must create or verify a slug-only pre-issue branch:
+
+- `${pre-issue-branch}`: `${promotion-type}/${short-name}`
+
+The pre-issue branch must be derived only from `${promotion-type}` and
+`${short-name}` because no numeric issue number exists yet. The main session
+must create or verify this branch before calling `new_potential_entry` or
+`new_potential_bug_entry`.
+
+After potential entry creation, `potential_to_issue` must return a numeric
+`${issue-num}` before the main session renames the branch to the final issue
+branch:
+
+- `${final-branch}`: `${promotion-type}/${short-name}-${issue-num}`
+
+The branch rename to `${final-branch}` must complete before calling
+`new_active_feature_folder`.
+
+## Pre-Implementation Gate
+
+The pre-implementation gate must pass before any edits, formatters, tests,
+staging, commits, or implementation delegation. This gate covers edits, formatters, tests, staging, commits, and implementation delegation. The main session must verify and persist all of the following before implementation can begin:
+
+- checkpoint route metadata is present and matches the selected route;
+- selected `${work-mode}` is present and matches the selected route;
+- lifecycle readiness is complete for the selected path;
+- branch state records `${pre-issue-branch}`, `${final-branch}`, and branch
+  rename status where lifecycle setup is required;
+- required MCP receipts exist for completed lifecycle operations.
+
+If any required item is missing, implementation is blocked until the checkpoint
+and lifecycle state are corrected.
+
+## Pre-Implementation Violation Handling
+
+If an implementation action is attempted before a required orchestration gate
+passes, the main session must stop implementation and persist a blocked
+checkpoint state. The required checkpoint outcome is blocked checkpoint state.
+The checkpoint or companion artifact must record:
+
+- violated gate name;
+- attempted action;
+- known mutated files, if any;
+- corrective next step;
+- current route metadata, lifecycle, branch, and MCP receipt state.
+
+After a pre-implementation gate violation, the main session must not continue
+implementation. It may only record the violation, restore or reconcile state
+when policy permits, and resume from the corrective orchestration step.
+
 ## Hard Enforcement Boundary
 
 The hard completion boundary for Codex orchestration is the deterministic
@@ -88,7 +187,8 @@ After reading `artifacts/orchestration/orchestrator-state.json`, the main sessio
 
 - `atomic-planner` — generates phased implementation plans
 - `atomic-executor` — executes approved plans task-by-task
-- `feature-review` — produces policy, code, and feature audit artifacts
+- `feature-reviewer` — produces policy, code, and feature audit artifacts by
+  applying the `feature-review` workflow skill
 - `task-researcher` — performs deep research and writes findings to `artifacts/research/`
 - `prd-feature` — produces issue, specification, and user-story artifacts when required by the selected workflow
 - `staged-review` — reviews staged changes when a pre-commit review is required
@@ -144,21 +244,22 @@ The orchestrator must not report completion until:
 3. The checkpoint file at `artifacts/orchestration/orchestrator-state.json` reflects the completed state.
 4. The orchestrator-state validator passes with `--require-complete`.
 
-## Pre-Feature-Review Commit
+## Pre-Review Commit
 
-Before delegating to the `feature-review` subagent, the orchestrator must:
+Before delegating to the `feature-reviewer` agent, the orchestrator must:
 
 1. Stage all modified and new files: `git add -A`.
 2. Run MCP tool `collect_commit_context` and capture the returned on-disk artifact path.
 3. Delegate to `commit_steward` using that commit-context artifact as the authoritative staged-change input.
 4. Commit using the generated message: `git commit -m "<generated message>"`.
-5. Only after a successful commit may the orchestrator proceed to the `feature-review` delegation.
+5. Only after a successful commit may the orchestrator proceed to the
+   `feature-reviewer` delegation.
 
 The review subagent compares against a base branch; uncommitted changes are invisible to the diff tool and cannot be audited.
 
 ## Post-Review Outcome Evaluation
 
-After each `feature-review` delegation returns:
+After each `feature-reviewer` delegation returns:
 
 1. Read the exact terminal status lines from the review result.
 2. If the result does not include `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`, stop and record blocked state.
@@ -173,7 +274,7 @@ A bounded loop consisting of five steps. The loop variable `remediation_pass` st
 - **R2 — Preflight clearance:** Delegate to `atomic-executor` for precondition validation only (no implementation). If the executor does not return `PREFLIGHT: ALL CLEAR`, return to R1 by re-delegating to `atomic-planner` against the same remediation-plan path with the required-changes output from the executor. Only after `PREFLIGHT: ALL CLEAR` may the orchestrator advance to R3.
 - **R3 — Remediation execution:** Delegate to `atomic-executor` with full execution authorization. Each task's toolchain loop (format → lint → type-check → test) is mandatory; no skipping.
 - **Pre-R4 commit:** Stage all changes (`git add -A`), run MCP tool `collect_commit_context`, delegate to `commit_steward` using the resulting artifact, and commit with the generated message. Advance to R4 only after a successful commit.
-- **R4 — Re-audit:** Refresh PR context via MCP tool `collect_pr_context`, then delegate to `feature-review` with the same inputs as the original review (resolved base branch, feature folder, refreshed PR context artifacts, acceptance-criteria source). No scope narrowing. The canonical issue number line must be included.
+- **R4 — Re-audit:** Refresh PR context via MCP tool `collect_pr_context`, then delegate to `feature-reviewer` with the same inputs as the original review (resolved base branch, feature folder, refreshed PR context artifacts, acceptance-criteria source). No scope narrowing. The canonical issue number line must be included.
 - **R5 — Loop-exit decision:** If the re-audit returns `REVIEW_STATUS: PASS`, exit the loop and advance to the PR creation gate. Otherwise, record `remediation_pass` increment in the checkpoint and return to R1.
 
 **Termination guard:** If `remediation_pass` reaches 3 without resolution, the orchestrator records `step6_status: "blocked_remediation_loop_limit"` in the checkpoint and halts. No further automation is attempted.
@@ -182,7 +283,8 @@ A bounded loop consisting of five steps. The loop variable `remediation_pass` st
 
 The canonical issue number is derived once from the active feature folder name: extract the trailing integer from the folder base name (e.g., `2026-04-26-push-down-claude-customizations-162` yields `162`). Record as `issue_num` in the checkpoint.
 
-Every delegation prompt to `atomic-planner`, `atomic-executor`, and `feature-review` must include the line:
+Every delegation prompt to `atomic-planner`, `atomic-executor`, and
+`feature-reviewer` must include the line:
 
 > `Canonical issue number for this feature is <issue_num>. All artifact content, file paths, and cross-references must use this number.`
 
@@ -199,7 +301,8 @@ current PR head SHA.
 
 The orchestrator must not create a PR, push a branch for PR purposes, or report work complete until all four conditions are simultaneously true:
 
-1. `blocking_findings_resolved: true` — the most recent `feature-review` produced zero blocking findings.
+1. `blocking_findings_resolved: true` — the most recent `feature-reviewer`
+   result produced zero blocking findings.
    Equivalent deterministic gate: the latest review returned `REVIEW_STATUS: PASS`.
 2. The AC verification artifact (`p14-acceptance-criteria-checkoff.md` or equivalent) confirms all acceptance criteria pass.
 3. The mandatory toolchain passed in its most recent run on the branch (no linting/type-check/test failures).
@@ -210,14 +313,14 @@ This gate is non-negotiable. Each condition is independently verified before PR
 
 ## Step 6 Delegation — Prohibited Prompt Language
 
-When delegating to the `feature-review` subagent, the orchestrator prompt MUST NOT:
+When delegating to the `feature-reviewer` agent, the orchestrator prompt MUST NOT:
 
 - describe the review scope as "plan scope," "plan-scope only," or any equivalent narrowing of scope to the currently-executed plan;
 - instruct the agent to skip, waive, or mark as "out of scope," "informational only," or "not applicable" any toolchain step or coverage check for a language that has changed files in the branch diff;
 - assert that a language category is "not applicable" when that language has changed files in the branch diff;
 - imply that coverage is not required because the plan scope contains only documentation changes when the branch diff contains non-documentation changes contributed by prior commits on the same branch.
 
-The orchestrator supplies only the following to the `feature-review` subagent:
+The orchestrator supplies only the following to the `feature-reviewer` agent:
 
 - the resolved base branch and merge-base SHA;
 - the active feature folder path;

package/resources/codex-and-agents-customizations/.agents/skills/orchestrator-workflow/SKILL.md

@@ -64,6 +64,9 @@ Persist and reuse these fields exactly:
 - `path_selected`
 - `promotion-type`
 - `short-name`
+- `pre-issue-branch`
+- `final-branch`
+- `branch-rename-status`
 - `relativeFile`
 - `long-name`
 - `issue-num`
@@ -96,6 +99,7 @@ Persist and reuse these fields exactly:
 - `local_execution_overrides`
 - `delegation_bypasses`
 - `lifecycle_operations`
+- `pre-implementation-violation`
 
 For small-path runs, also persist:
 - `bootstrap_mode`
@@ -126,6 +130,15 @@ Blocked-reason enum:
   - `review_status_missing`
   - `commit_context_missing`
   - `no_staged_changes`
+  - `pre_implementation_gate_violation`
+
+Pre-implementation violation schema:
+- `pre-implementation-violation` MUST be either `null` or an object with:
+  - `violated_gate`
+  - `attempted_action`
+  - `known_mutated_files`
+  - `corrective_next_step`
+  - `recorded_at`
 
 Delegation receipt schema:
 - `delegation_receipts` MUST be a list of objects with:
@@ -233,10 +246,12 @@ Required behavior:
 2. Use `feature-promotion-lifecycle` as the source of truth for lifecycle variables, branch naming, and `${plan-path}` resolution.
 3. Route all promotion, issue, and feature-folder automation through `repo-automation-adapter`.
 4. Enforce lifecycle preconditions before any active-folder authoring:
+   - route metadata persistence must be complete in the canonical checkpoint before potential-entry creation
+   - `${pre-issue-branch}` must be created or verified before potential-entry creation
    - `${relativeFile}` must resolve to a real potential markdown path and must not be `NONE`, `TBD`, or empty
-   - issue promotion must complete before branch or folder creation
-   - `${issue-num}` must be numeric before `new_active_feature_folder` runs
-   - do not create or edit `${feature-folder}/issue.md`, `${feature-folder}/spec.md`, `${feature-folder}/user-story.md`, or `plan*.md` until promotion and folder creation both succeed
+   - `${issue-num}` must be numeric before final branch rename or `new_active_feature_folder` runs
+   - final branch rename must complete before `new_active_feature_folder` runs
+   - do not create or edit `${feature-folder}/issue.md`, `${feature-folder}/spec.md`, `${feature-folder}/user-story.md`, or `plan*.md` until potential-entry creation, promotion, final branch rename, and folder creation all succeed
    - if any lifecycle precondition fails, set the relevant step status to `blocked`, set `blocked_reason` to `lifecycle_preconditions_missing`, and stop
 5. Enforce minor-audit folder integrity:
    - `${feature-folder}/issue.md` must exist
@@ -280,10 +295,12 @@ Required behavior:
 2. Use `feature-promotion-lifecycle` as the source of truth for lifecycle variables, branch naming, and `${plan-path}` resolution.
 3. Route all promotion, issue, and feature-folder automation through `repo-automation-adapter`.
 4. Enforce lifecycle preconditions before any active-folder authoring:
+   - route metadata persistence must be complete in the canonical checkpoint before potential-entry creation
+   - `${pre-issue-branch}` must be created or verified before potential-entry creation
    - `${relativeFile}` must resolve to a real potential markdown path and must not be `NONE`, `TBD`, or empty
-   - issue promotion must complete before branch or folder creation
-   - `${issue-num}` must be numeric before `new_active_feature_folder` runs
-   - do not create or edit `${feature-folder}/issue.md`, `${feature-folder}/spec.md`, `${feature-folder}/user-story.md`, or `plan*.md` until promotion and folder creation both succeed
+   - `${issue-num}` must be numeric before final branch rename or `new_active_feature_folder` runs
+   - final branch rename must complete before `new_active_feature_folder` runs
+   - do not create or edit `${feature-folder}/issue.md`, `${feature-folder}/spec.md`, `${feature-folder}/user-story.md`, or `plan*.md` until potential-entry creation, promotion, final branch rename, and folder creation all succeed
    - if any lifecycle precondition fails, set the relevant step status to `blocked`, set `blocked_reason` to `lifecycle_preconditions_missing`, and stop
 5. Complete the requirements-authoring steps before planning:
    - fill the potential entry details
@@ -347,6 +364,8 @@ Do not claim mission completion until all of the following are true:
 - the canonical checkpoint path was used without sidecar replacement or backup substitution
 - `${relativeFile}` is a real promoted-input path and `${issue-num}` is numeric when lifecycle setup was required
 - `${feature-folder}` and `${plan-path}` are known when lifecycle setup was required
+- route metadata, selected work mode, branch state, lifecycle receipts, and
+  folder readiness are present before implementation begins
 - the approved plan is executor-compliant and references the required baseline and final-QA evidence tasks
 - required review artifacts exist on disk
 - small path has Phase 0 evidence plus reduced audit artifacts
@@ -366,8 +385,14 @@ Do not claim mission completion until all of the following are true:
 - Do not bypass `repo-automation-adapter` for host-specific lifecycle steps.
 - Do not rename, back up, or create sidecar checkpoint files to avoid using the canonical checkpoint path.
 - Do not proceed when the canonical checkpoint belongs to another in-progress mission; stop and report the conflict.
-- Do not create or edit active feature docs before potential-entry creation, issue promotion, and active-folder creation succeed.
-- Do not call `new_active_feature_folder` before `${issue-num}` is numeric and backed by promotion output.
+- Do not create or edit active feature docs before route metadata persistence,
+  pre-issue branch setup, potential-entry creation, issue promotion, final branch
+  rename, and active-folder creation succeed.
+- Do not call `new_active_feature_folder` before `${issue-num}` is numeric,
+  backed by promotion output, and the final branch rename is complete.
+- Do not begin implementation edits, formatters, tests, staging, commits, or
+  implementation delegation when route metadata, branch state, lifecycle
+  receipts, or folder readiness are missing.
 - Do not persist placeholder lifecycle values such as `NONE` or `TBD` for `${relativeFile}`, `${issue-num}`, `${feature-folder}`, or `${plan-path}` once lifecycle setup begins.
 - Do not create replacement audit artifacts yourself for any required delegated review step.
 - Do not execute required delegated steps locally as a fallback.

package/resources/codex-and-agents-customizations/.agents/skills/repo-automation-adapter/SKILL.md

@@ -111,13 +111,18 @@ Required tools:
 
 Execute these lifecycle operations as one ordered chain:
 
-1. Create the potential entry.
-2. Promote with `potential_to_issue`.
-3. Capture numeric issue number from promotion output.
-4. Create or check out `${promotion-type}/${short-name}-${issue-num}`.
-5. Create the active feature folder with `new_active_feature_folder`.
-
-`new_active_feature_folder` is not an allowed bootstrap substitute for missing promotion state. If `${issue-num}` is missing, non-numeric, or placeholder text, stop. Do not synthesize GitHub issue state, active-folder scaffolding, or placeholder lifecycle variables.
+1. Verify route metadata and selected `${work-mode}` are persisted in the
+   canonical checkpoint.
+2. Create or verify pre-issue branch `${promotion-type}/${short-name}` before
+   `new_potential_entry` or `new_potential_bug_entry`.
+3. Create the potential entry with `new_potential_entry` or
+   `new_potential_bug_entry`.
+4. Promote with `potential_to_issue`.
+5. Capture numeric issue number from promotion output.
+6. Rename the branch to `${promotion-type}/${short-name}-${issue-num}`.
+7. Create the active feature folder with `new_active_feature_folder`.
+
+`new_active_feature_folder` is not an allowed bootstrap substitute for missing promotion state. If `${issue-num}` is missing, non-numeric, or placeholder text, stop before final branch rename or active folder creation. Do not synthesize GitHub issue state, active-folder scaffolding, or placeholder lifecycle variables.
 
 ### Customization publishing and hard-lock resolution
 

package/resources/codex-and-agents-customizations/.codex/config.toml

@@ -1,4 +1,4 @@
-default_permissions = "orchestrator-workspace"
+default_permissions = ":danger-full-access"
 
 [mcp_servers.drm-copilot]
 command = "npx"
@@ -7,17 +7,24 @@ required = true
 enabled_tools = [
     "collect_commit_context",
     "collect_pr_context",
-    "new_potential_entry",
+    "run_codex_native_converter",
+    "push_down_copilot_customizations",
+    "push_down_codex_and_agents_customizations",
+    "push_down_claude_customizations",
     "new_potential_bug_entry",
+    "new_potential_entry",
+    "link_parent_child",
     "potential_to_issue",
     "new_active_feature_folder",
-    "validate_orchestration_artifacts",
-    "resolve_atomic_plan_prompt",
-    "resolve_execute_hard_lock_prompt",
     "run_poshqc_format",
     "run_poshqc_analyze",
-    "run_poshqc_analyze_autofix",
     "run_poshqc_test",
+    "run_poshqc_analyze_autofix",
+    "run_poshqc_suite",
+    "resolve_policy_audit_template_asset",
+    "resolve_execute_hard_lock_prompt",
+    "resolve_atomic_plan_prompt",
+    "validate_orchestration_artifacts",
 ]
 default_tools_approval_mode = "prompt"
 
@@ -27,6 +34,58 @@ approval_mode = "approve"
 [features]
 multi_agent = true
 
+[[hooks.PreToolUse]]
+matcher = "Bash"
+command = "pwsh -NoProfile -File .codex/hooks/validate-bash.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Bash"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-promotion-mcp-only.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Bash"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-orchestration-preimplementation-gate.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Write|Edit"
+command = "pwsh -NoProfile -File .codex/hooks/check-python-test-purity.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Write|Edit"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-python-batch-budget.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Write|Edit"
+command = "pwsh -NoProfile -File .codex/hooks/check-powershell-test-purity.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Write|Edit"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-powershell-batch-budget.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Write|Edit"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-evidence-locations.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Write|Edit"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-orchestration-preimplementation-gate.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Write|Edit"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-checkpoint-monotonic.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Write|Edit"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-completion-consistency.ps1"
+
+[[hooks.PreToolUse]]
+matcher = "Agent"
+command = "pwsh -NoProfile -File .codex/hooks/enforce-orchestration-preimplementation-gate.ps1"
+
+[[hooks.SubagentStop]]
+matcher = "feature-review|feature-reviewer"
+command = "pwsh -NoProfile -File .codex/hooks/validate-feature-review-coverage.ps1"
+
 [permissions.orchestrator-workspace]
 description = "Workspace editing for deterministic orchestration with secret-path deny rules."
 extends = ":workspace"