@vheins/local-memory-mcp 0.14.6 → 0.14.8

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

@@ -3,150 +3,63 @@ 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, infer identity from the active CLI/IDE and append short session token.
+    description: Optional runner identity. If omitted, infer from CLI/IDE + short session token.
     required: false
 agent: Task Executor
-version: "1.5.4"
-license: Proprietary — Personal Use Only
 category: workflows
-type: Orchestrator
-complexity: Advanced
+version: "1.5.4"
 tags: [workflow, task-execution, memory]
-author: vheins
 ---
-# Skill: task-memory-executor
-
-## 1. SYNC & FILTER
-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 in task claim/update and handoff metadata so parallel terminals remain attributable.
-2. **List**: Call `task-list` ONCE for active tasks.
-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.
-
-## Task Cache (MANDATORY)
-- `task-detail` MUST be called at most ONCE per task
-- result MUST be reused across all steps
-- do NOT re-fetch or re-inject full detail
-
-## 2. EXECUTION LOOP
-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.
-   - **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 `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.
-8. **Execute**:
-   - **Trace**: Inspect logic, call sites, and docs. DO NOT infer from file presence.
-   - **Logic**: Implement per description/intent.
-9. **Validate**:
-   - Trace path end-to-end.
-   - Run tests/linters/type-checks.
-   - Logic audit for all affected paths.
-   - **Browser Verification (MANDATORY)**: If the task involves UI/UX changes, use Playwright or Chrome DevTools to verify the feature is functional and consumable by the user. Check console errors, layout overflow, responsive behavior, and core interactions.
-10. **Finalize**:
-   - **Evidence**: `task-update` status to `completed` with detailed 'comment' (inspected files, verified logic, test results).
-   - **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 the runner identity in handoff context/metadata.
-   - **Retrospective**: Invoke `learning-retrospective`.
-    - **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.
-   - **Blocker Classification**: Analyze the blocker comment to determine if it is **internal solvable** or **external**:
-     - **Internal Solvable** (auto-create task): Missing dependency, missing module/function, configuration/env setup, implementation gap, failing test, build error.
-     - **External** (skip auto-create): Awaiting user input/approval, API/service unavailability, manual external setup required.
-   - **Pattern Matching**: Use regex patterns to detect internal blockers in the comment:
-     - Missing patterns: `/(module|package|library|dependency|import)\s+(not\s+found|missing|undefined|not\s+installed)/i`
-     - Not implemented: `/(function|interface|class|method|endpoint)\s+not\s+(found|implemented|exists)/i`
-     - Configuration: `/(config|configuration|setup|env|environment)\s+(missing|not\s+set|invalid)/i`
-     - Test/build failure: `/(test|build|compile|type\s+check)\s+(failed|error)/i`
-   - **Auto-Create Task** (if internal solvable):
-     - 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)
-     - 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
-   - **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. **Repeat**: Claim next task from `task-list`.
+## FSM — Main Loop
 
-## 3. BACKLOG MAINTENANCE
-If active queue is empty:
-1. Call `task-list` (status: `backlog`).
-2. Move up to 20 highest-priority tasks to `pending` via `task-update`.
-3. Interpret priority using MCP ordering: `5=Critical`, `4=High`, `3=Medium`, `2=Normal`, `1=Low`.
+Entry=S0 → S1 → G0 → S2 → S3 → S4 → S5 → S6 → S7 → S8 Exit=exhausted|blocked
+Guard: S(N) req S(N-1)✅; dependency-ready filter (depends_on+parent_id done)
 
-## 4. BLOCKER REFERENCE (Patterns & Detection)
+S0 | sync: resolve identity (arg→auto `<runner>-<randomName>`, 1x reuse all loop) + task-list(ONCE) + handoff-list(pending, close stale) + audit stale in_progress(>30m, hydrate via task-detail) | — | filtered queue | —
+S1 | hydrate: task-detail ONCE per task — MUST cache, MUST reuse all steps, NO re-fetch | S0✅ | full task | —
+G0 | readiness: depends_on✅ AND parent_id✅? if all blocked → report blockers + pause | S1✅ | → S2 / skip+pick next | —
+S2 | claim: task-claim(with identity metadata) + task-update→in_progress(agent, role, identity) | G0✅ | ownership | —
+S3 | research: memory-search + standard-search(MANDATORY per task — even sub-agents/decomposed) + hydrate relevant | S2✅ | context | —
+S4 | execute: trace logic+callsites+docs — DO NOT infer from file presence; decompose if too broad | S3✅ | changes | —
+S5 | validate: tests + linters + type-check + browser(if UI — MANDATORY: console errors, overflow, responsive, core interactions) + logic audit all paths | S4✅ | verification | —
+S6 | finalize: task-update→completed(evidence: inspected files, verified logic, test results) + memory-store(insights) + standard-store(rules) + handoff(if work remains — with identity) + retrospective + report | S5✅ | completion | —
+S7 | commit: `type(scope): msg — {{task_title}} {{summary_task}} {{keyword}} #N` (fix|closes|resolve, extract N from metadata/URL) | S6✅ | git commit | —
+S8 | repeat → S0 | queue not empty | next task | —
 
