@danmoisan/drm-copilot-mcp 0.0.1 → 0.0.5

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

@@ -1,11 +1,6 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
 name: feature-promotion-lifecycle
-description: Deterministic promotion workflow from potential feature/bug entry to issue, branch, active feature folder, and downstream spec/research handoffs. Agent sessions must use the drmCopilotExtension MCP tool surface and record raw promotion receipts under the canonical checkpoint namespace.
+description: Deterministic promotion workflow from potential feature/bug entry to issue, branch, active feature folder, and downstream spec/research handoffs. Agent sessions must use the drm-copilot MCP tool surface and record raw promotion receipts under the canonical checkpoint namespace.
 ---
 
 # Feature Promotion Lifecycle
@@ -22,13 +17,13 @@ Use this skill when:
 
 ## MCP Tool Availability Preflight
 
-Before any promotion step starts, verify that the required `drmCopilotExtension` MCP tools are available in the current agent session.
+Before any promotion step starts, verify that the required `drm-copilot` MCP tools are available in the current agent session.
 
 Required MCP tool set:
-- feature potential entry: `mcp__drmCopilotExtension__new_potential_entry` with `short_name=${short-name}`
-- bug potential entry: `mcp__drmCopilotExtension__new_potential_bug_entry` with `short_name=${short-name}`
-- potential-to-issue promotion: `mcp__drmCopilotExtension__potential_to_issue` with `potential_path=${relativeFile}`, `promotion_type=${promotion-type}`, `work_mode=${work-mode}`
-- active feature folder creation: `mcp__drmCopilotExtension__new_active_feature_folder` with `feature_name=${long-name}`, `type=${promotion-type}`, `issue_number=${issue-num}`, `work_mode=${work-mode}`
+- feature potential entry: `mcp__drm-copilot__new_potential_entry` with `short_name=${short-name}`
+- bug potential entry: `mcp__drm-copilot__new_potential_bug_entry` with `short_name=${short-name}`
+- potential-to-issue promotion: `mcp__drm-copilot__potential_to_issue` with `potential_path=${relativeFile}`, `promotion_type=${promotion-type}`, `work_mode=${work-mode}`
+- active feature folder creation: `mcp__drm-copilot__new_active_feature_folder` with `feature_name=${long-name}`, `type=${promotion-type}`, `issue_number=${issue-num}`, `work_mode=${work-mode}`
 
 If the required MCP tools are unavailable, stop before potential-entry creation, issue promotion, or active-folder creation begins. Restore MCP connectivity first. Agent sessions do not have an approved non-MCP execution branch for promotion work.
 
@@ -71,12 +66,12 @@ Lifecycle guardrails:
 
 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__drmCopilotExtension__potential_to_issue` with `work_mode=minor-audit`.
+2) Promote the potential document through `mcp__drm-copilot__potential_to_issue` with `work_mode=minor-audit`.
 
 3) Create branch:
 - `${promotion-type}/${short-name}-${issue-num}`
 
-4) Create the active feature folder through `mcp__drmCopilotExtension__new_active_feature_folder` with `work_mode=minor-audit`.
+4) Create the active feature folder through `mcp__drm-copilot__new_active_feature_folder` with `work_mode=minor-audit`.
 
 4a) Verify minor-audit folder integrity before proceeding:
 - `${feature-folder}/issue.md` exists and contains `- Work Mode: minor-audit`
@@ -98,9 +93,13 @@ Lifecycle guardrails:
 7) Execute plan Phase 0 only via executor and checkpoint evidence.
 
 8) Branch:
-- manual bootstrap: save state and stop,
+- 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.
 
+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.
 
 ## Required Outputs for Downstream Handoffs

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

@@ -1,8 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
 name: feature-review-workflow
 description: 'Feature-branch review workflow for base-branch resolution, PR-context refresh, active feature folder selection, review artifact generation, validator gates, acceptance-criteria check-off, and remediation triggers. Use when authoring or executing PR-style feature reviews.'
@@ -100,7 +95,7 @@ Always apply:
      5. coverage (mandatory for every language that has changed files)
         - TypeScript: `npm run test:unit:coverage` → artifact: `coverage/lcov.info`
         - Python: `poetry run pytest --cov` → artifact: `artifacts/python/lcov.info`
-        - PowerShell: `mcp__drmCopilotExtension__run_poshqc_test` → artifact: `artifacts/pester/powershell-coverage.xml`
+        - PowerShell: `mcp__drm-copilot__run_poshqc_test` → artifact: `artifacts/pester/powershell-coverage.xml`
         - C#: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage` → artifact: `artifacts/csharp/coverage.xml`
         - Coverage thresholds:
           - New code files (added in this feature): line coverage must be >= 90%. Flag as FAIL otherwise.

