@danmoisan/drm-copilot-mcp 0.0.1

package/resources/claude-customizations/.claude/skills/csharp-change-budget-router/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: csharp-change-budget-router
+description: Budget-first routing contract for C# work: estimate production-file scope, choose small vs large path, enforce orchestration-first routing for larger changes, and use the VS Code extension command surface for promotion lifecycle steps when available.
+---
+
+# C# Change Budget Router
+
+Canonical guidance for deciding whether work should stay on the small path or escalate to the full C# orchestration workflow.
+
+## When to Use This Skill
+
+Use this skill when:
+- Intake starts from a natural-language C# request.
+- An agent must decide the execution path before planning or implementation.
+- A direct-mode route must reject over-budget requests and switch to orchestrated flow.
+
+## Canonical Routing Rules
+
+1) Estimate rough change budget first based on likely **production C# files** touched.
+2) Route:
+- `1-3` production files (+ corresponding tests) → **small path** (`csharp-typed-engineer` direct mode).
+- `>3` production files or `>3` test files → **large path** (orchestration workflow with promotion/research/spec/planning/execution/review).
+
+## Orchestrated Small-Path Requirements
+
+When routed through `csharp-orchestrator`, small path still requires lifecycle scaffolding before implementation:
+- invoke promotion/folder lifecycle steps through `vscode/runCommand` + extension access per `feature-promotion-lifecycle` when available; use script/CLI fallback only when direct extension command execution is unavailable,
+- promote potential item to GitHub issue with `--work-mode minor-audit`,
+- create active feature folder with `--work-mode minor-audit`,
+- delegate minimal-audit plan creation to `atomic_planner` with `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`,
+- require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`,
+- execute Phase 0 only via atomic_executor before branching,
+- run reduced small-audit after implementation and QC.
+
+Direct invocation of `csharp-typed-engineer` remains implementation-focused and does not replace orchestrator lifecycle steps.
+
+## Direct-Mode Rejection Rule
+
+If direct implementation is requested but estimated scope is `>3` production files:
+- Stop before implementation.
+- Return explicit routing instruction to invoke `csharp-orchestrator`.
+
+## Invocation Mode
+
+The `csharp-typed-engineer` worker supports two execution modes:
+
+- **Direct mode** (default): no handoff directive present. Strict overall change-budget limits apply per the routing rules above.
+- **Orchestrator handoff mode**: enabled only when the incoming request contains the exact line `DIRECTIVE: ORCHESTRATOR HANDOFF MODE`. Overall change-budget limits are lifted, but execution is allowed only when a complete context package is supplied.
+
+Required context package in orchestrator handoff mode:
+
+1. objective and expected outcome,
+2. `${promotion-type}` and `${issue-num}` when available,
+3. `${feature-folder}` path,
+4. issue doc path (`${feature-folder}/issue.md`),
+5. spec doc path (`${feature-folder}/spec.md`),
+6. user-story path (`${feature-folder}/user-story.md`) or explicit `NONE`,
+7. research artifact path(s),
+8. constraints, APIs, or invariants to preserve.
+
+If any required item is missing in orchestrator handoff mode, stop and request the missing context package fields before Phase A proceeds.
+
+## Per-Batch Cap
+
+In all modes, per-batch budget remains: at most **3 production files** and **3 test files** unless an explicit override is approved by the user. If no override is provided, the 3/3 per-batch limit applies. If a batch would exceed the cap, split it into smaller batches.
+
+## Orchestrator-Mode Delegation Chain
+
+When `csharp-typed-engineer` runs in orchestrator handoff mode, it must execute the following delegation chain and must not bypass it with direct implementation:
+
+1. Delegate to `atomic_planner` for an architecture plus testability plan only (no edits).
+2. Require planner output to include final `PREFLIGHT: ALL CLEAR` from the preflight validation loop.
+3. Delegate plan execution to `atomic_executor`.
+4. Delegate the final QA gate to `atomic_executor` per `csharp-qa-gate`.
+5. Delegate post-implementation review to `feature-review` per `feature-review-workflow`.
+
+Execution-start constraint: in orchestrator handoff mode, `csharp-typed-engineer` is routing-and-planning-only until the planner preflight loop returns `PREFLIGHT: ALL CLEAR`. Before that signal, it must not run any state-changing implementation command and must not edit production or test files directly. All implementation and QA execution must occur via delegated handoffs.
+
+Blocking rules in orchestrator mode:
+- If the incoming request does not include the exact directive line, stop and request a corrected orchestrator handoff.
+- If any delegation in the chain is skipped, treat the run as incomplete and do not report completion.
+- Do not claim completion unless the final report includes all artifact paths from the feature review step.
+
+## Documentation Expectations
+
+Record in response/logs:
+- estimated production file count,
+- chosen path (`small`/`large`),
+- rationale summary (1-3 bullets).
+

package/resources/claude-customizations/.claude/skills/csharp-orchestration-state-machine/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: csharp-orchestration-state-machine
+description: Checkpoint schema and resume protocol for long-running C# orchestration workflows.
+---
+
+# C# Orchestration State Machine
+
+Canonical checkpoint and resume behavior for orchestration agents running multi-step C# delivery flows.
+
+## When to Use This Skill
+
+Use this skill when:
+- A workflow spans multiple delegations and commands.
+- Execution may be interrupted and must resume deterministically.
+- An orchestrator must avoid repeating completed steps.
+
+## Canonical Checkpoint Location
+
+- `artifacts/orchestration/csharp-orchestrator-state.json`
+
+## Required Checkpoint Fields
+
+- `objective`
+- `change_budget_estimate`
+- `path_selected` (`small` or `large`)
+- `promotion-type`
+- `short-name`
+- `relativeFile`
+- `long-name`
+- `issue-num`
+- `feature-folder`
+- `work-mode` (`minor-audit`, `full-feature`, or `full-bug`; normalize legacy `full` to `full-feature` before persistence)
+- `plan-path` (minimal or full plan path)
+- `completed_steps`
+- `next_step`
+- `last_updated`
+
+For short-path runs, also persist:
+- `small_path_qc_summary`
+- `small_path_audit_artifacts`
+- `bootstrap_mode` (`manual-bootstrap` or `auto-small-dev`)
+- `phase0_execution_summary`
+- `resume_after_manual_bootstrap` (next step token)
+
+## Update Protocol
+
+- Write checkpoint after every completed orchestration sub-step.
+- Treat checkpoint as source-of-truth for progress state.
+- Never claim mission completion until checkpoint marks final state.
+
+## Resume Protocol
+
+On invocation:
+1) Read checkpoint if it exists.
+2) If incomplete, resume from `next_step` without re-running `completed_steps`.
+3) If missing or completed, start at phase-0 intake.
+4) If user explicitly requests restart, reset checkpoint and start phase-0.
+

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

@@ -0,0 +1,77 @@
+---
+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.
+---
+
+# C# QA Gate
+
+Canonical procedure for the Phase D final quality gate that every C# change must pass before completion is reported.
+
+## When to Use This Skill
+
+Use this skill when:
+
+- `csharp-typed-engineer` is about to declare a change complete.
+- An executor has finished applying a planned batch and must verify zero regressions against the baseline captured in Phase A.
+- A reviewer needs to confirm the toolchain was actually run and produced a clean pass.
+
+## Required Inputs
+
+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,
+- 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.
+
+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`
+
+If the environment prevents running any tool, stop and report the change as **unverified**. Do not declare completion.
+
+## Delta Requirements (Zero-Regression Hard Gate)
+
+Compare the final results to the Phase A baseline. All of the following must hold:
+
+- **Analyzer delta**: 0 new findings across the repository.
+- **Compiler / nullable delta**: 0 new diagnostics across the repository.
+- **MSTest 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.
+
+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.
+
+## Required Reporting Block
+
+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.
+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.
+
+## Evidence Storage
+
+Persist toolchain output according to `evidence-and-timestamp-conventions`:
+
+- store baseline outputs under `<FEATURE>/evidence/baseline/<timestamp>/`,
+- store post-change outputs under `<FEATURE>/evidence/qa-gates/<timestamp>/`,
+- use ISO-8601 UTC timestamps in folder names.
+
+This location is canonical per evidence-and-timestamp-conventions and is not overridable.
+See `.claude/skills/evidence-and-timestamp-conventions/SKILL.md` for the canonical evidence path authority.
+
+The evidence paths must be referenced in the agent's completion message to satisfy the `SubagentStop` completion-artifact gate.
+
+## Prohibited Shortcuts
+
+- Do not disable, skip, or narrow any step of the toolchain to reach a clean result.
+- Do not add analyzer suppressions, `#pragma warning disable`, `#nullable disable`, or test `[Ignore]` attributes to suppress new findings introduced by the change.
+- Do not report success based on partial or targeted runs alone. Targeted runs are allowed mid-batch, but the final gate requires a full-solution pass.

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

