@vheins/local-memory-mcp 0.8.30 → 0.8.33

package/dist/prompts/project-briefing.md

@@ -1,13 +1,13 @@
 ---
 name: project-briefing
-description: Onboard the agent to the current repository state
+description: Contextual onboarding to current repository.
 arguments: []
 agent: Session Concierge
 ---
-I am starting a new session in the current repository.
+Initialize session in repository.
 
-Please perform a briefing to catch up on the project:
-1. **Recent Knowledge**: Call `local-memory-mcp` MCP tools `memory-search` with a broad query or relevant tags for the current repo to discover key decisions, patterns, and mistakes without the noise of a full recap.
-2. **Current Tasks**: Call `local-memory-mcp` MCP tools `task-list` to understand what is currently pending or in-progress.
-3. **Context Check**: Summarize the top 3 most important architectural decisions you found.
-4. **Readiness**: Tell me what you are ready to help with based on the current backlog.
+Briefing Steps:
+1. **Discover**: Call `memory-search` (current repo) to find recent decisions, patterns, and mistakes.
+2. **Backlog**: Call `task-list` to see active/pending tasks.
+3. **Core Context**: Summarize the top 3 architectural decisions found.
+4. **Action**: Propose next steps based on backlog.

package/dist/prompts/review-and-audit.md

@@ -1,131 +1,48 @@
 ---
 name: review-and-audit
-description: Audit documentation against implementation and generate Local Memory MCP tasks for gaps.
+description: Audit documentation against implementation; generate local tasks for gaps.
 arguments:
   - name: target
-    description: Target module, feature, or component to audit
+    description: Module, feature, or component to audit.
     required: false
 agent: Quality Auditor
 ---