package/resources/codex-and-agents-customizations/.agents/skills/fill-feature-docs/SKILL.md

@@ -1,8 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
 name: fill-feature-docs
 description: Invoke the prd-feature worker to produce feature-document outputs from issue and research inputs.

package/resources/codex-and-agents-customizations/.agents/skills/general-code-change/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: general-code-change
+description: Cross-language code change policy for all files.
+paths:
+  - "**"
+description: Cross-language code change policy. Applies to all files.
+---
+
+# Converted rule
+
+Source: legacy Claude rule `general-code-change`.
+
+# General Code Change Policy
+
+This rule file summarizes the cross-language code change policy for this repository.
+
+## Design Principles
+
+Apply these priorities in order when designing or changing code:
+
+1. **Simplicity first** — Prefer the simplest design that works and is readable. Avoid cleverness and deep indirection.
+2. **Reusability** — Factor out logic that is clearly reusable. Avoid copy-paste; share behavior via composition or helper methods.
+3. **Extensibility** — Design public APIs so they can be extended without breaking callers. Prefer keyword-style parameters with defaults. Prefer composition over inheritance. Use interfaces/abstract types/protocols to support multiple implementations.
+4. **Separation of concerns** — Keep pure logic (transforms, calculations, parsing) separate from I/O (disk, network, DB), UI/CLI, and framework-specific glue.
+
+## Classes, Functions, and APIs
+
+- Create a class when: there is a clear domain concept with data + behavior, state and invariants must travel together, multiple implementations behind an interface are expected, or a multi-step workflow shares context.
+- Create a standalone function when: the operation is pure, stateless, and simple; it is a small helper that does not naturally belong on a domain class; or it is a simple transformation from inputs to outputs.
+- Keep methods small and focused. Avoid god objects.
+- Use interfaces/abstract types/protocols when multiple implementations are likely.
+
+## Module Rigor Tiers
+
+Module rigor tiers (T1–T4) and the uniform-versus-tier-dependent gate matrix are defined in `.agents/skills/quality-tiers.md`. Every project must be classified in `quality-tiers.yml` at repo root.
+
+## Mandatory Toolchain Loop
+
+Run the full seven-stage toolchain in this exact order and repeat until all stages pass in a single pass:
+
+1. **Formatting** (e.g., Black, Prettier, CSharpier, Invoke-Formatter)
+2. **Linting** (e.g., Ruff, ESLint, PSScriptAnalyzer, .NET analyzers)
+3. **Type checking** (e.g., Pyright, TSC, nullable analysis; skip for PowerShell)
+4. **Architecture-boundary tests** (e.g., dependency-cruiser, NetArchTest.Rules)
+5. **Unit tests** (e.g., Pytest, Vitest, MSTest, Pester) including property-based tests where applicable per `quality-tiers.md`
+6. **Contract / schema compatibility checks** (e.g., oasdiff, schema-snapshot diff)
+7. **Integration tests**
+
+**Restart from step 1** if any stage fails or auto-fixes any files. Do not stop the loop until all seven stages complete without errors in a single pass.
+
+Mutation testing and golden tests run in pre-merge or nightly pipelines, not the per-commit loop.
+
+## File Size Limit
+
+- No production code, test code, or reusable script file may exceed **500 lines**.
+- Exceptions: temporary throwaway scripts created and deleted within an agent session; raw text fixtures for language-processing test data; Markdown documentation files.
+
+## Error Handling and Logging
+
+- **Fail fast and explicitly**: raise or return clear, specific errors when invariants are violated.
+- Do not silently ignore errors. Do not use broad catch-all handlers unless you immediately re-raise or propagate with added context.
+- Use the project's established logging pattern. Log at appropriate levels (`debug`, `info`, `warning`, `error`).
+- Enforce invariants at construction/initialization time.
+- Use assertions only for internal sanity checks, not user-facing error handling.
+
+## Naming
+
+- Names must be descriptive. Abbreviations are acceptable only when they are standard (`id`, `url`, `db`).
+- Language-specific conventions: `snake_case` for Python functions/variables, `PascalCase` for Python classes, `camelCase` for TypeScript/C# locals, `PascalCase` for TypeScript/C# types and public members.
+
+## Public APIs and Compatibility
+
+- Prefer keyword-style parameters with defaults.
+- Prefer composition over inheritance when possible.
+- Avoid breaking public APIs. If a breaking change is necessary, update all callers in-repo and call it out clearly in the change description.
+
+## Dependencies
+
+- Use only libraries already approved in the project unless explicitly told to add more.
+- If adding a dependency is unavoidable, choose a well-maintained, widely used package and document why it is required.
+
+## I/O Boundaries
+
+- Isolate I/O (disk, network, APIs) into specific classes or modules.
+- Core domain logic must be testable without touching the network or filesystem.
+- Use of temporary files within tests is strictly prohibited.

