musememory 2.1.0 โ 2.2.0
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.
- package/.agents/skills/muse-drift/SKILL.md +70 -0
- package/.agents/skills/muse-health/SKILL.md +56 -0
- package/.agents/skills/muse-mesh/SKILL.md +66 -0
- package/.agents/skills/muse-sync/SKILL.md +63 -0
- package/.agents/skills/muse-why/SKILL.md +60 -0
- package/README.md +94 -59
- package/dist/index.js +1257 -210
- package/package.json +1 -1
|
@@ -0,0 +1,70 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: muse-drift
|
|
3
|
+
description: Living Architecture Decision Records (ADRs) and bidirectional documentation-to-code drift auditor. Investigates architectural drift, records living decisions, and maintains doc-code harmony.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# ๐๏ธ Muse Drift (`muse-drift`)
|
|
7
|
+
|
|
8
|
+
> **When to use**: Execute when introducing architectural changes, making technology choices, refactoring system boundaries, or checking if documentation matches actual implementation.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## ๐ Execution Workflow
|
|
13
|
+
|
|
14
|
+
### Step 1: Audit Documentation $\longleftrightarrow$ Code Alignment
|
|
15
|
+
Call the `memory_drift_audit` MCP tool (or run `memory drift`):
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{
|
|
19
|
+
"dir": "."
|
|
20
|
+
}
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
The auditor classifies documented items across 6 mutually exclusive states:
|
|
24
|
+
- `DOCUMENTED`: Architectural guidelines described in docs/ADRs.
|
|
25
|
+
- `IMPLEMENTED`: Verified clean match between doc and code AST.
|
|
26
|
+
- `PARTIAL`: Incomplete implementation or missing export.
|
|
27
|
+
- `CONFLICTING`: Code directly contradicts documented architecture.
|
|
28
|
+
- `STALE`: Document references removed modules or legacy abstractions.
|
|
29
|
+
- `MISSING`: Code exists with zero architectural documentation.
|
|
30
|
+
|
|
31
|
+
### Step 2: Record Living Architecture Decision Records (ADRs)
|
|
32
|
+
When establishing or changing an architectural design decision, record a first-class ADR using `memory_adr_record`:
|
|
33
|
+
|
|
34
|
+
```json
|
|
35
|
+
{
|
|
36
|
+
"title": "Use SQLite WAL and Microsecond In-Process Memory Cache",
|
|
37
|
+
"decision": "All memory read/write operations must use in-process SQLite WAL mode with an L0 hot cache. No resident background daemons.",
|
|
38
|
+
"status": "accepted",
|
|
39
|
+
"context_and_drivers": [
|
|
40
|
+
"Zero-daemon constraint",
|
|
41
|
+
"Sub-millisecond latency requirement for CLI commands"
|
|
42
|
+
],
|
|
43
|
+
"consequences": {
|
|
44
|
+
"positive": ["Microsecond hot cache lookups", "Concurrent multi-process reads"],
|
|
45
|
+
"negative": ["Requires file locking management on write"]
|
|
46
|
+
},
|
|
47
|
+
"anchors": [
|
|
48
|
+
{ "kind": "file", "file_path": "src/store.ts" },
|
|
49
|
+
{ "kind": "file", "file_path": "src/cache.ts" }
|
|
50
|
+
]
|
|
51
|
+
}
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
### Step 3: Supersede Obsolete Decisions
|
|
55
|
+
When replacing an existing ADR, provide the `supersedes` parameter with the old ADR ID. The engine automatically marks the old decision as `superseded` and records full provenance in the audit ledger.
|
|
56
|
+
|
|
57
|
+
---
|
|
58
|
+
|
|
59
|
+
## ๐ป CLI Equivalents (Zero-MCP Fallback)
|
|
60
|
+
|
|
61
|
+
```bash
|
|
62
|
+
# Check repository documentation vs code drift
|
|
63
|
+
memory drift
|
|
64
|
+
|
|
65
|
+
# List all living Architecture Decision Records
|
|
66
|
+
memory adr list
|
|
67
|
+
|
|
68
|
+
# Record a new Architecture Decision Record
|
|
69
|
+
memory adr record "Decision Title" --decision "..." --positive "..." --negative "..."
|
|
70
|
+
```
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: muse-health
|
|
3
|
+
description: Unified 5-pillar project health gate governor. Audits store integrity, code anchors, doc/code alignment, negative sentry, and technical debt to enforce production hardening gates.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# ๐ฅ Muse Health (`muse-health`)
|
|
7
|
+
|
|
8
|
+
> **When to use**: Execute before completing features, opening pull requests, or cutting releases to verify repository hardening and architectural health.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## ๐ Execution Workflow
|
|
13
|
+
|
|
14
|
+
### Step 1: Run 5-Pillar Health Gate
|
|
15
|
+
Call the `muse_health` MCP tool (or execute `memory health`):
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{
|
|
19
|
+
"dir": "."
|
|
20
|
+
}
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
### Step 2: Evaluate 5-Pillar Scorecard
|
|
24
|
+
The engine evaluates 5 distinct hardening dimensions, outputting an overall letter grade (**AโF**) and a gate status (**PASS**, **WARN**, or **FAIL**):
|
|
25
|
+
|
|
26
|
+
1. **Pillar 1: Store Integrity**:
|
|
27
|
+
- Validates referential integrity, YAML schema conformances, bidirectional links, and missing target memory IDs.
|
|
28
|
+
2. **Pillar 2: Native Code Anchors**:
|
|
29
|
+
- Verifies whether files, functions, and symbols referenced by code anchors exist on disk, flagging drifted structural hashes or orphaned anchors.
|
|
30
|
+
3. **Pillar 3: Doc $\longleftrightarrow$ Code Alignment**:
|
|
31
|
+
- Audits living ADRs and documented invariants against actual code implementations, identifying conflicting, stale, or missing code.
|
|
32
|
+
4. **Pillar 4: Negative Anti-Pattern Sentry**:
|
|
33
|
+
- Checks if any known `DO_NOT_USE` patterns, regression bug fixes, or failed approaches have resurfaced in the active working tree.
|
|
34
|
+
5. **Pillar 5: Technical Debt & Workaround Sentry**:
|
|
35
|
+
- Detects unresolved `TODO`/`FIXME`/`HACK` comments, dangerous type casts (`as any`), and drifted architectural commitments.
|
|
36
|
+
|
|
37
|
+
### Step 3: Execute Actionable Remediation Checklist
|
|
38
|
+
If the gate status is **WARN** or **FAIL**, the engine outputs an ordered remediation checklist. Execute the prioritized items:
|
|
39
|
+
- Prune or re-link orphaned code anchors via `memory reconcile --prune`.
|
|
40
|
+
- Adhere to active ADR decisions.
|
|
41
|
+
- Resolve flagged type assertions or negative pattern recurrences.
|
|
42
|
+
|
|
43
|
+
---
|
|
44
|
+
|
|
45
|
+
## ๐ป CLI Equivalents (Zero-MCP Fallback)
|
|
46
|
+
|
|
47
|
+
```bash
|
|
48
|
+
# Full terminal health dashboard
|
|
49
|
+
memory health
|
|
50
|
+
|
|
51
|
+
# Output raw JSON for CI/CD gating (exits 1 on FAIL)
|
|
52
|
+
memory health --json
|
|
53
|
+
|
|
54
|
+
# Interactively audit and prune orphaned code anchors
|
|
55
|
+
memory reconcile --prune
|
|
56
|
+
```
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: muse-mesh
|
|
3
|
+
description: Multi-repo and monorepo cross-project knowledge mesh. Resolves memories across package boundaries, broadcasts shared invariants, and audits cross-package dependency contract integrity.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# ๐ธ๏ธ Muse Mesh (`muse-mesh`)
|
|
7
|
+
|
|
8
|
+
> **When to use**: Execute in monorepo environments (pnpm, npm, bun, lerna) or multi-repo projects when code spans multiple package boundaries or microservices.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## ๐ Execution Workflow
|
|
13
|
+
|
|
14
|
+
### Step 1: Discover Monorepo Topology
|
|
15
|
+
Call the `muse_mesh_status` MCP tool (or run `memory mesh overview`):
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{
|
|
19
|
+
"dir": "."
|
|
20
|
+
}
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Automatically inspects `pnpm-workspace.yaml`, `package.json` workspaces, or `lerna.json`, listing all detected package nodes and explicit mesh links.
|
|
24
|
+
|
|
25
|
+
### Step 2: Query Knowledge Across Package Boundaries
|
|
26
|
+
Call `muse_mesh_query` to search memories across all connected packages:
|
|
27
|
+
|
|
28
|
+
```json
|
|
29
|
+
{
|
|
30
|
+
"query": "authentication session store",
|
|
31
|
+
"scope": "all"
|
|
32
|
+
}
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Results include origin package provenance badges (e.g. `[mesh:@scope/core]`), preventing agents in frontend apps from hallucinating backend contract violations.
|
|
36
|
+
|
|
37
|
+
### Step 3: Broadcast Shared Invariants to All Packages
|
|
38
|
+
When establishing a monorepo-wide rule (e.g., "All microservices must use JWT v2 tokens"):
|
|
39
|
+
- Use `memory mesh propagate --constraint "Use JWT v2 tokens across all services"`.
|
|
40
|
+
- The invariant is atomically stamped into every package's `.memory/CURRENT.md`.
|
|
41
|
+
|
|
42
|
+
### Step 4: Audit Cross-Package Contracts
|
|
43
|
+
Call `muse_mesh_audit` (or run `memory mesh check`):
|
|
44
|
+
- Verifies that cross-package imports match valid export entrypoints.
|
|
45
|
+
- Flags drifted cross-repo code anchors.
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## ๐ป CLI Equivalents (Zero-MCP Fallback)
|
|
50
|
+
|
|
51
|
+
```bash
|
|
52
|
+
# Display monorepo mesh topology and linked packages
|
|
53
|
+
memory mesh overview
|
|
54
|
+
|
|
55
|
+
# Query memories across all monorepo packages
|
|
56
|
+
memory mesh query "database pool" --scope all
|
|
57
|
+
|
|
58
|
+
# Audit cross-package contract integrity
|
|
59
|
+
memory mesh check
|
|
60
|
+
|
|
61
|
+
# Propagate a critical security constraint across all packages
|
|
62
|
+
memory mesh propagate --constraint "Never expose database connection strings"
|
|
63
|
+
|
|
64
|
+
# Explicitly link an external sibling repository
|
|
65
|
+
memory mesh link ../external-service
|
|
66
|
+
```
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: muse-sync
|
|
3
|
+
description: Cross-agent knowledge sync and P2P gossip mesh protocol. Enables multi-agent swarms and isolated subagent teams to exchange insights, deduplicate knowledge, and resolve contradictions asynchronously.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# ๐ค Muse Sync (`muse-sync`)
|
|
7
|
+
|
|
8
|
+
> **When to use**: Execute when coordinating multi-agent workflows (e.g., frontend, backend, and test subagents), sharing verified bug fixes between worktrees, or consolidating swarm learnings.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## ๐ Execution Workflow
|
|
13
|
+
|
|
14
|
+
### Step 1: Check Peer Mesh & Vector Clock Status
|
|
15
|
+
Call the `muse_sync_status` MCP tool (or run `memory sync --status`):
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{
|
|
19
|
+
"dir": "."
|
|
20
|
+
}
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
Returns peer agent vector clocks, tracked packet generations, and pending incoming packets.
|
|
24
|
+
|
|
25
|
+
### Step 2: Broadcast a Sealed Knowledge Packet
|
|
26
|
+
To export recent confirmed memories, bug fixes, and active constraints into a portable packet:
|
|
27
|
+
|
|
28
|
+
```json
|
|
29
|
+
{
|
|
30
|
+
"project": "my-project",
|
|
31
|
+
"export_constraints": true
|
|
32
|
+
}
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
The engine creates a cryptographically sealed `SyncPacket` with:
|
|
36
|
+
- Whole-packet SHA-256 checksum verification.
|
|
37
|
+
- Vector clock causal sequencing (`sender_id` + logical sequence).
|
|
38
|
+
- Automatic Vibeguard secret inspection prior to packaging.
|
|
39
|
+
|
|
40
|
+
### Step 3: Synchronize via Zero-Daemon Shared Pool
|
|
41
|
+
Call `muse_sync_pool` (or run `memory sync --pool`):
|
|
42
|
+
- Broadcasts un-synced memories into `.memory/sync_pool/`.
|
|
43
|
+
- Ingests new packets dropped by peer subagents.
|
|
44
|
+
- Eliminates duplicate entries automatically.
|
|
45
|
+
- Flags semantic contradictions with mutual `conflict_ids` and triggers dispute resolution.
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
## ๐ป CLI Equivalents (Zero-MCP Fallback)
|
|
50
|
+
|
|
51
|
+
```bash
|
|
52
|
+
# View peer agent sync status and vector clocks
|
|
53
|
+
memory sync --status
|
|
54
|
+
|
|
55
|
+
# Broadcast confirmed memories to an exported packet
|
|
56
|
+
memory sync --broadcast --out ./shared_sync.json
|
|
57
|
+
|
|
58
|
+
# Ingest peer knowledge packet with secret scrubbing
|
|
59
|
+
memory sync --ingest ./shared_sync.json
|
|
60
|
+
|
|
61
|
+
# Bidirectionally sync with the shared filesystem gossip pool
|
|
62
|
+
memory sync --pool
|
|
63
|
+
```
|
|
@@ -0,0 +1,60 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: muse-why
|
|
3
|
+
description: Historical rationale and code evolution explainer. Synthesizes past ADRs, bug fixes, trade-offs, and invariants to explain why code was written the way it is before refactoring.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# ๐ค Muse Why (`muse-why`)
|
|
7
|
+
|
|
8
|
+
> **When to use**: Execute before modifying unfamiliar code, refactoring complex logic, or when encountering code patterns that look unusual or overly defensive.
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## ๐ Execution Workflow
|
|
13
|
+
|
|
14
|
+
### Step 1: Query Code Rationale ("Why is this code like this?")
|
|
15
|
+
Call the `muse_why` MCP tool:
|
|
16
|
+
|
|
17
|
+
```json
|
|
18
|
+
{
|
|
19
|
+
"target": "src/mcp.ts",
|
|
20
|
+
"symbol": "createServer",
|
|
21
|
+
"query": "Why do we filter tools dynamically by profile?"
|
|
22
|
+
}
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
The "Why" reasoner traces backwards through history and synthesizes:
|
|
26
|
+
1. **Governing Architecture Decisions**: Living ADRs that authorized or mandated this structure.
|
|
27
|
+
2. **Historical Bug Fixes**: Edge cases and production regressions that necessitated defensive checks.
|
|
28
|
+
3. **Accepted Trade-offs**: Documented compromises between performance, complexity, and safety.
|
|
29
|
+
4. **Timeless Constraints**: Core architectural laws that must remain invariant.
|
|
30
|
+
|
|
31
|
+
### Step 2: Audit Fragility & Bug Friction Clusters
|
|
32
|
+
Call the `muse_bug_clusters` MCP tool:
|
|
33
|
+
|
|
34
|
+
```json
|
|
35
|
+
{
|
|
36
|
+
"dir": "."
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Clusters recurring issues across 5 core root causes:
|
|
41
|
+
- `concurrency_race`: Race conditions, lock timeouts, async synchronization.
|
|
42
|
+
- `type_mismatch`: Dangerous type bypasses, undefined property access.
|
|
43
|
+
- `state_drift`: Out-of-sync cache entries, missing invalidation.
|
|
44
|
+
- `resource_leak`: Unclosed file descriptors, runaway memory consumption.
|
|
45
|
+
- `edge_case`: Boundary errors, empty array handling, malformed input.
|
|
46
|
+
|
|
47
|
+
### Step 3: Check Pre-Flight Code & Memory Impact
|
|
48
|
+
Call `muse_code_impact` (or run `memory code-impact <file> --symbol <sym>`) to check direct callers, affected test suites, and composite risk levels before editing.
|
|
49
|
+
|
|
50
|
+
---
|
|
51
|
+
|
|
52
|
+
## ๐ป CLI Equivalents (Zero-MCP Fallback)
|
|
53
|
+
|
|
54
|
+
```bash
|
|
55
|
+
# Query unified code & memory impact before editing
|
|
56
|
+
memory code-impact src/mcp.ts --symbol createServer
|
|
57
|
+
|
|
58
|
+
# View technical debt hotspots
|
|
59
|
+
memory tech-debt
|
|
60
|
+
```
|
package/README.md
CHANGED
|
@@ -13,7 +13,7 @@
|
|
|
13
13
|

|
|
14
14
|

|
|
15
15
|
|
|
16
|
-

|
|
17
17
|

|
|
18
18
|

|
|
19
19
|

|
|
@@ -24,23 +24,60 @@
|
|
|
24
24
|
|
|
25
25
|
---
|
|
26
26
|
|
|
27
|
-
## ๐ What's New in v2.0.0 (
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
-
|
|
31
|
-
-
|
|
32
|
-
-
|
|
33
|
-
-
|
|
34
|
-
-
|
|
35
|
-
-
|
|
36
|
-
-
|
|
37
|
-
-
|
|
27
|
+
## ๐ What's New in v2.2.0, v2.1.0 & v2.0.0 (Impact Analysis, PR Context, Reconciler & Telemetry)
|
|
28
|
+
|
|
29
|
+
### ๐ฅ v2.2.0 Flagship Additions: Code Impact, PR Context & Cognitive Governance
|
|
30
|
+
- **๐ฅ Unified Code & Memory Impact Analysis (`memory code-impact`)**:
|
|
31
|
+
- Synthesizes AST code callers, affected test suites, linked memories, living ADRs, negative anti-patterns, and active constraints.
|
|
32
|
+
- Computes a composite Risk Score (0โ100) and Risk Level (`LOW`, `MEDIUM`, `HIGH`, `CRITICAL`) with pre-flight actionable recommendations before modifying code.
|
|
33
|
+
- Available via CLI `memory code-impact <file> [--symbol <name>]` and MCP tool `muse_code_impact`.
|
|
34
|
+
- **๐ PR & Change Context Generator (`memory pr-context`)**:
|
|
35
|
+
- Automatically analyzes git diff against base branch, linking touched code anchors, respected ADRs, active project constraints, and blast radius.
|
|
36
|
+
- Generates rich GitHub-ready Markdown pull request descriptions with verification checklists and merge promotion proposals.
|
|
37
|
+
- Available via CLI `memory pr-context [--base main] [--out <file>]` and MCP tool `muse_pr_context`.
|
|
38
|
+
- **โ Interactive Code Anchor Reconciler (`memory reconcile`)**:
|
|
39
|
+
- Audits code anchors across memories, pruning dead anchors, refreshing structural hashes for drifted code, and marking abandoned memories stale.
|
|
40
|
+
- Supports `--dry-run`, `--prune`, `--mark-stale`, `--update-hashes`, and MCP tool `muse_reconcile_anchors`.
|
|
41
|
+
- **โก Repeatable Speed, Quality & ROI Benchmark Suite (`memory benchmark`)**:
|
|
42
|
+
- Measures microsecond in-process cache reads (P50 < 4ยตs), SQLite FTS5 BM25 search, knapsack token packing, contradiction rates, and compression ratios in a clean ASCII scoreboard.
|
|
43
|
+
- **๐ง Complete Agent Skills Roster for v2.0โv2.2**:
|
|
44
|
+
- Added `.agents/skills/muse-health`, `muse-drift`, `muse-why`, `muse-sync`, and `muse-mesh`.
|
|
45
|
+
|
|
46
|
+
### ๐ v2.1.0 Flagship Additions: Multi-Agent & Mesh Orchestration
|
|
47
|
+
- **๐ค Cross-Agent Knowledge Sync & P2P Gossip Protocol (R14)**:
|
|
48
|
+
- Cryptographically sealed, portable `SyncPacket` engine with whole-packet SHA-256 integrity verification and vector clock causal ordering.
|
|
49
|
+
- Zero-daemon shared filesystem gossip pool (`.memory/sync_pool/`) allowing autonomous subagent teams (frontend, backend, test) to exchange insights asynchronously.
|
|
50
|
+
- Ingestion deduplication, inline Vibeguard secret scrubbing, and semantic contradiction tagging with mutual `conflict_ids`.
|
|
51
|
+
- CLI `memory sync` command suite & 4 MCP tools (`muse_sync_broadcast`, `muse_sync_ingest`, `muse_sync_status`, `muse_sync_pool`).
|
|
52
|
+
- **๐ Full Web Observability Studio (`memory studio`) (R15)**:
|
|
53
|
+
- Embedded zero-dependency visual web dashboard (`memory studio` or `memory ui`) with interactive control plane.
|
|
54
|
+
- Live 5-pillar health scorecard (AโF letter grade, PASS/WARN/FAIL gate status, and prioritized remediation checklist).
|
|
55
|
+
- Interactive ADR registry and bidirectional documentation $\longleftrightarrow$ code drift inspector.
|
|
56
|
+
- Historical "Why" reasoner query interface, recurring bug friction heatmap, and debt scanner.
|
|
57
|
+
- Real-time P2P gossip mesh status and interactive broadcast/shared pool sync controls.
|
|
58
|
+
- **๐ธ๏ธ Multi-Repo & Monorepo Cross-Project Mesh (R16)**:
|
|
59
|
+
- Passive automatic monorepo discovery across `pnpm`, `npm`, `bun`, `lerna`, and multi-repo sibling directories.
|
|
60
|
+
- Cross-project memory query resolver (`resolveMeshMemories`) with origin package provenance tags (`[mesh:@scope/package]`).
|
|
61
|
+
- Shared invariant and working constraint propagation (`propagateConstraintToMesh`) broadcasting critical security rules across all packages.
|
|
62
|
+
- Cross-package dependency contract and entrypoint export auditor (`auditMeshContracts`) validating cross-package imports and cross-repo code anchors.
|
|
63
|
+
- CLI `memory mesh` suite & 4 MCP tools (`muse_mesh_status`, `muse_mesh_query`, `muse_mesh_audit`, `muse_mesh_link`).
|
|
64
|
+
|
|
65
|
+
### ๐ง v2.0.0 Major Cognitive Overhaul:
|
|
66
|
+
- **๐ฅ Unified 5-Pillar Project Health Gate (`memory health` / `muse_health`)**: Single-call architectural audit across Store Integrity, Code Anchors, Doc-Code Alignment, Negative Sentry, and Technical Debt.
|
|
67
|
+
- **๐ค Autonomous Engineering Cognition & "Why" Reasoner (`muse_why`)**: Reconstructs historical code evolution through past bug workarounds, accepted trade-offs, and timeless rules before refactoring.
|
|
68
|
+
- **๐๏ธ First-Class Architecture Decision Records (`memory adr` / `memory_adr_record`)**: Living, queryable ADR entities with options considered, consequences, native code anchors, and supersession lineage.
|
|
69
|
+
- **๐ Bidirectional Documentation $\longleftrightarrow$ Code Drift Engine (`memory_drift_audit`)**: Continuously verifies alignment across 6 states (`DOCUMENTED`, `IMPLEMENTED`, `PARTIAL`, `CONFLICTING`, `STALE`, `MISSING`).
|
|
70
|
+
- **๐ฏ Flagship Unified Context Orchestrator (`muse_context`)**: Single-call fused context injection with knapsack token budget packing.
|
|
71
|
+
- **โ๏ธ Task-Focused MCP Profiles**: Dynamic role-based tool filtering (`core`, `coding`, `debugging`, `review`, `architecture`, `maintenance`).
|
|
72
|
+
- **โ Native Structural Code Anchors (`src/anchors/`)**: Line-independent structural SHA-256 hashing insensitive to spacing/comments.
|
|
73
|
+
- **๐ช Scoped Promotion & Extended Archival Lifecycle (`src/promotion/`)**: 3-tier promotion ladder (`local` $\rightarrow$ `project` $\rightarrow$ `global`), 5ร repeated success policy, universal generalization, and `active` $\rightarrow$ `cold` $\rightarrow$ `dormant` $\rightarrow$ `archived` lifecycle with query rehydration.
|
|
74
|
+
- **โก Hot Query Cache & SQLite WAL Optimization**: Microsecond memory lookups and high-throughput concurrent I/O.
|
|
38
75
|
|
|
39
76
|
---
|
|
40
77
|
|
|
41
78
|
## ๐ Table of Contents
|
|
42
79
|
|
|
43
|
-
- [๐ What's New in v2.0.0](#-whats-new-in-v200-autonomous-cognitive-engine-
|
|
80
|
+
- [๐ What's New in v2.1.0 & v2.0.0](#-whats-new-in-v210--v200-autonomous-cognitive-engine-p2p-sync--monorepo-mesh)
|
|
44
81
|
- [๐ก What is Muse Memory? (TL;DR)](#-what-is-muse-memory-tldr)
|
|
45
82
|
- [โจ Key Feature Highlights](#-key-feature-highlights)
|
|
46
83
|
- [โก Quick Start & Installation](#-quick-start--installation)
|
|
@@ -62,36 +99,43 @@ Most AI chatbots and coding assistants have **"goldfish memory"**: every time yo
|
|
|
62
99
|
**Muse Memory gives your AI assistants a persistent, self-organizing cognitive notebook directly on your machine.**
|
|
63
100
|
|
|
64
101
|
```
|
|
65
|
-
|
|
66
|
-
โ
|
|
67
|
-
โ
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
โ
|
|
72
|
-
โ
|
|
73
|
-
โ
|
|
74
|
-
โ โ
|
|
75
|
-
โ โ
|
|
76
|
-
โ
|
|
77
|
-
โ
|
|
78
|
-
โ โ
|
|
79
|
-
โ โ(
|
|
80
|
-
โ
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
โ
|
|
85
|
-
|
|
86
|
-
โ
|
|
87
|
-
|
|
88
|
-
โ
|
|
89
|
-
โ
|
|
90
|
-
โ
|
|
91
|
-
โ
|
|
92
|
-
โ
|
|
93
|
-
โ
|
|
94
|
-
|
|
102
|
+
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
103
|
+
โ AI Agents, Subagent Pods & Autonomous Swarms โ
|
|
104
|
+
โ (Claude Code, Cursor, Antigravity, Windsurf, Codex, CLI) โ
|
|
105
|
+
โโโโโโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโ
|
|
106
|
+
โ MCP stdio / Terminal CLI โ Local HTTP
|
|
107
|
+
โโโโโโโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโ
|
|
108
|
+
โ Muse Memory Core Engine โ
|
|
109
|
+
โ โ
|
|
110
|
+
โ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
111
|
+
โ โ Unified Context & โ โ 5-Pillar Health Gate โ โ Autonomous Cognition โ โ
|
|
112
|
+
โ โ Knapsack Retrieval โ โ & ADR Drift Sentry โ โ & "Why" Reasoner โ โ
|
|
113
|
+
โ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
114
|
+
โ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
115
|
+
โ โ P2P Gossip Sync โ โ Monorepo Workspace โ โ Web Observability โ โ
|
|
116
|
+
โ โ (Vector Clock Mesh) โ โ Cross-Project Mesh โ โ Studio (memory studio)โ โ
|
|
117
|
+
โ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
118
|
+
โ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
119
|
+
โ โ Vibeguard Credential โ โ Dynamic Code Anchors โ โ Universal Migrator โ โ
|
|
120
|
+
โ โ Secret Defense โ โ & Structural Hashes โ โ (29 Engines) โ โ
|
|
121
|
+
โ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโ โโโโโโโโโโโโโโโโโโโโโโโโโ โ
|
|
122
|
+
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโฌโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
123
|
+
โ Atomic SQLite & File I/O
|
|
124
|
+
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโผโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
125
|
+
โ Dual-Scope Storage Engine (.memory/) โ
|
|
126
|
+
โ โ
|
|
127
|
+
โ .memory/ โ
|
|
128
|
+
โ โโโ memory.db # Primary SQLite database (WAL + FTS5 BM25) โ
|
|
129
|
+
โ โโโ CURRENT.md # Real-time working constraints & session handoffs โ
|
|
130
|
+
โ โโโ USER.md # Persona archetypes & working style preferences โ
|
|
131
|
+
โ โโโ sync_pool/ # Zero-daemon shared P2P gossip pool drop folder โ
|
|
132
|
+
โ โโโ mesh_links.json # Explicit multi-repo cross-project mesh links โ
|
|
133
|
+
โ โโโ sync_peers.json # Peer agent vector clock causal tracking ledger โ
|
|
134
|
+
โ โโโ audit.jsonl # Append-only operational audit & compliance trail โ
|
|
135
|
+
โ โโโ memories/ # Dual-persisted human-readable YAML mirror โ
|
|
136
|
+
โ โโโ m_1700000001000_auth.yaml โ
|
|
137
|
+
โ โโโ m_1700000002000_mesh.yaml โ
|
|
138
|
+
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
95
139
|
```
|
|
96
140
|
|
|
97
141
|
---
|
|
@@ -169,20 +213,6 @@ memory upgrade
|
|
|
169
213
|
npx musememory upgrade
|
|
170
214
|
```
|
|
171
215
|
|
|
172
|
-
```
|
|
173
|
-
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
174
|
-
โ ๐ง MUSE MEMORY ยท SYSTEM LEVEL-UP & RECOVERY MATRIX โ
|
|
175
|
-
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
|
|
176
|
-
|
|
177
|
-
[โโโโโโโโโโโโโโโโโโโโ] 100% โ LEVEL 1: Vibeguard Security & Credential Audit [OK]
|
|
178
|
-
[โโโโโโโโโโโโโโโโโโโโ] 100% โ LEVEL 2: Package Manager Sync (bun/npm) [OK]
|
|
179
|
-
[โโโโโโโโโโโโโโโโโโโโ] 100% โ LEVEL 3: Synaptic Storage & Schema Alignment [OK]
|
|
180
|
-
[โโโโโโโโโโโโโโโโโโโโ] 100% โ LEVEL 4: 80+ Agent Platforms & Skills Auto-Wiring [OK]
|
|
181
|
-
[โโโโโโโโโโโโโโโโโโโโ] 100% โ LEVEL 5: Cognitive Ascendance Complete [OK]
|
|
182
|
-
|
|
183
|
-
๐ [LEVEL-UP COMPLETE] Muse Memory is now fully armed and up to date!
|
|
184
|
-
```
|
|
185
|
-
|
|
186
216
|
#### What `memory upgrade` automatically handles:
|
|
187
217
|
1. **Package Manager Auto-Detection**: Detects whether your workstation runs `bun`, `npm`, `pnpm`, or `yarn` and pulls the latest published binary.
|
|
188
218
|
2. **Self-Healing Storage Repair**: Recovers missing `.memory/`, `CURRENT.md` constraints, or `USER.md` persona files if corrupted or deleted.
|
|
@@ -521,13 +551,18 @@ memory <command> [arguments] [flags] # alias: musememory
|
|
|
521
551
|
<details>
|
|
522
552
|
<summary><b>๐ง Shipped Agent Skills (<code>.agents/skills/</code>)</b> โ <i>Click to expand</i></summary>
|
|
523
553
|
|
|
524
|
-
Muse Memory ships with
|
|
554
|
+
Muse Memory ships with 11 turnkey Agent Skills designed for coding agents (Claude Code, Cursor, Antigravity, OpenCode, Codex, Gemini CLI, etc.) under `.agents/skills/`:
|
|
525
555
|
|
|
526
556
|
| Skill | Trigger Phase | Core Agent Responsibility |
|
|
527
557
|
| :--- | :--- | :--- |
|
|
528
558
|
| [`muse-ground`](.agents/skills/muse-ground/SKILL.md) | **Session Start** | Retrieves Top-$K$ relevant memories, active `USER.md` persona profile, and `CURRENT.md` constraints before writing code. |
|
|
529
559
|
| [`muse-capture`](.agents/skills/muse-capture/SKILL.md) | **During Fixes & Refactors** | Captures atomic fix/architecture memories, validates evidence, runs Vibeguard secret scan, and supersedes obsolete knowledge. |
|
|
530
560
|
| [`muse-current`](.agents/skills/muse-current/SKILL.md) | **Invariants & Handoffs** | Synchronizes hard constraints into `.memory/CURRENT.md` and persists structured handoffs across context resets. |
|
|
561
|
+
| [`muse-health`](.agents/skills/muse-health/SKILL.md) | **Hardening Gates & PRs** | Evaluates 5-pillar architectural health (store, anchors, doc/code alignment, negative sentry, debt) and outputs remediation checklists. |
|
|
562
|
+
| [`muse-drift`](.agents/skills/muse-drift/SKILL.md) | **System Architecture & ADRs** | Audits documentation $\longleftrightarrow$ code drift across 6 states, records living ADRs, and supersedes legacy architectural decisions. |
|
|
563
|
+
| [`muse-why`](.agents/skills/muse-why/SKILL.md) | **Refactoring & Historical Context** | Reconstructs historical rationale, synthesizes past bug fixes and accepted trade-offs, and audits recurring bug friction clusters. |
|
|
564
|
+
| [`muse-sync`](.agents/skills/muse-sync/SKILL.md) | **Multi-Agent & Swarm Gossip** | Coordinates cross-agent knowledge sync with whole-packet SHA-256 integrity, vector clocks, and P2P gossip mesh pool. |
|
|
565
|
+
| [`muse-mesh`](.agents/skills/muse-mesh/SKILL.md) | **Monorepo & Multi-Repo Mesh** | Discovers monorepo workspaces, resolves cross-package memories with badges, and propagates shared security constraints. |
|
|
531
566
|
| [`muse-graph`](.agents/skills/muse-graph/SKILL.md) | **AST Code Investigation** | Indexes `.codegraph`/`.graphify` symbols and queries symbol-matching decisions with `+0.2` graph overlap bonus. |
|
|
532
567
|
| [`muse-wiki`](.agents/skills/muse-wiki/SKILL.md) | **Knowledge Compounding** | Compiles confirmed memories into Obsidian-compatible Markdown pages (`[[wikilinks]]`) and entity co-occurrence graphs. |
|
|
533
568
|
| [`muse-brief`](.agents/skills/muse-brief/SKILL.md) | **Daily Hygiene & Loops** | Generates morning briefings, tracks 90/180-day staleness decay, and surfaces unresolved transcript commitments. |
|
|
@@ -565,7 +600,7 @@ memory user set "- Prefers TypeScript, Bun, and ultra terse responses"
|
|
|
565
600
|
|
|
566
601
|
```bash
|
|
567
602
|
bun install
|
|
568
|
-
bun test #
|
|
603
|
+
bun test # 497 passed across 84 test files (2190 assertions)
|
|
569
604
|
bun run typecheck # 0 static type errors
|
|
570
605
|
bun run build # Clean bundled distribution build (dist/index.js)
|
|
571
606
|
```
|