@vheins/local-memory-mcp 0.9.3 → 0.9.4

package/dist/dashboard/server.js

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

package/dist/mcp/server.js

@@ -54,7 +54,7 @@ import {
   setLogLevel,
   updateSessionFromInitialize,
   updateSessionRoots
-} from "../chunk-KQHMJLUV.js";
+} from "../chunk-LFMZUZGW.js";
 
 // src/mcp/server.ts
 import readline from "readline";

package/dist/prompts/csl-from-docs.md

@@ -21,23 +21,25 @@ Goal:
 - If the path is a file:
   - Use the `read_file` tool to retrieve the content of the file.
   - Extract source-backed coding standards from the content.
-  - Produce one atomic CSL entry per distinct rule, constraint, prohibition, or required workflow.
+  - For each extracted rule, use the `standard-search` tool to check if a similar rule already exists (match by name or core instruction).
+  - Produce one atomic CSL entry per distinct rule that DOES NOT already exist.
   - Each entry must be ready for the `standard-store` tool shape: name, content, parent_id, context, version, language, stack, tags, metadata, repo, is_global.
 
 Atomic entry rules:
 - One entry = one rule. Split bundled guidance into separate entries.
+- DO NOT emit duplicates. If `standard-search` returns a high-confidence match, skip the entry or update it if the new source is more authoritative.
 - Use parent/child only for genuine hierarchy: parent = umbrella principle, child = narrower enforceable specialization.
 - Keep content concise, imperative, and implementation-relevant.
 - ALWAYS include relevant code examples or snippets from the source that illustrate or enforce the rule. Do NOT discard code blocks.
 - Preserve the source meaning without inventing requirements.
 - Ignore boilerplate, non-normative text, or metadata noise. Do NOT ignore code examples.
-- Do not emit duplicates or near-duplicates.
 - Do not infer version, language, stack, or scope unless the source makes them explicit.
 - Use metadata to preserve provenance, including the original file path and a short evidence_excerpt for each entry.
 
 Output contract:
 - If tool calls are available:
-  - Emit `standard-store` calls for every accepted entry found across all processed files.
+  - First, emit `standard-search` calls to verify existing data.
+  - Then, emit `standard-store` calls for every unique/new accepted entry.
   - When parent/child hierarchy exists, emit the parent first, then emit children with `parent_id` referencing the created parent standard ID.
 - If tool calls are unavailable, return a JSON object with:
   - `standards`: Array of `standard-store`-compatible payloads.

package/dist/prompts/csl-scrapper.md

@@ -15,25 +15,27 @@ Current repo: {{current_repo}}
 Goal:
 - Use the web_fetch tool (if available) to retrieve the content of the provided Source URL.
 - Extract only source-backed coding standards from the documentation.
-- Produce one atomic CSL entry per distinct rule, constraint, prohibition, or required workflow.
+- For each extracted rule, use the `standard-search` tool to check if a similar rule already exists (match by name or core instruction).
+- Produce one atomic CSL entry per distinct rule that DOES NOT already exist.
 - Each entry must be ready for the standard-store tool shape: name, content, parent_id, context, version, language, stack, tags, metadata, repo, is_global.
 - Identify documentation navigation menus (e.g., sidebars, index pages) containing links to related sub-pages. If present, create iterative scraping tasks for these sub-pages.
 - Detect documentation hierarchy when a page contains an umbrella rule with narrower sub-rules. In that case, emit one parent entry plus child entries linked with `parent_id`.
 
 Atomic entry rules:
 - One entry = one rule. Split bundled guidance into separate entries.
+- DO NOT emit duplicates. If `standard-search` returns a high-confidence match, skip the entry or update it if the new source is more authoritative.
 - Use parent/child only for genuine hierarchy: parent = umbrella principle, child = narrower enforceable specialization.
 - Keep content concise, imperative, and implementation-relevant.
 - ALWAYS include relevant code examples or snippets from the source that illustrate or enforce the rule. Do NOT discard code blocks.
 - Preserve the source meaning without inventing requirements.
 - Ignore marketing copy, release notes, and changelog noise. Do NOT ignore code examples.
-- Do not emit duplicates or near-duplicates.
 - Do not infer version, language, stack, or scope unless the source makes them explicit.
 - Use metadata to preserve provenance, including the source_url and a short evidence_excerpt for each entry.
 
 Output contract:
 - If tool calls are available:
-  - Emit one `standard-store` call per accepted entry.
+  - First, emit `standard-search` calls to verify existing data.
+  - Emit one `standard-store` call per unique/new accepted entry.
   - When parent/child hierarchy exists, emit the parent first, then emit children with `parent_id` referencing the created parent standard ID.
   - Emit one `task-create` call for each discovered documentation sub-page URL. The task title should be "Scrape: [URL]" and the description should instruct to use the `csl-scrapper` prompt for that URL.
 - If tool calls are unavailable, return a JSON object with:

package/package.json

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