package/resources/codex-and-agents-customizations/.agents/skills/general-unit-test/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: general-unit-test
+description: Cross-language unit test policy for all files.
+paths:
+  - "**"
+description: Cross-language unit test policy. Applies to all files.
+---
+
+# Converted rule
+
+Source: legacy Claude rule `general-unit-test`.
+
+# General Unit Test Policy
+
+This rule file summarizes the cross-language unit test policy for this repository.
+
+## Core Principles
+
+Every unit test must satisfy all five of these properties:
+
+1. **Independence** — Tests must be able to run in any order without impacting each other.
+2. **Isolation** — Each unit test targets a single function, method, or unit of behavior so failures clearly identify the faulty unit.
+3. **Fast execution** — Tests must be fast enough to support frequent runs and rapid feedback loops.
+4. **Determinism** — Given the same inputs and environment, tests must produce the same results. Avoid flakiness.
+5. **Readability and maintainability** — Test names, structure, and assertions must be clear and easy to understand.
+
+## Coverage Requirements
+
+- **Line coverage must remain >= 85% across all tiers (T1–T4).**
+- **Branch coverage must remain >= 75% across all tiers (T1–T4).**
+- Code changes or refactors must not reduce coverage for the lines that were changed.
+- Tier-specific lower coverage thresholds are not used in this repository. See `.agents/skills/quality-tiers.md` for the full tier system.
+- Coverage is a supporting metric, not the sole quality gate. Untested critical behavior is not acceptable even if the overall percentage looks good.
+- Configure coverage tooling to exclude test files (e.g., `tests/`) so metrics reflect application code, not tests.
+- Type-only / interface-only modules with no executable behavior may be omitted from coverage measurement. Examples: Python `Protocol`-only modules consumed only under `TYPE_CHECKING`, TypeScript interface/type-only files, and C# interface-only files. Such modules legitimately report 0% executable coverage and may be excluded from measurement. This is a clarification only; it does not lower any coverage threshold.
+
+## Coverage Exclusion Policy
+
+No production file may be excluded from coverage measurement. Every production source file is in the denominator of the coverage metric, regardless of whether its lines are reachable in the test environment.
+
+The correct response to a file that contains untestable lines is to refactor it — extract all logic into host-neutral, testable modules and leave only the thinnest possible wiring in the host-bound entry point. The entry point's uncovered lines then represent a real and visible cost in the coverage metric, which creates ongoing pressure to keep those files minimal.
+
+**Permitted `exclude` entries** (non-production paths only):
+- Build output directories: `dist/**`, `lib/**`, `lib-amd/**`.
+- Test files and test infrastructure: `**/*.test.ts`, `tests/**`, `src/test-support/**`.
+- Config files that are not production code: `vitest.config.ts`, `eslint.config.mjs`, `.dependency-cruiser.cjs`, `webpack.config.js`.
+- `node_modules/**`.
+
+**Prohibited `exclude` entries:**
+- Any path under `src/` that contains production runtime code, regardless of whether it is auto-generated, host-bound, or difficult to test.
+
+**Enforcement:** Feature-review agents must treat any `exclude` entry that matches a production source path as a **Blocking** finding.
+
+## Scenario Completeness
+
+For each unit or behavior, tests must cover:
+
+- Positive flows with valid inputs
+- Negative flows for invalid or missing inputs
+- Edge cases and boundary conditions
+- Error-handling behavior
+- Concurrency behavior when relevant
+- State transitions for stateful components
+
+## Test Structure — Arrange–Act–Assert
+
+Organize each test into three sections:
+
+- **Arrange** — set up inputs, environment, and dependencies
+- **Act** — execute the behavior under test
+- **Assert** — verify outcomes via assertions
+
+Assertions must produce clear, actionable failure messages.
+
+## External Dependencies
+
+- Unit tests must not depend on external services (databases, networks, remote APIs, external processes).
+- Use mocks, stubs, or fakes to isolate the unit under test when code interacts with external systems.
+- **Creation and use of temporary files in tests is strictly prohibited.**
+- Tests must not rely on mutable global state or external configuration that can change between runs.
+
+## Test File Location
+
+Test files must live in a `tests/` directory tree that mirrors the production source structure. The test for `src/foo/bar.ts` belongs at `tests/foo/bar.test.ts`; the test for `scripts/powershell/Foo.ps1` belongs at `tests/scripts/powershell/Foo.Tests.ps1`. Language-specific rules may add further naming conventions (framework suffix, file extension) on top of this universal layout requirement.
+
+Colocation — placing test files alongside production source files in `src/` or equivalent — is not permitted. An agent that creates or moves a test file into the production source tree has violated this rule.
+
+## Documentation
+
+- Each test must clearly communicate its purpose via a descriptive name and/or a short docstring or comment summarizing the scenario and expected outcome.
+- Group related tests logically within the same file or test class.
+
+## Test Categories
+
+The following test categories apply across the repository, with tier-dependent obligations per `.agents/skills/quality-tiers.md`:
+
+- **Unit tests** — required for all tiers (T1–T4). Cover single units of behavior in isolation.
+- **Property-based tests** — required for T1 and T2 modules: at least one property test per pure function. Use `fast-check` (TypeScript) or `hypothesis` (Python) where applicable.
+- **Golden / snapshot tests** — required only for T1 classifier-output modules, tested against a versioned corpus. Snapshot tests are otherwise discouraged unless stable and intentional.
+- **Contract / schema tests** — required at every host-service boundary (e.g., Office.js, Microsoft Graph, internal API contracts).
+- **Mutation tests** — required for T1 modules: mutation score >= 75%. Run in pre-merge or nightly pipelines.
+- **Integration tests** — required where adapters interact with external systems; scoped per tier in the gate matrix.
+
+## Determinism Infrastructure
+
+All test code must be deterministic. The following infrastructure requirements apply uniformly:
+
+- **Controllable clock** — use a `Clock` interface (TypeScript) or `TimeProvider` (.NET) injected into code under test. Do not read wall-clock time directly in production code under test.
+- **Seeded RNG** — randomness must be supplied via a seedable interface; on test failure the seed must be printed so the failure is reproducible.
+- **Banned APIs in test code** — `setTimeout`, `Thread.Sleep`, `Task.Delay`, real wall-clock waits, and `Date.now()` outside the clock interface are prohibited in tests.
+- **Virtual scheduler / fake timers / `FakeTimeProvider`** — async tests must use the framework's fake-timer facility (`vi.useFakeTimers()` for Vitest, `FakeTimeProvider` for .NET) to advance simulated time deterministically.

