@danmoisan/drm-copilot-mcp 0.0.1 → 0.0.6

package/resources/claude-customizations/.claude/rules/orchestrator-state.md

@@ -0,0 +1,39 @@
+# 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 `.claude/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/claude-customizations/.claude/rules/powershell.md

@@ -12,10 +12,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.
 
@@ -60,8 +60,8 @@ Introduce the smallest seam that enables reliable mocking. Apply these options i
 - Write focused tests exercising a single function or behavior.
 - Mock sparingly; prefer real code paths.
 - No external dependencies in unit tests.
-- Repository-wide line coverage must remain >= 80%.
-- Any new module, class, or method must reach >= 90% coverage.
+- Line coverage must remain >= 85% across all tiers (T1–T4) per `.claude/rules/quality-tiers.md`.
+- Branch coverage must remain >= 75% across all tiers (T1–T4).
 - Coverage regression on changed lines is a blocking finding.
 
 ### Deterministic Test Requirements

package/resources/claude-customizations/.claude/rules/python.md

@@ -13,7 +13,7 @@ This rule file summarizes the Python-specific policies for this repository.
 1. **Formatting — Black**: All Python code must be formatted with Black (default settings). Command: `poetry run black .`
 2. **Linting — Ruff**: Python code must pass Ruff using the project configuration. Command: `poetry run ruff check .` Suppressions require pre-authorization per `python-suppressions.instructions.md` or explicit user approval.
 3. **Type Checking — Pyright**: All Python code must be fully type-annotated and pass Pyright. Avoid `Any` unless unavoidable and commented. Command: `poetry run pyright`
-4. **Testing — Pytest**: All tests use Pytest. New logic must have test coverage >= 90%. Command: `poetry run pytest --cov --cov-report=term-missing`
+4. **Testing — Pytest**: All tests use Pytest. Coverage thresholds are uniform across tiers per `.claude/rules/quality-tiers.md` (>= 85% line, >= 75% branch). Command: `poetry run pytest --cov --cov-branch --cov-report=term-missing`
 
 Run the toolchain in order: format → lint → type-check → test. Restart from step 1 if any step fails or changes files. Do not stop the loop until all four steps complete without errors in a single pass.
 
@@ -85,9 +85,10 @@ Do not introduce generic service-locator patterns or heavy dependency-injection
 - No sleeps, retries, or timing hacks.
 - Organize tests to mirror code structure (for example, `tests/test_module_name.py` for `module_name.py`).
 - No external dependencies (network, databases, external processes, runtime filesystem temp files) in unit tests.
-- Repository-wide line coverage must remain >= 80%.
-- Any new module, class, or method must reach >= 90% coverage.
+- Line coverage must remain >= 85% across all tiers (T1–T4) per `.claude/rules/quality-tiers.md`.
+- Branch coverage must remain >= 75% across all tiers (T1–T4).
 - Coverage regression on changed lines is a blocking finding.
+- Type-only modules with no executable behavior — for example `Protocol`-only modules consumed only under `TYPE_CHECKING` — may be omitted from coverage measurement. Such modules legitimately report 0% executable coverage. This is a clarification only; it does not lower any coverage threshold.
 
 ## Prohibited Behaviors
 

package/resources/claude-customizations/.claude/rules/quality-tiers.md

