@vheins/local-memory-mcp 0.14.2 → 0.14.4

package/dist/prompts/session-planner.md

@@ -3,14 +3,15 @@ name: session-planner
 description: Break objective into atomic tasks.
 arguments:
   - name: objective
-    description: High-level session goal. Optional — inferred from active task, recent conversation, or pending handoff if omitted.
-    required: false
+    description: High-level session goal.
+    required: true
 agent: Strategy Lead
+version: "1.0.0"
+category: workflows
+tags: [workflow, planning, task-breakdown]
 ---
-## 0. CONTEXT RESOLUTION
-- **objective**: If provided, use directly. If omitted — extract from the active `in_progress` task description, the most recent pending handoff, or the last user request in conversation context.
 
-Plan execution for the resolved objective.
+Plan execution for: '{{objective}}'.
 
 Steps:
 1. **Orient**: Call `task-list` to avoid duplicate active/backlog work.
@@ -20,6 +21,6 @@ Steps:
 5. **Phase**: Group into `research`, `implementation`, and `validation`.
 6. **Hierarchy**: Use `parent_id` / `depends_on` for sequencing.
 7. **Priority Scale**: When creating tasks, use the exact MCP scale `1=Low`, `2=Normal`, `3=Medium`, `4=High`, `5=Critical`. Higher number means higher urgency.
-8. **Create**: Use `task-create` in current repo with stable `task_code`, tags, and acceptance criteria following the format: 1. Context & Analysis, 2. Step & Implementation, 3. Acceptance & Verification.
+8. **Create**: Use `task-create` in current repo with stable `task_code`, tags, and acceptance criteria.
 
 Display final plan to user.

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

@@ -3,6 +3,13 @@ name: task-management-guidelines
 description: Task tracking & progress management standards.
 arguments: []
 agent: Project Manager
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Utility
+complexity: Beginner
+tags: [workflow, tasks, status-management, mcp]
+author: vheins
 ---
 # Task Management Standards
 

package/dist/prompts/task-memory-executor.md

@@ -3,27 +3,31 @@ name: task-memory-executor
 description: Sequentially execute pending tasks for current repository.
 arguments:
   - name: agent_identity
-    description: Optional runner identity (e.g., Codex-Jarvis, Codex-HulkBuster, Gemini-Ultron). If omitted, identity is inferred from the active CLI/IDE and a short session token is appended.
+    description: Optional runner identity (e.g., Codex-Jarvis, Codex-HulkBuster, Gemini-Ultron). If omitted, infer identity from the active CLI/IDE and append short session token.
     required: false
 agent: Task Executor
+version: "1.5.4"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Orchestrator
+complexity: Advanced
+tags: [workflow, task-execution, memory]
+author: vheins
 ---
+# Skill: task-memory-executor
 
 ## 1. SYNC & FILTER
-1. **Identify**: Determine runner identity and repo context.
-   - Resolver priority: `agent_identity` argument -> auto session identity generated once per run.
+1. **Identify**: Resolve runner identity + repo name.
+   - Resolver priority: `agent_identity` argument -> auto-generated session identity for this run.
+   - Compute this once and reuse it across the full execution loop.
    - Auto identity format: `<runner>-<randomName>`.
    - `<runner>` should come from the active CLI/IDE label (for example `vibe-coding-cli`, `vibe-coding-ide`, `Codex`, `Gemini`) and `<randomName>` is a short stable session token.
-   - Use this identity for all `task-claim`, `task-update`, and handoff writes.
+   - Use this identity in task claim/update and handoff metadata so parallel terminals remain attributable.
 2. **List**: Call `task-list` ONCE for active tasks.
-3. **Dependency-aware selection** (in `task-list` order):
-   - Process tasks in the order returned by `task-list`.
-   - A task is READY only if:
-     - status is `backlog` or `pending`, and
-     - `depends_on` is empty, or the dependency task exists and is `completed`, and
-     - `parent_id` is empty, or the parent task is `completed`.
-   - Keep non-ready tasks out of execution for now.
-   - If a task is blocked by unresolved dependency/parent, do not claim it and continue to the next ready task.
-   - If all active tasks are blocked, report blockers and stop execution loop.
+3. **Dependency-ready filtering**: In the returned `task-list` order, only run `backlog`/`pending` tasks where:
+   - `depends_on` is empty or completed, and
+   - `parent_id` is empty or completed.
+   - If all are blocked, report blockers and pause.
 4. **Handoffs**: Call `handoff-list` with `status=pending` and inspect relevant transfer context before selecting work. Treat a pending handoff as active only when it has unfinished work, a blocker, a next owner, or a linked task. If it is obsolete or only describes completed work, close it with `handoff-update status=expired`.
 5. **Audit**: Identify stale `in_progress` tasks (>30m no update). Hydrate via `task-detail` to check timestamps.
 
