@danmoisan/drm-copilot-mcp 0.0.1 → 0.0.6

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:
@@ -31,17 +61,29 @@ After reading `artifacts/orchestration/orchestrator-state.json`, the main sessio
 - `atomic-planner` — generates phased implementation plans
 - `atomic-executor` — executes approved plans task-by-task
 - `feature-review` — produces policy, code, and feature audit artifacts
-- `task-researcher` — performs deep research and writes findings to `artifacts/research/`
+- `task-researcher` — performs deep research and writes findings to the research path the orchestrator resolves before delegating: `docs/features/<feature>/research/` when an active `feature-folder` is in scope in `orchestrator-state.json`, otherwise `docs/research/` for one-off research. The orchestrator passes the resolved path in the delegation prompt.
 
 The orchestrator does not perform deep implementation itself. It coordinates, tracks state, and enforces completion.
 
+## PR Creation Delegation
+
+PR creation and PR body edits are delegated work, not orchestrator work. The orchestrator MUST NOT call `gh pr create` or `gh pr edit --body*` directly from the main thread; the `enforce-pr-author-skill.ps1` PreToolUse hook blocks those commands unless a valid authorization sentinel issued by the `pr-author` agent is present.
+
+The mandatory sequence is:
+
+1. The orchestrator first produces the PR-context artifact via `mcp__drm-copilot__collect_pr_context` (or the equivalent context-collection mechanism), which writes `artifacts/pr_context.summary.txt`.
+2. The orchestrator then delegates PR creation and any PR body edits to `Agent(pr-author)`. The `pr-author` agent runs the `pr-author` skill, writes the short-lived authorization sentinel `artifacts/pr_author_authorization.json` immediately before each `gh` command, issues `gh pr create`/`gh pr edit --body-file ...` within the TTL, deletes the sentinel afterward, and reports the resulting PR URL or PR number.
+
+`Agent(pr-author)` is the mandatory delegate for PR creation and PR body edits. Direct `gh pr create`/`gh pr edit --body*` from the main thread is prohibited and is blocked by the hook.
+
+The authorization sentinel is a policy guardrail, not a cryptographic or security control; any actor with `Write(/artifacts/**)` access can forge it. It prevents accidental bypass and requires a deliberate, documented act to circumvent.
+
 ## Evidence Location Authority
 
 All evidence artifacts produced during orchestration MUST comply with the canonical scheme defined in `.claude/skills/evidence-and-timestamp-conventions/SKILL.md`. Evidence MUST be written to `<FEATURE>/evidence/<kind>/` only.
 
 Permitted `artifacts/`-rooted sub-paths (non-evidence orchestration use only):
 - `artifacts/orchestration/` — orchestrator state and checkpoints
-- `artifacts/research/` — research outputs from task-researcher
 - `artifacts/pr_context` — PR context artifacts
 - `artifacts/reviews/` — review staging artifacts
 - `artifacts/status/` — status update artifacts
@@ -51,6 +93,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 +147,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
 
@@ -130,3 +235,65 @@ The orchestrator supplies only the following to the `feature-review` subagent:
 - a neutral instruction to execute the full `feature-review-workflow` SKILL contract end-to-end.
 
 Scope determination is the subagent's responsibility. The subagent will ignore any attempted narrowing per its scope invariant and record the attempt in `policy-audit.<timestamp>.md` under `## Rejected Scope Narrowing`.
