@danmoisan/drm-copilot-mcp 0.0.1 → 0.0.6

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

@@ -1,10 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- Rewrite merged standing-guidance source paths to the native AGENTS.md target.
-- Rewrite Claude skill paths to shared skill paths.
-- Rewrite Claude rules-directory references to the native skill root.
-
 ---
 name: orchestrate
 description: Route a repository request through the deterministic orchestration workflow for feature, bug, research, planning, execution, and review handoffs.
@@ -15,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:
@@ -30,6 +34,152 @@ On every invocation, the main session must:
 1. Read `artifacts/orchestration/orchestrator-state.json` to check for existing state.
 2. If a valid checkpoint exists with a matching objective, resume from the recorded `next_step`.
 3. If no checkpoint exists or the objective is new, begin the orchestration lifecycle from the start.
+4. Read `config/orchestration-routing.json` before route selection and copy the
+   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
+orchestrator-state validator exposed through the `drm-copilot` MCP server, not
+a Codex lifecycle hook. Before any DONE transition, PR creation gate, or final
+completion report, the orchestrator must validate the canonical checkpoint with
+`validate_orchestration_artifacts` on the `drm-copilot` MCP server using
+`artifact_type: "orchestrator-state"`,
+`artifact_path: "artifacts/orchestration/orchestrator-state.json"`, and
+`require_complete: true`.
+
+There is no fallback. If the MCP server or validation tool is unavailable, or
+if validation fails, the orchestrator must update blocked state and stop rather
+than reporting completion.
+
+The repository CI gate `Orchestrator State Gate` runs the same validator when a
+checkpoint is present. Branch protection should require this check for branches
+that use orchestrated completion.
+
+Completion validation requires the checkpoint to prove mandatory handoffs and
+skill use. The checkpoint must include:
+
+- `route_id`: the selected route key from `config/orchestration-routing.json`
+- `required_agents`: exactly the selected route's `required_agents`
+- `required_skills`: exactly the selected route's `required_skills`
+- `required_mcp_tools`: exactly the selected route's `required_mcp_tools`
+- `delegation_receipts`: one receipt for each required agent
+- `skill_receipts`: one required receipt for each required skill, with evidence
+- `mcp_call_receipts`: one successful receipt for each required MCP tool
+- `local_execution_overrides`: an empty list at completion
+- `delegation_bypasses`: an empty list at completion
+- `lifecycle_operations`: any lifecycle operation must record `surface: "mcp"`
+
+If any required handoff, skill receipt, MCP receipt, or empty bypass list is
+missing, `validate_orchestration_artifacts --require-complete` fails and the
+orchestrator must not report DONE.
+
+## Autonomous-Execution Mandate
+
+The orchestrator must achieve all actions agentically with no unrecorded manual
+dependency. Every unautomatable requirement must be detected early, resolved by
+exactly one of the permitted responses below, and recorded in checkpoint state
+under `human_interaction.requirements[]`.
+
+Permitted responses:
+
+- `scope_change`: change scope to remove the manual dependency.
+- `exception`: permit an exception only when a runbook exists and its path is
+  recorded in `runbook_path`.
+- `halt`: halt until further instruction. A `halt` blocks DONE while present.
+
+The checkpoint validator enforces the `human_interaction` invariants. An
+unresolved response, invalid response value, `halt`, or exception without an
+existing runbook path blocks completion.
 
 ## Delegation Model
 
@@ -37,12 +187,38 @@ 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
-- `commit-steward` — writes commit messages from commit-context 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
+- `epic-review` — reviews epic-level artifacts when the work item is an epic
+- `status-updater` — produces status update artifacts when the workflow requires status synchronization
+- `python-typed-engineer` — performs delegated Python implementation work
+- `powershell-typed-engineer` — performs delegated PowerShell implementation work
+- `csharp-typed-engineer` — performs delegated C# implementation work
+- `typescript-engineer` — performs delegated TypeScript implementation work
+- `commit-steward` — writes commit messages from commit-context artifacts
 
 The orchestrator does not perform deep implementation itself. It coordinates, tracks state, and enforces completion.
 
