@danmoisan/drm-copilot-mcp 0.0.1

package/resources/customizations/.github/prompts/orchestrate-csharp-work.prompt.md

@@ -0,0 +1,66 @@
+---
+agent: 'csharp-orchestrator'
+description: 'Route a C# request through budget-based orchestration: direct small-scope delivery or full feature/bug lifecycle with promotion, research, plan/execution, and review.'
+---
+
+# C# Orchestration Prompt
+
+Use this prompt to run an end-to-end C# workflow through `csharp-orchestrator`.
+
+## Objective
+
+Coordinate the user request from intake to completion using the correct path based on rough change budget.
+
+## Inputs
+
+- **Request summary (required):** clear objective and expected outcome
+- **Likely affected files (optional):** any known production/test files
+- **Initial classification hint (optional):** `feature` or `bug`
+- **Constraints (optional):** APIs/paths/behavior that must remain unchanged
+
+## Required orchestration behavior
+
+1. Estimate rough change budget first (production C# files and test C# files).
+2. If budget is **1–3 production C# files** (+ corresponding tests):
+   - Execute enforced small-path lifecycle:
+     1) Scope/create potential entry and promote with `--work-mode minor-audit`
+   2) Create branch and active feature folder with `--work-mode minor-audit`, then verify `issue.md` contains an explicit `## Acceptance Criteria` section
+     3) Delegate plan creation to `atomic_planner` with directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
+     4) Require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`
+     5) Delegate to `atomic_executor` to execute **Phase 0 only**
+     6) Branch behavior:
+        - manual bootstrap: save state and stop for manual resume
+        - non-bootstrap small development: delegate constrained implementation to `csharp-typed-engineer`
+   7) Delegate post-delivery validation to `atomic_executor` for validation against issue.md, using only the explicit `## Acceptance Criteria` section for minor-audit acceptance validation, and persist checklist/doc updates
+     8) Run reduced small-path audit and remediation loop until ready-to-merge
+3. If budget is **>3 production C# files** or **>3 test C# files**:
+   - Execute full large-path lifecycle:
+     1) Scope and create potential entry (`feature` vs `bug`, short-name creation)
+     2) Promote to GitHub issue and capture issue metadata
+     3) Create branch and active feature folder
+     4) Delegate research + spec/story completion
+     5) Delegate plan creation to `csharp-atomic-planning` (which delegates to `atomic_planner`, then validates preflight via `atomic_executor` until `PREFLIGHT: ALL CLEAR`)
+     6) After all-clear, delegate implementation + QA directly to `csharp-atomic-executor`
+     7) Delegate post-implementation feature review
+
+## Persistence and resume
+
+- Maintain orchestration state in `artifacts/orchestration/csharp-orchestrator-state.json`.
+- Resume from the next incomplete step if interrupted.
+- Do not end early while required downstream steps remain.
+
+## Output expectations
+
+On completion, report:
+
+- Selected route (`small` or `large`)
+- Branch name (if created)
+- Key captured variables (`promotion-type`, `short-name`, `issue-num`, `feature-folder` when applicable)
+- Created/updated artifact paths
+- Final readiness summary and any remaining action items
+
+For small path also report:
+- approved `plan-path`
+- preflight result (`PREFLIGHT: ALL CLEAR`)
+- whether `manual bootstrap` branch was taken
+- Phase 0 execution evidence and stored `next_step` for resume

package/resources/customizations/.github/prompts/orchestrate-powershell-work.prompt.md