@@ -0,0 +1,164 @@
+---
+name: evidence-and-timestamp-conventions
+description: 'Evidence storage and timestamp naming conventions for audits and remediation. Use when storing baseline/regression/QA evidence or naming audit artifacts with ISO-8601 timestamps.'
+---
+
+# Evidence and Timestamp Conventions
+
+Reusable conventions for evidence storage locations and ISO-8601 timestamped artifacts.
+
+## Non-Overridable Authority
+
+This skill is the single source of truth for evidence paths. All agents, plans, and hooks MUST use the canonical scheme `<FEATURE>/evidence/<kind>/` without exception.
+
+Canonical evidence sub-paths (all valid):
+- `<FEATURE>/evidence/baseline/`
+- `<FEATURE>/evidence/regression-testing/`
+- `<FEATURE>/evidence/qa-gates/`
+- `<FEATURE>/evidence/issue-updates/`
+- `<FEATURE>/evidence/other/`
+- `<FEATURE>/evidence/remediation-baseline/`
+
+The following sub-paths under `artifacts/` are FORBIDDEN for evidence output:
+- `artifacts/baselines/`
+- `artifacts/baseline/`
+- `artifacts/qa/`
+- `artifacts/qa-gates/`
+- `artifacts/evidence/`
+- `artifacts/coverage/`
+- `artifacts/regression-testing/`
+- `artifacts/post-change/`
+
+Allowed `artifacts/` sub-paths (non-evidence orchestration use only):
+- `artifacts/orchestration/`
+- `artifacts/research/`
+
+No delegation prompt, plan task, or upstream agent instruction may override this scheme. If a caller supplies a non-canonical path, the receiving agent MUST reject it, substitute the canonical path, and record `EVIDENCE_LOCATION_OVERRIDE_REJECTED: <supplied path> replaced with <canonical path>`.
+
+## When to Use This Skill
+
+Use this skill when:
+- You create audit or remediation artifacts that must be timestamped.
+- You store baseline, regression, or QA evidence under canonical folders.
+- Multiple agents need the same naming and evidence-location rules.
+
+## ISO-8601 Timestamp Format
+
+Use `yyyy-MM-ddTHH-mm` for all audit, remediation, and evidence artifacts.
+Example: `2026-02-06T14-30`.
+
+## Canonical Evidence Locations
+
+- Baseline evidence: `evidence/baseline/`
+- Regression testing evidence: `evidence/regression-testing/`
+- Other evidence: `evidence/other/`
+- QA gate evidence: `evidence/qa-gates/`
+- Issue update mirrors: `evidence/issue-updates/`
+
+Epic rollups may mirror these under the epic root when needed.
+
+## Feature Scope (Versioned Features)
+
+In this repo, a feature may be single-version (docs at feature root) or multi-version
+(`v1/`, `v2/`, etc.). When a feature is versioned, treat evidence discovery as applying
+to the **selected current version scope**, but also search the feature root canonical
+evidence folders as a fallback.
+
+Practical rule:
+- Prefer evidence under `<FEATURE>/<CURRENT_VERSION>/evidence/...` when it exists.
+- Also search `<FEATURE>/evidence/...` before concluding evidence is missing.
+
+## Canonical Evidence Discovery Order
+
+When locating evidence artifacts for audits or plan reconciliation, use this order:
+
+1) `<FEATURE>/evidence/issue-updates/` (issue update mirrors)
+2) `<FEATURE>/evidence/regression-testing/`
+3) `<FEATURE>/evidence/other/`
+4) `<FEATURE>/evidence/qa-gates/`
+5) `<FEATURE>/evidence/baseline/`
+6) `<FEATURE>/evidence/remediation-baseline/`
+7) `<EPIC>/evidence/issue-updates/` (issue update mirrors)
+8) `<EPIC>/evidence/regression-testing/` (optional rollup)
+9) `<EPIC>/evidence/other/`
+10) `<EPIC>/evidence/qa-gates/` (optional rollup)
+11) `<EPIC>/evidence/baseline/` (optional rollup)
+12) `<EPIC>/evidence/remediation-baseline/` (optional rollup)
+
+Rule:
+- Use the list order by default for audit fidelity.
+- If the task is explicitly remediation reconciliation, you may prefer `remediation-baseline` over `baseline`, but still record the original baseline as the authoritative audit reference.
+
+If evidence or issue-update mirrors are found elsewhere, record it as non-canonical and include a remediation step to move/copy it into the first applicable canonical location.
+
+### Fail-before Requirements (Deterministic Check)
+
+When an acceptance criterion (AC) or plan item requires **fail-before / pass-after** evidence:
+
+- First, search for a failing run artifact in `<FEATURE>/evidence/regression-testing/`.
+- If no failing run exists (or it is structurally impossible), search for a **fail-before exception dossier**.
+
+Minimum required search pattern:
+- `fail-before-exception.*.md` (preferred name prefix)
+
+Only after checking both (failing run OR exception dossier) may you write a negative claim like
+"no fail-before evidence exists".
+
+## Evidence Artifact Schema (Machine-Checkable)
+
+When evidence artifacts are used for automated checking or plan reconciliation, include:
+- `Timestamp: <ISO-8601>`
+- `Command: <exact command>`
+- `EXIT_CODE: <int>`
+
+### Baseline Evidence Output Summary (Required)
+
+For baseline evidence artifacts stored under `evidence/baseline/`, include an output summary in addition to the schema fields above:
+- `Output Summary: <1–20 lines capturing the essential outcome>`
+
+The summary should be concise, human-readable, and include the most important result signal (e.g., “All checks passed”, “767 passed”, coverage total, or a brief error description).
+
+If a fail-before run is required but impossible, include a short exception dossier with:
+- `WhyFailingRunImpossible: <1–3 sentences>`
+- An alternative proof section (e.g., absence-of-test proof)
+
+Fail-before exception dossiers should be stored under `evidence/regression-testing/`.
+
+Preferred filename for fail-before exception dossiers:
+- `fail-before-exception.<timestamp>.md`
+
+If an exception dossier is present and schema-valid, it counts as satisfying the
+"fail-before" requirement for audit/plan reconciliation purposes.
+
+## Negative Evidence Claims (Absence Must Be Auditable)
+
+If you claim evidence is missing (e.g., "no exception dossier recorded"), you MUST also record:
+
+- `SearchScope:` the exact folder(s) searched (include both current-version scope and feature root when applicable)
+- `SearchPatterns:` the filename patterns used (e.g., `fail-before-exception.*.md`)
+- `SearchResult:` what was found (paths) or `none`
+
+This prevents false negatives caused by searching the wrong scope or using incomplete patterns.
+
+## Evidence-First Audit Writing
+
+When marking FAIL or PARTIAL in audit artifacts, include:
+- Concrete file + location (line/hunk/section when possible)
+- The violated rule or expected behavior
+- The verification command and its output (or why it could not be run)
+
+## Issue Update Mirroring (Canonical Location)
+
+When work involves updating a GitHub issue, create a local mirror artifact at:
+- `<FEATURE>/evidence/issue-updates/issue-<N>.<timestamp>.md`
+
+Required contents:
+- `Timestamp: <ISO-8601>`
+- The exact text intended/posted
+- `PostedAs: body` or `PostedAs: comment` (preferred), or `PostedAs: unknown`
+- If posted as a comment: the GitHub URL to the comment
+- If posted as an issue body update: the GitHub URL to the issue and `IssueUpdatedAt: <ISO-8601>`
+- If not posted: a `POSTING BLOCKED` header and the reason
+
+If `PostedAs: body`, mirror the same update into the local feature `issue.md` (current version folder if present; otherwise feature root).
+

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