@@ -33,14 +37,14 @@ agent: Task Executor
 - do NOT re-fetch or re-inject full detail
 
 ## 2. EXECUTION LOOP
-1. **Parallelism & Sub-Agents**: 
+1. **Parallelism & Sub-Agents**:
    - **MANDATORY**: Tasks MUST be delegated to sub-agents if the current agent has sub-agent capabilities.
-   - **Decomposition**: If a task is too broad, the agent is allowed to decompose it into multiple tasks (via `task-create`) and delegate them to sub-agents. All created tasks MUST follow the format: 1. Context & Analysis, 2. Step & Implementation, 3. Acceptance & Verification.
+   - **Decomposition**: If a task is too broad, the agent is allowed to decompose it into multiple tasks (via `task-create`) and delegate them to sub-agents.
    - **Spawn Limit**: The total number of parallel sub-agents MUST NOT exceed 2. Each sub-agent executes EXACTLY ONE task at a time.
    - **Fallback**: If the current agent CANNOT spawn sub-agents, it MUST execute tasks sequentially (exactly ONE concurrent task) until the queue is clear.
 2. **Hydrate**: Fetch full context via `task-detail` for the assigned task.
-3. **Readiness re-check**: Re-check blockers from hydrated detail (`depends_on`, `parent_id`) before claim. If still blocked, return to step 2 (execution loop) and pick the next ready task in list order.
-4. **Claim**: Use `task-claim` with `task_code` or `task_id` before implementation, and write the runner identity into claim metadata.
+3. **Readiness re-check**: Re-check `depends_on`/`parent_id` from hydrated detail; if still blocked, skip and pick next ready task.
+4. **Claim**: Use `task-claim` with `task_code` or `task_id` before implementation. Include the runner identity in claim metadata.
 5. **Start**: `task-update` status to `in_progress` (MUST transition: `pending` → `in_progress`). Add agent/role metadata and the same runner identity used by claims.
 6. **Research**: Call `memory-search` (Hybrid Search) and hydrate relevant results with `memory-detail`.
 7. **Standards (MANDATORY PER TASK)**: Call `standard-search` for every task inside the execution loop before any code edit, test edit, refactor, migration, or implementation decision, using the task intent, affected files, inferred language, stack, and repo as filters. This is required even for small tasks, decomposed tasks, and sub-agent assignments. Apply only relevant standards, hydrate details when needed, and if no relevant standards are returned, continue and state that no applicable standards were found.
@@ -57,16 +61,19 @@ agent: Task Executor
    - **Cleanup**: Completing/canceling a task automatically releases active claims and expires linked pending handoffs.
    - **Memory**: Store insights as `code_fact`/`pattern` via `memory-store`.
    - **Standards**: Store durable implementation rules via `standard-store`, not generic memory.
-   - **Handoff**: If work remains or ownership changes, create `handoff-create` with concise summary and structured context containing next steps/blockers/remaining work. Do not create handoffs for completed-work summaries. Include runner identity in handoff metadata/context.
+   - **Handoff**: If work remains or ownership changes, create `handoff-create` with concise summary and structured context containing next steps/blockers/remaining work. Do not create handoffs for completed-work summaries. Include the runner identity in handoff context/metadata.
    - **Retrospective**: Invoke `learning-retrospective`.
-   - **Commit**: Atomic git commit. The commit message MUST follow this format: `type(scope): [task-code] your commit message`, followed by a detailed description:
-     ```
-     - [Task Title]
-       [Summary Task]
-     ```
-     This ensures full traceability between code changes and project context.
-   - **GitHub Issue Traceability**: If task metadata contains a GitHub Issue reference, the commit message MUST also include the issue hashtag in `#123` format.
-   - **Issue Number Extraction**: Read the issue number from task metadata when available. If metadata only contains a GitHub Issue URL, extract the trailing issue number from that URL before committing.
+    - **Commit**: Atomic git commit. The commit message MUST follow this format:
+      ```
+      type(scope): your commit message
+
+      - {{task_title}}
+        {{summary_task}}
+
+      {{keyword}} #{{issue_number}}
+      ```
+      Use `fix` for bug fixes, `closes` for features/chores, `resolve` as general. Multiple issues: e.g., `fix #123, closes #124, resolve #125`. Issues close only when merged into the default branch.
+    - **Issue Number Extraction**: Read the issue number from task metadata when available. If metadata only contains a GitHub Issue URL, extract the trailing issue number from that URL before committing.
 
 10A. **BLOCKER HANDLING (AUTOMATIC TASK CREATION)**:
    - **Trigger**: When task status is updated to `blocked` with a comment explaining the blocker reason.