@@ -0,0 +1,51 @@
+---
+paths:
+  - "**"
+description: Module rigor tier system and uniform coverage thresholds.
+---
+
+# Module Rigor Tiers
+
+This rule defines the T1–T4 module rigor tier system used by all CI gates in this repository. The tier system source of truth is `docs/ci.research.md` section 1; the file `quality-tiers.yml` at the repository root maps every project to a tier. Adding a project without a tier classification fails CI.
+
+## Tiers
+
+- **T1 — Critical.** Behavior bugs cause silent data loss, model drift, or security holes. Examples (No-COM architecture): classifier engines (SpamBayes, Triage), ToDo ID allocator and hierarchy operations, Graph extended-properties adapter, auth/token handling, host-agnostic command bus.
+- **T2 — Core.** Bugs cause feature regressions but not data loss. Examples: `TaskMaster.Domain`, `TaskMaster.Application`, mail-item DTOs, settings store abstraction, schema definitions.
+- **T3 — Adapters & UI.** Glue around APIs the team does not own. Examples: Outlook task pane UI, Office.js wrappers, Microsoft Graph SDK wrappers, persistence I/O.
+- **T4 — Scaffolding.** Examples: DI wiring, bootstrap, build scripts, dev tooling, generated code, manifests.
+
+## Source of Truth
+
+- `quality-tiers.yml` at repo root maps every project to one tier.
+- The CI pipeline's `tier-classification` stage validates that every project entry has a tier and that no unclassified project exists. Adding a project without a tier classification fails CI.
+
+## Uniform-vs-Tier-Dependent Gate Matrix
+
+Per Authoritative Decision #2, line and branch coverage thresholds are uniform across all tiers. Other gates remain tier-dependent.
+
+### Uniform across all tiers (T1–T4)
+
+- Format check: 100% pass.
+- Lint errors: 0.
+- Type errors: 0.
+- Architecture violations: 0.
+- Line coverage: >= 85%.
+- Branch coverage: >= 75%.
+- No regression on changed lines.
+
+### Tier-dependent
+
+| Gate | T1 | T2 | T3 | T4 |
+|---|---|---|---|---|
+| Untyped escape hatches (`any`/`dynamic`) | 0 | 0 | <= 5 per file, justified | unlimited |
+| Property test density | >= 1 per pure function | >= 1 per pure function | none | none |
+| Mutation score | >= 75% | trend-only | none | none |
+| Contract breaking changes | major bump required | major bump required | n/a | n/a |
+| Determinism (retry rate) | < 0.5% | < 1% | < 2% | n/a |
+| Golden tests | required for classifier-output modules | optional | none | none |
+| Full E2E suite scope | all critical paths | core paths | adapter smoke | none |
+
+## Rationale (uniform coverage thresholds)
+
+High test coverage is a fundamental quality-control design choice that enables autonomous agentic development and trust in the work product. For that reason, line coverage >= 85% and branch coverage >= 75% apply uniformly across T1–T4; tier-specific lower coverage floors are not used in this repository.

package/resources/claude-customizations/.claude/rules/typescript.md

@@ -13,7 +13,7 @@ This rule file summarizes the TypeScript-specific policies for this repository.
 1. **Formatting — Prettier**: All TypeScript must be formatted with the repository Prettier configuration. Command: `npm run format`
 2. **Linting — ESLint**: TypeScript must pass ESLint using the repository configuration. Command: `npm run lint`
 3. **Type Checking — TSC**: TypeScript must pass the compiler type-check. Avoid `any`; prefer `unknown` plus narrowing. Command: `npm run typecheck`
-4. **Testing — Jest**: All TypeScript unit tests must use Jest. Command: `npm run test:unit`
+4. **Testing — Vitest**: All TypeScript unit tests must use Vitest. Command: `npm run test`
 
 Run the toolchain in order: format → lint → type-check → test. Restart from step 1 if any step fails or changes files.
 
@@ -25,21 +25,50 @@ Run the toolchain in order: format → lint → type-check → test. Restart fro
 - **Domain types**: Model domain concepts with interfaces/types that encode invariants. Prefer discriminated unions for state machines.
 - **Naming**: `PascalCase` for classes, interfaces, enums, and type aliases. `camelCase` for functions, methods, variables, and object properties. No `I` prefix on interfaces.
 - **File naming**: Prefer kebab-case filenames (e.g., `user-session.ts`, `task-runner.ts`).
-- **Separation of concerns**: Keep pure logic separate from VS Code extension APIs, filesystem/network I/O, and UI wiring.
+- **Separation of concerns**: Keep pure logic separate from Office.js, Microsoft Graph SDK, and other host-bound APIs, filesystem/network I/O, and UI wiring.
 - **Error handling**: Fail fast with clear errors. Avoid catch-all `catch (e)` without rethrowing or adding context.
 - **Dependencies**: Do not add new runtime dependencies unless explicitly approved.
 