-### Internal Solvable Blocker Patterns (Trigger Auto Task Creation)
+## Design Note
 
-**Missing Dependencies/Modules**: `module not found`, `missing dependency`, `import not installed`
-- Example: "ImportError: Function 'validateToken' not found"
+Main loop is intentionally infinite — runs until MCP task queue is fully exhausted (no pending/backlog tasks remain across all cycles). No max_iterations guard needed.
 
-**Not Implemented**: `function not implemented`, `interface not exists`, `component undefined`
-- Example: "Function 'processPayment' not implemented - exists in type definitions but no implementation"
+## Parallelism Rules
 
-**Configuration/Setup Issues**: `.env missing`, `configuration not set`, `setup invalid`
-- Example: "DATABASE_URL environment variable not set"
+- Delegate to sub-agents if capability exists; decompose broad tasks via task-create
+- **Max 2** parallel sub-agents; each executes EXACTLY 1 task
+- Fallback: sequential (1 concurrent) if no sub-agent capability
 
-**Test/Build Failures**: `test failed`, `assertion failed`, `type error`, `build error`
-- Example: "Type error: Property 'user' does not exist on type 'Request'"
+## FSM — Blocker Handling
 
-### External Blocker Patterns (Skip Auto Task Creation)
+Entry=S0 → S1 → G1|G2 → S2 Exit=unblocked|deferred
 
-**Awaiting User/External Action**: `awaiting user`, `requires manual`, `external dependency`
-- Example: "Awaiting user approval for database migration"
+S0 | detect: task-update→blocked with reason | is blocked? | blocker comment | —
+S1 | classify: regex-match comment against patterns below | S0✅ | internal solvable | external | —
+G1 | internal solvable? | S1✅ | → S2 auto-create | —
+G2 | external? (awaiting user, API down) | S1✅→external | → keep blocked, no auto task | —
+S2 | create fix task: code=`{parent}-FIX-{unix}`, title=`FIX: [{parent_title}] — Resolve: {reason}`, priority=4(HIGH), phase=blocker-resolution, parent=current_id, depends_on=parent, tags=[blocker-fix,auto-generated], metadata={triggered_by, blocker_reason, timestamp, identity} | G1✅ | blocker fix task | —
 
-**External Service Issues**: `API not responding`, `service unavailable`, `server not ready`
-- Example: "Payment gateway API not responding"
+### Blocker Regex Patterns
 
-### Auto Task Creation Example
+| Category  | Regex                                                                                                    | Example                                           |
+| --------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
+| Missing   | `/(module\|package\|library\|dependency\|import)\s+(not\s+found\|missing\|undefined\|not\s+installed)/i` | `ImportError: Function 'validateToken' not found` |
+| Not impl  | `/(function\|interface\|class\|method\|endpoint)\s+not\s+(found\|implemented\|exists)/i`                 | `Function 'processPayment' not implemented`       |
+| Config    | `/(config\|configuration\|setup\|env\|environment)\s+(missing\|not\s+set\|invalid)/i`                    | `DATABASE_URL not set`                            |
+| Test fail | `/(test\|build\|compile\|type\s+check)\s+(failed\|error)/i`                                              | `Type error: Property 'user' not on 'Request'`    |
 
-**Parent Task Blocked**:
-```
-Task: FEATURE-42 (Add payment middleware)
-Status: blocked
-Comment: "Function 'chargeCard' not implemented"
-```
+## FSM — Backlog Maintenance
 
-**Auto-Generated Fix Task**:
-```
-Code: FEATURE-42-FIX-1714737908
-Title: FIX: [Add payment middleware] - Resolve: Function 'chargeCard' not implemented
-Parent: FEATURE-42
-Priority: 4 (HIGH)
-Tags: ["blocker-fix", "auto-generated"]
-```
+Entry=S0 → S1 Exit=promoted
+Guard: active queue empty?
 
