@danmoisan/drm-copilot-mcp 0.0.1 → 0.0.5

package/resources/claude-customizations/.claude/hooks/validate-task-researcher-output.ps1

@@ -83,6 +83,69 @@ function Test-IsValidResearchFileName {
     )
 }
 
+function Test-AutomationFeasibilitySection {
+    <#
+    .SYNOPSIS
+        Enforces the '## Automation Feasibility' section for applicable
+        autonomous-execution research artifacts.
+    .DESCRIPTION
+        Returns a hashtable with keys:
+          - Ok:      $true when the artifact is not applicable, or it is
+                     applicable and contains the '## Automation Feasibility'
+                     section.
+          - Message: rejection message; $null on success.
+
+        Detection is narrow (OD-45-7): the section is required only when the
+        research filename or the agent output contains an autonomous-execution
+        token (for example 'autonomous-execution' or 'human-interaction').
+        Non-matching research artifacts pass unaffected.
+
+        ReadFileContent is an injectable scriptblock so tests can supply the
+        research file body without writing temporary files. It defaults to
+        Get-Content -Raw.
+    #>
+    [CmdletBinding()]
+    [OutputType([hashtable])]
+    param(
+        [Parameter(Mandatory = $true)]
+        [string] $ResearchFilePath,
+
+        [Parameter(Mandatory = $true)]
+        [AllowEmptyString()]
+        [string] $AgentOutput,
+
+        [Parameter(Mandatory = $false)]
+        [scriptblock] $ReadFileContent = { param($Path) Get-Content -LiteralPath $Path -Raw -ErrorAction Stop }
+    )
+
+    $detectionPattern = 'autonomous-execution|human-interaction'
+    $fileName = [System.IO.Path]::GetFileName(($ResearchFilePath -replace '\\', '/'))
+
+    $isApplicable = ([regex]::IsMatch($fileName, $detectionPattern, [System.Text.RegularExpressions.RegexOptions]::IgnoreCase)) -or
+    ([regex]::IsMatch($AgentOutput, $detectionPattern, [System.Text.RegularExpressions.RegexOptions]::IgnoreCase))
+
+    if (-not $isApplicable) {
+        return @{ Ok = $true; Message = $null }
+    }
+
+    $content = & $ReadFileContent $ResearchFilePath
+    if ([string]::IsNullOrWhiteSpace($content)) {
+        return @{ Ok = $false; Message = "task-researcher hook: autonomous-execution research artifact '$ResearchFilePath' is empty; it must include an '## Automation Feasibility' section." }
+    }
+
+    $hasSection = [regex]::IsMatch(
+        $content,
+        '(?m)^\s{0,3}#{2,}\s+Automation\s+Feasibility\s*$',
+        [System.Text.RegularExpressions.RegexOptions]::IgnoreCase
+    )
+
+    if (-not $hasSection) {
+        return @{ Ok = $false; Message = "task-researcher hook: autonomous-execution research artifact '$ResearchFilePath' is missing the required '## Automation Feasibility' section." }
+    }
+
+    return @{ Ok = $true; Message = $null }
+}
+
 function Invoke-TaskResearcherOutputValidation {
     [CmdletBinding()]
     [OutputType([hashtable])]
@@ -126,6 +189,11 @@ function Invoke-TaskResearcherOutputValidation {
         return @{ Ok = $false; Message = "task-researcher hook: researcher advertised research-path '$researchPath' but no file exists at that location." }
     }
 
+    $feasibilityResult = Test-AutomationFeasibilitySection -ResearchFilePath $researchPath -AgentOutput $agentOutput
+    if (-not $feasibilityResult.Ok) {
+        return @{ Ok = $false; Message = $feasibilityResult.Message }
+    }
+
     return @{ Ok = $true; Message = $null }
 }
 

package/resources/claude-customizations/.claude/rules/architecture-boundaries.md

