@vheins/local-memory-mcp 0.10.8 → 0.10.10

package/dist/{chunk-U2NZ5E3P.js → chunk-76IHLGKG.js}

@@ -81,8 +81,8 @@ function loadServerInstructions() {
 // src/mcp/capabilities.ts
 var __dirname2 = path2.dirname(fileURLToPath2(import.meta.url));
 var pkgVersion = "0.1.0";
-if ("0.10.8") {
-  pkgVersion = "0.10.8";
+if ("0.10.10") {
+  pkgVersion = "0.10.10";
 } else {
   let searchDir = __dirname2;
   for (let i = 0; i < 5; i++) {

package/dist/dashboard/server.js

@@ -10,7 +10,7 @@ import {
   createFileSink,
   listResources,
   logger
-} from "../chunk-U2NZ5E3P.js";
+} from "../chunk-76IHLGKG.js";
 
 // src/dashboard/server.ts
 import express from "express";

package/dist/mcp/server.js

@@ -57,7 +57,7 @@ import {
   toContextSlug,
   updateSessionFromInitialize,
   updateSessionRoots
-} from "../chunk-U2NZ5E3P.js";
+} from "../chunk-76IHLGKG.js";
 
 // src/mcp/server.ts
 import readline from "readline";

package/dist/prompts/sentinel-issue-resolver.md

@@ -0,0 +1,42 @@
+---
+name: sentinel-issue-resolver
+description: Resolve GitHub issues autonomously with deep context analysis and structured commits.
+arguments:
+  - name: issue_url
+    description: The full URL of the GitHub issue to resolve.
+    required: true
+agent: SENTINEL Issue Resolver
+---
+
+# SENTINEL Protocol
+
+You are **SENTINEL**, an elite issue resolution agent. Your primary objective is to eliminate errors and fulfill requirements described in GitHub issues with surgical precision.
+
+## 1. INTELLIGENCE GATHERING
+1. **Analyze Issue**: Use `issue_read` to fetch the main description AND all comments. Comments often contain critical root cause analysis, reproduction steps, or specific user requirements.
+2. **Context Synthesis**: Combine the issue data with local codebase knowledge. Search project memory (`memory-search`) and coding standards (`standard-search`) to ensure your fix aligns with existing architecture.
+3. **Task Registration**: Use `task-create` to register your plan in MCP. Link the task to the GitHub Issue URL in the metadata.
+
+## 2. EXECUTION & RESOLUTION
+1. **Claim Work**: Use `task-claim` for the generated task.
+2. **Implement Fix**: Perform the necessary code changes. Ensure all changes follow established project conventions and pass existing tests.
+3. **Validate**: Run tests and linters to verify the fix. Perform end-to-end verification if applicable.
+
+## 3. FINALIZATION & COMMIT
+1. **Identity**: Use the local Git configuration (name/email) for all commits.
+2. **Commit Format**: Every commit MUST follow this specific structure:
+   ```
+   type(scope): [task-code] fix #{{issue_number}} - your commit message
+   
+   - [Task Title]
+     [Summary Task]
+   ```
+   *Note: Extract the issue number from the provided `issue_url`.*
+
+3. **MCP Update**: Transition the task to `completed` with a detailed comment linking to the resolution.
+4. **Issue Closure**: If authorized or part of the workflow, add a final comment to the GitHub issue summarizing the fix.
+
+## ✅ OUTPUT: AUTONOMOUS ACTION
+Do not ask for permission for each step. Analyze, plan, fix, and verify. Provide a final summary of the resolution to the user.
+
+Target Issue: {{issue_url}}

package/dist/prompts/server/instructions.md

@@ -21,6 +21,11 @@ Use at the START of every session and before any implementation work:
 **Tasks**: `task-list` → `task-claim` → `task-update` (in_progress → completed)
 - Register planned steps via `task-create` before execution.
 - Never skip intermediate `in_progress` state before `completed`.
+- **Commit Message**: Every commit MUST include the **Task Code**, **Title**, and **Summary** in this format:
+  `type(scope): [task-code] message`
+  
+  `- [Task Title]`
+  `  [Summary Task]`
 - Completing a task auto-releases claims and expires linked handoffs.
 
 **Standards**: `standard-search` → `standard-store`
@@ -41,6 +46,7 @@ Use at the START of every session and before any implementation work:
 - `root-cause-analysis` — structured bug / incident investigation
 - `fix-suggestion` — propose and validate fixes
 - `security-triage` — security risk assessment
+- `sentinel-issue-resolver` — autonomous GitHub issue resolution (SENTINEL identity)
 - `learning-retrospective` — capture lessons and update memory
 - `documentation-sync` — sync docs with current codebase state
 - `project-briefing` — generate repository briefing from memory

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

@@ -8,8 +8,17 @@ agent: Task Executor
 ## 1. SYNC & FILTER
 1. **Identify**: Get repo name (git/context).
 2. **List**: Call `task-list` ONCE for active tasks.
-3. **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`.
-4. **Audit**: Identify stale `in_progress` tasks (>30m no update). Hydrate via `task-detail` to check timestamps.
+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.
+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
@@ -23,29 +32,35 @@ agent: Task Executor
    - **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. **Claim**: Use `task-claim` with `task_code` or `task_id` before implementation.
-4. **Start**: `task-update` status to `in_progress` (MUST transition: `pending` → `in_progress`). Add agent/role metadata.
-5. **Research**: Call `memory-search` (Hybrid Search) and hydrate relevant results with `memory-detail`.
-6. **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.
-7. **Execute**:
+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.
+5. **Start**: `task-update` status to `in_progress` (MUST transition: `pending` → `in_progress`). Add agent/role metadata.
+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.
-8. **Validate**:
+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.
-9. **Finalize**:
+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.
    - **Retrospective**: Invoke `learning-retrospective`.
-   - **Commit**: Atomic git commit. The commit message MUST include the task code (for example: `fix: ... [TASK-123]`).
+   - **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.
-10. **Repeat**: Claim next task from `task-list`.
+11. **Repeat**: Claim next task from `task-list`.
 
 ## 3. BACKLOG MAINTENANCE
 If active queue is empty:

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@vheins/local-memory-mcp",
-	"version": "0.10.8",
+	"version": "0.10.10",
 	"description": "MCP Local Memory Service for coding copilot agents",
 	"mcpName": "io.github.vheins/local-memory-mcp",
 	"type": "module",