@danmoisan/drm-copilot-mcp 0.0.1 → 0.0.5

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)",
@@ -78,6 +78,10 @@
           {
             "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"
           }
         ]
       },
@@ -103,6 +107,27 @@
           {
             "type": "command",
             "command": "pwsh -NoProfile -File .claude/hooks/enforce-evidence-locations.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"
           }
         ]
       }

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/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`.

package/resources/claude-customizations/.claude/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 `.claude/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/claude-customizations/.claude/skills/invoke-csharp-engineer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 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.
+description: Invoke the csharp-typed-engineer worker to design, implement, and verify C# changes within typed repository boundaries. Applies CSharpier -> .NET Analyzers -> Nullable Analysis -> xUnit toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.
 ---
 
 # Implement C# Skill
@@ -13,7 +13,7 @@ Use this skill when:
 
 - The user requests a C# code change, bug fix, refactor, or test addition.
 - Estimated scope fits the small path (1-3 production files plus corresponding tests).
-- The toolchain (CSharpier, .NET Analyzers, Nullable Analysis, MSTest) can be run in the current environment, or the user has explicitly authorized an unverified plan-only response.
+- The toolchain (CSharpier, .NET Analyzers, Nullable Analysis, xUnit) can be run in the current environment, or the user has explicitly authorized an unverified plan-only response.
 
 If the estimated scope exceeds the small-path budget, this skill defers to the orchestrated flow via `csharp-change-budget-router` instead of proceeding directly.
 
@@ -37,10 +37,10 @@ If the estimated scope exceeds the small-path budget, this skill defers to the o
 The worker must return the following reporting block:
 
 1. Scope (exact file list).
-2. Baseline (CSharpier, .NET Analyzers, Nullable Analysis, MSTest, coverage status).
+2. Baseline (CSharpier, .NET Analyzers, Nullable Analysis, xUnit, coverage status).
 3. Plan (design and test strategy).
 4. Diffs (patch-style or full-file replacements).
-5. QA Gate Results (CSharpier, .NET Analyzers, Nullable Analysis, MSTest, and coverage deltas, or clearly marked **unverified**).
+5. QA Gate Results (CSharpier, .NET Analyzers, Nullable Analysis, xUnit, and coverage deltas, or clearly marked **unverified**).
 
 ## Worker Routing
 

package/resources/claude-customizations/.claude/skills/orchestrate/SKILL.md

@@ -24,6 +24,36 @@ On every invocation, the main session must:
 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.
 