-## 5. REPORT
-Provide progress summary.
+S0 | list backlog: task-list(status=backlog) | active queue empty? | backlog tasks | —
+S1 | promote top 20 by priority(5→1) to pending via task-update | S0✅ | tasks→pending | —

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

@@ -6,16 +6,19 @@ arguments:
     description: CSV tech tags (e.g., 'react, tailwind').
     required: true
 agent: Tech Scout
-version: "1.0.0"
 category: planning
+version: "1.0.0"
 tags: [planning, patterns, memory, tech-affinity]
 ---
 
-Scout for relevant knowledge using tags: [{{tags}}].
+## FSM
+
+Entry=S0 → S1 → S2 → S3  Exit=scouted
+Guard: S(N) req S(N-1)✅
+
+S0 | search: memory-search (current_tags=[tags]) + standard-search (stack=[tags]) | tags provided? | pointer rows | —
+S1 | hydrate: memory-detail for relevant pointers | S0✅ | full entries | —
+S2 | filter: pattern + decision + coding standard entries from similar stacks | S1✅ | applicable knowledge | —
+S3 | adapt: explain adaptation to current project; separate memory-derived vs standards | S2✅ | adaptation guide | —
 
-Steps:
-1. **Search**: Call `memory-search` with `current_tags=[{{tags}}]`.
-2. **Standards**: Call `standard-search` with `stack=[{{tags}}]` to find reusable coding standards.
-3. **Hydrate**: Use `memory-detail` for relevant memory pointer rows.
-4. **Filter**: Identify applicable `pattern`, `decision`, and coding standard entries from similar stacks.
-5. **Adapt**: Explain adaptation of these practices to current project and clearly separate memory-derived guidance from standards.
+Tags: {{tags}}

package/dist/prompts/technical-planning.md

@@ -6,49 +6,34 @@ arguments:
     description: High-level goal.
     required: true
 agent: Technical Architect
-version: "1.0.0"
-license: Proprietary — Personal Use Only
 category: workflows
-type: Pipeline
-complexity: Advanced
+version: "1.0.0"
 tags: [workflow, technical-planning]
-author: vheins
 ---
 
-# Skill: Technical Planning Pipeline
-
-## Purpose
-Produces a comprehensive technical blueprint (tech stack, architecture, domain, database, API contracts, execution plan).
-
-## 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      | —
+Entry=create-task → task-claim  Exit=task-update completed|blocked
+Guard: A(N) req all prev A✅
 
-## 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.
+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 | derive total_sprints from roadmap timeline+capacity → generate 1 sprint-planning task per sprint(N) + allocation audit + MCP task tree(parent/child + depends_on) | G3✅ | roadmap + sprints-1..N + audit + tasks | tasks/ + MCP
+GF | final approve — blocked if sprint-N.md missing or MCP task tree not created | A6✅ | → documentation | —
 
 ## 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       | —
+
+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,49 +3,37 @@ 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
+version: "1.0.0"
 tags: [workflow, tooling, memory, policy, mcp]
-author: vheins
 ---