@@ -0,0 +1,46 @@
+---
+paths:
+  - "**/*.ts"
+  - "**/*.cs"
+description: Architecture boundary enforcement rules for the No-COM architecture.
+---
+
+# Architecture Boundaries
+
+Architecture boundary enforcement is a uniform gate across all tiers (T1–T4). Violations block PRs.
+
+## Enforcement Tools
+
+- **TypeScript:** `dependency-cruiser`. Configuration file pattern: `.dependency-cruiser.cjs`.
+- **.NET (when the backend exists):** `NetArchTest.Rules`. Test project naming pattern: `*.ArchitectureTests`.
+
+## No-COM Architecture Rules (enforceable assertions)
+
+Production code in this repository must satisfy each of the following assertions. Each assertion is enforced by `dependency-cruiser` (TypeScript) or `NetArchTest.Rules` (.NET) where applicable; legacy import utilities, when added, must satisfy the same assertions.
+
+1. New runtime code must not reference VSTO APIs (`Microsoft.Office.Tools.*`).
+2. New runtime code must not reference Outlook desktop automation APIs (`Microsoft.Office.Interop.Outlook`).
+3. New runtime code must not expose COM-visible interfaces (`[ComVisible(true)]` attribute is banned in production code).
+4. New runtime code must not use Ribbon extensibility callbacks tied to the desktop object model.
+5. New runtime code must not depend on local Outlook event streams.
+6. New runtime code must not depend on Outlook user-defined fields as the primary state store.
+7. Mailbox data must be accessed only through Office.js or Microsoft Graph.
+8. Business behavior must be implemented in the backend or in host-neutral domain or application modules.
+9. Client UI must be implemented as web UI.
+10. Legacy integration, when required, must be limited to offline data import from files or exported data.
+
+## Layer Boundary Assertions (TypeScript)
+
+- `src/taskpane/` and `src/commands/` must not import from backend internals.
+- Domain modules must not import from Office.js, Microsoft Graph SDK, or any infrastructure adapter.
+- Adapters may import from domain; domain must not import from adapters.
+
+## Layer Boundary Assertions (.NET, applies once the backend exists)
+
+- `TaskMaster.Domain` must have zero references to Outlook PIA, VSTO, or Office.js types.
+- `TaskMaster.Application` may depend on `TaskMaster.Domain` only.
+- Adapter projects may depend on `TaskMaster.Domain` and `TaskMaster.Application`; domain may not depend on adapters.
+
+## Enforcement Outcome
+
+Violations of any rule above are PR-blocking findings. CI runs the architecture-boundary stage on every PR; a non-zero violation count fails the stage and prevents merge.

package/resources/claude-customizations/.claude/rules/benchmark-baselines.md