@@ -82,25 +89,16 @@ agent: Task Executor
      - Task Code: `${parent_task_code}-FIX-${unix_timestamp}`
      - Title: `FIX: [${parent_task_title}] - Resolve: ${blocker_reason_extracted}`
      - Description: Follow standard format (1. Context & Analysis, 2. Step & Implementation, 3. Acceptance & Verification)
-       - Context: Reference parent task code and explain the blocking factor
-       - Steps: Identify root cause and implement fix
-       - Verification: Confirm parent task can proceed
      - Parent ID: Set to current blocked task ID
      - Priority: `4` (HIGH)
      - Phase: `blocker-resolution`
      - Tags: `["blocker-fix", "auto-generated"]`
      - Metadata: Include `triggered_by_task`, `blocker_reason`, `creation_timestamp`, and `agent_identity`
-   - **Update Parent Task**: Add comment linking to the new blocker-fix task: `"Blocker resolution task created: ${new_task_code}"`
-   - **Link Dependencies**: Set parent task's `depends_on` to the new blocker-fix task (parent waits for fix before retry)
+   - **Update Parent Task**: Add comment linking to the new blocker-fix task
+   - **Link Dependencies**: Set parent task's `depends_on` to the new blocker-fix task
    - **Skip Creation** (if external): Log that blocker is external, keep task status as `blocked`, no automatic task created.
 
-11. **Loop**: Follow `~/.agents/AGENTS.md` → **CONTINUOUS EXECUTION MODE**:
-    - `task-list` (pending) → claim next
-    - If empty → promote backlog → loop
-    - If backlog empty → check stale in_progress → loop
-    - If stale empty → check handoff → loop
-    - **Only then → STOP**
-    - **Violation = incomplete execution**
+11. **Repeat**: Claim next task from `task-list`.
 
 ## 3. BACKLOG MAINTENANCE
 If active queue is empty:
@@ -112,90 +110,43 @@ If active queue is empty:
 
 ### Internal Solvable Blocker Patterns (Trigger Auto Task Creation)
 
-**Missing Dependencies/Modules**:
-- `module not found`, `missing dependency`, `import not installed`, `undefined function`, `no such file`
+**Missing Dependencies/Modules**: `module not found`, `missing dependency`, `import not installed`
 - Example: "ImportError: Function 'validateToken' not found"
 
-**Not Implemented**:
-- `function/method not implemented`, `interface not exists`, `component undefined`
+**Not Implemented**: `function not implemented`, `interface not exists`, `component undefined`
 - Example: "Function 'processPayment' not implemented - exists in type definitions but no implementation"
 
-**Configuration/Setup Issues**:
-- `.env missing`, `configuration not set`, `setup invalid`, `environment variable not found`
+**Configuration/Setup Issues**: `.env missing`, `configuration not set`, `setup invalid`
 - Example: "DATABASE_URL environment variable not set"
 
-**Test/Build Failures** (solvable):
-- `test failed`, `assertion failed`, `type error`, `build error`, `compilation failed`
+**Test/Build Failures**: `test failed`, `assertion failed`, `type error`, `build error`
 - Example: "Type error: Property 'user' does not exist on type 'Request'"
 
-**Implementation Gaps**:
-- `endpoint not implemented`, `API route missing`, `middleware not registered`
-- Example: "GET /api/users endpoint returns 404 - not implemented"
-
 ### External Blocker Patterns (Skip Auto Task Creation)
 
-**Awaiting User/External Action**:
-- `awaiting user`, `requires manual`, `user must`, `external dependency`, `manual setup`
-- Example: "Awaiting user approval for database migration", "Requires manual infrastructure setup"
+**Awaiting User/External Action**: `awaiting user`, `requires manual`, `external dependency`
+- Example: "Awaiting user approval for database migration"
 
