@danmoisan/drm-copilot-mcp 0.0.1 → 0.0.6

package/resources/codex-and-agents-customizations/.agents/skills/csharp-change-budget-router/SKILL.md

@@ -1,8 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
 name: csharp-change-budget-router
 description: Budget-first routing contract for C# work: estimate production-file scope, choose small vs large path, enforce orchestration-first routing for larger changes, and use the VS Code extension command surface for promotion lifecycle steps when available.
@@ -29,7 +24,7 @@ Use this skill when:
 ## Orchestrated Small-Path Requirements
 
 When routed through `csharp-orchestrator`, small path still requires lifecycle scaffolding before implementation:
-- invoke promotion/folder lifecycle steps through `vscode/runCommand` + extension access per `feature-promotion-lifecycle` when available; use script/CLI fallback only when direct extension command execution is unavailable,
+- invoke promotion/folder lifecycle steps through the `drm-copilot` MCP tools required by `repo-automation-adapter`. If the MCP server or required tool is unavailable, stop before promotion,
 - promote potential item to GitHub issue with `--work-mode minor-audit`,
 - create active feature folder with `--work-mode minor-audit`,
 - delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,

package/resources/codex-and-agents-customizations/.agents/skills/csharp-orchestration-state-machine/SKILL.md

@@ -1,8 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
 name: csharp-orchestration-state-machine
 description: Checkpoint schema and resume protocol for long-running C# orchestration workflows.

package/resources/codex-and-agents-customizations/.agents/skills/csharp-qa-gate/SKILL.md

@@ -1,8 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- Rewrite Claude skill paths to shared skill paths.
-
 ---
 name: csharp-qa-gate
 description: Final QA gate for C# changes. Executes the full CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.

package/resources/codex-and-agents-customizations/.agents/skills/evidence-and-timestamp-conventions/SKILL.md

@@ -1,8 +1,3 @@
-# Converted skill
-
-Applied rewrites:
-- None
-
 ---
 name: evidence-and-timestamp-conventions
 description: 'Evidence storage and timestamp naming conventions for audits and remediation. Use when storing baseline/regression/QA evidence or naming audit artifacts with ISO-8601 timestamps.'

package/resources/codex-and-agents-customizations/.agents/skills/execute-hard-lock/SKILL.md

@@ -1,20 +1,11 @@
-# Converted skill
-
-Applied rewrites:
-- Rewrite Claude agent manifest paths to Codex agent paths.
-- Rewrite remaining VS Code command IDs to semantic MCP tool usage.
-
 ---
 name: execute-hard-lock
-description: Place the session in atomic execution mode bound to a specific plan-of-record. Resolves the hard-lock prompt via the drmCopilotExtension MCP tool, then delegates to the atomic-executor subagent with the resolved text. Use when a caller provides ${plan-path} and ${work-mode} and requires strict plan-following behavior.
-allowed-tools:
-  - mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt
-  - Read
+description: Place the session in atomic execution mode bound to a specific plan-of-record. Resolves the hard-lock prompt via the drm-copilot MCP tool, then delegates to the atomic-executor subagent with the resolved text. Use when a caller provides ${plan-path} and ${work-mode} and requires strict plan-following behavior.
 ---
 
 # Execute Hard Lock
 
-Thin wrapper that resolves the hard-lock prompt via the drmCopilotExtension MCP tool and hands the resolved text to the `atomic-executor` subagent as kickoff directives. The resolved prompt is the authoritative instruction set for the session; this skill does not duplicate its contents.
+Thin wrapper that resolves the hard-lock prompt via the drm-copilot MCP tool and hands the resolved text to the `atomic-executor` subagent as kickoff directives. The resolved prompt is the authoritative instruction set for the session; this skill does not duplicate its contents.
 
 ## When to Use This Skill
 
@@ -22,7 +13,7 @@ Use this skill when:
 
 - The caller provides an explicit plan file path (`${plan-path}`) and a selected work mode (`${work-mode}`).
 - Strict plan-following behavior is required (no replanning, no reordering, no bucket tasks).
-- The drmCopilotExtension MCP server is registered and reachable.
+- The drm-copilot MCP server is registered and reachable.
 
 ## Inputs
 