@@ -0,0 +1,35 @@
+# Benchmark Baseline Provenance
+
+This rule governs performance baselines used by benchmark regression gates. It exists because a baseline captured on a developer workstation was compared against a `windows-latest` runner, producing deterministic latency regressions that the benchmark gate could not survive (issue #26, PR #30).
+
+## Runner-Environment Parity (Required)
+
+Performance baselines must be captured in the same runner environment class against which they are compared. A baseline captured on a developer workstation must not be committed for comparison against a CI runner.
+
+## Prohibited: Unknown Processor
+
+A baseline whose `HostEnvironmentInfo.ProcessorName` is the literal string `"Unknown processor"` is rejected. This value indicates the baseline was captured in an environment where the processor could not be identified (typically a virtualized or developer workstation), which violates runner-environment parity.
+
+- Tooling MUST reject any baseline JSON where `HostEnvironmentInfo.ProcessorName == "Unknown processor"`.
+- The rejection is a Blocking finding; the baseline must be recaptured on the target runner class.
+
+## Required: Sibling Provenance File
+
+Every committed baseline file MUST have a sibling `baseline.provenance.json` in the same directory. The provenance file records, at minimum:
+
+- `runner_class` — the runner environment class that produced the baseline (for example `windows-latest`).
+- `host_signature` — a stable signature of the host (for example a hashed or labeled description of the CPU/core configuration).
+- `workflow_run_url` — the URL of the workflow run that produced the baseline.
+
+- Tooling MUST reject a baseline that has no sibling `baseline.provenance.json`.
+- The rejection is a Blocking finding; the baseline must be recaptured with provenance recorded.
+
+## Enforcement
+
+- The validator `scripts/benchmarks/Test-BaselineProvenance.ps1` enforces both rejection conditions above and accepts a runner-captured baseline whose `ProcessorName` is a real processor and whose sibling `baseline.provenance.json` is present.
+- The feature-review policy rule `modified-workflow-needs-green-run` (see `.claude/skills/feature-review-workflow/SKILL.md`) provides a second line of defense: a diff under `scripts/benchmarks/**` is Blocking unless a green workflow run against the branch head is present in remediation inputs.
+
+## Scope
+
+- This rule applies to any baseline consumed by a benchmark regression gate.
+- It does not change which checks are required by branch protection; it constrains the provenance of the data those checks consume.

package/resources/claude-customizations/.claude/rules/ci-workflows.md

@@ -0,0 +1,36 @@
+# CI Workflow Authoring
+
+This rule governs GitHub Actions workflow steps that run PowerShell (`pwsh`). It exists because a `pwsh` step that intentionally invoked a failing nested command left `$LASTEXITCODE == 1` after its verification logic had already succeeded, leaking a failure to GitHub Actions even though the step's intent was satisfied (issue #26, PR #30).
+
+## Deliberately-Failing Nested Command Pattern (Required)
+
+A workflow step whose `run:` block intentionally invokes a command expected to fail — for example a negative-path self-validation that asserts a gate catches a synthetic regression — MUST not allow the residual non-zero exit code to propagate to GitHub Actions.
+
+For any such step, the `run:` block MUST do one of the following:
+
+1. Reset the exit code explicitly after the expected failure:
+   ```powershell
+   & ./some-tool --expect-failure
+   $LASTEXITCODE = 0
+   ```
+2. Or terminate the success path with an explicit zero exit:
+   ```powershell
+   if ($verificationSucceeded) { exit 0 } else { exit 1 }
+   ```
+
+A `pwsh` step terminates with the exit code of the last external command unless the script explicitly resets it or calls `exit`. Negative-path verification steps therefore require an explicit reset or explicit `exit 0`.
+
+## Rationale
+
+- GitHub Actions interprets a step's process exit code as the step result. A leaked `$LASTEXITCODE` from an intentionally-failing nested command causes a passing verification to report failure.
+- No local toolchain stage executes a workflow's `run:` block, so this defect is invisible to local feature-review. This textual rule is the artifact local review cites when reading workflow YAML.
+
+## Enforcement
+
+- Local feature-review cites this rule when reviewing diffs that add or modify `pwsh` steps with deliberately-failing nested commands.
+- The feature-review policy rule `modified-workflow-needs-green-run` (see `.claude/skills/feature-review-workflow/SKILL.md`) requires a green workflow run against the branch head before a workflow change can merge, which exercises the exit-code path on the runner.
+
+## Scope
+
+- This rule applies to any workflow step whose `run:` block uses `shell: pwsh` (or the repo default `pwsh`) and intentionally invokes a failing nested command.
+- It does not change required-check configuration or branch protection.

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

@@ -2,43 +2,83 @@
 paths:
   - "**/*.cs"
   - "**/*.csproj"
-description: C#-specific toolchain and coding standards.
+description: C#-specific toolchain and coding standards (No-COM, xUnit).
 ---
 
 # C# Code Standards
 
-This rule file summarizes the C#-specific policies for this repository.
+This rule file summarizes the C#-specific policies for this repository. It targets the No-COM .NET foundation: xUnit, NSubstitute, FluentAssertions, `dotnet build`, the analyzer stack, `TimeProvider`, and uniform coverage thresholds.
 
 ## Toolchain
 
-1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Command: `dotnet tool run csharpier .` or `csharpier .`
-2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true`
-3. **Type Checking — Nullable Analysis**: Enable nullable reference types and fail on warnings. Command: `msbuild TaskMaster.sln /t:Build /p:Configuration=Debug /p:Platform="Any CPU" /p:Nullable=enable /p:TreatWarningsAsErrors=true`
-4. **Testing — MSTest + Moq + FluentAssertions**: Run tests with: `vstest.console.exe <test-assembly-paths> /EnableCodeCoverage`
+1. **Formatting — CSharpier**: All C# source files must be formatted with CSharpier. Do not use `dotnet format`. Command: `dotnet tool restore` followed by `dotnet csharpier check .` (or `dotnet csharpier .` to auto-format).
+2. **Linting — .NET Analyzers**: C# code must pass Roslyn/.NET analyzer diagnostics. Analyzer enforcement is centralized in `Directory.Build.props` (`AnalysisLevel=latest-all`, `AnalysisMode=All`, `TreatWarningsAsErrors=true`). Command: `dotnet build` runs analyzers as part of the build.
+3. **Type Checking — Nullable Analysis**: Nullable reference types are enabled solution-wide via `Directory.Build.props` (`Nullable=enable`, `TreatWarningsAsErrors=true`). Command: `dotnet build` enforces nullable warnings as errors.
+4. **Testing — xUnit + NSubstitute + FluentAssertions**: Run tests with: `dotnet test --collect:"XPlat Code Coverage"`.
 
-Run the toolchain in order: format → lint → type-check → test. Restart from step 1 if any step fails or changes files.
+Run the toolchain in order: format → lint → type-check → architecture → test. Restart from step 1 if any step fails or changes files.
 
 ## Coding Standards
 
-- **Naming**: `PascalCase` for types and public members. `camelCase` for locals and private fields/parameters.
+- **Naming**: `PascalCase` for types and public members. `camelCase` for locals and private fields/parameters. Private fields use `_camelCase`. Interfaces use the `I` prefix. Async methods carry the `Async` suffix.
 - **Null safety**: Keep nullable reference types enabled. Model optional values with nullable annotations and guard clauses.
 - **Composition over inheritance**: Keep classes cohesive and scoped to one responsibility. Favor composition unless polymorphism is a clear requirement.
 - **Async/await**: Use `async`/`await` for I/O-bound operations. Prefer `using`/`await using` for disposable resources.
 - **Exceptions**: Fail fast with explicit exceptions. Avoid broad `catch (Exception)` unless at a defined boundary with added context.
 - **Public surface**: Keep public API surface intentional and minimal. Prefer `internal` for non-public APIs.
 - **XML docs**: Public APIs should include XML documentation comments when behavior or contract is non-obvious.
+- **File-scoped namespaces**: Required (`csharp_style_namespace_declarations = file_scoped:error` in `.editorconfig`).
 
 ## Testing Standards
 
-- Use **MSTest** (`Microsoft.VisualStudio.TestTools.UnitTesting`) as the test framework.
-- Use **Moq** for mocking.
-- Prefer **FluentAssertions** for assertions; use MSTest `Assert` only when FluentAssertions is not practical.
-- Use `[TestClass]` and `[TestMethod]` attributes.
+- Use **xUnit** as the test framework with `[Fact]` and `[Theory]` attributes.
+- Use **`[Theory]` + `[InlineData]`** for parameterized tests.
+- Use **`IClassFixture<T>`** to share expensive setup across tests within a class.
+- Use **NSubstitute** for test doubles. Example: `var sut = Substitute.For<IService>(); sut.Get().Returns(value);`.
+- Prefer **FluentAssertions** for assertions; use xUnit `Assert` only when FluentAssertions is not practical.
 - Follow Arrange–Act–Assert structure.
 - No external dependencies in unit tests.
-- Repository-wide line coverage must remain >= 80%.
-- Any new module, class, or method must reach >= 90% coverage.
+
+### Coverage
+
+- Line coverage line >= 85% and branch coverage branch >= 75% uniform across all tiers (T1–T4). No tier-specific lower floor is used.
+- Mutation score mutation >= 75% on T1 modules (via Stryker.NET).
 - Coverage regression on changed lines is a blocking finding.
+- Interface-only files with no executable behavior — files consisting solely of `interface` declarations or abstract contracts — 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.
+
+### Property-Based and Mutation Testing
+
+- **CsCheck**: at least one property-based test per pure function on T1 and T2 modules.
+- **Stryker.NET**: mutation testing required on T1 modules with a mutation score mutation >= 75%. Runs in pre-merge or nightly pipelines.
+
+### Golden Tests
+
+- **Verify.Xunit**: required for T1 classifier-output modules, tested against a versioned corpus.
+
+## Analyzer Stack
+
+All projects reference the following analyzer packages via `<PackageReference>` with `PrivateAssets="all"` (versions pinned centrally in `Directory.Packages.props`):
+
+- `Meziantou.Analyzer` — `PrivateAssets="all"`
+- `SonarAnalyzer.CSharp` — `PrivateAssets="all"`
+- `Roslynator.Analyzers` — `PrivateAssets="all"`
+- `AsyncFixer` — `PrivateAssets="all"`
+- `SecurityCodeScan.VS2019` — `PrivateAssets="all"`
+- `Microsoft.CodeAnalysis.BannedApiAnalyzers` — `PrivateAssets="all"`
+
+The shared `<ItemGroup>` lives in `Directory.Build.props` so the stack applies to every project automatically.
+
+## Banned APIs
+
+The following APIs are banned outside an explicit allowlist; enforcement is via `Microsoft.CodeAnalysis.BannedApiAnalyzers` against `BannedSymbols.txt` (at solution root, wired through `Directory.Build.props` as an `<AdditionalFiles>` entry):
+
+- `DateTime.Now` (use `TimeProvider.GetLocalNow()` on an injected `TimeProvider`).
+- `DateTime.UtcNow` (use `TimeProvider.GetUtcNow()` on an injected `TimeProvider`).
+- `Random.Shared` (inject a seeded `Random` or use a deterministic seam).
+- `Thread.Sleep` (banned; use cooperative awaits and fake-time advancement).
+- `Task.Delay` (banned in production paths; tests must use `FakeTimeProvider`).
+
+Tests inject `TimeProvider` via `Microsoft.Extensions.TimeProvider.Testing`'s `FakeTimeProvider` rather than calling `DateTime.UtcNow` or `Task.Delay` directly.
 
 ## Deterministic Test Rules
 
@@ -48,9 +88,15 @@ Unit tests must not depend on network, mutable machine PATH or profile state, im
 
 Introduce the smallest seam that enables reliable unit testing. Apply in this order of preference:
 
-1. **Interface seam (preferred)** — extract boundary calls into narrow purpose-specific interfaces (for example, `IProcessRunner`, `IFileSystem`, `IClock`). Keep interfaces minimal.
+1. **Interface seam (preferred)** — extract boundary calls into narrow purpose-specific interfaces (for example, `IProcessRunner`, `IFileSystem`). Keep interfaces minimal.
 2. **Injectable delegate seam** — use a narrow `Func<>`/`Action<>` delegate for a single call path when a full interface is excessive. Default behavior must remain safe and deterministic.
-3. **Adapter seam for static or third-party APIs** — wrap the static or third-party call behind a small adapter so tests can mock the adapter with Moq.
+3. **Adapter seam for static or third-party APIs** — wrap the static or third-party call behind a small adapter so tests can substitute the adapter with NSubstitute.
+
+### Clock Seam
+
+- **`TimeProvider` is preferred** for new code (since .NET 8). Inject `TimeProvider` and use `GetUtcNow()` / `GetLocalNow()` / `CreateTimer()`.
+- Test code injects `FakeTimeProvider` from **`Microsoft.Extensions.TimeProvider.Testing`** to advance simulated time deterministically.
+- `IClock` legacy: acceptable only in legacy or pre-.NET 8 contexts that have not yet been migrated. New code must use `TimeProvider`.
 
 ## Prohibited Behaviors
 

package/resources/claude-customizations/.claude/rules/general-code-change.md

@@ -24,16 +24,25 @@ Apply these priorities in order when designing or changing code:
 - Keep methods small and focused. Avoid god objects.
 - Use interfaces/abstract types/protocols when multiple implementations are likely.
 
+## Module Rigor Tiers
+
+Module rigor tiers (T1–T4) and the uniform-versus-tier-dependent gate matrix are defined in `.claude/rules/quality-tiers.md`. Every project must be classified in `quality-tiers.yml` at repo root.
+
 ## Mandatory Toolchain Loop
 
-Run the full toolchain in this exact order and repeat until all steps pass in a single pass:
+Run the full seven-stage toolchain in this exact order and repeat until all stages pass in a single pass:
 
 1. **Formatting** (e.g., Black, Prettier, CSharpier, Invoke-Formatter)
 2. **Linting** (e.g., Ruff, ESLint, PSScriptAnalyzer, .NET analyzers)
 3. **Type checking** (e.g., Pyright, TSC, nullable analysis; skip for PowerShell)
-4. **Testing** (e.g., Pytest, Jest, MSTest, Pester)
+4. **Architecture-boundary tests** (e.g., dependency-cruiser, NetArchTest.Rules)
+5. **Unit tests** (e.g., Pytest, Vitest, MSTest, Pester) including property-based tests where applicable per `quality-tiers.md`
+6. **Contract / schema compatibility checks** (e.g., oasdiff, schema-snapshot diff)
+7. **Integration tests**
+
+**Restart from step 1** if any stage fails or auto-fixes any files. Do not stop the loop until all seven stages complete without errors in a single pass.
 
-**Restart from step 1** if any step fails or auto-fixes any files. Do not stop the loop until all four steps complete without errors in a single pass.
+Mutation testing and golden tests run in pre-merge or nightly pipelines, not the per-commit loop.
 
 ## File Size Limit
 

package/resources/claude-customizations/.claude/rules/general-unit-test.md

@@ -20,11 +20,30 @@ Every unit test must satisfy all five of these properties:
 
 ## Coverage Requirements
 
-- **Repository-wide line coverage must remain >= 80%.**
-- **Any new module, class, or method must target >= 90% coverage.**
+- **Line coverage must remain >= 85% across all tiers (T1–T4).**
+- **Branch coverage must remain >= 75% across all tiers (T1–T4).**
 - Code changes or refactors must not reduce coverage for the lines that were changed.
+- Tier-specific lower coverage thresholds are not used in this repository. See `.claude/rules/quality-tiers.md` for the full tier system.
 - Coverage is a supporting metric, not the sole quality gate. Untested critical behavior is not acceptable even if the overall percentage looks good.
 - Configure coverage tooling to exclude test files (e.g., `tests/`) so metrics reflect application code, not tests.
+- Type-only / interface-only modules with no executable behavior may be omitted from coverage measurement. Examples: Python `Protocol`-only modules consumed only under `TYPE_CHECKING`, TypeScript interface/type-only files, and C# interface-only files. Such modules legitimately report 0% executable coverage and may be excluded from measurement. This is a clarification only; it does not lower any coverage threshold.
+
+## Coverage Exclusion Policy
+
+No production file may be excluded from coverage measurement. Every production source file is in the denominator of the coverage metric, regardless of whether its lines are reachable in the test environment.
+
+The correct response to a file that contains untestable lines is to refactor it — extract all logic into host-neutral, testable modules and leave only the thinnest possible wiring in the host-bound entry point. The entry point's uncovered lines then represent a real and visible cost in the coverage metric, which creates ongoing pressure to keep those files minimal.
+
+**Permitted `exclude` entries** (non-production paths only):
+- Build output directories: `dist/**`, `lib/**`, `lib-amd/**`.
+- Test files and test infrastructure: `**/*.test.ts`, `tests/**`, `src/test-support/**`.
+- Config files that are not production code: `vitest.config.ts`, `eslint.config.mjs`, `.dependency-cruiser.cjs`, `webpack.config.js`.
+- `node_modules/**`.
+
+**Prohibited `exclude` entries:**
+- Any path under `src/` that contains production runtime code, regardless of whether it is auto-generated, host-bound, or difficult to test.
+
+**Enforcement:** Feature-review agents must treat any `exclude` entry that matches a production source path as a **Blocking** finding.
 
 ## Scenario Completeness
 
@@ -54,7 +73,33 @@ Assertions must produce clear, actionable failure messages.
 - **Creation and use of temporary files in tests is strictly prohibited.**
 - Tests must not rely on mutable global state or external configuration that can change between runs.
 
+## Test File Location
+
+Test files must live in a `tests/` directory tree that mirrors the production source structure. The test for `src/foo/bar.ts` belongs at `tests/foo/bar.test.ts`; the test for `scripts/powershell/Foo.ps1` belongs at `tests/scripts/powershell/Foo.Tests.ps1`. Language-specific rules may add further naming conventions (framework suffix, file extension) on top of this universal layout requirement.
+
+Colocation — placing test files alongside production source files in `src/` or equivalent — is not permitted. An agent that creates or moves a test file into the production source tree has violated this rule.
+
 ## Documentation
 
 - Each test must clearly communicate its purpose via a descriptive name and/or a short docstring or comment summarizing the scenario and expected outcome.
 - Group related tests logically within the same file or test class.
+
+## Test Categories
+
+The following test categories apply across the repository, with tier-dependent obligations per `.claude/rules/quality-tiers.md`:
+
+- **Unit tests** — required for all tiers (T1–T4). Cover single units of behavior in isolation.
+- **Property-based tests** — required for T1 and T2 modules: at least one property test per pure function. Use `fast-check` (TypeScript) or `hypothesis` (Python) where applicable.
+- **Golden / snapshot tests** — required only for T1 classifier-output modules, tested against a versioned corpus. Snapshot tests are otherwise discouraged unless stable and intentional.
+- **Contract / schema tests** — required at every host-service boundary (e.g., Office.js, Microsoft Graph, internal API contracts).
+- **Mutation tests** — required for T1 modules: mutation score >= 75%. Run in pre-merge or nightly pipelines.
+- **Integration tests** — required where adapters interact with external systems; scoped per tier in the gate matrix.
+
+## Determinism Infrastructure
+
+All test code must be deterministic. The following infrastructure requirements apply uniformly:
+
+- **Controllable clock** — use a `Clock` interface (TypeScript) or `TimeProvider` (.NET) injected into code under test. Do not read wall-clock time directly in production code under test.
+- **Seeded RNG** — randomness must be supplied via a seedable interface; on test failure the seed must be printed so the failure is reproducible.
+- **Banned APIs in test code** — `setTimeout`, `Thread.Sleep`, `Task.Delay`, real wall-clock waits, and `Date.now()` outside the clock interface are prohibited in tests.
+- **Virtual scheduler / fake timers / `FakeTimeProvider`** — async tests must use the framework's fake-timer facility (`vi.useFakeTimers()` for Vitest, `FakeTimeProvider` for .NET) to advance simulated time deterministically.

package/resources/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.