+Every worker listed above must exist as a native Codex agent under `.codex/agents/`.
+For required delegated steps, missing agent configuration, failed spawn, missing
+receipt, or missing required artifact output is a hard block. The orchestrator
+must persist blocked state and stop rather than performing that step locally.
+
+Every required skill listed in the selected route must be acknowledged in
+`skill_receipts[]` with:
+
+- `skill`
+- `required: true`
+- `acknowledged_at_phase`
+- `evidence`
+
+The evidence value must point to objective evidence: a checkpoint field, MCP
+receipt, artifact path, validator output, or test result. A bare narrative
+statement is not sufficient.
+
 ## Evidence Location Authority
 
 All evidence artifacts produced during orchestration MUST comply with the canonical scheme defined in `.agents/skills/evidence-and-timestamp-conventions/SKILL.md`. Evidence MUST be written to `<FEATURE>/evidence/<kind>/` only.
@@ -66,22 +242,24 @@ The orchestrator must not report completion until:
 1. All required artifacts for the selected workflow path are present on disk.
 2. All validation gates (toolchain, acceptance criteria, audit artifacts) have passed.
 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.
@@ -96,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.
@@ -105,34 +283,44 @@ 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.`
 
 If a subagent artifact references a different issue number, the orchestrator rejects it, requests correction, and records the discrepancy under `artifact_errors` in the checkpoint.
 
+## CI Green Gate
+
+Before PR/DONE completion, the orchestrator must observe the live PR head SHA
+and required GitHub checks through `gh`. The checkpoint must record the checked
+head SHA and CI result. DONE is blocked unless the required checks pass for the
+current PR head SHA.
+
 ## PR Creation Gate
 
 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).
 4. The checkpoint `next_step` is `S8_create_pr`.
+5. The required CI checks pass for the current PR head SHA.
 
 This gate is non-negotiable. Each condition is independently verified before PR creation proceeds.
 
 ## 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-state/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: orchestrator-state
+description: Orchestrator-state remediation-cycle and human-interaction invariants.
+---
+
+# Converted rule
+
+Source: legacy Claude rule `orchestrator-state`.
+
+# Orchestrator-State Remediation-Cycle and Human-Interaction Invariants
+
+This rule governs remediation-cycle records and the optional `human_interaction` block in the orchestrator-state checkpoint at `artifacts/orchestration/orchestrator-state.json`. It documents three invariants that must hold for each remediation cycle, plus three invariants for the `human_interaction` block, so that resume and review workflows do not depend on a structurally invalid checkpoint.
+
+## Foreign Schema Warning (do not copy verbatim)
+
+A hardened snapshot from another repository contains a JSON Schema for the orchestrator-state artifact whose `$id` references a foreign origin (`drmoisan.github.io/mix-calculator/`). That schema MUST NOT be copied verbatim into this repository: its `$id`, its top-level required-field set, and its cycle-level `additionalProperties: false` do not match this repository's checkpoint contract. The invariants below are re-expressed here as prose and enforced by validator logic in `scripts/dev_tools/validate_orchestrator_state.py`, not by importing a foreign schema file.
+
+This prohibition is specific to the disqualified foreign schema identified by the `drmoisan.github.io/mix-calculator/` `$id`. A schema whose `$id` is repo-local and whose required-field set and `additionalProperties` policy match this repository's checkpoint contract is not the disqualified foreign artifact; even so, the repository's enforcement mechanism remains the Python validator prose-and-logic above, not an imported schema file.
+
+## Scope and Backward Compatibility
+
+These invariants apply only when the checkpoint contains a top-level `remediation_loop` with a `cycles` array. A checkpoint with no `remediation_loop` (the existing step-based checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive.
+
+## Invariants (per remediation cycle)
+
+1. **Non-empty `plan_path`.** Each cycle's `plan_path` must be a non-empty string. A missing value, a non-string value, or an empty/whitespace-only string is a malformed cycle.
+
+2. **Execution requires cleared preflight.** A cycle's `execution_status` may be in `{in_progress, complete, failed}` only when that cycle's `preflight.final_status` is exactly `'clear'`. Any other preflight status with one of those execution statuses is a malformed cycle (execution was recorded before preflight cleared).
+
+3. **Exit gate requires zero blocking findings.** When a cycle's `exit_condition_met == true`, its `blocking_count` must be `0`. A non-zero `blocking_count` with `exit_condition_met == true` is a malformed cycle (the exit gate was marked satisfied while blocking findings remained).
+
+## Human-Interaction Scope and Backward Compatibility
+
+These invariants apply only when the checkpoint contains a top-level `human_interaction` block. A checkpoint with no `human_interaction` key (the existing checkpoint shape) is unaffected: it validates exactly as before and produces no new errors. The invariants are additive and support the autonomous-execution mandate documented in `.agents/skills/orchestrate/SKILL.md`.
+
+## Invariants (human_interaction block)
+
+1. **Required `requirements` list.** When `human_interaction` is present, it must be an object containing a `requirements` list. A non-object `human_interaction`, or a `requirements` value that is not a list, is a malformed block.
+
+2. **Per-requirement `response` enum membership.** Each requirement must be an object whose `response` value is one of `scope_change`, `exception`, or `halt`. A requirement that is not an object, or whose `response` is outside this enum, is a malformed requirement.
+
+3. **Exception requires `runbook_path`.** A requirement whose `response == "exception"` must carry a non-empty `runbook_path` string. A missing, non-string, or empty/whitespace-only `runbook_path` on an `exception` requirement is a malformed requirement.
+
+## Enforcement
+
+- `scripts/dev_tools/validate_orchestrator_state.py` appends one error per violated invariant when a `remediation_loop` is present, using the existing validator message style (literal, checkpoint-context prefixed). The validator returns a list of error strings and does not mutate its input.
+- `scripts/dev_tools/validate_orchestrator_state.py` likewise appends one error per violated `human_interaction` invariant when a `human_interaction` key is present, using the same literal, checkpoint-context-prefixed message style. The check does not import or read any schema file.
+- The validator is consumed by the MCP tool `validate_orchestration_artifacts`; backward compatibility for existing step-based checkpoints is preserved.

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

@@ -30,11 +30,22 @@ Use as needed:
 - Required delegated specialists:
   - `atomic-planner`
   - `atomic-executor`
+  - `feature-review`
   - `feature-reviewer`
+  - `task-researcher`
+  - `prd-feature`
+  - `staged-review`
+  - `epic-review`
+  - `status-updater`
+  - `python-typed-engineer`
+  - `powershell-typed-engineer`
+  - `csharp-typed-engineer`
+  - `typescript-engineer`
   - `commit-steward`
 - Deterministic availability rule:
-  - if the host exposes `spawn_agent`, treat all four required delegated specialists as available,
+  - if the host exposes `spawn_agent` and the required `.codex/agents/<name>.toml` file exists, treat that delegated specialist as available,
   - do not infer unavailability from missing nicknames, missing prior agent instances, or lack of a dedicated launcher alias.
+- Every required delegated specialist must exist as a native Codex agent under `.codex/agents/`. If a required agent file is missing, set `blocked_reason` to `spawn_agent_unavailable` and stop.
 - Required delegated steps MUST delegate or stop execution.
 - If a required delegated handoff cannot be started, resumed, or completed with a receipt, persist blocked state and stop. Do not perform that step directly.
 - Direct local execution is allowed only for workflow steps that are not designated below as required delegated handoffs.
@@ -44,12 +55,18 @@ Use as needed:
 Canonical checkpoint path:
 - `artifacts/orchestration/orchestrator-state.json`
 
+Canonical route matrix:
+- `config/orchestration-routing.json`
+
 Persist and reuse these fields exactly:
 - `objective`
 - `change_budget_estimate`
 - `path_selected`
 - `promotion-type`
 - `short-name`
+- `pre-issue-branch`
+- `final-branch`
+- `branch-rename-status`
 - `relativeFile`
 - `long-name`
 - `issue-num`
@@ -73,6 +90,16 @@ Persist and reuse these fields exactly:
 - `step10_status`
 - `delegation_receipts`
 - `blocked_reason`
+- `route_id`
+- `required_agents`
+- `required_skills`
+- `required_mcp_tools`
+- `skill_receipts`
+- `mcp_call_receipts`
+- `local_execution_overrides`
+- `delegation_bypasses`
+- `lifecycle_operations`
+- `pre-implementation-violation`
 
 For small-path runs, also persist:
 - `bootstrap_mode`
@@ -103,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:
@@ -115,6 +151,32 @@ Delegation receipt schema:
   - `result_signal`
   - `artifact_paths`
 
+Skill receipt schema:
+- `skill_receipts` MUST be a list of objects with:
+  - `skill`
+  - `required`
+  - `acknowledged_at_phase`
+  - `evidence`
+
+MCP receipt schema:
+- `mcp_call_receipts` MUST be a list of objects with:
+  - `tool`
+  - `ok`
+  - `evidence`
+
+Completion-state invariants:
+- `route_id` MUST identify an entry in `config/orchestration-routing.json`.
+- `required_agents`, `required_skills`, and `required_mcp_tools` MUST exactly
+  match the selected route matrix entry.
+- every required agent MUST have a matching `delegation_receipts[].agent_name`.
+- every required skill MUST have a matching required `skill_receipts[].skill`
+  with non-empty evidence.
+- every required MCP tool MUST have a successful `mcp_call_receipts[].tool`
+  receipt with non-empty evidence.
+- `local_execution_overrides` and `delegation_bypasses` MUST be empty lists at
+  completion.
+- every recorded `lifecycle_operations[]` item MUST use `surface: "mcp"`.
+
 Required-delegation step map:
 - small path:
   - Step 5 -> `atomic-planner`
@@ -170,6 +232,9 @@ If an exact signal or required path field is missing, set the relevant step to `
 4. If the scope is primarily PowerShell, use `powershell-change-budget-router`.
 5. If the scope is mixed-language, ambiguous, or unsupported by an existing change-budget router, fail closed to the large path.
 6. Treat any request outside the applicable small-path budget as large path.