@@ -37,7 +28,7 @@ Required:
 
 Call the extension's resolver as the first action:
 
-- Tool: `mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt`
+- Tool: `mcp__drm-copilot__resolve_execute_hard_lock_prompt`
 - Parameters:
   - `target` (required): the plan-of-record path (`${plan-path}`).
   - `workspace_root` (optional): the workspace root. Omit to default to the current working directory.
@@ -50,7 +41,7 @@ Use the `Read` tool on the path returned in `artifacts[0]`. Treat the file conte
 
 ### 3. Delegate to atomic-executor
 
-Invoke the `atomic-executor` subagent via the Agent tool. Pass the resolved prompt text as the subagent's kickoff directive, followed by `${plan-path}` and `${work-mode}` as session context.
+Spawn the `atomic-executor` subagent from `.codex/agents/atomic-executor.toml`. Pass the resolved prompt text as the subagent's kickoff directive, followed by `${plan-path}` and `${work-mode}` as session context. If the `atomic-executor` agent is unavailable, stop with `BLOCKED: execute-hard-lock spawn_agent_unavailable`.
 
 The resolved prompt itself already instructs the subagent to perform the mandatory read-proof (`git rev-parse HEAD`, SHA-256 of the plan file, unchecked-task count), preflight validation, and `READY TO BEGIN FROM [P#-T#]` handshake before executing any task. This skill does not reissue those instructions locally — doing so would risk divergence from the canonical template.
 
@@ -67,8 +58,8 @@ Stop immediately and report `BLOCKED: execute-hard-lock <cause>` in any of these
 
 The three entry points below all produce the same resolved hard-lock prompt for a given plan path. This skill always uses the MCP form:
 
-- MCP (used by this skill): `mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt` with `target=<plan-path>`. The extension passes `--output artifacts/hard_lock_prompt.txt` and `--quiet` to the bundled Python resolver.
-- VS Code command: `@command:mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt` (interactive; writes to stdout + clipboard, no file artifact).
+- MCP (used by this skill): `mcp__drm-copilot__resolve_execute_hard_lock_prompt` with `target=<plan-path>`. The extension passes `--output artifacts/hard_lock_prompt.txt` and `--quiet` to the bundled Python resolver.
+- VS Code command: `@command:mcp__drm-copilot__resolve_execute_hard_lock_prompt` (interactive; writes to stdout + clipboard, no file artifact).
 
 ## Delegation Contract
 
@@ -84,5 +75,5 @@ The `atomic-executor` subagent at [.codex/agents/atomic-executor.toml](.codex/ag
 - Do not proceed without a successful MCP resolver response AND a successful `Read` of the artifact.
 - Do not reconstruct the hard-lock contract from any other source (not from this file nor from prior session memory).
 - Do not modify the resolved prompt text before passing it to `atomic-executor`.
-- Do not replan, reorder, or add tasks at this layer — the subagent owns that contract.
+- Do not replan, reorder, or add tasks at this layer. The subagent owns that contract.
 - Do not create or read secrets unless explicitly authorized.

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,19 +17,22 @@ 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.
 
 ## 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`
@@ -43,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
@@ -56,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.
 
@@ -67,41 +72,52 @@ 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__drmCopilotExtension__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}`
 
-3) Create branch:
-- `${promotion-type}/${short-name}-${issue-num}`
+4) Create the potential entry through `mcp__drm-copilot__new_potential_entry` or `mcp__drm-copilot__new_potential_bug_entry`.
 
-4) Create the active feature folder through `mcp__drmCopilotExtension__new_active_feature_folder` with `work_mode=minor-audit`.
+5) Promote the potential document through `mcp__drm-copilot__potential_to_issue` with the selected `${work-mode}` and capture the numeric `${issue-num}`.
 
-4a) Verify minor-audit folder integrity before proceeding:
+6) Rename the branch to the final branch:
+- `${final-branch}`
+
+7) Create the active feature folder through `mcp__drm-copilot__new_active_feature_folder` with the selected `${work-mode}`.
+
+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:
-- manual bootstrap: save state and stop,
+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.
 
-9) Validate delivery via executor against `issue.md`, then run reduced audit/remediation loop until ready-to-merge.
+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
+
+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/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.'