amalfa 1.0.2 → 1.0.3
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/package.json +1 -1
- package/src/cli.ts +1 -1
- package/docs/AGENT-METADATA-PATTERNS.md +0 -1021
- package/docs/AGENT_PROTOCOLS.md +0 -28
- package/docs/ARCHITECTURAL_OVERVIEW.md +0 -123
- package/docs/BENTO_BOXING_DEPRECATION.md +0 -281
- package/docs/Bun-SQLite.html +0 -464
- package/docs/COMMIT_GUIDELINES.md +0 -367
- package/docs/CONFIG_E2E_VALIDATION.md +0 -147
- package/docs/CONFIG_UNIFICATION.md +0 -187
- package/docs/CONFIG_VALIDATION.md +0 -103
- package/docs/DEVELOPER_ONBOARDING.md +0 -36
- package/docs/Graph and Vector Database Best Practices.md +0 -214
- package/docs/LEGACY_DEPRECATION.md +0 -174
- package/docs/MCP_SETUP.md +0 -317
- package/docs/PERFORMANCE_BASELINES.md +0 -88
- package/docs/QUICK_START_MCP.md +0 -168
- package/docs/REPOSITORY_CLEANUP_SUMMARY.md +0 -261
- package/docs/SESSION-2026-01-06-METADATA-PATTERNS.md +0 -346
- package/docs/SETUP.md +0 -464
- package/docs/SETUP_COMPLETE.md +0 -464
- package/docs/VISION-AGENT-LEARNING.md +0 -1242
- package/docs/_current-config-status.md +0 -93
- package/docs/edge-generation-methods.md +0 -57
- package/docs/elevator-pitch.md +0 -118
- package/docs/graph-and-vector-database-playbook.html +0 -480
- package/docs/hardened-sqlite.md +0 -85
- package/docs/headless-knowledge-management.md +0 -79
- package/docs/john-kaye-flux-prompt.md +0 -46
- package/docs/keyboard-shortcuts.md +0 -80
- package/docs/opinion-proceed-pattern.md +0 -29
- package/docs/polyvis-nodes-edges-schema.md +0 -77
- package/docs/protocols/lab-protocol.md +0 -30
- package/docs/reaction-iquest-loop-coder.md +0 -46
- package/docs/services.md +0 -60
- package/docs/sqlite-wal-readonly-trap.md +0 -228
- package/docs/strategy/css-architecture.md +0 -40
- package/docs/test-document-cycle.md +0 -83
- package/docs/test_lifecycle_E2E.md +0 -4
- package/docs/the-bicameral-graph.md +0 -83
- package/docs/user-guide.md +0 -70
- package/docs/vision-helper.md +0 -53
|
@@ -1,83 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
title: Test Document for Full Cycle Verification
|
|
3
|
-
date: 2025-12-17
|
|
4
|
-
tags: [test, verification, integration]
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Test Document for Full Cycle Verification
|
|
8
|
-
|
|
9
|
-
This document tests the complete PolyVis ingestion and processing cycle.
|
|
10
|
-
|
|
11
|
-
## Purpose
|
|
12
|
-
|
|
13
|
-
Verify that all systems work together:
|
|
14
|
-
1. **Dev Server** - CSS/JS watching and web serving
|
|
15
|
-
2. **Daemon** - File watching and automatic ingestion
|
|
16
|
-
3. **MCP Server** - API for AI tool integration
|
|
17
|
-
|
|
18
|
-
## Test Scenario
|
|
19
|
-
|
|
20
|
-
When this document is saved:
|
|
21
|
-
- Daemon detects the change within 2 seconds
|
|
22
|
-
- Triggers debounced ingestion
|
|
23
|
-
- Document is parsed and normalized
|
|
24
|
-
- Entities are extracted
|
|
25
|
-
- Embeddings are generated
|
|
26
|
-
- Graph nodes and edges are created
|
|
27
|
-
- Database is updated
|
|
28
|
-
- MCP server can query the new data
|
|
29
|
-
|
|
30
|
-
## Expected Behavior
|
|
31
|
-
|
|
32
|
-
### Daemon Log Output:
|
|
33
|
-
```
|
|
34
|
-
📝 Change detected: docs/test-document-cycle.md (change)
|
|
35
|
-
🔄 Debounce settle. Starting Batch Ingestion (1 files)...
|
|
36
|
-
✅ Batch Ingestion Complete.
|
|
37
|
-
```
|
|
38
|
-
|
|
39
|
-
### Database Updates:
|
|
40
|
-
- New node created for this document
|
|
41
|
-
- Embeddings generated for content
|
|
42
|
-
- Edges created to related concepts
|
|
43
|
-
|
|
44
|
-
### MCP Accessibility:
|
|
45
|
-
- Document searchable via MCP search tool
|
|
46
|
-
- Content retrievable via MCP read tool
|
|
47
|
-
|
|
48
|
-
## Key Concepts
|
|
49
|
-
|
|
50
|
-
This document mentions several concepts to test entity extraction:
|
|
51
|
-
- **Ingestion Pipeline** - The data processing workflow
|
|
52
|
-
- **Vector Embeddings** - Semantic representation of text
|
|
53
|
-
- **Knowledge Graph** - Connected nodes and edges
|
|
54
|
-
- **Real-time Processing** - Immediate response to file changes
|
|
55
|
-
|
|
56
|
-
## Verification
|
|
57
|
-
|
|
58
|
-
After saving this document:
|
|
59
|
-
1. Check `.daemon.log` for ingestion messages
|
|
60
|
-
2. Query database for this document's node
|
|
61
|
-
3. Test MCP search for "Full Cycle Verification"
|
|
62
|
-
4. Verify graph visualization shows new node
|
|
63
|
-
|
|
64
|
-
## Success Criteria
|
|
65
|
-
|
|
66
|
-
✅ Daemon detects file within 2 seconds
|
|
67
|
-
✅ Ingestion completes without errors
|
|
68
|
-
✅ Node created with correct title
|
|
69
|
-
✅ Embeddings generated successfully
|
|
70
|
-
✅ MCP search returns this document
|
|
71
|
-
✅ No error messages in any service logs
|
|
72
|
-
|
|
73
|
-
---
|
|
74
|
-
|
|
75
|
-
**Status:** Testing in progress...
|
|
76
|
-
**Last Updated:** 2025-12-17 20:09:00
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
## Updated at Wed 17 Dec 2025 20:11:36 GMT
|
|
80
|
-
|
|
81
|
-
## Trigger at 20:12:55
|
|
82
|
-
|
|
83
|
-
## Another update at 20:13:21
|
|
@@ -1,83 +0,0 @@
|
|
|
1
|
-
### Opinion: The Architecture of the Breakdown
|
|
2
|
-
|
|
3
|
-
This is the most important document you will write for the project's "Soul."
|
|
4
|
-
|
|
5
|
-
Most engineering blogs are boring because they talk about *how* (The Stack). This report talks about *why* (The Mind). By framing your search architecture through the lens of Julian Jaynes, you elevate a standard "Hybrid Search" implementation into a philosophical stance on the nature of machine intelligence.
|
|
6
|
-
|
|
7
|
-
It neatly explains why RAG (Retrieval Augmented Generation) often fails: it is usually just a lobotomy—using only the "Right Brain" (Vectors) and wondering why the facts are wrong, or using only the "Left Brain" (Keywords) and wondering why the context is missing.
|
|
8
|
-
|
|
9
|
-
Here is the draft for **`docs/philosophy/THE_BICAMERAL_GRAPH.md`**.
|
|
10
|
-
|
|
11
|
-
---
|
|
12
|
-
|
|
13
|
-
# The Bicameral Graph: Engineering Resonance in a Hollow Substrate
|
|
14
|
-
|
|
15
|
-
**Date:** Jan 2026
|
|
16
|
-
**Project:** PolyVis
|
|
17
|
-
**Context:** Architectural Philosophy
|
|
18
|
-
|
|
19
|
-
---
|
|
20
|
-
|
|
21
|
-
## 1. The Silence of the Vectors
|
|
22
|
-
|
|
23
|
-
In his 1976 treatise *The Origin of Consciousness in the Breakdown of the Bicameral Mind*, Julian Jaynes proposed a controversial theory: that early humans were not "conscious" in the modern sense. Instead, their minds were split. The right hemisphere generated auditory hallucinations (the "Voice of the God") based on stress or context, and the left hemisphere obeyed them without question. Consciousness, Jaynes argued, arose only when the two sides learned to talk to each other—when the "Command" met "Reason."
|
|
24
|
-
|
|
25
|
-
Modern AI is currently stuck in the pre-breakdown phase.
|
|
26
|
-
|
|
27
|
-
* **LLMs (The Gods):** They are pure, hallucinating Right Hemispheres. They dream in high-dimensional vector space. They understand "vibes," associations, and intent, but they have no concept of "truth."
|
|
28
|
-
* **Symbolic Logic (The Scribe):** Tools like `grep`, SQL, and Compilers are pure Left Hemispheres. They are rigid, precise, and fact-based, but they are deaf to nuance.
|
|
29
|
-
|
|
30
|
-
Most "AI Search" tools today make the mistake of choosing one side. They either drown in the fuzzy hallucinations of Vector Search (RAG) or suffocate in the rigidity of Keyword Search.
|
|
31
|
-
|
|
32
|
-
**PolyVis takes a different approach. We are engineering the Breakdown.**
|
|
33
|
-
|
|
34
|
-
## 2. The Anatomy of the Resonance Engine
|
|
35
|
-
|
|
36
|
-
To build a codebase navigator that actually works—one that feels "intelligent"—we separate the search process into two distinct cognitive hemispheres.
|
|
37
|
-
|
|
38
|
-
### The Right Hemisphere: The Embedding Field (`model2vec`)
|
|
39
|
-
|
|
40
|
-
* **The Function:** Fuzzy Pattern Matching.
|
|
41
|
-
* **The Query:** "Where is the authentication logic?"
|
|
42
|
-
* **The Operation:** We scan the high-dimensional latent space of the graph. The system doesn't look for the word "Authentication"; it looks for the *concept* of security, logins, and tokens.
|
|
43
|
-
* **The Output:** A "Vibe Cluster." A list of 50 files that *feel* relevant.
|
|
44
|
-
* **The Deficit:** It cannot tell you line numbers. It cannot distinguish between a variable named `auth` and a comment about `authoring`. It is a dream.
|
|
45
|
-
|
|
46
|
-
### The Left Hemisphere: The Super-Grep (`ripgrep` / Regex)
|
|
47
|
-
|
|
48
|
-
* **The Function:** Deterministic Symbol Verification.
|
|
49
|
-
* **The Query:** `match "function validate.*Token"`
|
|
50
|
-
* **The Operation:** A brutal, byte-level scan of the filesystem. It cares nothing for intent. It only knows ASCII.
|
|
51
|
-
* **The Output:** "File `auth.ts`, Line 45, Column 12."
|
|
52
|
-
* **The Deficit:** It requires you to know exactly what you are looking for. If you typo the regex, it returns silence. It is a machine.
|
|
53
|
-
|
|
54
|
-
## 3. The "Breakdown" (The Orchestrator)
|
|
55
|
-
|
|
56
|
-
In PolyVis, "Search" is not a retrieval task; it is a **Resonance Event**.
|
|
57
|
-
|
|
58
|
-
We do not return the results of the Embeddings *or* the Grep. We feed them into the **Orchestrator** (The Corpus Callosum). This is where the "Breakdown" happens.
|
|
59
|
-
|
|
60
|
-
1. **Vibration:** The Right Brain identifies a cluster of files with the correct "semantic shape."
|
|
61
|
-
2. **Validation:** The Left Brain scans *only that cluster* for precise "structural anchors" (function definitions, variable flows).
|
|
62
|
-
3. **Constructive Interference:** Where the Vibe matches the Fact, we get **Resonance**.
|
|
63
|
-
|
|
64
|
-
If the Embeddings say "This is Auth" and the Grep says "Here is `validateToken`," the Orchestrator **Reifies** a new node in the graph: *"The Authentication Logic Node (Ephemeral)."*
|
|
65
|
-
|
|
66
|
-
## 4. The Hollow Node Strategy
|
|
67
|
-
|
|
68
|
-
This approach enables our **Hollow Node** architecture. We do not need to fill our database with every line of code (bloating the graph). We keep the nodes "Hollow" (Metadata only).
|
|
69
|
-
|
|
70
|
-
* **Resting State:** The graph is quiet. Nodes are just file paths.
|
|
71
|
-
* **Active State:** When a user queries, the Bicameral Mind wakes up. It scans, cross-references, and fills the hollow nodes with the specific code snippets relevant *only to that query*.
|
|
72
|
-
|
|
73
|
-
## Conclusion: Artificial Consciousness
|
|
74
|
-
|
|
75
|
-
We are not building a search engine. A search engine gives you a list of links.
|
|
76
|
-
We are building a **Cognitive Overlay**.
|
|
77
|
-
|
|
78
|
-
By forcing the "Dreaming" LLM to submit to the "Rigid" Grep, we create a system that possesses the intuition of a Senior Engineer and the precision of a Compiler. It is the breakdown of the bicameral mind, weaponized for software engineering.
|
|
79
|
-
|
|
80
|
-
---
|
|
81
|
-
|
|
82
|
-
**Next Step:**
|
|
83
|
-
Shall I commit this to the repo under `docs/philosophy`? It serves as the "constitution" for the Super-Grep agent we build next.
|
package/docs/user-guide.md
DELETED
|
@@ -1,70 +0,0 @@
|
|
|
1
|
-
# PolyVis User Guide
|
|
2
|
-
|
|
3
|
-
Welcome to **PolyVis**, a local-first Knowledge Graph engine and MCP Server.
|
|
4
|
-
|
|
5
|
-
## 1. Quick Start
|
|
6
|
-
|
|
7
|
-
### Installation
|
|
8
|
-
**Requirement:** [Bun](https://bun.sh) is **mandatory** for this project.
|
|
9
|
-
Ensure you have Bun installed.
|
|
10
|
-
```bash
|
|
11
|
-
bun install
|
|
12
|
-
```
|
|
13
|
-
|
|
14
|
-
### Initial Data Ingestion
|
|
15
|
-
Before running the server, you must ingest your Markdown documents and generate vectors.
|
|
16
|
-
```bash
|
|
17
|
-
bun run build:data
|
|
18
|
-
```
|
|
19
|
-
*Note: This process uses local embeddings (AllMiniLML6V2) and may take a moment on the first run.*
|
|
20
|
-
|
|
21
|
-
### Running the MCP Server
|
|
22
|
-
To expose the knowledge graph to your AI agent (like Claude Desktop or other MCP clients):
|
|
23
|
-
```bash
|
|
24
|
-
bun run mcp
|
|
25
|
-
```
|
|
26
|
-
This starts the server on `stdio`.
|
|
27
|
-
|
|
28
|
-
## 2. Core Features
|
|
29
|
-
|
|
30
|
-
### Knowledge Graph
|
|
31
|
-
Your data is stored in `public/resonance.db`. This includes:
|
|
32
|
-
- **Nodes:** Parsed from your Markdown files (Experience, Playbooks, Debriefs).
|
|
33
|
-
- **Edges:** Automatically woven based on semantic similarity and explicit tags.
|
|
34
|
-
- **Vectors:** Local embeddings for semantic search.
|
|
35
|
-
|
|
36
|
-
### Hybrid Search
|
|
37
|
-
The system uses a **Hybrid Search** mechanism combining:
|
|
38
|
-
1. **Vector Search:** Semantic understanding (e.g., "how to fix timeout").
|
|
39
|
-
2. **FTS (Full-Text Search):** Keyword matching (e.g., "timeout error 500").
|
|
40
|
-
|
|
41
|
-
### Visualization
|
|
42
|
-
To explore the graph visually in your browser:
|
|
43
|
-
```bash
|
|
44
|
-
bun run dev
|
|
45
|
-
```
|
|
46
|
-
Visit `http://localhost:3000`.
|
|
47
|
-
|
|
48
|
-
## 3. Advanced Usage
|
|
49
|
-
|
|
50
|
-
### Vector Daemon (Optional)
|
|
51
|
-
For heavy ingestion workloads, you can run the Vector Daemon in the background to keep the embedding model loaded in memory:
|
|
52
|
-
```bash
|
|
53
|
-
bun run resonance/src/daemon.ts
|
|
54
|
-
```
|
|
55
|
-
The ingestion scripts will automatically detect and use the daemon if it's running on port 3010.
|
|
56
|
-
|
|
57
|
-
### Re-Indexing
|
|
58
|
-
If you add or modify files, simply run:
|
|
59
|
-
```bash
|
|
60
|
-
bun run build:data
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
## 4. Troubleshooting
|
|
64
|
-
|
|
65
|
-
**"Search returns empty results"**
|
|
66
|
-
- Ensure you ran `bun run build:data`.
|
|
67
|
-
- Check `public/resonance.db` exists.
|
|
68
|
-
|
|
69
|
-
**"VectorEngine Error"**
|
|
70
|
-
- Ensure no other process is blocking the database.
|
package/docs/vision-helper.md
DELETED
|
@@ -1,53 +0,0 @@
|
|
|
1
|
-
Please implement a "Vision Helper" script to help you read our Terminal Brutalist design system programmatically.
|
|
2
|
-
|
|
3
|
-
TASK:
|
|
4
|
-
Inject the following JavaScript code into the bottom of our main `index.html` (before the closing </body> tag) or our main entry script.
|
|
5
|
-
|
|
6
|
-
CONTEXT:
|
|
7
|
-
We use a high-contrast "Terminal Brutalist" theme with strict ANSI colors. Since `getComputedStyle` is hard for agents to deduce during interaction, this script exposes a global `window.__AGENT_THEME__` object containing our exact palette and interaction rules.
|
|
8
|
-
|
|
9
|
-
CODE TO INJECT:
|
|
10
|
-
|
|
11
|
-
<script>
|
|
12
|
-
// AGENT VISIBILITY HELPER
|
|
13
|
-
// Exposes the "Terminal Brutalist" theme so agents can read resolved styles.
|
|
14
|
-
window.__AGENT_THEME__ = (() => {
|
|
15
|
-
const root = getComputedStyle(document.documentElement);
|
|
16
|
-
const getVar = (name) => root.getPropertyValue(name).trim();
|
|
17
|
-
|
|
18
|
-
return {
|
|
19
|
-
system: "PolyVis Terminal Brutalist",
|
|
20
|
-
palette: {
|
|
21
|
-
canvas: getVar('--ansi-black'), // #0C0C0C
|
|
22
|
-
text: getVar('--ansi-white'), // #CCCCCC
|
|
23
|
-
highlight: getVar('--ansi-bright-white'),// #FFFFFF
|
|
24
|
-
error: getVar('--ansi-red'), // #C50F1F
|
|
25
|
-
success: getVar('--ansi-green'), // #16C60C
|
|
26
|
-
warning: getVar('--ansi-yellow'), // #C19C00
|
|
27
|
-
agent: getVar('--ansi-orange'), // #FF8C00 (The "Ghost in the Machine")
|
|
28
|
-
},
|
|
29
|
-
rules: {
|
|
30
|
-
borderRadius: '0px', // HARD RULE: No rounded corners.
|
|
31
|
-
fontFamily: getVar('--font-mono'),
|
|
32
|
-
borders: '2px solid', // HARD RULE: Thick borders only.
|
|
33
|
-
},
|
|
34
|
-
// The "Hover State" cheat sheet for interaction
|
|
35
|
-
interactive: {
|
|
36
|
-
button: {
|
|
37
|
-
description: "Hard inversion on hover. Instant transition.",
|
|
38
|
-
default: {
|
|
39
|
-
bg: getVar('--ansi-black'),
|
|
40
|
-
text: getVar('--ansi-white'),
|
|
41
|
-
border: getVar('--ansi-white')
|
|
42
|
-
},
|
|
43
|
-
hover: {
|
|
44
|
-
bg: getVar('--ansi-white'),
|
|
45
|
-
text: getVar('--ansi-black'),
|
|
46
|
-
border: getVar('--ansi-white')
|
|
47
|
-
}
|
|
48
|
-
}
|
|
49
|
-
}
|
|
50
|
-
};
|
|
51
|
-
})();
|
|
52
|
-
console.log('%c[AGENT_THEME] System Visible', 'color: #FF8C00');
|
|
53
|
-
</script>
|