package/resources/codex-and-agents-customizations/.agents/skills/human-exception-runbook/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: human-exception-runbook
+description: Contract for runbooks that document permitted human exceptions recorded in orchestrator state.
+---
+
+# Human-Exception Runbook
+
+Defines the contract for a human-exception runbook: the artifact the orchestrator emits when an unautomatable requirement is resolved with the `exception` response under the autonomous-execution mandate (see `.agents/skills/orchestrate/SKILL.md`).
+
+## When to Use This Skill
+
+Use this skill when:
+
+- The orchestrator detects an unautomatable (human-interaction) requirement and resolves it with the `exception` response rather than `scope_change` or `halt`.
+- A permitted exception is recorded in orchestrator state and the schema's exception-requires-runbook invariant must be satisfied (`response == "exception"` requires a non-empty `runbook_path` pointing to an existing file).
+- Authoring or reviewing a runbook that a human will follow to complete a step the workflow cannot automate.
+
+## Canonical Path
+
+A human-exception runbook is stored per-feature at:
+
+```
+<FEATURE>/runbooks/<name>.runbook.md
+```
+
+The `runbook_path` recorded in `orchestrator-state.json` (`human_interaction.requirements[].runbook_path`) is the path relative to the repo root. This path is under the feature folder but is not an `evidence/` sub-path, so it is not governed by `enforce-evidence-locations.ps1` (OD-45-6).
+
+## Required Sections
+
+Every human-exception runbook MUST contain these five sections, in this order:
+
+1. **Cue** — when to act; the event or state that triggers the runbook (for example, "the orchestrator recorded an `exception` for Global-Administrator admin consent").
+2. **Prerequisites** — what must be true before the human starts: accounts, roles, devices, tools, and any prior state.
+3. **Step-by-step Instructions** — numbered steps, including detailed third-party UI navigation where applicable. Each step is concrete and verifiable.
+4. **Verification** — how the human confirms success: the observable state, confirmation dialog, or command output that proves the step completed.
+5. **Source and Citation** — the source URL(s) and a dated capture (`updated_at`) for each cited step. Third-party UI sections record the navigation source; non-UI CLI steps record the documentation source for the command used.
+
+## Sourcing Rule (MCP-first / web-second)
+
+Third-party UI steps (for example Azure portal / Entra admin center, Outlook desktop or mobile, the Microsoft 365 admin center) MUST be sourced **MCP-first, web-second**:
+
+1. Prefer an MCP documentation source (for example a Microsoft Learn MCP query) as the primary source.
+2. Use a web source (the vendor's current published documentation) only when no MCP source is available.
+3. Training data is NOT an acceptable sole source for any third-party UI step, because vendor UIs drift and stale navigation produces incorrect instructions.
+
+Per OD-45-5, the MCP-first / web-second ordering is mandatory for third-party UI navigation. Non-UI CLI steps (for example `az` commands) do not require the UI ordering, but every step type — UI and CLI alike — MUST carry a current, dated citation in the Source-and-Citation section. A runbook step without a dated source is not contract-conformant.
+
+## Conformance
+
+A runbook is contract-conformant when:
+
+- it lives at `<FEATURE>/runbooks/<name>.runbook.md`,
+- it contains all five required sections (Cue, Prerequisites, Step-by-step Instructions, Verification, Source and Citation),
+- its Source-and-Citation section records at least one source URL and a capture date,
+- third-party UI steps were sourced MCP-first / web-second.
+
+A self-contained, conformant example is provided at `.agents/skills/human-exception-runbook/example.runbook.md`.

package/resources/codex-and-agents-customizations/.agents/skills/human-exception-runbook/example.runbook.md

@@ -0,0 +1,36 @@
+# Example Human-Exception Runbook — Grant Tenant-Wide Admin Consent for an Entra Application
+
+This is a self-contained, contract-conformant example runbook per `.agents/skills/human-exception-runbook/SKILL.md`. It demonstrates the required five sections and the dated-citation requirement. It does not reference any other feature folder. The values below (tenant, application name) are illustrative placeholders.
+
+## Cue
+
+Act on this runbook when the orchestrator records an `exception` response for the requirement "tenant-wide admin consent for the Entra application." Admin consent for delegated Microsoft Graph permissions that require administrator approval cannot be granted unattended without a Global-Administrator service principal in CI (declined per the autonomous-execution mandate's scope decisions), so it is resolved as a permitted exception and this runbook is the human follow-up.
+
+## Prerequisites
+
+- An account with the **Global Administrator** or **Privileged Role Administrator** role in the target Microsoft Entra tenant.
+- The application's **Application (client) ID** and the tenant's display name.
+- Access to the Microsoft Entra admin center (https://entra.microsoft.com).
+- The set of delegated permissions the application requests is already declared on the app registration (this runbook grants consent for them; it does not add them).
+
+## Step-by-step Instructions
+
+1. Sign in to the Microsoft Entra admin center at https://entra.microsoft.com with the Global Administrator account.
+2. In the left navigation, select **Identity** > **Applications** > **App registrations**.
+3. Select **All applications**, then open the application by its Application (client) ID.
+4. In the application's left menu, select **API permissions**.
+5. Review the listed permissions and confirm the requested delegated Microsoft Graph permissions are present with status "Not granted for <tenant>".
+6. Select **Grant admin consent for <tenant>** at the top of the **Configured permissions** list.
+7. In the confirmation dialog, select **Yes** to grant tenant-wide admin consent.
+
+## Verification
+
+- After step 7, each affected permission row shows the status **Granted for <tenant>** with a green check mark.
+- Re-open **API permissions** and confirm no permission remains in the "Not granted" state.
+- Optionally, confirm programmatically that the consent exists by querying the service principal's OAuth2 permission grants with the Microsoft Graph CLI or `az ad`.
+
+## Source and Citation
+
+- Step source (third-party UI navigation, sourced MCP-first): Microsoft Learn — "Grant tenant-wide admin consent to an application." Source URL: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/grant-admin-consent — updated_at: 2026-06-01.
+- API permissions UI reference (web-second corroboration): Microsoft Learn — "Configure a client application to access a web API." Source URL: https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-configure-app-access-web-apis — updated_at: 2026-06-01.
+- Verification reference (CLI corroboration for the optional programmatic check): Microsoft Learn — "az ad app permission" command reference. Source URL: https://learn.microsoft.com/en-us/cli/azure/ad/app/permission — updated_at: 2026-06-01.

package/resources/codex-and-agents-customizations/.agents/skills/invoke-csharp-engineer/SKILL.md

@@ -1,12 +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 Claude skill paths to shared skill paths.
-- Rewrite Claude rule paths to shared skill paths.
-
 ---
 name: invoke-csharp-engineer
 description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.

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

@@ -1,12 +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 Claude skill paths to shared skill paths.
-- Rewrite Claude rule paths to shared skill paths.
-
 ---
 name: invoke-powershell-engineer
 description: Invoke the powershell-typed-engineer worker to design, implement, and verify PowerShell changes within typed repository boundaries. Applies PoshQC format -> analyze -> test toolchain, the 1-2 production-file direct-mode budget, the 3-production + 3-test per-batch cap, and zero-regression quality gates.

package/resources/codex-and-agents-customizations/.agents/skills/invoke-python-engineer/SKILL.md

@@ -1,12 +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 Claude skill paths to shared skill paths.
-- Rewrite Claude rule paths to shared skill paths.
-
 ---
 name: invoke-python-engineer
 description: Invoke the python-typed-engineer worker to design, implement, and verify Python changes within typed repository boundaries. Applies Black -> Ruff -> Pyright -> Pytest toolchain, the 3-production + 3-test per-batch budget, and zero-regression quality gates.

package/resources/codex-and-agents-customizations/.agents/skills/make-skill-template/SKILL.md

@@ -1,8 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
 name: make-skill-template
 description: 'Create new Agent Skills for GitHub Copilot from prompts or by duplicating this template. Use when asked to "create a skill", "make a new skill", "scaffold a skill", or when building specialized AI capabilities with bundled resources. Generates SKILL.md files with proper frontmatter, directory structure, and optional scripts/references/assets folders.'

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.
@@ -30,6 +23,64 @@ 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.
+
+## 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
 
@@ -38,11 +89,36 @@ 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
 - `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,6 +142,7 @@ 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
 
@@ -111,6 +188,13 @@ Every delegation prompt to `atomic-planner`, `atomic-executor`, and `feature-rev
 
 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:
@@ -120,6 +204,7 @@ The orchestrator must not create a PR, push a branch for PR purposes, or report
 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.
 

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.