-# Skill: review-audit
-
-## Purpose
-You are an **Audit Agent**. Your goal is to review the implementation against its existing documentation to identify any gaps or discrepancies. If gaps exist, you MUST generate structured tasks to resolve them.
-
-## Instructions
-
-### 1. Analysis (MANDATORY)
-1. **Sequential Discovery**: You MUST explore the documentation and codebase sequentially for each task. You are STRICTLY FORBIDDEN from spinning up parallel sub-agents for exploration. This ensures a stable and controlled discovery process.
-2. Read the relevant documentation first, then perform a deep-dive into the actual code implementation.
-3. **Use the `chrome-dev-tools` MCP integration** to interact with the application visually. You must audit the actual User Experience (UX), including visual elements, navigation flows, and responsiveness.
-4. Compare your findings from documentation and code against the actual rendered user experience to identify any missing features, outdated docs, or misaligned implementations.
-
-### 2. Task Generation Constraint
-If there is a gap, you MUST generate tasks in Local Memory MCP.
-When generating tasks, you MUST strictly follow the exact same rules as the **create-task** skill:
-
-#### 🚫 HARD CONSTRAINT: NON-EXECUTION (ABSOLUTE)
-You are **STRICTLY FORBIDDEN** from performing any of the following actions:
-* Editing any file
-* Creating new files
-* Deleting files
-* Running commands
-* Writing code implementations
-* Applying fixes directly
-* Simulating execution results
-
-**Allowed Actions:**
-* Read code and analyze context
-* Use `chrome-dev-tools` MCP to inspect browser UX
-* Create tasks via `local-memory-mcp` MCP tools `task-create`
-* Record decisions via `local-memory-mcp` MCP tools `memory-store`
-* List tasks via `local-memory-mcp` MCP tools `task-list`
-* Search memory via `local-memory-mcp` MCP tools `memory-search`
-
----
-
-### ✅ ALLOWED OUTPUT (STRICT)
-If gaps are found, your output MUST ONLY consist of calls to:
-* `local-memory-mcp` MCP tools `task-create`
-* `local-memory-mcp` MCP tools `memory-store`
-* `local-memory-mcp` MCP tools `task-list`
-* `local-memory-mcp` MCP tools `memory-search`
-
-**❌ DO NOT:**
-* Output explanations or narrative text
-* Output code or plans outside MCP
-* Suggest fixes directly
-
----
-
-### 3. PRE-ANALYSIS FOR TASK GENERATION (MANDATORY)
-Before creating tasks, you MUST:
-1. **Context discovery**: Call `local-memory-mcp` MCP tools `memory-search` to query existing architectural and historical context.
-2. **Search Logic**: Utilize Hybrid Search (70% Vector, 30% FTS5) for all repository research.
-3. **Conflict Prevention**: Respect the 0.55 similarity threshold in `memory-search` to prevent knowledge duplication.
-4. **Sync backlog**: Call `local-memory-mcp` MCP tools `task-list` to check existing tasks. **CRITICAL: Do NOT create a new task if a similar, redundant task already exists in `backlog` or `pending` status. If your new findings are distinct but related to an existing task, link them using `parent_id` or `depends_on` instead of creating an isolated task.**
-
----
-
-### 4. TASK DESIGN PRINCIPLES
-Each task MUST be:
-* **Atomic & Independent**: Exactly ONE logical change per task.
-* **Context-Rich**: Include file paths, class/function names, and API endpoints.
-* **Layer-Aware**: Specify if it's Database, Service, State, or UI layer.
-* **Contract-First**: Follow project API standards (include request/response shapes).
-* **Test-Ready**: Include at least one Positive and one Negative test case.
-
----
-
-### 5. TASK ATTRIBUTES (MANDATORY)
-Each `local-memory-mcp` MCP tools `task-create` MUST include:
-* `task_code`: (e.g., FEAT-123 / FIX-456 / REFACTOR-789)
-* `phase`: (Discovery / Implementation / Testing)
-* `priority`: (1–5)
-* `agent`: Current agent's name/role
-* `model`: Current AI model being used
-
-#### 🔥 DESCRIPTION FORMAT (STRICT)
-The `description` field MUST follow this structure EXACTLY:
-
-#### 1. Context & Analysis
-* **Finding / Trigger**: The audit finding or gap that triggered this task.
-* **Observation & Analysis**: The results of your context reading and technical reasoning.
-* **Goal**: A clear, non-redundant statement of what needs to be achieved.
-
-#### 2. Target Files & Implementation
-* Group by layer or exact file path. State the specific file references and the exact technical changes required. 
-* **Constraint**: Do NOT separate scope, references, and steps into different sections. Combine them here to avoid redundancy.
-
-#### 3. Acceptance & Verification
-* **Checklist**: Actionable criteria (e.g., `[ ] Condition 1`) that prove the gap is resolved.
-* **Testing**: Brief Positive/Negative scenarios to confirm success.
-
----
-
-### metadata (MANDATORY)
-* Required agent role.
-* Additional technical context.
-
----
-
-### 6. MEMORY STORAGE (CONDITIONAL)
-If the finding or gap involves a decision, new feature, or architectural change, you MUST log it as a memory using `local-memory-mcp` MCP tools `memory-store` with `type: decision`. This ensures the decision to create the task and its triggering context is captured in the global memory. 
-**CRITICAL**: Do NOT log tasks as decisions if they are purely for bug fixes or straightforward defect resolutions.
-
----
-
-### 7. MULTI-TASK HANDLING
-If gaps are complex:
-1. Create a parent task.
-2. Create child tasks using `parent_id` and `depends_on`.
-
----
-
-### 8. FINAL SELF-CHECK (MANDATORY)
-Before finishing, validate:
-* ❌ No code was written.
-* ❌ No execution was performed.
-* ✅ Only MCP task operations exist.
-
-extra_context:
+# Skill: review-and-audit (Audit Agent)
+
+## 1. ANALYSIS
+1. **Sequential Discovery**: Explore docs and code sequentially. NO parallel sub-agents.
+2. **UX Audit**: Use `chrome-dev-tools` for visual, navigation, and responsiveness checks.
+3. **Compare**: Match docs + code findings against live UI to find gaps/misalignments.
+
+## 🚫 FORBIDDEN: NON-EXECUTION
+DO NOT edit/create/delete files, run commands, or implement code.
+**Allowed**: Read code, `chrome-dev-tools`, `task-create`, `memory-store`, `task-list`, `memory-search`.
+
+## ✅ OUTPUT: MCP ONLY
+ONLY call MCP tools. No prose, code, or external plans.
+
+## 2. PRE-TASK ANALYSIS
+1. **Search**: Call `memory-search` (Hybrid Search). 0.55 similarity threshold.
+2. **De-duplicate**: Call `task-list`. Skip existing/redundant tasks. Link via `parent_id`/`depends_on`.
+
+## 3. TASK DESIGN & FORMAT
+- **Atomic**: One change per task.
+- **Attributes**: `task_code`, `phase`, `priority`, `agent`, `model`.
+- **Description** (STRICT FORMAT):
+  ### 1. Context & Analysis
+  - **Finding**: Gap trigger.
+  - **Observation**: Reasoning.
+  - **Goal**: Clear objective.
+  ### 2. Target Files & Implementation
+  - Combined scope/steps per path/layer.
+  ### 3. Acceptance & Verification
+  - **Checklist**: `[ ]` criteria.
+  - **Testing**: Scenarios.
+
+## 4. LOGGING & MULTI-TASK
+- Log architectural/feature changes as `type: decision` via `memory-store`.
+- Use Parent/Child structure for complex gaps.
+
+## 5. SELF-CHECK
+- ❌ No implementation.
+- ✅ ONLY MCP tool calls.