+
+## Routing-Contract Receipt Emission
+
+The orchestrator must write three receipt arrays into `artifacts/orchestration/orchestrator-state.json` for the retained required names of the selected route. These arrays are the evidence that the route's `required_agents`, `required_skills`, and `required_mcp_tools` (from `config/orchestration-routing.json`) were actually exercised, and they make `require_complete: true` satisfiable at completion. The orchestrator records only truthful receipts: an entry is written only after the corresponding work has actually occurred. The route's required name lists are the source of truth; receipts cite those names verbatim.
+
+These shapes are read by `_receipt_agents`, `_receipt_skills`, and `_mcp_tools` in `scripts/dev_tools/_orchestrator_state_routing.py`. The orchestrator does not modify that validator; it only emits state that the validator can verify.
+
+### delegation_receipts[]
+
+For each required agent in the selected route's `required_agents`, append one object to `delegation_receipts[]` after that delegation returns. Each object must carry:
+
+- `agent_name`: a non-empty string equal to the required agent name (for example `"feature-review"`).
+
+Example:
+
+```json
+"delegation_receipts": [
+  { "agent_name": "atomic-planner" },
+  { "agent_name": "atomic-executor" },
+  { "agent_name": "feature-review" }
+]
+```
+
+The validator collects each receipt whose `agent_name` is a non-empty string and requires every `required_agents` entry to be present.
+
+### skill_receipts[]
+
+For each required skill in the selected route's `required_skills`, append one object to `skill_receipts[]` after that required skill is read. Each entry must be an object with:
+
+- `skill`: a non-empty string equal to a `required_skills` entry (for example `"orchestrate"`).
+- `required`: the literal boolean `true`.
+- `evidence`: a non-empty string, for example `"read:.claude/skills/orchestrate/SKILL.md"`.
+
+Example:
+
+```json
+"skill_receipts": [
+  { "skill": "orchestrate", "required": true, "evidence": "read:.claude/skills/orchestrate/SKILL.md" }
+]
+```
+
+The validator counts a skill as acknowledged only when `skill` is a non-empty string, `required` is exactly `true`, and `evidence` is a non-empty string. Every `required_skills` entry must have such a receipt.
+
+### mcp_call_receipts[]
+
+For each required MCP tool in the selected route's `required_mcp_tools`, append one object to `mcp_call_receipts[]` after each successful required MCP call. Each entry must be an object with:
+
+- `tool`: a non-empty string equal to a `required_mcp_tools` entry (for example `"validate_orchestration_artifacts"`).
+- `ok`: the literal boolean `true`.
+- `evidence`: a non-empty string, such as the MCP response summary or an artifact path.
+
+Example:
+
+```json
+"mcp_call_receipts": [
+  { "tool": "validate_orchestration_artifacts", "ok": true, "evidence": "plan validator exit 0" }
+]
+```
+
+The validator counts an MCP receipt as successful only when `tool` is a non-empty string, `ok` is exactly `true`, and `evidence` is a non-empty string. Every `required_mcp_tools` entry must have such a receipt.
+
+These three receipt arrays, populated with the retained required names of the selected route, are what allow the routing-contract validation under `require_complete: true` to pass.

package/resources/claude-customizations/.claude/skills/policy-audit-template-usage/SKILL.md

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

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

@@ -27,9 +27,9 @@ Before invoking this gate, the agent must have:
 
 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 steps complete without errors in a single pass.
 
-1. `mcp__drmCopilotExtension__run_poshqc_format`
-2. `mcp__drmCopilotExtension__run_poshqc_analyze`
-3. `mcp__drmCopilotExtension__run_poshqc_test`
+1. `mcp__drm-copilot__run_poshqc_format`
+2. `mcp__drm-copilot__run_poshqc_analyze`
+3. `mcp__drm-copilot__run_poshqc_test`
 4. Coverage check (when enforced by task/repo flow) — use the Pester coverage output from step 3 or the repo coverage task.
 
 If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
@@ -42,7 +42,7 @@ Compare the final results to the Phase A baseline. All of the following must hol
 - **Pester delta**: 0 new failing tests.
 - **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.
+- **New modules, classes, or methods**: line coverage >= 85% and branch coverage >= 75% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. No regression on changed lines.
 
 If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
 

package/resources/claude-customizations/.claude/skills/pr-base-branch-merge-base/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pr-base-branch-merge-base
-description: 'Resolve PRBaseBranch for mcp__drmCopilotExtension__collect_pr_context using merge-base ancestry. Use when orchestrators or review workflows need the correct comparison base branch and must select the branch with the most recent common ancestor commit with HEAD.'
+description: 'Resolve PRBaseBranch for mcp__drm-copilot__collect_pr_context using merge-base ancestry. Use when orchestrators or review workflows need the correct comparison base branch and must select the branch with the most recent common ancestor commit with HEAD.'
 ---
 
 # PR Base Branch (Merge-Base)