@@ -0,0 +1,50 @@
+---
+agent: 'powershell-orchestrator'
+description: 'Route a PowerShell request through budget-based orchestration: direct small-scope delivery or full feature/bug lifecycle with promotion, research, plan/execution, and review.'
+---
+
+# PowerShell Orchestration Prompt
+
+Use this prompt to run an end-to-end PowerShell workflow through `powershell-orchestrator`.
+
+## Objective
+
+Coordinate the user request from intake to completion using the correct path based on rough change budget.
+
+## Inputs
+
+- **Request summary (required):** clear objective and expected outcome
+- **Likely affected files (optional):** any known production/test files
+- **Initial classification hint (optional):** `feature` or `bug`
+- **Constraints (optional):** APIs/paths/behavior that must remain unchanged
+
+## Required orchestration behavior
+
+1. Estimate rough change budget first (production PowerShell files).
+2. If budget is **1–2 production PowerShell files** (+ corresponding tests):
+   - Delegate directly to `powershell-typed-engineer` for plan + implementation + QA closure.
+3. If budget is **>2 production PowerShell files**:
+   - Execute full large-path lifecycle:
+     1) Scope and create potential entry (`feature` vs `bug`, short-name creation)
+     2) Promote to GitHub issue and capture issue metadata
+     3) Create branch and active feature folder
+     4) Delegate research + spec/story completion
+   5) Delegate plan creation to `powershell-atomic-planning` (which delegates to `atomic_planner`, then validates preflight via `atomic_executor` until `PREFLIGHT: ALL CLEAR`)
+   6) After all-clear, delegate implementation + QA directly to `powershell_atomic_executor`
+   7) Delegate post-implementation feature review
+
+## Persistence and resume
+
+- Maintain orchestration state in `artifacts/orchestration/powershell-orchestrator-state.json`.
+- Resume from the next incomplete step if interrupted.
+- Do not end early while required downstream steps remain.
+
+## Output expectations
+
+On completion, report:
+
+- Selected route (`small` or `large`)
+- Branch name (if created)
+- Key captured variables (`promotion-type`, `short-name`, `issue-num`, `feature-folder` when applicable)
+- Created/updated artifact paths
+- Final readiness summary and any remaining action items

package/resources/customizations/.github/prompts/orchestrate-python-work.prompt.md

@@ -0,0 +1,50 @@
+---
+agent: 'python-orchestrator'
+description: 'Route a Python request through budget-based orchestration: direct small-scope delivery or full feature/bug lifecycle with promotion, research, plan/execution, and review.'
+---
+
+# Python Orchestration Prompt
+
+Use this prompt to run an end-to-end Python workflow through `python-orchestrator`.
+
+## Objective
+
+Coordinate the user request from intake to completion using the correct path based on rough change budget.
+
+## Inputs
+
+- **Request summary (required):** clear objective and expected outcome
+- **Likely affected files (optional):** any known production/test files
+- **Initial classification hint (optional):** `feature` or `bug`
+- **Constraints (optional):** APIs/paths/behavior that must remain unchanged
+
+## Required orchestration behavior
+
+1. Estimate rough change budget first (production Python files and test Python files).
+2. If budget is **1–3 production Python files** (+ corresponding tests):
+   - Delegate directly to `python-typed-engineer` for plan + implementation + QA closure.
+3. If budget is **>3 production Python files** or **>3 test Python files**:
+   - Execute full large-path lifecycle:
+     1) Scope and create potential entry (`feature` vs `bug`, short-name creation)
+     2) Promote to GitHub issue and capture issue metadata
+     3) Create branch and active feature folder
+     4) Delegate research + spec/story completion
+   5) Delegate plan creation to `python-atomic-planning` (which delegates to `atomic_planner`, then validates preflight via `atomic_executor` until `PREFLIGHT: ALL CLEAR`)
+   6) After all-clear, delegate implementation + QA directly to `python-atomic-executor`
+   7) Delegate post-implementation feature review
+
+## Persistence and resume
+
+- Maintain orchestration state in `artifacts/orchestration/python-orchestrator-state.json`.
+- Resume from the next incomplete step if interrupted.
+- Do not end early while required downstream steps remain.
+
+## Output expectations
+
+On completion, report:
+
+- Selected route (`small` or `large`)
+- Branch name (if created)
+- Key captured variables (`promotion-type`, `short-name`, `issue-num`, `feature-folder` when applicable)
+- Created/updated artifact paths
+- Final readiness summary and any remaining action items

package/resources/customizations/.github/prompts/orchestrate-work.prompt.md