package/dist/prompts/review-and-post-issue.md

@@ -1,103 +1,50 @@
 ---
 name: review-and-post-issue
-description: Audit documentation against implementation and generate GitHub issues for gaps.
+description: Audit documentation against implementation; generate GitHub issues for gaps.
 arguments:
   - name: owner
-    description: GitHub repository owner (e.g., 'facebook')
+    description: GitHub repo owner.
     required: true
   - name: repo
-    description: GitHub repository name (e.g., 'react')
+    description: GitHub repo name.
     required: true
   - name: target
-    description: Target module, feature, or component to audit
+    description: Module, feature, or component to audit.
     required: false
 agent: Quality Auditor
 ---
-# Skill: review-and-post-issue
-
-## Purpose
-You are an **Audit Agent**. Your goal is to review the implementation against its existing documentation to identify any gaps or discrepancies. If gaps exist, you MUST generate structured **GitHub Issues** to resolve them.
-
-## Instructions
-
-### 1. Analysis (MANDATORY)
-1. **Sequential Discovery**: You MUST explore the documentation and codebase sequentially for each task. You are STRICTLY FORBIDDEN from spinning up parallel sub-agents for exploration. This ensures a stable and controlled discovery process.
-2. Read the relevant documentation first, then perform a deep-dive into the actual code implementation.
-3. **Audit User Experience**: If applicable, use `chrome-dev-tools` MCP integration to interact with the application visually. You must audit the actual UX, including visual elements, navigation flows, and responsiveness.
-4. Compare your findings from documentation and code against the actual rendered user experience to identify any missing features, outdated docs, or misaligned implementations.
-
-### 2. Issue Generation Constraint
-If there is a gap, you MUST generate issues in the specified GitHub repository.
-When generating issues, you MUST strictly follow high-quality engineering standards:
-
-#### 🚫 HARD CONSTRAINT: NON-EXECUTION (ABSOLUTE)
-You are **STRICTLY FORBIDDEN** from performing any of the following actions:
-* Editing any file
-* Creating new files
-* Deleting files
-* Running commands
-* Writing code implementations
-* Applying fixes directly
-
-**Allowed Actions:**
-* Read code and analyze context
-* Use `chrome-dev-tools` MCP to inspect browser UX
-* Search memory via `local-memory-mcp` MCP tools `memory-search`
-* Search GitHub issues via **Github MCP Server Tools (search_issues)**
-* Create GitHub issues via **Github MCP Server Tools (issue_write)** (method: 'create')
-
----
-
-### ✅ ALLOWED OUTPUT (STRICT)
-If gaps are found, your output MUST ONLY consist of calls to:
-* **Github MCP Server Tools (search_issues)**
-* **Github MCP Server Tools (issue_write)**
-* `local-memory-mcp` MCP tools `memory-search`
-
-**❌ DO NOT:**
-* Output explanations or narrative text
-* Output code or plans outside GitHub
-* Suggest fixes directly
-
----
-
-### 3. PRE-ANALYSIS FOR ISSUE GENERATION (MANDATORY)
-Before creating issues, you MUST:
-1. **Context discovery**: Call `local-memory-mcp` MCP tools `memory-search` to query existing architectural and historical context.
-2. **Search Logic**: Utilize Hybrid Search (70% Vector, 30% FTS5) for all repository research.
-3. **Conflict Prevention**: Respect the 0.55 similarity threshold in `memory-search` to prevent knowledge duplication.
-4. **Sync GitHub Backlog**: Call **Github MCP Server Tools (search_issues)** with relevant keywords to check for existing issues. **CRITICAL: Do NOT create a new issue if a similar, redundant issue already exists. If your findings are distinct but related, comment on the existing issue instead.**
-
----
-
-### 4. ISSUE DESIGN PRINCIPLES
-Each issue MUST be:
-* **Atomic & Independent**: Exactly ONE logical change per issue.
-* **Context-Rich**: Include file paths, class/function names, and API endpoints.
-* **Layer-Aware**: Specify if it's Database, Service, State, or UI layer.
-* **Test-Ready**: Include at least one Positive and one Negative test case.
-
----
-
-### 5. DESCRIPTION FORMAT (STRICT)
-The `body` of each GitHub issue MUST follow this structure EXACTLY:
-
-#### 1. Context & Analysis
-* **Finding / Trigger**: The audit finding or gap that triggered this issue.
-* **Observation & Analysis**: The results of your context reading and technical reasoning.
-* **Goal**: A clear statement of what needs to be achieved.
-
-#### 2. Target Files & Implementation
-* Group by layer or exact file path. State the specific file references and the exact technical changes required.
-
-#### 3. Acceptance & Verification
-* **Checklist**: Actionable criteria (e.g., `[ ] Condition 1`) that prove the gap is resolved.
-* **Testing**: Brief Positive/Negative scenarios to confirm success.
-
----
-
-### 6. FINAL SELF-CHECK (MANDATORY)
-Before finishing, validate:
-* ❌ No code was written.
-* ❌ No execution was performed.
-* ✅ Only GitHub issue operations and memory searches exist.
+# Skill: review-and-post-issue (Audit Agent)
+
+## 1. ANALYSIS
+1. **Sequential Discovery**: Explore docs and code sequentially. NO parallel sub-agents.
+2. **UX Audit**: If applicable, use `chrome-dev-tools` for visual, navigation, and responsiveness checks.
+3. **Compare**: Match findings against live UI to find gaps/misalignments.
+
+## 🚫 FORBIDDEN: NON-EXECUTION
+DO NOT edit/create/delete files, run commands, or implement code.
+**Allowed**: Read code, `chrome-dev-tools`, `memory-search`, GitHub `search_issues`, `issue_write`.
+
+## ✅ OUTPUT: GITHUB ONLY
+ONLY call: `search_issues`, `issue_write` (method: 'create'), `memory-search`.
+No prose. No external plans.
+
+## 2. PRE-ISSUE ANALYSIS
+1. **Search**: Call `memory-search` (Hybrid Search). 0.55 similarity threshold.
+2. **De-duplicate**: Call `search_issues`. Skip existing/redundant issues. Comment on related issues if distinct.
+
+## 3. ISSUE DESIGN & FORMAT
+- **Atomic**: One change per issue.
+- **Body** (STRICT FORMAT):
+  ### 1. Context & Analysis
+  - **Finding**: Gap trigger.
+  - **Observation**: Reasoning.
+  - **Goal**: Clear objective.
+  ### 2. Target Files & Implementation
+  - Path/layer specific changes.
+  ### 3. Acceptance & Verification
+  - **Checklist**: `[ ]` criteria.
+  - **Testing**: Scenarios.
+
+## 4. SELF-CHECK
+- ❌ No implementation.
+- ✅ ONLY GitHub/Memory tool calls.