+7. Select `route_id` from `config/orchestration-routing.json` and persist the
+   exact required agent, skill, and MCP lists from the matrix before starting
+   lifecycle automation.
 
 ## Small Path
 
@@ -181,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
@@ -199,7 +266,8 @@ Required behavior:
 7. Spawn `atomic-executor` to execute Phase 0 only.
    - Record a delegation receipt and set `step6_status` to `verified` before branching
    - If the handoff cannot be started or does not return a receipt, set `step6_status` to `blocked`, set `blocked_reason`, and stop
-8. If the request is manual bootstrap, persist the resume checkpoint and stop after Phase 0.
+8. If and only if the initial user request explicitly opted into manual orchestration from the beginning, persist the resume checkpoint and stop after Phase 0.
+   - Otherwise manual bootstrap is prohibited; continue automated execution.
 9. Otherwise continue with constrained implementation:
    - steps that are not modeled as required delegated handoffs may execute directly while staying within the approved plan and applicable repo policy
 10. Validate the delivered work against `${feature-folder}/issue.md` and persist plan or acceptance-criteria checkoffs before review.
@@ -227,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
@@ -287,10 +357,15 @@ Do not claim mission completion until all of the following are true:
 
 - the selected path completed end to end
 - all required delegations completed with receipts
+- all required skills have `skill_receipts` with evidence
+- all required MCP tools have successful `mcp_call_receipts`
+- no local execution override or delegation bypass is recorded
 - the checkpoint is updated with the final state
 - 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