@@ -0,0 +1,66 @@
+---
+agent: 'orchestrator'
+description: 'Route a request through budget-based orchestration: direct small-scope delivery or full feature/bug lifecycle with promotion, research, plan/execution, and review.'
+---
+
+# Orchestration Prompt
+
+Use this prompt to run an end-to-end workflow through `orchestrator`.
+
+## Objective
+
+Coordinate the user request from intake to completion using the correct path based on rough change budget.
+
+## Inputs
+
+- **Request summary (required):** clear objective and expected outcome
+- **Likely affected files (optional):** any known production/test files
+- **Initial classification hint (optional):** `feature` or `bug`
+- **Constraints (optional):** APIs/paths/behavior that must remain unchanged
+
+## Required orchestration behavior
+
+1. Estimate rough change budget first (production files and test files).
+2. If budget is **1–3 production files** (+ corresponding tests):
+   - Execute enforced small-path lifecycle:
+     1) Scope/create potential entry and promote with `--work-mode minor-audit`
+   2) Create branch and active feature folder with `--work-mode minor-audit`, then verify `issue.md` contains an explicit `## Acceptance Criteria` section
+     3) Delegate plan creation to `atomic_planner` with directive `DIRECTIVE: MINIMAL-AUDIT PLAN REQUIRED`
+     4) Require `atomic_executor` preflight until `PREFLIGHT: ALL CLEAR`
+     5) Delegate to `atomic_executor` to execute **Phase 0 only**
+     6) Branch behavior:
+        - manual bootstrap: save state and stop for manual resume
+        - non-bootstrap small development: delegate constrained implementation to the small-path engineer
+   7) Delegate post-delivery validation to `atomic_executor` against `issue.md`, using only the explicit `## Acceptance Criteria` section for minor-audit acceptance validation, and persist checklist/doc updates
+     8) Run reduced small-path audit and remediation loop until ready-to-merge
+3. If budget is **>3 production files** or **>3 test files**:
+   - Execute full large-path lifecycle:
+     1) Scope and create potential entry (`feature` vs `bug`, short-name creation)
+     2) Promote to GitHub issue and capture issue metadata
+     3) Create branch and active feature folder
+     4) Delegate research + spec/story completion
+   5) Delegate plan creation to `atomic_planner` (and require validation-only preflight through `atomic_executor` until `PREFLIGHT: ALL CLEAR`)
+   6) After all-clear, delegate implementation + QA directly to `atomic_executor`
+   7) Delegate post-implementation feature review
+
+## Persistence and resume
+
+- Maintain orchestration state in `artifacts/orchestration/orchestrator-state.json`.
+- Resume from the next incomplete step if interrupted.
+- Do not end early while required downstream steps remain.
+
+## Output expectations
+
+On completion, report:
+
+- Selected route (`small` or `large`)
+- Branch name (if created)
+- Key captured variables (`promotion-type`, `short-name`, `issue-num`, `feature-folder` when applicable)
+- Created/updated artifact paths
+- Final readiness summary and any remaining action items
+
+For small path also report:
+- approved `plan-path`
+- preflight result (`PREFLIGHT: ALL CLEAR`)
+- whether `manual bootstrap` branch was taken
+- Phase 0 execution evidence and stored `next_step` for resume

package/resources/customizations/.github/prompts/remediate-comments.prompt.md