-**External Service Issues**:
-- `API not responding`, `service unavailable`, `server not ready`
-- Example: "Payment gateway API not responding - external service unavailable"
+**External Service Issues**: `API not responding`, `service unavailable`, `server not ready`
+- Example: "Payment gateway API not responding"
 
-**Manual Prerequisites**:
-- `install locally`, `run script manually`, `requires external tool`
-- Example: "Requires manual Docker setup - not part of this task"
+### Auto Task Creation Example
 
-### Auto Task Creation Example Flow
-
-**Parent Task Blocked:**
+**Parent Task Blocked**:
 ```
-Task Code: FEATURE-42
-Title: Add payment processing middleware
+Task: FEATURE-42 (Add payment middleware)
 Status: blocked
-Comment: "Function 'chargeCard' in services/payment.ts not implemented - exists in interface but implementation missing"
+Comment: "Function 'chargeCard' not implemented"
 ```
 
-**Detection & Classification:**
-```
-Pattern detected: "Function .* not implemented" → INTERNAL SOLVABLE ✅
-Action: Create blocker-fix task
+**Auto-Generated Fix Task**:
 ```
-
-**Auto-Generated Task:**
-```
-Task Code: FEATURE-42-FIX-1714737908
-Title: FIX: [Add payment processing middleware] - Resolve: Function 'chargeCard' not implemented
-Parent ID: FEATURE-42
+Code: FEATURE-42-FIX-1714737908
+Title: FIX: [Add payment middleware] - Resolve: Function 'chargeCard' not implemented
+Parent: FEATURE-42
 Priority: 4 (HIGH)
-Phase: blocker-resolution
 Tags: ["blocker-fix", "auto-generated"]
-
-Description:
-1. Context & Analysis:
-   Parent task FEATURE-42 blocked due to: Function 'chargeCard' in services/payment.ts not implemented
-   The function exists in the interface but has no implementation body
-   Blocking factor: services/payment.ts - chargeCard function stub
-
-2. Step & Implementation:
-   - Review services/payment.ts chargeCard function signature
-   - Implement full payment processing logic (charges, refunds, error handling)
-   - Add proper error handling and validation
-   - Write unit tests for charge scenarios
-
-3. Acceptance & Verification:
-   - chargeCard function fully implemented
-   - Unit tests passing
-   - Function can be called from FEATURE-42 middleware
-   - FEATURE-42 parent task can proceed without blockers
 ```
 
-**Execution Workflow:**
-1. Agent picks blocker-fix task first (independent, no dependencies)
-2. Implements `chargeCard` function
-3. Completes blocker-fix task
-4. Parent task FEATURE-42 becomes ready (fix completed)
-5. Agent proceeds with FEATURE-42 execution
-
 ## 5. REPORT
 Provide progress summary.

package/dist/prompts/tech-affinity-scout.md

@@ -3,14 +3,15 @@ name: tech-affinity-scout
 description: Scout best practices from similar tech projects.
 arguments:
   - name: tags
-    description: CSV tech tags (e.g., 'react, tailwind'). Optional — auto-detected from repo package files, file extensions, or active task tags if omitted.
-    required: false
+    description: CSV tech tags (e.g., 'react, tailwind').
+    required: true
 agent: Tech Scout
+version: "1.0.0"
+category: planning
+tags: [planning, patterns, memory, tech-affinity]
 ---
-## 0. CONTEXT RESOLUTION
-- **tags**: If provided, use directly. If omitted — detect from repo package files, file extensions, or active task tags.
 
-Scout for relevant knowledge using detected/provided tags.
+Scout for relevant knowledge using tags: [{{tags}}].
 
 Steps:
 1. **Search**: Call `memory-search` with `current_tags=[{{tags}}]`.

package/dist/prompts/technical-planning.md

@@ -1,23 +1,54 @@
 ---
 name: technical-planning
-description: Technical blueprint for new feature/product.
+description: Technical blueprint for new feature/product, including full-roadmap execution planning.
 arguments:
   - name: objective
-    description: High-level goal. Optional — inferred from active task description, pending handoff, or recent conversation if omitted.
-    required: false
+    description: High-level goal.
+    required: true
 agent: Technical Architect
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Pipeline
+complexity: Advanced
+tags: [workflow, technical-planning]
+author: vheins
 ---