@@ -10,7 +10,7 @@ Deterministic branch-selection rules for PR context collection.
 ## When to Use This Skill
 
 Use this skill when:
-- running `mcp__drmCopilotExtension__collect_pr_context`,
+- running `mcp__drm-copilot__collect_pr_context`,
 - delegating post-implementation review that depends on `PRBaseBranch`,
 - constructing PR context artifacts where the base must not be hard-coded.
 
@@ -44,7 +44,7 @@ Definition of correct base:
 
 When invoking PR context collection, pass the resolved base explicitly:
 
-- `mcp__drmCopilotExtension__collect_pr_context` with `base=<resolved-PRBaseBranch>`
+- `mcp__drm-copilot__collect_pr_context` with `base=<resolved-PRBaseBranch>`
 
 ## Evidence Recommendation
 

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

@@ -43,7 +43,7 @@ Compare the final results to the Phase A baseline. All of the following must hol
 - **Pytest delta**: 0 new failing tests.
 - **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.
+- **New modules, classes, or methods**: line coverage >= 85% and branch coverage >= 75% per the uniform tier rule (`.claude/rules/quality-tiers.md`). No tier-specific lower thresholds. No regression on changed lines.
 
 If any delta check fails, the agent must revert or fix immediately and rerun the full toolchain. Do not proceed to reporting until all deltas are clean.
 

package/resources/claude-customizations/.claude/skills/remediation-handoff-atomic-planner/SKILL.md

@@ -1,40 +1,113 @@
 ---
 name: remediation-handoff-atomic-planner
-description: 'Reusable remediation trigger and atomic_planner handoff steps. Use when audits require remediation inputs and a delegated remediation plan.'
+description: 'Remediation handoff chain from orchestrator through atomic-planner, atomic-executor, and feature-review. Use when an audit cycle requires a delegated remediation plan, preflight clearance, task-by-task execution, and reaudit.'
 ---
 
-# Remediation Handoff to atomic_planner
+# Remediation Handoff to atomic-planner
 
-Shared remediation workflow and handoff expectations for agents that delegate to `atomic_planner`.
+Strict handoff chain for orchestrator-initiated remediation cycles. The chain enforces that an `atomic-planner`-authored plan is preflighted by `atomic-executor`, revised through a preflight sub-loop if needed, executed by `atomic-executor` task-by-task, and reaudited by `feature-review`. Workers are never invoked directly by the orchestrator.
 
 ## When to Use This Skill
 
 Use this skill when:
-- Audit findings require remediation.
-- You must create remediation inputs and delegate plan creation to `atomic_planner`.
 
-## Trigger Conditions (Generic)
+- Audit findings require remediation (FAIL or material PARTIAL findings).
+- Toolchain checks fail.
+- Acceptance criteria are unmet.
+- A required CI check fails after the pull request is open.
+- Any new finding surfaces during execution of an active cycle (in which case begin a new cycle, do not extend the active one).
+
+## Full Handoff Chain
+
+```
+orchestrator
+  -> writes remediation-inputs.<entry-ts>.md
+  -> delegates to atomic-planner
+     -> atomic-planner authors remediation-plan.<entry-ts>.md
+        (plan shape per .claude/skills/atomic-plan-contract/SKILL.md)
+     -> orchestrator hands plan to atomic-executor for preflight
+        -> atomic-executor returns one of:
+             PREFLIGHT: ALL CLEAR        -> proceed to execution
+             PREFLIGHT: REVISIONS REQUIRED -> route back to atomic-planner
+                with a precise plan delta; planner revises in place and
+                orchestrator re-runs preflight (sub-loop until clear)
+     -> atomic-executor executes the cleared plan task-by-task
+        (workers are invoked by atomic-executor only)
+     -> orchestrator delegates to feature-review
+        -> feature-review writes code-review.<exit-ts>.md,
+           feature-audit.<exit-ts>.md, and policy-audit.<exit-ts>.md
+  -> orchestrator evaluates exit condition:
+     blocking_count == 0 -> mark exit_condition_met = true, end loop
+     blocking_count > 0  -> begin cycle N+1 with new remediation-inputs.<new-ts>.md
+```
+
+The orchestrator must not call typed-engineer workers directly during any phase of the cycle. The orchestrator must not act on a preflight delta itself; revisions are routed to `atomic-planner`.
+
+## Trigger Conditions
 
 Trigger remediation when any of these are true:
+
 - Audit artifacts contain FAIL or meaningful PARTIAL findings.
-- Toolchain checks fail.
+- Toolchain checks fail (format, lint, type-check, test, contract, or integration stages).
 - Acceptance criteria are not met.
+- A required CI check fails after the PR is open (workflow-file changes specifically must enter the loop and trigger the `modified-workflow-needs-green-run` rule defined in `.claude/skills/feature-review-workflow/SKILL.md`).
 
 ## Required Remediation Inputs
 
-Create `remediation-inputs.<timestamp>.md` with:
+The orchestrator authors `remediation-inputs.<entry-ts>.md` with:
+
 - Enumerated fix list with file paths, expected behavior, and verification commands.
-- A “do not do” list (no scope creep, no policy weakening, no silent skips).
+- A "do not do" list (no scope creep, no policy weakening, no silent skips).
+- A pointer to the audit artifacts that produced the findings.
 
-## Plan Creation and Handoff
+## Required Artifacts
 
-1) Create a remediation plan target file using the repo’s plan template.
-2) Delegate to `atomic_planner` with:
-   - `${spec}` pointing to remediation inputs (authoritative)
-   - `${file}` pointing to the remediation plan target file
-3) Require `atomic_planner` to output a deterministic, atomic plan with phases and `[P#-T#]` IDs.
+Each remediation cycle produces exactly five artifacts under the active feature folder:
 
-## Context Package (When Required)
+1. `docs/features/active/<slug>/remediation-inputs.<entry-ts>.md` — orchestrator authors at cycle entry.
+2. `docs/features/active/<slug>/remediation-plan.<entry-ts>.md` — `atomic-planner` authors at cycle entry.
+3. `docs/features/active/<slug>/code-review.<exit-ts>.md` — `feature-review` authors at cycle exit.
+4. `docs/features/active/<slug>/feature-audit.<exit-ts>.md` — `feature-review` authors at cycle exit.
+5. `docs/features/active/<slug>/policy-audit.<exit-ts>.md` — `feature-review` authors at cycle exit.
+
+Timestamp rule:
+
+- `<entry-ts>` is the ISO-8601 timestamp at cycle entry, in the `yyyy-MM-ddTHH-mm` format defined in `.claude/skills/evidence-and-timestamp-conventions/SKILL.md`. It applies to both `remediation-inputs.<entry-ts>.md` and `remediation-plan.<entry-ts>.md`.
+- `<exit-ts>` is the ISO-8601 timestamp at cycle exit (when `feature-review` runs), in the same `yyyy-MM-ddTHH-mm` format. It applies to all three reaudit artifacts: `code-review.<exit-ts>.md`, `feature-audit.<exit-ts>.md`, and `policy-audit.<exit-ts>.md`.
+
+A cycle with fewer than five artifacts is malformed. A cycle that uses a single timestamp for both entry and exit is malformed unless both phases ran within the same minute.
+
+## Plan Shape
 