@@ -0,0 +1,53 @@
+---
+agent: 'comment_remediator'
+description: 'Remediate a specified Python scope so docstrings and intent comments comply with self-explanatory-code-commenting rules, following all repo policies.'
+tools: ['search/listDirectory', 'search/fileSearch', 'search/codebase', 'search/usages', 'search/changes', 'read/readFile', 'edit/createFile', 'edit/createDirectory', 'edit/editFiles', 'execute/runTask', 'execute/createAndRunTask', 'execute/runInTerminal', 'execute/getTerminalOutput', 'read/problems', 'execute/testFailure', 'todo']
+---
+
+# Comment Remediation Loader
+
+Use this prompt to launch `comment_remediator` on any scope (single file, folder, or glob) and enforce `.github/instructions/self-explanatory-code-commenting.instructions.md` while obeying all repo policies.
+
+## Inputs
+
+- **Scope** (required): Path or glob to remediate (e.g., `src/lexile_corpus_tuner/.../enrich_original_pub_year/**`).
+
+## Policy Order
+
+Apply in this sequence:
+1. `.github/copilot-instructions.md`
+2. `.github/instructions/general-code-change.instructions.md`
+3. `.github/instructions/general-unit-test.instructions.md`
+4. `.github/instructions/python-code-change.instructions.md`
+5. `.github/instructions/python-unit-test.instructions.md`
+6. `.github/instructions/self-explanatory-code-commenting.instructions.md`
+
+## Execution Rules
+
+- Remediate the entire scope to add/adjust robust docstrings and intent comments for loops, branches, and multi-step blocks; avoid low-value narration.
+- Keep modules cohesive, under 500 lines, strongly typed; avoid `Any` unless justified.
+- Maintain encoding/EOL and ASCII unless the file already uses Unicode.
+- Do not pause for approval or clarification once scope is set; continue across turns if needed until fully compliant.
+
+## Workflow
+
+1. **Context pass**: Identify files in scope and gaps; capture tasks with `manage_todo_list`.
+2. **Remediate**: Add or refine docstrings and intent comments; refactor only when needed for clarity.
+3. **Validate (loop until clean)**:
+   - `poetry run black .`
+   - `poetry run ruff check`
+   - `poetry run pyright`
+   - `poetry run pytest`
+   Restart from Black after any change or failure; resolve all errors before finishing.
+
+## Completion Criteria
+
+- Scope complies with self-explanatory commenting guidance and repo policies.
+- Final toolchain pass is green.
+- Provide a concise summary and list of commands run.
+
+## Launch Template
+
+```
+Scope: <INSERT SCOPE PATH OR GLOB>
+```

package/resources/customizations/.github/prompts/research-issue.prompt.md