+## ESLint Stack
+
+- Require `typescript-eslint` strict-type-checked + stylistic-type-checked rule sets.
+- Enable type-aware parsing (`parserOptions.project = true`).
+- Required plugins: `eslint-plugin-office-addins`, `eslint-plugin-promise`, `eslint-plugin-security`, `eslint-plugin-import`.
+- Error-level rules: `no-floating-promises`, `no-misused-promises`, all `no-unsafe-*`.
+- Add a `no-restricted-syntax` rule banning `Date.now`, `setTimeout`, `setInterval`, and `Math.random` outside an explicit infrastructure allowlist.
+
 ## Testing Standards
 
-- Use **Jest** as the test framework.
+- Use **Vitest** as the test framework.
 - Name test files `*.test.ts`.
-- Unit tests must not require the VS Code extension host.
+- Unit tests must not require the Outlook host runtime.
 - Follow Arrange–Act–Assert structure.
 - Each test targets one behavior.
-- Use `jest.spyOn` or `jest.mock` for targeted mocking; reset mocks with `afterEach(() => { jest.resetAllMocks(); })`.
+- Use `vi.spyOn` or `vi.mock` for targeted mocking; reset mocks with `afterEach(() => { vi.resetAllMocks(); })`.
 - No external dependencies (network, filesystem temp files, external processes) in unit tests.
 - Avoid snapshot tests unless stable and intentional.
-- Repository-wide line coverage must remain >= 80%.
-- Any new module, class, or method must reach >= 90% coverage.
-- Coverage command: `npm run test:unit:coverage`
+- Coverage thresholds follow the uniform tier rule defined in `.claude/rules/quality-tiers.md`: line coverage >= 85% and branch coverage >= 75% across all tiers (T1–T4).
+- Coverage command: `npm run test:coverage` (the script is wired in Prompt B1 alongside the Vitest dependency).
 - Coverage regression on changed lines is a blocking finding.
+- Interface/type-only files with no executable behavior — files consisting solely of `interface` or `type` declarations — may be omitted from coverage measurement. Such files legitimately report 0% executable coverage. This is a clarification only; it does not lower any coverage threshold.
+
+## Architecture Boundaries
+
+Layer rules and the No-COM architecture assertions are defined in `.claude/rules/architecture-boundaries.md`. The TypeScript enforcement tool is `dependency-cruiser` with configuration file `.dependency-cruiser.cjs`.
+
+## Property-Based and Mutation Testing
+
+- `fast-check` provides property-based tests; T1 and T2 modules require >= 1 property test per pure function.
+- `StrykerJS` provides mutation testing; T1 modules require mutation score >= 75%.
+- Both run in pre-merge or nightly pipelines per `general-code-change.md`.
+
+## Golden Tests
+
+- T1 classifier modules require golden-output snapshots tested against a versioned corpus.
+- The general guidance to avoid snapshot tests unless stable and intentional remains in force for all other scenarios; classifier-output and schema-evolution snapshots are explicitly permitted when versioned.
+
+## Runtime Determinism
+
+- `Date`, `Math.random`, and `setTimeout` access must flow through an injected `Clock` / `Random` interface.
+- Tests use Vitest fake timers (`vi.useFakeTimers()`).
+- Prefer `await flushPromises()` over `setTimeout(0)` for awaiting micro-tasks.

package/resources/claude-customizations/.claude/settings.json

@@ -10,18 +10,18 @@
       "Edit(/docs/**)",
       "Write(/docs/**)",
       "Write(/artifacts/**)",