@@ -0,0 +1,82 @@
+---
+name: execute-hard-lock
+description: Place the session in atomic execution mode bound to a specific plan-of-record. Resolves the hard-lock prompt via the drmCopilotExtension MCP tool, then delegates to the atomic-executor subagent with the resolved text. Use when a caller provides ${plan-path} and ${work-mode} and requires strict plan-following behavior.
+allowed-tools:
+  - mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt
+  - Read
+---
+
+# 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.
+
+## When to Use This Skill
+
+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.
+
+## Inputs
+
+Required:
+
+- `plan-path` — absolute or repo-relative path to the plan-of-record markdown file.
+- `work-mode` — one of `minor-audit`, `full-feature`, `full-bug`. Legacy value `full` normalizes to `full-feature`. Missing or malformed values fail closed to `full-feature`.
+
+## Invocation Flow
+
+### 1. Resolve the Hard-Lock Prompt via MCP
+
+Call the extension's resolver as the first action:
+
+- Tool: `mcp__drmCopilotExtension__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.
+
+On success, the response contains an `artifacts` array whose first entry is the absolute path of a file containing the resolved hard-lock prompt (produced by the extension passing `--output` and `--quiet` to the bundled Python resolver).
+
+### 2. Read the Resolved Prompt
+
+Use the `Read` tool on the path returned in `artifacts[0]`. Treat the file contents as the authoritative hard-lock instruction set for this session.
+
+### 3. Delegate to atomic-executor
+
+Invoke the `atomic-executor` subagent via the Agent tool. Pass the resolved prompt text as the subagent's kickoff directive, followed by `${plan-path}` and `${work-mode}` as session context.
+
+The resolved prompt itself already instructs the subagent to perform the mandatory read-proof (`git rev-parse HEAD`, SHA-256 of the plan file, unchecked-task count), preflight validation, and `READY TO BEGIN FROM [P#-T#]` handshake before executing any task. This skill does not reissue those instructions locally — doing so would risk divergence from the canonical template.
+
+## Abort Conditions
+
+Stop immediately and report `BLOCKED: execute-hard-lock <cause>` in any of these cases. Do not reconstruct the hard-lock prompt from any other source and do not delegate to `atomic-executor` without a successful read in step 2.
+
+- MCP tool is not available or not permitted.
+- MCP response has `ok: false` or is otherwise malformed.
+- MCP response omits `artifacts` or `artifacts[0]`.
+- `Read` on the artifact path fails (file missing, unreadable, empty).
+
+## Equivalent Entry Points (Reference)
+
+The three entry points below all produce the same resolved hard-lock prompt for a given plan path. This skill always uses the MCP form:
+
+- MCP (used by this skill): `mcp__drmCopilotExtension__resolve_execute_hard_lock_prompt` with `target=<plan-path>`. The extension passes `--output artifacts/hard_lock_prompt.txt` and `--quiet` to the bundled Python resolver.
+- VS Code command: `@command:drmCopilotExtension.resolveExecuteHardLockPrompt` (interactive; writes to stdout + clipboard, no file artifact).
+
+## Delegation Contract
+
+The `atomic-executor` subagent at [../../agents/atomic-executor.md](../../agents/atomic-executor.md) enforces the persistent execution-mode behaviors (anti-replanning, preflight-only blocking, persistence across turns, resume) and preloads the shared skills that support them:
+
+- `policy-compliance-order` — mandatory policy reading order.
+- `atomic-plan-contract` — plan format, Phase 0 requirements, preflight signals, validator gate, and mode-specific plan gates.
+- `acceptance-criteria-tracking` — AC check-off protocol and status summary format.
+- `evidence-and-timestamp-conventions` — baseline and final-QC artifact paths and required fields.
+
+## Prohibitions
+
+- Do not proceed without a successful MCP resolver response AND a successful `Read` of the artifact.
+- Do not reconstruct the hard-lock contract from any other source (not from this file nor from prior session memory).
+- Do not modify the resolved prompt text before passing it to `atomic-executor`.
+- Do not replan, reorder, or add tasks at this layer — the subagent owns that contract.
+- Do not create or read secrets unless explicitly authorized.

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

@@ -0,0 +1,115 @@
+---
+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.
+---
+
+# Feature Promotion Lifecycle
+
+Canonical variable model and MCP-only command sequence for promoting potential feature/bug entries and initializing active feature delivery.
+
+## When to Use This Skill
+
+Use this skill when:
+- A large-scope change requires feature/bug promotion workflow.
+- A short-path workflow still requires promotion/folder initialization before delegated implementation.
+- An orchestrator must create potential docs, promote to issue, branch, and active feature folder.
+- Downstream research/spec agents depend on deterministic paths and identifiers.
+
+## MCP Tool Availability Preflight
+
+Before any promotion step starts, verify that the required `drmCopilotExtension` 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}`
+
+If the required MCP tools are unavailable, stop before potential-entry creation, issue promotion, or active-folder creation begins. Restore MCP connectivity first. Agent sessions do not have an approved non-MCP execution branch for promotion work.
+
+## Agent-Session Promotion Execution Rule
+
+Execute the lifecycle only through the MCP tool forms listed above. The MCP path is the sole authoritative execution path for agent sessions.
+
+After each successful promotion operation, persist the raw MCP receipt payload under the matching checkpoint key in `artifacts/orchestration/orchestrator-state.json`:
+- `delegation_receipts.promotion.potential_entry`
+- `delegation_receipts.promotion.issue`
+- `delegation_receipts.promotion.feature_folder`
+
+Each `delegation_receipts.promotion.*` field stores the raw MCP receipt payload returned by the corresponding promotion operation without lossy normalization.
+
+Note: VS Code command-palette commands may exist for interactive extension use, but this note is non-authoritative for agent sessions.
+
+## Canonical Variables
+
+- `${promotion-type}`: `feature` or `bug`
+- `${short-name}`: lowercase slug, hyphen-separated
+- `${relativeFile}`: workspace-relative path to created potential entry markdown
+- `${long-name}`: `${relativeFile}` filename without `.md`
+- `${issue-num}`: promoted GitHub issue number
+- `${feature-folder}`: active feature folder path
+- `${plan-path}`: single canonical plan file path reused across planning and preflight revisions
+- `${work-mode}`: `minor-audit`, `full-feature`, or `full-bug` (legacy `full` is accepted only as an alias for `full-feature`)
+- `${short-path-flag}`: `--work-mode minor-audit` (mandatory for short-path promotion/folder creation)
+
+When orchestrator routing selects short path, promotion/folder initialization still occurs and MUST use `minor-audit` mode.
+
+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`.
+
+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`.
+
+4a) Verify minor-audit folder integrity before proceeding:
+- `${feature-folder}/issue.md` exists and contains `- Work Mode: minor-audit`
+- `${feature-folder}/issue.md` contains an explicit `## Acceptance Criteria` section
+- `${feature-folder}/spec.md` does not exist
+- `${feature-folder}/user-story.md` does not exist
+- if any check fails, stop and remediate before planning
+
+5) Delegate minimal-audit plan creation to `atomic_planner` with directive:
+- `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
+
+5a) Resolve and persist `${plan-path}` before delegation:
+- reuse the earliest existing `plan*.md` in `${feature-folder}` when present
+- otherwise create exactly one canonical plan file path and reuse it for all revisions
+
+6) Require preflight validation via `atomic_executor` until:
+- `PREFLIGHT: ALL CLEAR`
+
+7) Execute plan Phase 0 only via executor and checkpoint evidence.
+
+8) Branch:
+- manual bootstrap: save state and stop,
+- non-bootstrap: continue with constrained small-path development.
+
+9) Validate delivery via executor against `issue.md`, then run reduced audit/remediation loop until ready-to-merge.
+
+## Required Outputs for Downstream Handoffs
+
+Before delegating research/spec/planning, provide:
+- `${feature-folder}/issue.md`
+- `${feature-folder}/spec.md` (or expected target path)
+- `${feature-folder}/user-story.md` (or explicit `NONE`)
+- latest research artifact path(s)
+- constraints/APIs/invariants to preserve
+
+Mode-aware expectations:
+- For `minor-audit`, the explicit `## Acceptance Criteria` section in `issue.md` is the primary acceptance-criteria source and `spec.md`/`user-story.md` may be intentionally absent by design.
+- For `minor-audit`, do not infer acceptance criteria from other `issue.md` sections such as verification notes, next steps, or severity checklists.
+- For `minor-audit`, `spec.md`/`user-story.md` must be treated as integrity failures when they appear unexpectedly in the active folder.
+- For `full-feature`, `spec.md` and `user-story.md` are expected alongside `issue.md`.
+- For `full-bug`, `spec.md` is expected alongside `issue.md`; `user-story.md` should be absent unless the requirements explicitly justify it.
+
+Selected-mode persistence requirements:
+- Producer outputs MUST persist exactly one marker in `issue.md` metadata above the first `##` heading:
+	- `- Work Mode: minor-audit`
+	- `- Work Mode: full-feature`
+	- `- Work Mode: full-bug`
+- Persisted marker MUST represent selected mode after eligibility checks, not requested mode.
+- If a legacy requested `full` path is accepted, tooling MUST normalize it to `full-feature` before persistence.
+- If a requested `minor-audit` path is rejected by eligibility checks, tooling MUST fail closed to `full-feature`, emit the downgrade reason, and persist `- Work Mode: full-feature`.
+