-## 0. CONTEXT RESOLUTION
-- **objective**: If provided, use directly. If omitted — extract from the active `in_progress` task description, the most recent pending handoff summary, or the last user instruction in conversation context.
 
-Create technical blueprint for the resolved objective.
+# Skill: Technical Planning Pipeline
 
-Cover:
-1. **Tech Stack**: Selected/confirmed technologies.
-2. **Architecture**: Components & data flow.
-3. **Domain Model**: Entities, value objects, events.
-4. **Database**: Normalized schema & relationships.
-5. **API Contracts**: Requests, responses, errors.
-6. **Execution**: Roadmap & phased delivery.
+## Purpose
+Produces a comprehensive technical blueprint (tech stack, architecture, domain, database, API contracts, execution plan).
 
-Present design for feedback before implementation.
+## Input
+| Variable | Type | Req | Description |
+|----------|------|-----|-------------|
+| `objective` | string | Yes | High-level goal |
+
+## FSM
+Entry: create-task → task-claim   Exit: task-update completed|blocked
+Guard: A(N) requires all prev A✅
+
+A1 | tech-stack-selection           | —    | tech stack decision  | —
+A2 | architecture-design            | A1✅ | architecture plan    | design/architecture/
+G1 | approve stack + arch          | A2✅ | → proceed            | —
+A3 | domain-modeling                | G1✅ | domain model         | design/domain/
+A4 | database-schema-planning       | A3✅ | schema plan          | design/database/
+G2 | approve domain + db           | A4✅ | → proceed            | —
+A5 | api-contract-design            | G2✅ | API contract         | design/api/
+G3 | approve API contracts         | A5✅ | → proceed            | —
+A6 | roadmap-creation + all sprint plans + MCP tasks | G3✅ | roadmap + sprint-1..sprint-N + allocation audit + MCP task tree | tasks/roadmap/ + tasks/sprints/ + local-memory-mcp
+GF | final approve                 | A6✅ | → documentation      | —
+
+## Execution Planning Rule
+A6 MUST cover the full delivery horizon. `sprint-planning` is per sprint, so A6 must derive `total_sprints` from roadmap timeline/capacity and generate one sprint-planning task for every sprint number from 1 through `total_sprints`. After sprint allocation audit passes, A6 must invoke `create-task` to create the Local Memory MCP task tree with parent/child and `depends_on` links. The final approval is blocked if only `sprint-1.md` exists while the roadmap contains later sprint-ready work, or if the MCP task tree was not created from the final sprint plans.
+
+## Optional
+A7  | capacity-planning             | —    | capacity plan        | —
+A8  | event-storming                | —    | domain discovery     | —
+A9  | dependency-mapping            | —    | dependency map       | —
+A10 | microservices-boundary        | —    | service boundaries   | —
+A11 | monolith-decomposition        | —    | migration plan       | —
+A12 | sla-slo-definition            | —    | SLA/SLO doc          | —
+A13 | system-design-review          | —    | review findings      | —
+A14 | tech-affinity-scout           | —    | best practices       | —

package/dist/prompts/tool-usage-guidelines.md

@@ -3,6 +3,13 @@ name: tool-usage-guidelines
 description: Tool usage standards & data integrity.
 arguments: []
 agent: System Architect
+version: "1.0.0"
+license: Proprietary — Personal Use Only
+category: workflows
+type: Utility
+complexity: Beginner
+tags: [workflow, tooling, memory, policy, mcp]
+author: vheins
 ---
 # Tool Usage Standards
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@vheins/local-memory-mcp",
-	"version": "0.14.2",
+	"version": "0.14.4",
 	"description": "MCP Local Memory Service for coding copilot agents",
 	"mcpName": "io.github.vheins/local-memory-mcp",
 	"type": "module",
@@ -78,7 +78,7 @@
 		"prettier": "^3.8.2",
 		"prettier-plugin-svelte": "^3.5.1",
 		"shx": "^0.4.0",
-		"svelte": "^5.55.1",
+		"svelte": "^5.55.9",
 		"svelte-check": "^4.4.6",
 		"svelte-eslint-parser": "^1.6.0",
 		"tsup": "^8.5.1",
@@ -89,6 +89,7 @@
 		"vitest": "^4.1.7"
 	},
 	"overrides": {
-		"protobufjs": "^7.5.5"
+		"protobufjs": "^7.5.8",
+		"brace-expansion": "^5.0.6"
 	}
 }