-      "mcp__drmCopilotExtension__run_poshqc_format",
-      "mcp__drmCopilotExtension__run_poshqc_analyze",
-      "mcp__drmCopilotExtension__run_poshqc_test",
-      "mcp__drmCopilotExtension__run_poshqc_analyze_autofix",
-      "mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt",
-      "mcp__drmCopilotExtension__collect_pr_context",
-      "mcp__drmCopilotExtension__new_potential_entry",
-      "mcp__drmCopilotExtension__new_potential_bug_entry",
-      "mcp__drmCopilotExtension__potential_to_issue",
-      "mcp__drmCopilotExtension__new_active_feature_folder",
-      "mcp__drmCopilotExtension__validate_orchestration_artifacts",
-      "mcp__drmCopilotExtension__resolve_atomic_plan_prompt",
+      "mcp__drm-copilot__run_poshqc_format",
+      "mcp__drm-copilot__run_poshqc_analyze",
+      "mcp__drm-copilot__run_poshqc_test",
+      "mcp__drm-copilot__run_poshqc_analyze_autofix",
+      "mcp__drm-copilot__resolve_execute_hard_lock_prompt",
+      "mcp__drm-copilot__collect_pr_context",
+      "mcp__drm-copilot__new_potential_entry",
+      "mcp__drm-copilot__new_potential_bug_entry",
+      "mcp__drm-copilot__potential_to_issue",
+      "mcp__drm-copilot__new_active_feature_folder",
+      "mcp__drm-copilot__validate_orchestration_artifacts",
+      "mcp__drm-copilot__resolve_atomic_plan_prompt",
       "Agent(atomic-planner)",
       "Agent(atomic-executor)",
       "Agent(feature-review)",
@@ -30,6 +30,7 @@
       "Agent(staged-review)",
       "Agent(epic-review)",
       "Agent(status-updater)",
+      "Agent(pr-author)",
       "Agent(python-typed-engineer)",
       "Agent(powershell-typed-engineer)",
       "Agent(csharp-typed-engineer)",
@@ -78,6 +79,14 @@
           {
             "type": "command",
             "command": "pwsh -NoProfile -File .claude/hooks/enforce-promotion-mcp-only.ps1"
+          },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-pr-author-skill.ps1"
+          },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-orchestration-preimplementation-gate.ps1"
           }
         ]
       },
@@ -103,6 +112,35 @@
           {
             "type": "command",
             "command": "pwsh -NoProfile -File .claude/hooks/enforce-evidence-locations.ps1"
+          },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-orchestration-preimplementation-gate.ps1"
+          },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-feature-folder-order.ps1"
+          },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-checkpoint-monotonic.ps1"
+          },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-completion-consistency.ps1"
+          }
+        ]
+      },
+      {
+        "matcher": "Agent",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-prd-feature-before-planner.ps1"
+          },
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/enforce-orchestration-preimplementation-gate.ps1"
           }
         ]
       }
@@ -134,6 +172,15 @@
             "command": "pwsh -NoProfile -File .claude/hooks/validate-planner-output.ps1"
           }
         ]
+      },
+      {
+        "matcher": "pr-author",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "pwsh -NoProfile -File .claude/hooks/validate-pr-author-output.ps1"
+          }
+        ]
       }
     ]
   },

package/resources/claude-customizations/.claude/skills/atomic-plan-contract/SKILL.md

@@ -19,7 +19,7 @@ Use this skill when:
 - Phase headings must be: `### Phase N — <Title>`
 - Tasks must start with: `- [ ] [P#-T#]` (or `[x]` for completed)
 - Task IDs must match their phase and be sequential per phase.
-- Plans must pass the `mcp__drmCopilotExtension__validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>` before they can be reported as approved.
+- Plans must pass the `mcp__drm-copilot__validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>` before they can be reported as approved.
 
 ## Short-Path Minimal Plan Contract
 
@@ -153,7 +153,7 @@ When validating or handing off plans for execution:
 
 Before a plan can be treated as approved:
 
-- run the `mcp__drmCopilotExtension__validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`,
+- run the `mcp__drm-copilot__validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>`,
 - reject the plan if that validator exits non-zero,
 - do not treat human-readable summaries as a substitute for validator success.
 

package/resources/claude-customizations/.claude/skills/csharp-qa-gate/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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.
+description: Final QA gate for C# changes. Executes the full CSharpier -> .NET Analyzers -> Nullable Analysis -> xUnit toolchain (with architecture tests), compares against a captured baseline, enforces zero-regression deltas, and produces the required reporting block before the agent declares the change complete.
 ---
 
 # C# QA Gate
@@ -19,18 +19,32 @@ Use this skill when:
 
 Before invoking this gate, the agent must have:
 