+## Autonomous-Execution Mandate
+
+The orchestrator must achieve all actions agentically with no human interaction; full autonomy is a hard requirement. A silent manual blocker discovered at the end of a workflow is a defect, not an acceptable outcome. Every unautomatable (human-interaction) requirement must be detected early, resolved by exactly one of three permitted responses, and recorded in orchestrator state.
+
+### Detection points
+
+- Unautomatable requirements are enumerated as mandatory-unachievable requirements **before kickoff** wherever they are knowable up front.
+- Where research is needed to discover them, they MUST be surfaced **no later than the research stage**.
+- Research that touches third-party UIs (for example the Azure portal / Entra admin center, Outlook desktop or mobile, the Microsoft 365 admin center) MUST include an explicit automation-feasibility / human-interaction assessment recorded under an `## Automation Feasibility` section in the research artifact.
+
+### Three permitted responses
+
+When a step cannot be performed without a human, the orchestrator chooses exactly one response per requirement and records it in orchestrator state under `human_interaction.requirements[]`:
+
+1. **`scope_change`** — change the scope to remove the manual dependency (for example, replace a portal click with an `az` CLI step that runs unattended).
+2. **`exception`** — permit an exception. This requires emitting a human-exception runbook (see below). The exception is unresolved until its runbook file exists on disk.
+3. **`halt`** — halt until further instruction. A `halt` blocks DONE while present. A `halt` is recoverable: a later checkpoint update that resolves the requirement (to `scope_change` or a runbook-backed `exception`, or clears the halt) lifts the block.
+
+### Exception-runbook requirement
+
+On a permitted `exception`, the orchestrator emits a human-readable runbook at `<FEATURE>/runbooks/<name>.runbook.md` and records its repo-root-relative path in `human_interaction.requirements[].runbook_path`. The runbook contract — canonical path, the five required sections (Cue, Prerequisites, Step-by-step Instructions, Verification, Source and Citation), and the MCP-first / web-second sourcing rule — is defined authoritatively in `.claude/skills/human-exception-runbook/SKILL.md`.
+
+### Enforcement points
+
+The mandate is enforced mechanically, so DONE cannot be written while a human-interaction requirement is unresolved:
+
+- **Validator invariants.** The top-level `human_interaction.requirements[]` invariants — the `response` enum `scope_change` | `exception` | `halt`, and the exception-requires-runbook invariant (`response == "exception"` requires a non-empty `runbook_path`) — are enforced by `scripts/dev_tools/validate_orchestrator_state.py` and by `Test-HumanInteractionShape` in `.claude/hooks/validate-orchestrator-output.ps1`, per the documented contract in `.claude/rules/orchestrator-state.md`. Checkpoints without a `human_interaction` key stay valid, so existing checkpoints are unaffected.
+- **Completion gate.** `Test-HumanInteractionShape` in `.claude/hooks/validate-orchestrator-output.ps1` blocks DONE when a requirement has no resolved `response`, a `response` outside the enum, any `response == "halt"`, or an `exception` whose `runbook_path` is missing/empty or whose file does not exist. An absent `human_interaction` key passes.
+- **Research gate.** `Test-AutomationFeasibilitySection` in `.claude/hooks/validate-task-researcher-output.ps1` requires the `## Automation Feasibility` section for applicable autonomous-execution research artifacts and blocks otherwise; non-applicable research is unaffected.
+
 ## Delegation Model
 
 After reading `artifacts/orchestration/orchestrator-state.json`, the main session delegates work exclusively through configured workers:
@@ -51,6 +81,10 @@ Permitted `artifacts/`-rooted sub-paths (non-evidence orchestration use only):
 
 All other `artifacts/` sub-paths (e.g., `artifacts/baselines/`, `artifacts/qa/`, `artifacts/coverage/`, `artifacts/evidence/`) are FORBIDDEN for evidence output and will be blocked by the `enforce-evidence-locations.ps1` PreToolUse hook.
 
+## GitHub Actions Reusable Workflows
+
+Every new CI gate in this repository ships as a callable reusable workflow named `_<name>.yml` that declares both `on: workflow_call:` and `on: workflow_dispatch:`. Orchestrator workflows (for example `pr-pipeline.yml`) reference these callees via `uses: ./.github/workflows/_<name>.yml` and contain no inline `steps:` of their own. Cross-job filesystem reliance is not implicit; any job that needs to share files with another job must use explicit `actions/upload-artifact` + `actions/download-artifact`. The GitHub Actions reusable-workflow nesting depth cap is 4; this repository uses one level of nesting and does not introduce additional levels without an explicit design review. See `.github/workflows/README.md` for the full per-stage dispatch and branch-protection rename procedure.
+
 ## Completion Requirements
 
 The orchestrator must not report completion until:
@@ -101,16 +135,75 @@ 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.
 