package/dist/prompts/root-cause-analysis.md

@@ -1,27 +1,27 @@
 ---
 name: root-cause-analysis
-description: Apply structured 5-Why analysis to trace bugs to their origin
+description: 5-Why analysis to trace bug origins.
 arguments:
   - name: tech_stack
-    description: Target technology stack
+    description: Target tech stack.
     required: true
   - name: bug_description
-    description: Observable symptom or bug behavior
+    description: Bug behavior.
     required: true
   - name: symptoms
-    description: Additional errors, logs, metrics
+    description: Logs, errors, metrics.
     required: false
 agent: Diagnostic Lead
 ---
-You are a senior software engineer conducting a root cause analysis for a bug in the current repository.
+Conduct root cause analysis for repository bug.
 
-Tech stack: {{tech_stack}}
-Bug description: {{bug_description}}
+Stack: {{tech_stack}}
+Bug: {{bug_description}}
 Symptoms: {{symptoms}}
 
-Apply a full **5-Why analysis**:
-1. **Symptom Statement**: Technically restate the problem.
-2. **5-Why Causal Chain**: Trace from symptom to the core process/design/environmental failure.
-3. **Root Cause Statement**: "The root cause is [X] because [Y], which allowed [Z] to occur."
-4. **Fix Recommendation**: Address the root cause, not just the symptom.
-5. **Recurrence Prevention**: Suggest a monitoring or testing measure.
+Output:
+1. **Symptom**: Technical problem restatement.
+2. **5-Whys**: Causal chain from symptom to core failure.
+3. **Root Cause**: "The root cause is [X] because [Y], allowing [Z]."
+4. **Recommendation**: Fix addressing root cause.
+5. **Prevention**: Monitoring/testing measure.