-- a baseline record produced in Phase A, containing analyzer findings, compiler/nullable diagnostics, MSTest pass/fail status, and per-file coverage status for the in-scope files,
+- a baseline record produced in Phase A, containing analyzer findings, compiler/nullable diagnostics, xUnit pass/fail status, and per-file coverage status for the in-scope files,
 - the exact list of touched production and test files,
 - a clean working tree (all planned edits committed to the working copy).
 
 ## Toolchain Execution Sequence
 
-Run the full toolchain in this exact order. If any step fails or modifies files, fix the issue and restart from step 1. Do not stop the loop until all four steps complete without errors in a single pass.
+Run the full toolchain in this exact order. If any step fails or modifies files, fix the issue and restart from step 1. Do not stop the loop until all five steps complete without errors in a single pass.
 
-1. `dotnet tool run csharpier .`
-2. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
-4. `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
+Analyzer settings (`AnalysisLevel`, `AnalysisMode`, `TreatWarningsAsErrors`, `Nullable`) are centralized in `Directory.Build.props` and apply to every project automatically. Per-project analyzer-enablement properties are not used — central settings are authoritative.
+
+1. `dotnet tool restore`
+2. `dotnet csharpier check .`
+3. `dotnet build` (analyzers and nullable analysis enforced via `Directory.Build.props`; `TreatWarningsAsErrors=true` fails the build on any warning)
+4. `dotnet test tests/*.ArchitectureTests/*.csproj --no-build` (architecture tests against the `*.ArchitectureTests` project)
+5. `dotnet test --collect:"XPlat Code Coverage"` (full unit-test pass with coverage)
+6. Emit canonical coverage artifact: after `dotnet test` completes, copy the newest `TestResults/*/coverage.cobertura.xml` to `artifacts/csharp/coverage.xml` so local runs produce the same canonical artifact as CI. PowerShell sketch:
+
+   ```pwsh
+   New-Item -ItemType Directory -Force -Path artifacts/csharp | Out-Null
+   $latest = Get-ChildItem TestResults -Recurse -Filter coverage.cobertura.xml |
+     Sort-Object LastWriteTime -Descending | Select-Object -First 1
+   if (-not $latest) { Write-Error 'No coverage.cobertura.xml found'; exit 1 }
+   Copy-Item $latest.FullName artifacts/csharp/coverage.xml -Force
+   ```
+
+   The step must fail non-zero when no `coverage.cobertura.xml` is present.
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
 
@@ -40,7 +54,8 @@ Compare the final results to the Phase A baseline. All of the following must hol
 
 - **Analyzer delta**: 0 new findings across the repository.
 - **Compiler / nullable delta**: 0 new diagnostics across the repository.
-- **MSTest delta**: 0 new failing tests.
+- **xUnit delta**: 0 new failing tests.
+- **Architecture-test delta**: 0 new failing facts in the `*.ArchitectureTests` project.
 - **Per-file coverage delta**: coverage for every touched file is greater than or equal to the baseline for that file.
 - **Overall coverage delta** (when the repo enforces it): overall coverage is greater than or equal to the baseline.
 - **New modules, classes, or methods**: coverage >= 90% for each new unit introduced in the batch.
@@ -52,10 +67,10 @@ If any delta check fails, the agent must revert or fix immediately and rerun the
 Every completion response must include the following sections:
 
 1. **Scope** — exact file list touched in this change.
-2. **Baseline** — analyzer, compiler/nullable, MSTest, and coverage status recorded in Phase A.
+2. **Baseline** — analyzer, compiler/nullable, xUnit, and coverage status recorded in Phase A.
 3. **Plan** — design and test-strategy summary, referencing the approved plan.
 4. **Diffs** — patch-style or full-file replacements for scoped files only.
-5. **QA Gate Results** — analyzer, compiler/nullable, MSTest, and coverage deltas. If any step could not be run, mark the corresponding line **unverified** and state why.
+5. **QA Gate Results** — analyzer, compiler/nullable, xUnit, architecture-test, and coverage deltas. If any step could not be run, mark the corresponding line **unverified** and state why.
 
 ## Evidence Storage
 

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

@@ -31,7 +31,6 @@ The following sub-paths under `artifacts/` are FORBIDDEN for evidence output:
 
 Allowed `artifacts/` sub-paths (non-evidence orchestration use only):
 - `artifacts/orchestration/`
-- `artifacts/research/`
 
 No delegation prompt, plan task, or upstream agent instruction may override this scheme. If a caller supplies a non-canonical path, the receiving agent MUST reject it, substitute the canonical path, and record `EVIDENCE_LOCATION_OVERRIDE_REJECTED: <supplied path> replaced with <canonical path>`.
 

package/resources/claude-customizations/.claude/skills/execute-hard-lock/SKILL.md

@@ -1,14 +1,14 @@
 ---
 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.
+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.
 allowed-tools:
-  - mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt
+  - mcp__drm-copilot__resolve_execute_hard_lock_prompt
   - Read
 ---
 
 # 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
 
@@ -16,7 +16,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
 
@@ -31,7 +31,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.
@@ -61,7 +61,7 @@ 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.
+- 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:drmCopilotExtension.resolveExecuteHardLockPrompt` (interactive; writes to stdout + clipboard, no file artifact).
 
 ## Delegation Contract