@@ -299,6 +374,8 @@ Do not claim mission completion until all of the following are true:
 - any required remediation artifacts exist on disk and the latest re-review is clean
 - any required remediation loop run also includes a remediation execution receipt, a remediation commit receipt, and a final `REVIEW_STATUS: PASS`
 - validator-backed checks for the approved plan, policy audit, code review, feature audit, and checkpoint state pass
+- the canonical checkpoint passes `validate_orchestration_artifacts` with `artifact_type: "orchestrator-state"` and `require_complete: true`
+- required GitHub checks pass for the current PR head SHA before PR/DONE completion
 
 ## Hard Constraints
 
@@ -308,10 +385,17 @@ 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.
 - Do not accept stale PR-context artifacts, unsupported checklist checkoffs, or missing required evidence as PASS outcomes.
+- Do not treat Codex lifecycle hooks as the hard completion boundary; use deterministic validator and CI gates for completion enforcement.
 - Do not claim completion without reporting the checkpoint path and the created or updated artifact paths.

package/resources/codex-and-agents-customizations/.agents/skills/policy-audit-template-usage/SKILL.md

@@ -1,8 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
 name: policy-audit-template-usage
 description: 'Policy audit template usage and output requirements. Use when creating policy-audit.<timestamp>.md artifacts from the repo templates.'
@@ -20,13 +15,13 @@ Use this skill when:
 
 ## Template Source
 
