@vheins/local-memory-mcp 0.10.9 → 0.10.11
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -81,8 +81,8 @@ function loadServerInstructions() {
|
|
|
81
81
|
// src/mcp/capabilities.ts
|
|
82
82
|
var __dirname2 = path2.dirname(fileURLToPath2(import.meta.url));
|
|
83
83
|
var pkgVersion = "0.1.0";
|
|
84
|
-
if ("0.10.
|
|
85
|
-
pkgVersion = "0.10.
|
|
84
|
+
if ("0.10.11") {
|
|
85
|
+
pkgVersion = "0.10.11";
|
|
86
86
|
} else {
|
|
87
87
|
let searchDir = __dirname2;
|
|
88
88
|
for (let i = 0; i < 5; i++) {
|
package/dist/dashboard/server.js
CHANGED
package/dist/mcp/server.js
CHANGED
|
@@ -1,15 +1,31 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: task-memory-executor
|
|
3
3
|
description: Sequentially execute pending tasks for current repository.
|
|
4
|
-
arguments:
|
|
4
|
+
arguments:
|
|
5
|
+
- name: agent_identity
|
|
6
|
+
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.
|
|
7
|
+
required: false
|
|
5
8
|
agent: Task Executor
|
|
6
9
|
---
|
|
7
10
|
|
|
8
11
|
## 1. SYNC & FILTER
|
|
9
|
-
1. **Identify**:
|
|
12
|
+
1. **Identify**: Determine runner identity and repo context.
|
|
13
|
+
- Resolver priority: `agent_identity` argument -> auto session identity generated once per run.
|
|
14
|
+
- Auto identity format: `<runner>-<randomName>`.
|
|
15
|
+
- `<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.
|
|
16
|
+
- Use this identity for all `task-claim`, `task-update`, and handoff writes.
|
|
10
17
|
2. **List**: Call `task-list` ONCE for active tasks.
|
|
11
|
-
3. **
|
|
12
|
-
|
|
18
|
+
3. **Dependency-aware selection** (in `task-list` order):
|
|
19
|
+
- Process tasks in the order returned by `task-list`.
|
|
20
|
+
- A task is READY only if:
|
|
21
|
+
- status is `backlog` or `pending`, and
|
|
22
|
+
- `depends_on` is empty, or the dependency task exists and is `completed`, and
|
|
23
|
+
- `parent_id` is empty, or the parent task is `completed`.
|
|
24
|
+
- Keep non-ready tasks out of execution for now.
|
|
25
|
+
- If a task is blocked by unresolved dependency/parent, do not claim it and continue to the next ready task.
|
|
26
|
+
- If all active tasks are blocked, report blockers and stop execution loop.
|
|
27
|
+
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`.
|
|
28
|
+
5. **Audit**: Identify stale `in_progress` tasks (>30m no update). Hydrate via `task-detail` to check timestamps.
|
|
13
29
|
|
|
14
30
|
## Task Cache (MANDATORY)
|
|
15
31
|
- `task-detail` MUST be called at most ONCE per task
|
|
@@ -23,24 +39,25 @@ agent: Task Executor
|
|
|
23
39
|
- **Spawn Limit**: The total number of parallel sub-agents MUST NOT exceed 2. Each sub-agent executes EXACTLY ONE task at a time.
|
|
24
40
|
- **Fallback**: If the current agent CANNOT spawn sub-agents, it MUST execute tasks sequentially (exactly ONE concurrent task) until the queue is clear.
|
|
25
41
|
2. **Hydrate**: Fetch full context via `task-detail` for the assigned task.
|
|
26
|
-
3. **
|
|
27
|
-
4. **
|
|
28
|
-
5. **
|
|
29
|
-
6. **
|
|
30
|
-
7. **
|
|
42
|
+
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.
|
|
43
|
+
4. **Claim**: Use `task-claim` with `task_code` or `task_id` before implementation, and write the runner identity into claim metadata.
|
|
44
|
+
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.
|
|
45
|
+
6. **Research**: Call `memory-search` (Hybrid Search) and hydrate relevant results with `memory-detail`.
|
|
46
|
+
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.
|
|
47
|
+
8. **Execute**:
|
|
31
48
|
- **Trace**: Inspect logic, call sites, and docs. DO NOT infer from file presence.
|
|
32
49
|
- **Logic**: Implement per description/intent.
|
|
33
|
-
|
|
50
|
+
9. **Validate**:
|
|
34
51
|
- Trace path end-to-end.
|
|
35
52
|
- Run tests/linters/type-checks.
|
|
36
53
|
- Logic audit for all affected paths.
|
|
37
54
|
- **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.
|
|
38
|
-
|
|
55
|
+
10. **Finalize**:
|
|
39
56
|
- **Evidence**: `task-update` status to `completed` with detailed 'comment' (inspected files, verified logic, test results).
|
|
40
57
|
- **Cleanup**: Completing/canceling a task automatically releases active claims and expires linked pending handoffs.
|
|
41
58
|
- **Memory**: Store insights as `code_fact`/`pattern` via `memory-store`.
|
|
42
59
|
- **Standards**: Store durable implementation rules via `standard-store`, not generic memory.
|
|
43
|
-
- **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.
|
|
60
|
+
- **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.
|
|
44
61
|
- **Retrospective**: Invoke `learning-retrospective`.
|
|
45
62
|
- **Commit**: Atomic git commit. The commit message MUST follow this format: `type(scope): [task-code] your commit message`, followed by a detailed description:
|
|
46
63
|
```
|
|
@@ -50,7 +67,7 @@ agent: Task Executor
|
|
|
50
67
|
This ensures full traceability between code changes and project context.
|
|
51
68
|
- **GitHub Issue Traceability**: If task metadata contains a GitHub Issue reference, the commit message MUST also include the issue hashtag in `#123` format.
|
|
52
69
|
- **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.
|
|
53
|
-
|
|
70
|
+
11. **Repeat**: Claim next task from `task-list`.
|
|
54
71
|
|
|
55
72
|
## 3. BACKLOG MAINTENANCE
|
|
56
73
|
If active queue is empty:
|