package/resources/claude-customizations/.claude/skills/feature-promotion-lifecycle/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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
@@ -17,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.
 
@@ -56,12 +56,12 @@ When orchestrator routing selects short path, promotion/folder initialization st
 
 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`

package/resources/claude-customizations/.claude/skills/feature-review-workflow/SKILL.md

@@ -63,6 +63,17 @@ Always apply:
   - if the marker is missing or malformed, use `full-feature`
   - if `minor-audit` is selected and `issue.md` lacks `## Acceptance Criteria`, require remediation
 
+## Policy Rules
+
+### modified-workflow-needs-green-run
+
+If the branch diff modifies any path matching `.github/workflows/**`, `scripts/benchmarks/**`, or `.github/actions/**`, the policy audit emits a Blocking finding unless evidence of a green workflow run against the branch head is present in the remediation inputs.
+
+- The rule provides a second, independent line of defense for CI-gate-modifying features, separate from and prior to the orchestrator's S9 CI green gate.
+- "Green workflow run against the branch head" means a workflow run whose head SHA matches the current branch head and whose conclusion is success for the affected workflow.
+- A green `workflow_dispatch` run against the branch head also satisfies the rule, not only a PR-context run. This mitigates the chicken-and-egg case where a feature must land its CI gate before the gate can run in PR context (see spec.md Risks & Mitigations).
+- When the rule fires and no qualifying green-run evidence is present, record a Blocking finding and route it through the standard remediation handoff. The supporting validator `scripts/feature-review/Test-ModifiedWorkflowNeedsGreenRun.ps1` implements the trigger-path and evidence-presence logic.
+
 ## Ordered Procedure
 
 1. **Resolve the base branch**
@@ -95,12 +106,12 @@ 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`
-        - 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.
-          - Modified files (changed but previously existing): line coverage must show no regression relative to baseline and must remain >= 80%. Flag as FAIL otherwise.
-          - Repo-wide line coverage must remain >= 80% per language. Flag as FAIL otherwise.
+        - PowerShell: `mcp__drm-copilot__run_poshqc_test` → artifact: `artifacts/pester/powershell-coverage.xml`
+        - C#: `dotnet test --collect:"XPlat Code Coverage"` → artifact: `artifacts/csharp/coverage.xml`
+        - Coverage thresholds (uniform tier rule per quality-tiers.md):
+          - New code files (added in this feature): line coverage >= 85% and branch coverage >= 75%. Flag as FAIL otherwise.
+          - Modified files (changed but previously existing): line coverage >= 85%, branch coverage >= 75%, and no regression on changed lines relative to baseline. Flag as FAIL otherwise.
+          - Repo-wide per language: line coverage >= 85% and branch coverage >= 75%. Flag as FAIL otherwise.
         - If coverage artifacts already exist from the executor run, inspect them instead of re-running.
         - If no coverage artifact exists for a language that has changed files, flag as FAIL — coverage verification is mandatory for all languages with changed files.
    - Run the smallest relevant subset first when the repo policy permits it.

package/resources/claude-customizations/.claude/skills/human-exception-runbook/SKILL.md

@@ -0,0 +1,52 @@
+# 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 `.claude/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 `.claude/skills/human-exception-runbook/example.runbook.md`.