diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
deleted file mode 100644
index 588a1c48..00000000
--- a/.github/copilot-instructions.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# GitHub Copilot Instructions for Process-PSModule
-
-## Terminal Commands
-
-- Prefer MCP server calls over command-line tools when possible.
-- When running scripts within the [scripts](../.specify/scripts/) folder, just run them directly (shell is default PowerShell).
-- For other commands, send them into `pwsh -Command` to ensure proper execution.
-
-### Quoting in PowerShell
-
-Proper quoting is essential in PowerShell to prevent parsing errors and ensure correct command execution.
-
-- **Direct script execution**: Scripts run directly in PowerShell use standard PowerShell quoting rules. Double quotes expand variables and expressions, while single quotes are literal. No additional shell escaping is needed.
-
-- **Via `pwsh -Command`**: Commands are passed as strings to PowerShell. Enclose the entire command in single quotes to treat it as a literal string. Escape single quotes within the command by doubling them (e.g., `It's` becomes `It''s`). Use double quotes within the command for variable expansion, but ensure the outer single quotes protect the string from shell interpretation.
-
-For arguments containing single quotes, prefer double-quoting the argument inside the command string.
-
-Example: `pwsh -Command 'Write-Host "I''m Groot"'`
diff --git a/.github/prompts/PSModule.analyze.prompt.md b/.github/prompts/PSModule.analyze.prompt.md
deleted file mode 100644
index a3525777..00000000
--- a/.github/prompts/PSModule.analyze.prompt.md
+++ /dev/null
@@ -1,150 +0,0 @@
----
-description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
----
-
-# Analyze
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-Goal: Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/tasks` has successfully produced a complete `tasks.md`.
-
-STRICTLY READ-ONLY: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
-
-Constitution Authority: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/analyze`.
-
-Execution steps:
-
-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
-   - SPEC = FEATURE_DIR/spec.md
-   - PLAN = FEATURE_DIR/plan.md
-   - TASKS = FEATURE_DIR/tasks.md
-   Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command).
-
-2. Load artifacts:
-   - Parse spec.md sections: Overview/Context, Functional Requirements, Non-Functional Requirements, User Stories, Edge Cases (if present).
-   - Parse plan.md: Architecture/stack choices, Data Model references, Phases, Technical constraints.
-   - Parse tasks.md: Task IDs, descriptions, phase grouping, parallel markers [P], referenced file paths.
-   - Load constitution `.specify/memory/constitution.md` for principle validation.
-
-3. Build internal semantic models:
-   - Requirements inventory: Each functional + non-functional requirement with a stable key (derive slug based on imperative phrase; e.g., "User can upload file" -> `user-can-upload-file`).
-   - User story/action inventory.
-   - Task coverage mapping: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases).
-   - Constitution rule set: Extract principle names and any MUST/SHOULD normative statements.
-
-4. Detection passes:
-   A. Duplication detection:
-      - Identify near-duplicate requirements. Mark lower-quality phrasing for consolidation.
-   B. Ambiguity detection:
-      - Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria.
-      - Flag unresolved placeholders (TODO, TKTK, ???, <placeholder>, etc.).
-   C. Underspecification:
-      - Requirements with verbs but missing object or measurable outcome.
-      - User stories missing acceptance criteria alignment.
-      - Tasks referencing files or components not defined in spec/plan.
-   D. Constitution alignment:
-      - Any requirement or plan element conflicting with a MUST principle.
-      - Missing mandated sections or quality gates from constitution.
-   E. Coverage gaps:
-      - Requirements with zero associated tasks.
-      - Tasks with no mapped requirement/story.
-      - Non-functional requirements not reflected in tasks (e.g., performance, security).
-   F. Inconsistency:
-      - Terminology drift (same concept named differently across files).
-      - Data entities referenced in plan but absent in spec (or vice versa).
-      - Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note).
-      - Conflicting requirements (e.g., one requires to use Next.js while other says to use Vue as the framework).
-
-5. Severity assignment heuristic:
-   - CRITICAL: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality.
-   - HIGH: Duplicate or conflicting requirement, ambiguous security/performance attribute, or untestable acceptance criterion.
-   - MEDIUM: Terminology drift, missing non-functional task coverage, or underspecified edge case.
-   - LOW: Style/wording improvements, or minor redundancy not affecting execution order.
-
-6. Produce a Markdown report (no file writes) with sections:
-
-   ```markdown
-   ### Specification Analysis Report
-
-   | ID | Category | Severity | Location(s) | Summary | Recommendation |
-   |----|----------|----------|-------------|---------|----------------|
-   | A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version |
-   (Add one row per finding; generate stable IDs prefixed by category initial.)
-   ```
-
-   Additional subsections:
-   - Coverage Summary Table:
-
-    ```markdown
-    | Requirement Key | Has Task? | Task IDs | Notes |
-    |-----------------|-----------|----------|-------|
-    ```
-
-   - Constitution Alignment Issues (if any)
-   - Unmapped Tasks (if any)
-   - Metrics:
-     * Total Requirements
-     * Total Tasks
-     * Coverage % (requirements with >=1 task)
-     * Ambiguity Count
-     * Duplication Count
-     * Critical Issues Count
-
-7. **Post issue comment** with analysis results organized by severity:
-   - Post a comment to the GitHub issue with the analysis findings
-   - Format the comment with separate tables for each severity level (only include levels that have findings):
-     ```markdown
-     ## Analysis Report
-
-     ### Summary
-     - Total Requirements: X
-     - Total Tasks: Y
-     - Coverage: Z%
-     - Issues Found: N (A critical, B high, C medium, D low)
-
-     ### Critical Issues
-     | ID | Category | Location(s) | Summary | Recommendation |
-     |----|----------|-------------|---------|----------------|
-     | C1 | ... | ... | ... | ... |
-
-     ### High Priority Issues
-     | ID | Category | Location(s) | Summary | Recommendation |
-     |----|----------|-------------|---------|----------------|
-     | H1 | ... | ... | ... | ... |
-
-     ### Medium Priority Issues
-     | ID | Category | Location(s) | Summary | Recommendation |
-     |----|----------|-------------|---------|----------------|
-     | M1 | ... | ... | ... | ... |
-
-     ### Low Priority Issues
-     | ID | Category | Location(s) | Summary | Recommendation |
-     |----|----------|-------------|---------|----------------|
-     | L1 | ... | ... | ... | ... |
-
-     ### Next Actions
-     - [Recommendation based on findings]
-     ```
-   - Keep tables concise, limit to 20 findings per severity level
-   - If more than 20 findings in a category, add a note: "_(Additional N issues not shown - see full report)_"
-   - Include the complete "Next Actions" block with specific recommendations
-
-8. At end of report, output a concise Next Actions block:
-   - If CRITICAL issues exist: Recommend resolving them before `/implement`.
-   - If only LOW/MEDIUM issues: User may proceed, but provide improvement suggestions.
-   - Provide explicit command suggestions: e.g., "Run /specify with refinement", "Run /plan to adjust architecture", or "Manually edit tasks.md to add coverage for 'performance-metrics'".
-
-8. Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
-
-Behavior rules:
-- NEVER modify files.
-- NEVER hallucinate missing sections—if absent, report them.
-- KEEP findings deterministic: if rerun without changes, produce consistent IDs and counts.
-- LIMIT total findings in the main table to 50; aggregate remainder in a summarized overflow note.
-- If zero issues found, emit a success report with coverage statistics and proceed recommendation.
-
-Context: $ARGUMENTS
diff --git a/.github/prompts/PSModule.clarify.prompt.md b/.github/prompts/PSModule.clarify.prompt.md
deleted file mode 100644
index ed8a26d0..00000000
--- a/.github/prompts/PSModule.clarify.prompt.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
----
-
-# Clarify
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
-
-Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
-
-Execution steps:
-
-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
-   - `FEATURE_DIR`
-   - `FEATURE_SPEC`
-   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
-   - If JSON parsing fails, abort and instruct user to re-run `/specify` or verify feature branch environment.
-
-2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).
-
-   Functional Scope & Behavior:
-   - Core user goals & success criteria
-   - Explicit out-of-scope declarations
-   - User roles / personas differentiation
-
-   Domain & Data Model:
-   - Entities, attributes, relationships
-   - Identity & uniqueness rules
-   - Lifecycle/state transitions
-   - Data volume / scale assumptions
-
-   Interaction & UX Flow:
-   - Critical user journeys / sequences
-   - Error/empty/loading states
-   - Accessibility or localization notes
-
-   Non-Functional Quality Attributes:
-   - Performance (latency, throughput targets)
-   - Scalability (horizontal/vertical, limits)
-   - Reliability & availability (uptime, recovery expectations)
-   - Observability (logging, metrics, tracing signals)
-   - Security & privacy (authN/Z, data protection, threat assumptions)
-   - Compliance / regulatory constraints (if any)
-
-   Integration & External Dependencies:
-   - External services/APIs and failure modes
-   - Data import/export formats
-   - Protocol/versioning assumptions
-
-   Edge Cases & Failure Handling:
-   - Negative scenarios
-   - Rate limiting / throttling
-   - Conflict resolution (e.g., concurrent edits)
-
-   Constraints & Tradeoffs:
-   - Technical constraints (language, storage, hosting)
-   - Explicit tradeoffs or rejected alternatives
-
-   Terminology & Consistency:
-   - Canonical glossary terms
-   - Avoided synonyms / deprecated terms
-
-   Completion Signals:
-   - Acceptance criteria testability
-   - Measurable Definition of Done style indicators
-
-   Misc / Placeholders:
-   - TODO markers / unresolved decisions
-   - Ambiguous adjectives ("robust", "intuitive") lacking quantification
-
-   For each category with Partial or Missing status, add a candidate question opportunity unless:
-   - Clarification would not materially change implementation or validation strategy
-   - Information is better deferred to planning phase (note internally)
-
-3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:
-    - Maximum of 5 total questions across the entire session.
-    - Each question must be answerable with EITHER:
-      * A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR
-      * A one-word / short‑phrase answer (explicitly constrain: "Answer in ≤5 words").
-    - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
-    - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved.
-    - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness).
-    - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests.
-    - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic.
-
-4. Sequential questioning loop (interactive):
-    - Present EXACTLY ONE question at a time.
-    - For multiple‑choice questions render options as a Markdown table:
-
-       ```markdown
-       | Option | Description |
-       |--------|-------------|
-       | A | <Option A description> |
-       | B | <Option B description> |
-       | C | <Option C description> (add D/E as needed up to 5) |
-       | Short | Provide a different short answer (<=5 words) (Include only if free-form alternative is appropriate) |
-       ```
-
-    - For short‑answer style (no meaningful discrete options), output a single line after the question: `Format: Short answer (≤5 words)`.
-    - After the user answers:
-       * Validate the answer maps to one option or fits the ≤5 word constraint.
-       * If ambiguous, ask for a quick disambiguation (count still belongs to same question; do not advance).
-       * Once satisfactory, record it in working memory (do not yet write to disk) and move to the next queued question.
-    - Stop asking further questions when:
-       * All critical ambiguities resolved early (remaining queued items become unnecessary), OR
-       * User signals completion ("done", "good", "no more"), OR
-       * You reach 5 asked questions.
-    - Never reveal future queued questions in advance.
-    - If no valid questions exist at start, immediately report no critical ambiguities.
-
-5. Integration after EACH accepted answer (incremental update approach):
-    - Maintain in-memory representation of the spec (loaded once at start) plus the raw file contents.
-    - For the first integrated answer in this session:
-       * Ensure a `## Clarifications` section exists (create it just after the highest-level contextual/overview section per the spec template if missing).
-       * Under it, create (if not present) a `### Session YYYY-MM-DD` subheading for today.
-    - Append a bullet line immediately after acceptance: `- Q: <question> → A: <final answer>`.
-    - Then immediately apply the clarification to the most appropriate section(s):
-       * Functional ambiguity → Update or add a bullet in Functional Requirements.
-       * User interaction / actor distinction → Update User Stories or Actors subsection (if present) with clarified role, constraint, or scenario.
-       * Data shape / entities → Update Data Model (add fields, types, relationships) preserving ordering; note added constraints succinctly.
-       * Non-functional constraint → Add/modify measurable criteria in Non-Functional / Quality Attributes section (convert vague adjective to metric or explicit target).
-       * Edge case / negative flow → Add a new bullet under Edge Cases / Error Handling (or create such subsection if template provides placeholder for it).
-       * Terminology conflict → Normalize term across spec; retain original only if necessary by adding `(formerly referred to as "X")` once.
-    - If the clarification invalidates an earlier ambiguous statement, replace that statement instead of duplicating; leave no obsolete contradictory text.
-    - Save the spec file AFTER each integration to minimize risk of context loss (atomic overwrite).
-    - Preserve formatting: do not reorder unrelated sections; keep heading hierarchy intact.
-    - Keep each inserted clarification minimal and testable (avoid narrative drift).
-
-6. Validation (performed after EACH write plus final pass):
-   - Clarifications session contains exactly one bullet per accepted answer (no duplicates).
-   - Total asked (accepted) questions ≤ 5.
-   - Updated sections contain no lingering vague placeholders the new answer was meant to resolve.
-   - No contradictory earlier statement remains (scan for now-invalid alternative choices removed).
-   - Markdown structure valid; only allowed new headings: `## Clarifications`, `### Session YYYY-MM-DD`.
-   - Terminology consistency: same canonical term used across all updated sections.
-
-7. Write the updated spec back to `FEATURE_SPEC`.
-
-8. **Post issue comment** with clarification summary (only if questions were asked and answered):
-   - Post a comment to the GitHub issue summarizing the clarifications
-   - Format the comment as:
-     ```markdown
-     ## Clarification Session (YYYY-MM-DD)
-
-     | # | Question | Answer |
-     |---|----------|--------|
-     | 1 | <question text> | <answer text> |
-     | 2 | <question text> | <answer text> |
-     | ... | ... | ... |
-
-     _All clarifications have been integrated into the specification._
-     ```
-   - Keep the table concise and readable
-   - Include all questions asked and answers received during this session (up to 5)
-
-9. Report completion (after questioning loop ends or early termination):
-   - Number of questions asked & answered.
-   - Path to updated spec.
-   - Sections touched (list names).
-   - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial/Missing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial/Missing but low impact).
-   - If any Outstanding or Deferred remain, recommend whether to proceed to `/plan` or run `/clarify` again later post-plan.
-   - Suggested next command.
-
-Behavior rules:
-
-- If no meaningful ambiguities found (or all potential questions would be low-impact), respond: "No critical ambiguities detected worth formal clarification." and suggest proceeding.
-- If spec file missing, instruct user to run `/specify` first (do not create a new spec here).
-- Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions).
-- Avoid speculative tech stack questions unless the absence blocks functional clarity.
-- Respect user early termination signals ("stop", "done", "proceed").
-- If no questions asked due to full coverage, output a compact coverage summary (all categories Clear) then suggest advancing.
-- If quota reached with unresolved high-impact categories remaining, explicitly flag them under Deferred with rationale.
-
-Context for prioritization: $ARGUMENTS
diff --git a/.github/prompts/PSModule.constitution.prompt.md b/.github/prompts/PSModule.constitution.prompt.md
deleted file mode 100644
index 454a3a03..00000000
--- a/.github/prompts/PSModule.constitution.prompt.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-description: Create (if absent) or iteratively update the project constitution from interactive or provided inputs, ensuring all dependent templates stay in sync.
----
-
-# Constitution
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-**Note**: This command operates on the local repository's constitution and does not typically require fork-specific logic, as constitutional changes are usually made within the repository itself rather than targeting upstream repositories.
-
-You are (a) creating or (b) iterating on the project constitution at `.specify/memory/constitution.md`.
-
-Two operating modes:
-
-1. Initial Creation Mode (constitution file does NOT exist):
-   - Copy `.specify/templates/constitution-template.md` to `.specify/memory/constitution.md` verbatim before processing.
-   - Treat the copied file as a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`).
-   - Produce an initial version (default `1.0.0` unless the user specifies otherwise). Ratification date = today (unless user supplies one). Last amended date = same as ratification.
-2. Iteration Mode (constitution file already exists):
-   - Load the existing `.specify/memory/constitution.md` (NOT the template) as the authoritative current constitution.
-   - Do NOT re-copy the template. Only reference the template to discover any NEW placeholders/sections that could be adopted.
-   - Identify new functionality / sections / principles requested (from user input or arguments) and integrate them.
-   - If a new principle or governance rule appears to REPLACE or substantially OVERLAP an existing one, generate a Replacement Analysis Table and request user confirmation before destructive changes. If interactive confirmation is not possible in this run, mark the affected original item with `TODO(REVIEW_REPLACEMENT): Proposed replacement: <new title>` and include in the Sync Impact Report under deferred actions.
-   - Preserve original ratification date. Increment version per rules below. Update last amended date to today if any material change occurs.
-
-Replacement Analysis Table (when overlap detected):
-
-| Existing Item       | Proposed New / Change     | Overlap Basis                                | Suggested Action           |
-|---------------------|---------------------------|----------------------------------------------|----------------------------|
-| <title / section>   | <incoming title / change> | e.g. semantic similarity, scope duplication | Replace / Merge / Keep Both |
-
-Heuristics for overlap:
-- Title similarity score (case-insensitive) >= 0.6 (rough string similarity) OR
-- >50% of bullet rules conceptually duplicate (same verbs/nouns) OR
-- Governance rule introduces stricter variant of an existing rule.
-
-If ambiguity remains, prefer non-destructive addition plus TODO marker.
-
-Follow this execution flow:
-
-0. Existence Check & Mode Selection:
-   - If `.specify/memory/constitution.md` is missing → enter Initial Creation Mode (copy template, then proceed).
-   - If it exists → Iteration Mode (operate directly on existing file; treat remaining bracket tokens, if any, as still-to-be-resolved placeholders).
-
-1. Load Source Document:
-   - Creation Mode: load freshly copied `.specify/memory/constitution.md` (formerly the template).
-   - Iteration Mode: load existing `.specify/memory/constitution.md` and independently load `.specify/templates/constitution-template.md` only to detect any NEW placeholders/sections not yet present.
-   - Identify every placeholder token `[ALL_CAPS_IDENTIFIER]` still unresolved in the working constitution (not just in template).
-   - IMPORTANT: User may request changing the number of principles. Respect explicit user instruction; re-number or re-label as needed (maintain Roman numeral style if already in use; otherwise adopt consistent scheme).
-
-2. Collect/derive values for placeholders (and new/changed content):
-   - If user input (conversation) supplies a value, use it.
-   - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
-   - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
-   - `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
-     * MAJOR: Backward incompatible governance/principle removals or redefinitions.
-     * MINOR: New principle/section added or materially expanded guidance.
-     * PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
-   - If version bump type ambiguous, propose reasoning before finalizing.
-
-3. Draft / Merge updated constitution content:
-    - In Iteration Mode, integrate new principles/sections with minimal disruption:
-      * Retain stable identifiers (e.g., keep existing principle numbering unless renumbering is explicitly required or gaps introduced by removals).
-      * When replacing, either (a) fully substitute content if user confirmed or (b) append revised content and mark old with `DEPRECATED:` prefix plus TODO for removal in a future major version.
-    - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
-    - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
-    - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
-    - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
-
-4. Consistency propagation checklist (convert prior checklist into active validations):
-   - Read [`.specify/templates/plan-template.md`](../../.specify/templates/plan-template.md) and ensure any "Constitution Check" or rules align with updated principles.
-   - Read [`.specify/templates/spec-template.md`](../../.specify/templates/spec-template.md) for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
-   - Read [`.specify/templates/tasks-template.md`](../../.specify/templates/tasks-template.md) and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
-   - Read each related prompt file in `.github/prompts/` (including this one) to verify no outdated agent-specific references remain (e.g., names tied to a specific LLM vendor) when generic guidance is required.
-   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
-
-5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
-   - Version change: old → new
-   - List of modified principles (old title → new title if renamed)
-   - Added sections
-   - Removed sections
-   - Deprecated (marked) sections pending removal
-   - Templates requiring updates (✅ updated / ⚠ pending) with file paths
-   - Follow-up TODOs if any placeholders intentionally deferred.
-   - Replacement items needing confirmation (if any)
-
-6. Validation before final output:
-   - No remaining unexplained bracket tokens.
-   - Version line matches report.
-   - Dates in ISO format (YYYY-MM-DD).
-   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
-
-7. Write the completed constitution back to [`.specify/memory/constitution.md`](../../.specify/memory/constitution.md) (overwrite). Never write to the template path during iteration.
-
-8. Output a final summary to the user with:
-   - New version and bump rationale.
-   - Any files flagged for manual follow-up.
-   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
-
-Formatting & Style Requirements:
-- Use Markdown headings exactly as in the template (do not demote/promote levels).
-- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
-- Keep a single blank line between sections.
-- Avoid trailing whitespace.
-
-If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
-
-If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
-
-Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.
diff --git a/.github/prompts/PSModule.implement.prompt.md b/.github/prompts/PSModule.implement.prompt.md
deleted file mode 100644
index 93390842..00000000
--- a/.github/prompts/PSModule.implement.prompt.md
+++ /dev/null
@@ -1,175 +0,0 @@
----
-description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
----
-
-# Implement
-
-The user input can be provided directly by the agent or as a command argument — you **MUST** consider it before proceeding with the prompt (if not empty).
-
-**User input:**
-
-$ARGUMENTS
-
----
-
-**Workflow Modes**: This command supports two modes:
-
-- **Local (default)**: Work with the current repository (origin). No special configuration needed.
-- **Fork**: Contribute to an upstream repository. Detected via `git remote -v`.
-
-**Iteration Support**: This command supports iterative implementation — you can run it multiple times to complete remaining tasks, fix issues, or add refinements. Task completion state is tracked in `tasks.md` with `[X]` markers.
-
----
-
-## Workflow Steps
-
-1. **Set Implementing label immediately**
-   - **Determine target repository**:
-     - Run `git remote -v` to check configured remotes.
-     - **If `upstream` remote exists**: Fork mode
-       - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels)
-       - Use `origin` for all git operations (push, fetch)
-     - **If only `origin` remote exists**: Origin mode
-       - Use `origin` owner/repo for all operations (both git push and GitHub operations)
-     - Parse the URLs to extract owner and repo name: `https://github.com/<owner>/<repository>.git`.
-     - If in doubt, ask the user to clarify which repository to target.
-   - Get the issue number associated with the current feature branch.
-   - **Add `Implementing` label** to the issue and PR immediately in the target repository.
-   - **Remove `Planning` label** from the issue and PR.
-
-   **GitHub Integration**: If GitHub tools are available, update labels automatically in the target repository. If not available, use:
-
-   ```bash
-   # If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Planning" --add-label "Implementing"
-   # If local: gh issue edit <issue-number> --remove-label "Planning" --add-label "Implementing"
-   gh issue edit <issue-number> --remove-label "Planning" --add-label "Implementing"
-   ```
-
-2. **Run prerequisites**
-   Run [`check-prerequisites.ps1`](../../.specify/scripts/powershell/check-prerequisites.ps1) from repo root:
-
-   ```powershell
-   .specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks
-   ```
-
-   Parse `FEATURE_DIR` and `AVAILABLE_DOCS` list. All paths must be absolute.
-
-3. **Load and analyze the implementation context**
-
-   * **REQUIRED**: Read `tasks.md` for the complete task list and execution plan.
-   * **REQUIRED**: Read `plan.md` for tech stack, architecture, and file structure.
-   * **IF EXISTS**: Read `data-model.md` for entities and relationships.
-   * **IF EXISTS**: Read `contracts/` for API specifications and test requirements.
-   * **IF EXISTS**: Read `research.md` for technical decisions and constraints.
-   * **IF EXISTS**: Read `quickstart.md` for integration scenarios.
-
-4. **Parse `tasks.md` structure and extract**
-
-   * Detect iteration state (completed `[X]`, pending `[ ]`).
-   * Identify task phases: Setup, Tests, Core, Integration, Polish.
-   * Capture dependencies: sequential vs parallel (`[P]`).
-   * Build execution flow based on order and requirements.
-
-5. **Execute implementation following the task plan**
-
-   * Skip completed `[X]` tasks.
-   * Resume from first `[ ]` task.
-   * Execute phase-by-phase, respecting dependencies.
-   * Follow TDD: tests before implementation.
-   * Coordinate tasks by file access.
-   * Add validation checkpoints.
-
-6. **Implementation execution rules**
-
-   * Setup first (dependencies, configs).
-   * Tests before code.
-   * Core development.
-   * Integration (DB, middleware, logging, external services).
-   * Polish (tests, performance, docs).
-
-7. **Progress tracking and error handling**
-
-   * Report progress after each task.
-   * Halt on failed sequential tasks; continue parallel `[P]` where possible.
-   * Provide clear error messages and next-step suggestions.
-   * **Update task status immediately after completion**:
-
-     * Mark as `[X]` in `tasks.md`.
-     * Update PR task list (`- [ ] T###:` → `- [X] T###:`).
-     * Use `gh pr edit <PR-number> --body "<updated-description>"` if needed.
-
-8. **Completion validation**
-
-   * Verify required tasks.
-   * Confirm spec compliance.
-   * Ensure tests pass and coverage is met.
-   * Check against `plan.md`.
-   * Report final status.
-
-9. **Update the constitution**
-
-   * Read [Constitution](../../.specify/memory/constitution.md).
-   * Read [constitution prompt](./constitution.prompt.md).
-   * Update constitution with implemented details.
-   * Remove obsolete sections.
-
-10. **Update the CHANGELOG**
-
-    * Use `CHANGELOG.md` in root.
-    * Add entry in [Keep a Changelog](https://keepachangelog.com) format.
-    * Categories: Added, Changed, Deprecated, Removed, Fixed, Security.
-    * Keep user-focused and concise.
-    * Example:
-
-      ```markdown
-      ## [Unreleased] - 2025-10-03
-
-      ### Added
-      - Support for new implementation workflow [#123]
-      ```
-
-11. **Final commit and push**
-
-    * Stage all changes (`tasks.md`, `CHANGELOG.md`, `constitution.md`, code, configs).
-    * Commit using Conventional Commit format:
-
-      ```markdown
-      <type>(<scope>): <description>
-      Fixes #<issue-number>
-      ```
-    * Push branch to remote.
-
-12. **Update PR description with release notes**
-
-    * Replace PR body entirely with release notes.
-    * Ensure title matches issue.
-    * Release note structure:
-
-      * Opening summary (what, why, impact).
-      * **What's Changed** (3–5 bullets).
-      * **Usage** (if needed).
-      * **Breaking Changes** (if any).
-      * **Technical Notes** (optional).
-
-    **Fallback command:**
-
-    ```bash
-    gh pr edit <PR-number> --body "<release-note-description>"
-    ```
-
-13. **Mark PR as ready for review**
-
-    * Remove `Implementing` label.
-    * Ensure PR is not draft.
-
-    **Fallback commands:**
-
-    ```bash
-    gh pr ready <PR-number>
-    gh issue edit <issue-number> --remove-label "Implementing"
-    gh pr edit <PR-number> --remove-label "Implementing"
-    ```
-
----
-
-**Note**: This command assumes a complete task breakdown exists in `tasks.md`. If missing, run `/tasks` first to regenerate.
diff --git a/.github/prompts/PSModule.plan.prompt.md b/.github/prompts/PSModule.plan.prompt.md
deleted file mode 100644
index 26959b24..00000000
--- a/.github/prompts/PSModule.plan.prompt.md
+++ /dev/null
@@ -1,142 +0,0 @@
----
-description: Execute the implementation planning workflow using the plan template to generate design artifacts.
----
-
-# Plan
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-**Workflow Modes**: This command supports two modes:
-- **Local (default)**: Work with the current repository (origin). No special configuration needed.
-- **Fork**: Contribute to an upstream repository. Detected via `git remote -v`.
-
-**Iteration Support**: This command detects whether you're creating a new plan or updating an existing one based on the presence of plan.md in the feature directory.
-
-Given the implementation details provided as an argument, do this:
-
-1. **Set Planning label immediately**:
-   - **Determine target repository**:
-     - Run `git remote -v` to check configured remotes.
-     - **If `upstream` remote exists**: Fork mode
-       - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels)
-       - Use `origin` for all git operations (push, fetch)
-     - **If only `origin` remote exists**: Origin mode
-       - Use `origin` owner/repo for all operations (both git push and GitHub operations)
-     - Parse the URLs to extract owner and repo name: `https://github.com/<owner>/<repository>.git`.
-     - If in doubt, ask the user to clarify which repository to target.
-   - Get the issue number associated with the current feature branch
-   - **Add 'Planning' label** to the issue immediately in the target repository
-   - **Remove 'Specification' label** from the issue
-
-   **GitHub Integration**: If GitHub tools are available, update labels automatically in the target repository. If not available, use:
-   ```bash
-   # If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Specification" --add-label "Planning"
-   # If local: gh issue edit <issue-number> --remove-label "Specification" --add-label "Planning"
-   gh issue edit <issue-number> --remove-label "Specification" --add-label "Planning"
-   ```
-
-2. Run [`.specify/scripts/powershell/setup-plan.ps1 -Json`](../../.specify/scripts/powershell/setup-plan.ps1) from the repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. All future file paths must be absolute.
-   - **Detect iteration mode**: Check if IMPL_PLAN (plan.md) already exists:
-     - **If exists**: You are ITERATING on an existing plan. User input should guide refinements/additions to the existing plan content.
-     - **If not exists**: You are CREATING a new plan from scratch.
-   - BEFORE proceeding, inspect FEATURE_SPEC for a `## Clarifications` section with at least one `Session` subheading. If missing or clearly ambiguous areas remain (vague adjectives, unresolved critical choices), PAUSE and instruct the user to run `/clarify` first to reduce rework. Only continue if: (a) Clarifications exist OR (b) an explicit user override is provided (e.g., "proceed without clarification"). Do not attempt to fabricate clarifications yourself.
-
-3. Read and analyze the feature specification to understand:
-   - The feature requirements and user stories
-   - Functional and non-functional requirements
-   - Success criteria and acceptance criteria
-   - Any technical constraints or dependencies mentioned
-
-4. Read the constitution at [`.specify/memory/constitution.md`](../../.specify/memory/constitution.md) to understand constitutional requirements.
-
-5. Execute the implementation plan template:
-   - Load [`.specify/templates/plan-template.md`](../../.specify/templates/plan-template.md) (already copied to IMPL_PLAN path)
-   - Set Input path to FEATURE_SPEC
-   - **If ITERATING** (plan.md exists):
-     - Read existing plan.md content
-     - Identify what needs updating based on user input ($ARGUMENTS)
-     - Preserve existing valid content
-     - Refine or expand sections as needed
-     - Maintain consistency with existing decisions unless explicitly changing them
-   - **If CREATING** (new plan):
-     - Run the Execution Flow (main) function steps 1-9
-     - The template is self-contained and executable
-     - Follow error handling and gate checks as specified
-   - Let the template guide artifact generation in $SPECS_DIR:
-     * Phase 0 generates research.md
-     * Phase 1 generates data-model.md, contracts/, quickstart.md
-     * Phase 2 generates tasks.md
-   - Incorporate user-provided details from arguments into Technical Context: $ARGUMENTS
-   - Update Progress Tracking as you complete each phase
-
-6. Verify execution completed:
-   - Check Progress Tracking shows all phases complete
-   - Ensure all required artifacts were generated
-   - Confirm no ERROR states in execution
-
-7. Commit and push the changes:
-   - Stage all generated artifacts and modified files
-   - Create a commit with a descriptive message summarizing the plan
-   - Push the branch (BRANCH) to remote
-
-8. Create or update a Pull Request:
-   - **Determine workflow mode and target repository**:
-     - Run `git remote -v` to check configured remotes.
-     - **If `upstream` remote exists**: Fork mode
-       - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels)
-       - Use `origin` for all git operations (push, fetch)
-     - **If only `origin` remote exists**: Origin mode
-       - Use `origin` owner/repo for all operations (both git push and GitHub operations)
-     - Parse the URLs to extract owner and repo name: `https://github.com/<owner>/<repository>.git`.
-     - If in doubt, ask the user to clarify which repository to target.
-   - **Determine PR operation** (create vs update):
-     - If PR already exists for this branch, UPDATE it
-     - If no PR exists, CREATE a new one
-   - The PR must be against the default branch.
-   - The PR must be opened as a draft (or remain draft if updating).
-   - **Retrieve the issue title**: Get the title from the linked GitHub issue (created in `/specify`) from the target repository
-   - **Use the same title for the PR**: The PR title must match the issue title exactly
-   - If unable to retrieve the issue title, determine the PR type and icon based on the changes:
-
-     | Type of change  | Icon | Label      |
-     | --------------- | ---- | ---------- |
-     | Docs            | 📖   | Docs       |
-     | Fix             | 🪲   | Fix, Patch |
-     | Security fix    | ⚠️   | Fix        |
-     | Patch           | 🩹   | Patch      |
-     | Feature         | 🚀   | Minor      |
-     | Breaking change | 🌟   | Major      |
-
-   - Fallback PR title format (if issue title unavailable): `<Icon> [Type of change]: <Short description>`
-   - Create PR description:
-     * Start with a summary paragraph describing the key outcome and changes for user
-     * DO NOT add a title before the leading paragraph
-     * At the end of the PR paragraph, add a "- Fixes #<issue-number>" line to link the PR to the issue
-     * Follow with additional details answering Why, How, and What
-     * Avoid superfluous headers or sections
-     * We do not need details, we need to add what changes for the user of the code
-   - **Apply appropriate labels to the PR**:
-     * **Version/change level label**: Based on the type of change: `Major`, `Minor`, `Patch`, `Fix`, or `Docs`
-     * **Phase label**: `Planning` (to indicate current phase)
-   - Link the PR to the associated issue
-
-   **GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to create/update the PR and manage labels automatically in the target repository. If not available, provide these fallback commands with the correct repository:
-   ```bash
-   # Create draft PR with both version/change level label and Planning label
-   # If fork: gh pr create --repo <upstream_owner>/<upstream_repo> --draft --title "<Icon> [Type]: <Description>" --body "<PR description>" --label "<Version-Label>,Planning"
-   # If local: gh pr create --draft --title "<Icon> [Type]: <Description>" --body "<PR description>" --label "<Version-Label>,Planning"
-   gh pr create --draft --title "<Icon> [Type]: <Description>" --body "<PR description>" --label "<Version-Label>,Planning"
-
-   # Link to issue (if not using "Fixes #<issue>" in body)
-   gh pr edit <PR-number> --add-label "<Version-Label>,Planning"
-   ```
-
-9. **Post final status comment**: "✅ Planning complete. Ready for task generation with `/tasks` or analysis with `/analyze`."
-
-10. Report results with branch name, PR URL, file paths, and generated artifacts.
-
-Use absolute paths with the repository root for all file operations to avoid path issues.
diff --git a/.github/prompts/PSModule.pr.prompt.md b/.github/prompts/PSModule.pr.prompt.md
deleted file mode 100644
index 0787c242..00000000
--- a/.github/prompts/PSModule.pr.prompt.md
+++ /dev/null
@@ -1,166 +0,0 @@
----
-description: Create a pull request with a release note style description, appropriate title, and labels based on the change type.
----
-
-# PR
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-Use the GitHub MCP tools to create or update a pull request in the appropriate repository (fork or origin mode), with a structured release note style description, a title that includes an icon and change type, and labels based on the specified change type.
-
-## User input
-
-$ARGUMENTS
-
-**Purpose**: Create or update a pull request with a release note style description and title, automatically applying the appropriate labels based on the change type specified.
-
-## Supported Change Types
-
-| Type        | Icon | Labels         | Description                                |
-| ----------- | ---- | -------------- | -------------------------------------------|
-| Major       | 🌟   | `Major`        | Breaking changes that affect compatibility |
-| Minor       | 🚀   | `Minor`        | New features or enhancements               |
-| Patch       | 🩹   | `Patch`        | Small fixes or improvements                |
-| Docs        | 📖   | `NoRelease`    | Documentation changes only                 |
-| Maintenance | ⚙️   | `NoRelease`    | CI/CD, build configs, internal maintenance |
-
-## Execution Steps
-
-0. If a folder is **explicitly attached to this chat** (“references”), you **must** change directory to the root of the git folder it is in. If there are no git folders you can change to the provided folder.
-
-1. **Detect repository mode**:
-   - Run `git remote -v` to check configured remotes.
-   - **If `upstream` remote exists**: Fork mode
-     - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels)
-     - Use `origin` for all git operations (push, fetch)
-   - **If only `origin` remote exists**: Origin mode
-     - Use `origin` owner/repo for all operations (both git push and GitHub operations)
-   - Parse the URLs to extract owner and repo name: `https://github.com/<owner>/<repository>.git`.
-   - If in doubt, ask the user to clarify which repository to target.
-
-2. **Determine the change type**:
-   1. Parse the user input to identify the change type (Major, Minor, Patch, Fix, Docs, or Maintenance)
-   2. If nothing is provided, **analyze ALL changes in the branch** to infer the type:
-      - Run `git diff origin/main...HEAD --name-only` to get all changed files in the branch
-      - Read the diff content using `git diff origin/main...HEAD` to understand the nature of changes
-      - Categorize based on ALL changes combined, not just recent commits:
-        * **Maintenance**: CI/CD workflows, build configs, dependency updates, or internal tooling with no user-facing changes
-        * **Docs**: ONLY if ALL changes are to documentation files (*.md, docs/, .github/prompts/, etc.) with no code/functionality changes
-        * **Patch**: Small fixes or improvements that do not add new features
-        * **Minor**: New features or enhancements that do not break existing functionality
-        * **Major**: Changes that break backward compatibility (e.g., removing public APIs, changing method signatures)
-      - **Important**: If the branch contains BOTH code changes AND documentation changes, classify based on the code changes, not the documentation
-      - **Important**: Check the entire branch diff, not just uncommitted changes or the last commit
-
-3. **Stage, commit, and push all changes**:
-   - **ALWAYS run these commands before creating/updating the PR**:
-     1. `git add .` - Stage all changes (tracked and untracked files)
-     2. Check if there are staged changes with `git diff --cached --quiet`
-     3. If there are staged changes, commit with: `git commit -m "Update for PR"`
-     4. `git push origin <branch-name>` - Push to origin remote (even in fork mode)
-   - This ensures the PR reflects all local changes
-   - Get the current branch name for the push command
-
-4. **Retrieve linked issue information** (if available):
-   - Attempt to find the GitHub issue number associated with the current branch
-   - If found, retrieve the issue title from the **target repository** (upstream in fork mode, origin otherwise)
-   - Use the issue title as the PR title (with appropriate icon prefix)
-   - If no issue is found, ask the user to provide one of the following:
-     - the number of the issue to link to the PR
-     - if a new issue should be raised for this PR
-     - Stop if the user cannot provide either of these.
-
-5. **Generate PR title**:
-   - **If issue title retrieved**: Use format `<Icon> [<type of change>]: <Issue Title>`
-   - Examples:
-     - `🚀 [Feature]: Add support for custom module templates`
-     - `🪲 [Fix]: Resolve null reference in parameter validation`
-     - `📖 [Docs]: Update installation guide with prerequisites`
-     - `⚙️ [Maintenance]: Update Release workflow and dependencies`
-
-6. **Generate release note style description**:
-   - The PR description will be used automatically as the release note in an automated release
-   - Use this exact structure (ordered list format):
-
-   **1. Leading Paragraph (Summary)**
-   - Write a concise paragraph describing **what changes for the user** of the solution
-   - Focus on user-facing value and impact, not implementation details
-   - Use present tense and active voice
-   - Audience: Users of the solution (not developers)
-
-   **2. Issue Links (Unordered List)**
-   - Add one or more issue links as unordered list items
-   - Format: `- Fixes #<issue-number>`
-   - If multiple issues: `- Fixes #<issue-1>`, `- Fixes #<issue-2>`
-
-   **3. Details (Sections with Headers)**
-   - For each significant change, add a header (e.g., `## Configuration`, `## Breaking Changes`, `## Usage`)
-   - Under each header, provide:
-     * Details of what changed
-     * What the user needs to change or do differently (if anything)
-     * Examples or code snippets if helpful for understanding
-   - Keep sections concise and user-focused
-   - Avoid implementation details unless necessary for user understanding
-
-   **Example Structure:**
-   ````markdown
-   The workflow now provides fine-grained control over repository linting behavior through simple configuration options. You can disable the linter entirely or customize which validations run by configuring super-linter environment variables directly in your settings file.
-
-   - Fixes #218
-
-   ## Configure settings for repository linting
-
-   You can now control the linter behavior via the `Linter` section in your `.settings.yml` file. This allows you to skip linting altogether or customize which validations are performed.
-
-   Added `Linter.Skip` and `Linter.env` settings to control linter behavior. You can now disable the linter entirely or customize which validations run.
-
-   To disable the linter:
-   ```yaml
-   Linter:
-     Skip: true
-   ```
-
-   To customize validations:
-   ```yaml
-   Linter:
-     env:
-       VALIDATE_JSCPD: false
-   ```
-
-   ````
-
-7. **Create or update the pull request**:
-   - **Check if PR already exists** for this branch in the **target repository** (upstream in fork mode, origin otherwise)
-   - **If PR exists**: Update the title, description, and labels
-   - **If PR does not exist**: Create a new PR from your fork's branch to the target repository's default branch
-   - In fork mode, the PR will be from `<fork-owner>:<branch>` to `<upstream-owner>:<default-branch>`
-   - Set PR to target the default branch (main/master) of the target repository
-   - Open as a **draft PR** (or keep as draft if updating)
-   - **Use GitHub MCP tools** to perform these operations in the **target repository**:
-     - Create PR (if not exists) - owner/repo should be target repository, use `create_pull_request`
-     - Update PR (if exists) - owner/repo should be target repository, use `update_pull_request`
-     - Add labels to PR - owner/repo should be target repository, use `update_issue` (PRs are issues in GitHub API)
-
-8. **Apply labels to the PR**:
-   - Add the **change type label** based on the type specified (Major, Minor, Patch, Fix, Docs, or Maintenance)
-   - If currently in a feature workflow phase (e.g., Planning, Implementation), also apply that phase label
-   - Use GitHub MCP to add labels in the **target repository** (upstream in fork mode, origin otherwise)
-
-9. **Confirm completion**:
-   - Display the PR URL to the user
-   - Summarize the PR title, type, and labels applied
-   - If in fork mode, remind the user that the PR was created in the upstream repository
-
-
-## Notes
-
-- **This command always stages all changes (`git add .`), commits if needed, and pushes to origin before creating/updating the PR**
-- Changes are always pushed to `origin` remote
-- In fork mode, PRs and Issue operations are performed on the `upstream` repository
-- In origin mode, all operations use the `origin` repository
-- The PR is always created as a draft to allow for review before marking as ready
-- Labels can be manually adjusted after PR creation if needed
-- **The PR description uses a structured format designed for automated release notes**:
-  1. Leading paragraph (user-focused summary)
-  2. Issue links (unordered list)
-  3. Details (sections with headers explaining changes and user actions needed)
diff --git a/.github/prompts/PSModule.specify.prompt.md b/.github/prompts/PSModule.specify.prompt.md
deleted file mode 100644
index 0f0d7447..00000000
--- a/.github/prompts/PSModule.specify.prompt.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-description: Create or update the feature specification from a natural language feature description.
----
-
-# Specify
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-**Workflow Modes**: This command supports two modes:
-- **Local (default)**: Work with the current repository (origin). No special configuration needed.
-- **Fork**: Contribute to an upstream repository. Automatically detected via `git remote -v`.
-
-**Iteration Support**: This command detects whether you're creating a new feature or refining an existing one based on your current branch.
-
-The text the user typed after `/specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `$ARGUMENTS` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
-
-Given that feature description, do this:
-
-1. **Detect repository mode**:
-   - Run `git remote -v` to check configured remotes.
-   - **If `upstream` remote exists**: Fork mode
-     - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels)
-     - Use `origin` for all git operations (push, fetch)
-   - **If only `origin` remote exists**: Origin mode
-     - Use `origin` owner/repo for all operations (both git push and GitHub operations)
-   - Parse the URLs to extract owner and repo name: `https://github.com/<owner>/<repository>.git`.
-   - If in doubt, ask the user to clarify which repository to target.
-
-2. Analyze the feature description and generate a concise, descriptive branch name:
-   - Extract the core concept/action from the description (2-4 words maximum)
-   - Use kebab-case format (lowercase, hyphen-separated)
-   - Focus on the primary change or feature being implemented
-   - Examples: "user-authentication", "merge-workflows", "api-rate-limiting", "fix-memory-leak"
-
-3. Run the script [`.specify/scripts/powershell/create-new-feature.ps1 -Json -FeatureDescription "$ARGUMENTS" -BranchName "<your-generated-name>"`](../../.specify/scripts/powershell/create-new-feature.ps1) from repo root and parse its JSON output for BRANCH_NAME, SPEC_FILE, and IS_EXISTING_BRANCH. All file paths must be absolute.
-
-**IMPORTANT** You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for.
-
-**NOTE**
-
-- The script will prepend an auto-incremented feature number (e.g., `003-`) to your branch name.
-- If you're currently on `main` branch, a new feature branch will be created.
-- If you're already on a feature branch (starts with 3 digits like `001-`, `002-`, etc.), you'll stay on that branch to iterate on the existing feature.
-- This allows you to refine specifications without creating multiple branches for the same feature.
-
-4. Load [`.specify/templates/spec-template.md`](../../.specify/templates/spec-template.md) to understand required sections.
-
-5. **Write or update the specification**:
-   - **If IS_EXISTING_BRANCH is false** (new feature on main branch):
-     - Write a new specification to SPEC_FILE using the template structure
-     - Replace placeholders with concrete details derived from the feature description
-     - Preserve section order and headings from the template
-   - **If IS_EXISTING_BRANCH is true** (iterating on existing feature):
-     - Read the existing SPEC_FILE to understand the current specification
-     - Analyze the new feature description (arguments) to identify:
-       - New requirements or details to add
-       - Existing content that needs refinement or clarification
-       - Sections that may need updating based on the new input
-     - Update the specification incrementally:
-       - Preserve all existing content that remains relevant
-       - Add new sections or details where the new description adds information
-       - Refine or expand existing sections where the new description provides clarification
-       - Maintain the template structure and section order
-     - The goal is evolution, not replacement - build upon the existing spec rather than starting over
-
-6. Create or update a GitHub issue for this feature:
-   - **Use target repository determined in step 1**:
-     - If fork mode: Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels)
-     - If origin mode: Use `origin` owner/repo for all operations (both git push and GitHub operations)
-   - **Generate the issue title** in format `<Icon> [Type]: <Feature name>` where:
-     - Icon: 📖 (Docs), 🪲 (Fix), ⚠️ (Security fix), 🩹 (Patch), 🚀 (Feature/Minor), 🌟 (Breaking change/Major)
-     - Type: Docs, Fix, Patch, Feature, or Breaking change
-     - Feature name: Short description from the spec
-   - **Store the generated title** for use in subsequent workflow steps (plan, implement)
-   - **If IS_EXISTING_BRANCH is true**:
-     - Update the existing issue associated with this feature branch (if one exists) with the refined specification
-     - **Evaluate if the title needs updating**: If the feature scope has changed significantly (e.g., from patch to feature, or major functionality changes), update the issue title. For minor refinements or clarifications, keep the existing title.
-     - **Ensure Specification label**: Verify the issue has the 'Specification' label (indicates current phase)
-   - **If IS_EXISTING_BRANCH is false** (new branch): Create a new GitHub issue with:
-     - Title: Use the generated title format above
-     - Body: The complete content of the SPEC_FILE (spec.md). Remove the first H1 (#) header and the first H2 (##) header if they exist. We want the PR description to start with the "Primary user story" section.
-     - Labels:
-       - `Specification` (always - indicates current phase)
-       - Type-based label: `Docs`, `Fix`, `Patch`, `Minor`, or `Major` based on the type of change
-
-   **GitHub Integration**: If GitHub MCP Server is available, use it to create/update the issue automatically in the target repository. ONLY IF NOT AVAILABLE; provide the appropriate fallback command with the correct repository:
-
-   For new issues:
-   ```bash
-   # If fork: gh issue create --repo <upstream_owner>/<upstream_repo> ...
-   # If local: gh issue create ...
-   gh issue create --title "<Icon> [Type]: <Feature name>" --body-file <SPEC_FILE> --label "Specification,<Type>" --body "<existing body>\n\n---\n**Feature Branch**: `<BRANCH_NAME>`"
-   ```
-
-   For updating existing issues (find the issue number associated with the branch):
-   ```bash
-   # If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> ...
-   # If local: gh issue edit <issue-number> ...
-   gh issue edit <issue-number> --body-file <SPEC_FILE>
-   ```
-
-7. **Post final status comment**: "✅ Specification complete. Ready for clarification with `/clarify` or planning with `/plan`."
-
-8. Report completion with branch name, spec file path, whether it's a new or updated feature, issue number, target repository (if fork), and readiness for the next phase.
-
-Note: The script handles branch creation/reuse and initializes the spec file before writing.
diff --git a/.github/prompts/PSModule.tasks.prompt.md b/.github/prompts/PSModule.tasks.prompt.md
deleted file mode 100644
index 3cfc71d0..00000000
--- a/.github/prompts/PSModule.tasks.prompt.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
----
-
-# Tasks
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-**Workflow Modes**: This command supports two modes:
-- **Local (default)**: Work with the current repository (origin). No special configuration needed.
-- **Fork**: Contribute to an upstream repository. Detected via `git remote -v`.
-
-**Iteration Support**: This command detects whether you're creating new tasks or updating existing ones based on the presence of tasks.md in the feature directory.
-
-1. Run [`.specify/scripts/powershell/check-prerequisites.ps1 -Json`](../../.specify/scripts/powershell/check-prerequisites.ps1) from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
-   - **Detect iteration mode**: Check if FEATURE_DIR/tasks.md already exists:
-     - **If exists**: You are ITERATING on existing tasks. User input should guide refinements, additions, or reordering of tasks.
-     - **If not exists**: You are CREATING new tasks from scratch.
-
-2. Load and analyze available design documents:
-   - Always read plan.md for tech stack and libraries
-   - IF EXISTS: Read data-model.md for entities
-   - IF EXISTS: Read contracts/ for API endpoints
-   - IF EXISTS: Read research.md for technical decisions
-   - IF EXISTS: Read quickstart.md for test scenarios
-
-   Note: Not all projects have all documents. For example:
-   - Command-line tools might not have contracts/
-   - Simple libraries might not need data-model.md
-   - Generate tasks based on what's available
-
-3. Generate tasks following the template:
-   - **If ITERATING** (tasks.md exists):
-     - Read existing tasks.md content
-     - Identify what needs updating based on user input ($ARGUMENTS)
-     - Preserve completed tasks (marked with [X])
-     - Add new tasks as needed
-     - Reorder or refine task descriptions
-     - Maintain task ID sequence
-   - **If CREATING** (new tasks):
-     - Use [`.specify/templates/tasks-template.md`](../../.specify/templates/tasks-template.md) as the base
-     - Replace example tasks with actual tasks based on:
-       * **Setup tasks**: Project init, dependencies, linting
-       * **Test tasks [P]**: One per contract, one per integration scenario
-       * **Core tasks**: One per entity, service, CLI command, endpoint
-       * **Integration tasks**: DB connections, middleware, logging
-       * **Polish tasks [P]**: Unit tests, performance, docs
-
-4. Task generation rules:
-   - Each contract file → contract test task marked [P]
-   - Each entity in data-model → model creation task marked [P]
-   - Each endpoint → implementation task (not parallel if files are shared)
-   - Each user story → integration test marked [P]
-   - Different files = can be parallel [P]
-   - Same file = sequential (no [P])
-
-5. Order tasks by dependencies:
-   - Setup before everything
-   - Tests before implementation (TDD)
-   - Models before services
-   - Services before endpoints
-   - Core before integration
-   - Everything before polish
-
-6. Include parallel execution examples:
-   - Group [P] tasks that can run together
-   - Show actual Task agent commands
-
-7. Create FEATURE_DIR/tasks.md with:
-   - Correct feature name from implementation plan
-   - Numbered tasks (T001, T002, etc.)
-   - Clear file paths for each task
-   - Dependency notes
-   - Parallel execution guidance
-   - **IMPORTANT**: After each task in the task list, add a sub-step to update the PR description:
-     * Add: "After completing this task, update the PR description to mark this task as complete by changing `- [ ] T###:` to `- [X] T###:` in the Implementation Tasks section"
-     * This ensures that the PR description stays synchronized with actual progress
-     * Each task should have this update step included in its description or as a final action item
-
-8. Update the Pull Request description:
-   - **Determine workflow mode and target repository**:
-     - Run `git remote -v` to check configured remotes.
-     - **If `upstream` remote exists**: Fork mode
-       - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels)
-       - Use `origin` for all git operations (push, fetch)
-     - **If only `origin` remote exists**: Origin mode
-       - Use `origin` owner/repo for all operations (both git push and GitHub operations)
-     - Parse the URLs to extract owner and repo name: `https://github.com/<owner>/<repository>.git`.
-     - If in doubt, ask the user to clarify which repository to target.
-   - Append or update the tasks.md content in the existing PR description
-   - Format tasks with checkboxes for each task phase:
-     * Setup: `- [ ] T001: Task description`
-     * Tests: `- [ ] T002: Task description [P]`
-     * Core: `- [ ] T003: Task description`
-     * Integration: `- [ ] T004: Task description`
-     * Polish: `- [ ] T005: Task description [P]`
-   - Keep the existing PR content (summary, plan.md content, issue link)
-   - Add a section header before tasks: `## Implementation Tasks`
-
-   **GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to update the PR description automatically in the target repository. If not available, provide this fallback command with the correct repository:
-   ```bash
-   # Get current PR description and append tasks
-   # If fork: gh pr view <PR-number> --repo <upstream_owner>/<upstream_repo> --json body --jq .body > temp_body.md
-   # If local: gh pr view <PR-number> --json body --jq .body > temp_body.md
-   gh pr view <PR-number> --json body --jq .body > temp_body.md
-   cat tasks.md >> temp_body.md
-   # If fork: gh pr edit <PR-number> --repo <upstream_owner>/<upstream_repo> --body-file temp_body.md
-   # If local: gh pr edit <PR-number> --body-file temp_body.md
-   gh pr edit <PR-number> --body-file temp_body.md
-   rm temp_body.md
-   ```
-
-9. **Post final status comment**: "✅ Task list ready. Run `/analyze` for quality check or `/implement` to begin execution."
-
-10. Report completion with task count, file path, and PR update status.
-
-Context for task generation: $ARGUMENTS
-
-The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without requiring additional context.
diff --git a/.specify/scripts/powershell/check-prerequisites.ps1 b/.specify/scripts/powershell/check-prerequisites.ps1
deleted file mode 100644
index 9ac7a434..00000000
--- a/.specify/scripts/powershell/check-prerequisites.ps1
+++ /dev/null
@@ -1,148 +0,0 @@
-#!/usr/bin/env pwsh
-
-# Consolidated prerequisite checking script (PowerShell)
-#
-# This script provides unified prerequisite checking for Spec-Driven Development workflow.
-# It replaces the functionality previously spread across multiple scripts.
-#
-# Usage: ./check-prerequisites.ps1 [OPTIONS]
-#
-# OPTIONS:
-#   -Json               Output in JSON format
-#   -RequireTasks       Require tasks.md to exist (for implementation phase)
-#   -IncludeTasks       Include tasks.md in AVAILABLE_DOCS list
-#   -PathsOnly          Only output path variables (no validation)
-#   -Help, -h           Show help message
-
-[CmdletBinding()]
-param(
-    [switch]$Json,
-    [switch]$RequireTasks,
-    [switch]$IncludeTasks,
-    [switch]$PathsOnly,
-    [switch]$Help
-)
-
-$ErrorActionPreference = 'Stop'
-
-# Source common functions
-. "$PSScriptRoot/common.ps1"
-
-# Show help if requested
-if ($Help) {
-    Write-Output @'
-Usage: check-prerequisites.ps1 [OPTIONS]
-
-Consolidated prerequisite checking for Spec-Driven Development workflow.
-
-OPTIONS:
-  -Json               Output in JSON format
-  -RequireTasks       Require tasks.md to exist (for implementation phase)
-  -IncludeTasks       Include tasks.md in AVAILABLE_DOCS list
-  -PathsOnly          Only output path variables (no prerequisite validation)
-  -Help, -h           Show this help message
-
-EXAMPLES:
-  # Check task prerequisites (plan.md required)
-  .\check-prerequisites.ps1 -Json
-
-  # Check implementation prerequisites (plan.md + tasks.md required)
-  .\check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks
-
-  # Get feature paths only (no validation)
-  .\check-prerequisites.ps1 -PathsOnly
-
-'@
-    exit 0
-}
-
-# Get feature paths and validate branch
-$paths = Get-FeaturePathsEnv
-
-if (-not (Test-FeatureBranch -Branch $paths.CURRENT_BRANCH -HasGit:$paths.HAS_GIT)) {
-    exit 1
-}
-
-# If paths-only mode, output paths and exit (support combined -Json -PathsOnly)
-if ($PathsOnly) {
-    if ($Json) {
-        [PSCustomObject]@{
-            REPO_ROOT    = $paths.REPO_ROOT
-            BRANCH       = $paths.CURRENT_BRANCH
-            FEATURE_DIR  = $paths.FEATURE_DIR
-            FEATURE_SPEC = $paths.FEATURE_SPEC
-            IMPL_PLAN    = $paths.IMPL_PLAN
-            TASKS        = $paths.TASKS
-        } | ConvertTo-Json -Compress
-    } else {
-        Write-Output "REPO_ROOT: $($paths.REPO_ROOT)"
-        Write-Output "BRANCH: $($paths.CURRENT_BRANCH)"
-        Write-Output "FEATURE_DIR: $($paths.FEATURE_DIR)"
-        Write-Output "FEATURE_SPEC: $($paths.FEATURE_SPEC)"
-        Write-Output "IMPL_PLAN: $($paths.IMPL_PLAN)"
-        Write-Output "TASKS: $($paths.TASKS)"
-    }
-    exit 0
-}
-
-# Validate required directories and files
-if (-not (Test-Path $paths.FEATURE_DIR -PathType Container)) {
-    Write-Output "ERROR: Feature directory not found: $($paths.FEATURE_DIR)"
-    Write-Output 'Run /specify first to create the feature structure.'
-    exit 1
-}
-
-if (-not (Test-Path $paths.IMPL_PLAN -PathType Leaf)) {
-    Write-Output "ERROR: plan.md not found in $($paths.FEATURE_DIR)"
-    Write-Output 'Run /plan first to create the implementation plan.'
-    exit 1
-}
-
-# Check for tasks.md if required
-if ($RequireTasks -and -not (Test-Path $paths.TASKS -PathType Leaf)) {
-    Write-Output "ERROR: tasks.md not found in $($paths.FEATURE_DIR)"
-    Write-Output 'Run /tasks first to create the task list.'
-    exit 1
-}
-
-# Build list of available documents
-$docs = @()
-
-# Always check these optional docs
-if (Test-Path $paths.RESEARCH) { $docs += 'research.md' }
-if (Test-Path $paths.DATA_MODEL) { $docs += 'data-model.md' }
-
-# Check contracts directory (only if it exists and has files)
-if ((Test-Path $paths.CONTRACTS_DIR) -and (Get-ChildItem -Path $paths.CONTRACTS_DIR -ErrorAction SilentlyContinue | Select-Object -First 1)) {
-    $docs += 'contracts/'
-}
-
-if (Test-Path $paths.QUICKSTART) { $docs += 'quickstart.md' }
-
-# Include tasks.md if requested and it exists
-if ($IncludeTasks -and (Test-Path $paths.TASKS)) {
-    $docs += 'tasks.md'
-}
-
-# Output results
-if ($Json) {
-    # JSON output
-    [PSCustomObject]@{
-        FEATURE_DIR    = $paths.FEATURE_DIR
-        AVAILABLE_DOCS = $docs
-    } | ConvertTo-Json -Compress
-} else {
-    # Text output
-    Write-Output "FEATURE_DIR:$($paths.FEATURE_DIR)"
-    Write-Output 'AVAILABLE_DOCS:'
-
-    # Show status of each potential document
-    Test-FileExists -Path $paths.RESEARCH -Description 'research.md' | Out-Null
-    Test-FileExists -Path $paths.DATA_MODEL -Description 'data-model.md' | Out-Null
-    Test-DirHasFiles -Path $paths.CONTRACTS_DIR -Description 'contracts/' | Out-Null
-    Test-FileExists -Path $paths.QUICKSTART -Description 'quickstart.md' | Out-Null
-
-    if ($IncludeTasks) {
-        Test-FileExists -Path $paths.TASKS -Description 'tasks.md' | Out-Null
-    }
-}
diff --git a/.specify/scripts/powershell/common.ps1 b/.specify/scripts/powershell/common.ps1
deleted file mode 100644
index 029bd9a7..00000000
--- a/.specify/scripts/powershell/common.ps1
+++ /dev/null
@@ -1,507 +0,0 @@
-#!/usr/bin/env pwsh
-# Common PowerShell functions analogous to common.sh
-
-function Get-RepoRoot {
-    try {
-        $result = git rev-parse --show-toplevel 2>$null
-        if ($LASTEXITCODE -eq 0) {
-            return $result
-        }
-    } catch {
-        # Git command failed
-    }
-
-    # Fall back to script location for non-git repos
-    return (Resolve-Path (Join-Path $PSScriptRoot '../../..')).Path
-}
-
-function Get-CurrentBranch {
-    # First check if SPECIFY_FEATURE environment variable is set
-    if ($env:SPECIFY_FEATURE) {
-        return $env:SPECIFY_FEATURE
-    }
-
-    # Then check git if available
-    try {
-        $result = git rev-parse --abbrev-ref HEAD 2>$null
-        if ($LASTEXITCODE -eq 0) {
-            return $result
-        }
-    } catch {
-        # Git command failed
-    }
-
-    # For non-git repos, try to find the latest feature directory
-    $repoRoot = Get-RepoRoot
-    $specsDir = Join-Path $repoRoot 'specs'
-
-    if (Test-Path $specsDir) {
-        $latestFeature = ''
-        $highest = 0
-
-        Get-ChildItem -Path $specsDir -Directory | ForEach-Object {
-            if ($_.Name -match '^(\d{3})-') {
-                $num = [int]$matches[1]
-                if ($num -gt $highest) {
-                    $highest = $num
-                    $latestFeature = $_.Name
-                }
-            }
-        }
-
-        if ($latestFeature) {
-            return $latestFeature
-        }
-    }
-
-    # Final fallback
-    return 'main'
-}
-
-function Test-HasGit {
-    try {
-        git rev-parse --show-toplevel 2>$null | Out-Null
-        return ($LASTEXITCODE -eq 0)
-    } catch {
-        return $false
-    }
-}
-
-function Test-FeatureBranch {
-    param(
-        [string]$Branch,
-        [bool]$HasGit = $true
-    )
-
-    # For non-git repos, we can't enforce branch naming but still provide output
-    if (-not $HasGit) {
-        Write-Warning '[specify] Warning: Git repository not detected; skipped branch validation'
-        return $true
-    }
-
-    if ($Branch -notmatch '^[0-9]{3}-') {
-        Write-Output "ERROR: Not on a feature branch. Current branch: $Branch"
-        Write-Output 'Feature branches should be named like: 001-feature-name'
-        return $false
-    }
-    return $true
-}
-
-function Get-FeatureDir {
-    param([string]$RepoRoot, [string]$Branch)
-    Join-Path $RepoRoot "specs/$Branch"
-}
-
-function Get-FeaturePathsEnv {
-    $repoRoot = Get-RepoRoot
-    $currentBranch = Get-CurrentBranch
-    $hasGit = Test-HasGit
-    $featureDir = Get-FeatureDir -RepoRoot $repoRoot -Branch $currentBranch
-
-    [PSCustomObject]@{
-        REPO_ROOT      = $repoRoot
-        CURRENT_BRANCH = $currentBranch
-        HAS_GIT        = $hasGit
-        FEATURE_DIR    = $featureDir
-        FEATURE_SPEC   = Join-Path $featureDir 'spec.md'
-        IMPL_PLAN      = Join-Path $featureDir 'plan.md'
-        TASKS          = Join-Path $featureDir 'tasks.md'
-        RESEARCH       = Join-Path $featureDir 'research.md'
-        DATA_MODEL     = Join-Path $featureDir 'data-model.md'
-        QUICKSTART     = Join-Path $featureDir 'quickstart.md'
-        CONTRACTS_DIR  = Join-Path $featureDir 'contracts'
-    }
-}
-
-function Test-FileExists {
-    param([string]$Path, [string]$Description)
-    if (Test-Path -Path $Path -PathType Leaf) {
-        Write-Output "  ✓ $Description"
-        return $true
-    } else {
-        Write-Output "  ✗ $Description"
-        return $false
-    }
-}
-
-function Test-DirHasFiles {
-    param([string]$Path, [string]$Description)
-    if ((Test-Path -Path $Path -PathType Container) -and (Get-ChildItem -Path $Path -ErrorAction SilentlyContinue | Where-Object { -not $_.PSIsContainer } | Select-Object -First 1)) {
-        Write-Output "  ✓ $Description"
-        return $true
-    } else {
-        Write-Output "  ✗ $Description"
-        return $false
-    }
-}
-
-# Resolve repository root. Prefer git information when available, but fall back
-# to searching for repository markers so the workflow still functions in repositories that
-# were initialised with --no-git.
-function Find-RepositoryRoot {
-    param(
-        [string]$StartDir,
-        [string[]]$Markers = @('.git', '.specify')
-    )
-    $current = Resolve-Path $StartDir
-    while ($true) {
-        foreach ($marker in $Markers) {
-            if (Test-Path (Join-Path $current $marker)) {
-                return $current
-            }
-        }
-        $parent = Split-Path $current -Parent
-        if ($parent -eq $current) {
-            # Reached filesystem root without finding markers
-            return $null
-        }
-        $current = $parent
-    }
-}
-
-function Write-Info {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$Message
-    )
-    Write-Host "INFO: $Message"
-}
-
-function Write-Success {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$Message
-    )
-    Write-Host "$([char]0x2713) $Message"
-}
-
-function Write-WarningMsg {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$Message
-    )
-    Write-Warning $Message
-}
-
-function Write-Err {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$Message
-    )
-    Write-Host "ERROR: $Message" -ForegroundColor Red
-}
-
-function Validate-Environment {
-    if (-not $CURRENT_BRANCH) {
-        Write-Err 'Unable to determine current feature'
-        if ($HAS_GIT) { Write-Info "Make sure you're on a feature branch" } else { Write-Info 'Set SPECIFY_FEATURE environment variable or create a feature first' }
-        exit 1
-    }
-    if (-not (Test-Path $NEW_PLAN)) {
-        Write-Err "No plan.md found at $NEW_PLAN"
-        Write-Info 'Ensure you are working on a feature with a corresponding spec directory'
-        if (-not $HAS_GIT) { Write-Info 'Use: $env:SPECIFY_FEATURE=your-feature-name or create a new feature first' }
-        exit 1
-    }
-    if (-not (Test-Path $TEMPLATE_FILE)) {
-        Write-Err "Template file not found at $TEMPLATE_FILE"
-        Write-Info 'Run specify init to scaffold .specify/templates, or add agent-file-template.md there.'
-        exit 1
-    }
-}
-
-function Extract-PlanField {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$FieldPattern,
-        [Parameter(Mandatory = $true)]
-        [string]$PlanFile
-    )
-    if (-not (Test-Path $PlanFile)) { return '' }
-    # Lines like **Language/Version**: Python 3.12
-    $regex = "^\*\*$([Regex]::Escape($FieldPattern))\*\*: (.+)$"
-    Get-Content -LiteralPath $PlanFile -Encoding utf8 | ForEach-Object {
-        if ($_ -match $regex) {
-            $val = $Matches[1].Trim()
-            if ($val -notin @('NEEDS CLARIFICATION', 'N/A')) { return $val }
-        }
-    } | Select-Object -First 1
-}
-
-function Parse-PlanData {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$PlanFile
-    )
-    if (-not (Test-Path $PlanFile)) { Write-Err "Plan file not found: $PlanFile"; return $false }
-    Write-Info "Parsing plan data from $PlanFile"
-    $script:NEW_LANG = Extract-PlanField -FieldPattern 'Language/Version' -PlanFile $PlanFile
-    $script:NEW_FRAMEWORK = Extract-PlanField -FieldPattern 'Primary Dependencies' -PlanFile $PlanFile
-    $script:NEW_DB = Extract-PlanField -FieldPattern 'Storage' -PlanFile $PlanFile
-    $script:NEW_PROJECT_TYPE = Extract-PlanField -FieldPattern 'Project Type' -PlanFile $PlanFile
-
-    if ($NEW_LANG) { Write-Info "Found language: $NEW_LANG" } else { Write-WarningMsg 'No language information found in plan' }
-    if ($NEW_FRAMEWORK) { Write-Info "Found framework: $NEW_FRAMEWORK" }
-    if ($NEW_DB -and $NEW_DB -ne 'N/A') { Write-Info "Found database: $NEW_DB" }
-    if ($NEW_PROJECT_TYPE) { Write-Info "Found project type: $NEW_PROJECT_TYPE" }
-    return $true
-}
-
-function Format-TechnologyStack {
-    param(
-        [Parameter(Mandatory = $false)]
-        [string]$Lang,
-        [Parameter(Mandatory = $false)]
-        [string]$Framework
-    )
-    $parts = @()
-    if ($Lang -and $Lang -ne 'NEEDS CLARIFICATION') { $parts += $Lang }
-    if ($Framework -and $Framework -notin @('NEEDS CLARIFICATION', 'N/A')) { $parts += $Framework }
-    if (-not $parts) { return '' }
-    return ($parts -join ' + ')
-}
-
-function Get-ProjectStructure {
-    param(
-        [Parameter(Mandatory = $false)]
-        [string]$ProjectType
-    )
-    if ($ProjectType -match 'web') { return "backend/`nfrontend/`ntests/" } else { return "src/`ntests/" }
-}
-
-function Get-CommandsForLanguage {
-    param(
-        [Parameter(Mandatory = $false)]
-        [string]$Lang
-    )
-    switch -Regex ($Lang) {
-        'Python' { return 'cd src; pytest; ruff check .' }
-        'Rust' { return 'cargo test; cargo clippy' }
-        'JavaScript|TypeScript' { return 'npm test; npm run lint' }
-        default { return "# Add commands for $Lang" }
-    }
-}
-
-function Get-LanguageConventions {
-    param(
-        [Parameter(Mandatory = $false)]
-        [string]$Lang
-    )
-    if ($Lang) { "${Lang}: Follow standard conventions" } else { 'General: Follow standard conventions' }
-}
-
-function New-AgentFile {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$TargetFile,
-        [Parameter(Mandatory = $true)]
-        [string]$ProjectName,
-        [Parameter(Mandatory = $true)]
-        [datetime]$Date
-    )
-    if (-not (Test-Path $TEMPLATE_FILE)) { Write-Err "Template not found at $TEMPLATE_FILE"; return $false }
-    $temp = New-TemporaryFile
-    Copy-Item -LiteralPath $TEMPLATE_FILE -Destination $temp -Force
-
-    $projectStructure = Get-ProjectStructure -ProjectType $NEW_PROJECT_TYPE
-    $commands = Get-CommandsForLanguage -Lang $NEW_LANG
-    $languageConventions = Get-LanguageConventions -Lang $NEW_LANG
-
-    $escaped_lang = $NEW_LANG
-    $escaped_framework = $NEW_FRAMEWORK
-    $escaped_branch = $CURRENT_BRANCH
-
-    $content = Get-Content -LiteralPath $temp -Raw -Encoding utf8
-    $content = $content -replace '\[PROJECT NAME\]', $ProjectName
-    $content = $content -replace '\[DATE\]', $Date.ToString('yyyy-MM-dd')
-
-    # Build the technology stack string safely
-    $techStackForTemplate = ''
-    if ($escaped_lang -and $escaped_framework) {
-        $techStackForTemplate = "- $escaped_lang + $escaped_framework ($escaped_branch)"
-    } elseif ($escaped_lang) {
-        $techStackForTemplate = "- $escaped_lang ($escaped_branch)"
-    } elseif ($escaped_framework) {
-        $techStackForTemplate = "- $escaped_framework ($escaped_branch)"
-    }
-
-    $content = $content -replace '\[EXTRACTED FROM ALL PLAN.MD FILES\]', $techStackForTemplate
-    # For project structure we manually embed (keep newlines)
-    $escapedStructure = [Regex]::Escape($projectStructure)
-    $content = $content -replace '\[ACTUAL STRUCTURE FROM PLANS\]', $escapedStructure
-    # Replace escaped newlines placeholder after all replacements
-    $content = $content -replace '\[ONLY COMMANDS FOR ACTIVE TECHNOLOGIES\]', $commands
-    $content = $content -replace '\[LANGUAGE-SPECIFIC, ONLY FOR LANGUAGES IN USE\]', $languageConventions
-
-    # Build the recent changes string safely
-    $recentChangesForTemplate = ''
-    if ($escaped_lang -and $escaped_framework) {
-        $recentChangesForTemplate = "- ${escaped_branch}: Added ${escaped_lang} + ${escaped_framework}"
-    } elseif ($escaped_lang) {
-        $recentChangesForTemplate = "- ${escaped_branch}: Added ${escaped_lang}"
-    } elseif ($escaped_framework) {
-        $recentChangesForTemplate = "- ${escaped_branch}: Added ${escaped_framework}"
-    }
-
-    $content = $content -replace '\[LAST 3 FEATURES AND WHAT THEY ADDED\]', $recentChangesForTemplate
-    # Convert literal \n sequences introduced by Escape to real newlines
-    $content = $content -replace '\\n', [Environment]::NewLine
-
-    $parent = Split-Path -Parent $TargetFile
-    if (-not (Test-Path $parent)) { New-Item -ItemType Directory -Path $parent | Out-Null }
-    Set-Content -LiteralPath $TargetFile -Value $content -NoNewline -Encoding utf8
-    Remove-Item $temp -Force
-    return $true
-}
-
-function Update-ExistingAgentFile {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$TargetFile,
-        [Parameter(Mandatory = $true)]
-        [datetime]$Date
-    )
-    if (-not (Test-Path $TargetFile)) { return (New-AgentFile -TargetFile $TargetFile -ProjectName (Split-Path $REPO_ROOT -Leaf) -Date $Date) }
-
-    $techStack = Format-TechnologyStack -Lang $NEW_LANG -Framework $NEW_FRAMEWORK
-    $newTechEntries = @()
-    if ($techStack) {
-        $escapedTechStack = [Regex]::Escape($techStack)
-        if (-not (Select-String -Pattern $escapedTechStack -Path $TargetFile -Quiet)) {
-            $newTechEntries += "- $techStack ($CURRENT_BRANCH)"
-        }
-    }
-    if ($NEW_DB -and $NEW_DB -notin @('N/A', 'NEEDS CLARIFICATION')) {
-        $escapedDB = [Regex]::Escape($NEW_DB)
-        if (-not (Select-String -Pattern $escapedDB -Path $TargetFile -Quiet)) {
-            $newTechEntries += "- $NEW_DB ($CURRENT_BRANCH)"
-        }
-    }
-    $newChangeEntry = ''
-    if ($techStack) { $newChangeEntry = "- ${CURRENT_BRANCH}: Added ${techStack}" }
-    elseif ($NEW_DB -and $NEW_DB -notin @('N/A', 'NEEDS CLARIFICATION')) { $newChangeEntry = "- ${CURRENT_BRANCH}: Added ${NEW_DB}" }
-
-    $lines = Get-Content -LiteralPath $TargetFile -Encoding utf8
-    $output = New-Object System.Collections.Generic.List[string]
-    $inTech = $false; $inChanges = $false; $techAdded = $false; $changeAdded = $false; $existingChanges = 0
-
-    for ($i = 0; $i -lt $lines.Count; $i++) {
-        $line = $lines[$i]
-        if ($line -eq '## Active Technologies') {
-            $output.Add($line)
-            $inTech = $true
-            continue
-        }
-        if ($inTech -and $line -match '^##\s') {
-            if (-not $techAdded -and $newTechEntries.Count -gt 0) { $newTechEntries | ForEach-Object { $output.Add($_) }; $techAdded = $true }
-            $output.Add($line); $inTech = $false; continue
-        }
-        if ($inTech -and [string]::IsNullOrWhiteSpace($line)) {
-            if (-not $techAdded -and $newTechEntries.Count -gt 0) { $newTechEntries | ForEach-Object { $output.Add($_) }; $techAdded = $true }
-            $output.Add($line); continue
-        }
-        if ($line -eq '## Recent Changes') {
-            $output.Add($line)
-            if ($newChangeEntry) { $output.Add($newChangeEntry); $changeAdded = $true }
-            $inChanges = $true
-            continue
-        }
-        if ($inChanges -and $line -match '^##\s') { $output.Add($line); $inChanges = $false; continue }
-        if ($inChanges -and $line -match '^- ') {
-            if ($existingChanges -lt 2) { $output.Add($line); $existingChanges++ }
-            continue
-        }
-        if ($line -match '\*\*Last updated\*\*: .*\d{4}-\d{2}-\d{2}') {
-            $output.Add(($line -replace '\d{4}-\d{2}-\d{2}', $Date.ToString('yyyy-MM-dd')))
-            continue
-        }
-        $output.Add($line)
-    }
-
-    # Post-loop check: if we're still in the Active Technologies section and haven't added new entries
-    if ($inTech -and -not $techAdded -and $newTechEntries.Count -gt 0) {
-        $newTechEntries | ForEach-Object { $output.Add($_) }
-    }
-
-    Set-Content -LiteralPath $TargetFile -Value ($output -join [Environment]::NewLine) -Encoding utf8
-    return $true
-}
-
-function Update-AgentFile {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$TargetFile,
-        [Parameter(Mandatory = $true)]
-        [string]$AgentName
-    )
-    if (-not $TargetFile -or -not $AgentName) { Write-Err 'Update-AgentFile requires TargetFile and AgentName'; return $false }
-    Write-Info "Updating $AgentName context file: $TargetFile"
-    $projectName = Split-Path $REPO_ROOT -Leaf
-    $date = Get-Date
-
-    $dir = Split-Path -Parent $TargetFile
-    if (-not (Test-Path $dir)) { New-Item -ItemType Directory -Path $dir | Out-Null }
-
-    if (-not (Test-Path $TargetFile)) {
-        if (New-AgentFile -TargetFile $TargetFile -ProjectName $projectName -Date $date) { Write-Success "Created new $AgentName context file" } else { Write-Err 'Failed to create new agent file'; return $false }
-    } else {
-        try {
-            if (Update-ExistingAgentFile -TargetFile $TargetFile -Date $date) { Write-Success "Updated existing $AgentName context file" } else { Write-Err 'Failed to update agent file'; return $false }
-        } catch {
-            Write-Err "Cannot access or update existing file: $TargetFile. $_"
-            return $false
-        }
-    }
-    return $true
-}
-
-function Update-SpecificAgent {
-    param(
-        [Parameter(Mandatory = $true)]
-        [string]$Type
-    )
-    switch ($Type) {
-        'claude' { Update-AgentFile -TargetFile $CLAUDE_FILE -AgentName 'Claude Code' }
-        'gemini' { Update-AgentFile -TargetFile $GEMINI_FILE -AgentName 'Gemini CLI' }
-        'copilot' { Update-AgentFile -TargetFile $COPILOT_FILE -AgentName 'GitHub Copilot' }
-        'cursor' { Update-AgentFile -TargetFile $CURSOR_FILE -AgentName 'Cursor IDE' }
-        'qwen' { Update-AgentFile -TargetFile $QWEN_FILE -AgentName 'Qwen Code' }
-        'opencode' { Update-AgentFile -TargetFile $AGENTS_FILE -AgentName 'opencode' }
-        'codex' { Update-AgentFile -TargetFile $AGENTS_FILE -AgentName 'Codex CLI' }
-        'windsurf' { Update-AgentFile -TargetFile $WINDSURF_FILE -AgentName 'Windsurf' }
-        'kilocode' { Update-AgentFile -TargetFile $KILOCODE_FILE -AgentName 'Kilo Code' }
-        'auggie' { Update-AgentFile -TargetFile $AUGGIE_FILE -AgentName 'Auggie CLI' }
-        'roo' { Update-AgentFile -TargetFile $ROO_FILE -AgentName 'Roo Code' }
-        default { Write-Err "Unknown agent type '$Type'"; Write-Err 'Expected: claude|gemini|copilot|cursor|qwen|opencode|codex|windsurf|kilocode|auggie|roo'; return $false }
-    }
-}
-
-function Update-AllExistingAgents {
-    $found = $false
-    $ok = $true
-    if (Test-Path $CLAUDE_FILE) { if (-not (Update-AgentFile -TargetFile $CLAUDE_FILE -AgentName 'Claude Code')) { $ok = $false }; $found = $true }
-    if (Test-Path $GEMINI_FILE) { if (-not (Update-AgentFile -TargetFile $GEMINI_FILE -AgentName 'Gemini CLI')) { $ok = $false }; $found = $true }
-    if (Test-Path $COPILOT_FILE) { if (-not (Update-AgentFile -TargetFile $COPILOT_FILE -AgentName 'GitHub Copilot')) { $ok = $false }; $found = $true }
-    if (Test-Path $CURSOR_FILE) { if (-not (Update-AgentFile -TargetFile $CURSOR_FILE -AgentName 'Cursor IDE')) { $ok = $false }; $found = $true }
-    if (Test-Path $QWEN_FILE) { if (-not (Update-AgentFile -TargetFile $QWEN_FILE -AgentName 'Qwen Code')) { $ok = $false }; $found = $true }
-    if (Test-Path $AGENTS_FILE) { if (-not (Update-AgentFile -TargetFile $AGENTS_FILE -AgentName 'Codex/opencode')) { $ok = $false }; $found = $true }
-    if (Test-Path $WINDSURF_FILE) { if (-not (Update-AgentFile -TargetFile $WINDSURF_FILE -AgentName 'Windsurf')) { $ok = $false }; $found = $true }
-    if (Test-Path $KILOCODE_FILE) { if (-not (Update-AgentFile -TargetFile $KILOCODE_FILE -AgentName 'Kilo Code')) { $ok = $false }; $found = $true }
-    if (Test-Path $AUGGIE_FILE) { if (-not (Update-AgentFile -TargetFile $AUGGIE_FILE -AgentName 'Auggie CLI')) { $ok = $false }; $found = $true }
-    if (Test-Path $ROO_FILE) { if (-not (Update-AgentFile -TargetFile $ROO_FILE -AgentName 'Roo Code')) { $ok = $false }; $found = $true }
-    if (-not $found) {
-        Write-Info 'No existing agent files found, creating default Claude file...'
-        if (-not (Update-AgentFile -TargetFile $CLAUDE_FILE -AgentName 'Claude Code')) { $ok = $false }
-    }
-    return $ok
-}
-
-function Show-Summary {
-    Write-Host ''
-    Write-Info 'Summary of changes:'
-    if ($NEW_LANG) { Write-Host "  - Added language: $NEW_LANG" }
-    if ($NEW_FRAMEWORK) { Write-Host "  - Added framework: $NEW_FRAMEWORK" }
-    if ($NEW_DB -and $NEW_DB -ne 'N/A') { Write-Host "  - Added database: $NEW_DB" }
-    Write-Host ''
-    Write-Info 'Usage: ./update-agent-context.ps1 [-AgentType claude|gemini|copilot|cursor|qwen|opencode|codex|windsurf|kilocode|auggie|roo]'
-}
diff --git a/.specify/scripts/powershell/create-new-feature.ps1 b/.specify/scripts/powershell/create-new-feature.ps1
deleted file mode 100644
index c05032e3..00000000
--- a/.specify/scripts/powershell/create-new-feature.ps1
+++ /dev/null
@@ -1,157 +0,0 @@
-#!/usr/bin/env pwsh
-# Create a new feature
-[CmdletBinding()]
-param(
-    [switch]$Json,
-    [Parameter(ValueFromRemainingArguments = $true)]
-    [string[]]$FeatureDescription,
-    [Parameter()]
-    [string]$BranchName
-)
-$ErrorActionPreference = 'Stop'
-
-# Source common functions
-. "$PSScriptRoot/common.ps1"
-
-if (-not $FeatureDescription -or $FeatureDescription.Count -eq 0) {
-    Write-Error 'Usage: ./create-new-feature.ps1 [-Json] <feature description>'
-    exit 1
-}
-$featureDesc = ($FeatureDescription -join ' ').Trim()
-
-$fallbackRoot = (Find-RepositoryRoot -StartDir $PSScriptRoot)
-if (-not $fallbackRoot) {
-    Write-Error 'Error: Could not determine repository root. Please run this script from within the repository.'
-    exit 1
-}
-
-try {
-    $repoRoot = git rev-parse --show-toplevel 2>$null
-    if ($LASTEXITCODE -eq 0) {
-        $hasGit = $true
-    } else {
-        throw 'Git not available'
-    }
-} catch {
-    $repoRoot = $fallbackRoot
-    $hasGit = $false
-}
-
-Set-Location $repoRoot
-
-$specsDir = Join-Path $repoRoot 'specs'
-New-Item -ItemType Directory -Path $specsDir -Force | Out-Null
-
-$highest = 0
-if (Test-Path $specsDir) {
-    Get-ChildItem -Path $specsDir -Directory | ForEach-Object {
-        if ($_.Name -match '^(\d{3})') {
-            $num = [int]$matches[1]
-            if ($num -gt $highest) { $highest = $num }
-        }
-    }
-}
-$next = $highest + 1
-$featureNum = ('{0:000}' -f $next)
-
-# Determine if we should create a new branch or stay on the current one
-$shouldCreateBranch = $false
-$currentBranch = ''
-$isExistingFeature = $false
-
-if ($hasGit) {
-    try {
-        $currentBranch = git rev-parse --abbrev-ref HEAD 2>$null
-        if ($LASTEXITCODE -eq 0) {
-            # Create new branch only if we're on 'main' or a branch that doesn't start with 3 digits
-            if ($currentBranch -eq 'main' -or $currentBranch -notmatch '^\d{3}-') {
-                $shouldCreateBranch = $true
-            } else {
-                # We're on a feature branch, reuse it
-                $isExistingFeature = $true
-                $branchName = $currentBranch
-
-                # Extract feature number from existing branch
-                if ($branchName -match '^(\d{3})') {
-                    $featureNum = $matches[1]
-                }
-
-                Write-Verbose "Staying on existing feature branch: $branchName"
-            }
-        }
-    } catch {
-        Write-Warning 'Failed to get current branch name'
-        $shouldCreateBranch = $true
-    }
-}
-
-# Only generate new branch name if we need to create a new branch
-if ($shouldCreateBranch) {
-    # Use provided BranchName if available, otherwise generate from feature description
-    if ($BranchName) {
-        # Sanitize the provided branch name
-        $branchSuffix = $BranchName.ToLower() -replace '[^a-z0-9]', '-' -replace '-{2,}', '-' -replace '^-', '' -replace '-$', ''
-    } else {
-        # Fallback: Generate from feature description (first 3 words)
-        $branchSuffix = $featureDesc.ToLower() -replace '[^a-z0-9]', '-' -replace '-{2,}', '-' -replace '^-', '' -replace '-$', ''
-        $words = ($branchSuffix -split '-') | Where-Object { $_ } | Select-Object -First 3
-        $branchSuffix = [string]::Join('-', $words)
-    }
-
-    $branchName = "$featureNum-$branchSuffix"
-}
-
-if ($hasGit -and $shouldCreateBranch) {
-    try {
-        git checkout -b $branchName | Out-Null
-    } catch {
-        Write-Warning "Failed to create git branch: $branchName"
-    }
-} elseif (-not $hasGit) {
-    # If no git, still generate a branch name for directory structure
-    if ($BranchName) {
-        $branchSuffix = $BranchName.ToLower() -replace '[^a-z0-9]', '-' -replace '-{2,}', '-' -replace '^-', '' -replace '-$', ''
-    } else {
-        $branchSuffix = $featureDesc.ToLower() -replace '[^a-z0-9]', '-' -replace '-{2,}', '-' -replace '^-', '' -replace '-$', ''
-        $words = ($branchSuffix -split '-') | Where-Object { $_ } | Select-Object -First 3
-        $branchSuffix = [string]::Join('-', $words)
-    }
-    $branchName = "$featureNum-$branchSuffix"
-    Write-Warning "[specify] Warning: Git repository not detected; skipped branch creation for $branchName"
-}
-
-$featureDir = Join-Path $specsDir $branchName
-New-Item -ItemType Directory -Path $featureDir -Force | Out-Null
-
-$template = Join-Path $repoRoot '.specify/templates/spec-template.md'
-$specFile = Join-Path $featureDir 'spec.md'
-if (Test-Path $template) {
-    Copy-Item $template $specFile -Force
-} else {
-    New-Item -ItemType File -Path $specFile | Out-Null
-}
-
-# Set the SPECIFY_FEATURE environment variable for the current session
-$env:SPECIFY_FEATURE = $branchName
-
-if ($Json) {
-    $obj = [PSCustomObject]@{
-        BRANCH_NAME        = $branchName
-        SPEC_FILE          = $specFile
-        FEATURE_NUM        = $featureNum
-        HAS_GIT            = $hasGit
-        IS_EXISTING_BRANCH = $isExistingFeature
-        CURRENT_BRANCH     = $currentBranch
-    }
-    $obj | ConvertTo-Json -Compress
-} else {
-    Write-Output "BRANCH_NAME: $branchName"
-    Write-Output "SPEC_FILE: $specFile"
-    Write-Output "FEATURE_NUM: $featureNum"
-    Write-Output "HAS_GIT: $hasGit"
-    Write-Output "IS_EXISTING_BRANCH: $isExistingFeature"
-    if ($isExistingFeature) {
-        Write-Output "Reusing existing feature branch: $branchName"
-    }
-    Write-Output "SPECIFY_FEATURE environment variable set to: $branchName"
-}
diff --git a/.specify/scripts/powershell/setup-plan.ps1 b/.specify/scripts/powershell/setup-plan.ps1
deleted file mode 100644
index 5f2859b1..00000000
--- a/.specify/scripts/powershell/setup-plan.ps1
+++ /dev/null
@@ -1,61 +0,0 @@
-#!/usr/bin/env pwsh
-# Setup implementation plan for a feature
-
-[CmdletBinding()]
-param(
-    [switch]$Json,
-    [switch]$Help
-)
-
-$ErrorActionPreference = 'Stop'
-
-# Load common functions
-. "$PSScriptRoot/common.ps1"
-
-# Show help if requested
-if ($Help) {
-    Write-Output 'Usage: ./setup-plan.ps1 [-Json] [-Help]'
-    Write-Output '  -Json     Output results in JSON format'
-    Write-Output '  -Help     Show this help message'
-    exit 0
-}
-
-# Get all paths and variables from common functions
-$paths = Get-FeaturePathsEnv
-
-# Check if we're on a proper feature branch (only for git repos)
-if (-not (Test-FeatureBranch -Branch $paths.CURRENT_BRANCH -HasGit $paths.HAS_GIT)) {
-    exit 1
-}
-
-# Ensure the feature directory exists
-New-Item -ItemType Directory -Path $paths.FEATURE_DIR -Force | Out-Null
-
-# Copy plan template if it exists, otherwise note it or create empty file
-$template = Join-Path $paths.REPO_ROOT '.specify/templates/plan-template.md'
-if (Test-Path $template) {
-    Copy-Item $template $paths.IMPL_PLAN -Force
-    Write-Output "Copied plan template to $($paths.IMPL_PLAN)"
-} else {
-    Write-Warning "Plan template not found at $template"
-    # Create a basic plan file if template doesn't exist
-    New-Item -ItemType File -Path $paths.IMPL_PLAN -Force | Out-Null
-}
-
-# Output results
-if ($Json) {
-    $result = [PSCustomObject]@{
-        FEATURE_SPEC = $paths.FEATURE_SPEC
-        IMPL_PLAN    = $paths.IMPL_PLAN
-        SPECS_DIR    = $paths.FEATURE_DIR
-        BRANCH       = $paths.CURRENT_BRANCH
-        HAS_GIT      = $paths.HAS_GIT
-    }
-    $result | ConvertTo-Json -Compress
-} else {
-    Write-Output "FEATURE_SPEC: $($paths.FEATURE_SPEC)"
-    Write-Output "IMPL_PLAN: $($paths.IMPL_PLAN)"
-    Write-Output "SPECS_DIR: $($paths.FEATURE_DIR)"
-    Write-Output "BRANCH: $($paths.CURRENT_BRANCH)"
-    Write-Output "HAS_GIT: $($paths.HAS_GIT)"
-}
diff --git a/.specify/scripts/powershell/update-agent-context.ps1 b/.specify/scripts/powershell/update-agent-context.ps1
deleted file mode 100644
index 73a662c4..00000000
--- a/.specify/scripts/powershell/update-agent-context.ps1
+++ /dev/null
@@ -1,77 +0,0 @@
-#!/usr/bin/env pwsh
-<#!
-.SYNOPSIS
-Update agent context files with information from plan.md (PowerShell version)
-
-.DESCRIPTION
-Mirrors the behavior of scripts/bash/update-agent-context.sh:
- 1. Environment Validation
- 2. Plan Data Extraction
- 3. Agent File Management (create from template or update existing)
- 4. Content Generation (technology stack, recent changes, timestamp)
- 5. Multi-Agent Support (claude, gemini, copilot, cursor, qwen, opencode, codex, windsurf)
-
-.PARAMETER AgentType
-Optional agent key to update a single agent. If omitted, updates all existing agent files (creating a default Claude file if none exist).
-
-.EXAMPLE
-./update-agent-context.ps1 -AgentType claude
-
-.EXAMPLE
-./update-agent-context.ps1   # Updates all existing agent files
-
-.NOTES
-Relies on common helper functions in common.ps1
-#>
-param(
-    [Parameter(Position = 0)]
-    [ValidateSet('claude', 'gemini', 'copilot', 'cursor', 'qwen', 'opencode', 'codex', 'windsurf', 'kilocode', 'auggie', 'roo')]
-    [string]$AgentType
-)
-
-$ErrorActionPreference = 'Stop'
-
-# Import common helpers
-. "$PSScriptRoot/common.ps1"
-
-# Acquire environment paths
-$envData = Get-FeaturePathsEnv
-$REPO_ROOT = $envData.REPO_ROOT
-$CURRENT_BRANCH = $envData.CURRENT_BRANCH
-$HAS_GIT = $envData.HAS_GIT
-$IMPL_PLAN = $envData.IMPL_PLAN
-$NEW_PLAN = $IMPL_PLAN
-
-# Agent file paths
-$CLAUDE_FILE = Join-Path $REPO_ROOT 'CLAUDE.md'
-$GEMINI_FILE = Join-Path $REPO_ROOT 'GEMINI.md'
-$COPILOT_FILE = Join-Path $REPO_ROOT '.github/copilot-instructions.md'
-$CURSOR_FILE = Join-Path $REPO_ROOT '.cursor/rules/specify-rules.mdc'
-$QWEN_FILE = Join-Path $REPO_ROOT 'QWEN.md'
-$AGENTS_FILE = Join-Path $REPO_ROOT 'AGENTS.md'
-$WINDSURF_FILE = Join-Path $REPO_ROOT '.windsurf/rules/specify-rules.md'
-$KILOCODE_FILE = Join-Path $REPO_ROOT '.kilocode/rules/specify-rules.md'
-$AUGGIE_FILE = Join-Path $REPO_ROOT '.augment/rules/specify-rules.md'
-$ROO_FILE = Join-Path $REPO_ROOT '.roo/rules/specify-rules.md'
-
-$TEMPLATE_FILE = Join-Path $REPO_ROOT '.specify/templates/agent-file-template.md'
-
-# Parsed plan data placeholders
-$script:NEW_LANG = ''
-$script:NEW_FRAMEWORK = ''
-$script:NEW_DB = ''
-$script:NEW_PROJECT_TYPE = ''
-
-Validate-Environment
-Write-Info "=== Updating agent context files for feature $CURRENT_BRANCH ==="
-if (-not (Parse-PlanData -PlanFile $NEW_PLAN)) { Write-Err 'Failed to parse plan data'; exit 1 }
-$success = $true
-if ($AgentType) {
-    Write-Info "Updating specific agent: $AgentType"
-    if (-not (Update-SpecificAgent -Type $AgentType)) { $success = $false }
-} else {
-    Write-Info 'No agent specified, updating all existing agent files...'
-    if (-not (Update-AllExistingAgents)) { $success = $false }
-}
-Show-Summary
-if ($success) { Write-Success 'Agent context update completed successfully'; exit 0 } else { Write-Err 'Agent context update completed with errors'; exit 1 }
diff --git a/.specify/templates/agent-file-template.md b/.specify/templates/agent-file-template.md
deleted file mode 100644
index c99594e8..00000000
--- a/.specify/templates/agent-file-template.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# [PROJECT NAME] Development Guidelines
-
-Auto-generated from all feature plans. Last updated: [DATE]
-
-## Active Technologies
-
-[EXTRACTED FROM ALL PLAN.MD FILES]
-
-## Project Structure
-
-```plaintext
-[ACTUAL STRUCTURE FROM PLANS]
-```
-
-## Commands
-[ONLY COMMANDS FOR ACTIVE TECHNOLOGIES]
-
-## Code Style
-[LANGUAGE-SPECIFIC, ONLY FOR LANGUAGES IN USE]
-
-## Recent Changes
-[LAST 3 FEATURES AND WHAT THEY ADDED]
-
-<!-- MANUAL ADDITIONS START -->
-<!-- MANUAL ADDITIONS END -->
diff --git a/.specify/templates/constitution-template.md b/.specify/templates/constitution-template.md
deleted file mode 100644
index 1ed8d77a..00000000
--- a/.specify/templates/constitution-template.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# [PROJECT_NAME] Constitution
-<!-- Example: Spec Constitution, TaskFlow Constitution, etc. -->
-
-## Core Principles
-
-### [PRINCIPLE_1_NAME]
-<!-- Example: I. Library-First -->
-[PRINCIPLE_1_DESCRIPTION]
-<!-- Example: Every feature starts as a standalone library; Libraries must be self-contained, independently testable, documented; Clear purpose required - no organizational-only libraries -->
-
-### [PRINCIPLE_2_NAME]
-<!-- Example: II. CLI Interface -->
-[PRINCIPLE_2_DESCRIPTION]
-<!-- Example: Every library exposes functionality via CLI; Text in/out protocol: stdin/args → stdout, errors → stderr; Support JSON + human-readable formats -->
-
-### [PRINCIPLE_3_NAME]
-<!-- Example: III. Test-First (NON-NEGOTIABLE) -->
-[PRINCIPLE_3_DESCRIPTION]
-<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced -->
-
-### [PRINCIPLE_4_NAME]
-<!-- Example: IV. Integration Testing -->
-[PRINCIPLE_4_DESCRIPTION]
-<!-- Example: Focus areas requiring integration tests: New library contract tests, Contract changes, Inter-service communication, Shared schemas -->
-
-### [PRINCIPLE_5_NAME]
-<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Simplicity -->
-[PRINCIPLE_5_DESCRIPTION]
-<!-- Example: Text I/O ensures debuggability; Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: Start simple, YAGNI principles -->
-
-## [SECTION_2_NAME]
-<!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. -->
-
-[SECTION_2_CONTENT]
-<!-- Example: Technology stack requirements, compliance standards, deployment policies, etc. -->
-
-## [SECTION_3_NAME]
-<!-- Example: Development Workflow, Review Process, Quality Gates, etc. -->
-
-[SECTION_3_CONTENT]
-<!-- Example: Code review requirements, testing gates, deployment approval process, etc. -->
-
-## Governance
-<!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan -->
-
-[GOVERNANCE_RULES]
-<!-- Example: All PRs/reviews must verify compliance; Complexity must be justified; Use [GUIDANCE_FILE] for runtime development guidance -->
-
-**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]
-<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 -->
\ No newline at end of file
diff --git a/.specify/templates/plan-template.md b/.specify/templates/plan-template.md
deleted file mode 100644
index 8fa54670..00000000
--- a/.specify/templates/plan-template.md
+++ /dev/null
@@ -1,272 +0,0 @@
-# Implementation Plan: [FEATURE]
-
-**Branch**: `[###-feature-name]` | **Date**: [DATE] | **Spec**: [link]
-**Input**: Feature specification from `/specs/[###-feature-name]/spec.md`
-
-## Execution Flow (/plan command scope)
-
-1. Load feature spec from Input path
-   → If not found: ERROR "No feature spec at {path}"
-2. Fill Technical Context (scan for NEEDS CLARIFICATION)
-   → Detect Project Type from file system structure or context (web=frontend+backend, mobile=app+API)
-   → Set Structure Decision based on project type
-3. Fill the Constitution Check section based on the content of the main README.
-4. Evaluate Constitution Check section below
-   → If violations exist: Document them in Complexity Tracking
-   → If no justification is possible: ERROR "Simplify approach first"
-   → Update Progress Tracking: Initial Constitution Check
-5. Execute Phase 0 → research.md
-   → If NEEDS CLARIFICATION remain: ERROR "Resolve unknowns"
-6. Execute Phase 1 → contracts, data-model.md, quickstart.md, agent-specific template file (e.g., `CLAUDE.md` for Claude Code, `.github/copilot-instructions.md` for GitHub Copilot, `GEMINI.md` for Gemini CLI, `QWEN.md` for Qwen Code or `AGENTS.md` for opencode).
-7. Re-evaluate Constitution Check section
-   → If new violations: Refactor design, return to Phase 1
-   → Update Progress Tracking: Post-Design Constitution Check
-8. Plan Phase 2 → Describe task generation approach (DO NOT create tasks.md)
-9. STOP - Ready for /tasks command
-
-**IMPORTANT**: The /plan command STOPS at step 7. Phases 2-4 are executed by other commands:
-
-- Phase 2: /tasks command creates tasks.md
-- Phase 3-4: Implementation execution (manual or via tools)
-
-## Summary
-
-[Extract from feature spec: primary requirement + technical approach from research]
-
-## Technical Context
-
-| Aspect                   | Details                                                                                    |
-| ------------------------ | ------------------------------------------------------------------------------------------ |
-| **Language/Version**     | [e.g., Python 3.11, Swift 5.9, Rust 1.75 or NEEDS CLARIFICATION]                           |
-| **Primary Dependencies** | [e.g., FastAPI, UIKit, LLVM or NEEDS CLARIFICATION]                                        |
-| **Storage**              | [if applicable, e.g., PostgreSQL, CoreData, files or N/A]                                  |
-| **Testing**              | [e.g., pytest, XCTest, cargo test or NEEDS CLARIFICATION]                                  |
-| **Target Platform**      | [e.g., Linux server, iOS 15+, Wasm or NEEDS CLARIFICATION]                                 |
-| **Project Type**         | [single/web/mobile - determines source structure]                                          |
-| **Performance Goals**    | [domain-specific, e.g., 1000 req/s, 10k lines/sec, 60 fps or NEEDS CLARIFICATION]          |
-| **Constraints**          | [domain-specific, e.g., <200ms p95, <100MB memory, offline-capable or NEEDS CLARIFICATION] |
-| **Scale/Scope**          | [domain-specific, e.g., 10k users, 1M LOC, 50 screens or NEEDS CLARIFICATION]              |
-
-## Constitution Check
-
-*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
-
-### I. Workflow-First Design (NON-NEGOTIABLE)
-
-- [ ] Feature is implemented as reusable GitHub Actions workflow(s)
-- [ ] Workflows have clearly defined inputs and outputs
-- [ ] Workflows follow single responsibility principle
-- [ ] Matrix strategies used for parallel execution where appropriate
-- [ ] Workflows are independently testable via CI validation workflow
-- [ ] Logic delegated to reusable GitHub Actions (PSModule organization)
-- [ ] Inline PowerShell code avoided; action-based scripts used instead
-- [ ] Actions referenced by specific versions/tags
-
-### II. Test-Driven Development (NON-NEGOTIABLE)
-
-- [ ] Tests will be written before implementation
-- [ ] Initial tests will fail (Red phase documented)
-- [ ] Implementation plan includes making tests pass (Green phase)
-- [ ] Refactoring phase planned while maintaining tests
-- [ ] PSScriptAnalyzer validation included
-- [ ] Manual testing documented if needed
-- [ ] CI validation workflow tests included
-
-### III. Platform Independence with Modern PowerShell
-
-- [ ] PowerShell 7.4+ constructs used exclusively
-- [ ] Matrix testing across Linux, macOS, Windows included
-- [ ] Platform-specific behaviors documented
-- [ ] Skip mechanisms justified if platform-specific tests needed
-- [ ] No backward compatibility with PowerShell 5.1 required
-
-### IV. Quality Gates and Observability
-
-- [ ] Test results captured in structured JSON format
-- [ ] Code coverage measurement included
-- [ ] Linting results captured and enforced
-- [ ] Quality gate thresholds defined
-- [ ] Clear error messages planned
-- [ ] Debug mode support included
-
-### V. Continuous Delivery with Semantic Versioning
-
-- [ ] Version bump strategy documented (labels, SemVer)
-- [ ] Release automation compatible with existing workflow
-- [ ] Documentation updates included
-- [ ] GitHub Pages publishing considered if docs changes
-
-## Project Structure
-
-### Documentation (this feature)
-
-```plaintext
-specs/[###-feature]/
-├── plan.md              # This file (/plan command output)
-├── research.md          # Phase 0 output (/plan command)
-├── data-model.md        # Phase 1 output (/plan command)
-├── quickstart.md        # Phase 1 output (/plan command)
-├── contracts/           # Phase 1 output (/plan command)
-└── tasks.md             # Phase 2 output (/tasks command - NOT created by /plan)
-```
-
-### Source Code (repository root)
-
-<!--
-  ACTION REQUIRED: Replace the placeholder tree below with the concrete layout
-  for this feature. Delete unused options and expand the chosen structure with
-  real paths (e.g., apps/admin, packages/something). The delivered plan must
-  not include Option labels.
--->
-
-```plaintext
-# [REMOVE IF UNUSED] Option 1: Single project (DEFAULT)
-src/
-├── models/
-├── services/
-├── cli/
-└── lib/
-
-tests/
-├── contract/
-├── integration/
-└── unit/
-
-# [REMOVE IF UNUSED] Option 2: Web application (when "frontend" + "backend" detected)
-backend/
-├── src/
-│   ├── models/
-│   ├── services/
-│   └── api/
-└── tests/
-
-frontend/
-├── src/
-│   ├── components/
-│   ├── pages/
-│   └── services/
-└── tests/
-
-# [REMOVE IF UNUSED] Option 3: Mobile + API (when "iOS/Android" detected)
-api/
-└── [same as backend above]
-
-ios/ or android/
-└── [platform-specific structure: feature modules, UI flows, platform tests]
-```
-
-**Structure Decision**: [Document the selected structure and reference the real
-directories captured above]
-
-## Phase 0: Outline & Research
-
-1. **Extract unknowns from Technical Context** above:
-   - For each NEEDS CLARIFICATION → research task
-   - For each dependency → best practices task
-   - For each integration → patterns task
-2. **Generate and dispatch research agents**:
-   ```plaintext
-   For each unknown in Technical Context:
-     Task: "Research {unknown} for {feature context}"
-   For each technology choice:
-     Task: "Find best practices for {tech} in {domain}"
-   ```
-3. **Consolidate findings** in `research.md` using format:
-   - Decision: [what was chosen]
-   - Rationale: [why chosen]
-   - Alternatives considered: [what else evaluated]
-
-**Output**: research.md with all NEEDS CLARIFICATION resolved
-
-## Phase 1: Design & Contracts
-
-*Prerequisites: research.md complete*
-
-1. **Extract entities from feature spec** → `data-model.md`:
-   - Entity name, fields, relationships
-   - Validation rules from requirements
-   - State transitions if applicable
-2. **Generate API contracts** from functional requirements:
-   - For each user action → endpoint
-   - Use standard REST/GraphQL patterns
-   - Output OpenAPI/GraphQL schema to `/contracts/`
-3. **Generate contract tests** from contracts:
-   - One test file per endpoint
-   - Assert request/response schemas
-   - Tests must fail (no implementation yet)
-4. **Extract test scenarios** from user stories:
-   - Each story → integration test scenario
-   - Quickstart test = story validation steps
-5. **Update agent file incrementally** (O(1) operation):
-   - Run `.specify/scripts/powershell/update-agent-context.ps1 -AgentType copilot`
-     **IMPORTANT**: Execute it exactly as specified above. Do not add or remove any arguments.
-   - If exists: Add only NEW tech from current plan
-   - Preserve manual additions between markers
-   - Update recent changes (keep last 3)
-   - Keep under 150 lines for token efficiency
-   - Output to repository root
-
-**Output**: data-model.md, /contracts/*, failing tests, quickstart.md, agent-specific file
-
-## Phase 2: Task Planning Approach
-
-*This section describes what the /tasks command will do - DO NOT execute during /plan*
-
-**Task Generation Strategy**:
-
-- Load `.specify/templates/tasks-template.md` as base
-- Generate tasks from Phase 1 design docs (contracts, data model, quickstart)
-- Each contract → contract test task [P]
-- Each entity → model creation task [P]
-- Each user story → integration test task
-- Implementation tasks to make tests pass
-
-**Ordering Strategy**:
-
-- TDD order: Tests before implementation
-- Dependency order: Models before services before UI
-- Mark [P] for parallel execution (independent files)
-
-**Estimated Output**: 25-30 numbered, ordered tasks in tasks.md
-
-**IMPORTANT**: This phase is executed by the /tasks command, NOT by /plan
-
-## Phase 3+: Future Implementation
-
-*These phases are beyond the scope of the /plan command*
-
-**Phase 3**: Task execution (/tasks command creates tasks.md)
-**Phase 4**: Implementation (execute tasks.md following constitutional principles)
-**Phase 5**: Validation (run tests, execute quickstart.md, performance validation)
-
-## Complexity Tracking
-
-*Fill ONLY if Constitution Check has violations that must be justified*
-
-| Violation                  | Why Needed         | Simpler Alternative Rejected Because |
-| -------------------------- | ------------------ | ------------------------------------ |
-| [e.g., 4th project]        | [current need]     | [why 3 projects insufficient]        |
-| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient]  |
-
-## Progress Tracking
-
-*This checklist is updated during execution flow*
-
-**Phase Status**:
-
-- [ ] Phase 0: Research complete (/plan command)
-- [ ] Phase 1: Design complete (/plan command)
-- [ ] Phase 2: Task planning complete (/plan command - describe approach only)
-- [ ] Phase 3: Tasks generated (/tasks command)
-- [ ] Phase 4: Implementation complete
-- [ ] Phase 5: Validation passed
-
-**Gate Status**:
-
-- [ ] Initial Constitution Check: PASS
-- [ ] Post-Design Constitution Check: PASS
-- [ ] All NEEDS CLARIFICATION resolved
-- [ ] Complexity deviations documented
-
----
-*Based on Constitution - See `README.md` Principles and Architecture section*
diff --git a/.specify/templates/spec-template.md b/.specify/templates/spec-template.md
deleted file mode 100644
index 600e8d0b..00000000
--- a/.specify/templates/spec-template.md
+++ /dev/null
@@ -1,161 +0,0 @@
-# Feature Specification: [FEATURE NAME]
-
-## User Scenarios & Testing *(mandatory)*
-
-### Primary User Story
-
-[Describe the main user journey in plain language]
-
-### Acceptance Scenarios
-
-1. **Given** [initial state], **When** [action], **Then** [expected outcome]
-2. **Given** [initial state], **When** [action], **Then** [expected outcome]
-
-### Edge Cases
-
-- What happens when [boundary condition]?
-- How does system handle [error scenario]?
-
-## Requirements *(mandatory)*
-
-### Functional Requirements
-
-| ID         | Requirement                                                                                                       |
-| ---------- | ----------------------------------------------------------------------------------------------------------------- |
-| **FR-001** | System MUST [specific capability, e.g., "allow users to create accounts"]                                         |
-| **FR-002** | System MUST [specific capability, e.g., "validate email addresses"]                                               |
-| **FR-003** | Users MUST be able to [key interaction, e.g., "reset their password"]                                             |
-| **FR-004** | System MUST [data requirement, e.g., "persist user preferences"]                                                  |
-| **FR-005** | System MUST [behavior, e.g., "log all security events"]                                                           |
-| **FR-006** | System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?] |
-| **FR-007** | System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]                            |
-
-### Non-Functional Requirements
-
-| ID          | Requirement                                                                                                  |
-| ----------- | ------------------------------------------------------------------------------------------------------------ |
-| **NFR-001** | System MUST respond within [specific time, e.g., "500ms for 95th percentile"]                                |
-| **NFR-002** | System MUST handle [specific load, e.g., "1000 concurrent users"]                                            |
-| **NFR-003** | System MUST maintain [availability target, e.g., "99.9% uptime"]                                             |
-| **NFR-004** | System MUST scale to [capacity limit, e.g., "10,000 transactions per second"]                                |
-| **NFR-005** | System MUST recover within [time period, e.g., "5 minutes after failure"]                                    |
-| **NFR-006** | System MUST encrypt data [NEEDS CLARIFICATION: encryption scope not specified - at rest, in transit, both?] |
-| **NFR-007** | System MUST maintain audit logs for [NEEDS CLARIFICATION: retention period not specified]                    |
-
-### Quality Attributes Addressed
-
-| Attribute           | Target Metric                                                             |
-| ------------------- | ------------------------------------------------------------------------- |
-| **Performance**     | [e.g., "Response time < 200ms", "Throughput > 5000 TPS"]                  |
-| **Scalability**     | [e.g., "Support 100,000 concurrent users", "Linear scaling to 10 nodes"] |
-| **Availability**    | [e.g., "99.95% uptime", "Max 4 hours downtime per year"]                  |
-| **Reliability**     | [e.g., "MTBF > 720 hours", "Error rate < 0.01%"]                          |
-| **Security**        | [e.g., "OWASP Top 10 compliant", "SOC 2 Type II certified"]               |
-| **Maintainability** | [e.g., "Code coverage > 80%", "Cyclomatic complexity < 10"]               |
-| **Usability**       | [e.g., "Task completion time < 2 minutes", "User satisfaction > 4.5/5"]   |
-
-### Constraints *(include if applicable)*
-
-| Constraint         | Description                                                           |
-| ------------------ | --------------------------------------------------------------------- |
-| **[Constraint 1]** | [Limitation or restriction, e.g., "Must run on Windows Server 2019+"] |
-| **[Constraint 2]** | [Compliance requirement, e.g., "Must comply with GDPR"]               |
-
-### Key Entities *(include if feature involves data)*
-
-| Entity         | Description                                                 |
-| -------------- | ----------------------------------------------------------- |
-| **[Entity 1]** | [What it represents, key attributes without implementation] |
-| **[Entity 2]** | [What it represents, relationships to other entities]       |
-
----
-
-**Feature Branch**: `[###-feature-name]`
-**Created**: [DATE]
-**Status**: Draft
-**Input**: User description: "$ARGUMENTS"
-
-## Execution Flow (main)
-
-1. Parse user description from Input
-   → If empty: ERROR "No feature description provided"
-2. Extract key concepts from description
-   → Identify: actors, actions, data, constraints
-3. For each unclear aspect:
-   → Mark with [NEEDS CLARIFICATION: specific question]
-4. Fill User Scenarios & Testing section
-   → If no clear user flow: ERROR "Cannot determine user scenarios"
-5. Generate Functional Requirements
-   → Each requirement must be testable
-   → Mark ambiguous requirements
-6. Identify Key Entities (if data is involved)
-7. Run Review Checklist
-   → If any [NEEDS CLARIFICATION]: WARN "Spec has uncertainties"
-   → If implementation details found: ERROR "Remove tech details"
-8. Return: SUCCESS (spec ready for planning)
-
----
-
-## ⚡ Quick Guidelines
-
-- ✅ Focus on WHAT users need and WHY
-- ❌ Avoid HOW to implement (no tech stack, APIs, code structure)
-- 👥 Written for business stakeholders, not developers
-
-### Section Requirements
-
-- **Mandatory sections**: Must be completed for every feature
-- **Optional sections**: Include only when relevant to the feature
-- When a section doesn't apply, remove it entirely (don't leave as "N/A")
-
-### For AI Generation
-
-When creating this spec from a user prompt:
-
-1. **Mark all ambiguities**: Use [NEEDS CLARIFICATION: specific question] for any assumption you'd need to make
-2. **Don't guess**: If the prompt doesn't specify something (e.g., "login system" without auth method), mark it
-3. **Think like a tester**: Every vague requirement should fail the "testable and unambiguous" checklist item
-4. **Common underspecified areas**:
-   - User types and permissions
-   - Data retention/deletion policies
-   - Performance targets and scale
-   - Error handling behaviors
-   - Integration requirements
-   - Security/compliance needs
-
----
-
-## Review & Acceptance Checklist
-
-*GATE: Automated checks run during main() execution*
-
-### Content Quality
-
-- [ ] No implementation details (languages, frameworks, APIs)
-- [ ] Focused on user value and business needs
-- [ ] Written for non-technical stakeholders
-- [ ] All mandatory sections completed
-
-### Requirement Completeness
-
-- [ ] No [NEEDS CLARIFICATION] markers remain
-- [ ] Requirements are testable and unambiguous
-- [ ] Success criteria are measurable
-- [ ] Scope is clearly bounded
-- [ ] Dependencies and assumptions identified
-
----
-
-## Execution Status
-
-*Updated by main() during processing*
-
-- [ ] User description parsed
-- [ ] Key concepts extracted
-- [ ] Ambiguities marked
-- [ ] User scenarios defined
-- [ ] Requirements generated
-- [ ] Entities identified
-- [ ] Review checklist passed
-
----
diff --git a/.specify/templates/tasks-template.md b/.specify/templates/tasks-template.md
deleted file mode 100644
index 0f7cf2dd..00000000
--- a/.specify/templates/tasks-template.md
+++ /dev/null
@@ -1,135 +0,0 @@
-# Tasks: [FEATURE NAME]
-
-**Input**: Design documents from `/specs/[###-feature-name]/`
-**Prerequisites**: plan.md (required), research.md, data-model.md, contracts/
-
-## Execution Flow (main)
-
-1. Load plan.md from feature directory
-   → If not found: ERROR "No implementation plan found"
-   → Extract: tech stack, libraries, structure
-2. Load optional design documents:
-   → data-model.md: Extract entities → model tasks
-   → contracts/: Each file → contract test task
-   → research.md: Extract decisions → setup tasks
-3. Generate tasks by category:
-   → Setup: project init, dependencies, linting
-   → Tests: contract tests, integration tests
-   → Core: models, services, CLI commands
-   → Integration: DB, middleware, logging
-   → Polish: unit tests, performance, docs
-4. Apply task rules:
-   → Different files = mark [P] for parallel
-   → Same file = sequential (no [P])
-   → Tests before implementation (TDD)
-5. Number tasks sequentially (T001, T002...)
-6. Generate dependency graph
-7. Create parallel execution examples
-8. Validate task completeness:
-   → All contracts have tests?
-   → All entities have models?
-   → All endpoints implemented?
-9. Return: SUCCESS (tasks ready for execution)
-
-## Format: `[ID] [P?] Description`
-
-- **[P]**: Can run in parallel (different files, no dependencies)
-- Include exact file paths in descriptions
-
-## Path Conventions
-
-- **Single project**: `src/`, `tests/` at repository root
-- **Web app**: `backend/src/`, `frontend/src/`
-- **Mobile**: `api/src/`, `ios/src/` or `android/src/`
-- Paths shown below assume single project - adjust based on plan.md structure
-
-## Phase 3.1: Setup
-
-- [ ] T001 Create project structure per implementation plan
-- [ ] T002 Initialize [language] project with [framework] dependencies
-- [ ] T003 [P] Configure linting and formatting tools
-
-## Phase 3.2: Tests First (TDD) ⚠️ MUST COMPLETE BEFORE 3.3
-
-**CRITICAL: These tests MUST be written and MUST FAIL before ANY implementation**
-- [ ] T004 [P] Contract test POST /api/users in tests/contract/test_users_post.py
-- [ ] T005 [P] Contract test GET /api/users/{id} in tests/contract/test_users_get.py
-- [ ] T006 [P] Integration test user registration in tests/integration/test_registration.py
-- [ ] T007 [P] Integration test auth flow in tests/integration/test_auth.py
-
-## Phase 3.3: Core Implementation (ONLY after tests are failing)
-
-- [ ] T008 [P] User model in src/models/user.py
-- [ ] T009 [P] UserService CRUD in src/services/user_service.py
-- [ ] T010 [P] CLI --create-user in src/cli/user_commands.py
-- [ ] T011 POST /api/users endpoint
-- [ ] T012 GET /api/users/{id} endpoint
-- [ ] T013 Input validation
-- [ ] T014 Error handling and logging
-
-## Phase 3.4: Integration
-
-- [ ] T015 Connect UserService to DB
-- [ ] T016 Auth middleware
-- [ ] T017 Request/response logging
-- [ ] T018 CORS and security headers
-
-## Phase 3.5: Polish
-
-- [ ] T019 [P] Unit tests for validation in tests/unit/test_validation.py
-- [ ] T020 Performance tests (<200ms)
-- [ ] T021 [P] Update docs/api.md
-- [ ] T022 Remove duplication
-- [ ] T023 Run manual-testing.md
-
-## Dependencies
-
-- Tests (T004-T007) before implementation (T008-T014)
-- T008 blocks T009, T015
-- T016 blocks T018
-- Implementation before polish (T019-T023)
-
-## Parallel Example
-
-```plaintext
-# Launch T004-T007 together:
-Task: "Contract test POST /api/users in tests/contract/test_users_post.py"
-Task: "Contract test GET /api/users/{id} in tests/contract/test_users_get.py"
-Task: "Integration test registration in tests/integration/test_registration.py"
-Task: "Integration test auth in tests/integration/test_auth.py"
-```
-
-## Notes
-
-- [P] tasks = different files, no dependencies
-- Verify tests fail before implementing
-- Commit after each task
-- Avoid: vague tasks, same file conflicts
-
-## Task Generation Rules
-
-*Applied during main() execution*
-
-1. **From Contracts**:
-   - Each contract file → contract test task [P]
-   - Each endpoint → implementation task
-2. **From Data Model**:
-   - Each entity → model creation task [P]
-   - Relationships → service layer tasks
-3. **From User Stories**:
-   - Each story → integration test [P]
-   - Quickstart scenarios → validation tasks
-4. **Ordering**:
-   - Setup → Tests → Models → Services → Endpoints → Polish
-   - Dependencies block parallel execution
-
-## Validation Checklist
-
-*GATE: Checked by main() before returning*
-
-- [ ] All contracts have corresponding tests
-- [ ] All entities have model tasks
-- [ ] All tests come before implementation
-- [ ] Parallel tasks truly independent
-- [ ] Each task specifies exact file path
-- [ ] No task modifies same file as another [P] task