@@ -0,0 +1,125 @@
+---
+agent: 'Task Researcher Instructions'
+description: 'Research-only kickoff: investigate best implementation approach for a feature using provided issue/spec docs.'
+---
+
+# Research Prompt: Feature implementation approach (research-only)
+
+## Goal
+
+Determine the **best implementation approach** for the feature described in the documentation provided after this prompt (typically an `issue.md`, and sometimes also a `user-story.md`).
+
+Your output must be actionable for an engineer/agent to implement, and must be grounded in verified evidence from:
+
+- the current codebase (existing patterns, constraints, and seams), and
+- authoritative external references (official docs, well-maintained repos, etc.).
+
+## Scope and operating rules
+
+Follow the operating rules in your agent definition (research-only, write to `artifacts/research/`, evidence-based). Do not restate those rules in the research notes; apply them.
+
+## Inputs / Context (authoritative)
+
+After this kickoff prompt, you will be given one or more feature documents. Treat them as the primary specification.
+ 
+Common examples (not exhaustive):
+
+- `docs/features/active/<feature>/issue.md` (usually)
+- `docs/features/active/<feature>/user-story.md` (sometimes)
+
+Also identify (from the feature docs) the **implementation target files** in the repo (e.g., the script/module to change), and treat those as primary technical context.
+
+## Research Outputs (required)
+
+Create (or update) a single research file under `artifacts/research/` using the Task Researcher template exactly.
+
+Filename convention:
+
+- `artifacts/research/YYYYMMDD-<short-feature-name>-implementation-research.md`
+
+In the research file, keep any discussion of non-selected approaches *brief and non-exhaustive*. After selecting a recommendation, remove detailed notes for other approaches and keep only a short “Rejected alternatives” summary (what was rejected and why).
+
+Because the research template must be followed exactly, place the “Rejected alternatives” summary inside the required template under `## Recommended Approach` (as a short subsection/paragraph), not as a separate top-level header.
+
+Also place the core context (issue link, feature folder, spec doc paths, target files) inside the required template under `## Research Executed` (e.g., `### File Analysis`) and/or `### Project Conventions`. Do not add a separate custom header outside the template.
+
+## What to Investigate
+
+### 1) Current state analysis (internal)
+
+- Identify the implementation targets from the feature docs.
+- Read the relevant modules end-to-end.
+- Document:
+  - current behavior and user-visible outputs
+  - key abstractions and extension points
+  - constraints imposed by repo policies/toolchain
+  - how success/failure is currently computed and surfaced
+
+### 2) Candidate implementation approaches (external + internal feasibility)
+
+Research and compare at least two viable approaches (but select ONE final recommendation). Examples of “approaches” include:
+
+- different UX/output strategies (interactive vs non-interactive fallback)
+- dependency-free vs library-backed implementations
+- architectural patterns (small new component vs minimal inline changes)
+
+For any approach that introduces a new dependency:
+
+- confirm whether it is already present in the repo’s dependency set, and
+- justify why adding it is necessary and low-risk.
+
+For each approach, gather **authoritative docs** and/or examples to support the recommendation.
+
+### 3) Behavior semantics and edge cases
+
+Extract the intended behavior from the feature docs and define:
+
+- success/failure conditions
+- ordering rules (if any)
+- cancellation/abort behavior (if applicable)
+- CI vs local terminal behavior expectations
+
+Research comparable tools/projects that implement similar semantics.
+
+### 4) Requirements mapping → design
+
+Map the acceptance criteria into a concrete design and internal API boundaries.
+
+Your mapping should include:
+
+- a proposed state model (states, transitions)
+- where/when updates occur
+- how the final summary/reporting is produced
+- what changes are required (files/functions), and why
+
+### 5) Testing implications (design-level)
+
+Without writing tests, propose a test strategy consistent with repo policy:
+
+- Unit tests for a pure “status state machine” component.
+- Unit tests for fail-fast coordination behavior.
+- Integration test concept (if feasible) that avoids external dependencies and avoids temp files.
+
+## Selection Criteria (how you choose the recommendation)
+
+Recommend ONE approach based on:
+
+- Alignment with the feature docs’ acceptance criteria.
+- Compatibility with the repo’s supported environments (local dev + CI).
+- Maintainability and simplicity (prefer small, testable units).
+- Minimal disruption to existing behavior unless explicitly required.
+- Dependency impact (avoid new deps unless strongly justified).
+
+## Deliverable Requirements (in the research doc)
+
+Your final research file must include:
+
+- A single recommended approach with rationale, plus a brief (non-exhaustive) “Rejected alternatives” summary.
+- A proposed high-level design:
+  - components/classes/functions to add
+  - data structures (shared status map, locks)
+  - threading and cancellation model
+  - pseudocode for the rendering loop and the branch update calls
+- Specific implementation hooks in the relevant target file(s) (identify functions/locations).
+- Risks and mitigations (Windows/CI output, subprocess behavior).
+- Verification plan aligned to the repo’s toolchain and acceptance criteria.

package/resources/customizations/.github/prompts/review-epic.prompt.md