-# Tool Usage Standards
-
-Use the tools in the same flow exposed by the dashboard: navigate with compact lists/search, hydrate only selected records, then mutate through the dedicated create/update tools.
-
-## 1. Memory Flow
-- **Navigate**: Use `memory-recap` for repository overview and `memory-search` for targeted lookup. Search returns pointer rows only.
-- **Hydrate**: Use `memory-detail` with `id` or `code` before relying on full content.
-- **Store**: Use `memory-store` only for durable project knowledge. Tag by tech stack, keep titles human-readable, and put auxiliary context in `metadata`.
-- **Scope**: Set `is_global=true` only for rules that apply across repositories.
-- **Maintain**: Use `memory-update` or `supersedes` when knowledge changes. Avoid duplicate memories.
-- **Acknowledge**: After using memory to generate code, call `memory-acknowledge` with `used`, `irrelevant`, or `contradictory`.
-
-## 2. Task Flow
-- **Navigate**: Start with `task-list` using active statuses (`in_progress,pending`) or explicit filters.
-- **Hydrate**: Use `task-detail` after selecting a task from the list. Full task detail includes comments plus current coordination state such as active claims and pending handoffs.
-- **Mutate**: Use `task-create`, `task-update`, and `task-delete` for lifecycle changes.
-- **Transitions**: Move `backlog/pending/blocked` to `in_progress` before `completed`; include validation evidence and token estimate on completion.
-- **Automatic cleanup**: Moving a task to `completed` or `canceled` automatically releases active claims and expires pending handoffs linked to that task.
-
-## 3. Standards Flow
-- **Search first**: `standard-search` is mandatory before any code edit, test edit, refactor, migration, or implementation decision. Search by `query`, `language`, `stack`, `repo`, and `is_global`; if no relevant standards are returned, continue and state that no applicable standards were found.
-- **Apply precisely**: Treat standards as implementation rules, not generic documentation summaries.
-- **Store atomically**: Use `standard-store` for one rule per entry with `name`, `content`, `context`, `version`, `language`, `stack`, `tags`, and correct repo/global scope.
-- **Scope**: Prefer repo-specific standards for local conventions; use global standards only for cross-repo rules.
-
-## 4. Handoff & Claim Flow
-- **Queue**: Use `handoff-list` as the handoff navigation layer. Filter by `status`, `from_agent`, or `to_agent`. Hydrated handoff rows include `task_code`, `updated_at`, `expires_at`, and structured `context`.
-- **Create handoff**: Use `handoff-create` only when unfinished work needs context transfer. Include `from_agent`, optional `to_agent`, optional `task_code` or `task_id`, concise `summary`, and structured `context` with `next_steps`, `blockers`, or `remaining_work`.
-- **Close handoff**: Use `handoff-update` to move stale or consumed handoffs out of `pending`. Use `accepted` when consumed, `rejected` when declined, and `expired` when obsolete or only a completed-work summary.
-- **No completion handoff**: Do not create pending handoffs for completed-work summaries, release notes, validation notes, or archive records. Put those on `task-update` comments or durable memory.
-- **Claim task**: Use `task-claim` for task ownership. Do not encode claims in memory metadata.
-- **Inspect claims**: Use `claim-list` to inspect active ownership by repo or agent before reassigning work.
-- **Release claims**: Use `claim-release` to explicitly clear stale ownership when work is transferred or abandoned.
-- **Linkage**: Prefer `task_code` for human workflows and `task_id` when already hydrated.
-
-## 5. Reference Flow
-- Use the dashboard Reference tab as the canonical index of available tools, prompts, resources, schemas, and descriptions.
-- Keep prompt and tool definitions aligned with actual schemas so agents and UI users see the same workflow contract.
+
+## FSM — Memory Flow
+
+Entry=S0 → S1 → S2 → S3 → S4   Exit=maintained
+Guard: S(N) req S(N-1)✅
+
+S0 | navigate: memory-recap (overview) / memory-search (targeted) | — | pointer rows | —
+S1 | hydrate: memory-detail (id or code) before relying on content | S0✅ | full entry | —
+S2 | store: memory-store (durable only, tech tags, human title, aux in metadata) | — | stored | —
+S3 | maintain: memory-update / supersedes for changes; avoid duplicates | — | updated | —
+S4 | acknowledge: memory-acknowledge (used|irrelevant|contradictory) after code gen | code generated? | feedback | —
+
+## FSM — Standards Flow
+
+Entry=S0 → S1 → S2   Exit=done
+Guard: S(N) req S(N-1)✅
+
+S0 | search: standard-search mandatory before code edit/test/refactor/migrate (query, lang, stack, repo) | — | applicable | —
+S1 | apply precisely as implementation rules | S0✅ | compliant code | —
+S2 | store: standard-store (1 rule/entry, name, content, context, version, lang, stack, tags, scope) | — | new entry | —
+
+## FSM — Handoff & Claim Flow
+
+Entry=S0 → S1 → S2 → S3   Exit=resolved
+Guard: S(N) req S(N-1)✅
+
+S0 | check: handoff-list (status, from/to agent) + claim-list | — | active state | —
+S1 | ensure: NO handoff for completion summaries — use task-update or memory | — | valid | —
+S2 | create: handoff-create (unfinished work only, summary + structured context) / task-claim (ownership) | S0✅ | pending | claimed | —
+S3 | close: handoff-update (accepted|rejected|expired) / claim-release (stale ownership) | consumed | stale | resolved | —

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@vheins/local-memory-mcp",
-	"version": "0.14.6",
+	"version": "0.14.8",
 	"description": "MCP Local Memory Service for coding copilot agents",
 	"mcpName": "io.github.vheins/local-memory-mcp",
 	"type": "module",
@@ -55,6 +55,7 @@
 		"marked": "^18.0.0",
 		"proper-lockfile": "^4.1.2",
 		"qs": "^6.15.0",
+		"sweetalert2": "^11.26.25",
 		"zod": "^4.3.5"
 	},
 	"devDependencies": {