package/dist/prompts/security-triage.md

@@ -1,27 +1,27 @@
 ---
 name: security-triage
-description: Assess security vulnerability reports for exploitability and prioritize remediation
+description: Assess vulnerability exploitability and prioritize fix.
 arguments:
   - name: tech_stack
-    description: Application stack
+    description: App stack.
     required: true
   - name: vulnerability_report
-    description: Report details (CVE, SAST, etc.)
+    description: Report details (CVE, SAST).
     required: true
   - name: codebase_context
-    description: Component usage context
+    description: Usage context.
     required: false
 agent: Security Engineer
 ---
-Act as a senior application security engineer triaging a vulnerability for the current repository.
+Triage vulnerability for repository.
 
 Stack: {{tech_stack}}
 Report: {{vulnerability_report}}
-Codebase context: {{codebase_context}}
+Context: {{codebase_context}}
 
-Please provide:
-1. **Vulnerability Classification**: Type, CVE, CVSS, and attack vector.
-2. **Exploitability Assessment**: Contextual reachability and realistic scenarios.
-3. **Impact Assessment**: Impact on Confidentiality, Integrity, and Availability.
-4. **Remediation Priority & Fix**: Concrete priority (P0-P3) and fix steps.
-5. **Verification**: How to test and verify the fix.
+Output:
+1. **Classification**: Type, CVE, CVSS, vector.
+2. **Exploitability**: Reachability & scenarios.
+3. **Impact**: CIA impact.
+4. **Remediation**: Priority (P0-P3) & fix steps.
+5. **Verification**: Testing method.

package/dist/prompts/senior-code-review.md

@@ -1,33 +1,32 @@
 ---
 name: senior-code-review
-description: Performs a comprehensive production-readiness evaluation for the current repository context
+description: Comprehensive production-readiness evaluation.
 arguments:
   - name: tech_stack
-    description: Target tech stack (e.g., 'Node.js + Express')
+    description: Tech stack.
     required: true
   - name: context
-    description: Production context (traffic, data sensitivity, SLA, conventions)
+    description: Production context (SLA, data, conventions).
     required: false
 agent: Principal Reviewer
 ---
-Act as a principal software engineer performing a production-readiness review for the current repository.
+Perform production-readiness review for repository.
 
 Stack: {{tech_stack}}
 Context: {{context}}
 
-Please review the current code/changes against these 6 dimensions:
-1. **Error Handling Completeness**
-2. **Security** (Injection, Input validation, PII/Secrets)
-3. **Performance** (Time/Memory complexity, DB queries)
-4. **Observability** (Logging, Metrics, Tracing)
-5. **Test Coverage**
-6. **Documentation**
+Audit Dimensions:
+1. **Errors**: Completeness & patterns.
+2. **Security**: Validation, injection, secrets.
+3. **Performance**: Complexity, DB efficiency.
+4. **Observability**: Logs, metrics, traces.
+5. **Testing**: Coverage & quality.
+6. **Docs**: Clarity & accuracy.
 
-For each finding, provide:
-- **Severity**: P0-P3
-- **Dimension**: One of the above
-- **Location**: Specific function/line
-- **Problem**: What is wrong and why it matters
-- **Fix**: Actionable recommendation
+Output per Finding:
+- **Severity**: P0-P3.
+- **Problem**: What & why.
+- **Location**: Path/function.
+- **Fix**: Actionable step.
 
-Produce a **Production Readiness Verdict**: READY | READY WITH MINOR FIXES | NOT READY
+Verdict: READY | READY WITH MINOR FIXES | NOT READY

package/dist/prompts/session-planner.md