@@ -0,0 +1,94 @@
+---
+agent: 'epic_review_agent'
+description: 'Prompt for reviewing an epic documentation root folder with a delivery-first audit for a single-developer, multi-feature initiative. Derives all feature subfolders and current versions/plans from the epic root input, validates acceptance criteria against current code, reconciles plan checklists, generates epic-audit + feature-delivery-inventory + policy-audit (plus pre-execution orchestration-review when applicable); if remediation is needed, produces remediation inputs and automatically creates remediation-plan.md via atomic_planner.'
+---
+
+# Epic Review Prompt
+
+## Goal
+
+Act as an epic reviewer with a **delivery-first** posture. Review the epic **from its documentation root folder**, derive all constituent feature documentation (including version selection), validate acceptance criteria against the current codebase and tests, reconcile plan checklists, and produce audit-grade outputs suitable for merge readiness and execution planning.
+
+An epic is defined here as:
+> “A multi-feature initiative with interdependencies, used to organize scope and delivery for a single developer (or small team), without requiring formal program increments or business-case artifacts.”
+
+Do not ask clarifying questions. Make best-effort inferences, document assumptions, and provide evidence-based findings. Missing formal business-case documentation should be **noted** but is **non-blocking** for merge readiness.
+
+## Inputs (required)
+
+- **Epic root folder (required):** `${input:EpicRootFolder}`
+  - Example: `docs/features/active/2026-02-02-some-epic-47`
+
+## What you must derive from the epic root
+
+From the epic root folder contents:
+- Read `initiative.md`, `issue.md`, `orchestration.md` (if present)
+- Enumerate each feature subfolder
+- For each feature:
+  - If version folders exist (`v1`, `v2`, ...), select the highest `vN` as current
+  - Otherwise treat the feature root as current
+  - Select latest `plan.<timestamp>.md` using max ISO timestamp (`yyyy-MM-ddTHH-mm`)
+  - Read `issue.md`, `spec.md`, `user-story.md`, and the selected plan (best-effort)
+   - Extract acceptance criteria from `spec.md` and `user-story.md`
+   - Verify each acceptance criterion against code/tests and capture evidence
+   - Reconcile unchecked plan items against delivered code/tests (auto-check if delivered)
+
+## Evidence provenance and freshness rules (blocking metrics)
+
+Apply these requirements to any **numeric/metric claim** (coverage, pass rates, counts, etc.) used in audits or blocking decisions:
+
+1. **Evidence provenance requirement (blocking claim):**
+   - Every numeric claim MUST cite **source file + timestamp + command** (if applicable).
+   - Example: “Coverage $= 45\%$ (source: `implementation-summary.md`, 2026-02-02, command not recorded).”
+
+2. **Evidence classification (mandatory tag):**
+   - **Verified**: toolchain output, `coverage.xml`, or a CI run URL.
+   - **Reported**: doc-only claim without toolchain output.
+   - **Stale**: doc-only claim **older than the review date** or not backed by toolchain output.
+
+3. **Freshness rule:**
+   - If the source is not a toolchain output OR is older than the review date, mark the claim **Stale**.
+   - **Stale claims cannot be used as blocking evidence** without re-validation.
+
+4. **Blocking claims must be Verified:**
+   - Any blocking item based on metrics requires **Verified** status.
+   - Otherwise, phrase it as **“needs verification”** rather than **“fails.”**
+
+## Output format
+
+Write all outputs to the epic root folder `${input:EpicRootFolder}`.
+
+All filenames must include a timestamp in ISO-8601 format `yyyy-MM-ddTHH-mm` (e.g., `2026-02-02T15-30`).
+
+### Required deliverables
+
+1. `epic-audit.<timestamp>.md`
+   - Single-developer work-planning clarity and decision-quality audit
+   - Objective/scope mapping across features
+   - Overall epic readiness: PASS / NEEDS REVISION / BLOCKED
+
+2. `feature-delivery-inventory.<timestamp>.md`
+   - Inventory of features + versions + selected “current” docs
+   - Summary chart including requirements delivered (Met/Total)
+   - Per-feature acceptance criteria list with status (Met / Partially Met / Not Met / Unknown)
+   - Concrete evidence from code/tests for each criterion
+   - Plan reconciliation notes (auto-checked items with evidence)
+
+3. `policy-audit.<timestamp>.md`
+   - Repo-wide policy audit using `docs/features/templates/policy_audit/policy-audit.yyyy-MM-ddTHH-mm.md`
+
+### Conditional deliverables (only if remediation is required)
+
+4. `remediation-inputs.<timestamp>.md`
+   - Concrete, enumerated fix list with “done” criteria and exact doc locations
+
+5. A **completed** `remediation-plan.<timestamp>.md` created by automatically invoking `atomic_planner`
+
+### Conditional deliverables (pre-execution only)
+
+6. `orchestration-review.<timestamp>.md`
+   - Dependency, sequencing, and integration review of `orchestration.md`
+   - Cross-check orchestration claims against feature plans
+   - Only generate when execution has not begun (no delivered plan items and no code/test evidence yet)
+
+

package/resources/customizations/.github/prompts/review-feature.prompt.md