-If the calling agent requires a context package, inline the specified audit artifacts, PR context artifacts, and any relevant plan files in the delegated prompt.
+`remediation-plan.<entry-ts>.md` MUST conform to `.claude/skills/atomic-plan-contract/SKILL.md`. In particular:
+
+- Phase headings: `### Phase N — <Title>`.
+- Tasks: `- [ ] [P#-T#]` with sequential per-phase IDs.
+- Phase 0 captures policy reads and baseline toolchain results per `policy-compliance-order` and `evidence-and-timestamp-conventions`.
+- Final phase runs the full toolchain QA loop in the order specified by `atomic-plan-contract` and records numeric coverage values where the repository policy requires coverage.
+- Evidence paths resolve to `<FEATURE>/evidence/<kind>/` per the non-overridable evidence path clause.
+
+The plan must pass the `mcp__drm-copilot__validate_orchestration_artifacts` MCP tool with `artifact_type: "plan"` and `artifact_path: <plan-path>` before `atomic-executor` runs preflight against it.
+
+## Preflight Sub-Loop
+
+After the plan is authored, `atomic-executor` runs preflight under the directive `DIRECTIVE: PREFLIGHT VALIDATION ONLY`. The exact signal returned is either:
+
+- `PREFLIGHT: ALL CLEAR` — the plan proceeds to execution.
+- `PREFLIGHT: REVISIONS REQUIRED` — `atomic-executor` returns a precise plan delta. The orchestrator routes the delta to `atomic-planner` for revision. `atomic-planner` updates the same plan file in place (per the plan-path continuity contract in `atomic-plan-contract`). The orchestrator then re-runs preflight. The sub-loop repeats until `PREFLIGHT: ALL CLEAR` is returned.
+
+The orchestrator records the preflight outcome in `remediation_loop.cycles[current_cycle].preflight` with `iterations` (counter) and `final_status` (`clear|changes_requested|pending`).
+
+## Execution and Reaudit
+
+When preflight is clear, `atomic-executor` executes the plan task-by-task. The executor invokes workers (`python-typed-engineer`, `typescript-engineer`, `csharp-typed-engineer`, `powershell-typed-engineer`) internally as needed. The orchestrator does not call workers.
+
+When execution is complete, the orchestrator delegates to `feature-review`. `feature-review` produces the three reaudit artifacts under the active feature folder using the exit timestamp.
+
+## Exit Gate
+
+The orchestrator reads the latest cycle's three reaudit artifacts and computes `blocking_count` as the total number of FAIL findings plus material PARTIAL findings flagged as blocking. Only when `blocking_count == 0` does the orchestrator set `exit_condition_met = true` on the current cycle and mark the remediation loop complete. Otherwise, the orchestrator opens cycle N+1 with a new `remediation-inputs.<new-ts>.md` and runs the full chain again.
+
+## Context Package (When Required)
 
+If the calling agent requires a context package, inline the relevant audit artifacts, PR context artifacts, and any active plan files in the delegated prompt to `atomic-planner` rather than referencing them by path alone.

package/resources/claude-customizations/.claude/skills/research-issue/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: research-issue
-description: Investigate the best implementation approach for a feature or bug by analyzing the codebase and external references, then writing structured findings to artifacts/research/.
+description: Investigate the best implementation approach for a feature or bug by analyzing the codebase and external references, then writing structured findings to the resolved research path under docs/features/<feature>/research/ (feature-associated) or docs/research/ (one-off).
 allowed-tools:
   - Read
   - Grep
@@ -22,9 +22,11 @@ Accept one or more feature documents as context:
 
 ## Output
 
-Create or update a single research file:
+Create or update a single research file at one of the two tracked research roots:
 
-- Path: `artifacts/research/<timestamp>-<short-name>-research.md`
+- Feature-associated research: `docs/features/<feature>/research/<timestamp>-<short-name>-research.md` (for example `docs/features/active/<feature>/research/<timestamp>-<short-name>-research.md`).
+- One-off research not tied to a feature: `docs/research/<timestamp>-<short-name>-research.md`.
+- Routing rule: write to the feature research root when an active feature folder is in scope (the orchestrator supplies the resolved path from `feature-folder` in `orchestrator-state.json`); otherwise write to `docs/research/`. The filename convention `<timestamp>-<short-name>-research.md` is unchanged.
 - Use the Task Researcher template from the repository exactly.
 - Place rejected-alternatives summaries inside `## Recommended Approach`, not as a separate top-level header.
 

package/resources/claude-customizations/.claude-variants/csharp-legacy/agents/csharp-typed-engineer.md