+## Step S9 — CI Green Gate
+
+`S9_ci_green` runs after `S8_create_pr` and before any DONE transition. It is the structural guarantee that the orchestrator observes what GitHub Actions produces against the live PR head SHA before writing DONE. S9 applies to every feature, not only features that modify CI paths.
+
+S9 procedure:
+
+1. Resolve the live PR head SHA for the feature branch (`gh pr view --json headRefOid` or equivalent).
+2. Invoke `gh pr checks --required --json bucket,name,state,link,workflow` (or an equivalent JSON-emitting command) against that head SHA. `gh` is the only sanctioned channel for querying GitHub Actions state.
+3. Parse the JSON via `scripts/orchestration/Invoke-CiGateParser.ps1`, which emits the `ci_gate` object defined below and derives `ci_gate.conclusion` as `success` when all required checks pass, `failure` when any required check failed, and `pending` when any required check is still in progress.
+4. Poll with a bounded interval and a documented total timeout while `conclusion == "pending"`. When the timeout is exhausted, set `step9_status: "failed_remediation_required"` and enter the remediation-loop CI-failure handling below with a timeout log.
+5. Write the `ci_gate` object and `last_verified_ci_sha` to the checkpoint, and set `step9_status` to `passed` only when `ci_gate.conclusion == "success"` AND `ci_gate.head_sha` equals the current PR head SHA.
+
+DONE is not written while `step9_status` is anything other than `passed`.
+
+## Checkpoint Schema — CI Gate Fields
+
+The orchestrator checkpoint (`artifacts/orchestration/orchestrator-state.json`) is extended with:
+
+- a top-level `ci_gate` object containing:
+  - `head_sha` — the PR head SHA that the required checks were observed against.
+  - `pr_pipeline_run_id` — the GitHub Actions run id for the PR Pipeline.
+  - `pr_pipeline_run_url` — the URL of that run.
+  - `conclusion` — one of `success`, `failure`, `pending`.
+  - `verified_at` — ISO-8601 timestamp of when S9 recorded the result.
+- a top-level `last_verified_ci_sha` — the most recent head SHA for which S9 recorded a result.
+- a top-level `step9_status` — an enumeration with at minimum the values `pending`, `passed`, `failed_remediation_required`, and `blocked_ci_loop_limit`.
+
+Illustrative shape:
+
+```jsonc
+{
+  "completed_steps": ["...", "S8_create_pr", "S9_ci_green"],
+  "step9_status": "pending|passed|failed_remediation_required|blocked_ci_loop_limit",
+  "ci_gate": {
+    "head_sha": "<sha>",
+    "pr_pipeline_run_id": "<id>",
+    "pr_pipeline_run_url": "<url>",
+    "conclusion": "success",
+    "verified_at": "<iso8601>"
+  },
+  "last_verified_ci_sha": "<sha>"
+}
+```
+
+### Backward compatibility
+
+A checkpoint that predates this schema and has no `ci_gate` object (or no `step9_status`) is treated as `step9_status: "pending"`. Missing CI-gate fields are never interpreted as `passed`; the gate fails closed. The orchestrator runs S9 to populate the fields before any DONE transition.
+
+## Remediation Loop — CI-Failure Handling
+
+When S9 records `step9_status: "failed_remediation_required"` (a failed required check or an exhausted poll timeout):
+
+1. The failed-check log from `gh run view <run-id> --log-failed` (or the timeout log) is written as `remediation-inputs.<timestamp>.md` in the active feature folder.
+2. The failure is converted to a synthetic finding with severity `Blocking` that identifies the failing check by name and the failing job by URL.
+3. The existing R1-R5 remediation loop processes that finding exactly as it processes a local blocking finding. No new loop is introduced.
+4. The `remediation_pass` counter is shared with local-finding passes; the cap is 3.
+5. On the third CI-failure pass without resolution, the orchestrator records `step9_status: "blocked_ci_loop_limit"`, does not write DONE, and halts. No further automation is attempted.
+
 ## 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:
+The orchestrator must not create a PR, push a branch for PR purposes, or report work complete until all five conditions are simultaneously true:
 
 1. `blocking_findings_resolved: true` — the most recent `feature-review` produced zero blocking findings.
 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`.
+4. The checkpoint `next_step` is `S8_create_pr` (precondition to entering S9).
+5. `ci_gate.conclusion == "success"` AND `ci_gate.head_sha == current head SHA of the PR branch`. DONE is not written while either sub-condition is false.
 
-This gate is non-negotiable. Each condition is independently verified before PR creation proceeds.
+This gate is non-negotiable. Each condition is independently verified before PR creation proceeds. Conditions 1-4 are unchanged from the prior contract; condition 5 is additive.
 
 ## Step 6 Delegation — Prohibited Prompt Language