-- Required template source: the MCP server tool `mcp__drmCopilotExtension__resolve_policy_audit_template_asset` with asset selector `template`.
+- Required template source: the MCP server tool `mcp__drm-copilot__resolve_policy_audit_template_asset` with asset selector `template`.
 - The resolved MCP asset is authoritative even when a matching repo file also exists.
 - If MCP asset resolution fails, create a minimal policy audit artifact marked BLOCKED and document the missing template resolution.
 
 ## Required Steps
 
-1) Resolve the policy-audit template through the MCP server tool `mcp__drmCopilotExtension__resolve_policy_audit_template_asset` with asset `template`, then copy the resolved asset to the target location using an ISO-8601 timestamp.
+1) Resolve the policy-audit template through the MCP server tool `mcp__drm-copilot__resolve_policy_audit_template_asset` with asset `template`, then copy the resolved asset to the target location using an ISO-8601 timestamp.
 2) Replace placeholders with actual values (component, date, files under test, commits).
 3) Remove any template usage instructions per template guidance.
 4) Mark each section PASS/FAIL/N/A using the template’s expected conventions.
@@ -44,7 +39,7 @@ Use this skill when:
    - `## 10. Compliance Verdict`
    - `## Appendix A: Test Inventory`
    - `## Appendix B: Toolchain Commands Reference`
-6) Run the `mcp__drmCopilotExtension__validate_orchestration_artifacts` MCP tool with `artifact_type: "policy-audit"` and `artifact_path: <path>` and fail closed on any non-zero result.
+6) Run the `mcp__drm-copilot__validate_orchestration_artifacts` MCP tool with `artifact_type: "policy-audit"` and `artifact_path: <path>` and fail closed on any non-zero result.
 
 ## Invalid Outputs
 

package/resources/codex-and-agents-customizations/.agents/skills/policy-compliance-order/SKILL.md

@@ -1,13 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- Rewrite merged standing-guidance source paths to the native AGENTS.md target.
-- Rewrite merged standing-guidance source paths to the native AGENTS.md target.
-- Rewrite merged standing-guidance source paths to the native AGENTS.md target.
-- Rewrite GitHub Copilot instruction-directory references to the native skill root.
-- Rewrite Claude rule paths to shared skill paths.
-- Rewrite Claude rules-directory references to the native skill root.
-
 ---
 name: policy-compliance-order
 description: 'Repository policy compliance order and hard constraints. Use when an agent must read mandatory policy files, apply repo-wide constraints, or restate policy precedence without duplicating blocks across agents.'

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

@@ -1,9 +1,5 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
+name: powershell
 paths:
   - "**/*.ps1"
   - "**/*.psm1"
@@ -17,10 +13,10 @@ This rule file summarizes the PowerShell-specific policies for this repository.
 
 ## Toolchain
 
-1. **Formatting — Invoke-Formatter**: Format all PowerShell files via PoshQC. MCP command: `mcp__drmCopilotExtension__run_poshqc_format`
-2. **Linting — PSScriptAnalyzer**: Run PoshQC analyzer with repo settings. MCP command: `mcp__drmCopilotExtension__run_poshqc_analyze`. Optional autofix: `mcp__drmCopilotExtension__run_poshqc_analyze_autofix`
+1. **Formatting — Invoke-Formatter**: Format all PowerShell files via PoshQC. MCP command: `mcp__drm-copilot__run_poshqc_format`
+2. **Linting — PSScriptAnalyzer**: Run PoshQC analyzer with repo settings. MCP command: `mcp__drm-copilot__run_poshqc_analyze`. Optional autofix: `mcp__drm-copilot__run_poshqc_analyze_autofix`
 3. **Type checking**: Not applicable for PowerShell; skip to testing.
-4. **Testing — Pester (v5.x)**: Run tests via MCP. MCP command: `mcp__drmCopilotExtension__run_poshqc_test`. Use repo config at `scripts/powershell/PoshQC/settings/pester.runsettings.psd1`.
+4. **Testing — Pester (v5.x)**: Run tests via MCP. MCP command: `mcp__drm-copilot__run_poshqc_test`. Use repo config at `scripts/powershell/PoshQC/settings/pester.runsettings.psd1`.
 
 Run the toolchain in order: format → analyze → test. Restart from step 1 if any step fails or changes files. Use the MCP server functions; do not substitute VS Code task wrappers.