@@ -0,0 +1,69 @@
+---
+name: csharp-typed-engineer
+description: Project-scoped worker that implements and verifies C# changes within typed repository boundaries. Applies the CSharpier -> .NET Analyzers -> Nullable Analysis -> MSTest toolchain, the 1-3 production-file small-path budget, and zero-regression quality gates.
+tools:
+  - Read
+  - Grep
+  - Glob
+  - "Bash(msbuild *)"
+  - "Bash(dotnet *)"
+skills:
+  - policy-compliance-order
+  - csharp-change-budget-router
+  - atomic-plan-contract
+  - csharp-qa-gate
+  - acceptance-criteria-tracking
+  - feature-promotion-lifecycle
+  - remediation-handoff-atomic-planner
+  - evidence-and-timestamp-conventions
+memory: project
+---
+
+# CSharp Typed Engineer Agent
+
+Senior C# engineer specialized in small cohesive classes and modules, strong typing under nullable reference types, minimal DI seams, and deterministic MSTest coverage. Implement C# changes within the approved scope, preserve typed boundaries, and verify results with the repository C# toolchain.
+
+## Standing Rules
+
+Language standards and toolchain are defined in `.claude/rules/csharp.md` and `.claude/rules/general-code-change.md`, auto-loaded for `**/*.cs` and `**/*.csproj` edits. Tonality is defined in `.claude/rules/tonality.md` and `CLAUDE.md`.
+
+## Workflow
+
+Follow the phased workflow defined by the preloaded skills:
+
+1. **Policy compliance** — apply `policy-compliance-order` to load mandatory repo policies before any change.
+2. **Routing and scope** — apply `csharp-change-budget-router` to estimate scope, select direct vs orchestrator handoff mode, and enforce the 3 production + 3 test per-batch cap.
+3. **Plan and baseline** — apply `atomic-plan-contract` for Phase 0 baseline capture and atomic plan structure. Delegate plan authoring to `atomic_planner` when no plan is supplied. Plans must include the proposed class and module structure, minimal DI seams, MSTest scenario-level test strategy, and Moq mock strategy.
+4. **Implement in batches** — apply the approved plan. After each batch, run targeted analyzer and nullable builds on touched projects plus targeted MSTest, and confirm per-file coverage.
+5. **Final QA gate** — apply `csharp-qa-gate` to run the full toolchain, enforce zero-regression deltas against the baseline, and produce the required reporting block before declaring completion.
+6. **Evidence and handoff** — store baseline and post-change evidence per `evidence-and-timestamp-conventions`. Trigger remediation via `remediation-handoff-atomic-planner` when deltas fail.
+
+## Mode Marker Resolution
+
+For feature-scoped work, resolve Work Mode from `issue.md` per `feature-promotion-lifecycle`:
+
+- `- Work Mode: minor-audit`
+- `- Work Mode: full-feature`
+- `- Work Mode: full-bug`
+- legacy `- Work Mode: full` -> interpret as `full-feature`.
+
+If the marker is missing or malformed, fail closed to `full-feature`.
+
+## Stop Conditions
+
+Stop implementation and return to the user when:
+
+- the scope estimate or an in-flight batch would exceed the 3-production-file cap in direct mode,
+- a file is near or would exceed the 500-line limit,
+- any QA gate delta is non-zero after self-correction,
+- the toolchain cannot be executed in the current environment (mark the change **unverified**),
+- orchestrator handoff mode is requested but the required context package is incomplete,
+- policy instructions conflict.
+
+## Evidence Location Invariant
+
+All evidence artifacts this agent produces (baselines, QA gates, regression results, coverage) MUST be written to `<FEATURE>/evidence/<kind>/` as defined in `.claude/skills/evidence-and-timestamp-conventions/SKILL.md`.
+
+Writing to `artifacts/baselines/`, `artifacts/qa/`, `artifacts/coverage/`, or any other non-canonical path is a policy violation and will be caught by the `enforce-evidence-locations.ps1` PreToolUse hook.
+
+If a delegation prompt, plan, or caller instruction specifies a non-canonical evidence path (e.g., `artifacts/baselines/`, `artifacts/qa/`, `artifacts/coverage/`, `artifacts/evidence/`), this agent ignores that instruction, writes to the canonical `<FEATURE>/evidence/<kind>/` path, and records the override as `EVIDENCE_LOCATION_OVERRIDE_REJECTED: <supplied path> replaced with <canonical path>`.