@@ -0,0 +1,130 @@
+---
+agent: 'feature_code_review_agent'
+description: 'Prompt for reviewing an entire feature branch relative to a base branch. Generates PolicyAudit + CodeReview + FeatureAudit (acceptance criteria) in the active feature folder; if remediation is needed, generates remediation inputs and AUTOMATICALLY delegates remediation plan creation to atomic_planner.'
+---
+
+# Feature Code Review Prompt
+
+## Goal
+
+Act as a feature-branch reviewer and policy auditor. Review the feature branch **relative to the specified base branch**, using PR context artifacts generated by the repo tooling.
+
+Read `artifacts/pr_context.summary.txt` thoroughly as the primary source of truth. Use `artifacts/pr_context.appendix.txt` only as needed for full baseline diff evidence.
+
+Do not ask clarifying questions. Make best-effort inferences, document assumptions, and produce audit-grade documentation suitable for PR readiness and merge decisions.
+
+## Output Format
+
+Write outputs to the **active feature folder** determined by the agent. If no active feature folder can be inferred, use the agent’s fallback (e.g., `docs/features/active/<date>-feature-review/`).
+
+### Baseline capture location (canonical)
+
+- Store baseline artifacts in a `baseline/` folder next to the plan file.
+- For multi-feature epics, store the epic-wide baseline at the epic root `baseline/`.
+- For multi-version features, keep a feature-level baseline in the feature root `baseline/`, and store version-specific baselines in a `baseline/` folder next to each version plan.
+
+### Required deliverables
+
+All filenames must include a timestamp in ISO-8601 format `yyyy-MM-ddTHH-mm` (e.g., `policy-audit.2026-01-08T14-30.md`).
+
+1. `policy-audit.<timestamp>.md`
+   - A completed Policy Audit document based on the repo's policy-audit template and the policy_audit template guidance.
+   - Must include PASS/PARTIAL/FAIL (or equivalent) statuses with concrete evidence (commands run, outputs, file references).
+   - For languages in scope with mandatory coverage policy, MUST include numeric baseline/post/new-code coverage values and command evidence; `UNVERIFIED` is not allowed for a PASS verdict.
+
+2. `code-review.<timestamp>.md`
+   - A feature-level code review relative to the base branch, emphasizing strongly typed Python best practices and repo compliance.
+   - Must include a clear go/no-go recommendation for PR readiness.
+
+3. `feature-audit.<timestamp>.md`
+   - A feature acceptance audit mapping acceptance criteria to evidence and verification results relative to the base branch.
+   - Must clearly state overall feature readiness (PASS / NEEDS REVISION / BLOCKED).
+   - If required coverage metrics are missing, overall readiness MUST be `NEEDS REVISION` (not PASS).
+
+### Minor-audit integrity gate (mandatory when `issue.md` declares `- Work Mode: minor-audit`)
+
+For short-path/minor-audit reviews, the reviewer MUST verify all of the following before issuing any PASS-style outcome:
+
+- `${feature-folder}/issue.md` exists and is the sole requirements source used for acceptance validation.
+- `${feature-folder}/issue.md` contains an explicit `## Acceptance Criteria` section, and only that section is used for minor-audit acceptance validation.
+- `${feature-folder}/spec.md` does not exist.
+- `${feature-folder}/user-story.md` does not exist.
+- `phase0-instructions-read.md` exists in the canonical baseline location with the required metadata fields.
+- every baseline command-step artifact required by the approved plan exists and includes `Timestamp:`, `Command:`, `EXIT_CODE:`, and `Output Summary:`.
+- plan checklist state matches artifact evidence on disk; do not accept blanket or inferred checkoffs.
+
+If any minor-audit integrity condition fails:
+- `policy-audit` MUST NOT report PASS,
+- `feature-audit` overall readiness MUST be `NEEDS REVISION` or `BLOCKED`,
+- remediation inputs MUST explicitly call out the missing/contradictory evidence.
+
+### Conditional deliverables (only if remediation is required)
+
+4. `remediation-inputs.<timestamp>.md`
+   - Concrete, enumerated fix list with acceptance criteria and verification commands.
+   - Must explicitly identify unmet acceptance criteria, if any.
+
+5. `remediation-plan.<timestamp>.md`
+   - MUST be produced by **automatically delegating** to the `atomic_planner` agent (no copy/paste prompt in chat as the primary mechanism).
+   - MUST use `.github/prompts/generate-atomic-plan.prompt.md` as the base prompt template, with all template variables filled deterministically.
+   - MUST be written to the same active feature folder as the audit documents.
+
+## Final report contract (mandatory)
+
+The final response MUST end with these exact single-line fields:
+
+- `REVIEW_STATUS: PASS` or `REVIEW_STATUS: REMEDIATION_REQUIRED`
+- `FEATURE_FOLDER: <path>`
+- `POLICY_AUDIT: <path>`
+- `CODE_REVIEW: <path>`
+- `FEATURE_AUDIT: <path>`
+- `REMEDIATION_INPUTS: <path-or-NONE>`
+- `REMEDIATION_PLAN: <path-or-NONE>`
+
+Set `REVIEW_STATUS: PASS` only when no remediation artifact is required. Set `REVIEW_STATUS: REMEDIATION_REQUIRED` when remediation inputs or a remediation plan was required.
+
+#### Atomic planner delegation requirements (mandatory when remediation is triggered)
+
+When remediation is triggered, the feature review agent MUST:
+
+1) Create a remediation plan target file from a plan template (so `${file}` exists and has structure to fill)
+   - Default template: `docs/features/templates/feature/plan.yyyy-MM-ddTHH-mm.md`
+   - Output path: `<FEATURE_FOLDER>/remediation-plan.<timestamp>.md`
+   - Replace top-level placeholders minimally (feature name, issue reference if known, last updated timestamp). Leave task checkboxes empty for atomic_planner to fill.
+
+2) Delegate to `atomic_planner` with a fully-resolved prompt
+   - The delegated prompt MUST be the content of `.github/prompts/generate-atomic-plan.prompt.md` with:
+     - `${name}` = `Remediation Plan: <feature-folder-name> (<timestamp>)`
+     - `${file}` = `<FEATURE_FOLDER>/remediation-plan.<timestamp>.md`
+     - `${spec}` = `<FEATURE_FOLDER>/remediation-inputs.<timestamp>.md` (PRIMARY requirements source)
+     - `${user-story}` = best-effort: the most relevant scoping doc path (e.g., `<FEATURE_FOLDER>/spec.md` if present), but treated as secondary.
+
+3) Ensure the atomic_planner prompt is **self-contained** (no missing context)
+   - Append a “Context package” section that includes the FULL TEXT (verbatim) of:
+     - `<FEATURE_FOLDER>/remediation-inputs.<timestamp>.md` (primary)
+     - `artifacts/pr_context.summary.txt`
+     - `artifacts/pr_context.appendix.txt` (at minimum: base/head, commits in range, changed files; include full file if feasible)
+     - `<FEATURE_FOLDER>/policy-audit.<timestamp>.md`
+     - `<FEATURE_FOLDER>/code-review.<timestamp>.md`
+     - `<FEATURE_FOLDER>/feature-audit.<timestamp>.md`
+     - The original plan file(s) in the feature folder (e.g., `<FEATURE_FOLDER>/plan.<timestamp>.md` if present)
+
+4) Remediation planning must prioritize remediation-inputs over scoping docs
+   - The remediation plan MUST implement every fix and acceptance criterion listed in `remediation-inputs.<timestamp>.md`.
+   - `spec.md` / `user-story.md` may be used only to preserve boundaries/invariants; do not allow them to dilute or override remediation-inputs.
+
+5) Plan status synchronization requirements (must be included in remediation plan tasks)
+   - The remediation plan MUST include explicit tasks to:
+     - Check off any items in the original `plan.<timestamp>.md` (or feature plan file) that were completed but remain unchecked.
+     - Check off additional items that become delivered as remediation work completes.
+   - These sync tasks MUST be repeated at least:
+     - Once immediately after remediation-plan creation (baseline sync)
+     - Once at the end of the remediation execution (final sync)
+
+## Context Template
+
+- **Base branch (required):** [e.g., `development`, `main`]
+- **Feature intent / summary (optional):** [One sentence describing the feature’s purpose]
+- **Acceptance criteria source (optional):** [Plan / PRD / feature doc if known]
+- **Verification hints (optional):** [Repo-specific tasks/commands to prioritize]
+- **Risk tolerance (optional):** [e.g., “fail if any PARTIAL”, or “allow PARTIAL with remediation plan”]