@@ -1,18 +1,18 @@
 ---
 name: session-planner
-description: Break down a complex objective into atomic tasks for the current repository
+description: Break objective into atomic tasks.
 arguments:
   - name: objective
-    description: The high-level goal for this session
+    description: High-level session goal.
     required: true
 agent: Strategy Lead
 ---
-Our objective for today in the current repository is: '{{objective}}'.
+Plan execution for: '{{objective}}'.
 
-Please act as a project manager and plan the execution:
-1. **Analyze**: Break this objective down into 3-7 small, atomic, and verifiable tasks.
-2. **Execute**: Use 'task-manage' with action='create' to add these to the local tracker for the current repo.
-3. **Hierarchy**: Use 'parent_id' or 'depends_on' if there is a clear order of operations.
-4. **Phases**: Group tasks into phases like 'research', 'implementation', and 'validation'.
+Steps:
+1. **Analyze**: Break into 3-7 atomic, verifiable tasks.
+2. **Phase**: Group into 'research', 'implementation', 'validation'.
+3. **Hierarchy**: Use `parent_id` / `depends_on` for sequencing.
+4. **Create**: Use `task-create` in current repo.
 
-Display the created plan to the user when done.
+Display final plan to user.

package/dist/prompts/task-management-guidelines.md

@@ -1,28 +1,23 @@
 ---
 name: task-management-guidelines
-description: Best practices for task tracking and progress management
+description: Task tracking & progress management standards.
 arguments: []
 agent: Project Manager
 ---
-Guidelines for Task Management:
+# Task Management Standards
 
-1. task-list (PRIMARY NAVIGATION & SEARCH):
-   - MANDATORY: Always call `local-memory-mcp` MCP tools `task-list` (with no status specified to get active tasks) at the very start of a new session.
-   - Returns a compact table: columns = [id, task_code, title, status, priority, comments_count]. Rows are pointers — NOT full tasks.
-   - Default behavior: returns `in_progress` and `pending` tasks if `status` is omitted.
-   - Filter by status via the `status` param (comma-separated, e.g., `"in_progress,pending"`).
-   - Search by keyword matching task_code, title, or description via the `query` param.
-   - After selecting a task from the table, fetch its full context via `task-detail` tool.
-   - Coordinate: If a task is already 'in_progress', do not attempt to work on it unless specifically asked to collaborate.
-   - DO NOT work on multiple tasks simultaneously.
+## 1. NAVIGATION (`task-list`)
+-   **Sync**: Call `task-list` at every session start (default: `in_progress,pending`).
+-   **Format**: Compact table (IDs only). Use `query` for keyword search.
+-   **Retrieve**: Fetch full context via `task-detail` AFTER selecting a task.
+-   **Coordination**: NEVER work on `in_progress` tasks assigned to others. Focus on ONE task at a time.
 
-3. Detail Tools:
-   - Use `local-memory-mcp` MCP tools `task-detail` to fetch full task details (including comments and history) by ID or task_code.
-   - Use `local-memory-mcp` MCP tools `memory-detail` to fetch full memory content by ID.
+## 2. DETAIL TOOLS
+-   **Tasks**: Call `task-detail` for history/comments (ID or `task_code`).
+-   **Memory**: Call `memory-detail` for full entry content.
 
-4. Workflow Integration:
-   - Plan first: Create tasks for the entire lifecycle (Research → Strategy → Execution → Validation).
-   - Atomic Updates: Update the task status to 'in_progress' EXACTLY ONCE when you begin working on a task.
-   - Workflow Enforcement (MANDATORY): You cannot move a task from 'pending' or 'backlog' directly to 'completed'. You MUST transition to 'in_progress' first for status transition safety.
-   - Finalize: Only mark a task as 'completed' after successful validation (tests passed).
-   - Automatic Archiving: Marking a task as 'completed' automatically triggers `archiveTaskToMemory`, creating a 'task_archive' memory entry with the full history and token usage report.
+## 3. WORKFLOW
+-   **Planning**: Create tasks for full lifecycle (Research → Strategy → Execution → Validation).
+-   **Transition Safety**: MUST move from `backlog/pending` → `in_progress` → `completed`. Skipping `in_progress` is forbidden.
+-   **Validation**: Only `complete` after passing tests.
+-   **Archiving**: Completion triggers auto-archive to `task_archive` memory with token reporting.