mirror of
https://github.com/basicmachines-co/basic-memory
synced 2026-06-21 13:47:35 +00:00
Compare commits
34 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 89ee324df0 | |||
| 8664c57bb3 | |||
| 8117a7b0ed | |||
| f47fb2aeef | |||
| 8fa197e2ec | |||
| 58f3fe95b7 | |||
| 1d6054d30a | |||
| 812947fc4b | |||
| dab957314a | |||
| 70b2eb3a4a | |||
| 80cdecdbf0 | |||
| 8dd923d5bc | |||
| 0cb429bfd3 | |||
| a15265783e | |||
| e48deaeecf | |||
| 854cf8302e | |||
| 6e4a53cdfa | |||
| 2e215fe83c | |||
| b546941779 | |||
| 29a259421a | |||
| 071e76a0ff | |||
| 9ee67e9de0 | |||
| edbc04be60 | |||
| 864209c5f8 | |||
| b40f0c75da | |||
| 230738ee9c | |||
| d15d8f91a4 | |||
| a6fdfad374 | |||
| 3e78fcc2c2 | |||
| b5d09a4854 | |||
| 01d46727b4 | |||
| 713b3bedf8 | |||
| 97d3a0196e | |||
| 052f491fff |
@@ -64,8 +64,15 @@ jobs:
|
||||
|
||||
- name: Install uv
|
||||
run: |
|
||||
curl -LsSf https://astral.sh/uv/install.sh | sh
|
||||
echo "$HOME/.cargo/bin" >> $GITHUB_PATH
|
||||
pip install uv
|
||||
|
||||
- name: Create virtual env
|
||||
run: |
|
||||
uv venv
|
||||
|
||||
- name: Install dependencies
|
||||
run: |
|
||||
uv pip install -e .[dev]
|
||||
|
||||
- name: Install librsvg
|
||||
run: brew install librsvg
|
||||
@@ -78,20 +85,34 @@ jobs:
|
||||
|
||||
- name: Build macOS installer
|
||||
run: |
|
||||
uv pip install -e ".[dev]"
|
||||
cd installer
|
||||
uv run python setup.py bdist_mac
|
||||
# Remove quarantine attribute
|
||||
xattr -dr com.apple.quarantine "dist/Basic Memory Installer.app"
|
||||
# Debug info
|
||||
echo "Environment Info:"
|
||||
uv pip list
|
||||
python --version
|
||||
which uv
|
||||
which python
|
||||
ls -la $(dirname $(which python))
|
||||
echo "PYTHONPATH=$PYTHONPATH"
|
||||
|
||||
# Build
|
||||
make installer-mac
|
||||
#xattr -dr com.apple.quarantine "installer/build/Basic Memory Installer.app"
|
||||
|
||||
- name: Zip macOS installer
|
||||
- name: Inspect build
|
||||
run: |
|
||||
cd installer/build
|
||||
zip -r "Basic-Memory-Installer-${{ needs.release.outputs.tag }}.zip" "Basic Memory Installer.app"
|
||||
echo "Build structure:"
|
||||
ls -la installer/build/Basic\ Memory\ Installer.app/Contents/MacOS/
|
||||
|
||||
|
||||
# - name: Zip macOS installer
|
||||
# run: |
|
||||
# cd installer/build
|
||||
# zip -ry "Basic-Memory-Installer-${{ needs.release.outputs.tag }}.zip" "Basic Memory Installer.app"
|
||||
|
||||
- name: Upload macOS installer
|
||||
uses: softprops/action-gh-release@v1
|
||||
with:
|
||||
files: installer/build/Basic-Memory-Installer-${{ needs.release.outputs.tag }}.zip
|
||||
#files: installer/build/Basic-Memory-Installer-${{ needs.release.outputs.tag }}.zip
|
||||
files: installer/build/*.app
|
||||
tag_name: ${{ needs.release.outputs.tag }}
|
||||
token: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
+108
@@ -1,6 +1,114 @@
|
||||
# CHANGELOG
|
||||
|
||||
|
||||
## v0.2.18 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Don't zip app on release
|
||||
([`8664c57`](https://github.com/basicmachines-co/basic-memory/commit/8664c57bb331d7f3f7e0239acb5386c7a3c6144e))
|
||||
|
||||
|
||||
## v0.2.17 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Fix app zip in installer release
|
||||
([`8fa197e`](https://github.com/basicmachines-co/basic-memory/commit/8fa197e2ec8a1b6caaf6dbb39c3c6626bba23e2e))
|
||||
|
||||
|
||||
## v0.2.16 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Debug inspect build on ci
|
||||
([`1d6054d`](https://github.com/basicmachines-co/basic-memory/commit/1d6054d30a477a4e6a5d6ac885632e50c01945d3))
|
||||
|
||||
|
||||
## v0.2.15 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Debug installer ci
|
||||
([`dab9573`](https://github.com/basicmachines-co/basic-memory/commit/dab957314aec9ed0e12abca2265552494ae733a2))
|
||||
|
||||
|
||||
## v0.2.14 (2025-02-14)
|
||||
|
||||
|
||||
## v0.2.13 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Refactor release.yml installer
|
||||
([`a152657`](https://github.com/basicmachines-co/basic-memory/commit/a15265783e47c22d8c7931396281d023b3694e27))
|
||||
|
||||
- Try using symlinks in installer build
|
||||
([`8dd923d`](https://github.com/basicmachines-co/basic-memory/commit/8dd923d5bc0587276f92b5f1db022ad9c8687e45))
|
||||
|
||||
|
||||
## v0.2.12 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Fix cx_freeze options for installer
|
||||
([`854cf83`](https://github.com/basicmachines-co/basic-memory/commit/854cf8302e2f83578030db05e29b8bdc4348795a))
|
||||
|
||||
|
||||
## v0.2.11 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Ci installer app fix #37
|
||||
([`2e215fe`](https://github.com/basicmachines-co/basic-memory/commit/2e215fe83ca421b921186c7f1989dc2cb5cca278))
|
||||
|
||||
|
||||
## v0.2.10 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Fix build on github ci for app installer
|
||||
([`29a2594`](https://github.com/basicmachines-co/basic-memory/commit/29a259421a0ccb10cfa68e3707eaa506ad5e55c0))
|
||||
|
||||
|
||||
## v0.2.9 (2025-02-14)
|
||||
|
||||
|
||||
## v0.2.8 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Fix installer on ci, maybe
|
||||
([`edbc04b`](https://github.com/basicmachines-co/basic-memory/commit/edbc04be601d234bb1f5eb3ba24d6ad55244b031))
|
||||
|
||||
|
||||
## v0.2.7 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Try to fix installer ci
|
||||
([`230738e`](https://github.com/basicmachines-co/basic-memory/commit/230738ee9c110c0509e0a09cb0e101a92cfcb729))
|
||||
|
||||
|
||||
## v0.2.6 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Bump project patch version
|
||||
([`01d4672`](https://github.com/basicmachines-co/basic-memory/commit/01d46727b40c24b017ea9db4b741daef565ac73e))
|
||||
|
||||
- Fix installer setup.py change ci to use make
|
||||
([`3e78fcc`](https://github.com/basicmachines-co/basic-memory/commit/3e78fcc2c208d83467fe7199be17174d7ffcad1a))
|
||||
|
||||
|
||||
## v0.2.5 (2025-02-14)
|
||||
|
||||
### Bug Fixes
|
||||
|
||||
- Refix vitual env in installer build
|
||||
([`052f491`](https://github.com/basicmachines-co/basic-memory/commit/052f491fff629e8ead629c9259f8cb46c608d584))
|
||||
|
||||
|
||||
## v0.2.4 (2025-02-14)
|
||||
|
||||
|
||||
|
||||
+3
-5
@@ -11,21 +11,19 @@ build_exe_options = {
|
||||
if sys.platform == "win32":
|
||||
base = "Win32GUI" # Use GUI base for Windows
|
||||
build_exe_options.update({
|
||||
"include_msvcr": True, # Include Visual C++ runtime
|
||||
"include_msvcr": True,
|
||||
})
|
||||
target_name = "Basic Memory Installer.exe"
|
||||
icon = None # We'll add Windows icon later
|
||||
else: # darwin
|
||||
base = None # Don't use GUI base for macOS
|
||||
target_name = "Basic Memory Installer"
|
||||
icon = "Basic.icns"
|
||||
|
||||
executables = [
|
||||
Executable(
|
||||
script="installer.py",
|
||||
target_name=target_name,
|
||||
base=base,
|
||||
icon=icon
|
||||
icon="Basic.icns"
|
||||
)
|
||||
]
|
||||
|
||||
@@ -37,7 +35,7 @@ setup(
|
||||
"build_exe": build_exe_options,
|
||||
"bdist_mac": {
|
||||
"bundle_name": "Basic Memory Installer",
|
||||
"iconfile": icon if sys.platform == "darwin" else None
|
||||
"iconfile": "Basic.icns"
|
||||
}
|
||||
},
|
||||
executables=executables,
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
[project]
|
||||
name = "basic-memory"
|
||||
version = "0.2.4"
|
||||
version = "0.2.18"
|
||||
description = "Local-first knowledge management combining Zettelkasten with knowledge graphs"
|
||||
readme = "README.md"
|
||||
requires-python = ">=3.12.1"
|
||||
|
||||
@@ -1,458 +0,0 @@
|
||||
# Basic Memory Tasks
|
||||
|
||||
## Current Focus
|
||||
|
||||
### Observation Management
|
||||
|
||||
Implement update/remove functionality for observations with a focus on maintainability and consistency with our "
|
||||
filesystem is source of truth" principle.
|
||||
|
||||
Options under consideration:
|
||||
|
||||
1. Bulk Update Approach
|
||||
- Update all observations at once
|
||||
- Pros:
|
||||
- Simpler file operations
|
||||
- No need to match on observation content
|
||||
- Easier database synchronization
|
||||
- Very consistent with "filesystem is source of truth"
|
||||
- Cons:
|
||||
- Less efficient - rewrites everything for small changes
|
||||
- Potential concurrency implications
|
||||
|
||||
2. Tracked Observations Approach
|
||||
- Use markdown comments for observation IDs
|
||||
```markdown
|
||||
# Entity Name
|
||||
type: entity_type
|
||||
|
||||
## Observations
|
||||
- <!-- obs-id: abc123 -->
|
||||
This is an observation
|
||||
```
|
||||
- Pros:
|
||||
- Can track individual observations
|
||||
- Enables precise updates/deletes
|
||||
- Cons:
|
||||
- More complex markdown parsing
|
||||
- IDs visible in markdown
|
||||
|
||||
3. Diff-based Approach
|
||||
- Implement observation-aware diffing
|
||||
- Track changes at observation level
|
||||
- Pros:
|
||||
- More efficient updates
|
||||
- Preserves manual edits
|
||||
- Cons:
|
||||
- More complex implementation
|
||||
- Need to handle merge conflicts
|
||||
|
||||
4. Position-based Management
|
||||
- Track observations by their position/order
|
||||
- Pros:
|
||||
- No need for explicit IDs
|
||||
- Clean markdown
|
||||
- Cons:
|
||||
- Fragile if order changes
|
||||
- Hard to handle concurrent edits
|
||||
|
||||
## Completed
|
||||
|
||||
- [x] Extract file operations to fileio.py module
|
||||
- [x] Update EntityService to use fileio functions
|
||||
- [x] Initial ObservationService implementation
|
||||
- [x] Basic test coverage
|
||||
|
||||
## Future Work
|
||||
|
||||
- [ ] Implement observation updates/removals (exploring options above)
|
||||
- [ ] Proper session management for concurrent operations
|
||||
- [ ] EntityService tests using new fileio module
|
||||
- [ ] More sophisticated search functionality
|
||||
- [ ] Handle markdown formatting edge cases
|
||||
|
||||
## TODO
|
||||
|
||||
### refactor input schema
|
||||
|
||||
1. Observations Format:
|
||||
Old (JSON) way I tried first:
|
||||
|
||||
```python
|
||||
"observations": ["First observation", "Second observation"] # Simple string array
|
||||
```
|
||||
|
||||
New required format:
|
||||
|
||||
```python
|
||||
"observations": [
|
||||
{"content": "First observation"},
|
||||
{"content": "Second observation"}
|
||||
] # Array of objects with content field
|
||||
```
|
||||
|
||||
2. Relations Format:
|
||||
Old way:
|
||||
|
||||
```python
|
||||
"relations": [
|
||||
{"from": "EntityName", "to": "OtherEntity", "relationType": "relates_to"} # Using names
|
||||
]
|
||||
```
|
||||
|
||||
New format:
|
||||
|
||||
```python
|
||||
"relations": [
|
||||
{"fromId": "20241210-entity-id", "toId": "20241210-other-id", "relationType": "relates_to"} # Using IDs
|
||||
]
|
||||
```
|
||||
|
||||
My preferences:
|
||||
|
||||
1. For observations: The simple string array felt more intuitive for basic use, but I can see the benefits of the object
|
||||
format:
|
||||
- Allows for additional metadata (context, timestamps, etc.)
|
||||
- More explicit about what each field means
|
||||
- Consistent with how we'd want to store this in a database
|
||||
|
||||
2. For relations: Using IDs is technically better but requires an extra lookup step in my workflow:
|
||||
- I have to first create the entities to get their IDs
|
||||
- Then use those IDs to create relations
|
||||
- Makes it harder to create entities and relations in a single step
|
||||
|
||||
Suggestions for making it more intuitive:
|
||||
|
||||
1. For observations: We could have a helper function that accepts either format:
|
||||
|
||||
```python
|
||||
# Both would work:
|
||||
create_entities([{
|
||||
"name": "Entity",
|
||||
"entityType": "type",
|
||||
"observations": ["Simple string obs"] # Auto-converted to object format
|
||||
}])
|
||||
|
||||
create_entities([{
|
||||
"name": "Entity",
|
||||
"entityType": "type",
|
||||
"observations": [{"content": "Full object obs"}] # Native format
|
||||
}])
|
||||
```
|
||||
|
||||
2. For relations: Maybe allow a name-based helper function:
|
||||
|
||||
```python
|
||||
# Instead of requiring IDs:
|
||||
create_relations_by_name([{
|
||||
"from": "EntityName",
|
||||
"to": "OtherEntity",
|
||||
"relationType": "relates_to"
|
||||
}])
|
||||
```
|
||||
|
||||
3. A combined creation function for when we want to create entities and their relations together:
|
||||
|
||||
```python
|
||||
create_entity_with_relations({
|
||||
"entity": {
|
||||
"name": "NewEntity",
|
||||
"entityType": "type",
|
||||
"observations": ["Obs 1", "Obs 2"]
|
||||
},
|
||||
"relations": [{
|
||||
"to": "ExistingEntity",
|
||||
"relationType": "relates_to"
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
The current schema is more "correct" from a software engineering perspective, but these helpers could make it more
|
||||
natural to use while maintaining the rigorous underlying structure. What do you think about these suggestions? Would you
|
||||
prefer to keep it strict for clarity, or add some convenience layers?
|
||||
|
||||
### entity file organization
|
||||
|
||||
- my problems
|
||||
- wall of text is hard to scan visually
|
||||
- files are not ordered or grouped granular enough. Only `<date>_<entity_name>.md`
|
||||
- hard to tell when a new entity file is added
|
||||
|
||||
Possible fixes:
|
||||
|
||||
- use subdirectories?
|
||||
|
||||
## TASKS
|
||||
|
||||
1. **Core Functionality Improvements**
|
||||
- [x] entity.description addition
|
||||
- [x] subdirectories
|
||||
- Paul needs this for markdown view
|
||||
- [x] refine directory sprawl
|
||||
- [ ] improve tool api
|
||||
- [ ] Choose and implement observation update/removal strategy
|
||||
- [ ] Handle relationship updates in files
|
||||
- [ ] Complete full CRUD operations
|
||||
- delete
|
||||
- [ ] Improve search functionality (currently broken as we discovered)
|
||||
|
||||
### Suggested Sequence
|
||||
|
||||
1. **Schema Update First**
|
||||
- Add `entity.description` field
|
||||
- rename entity.references?
|
||||
- This affects database, Pydantic models, and file format
|
||||
- Good foundation for other changes
|
||||
|
||||
2. **File Organization**
|
||||
- Add subdirectory support
|
||||
- Affects:
|
||||
- File path handling
|
||||
- Entity loading/saving
|
||||
- URI resolution
|
||||
- Will make Paul's markdown viewing experience better
|
||||
|
||||
3. **Tool API Improvements**
|
||||
- Cleaner input/output schemas
|
||||
- More consistent patterns
|
||||
- Better error handling
|
||||
- This sets us up for implementing the remaining operations
|
||||
|
||||
4. **Core Operations**
|
||||
- Implement delete operations
|
||||
- Update/remove observations
|
||||
- Relationship updates in files
|
||||
- Building on the improved API
|
||||
|
||||
5. **Search Fix**
|
||||
- Can properly tackle this after file organization
|
||||
- Will benefit from improved schema
|
||||
|
||||
Would you like me to:
|
||||
1. Start with the schema update for entity.description?
|
||||
2. Plan out the subdirectory implementation?
|
||||
3. Or focus on a different area?
|
||||
|
||||
I think the schema update would be a clean, contained change to start with, but I'm happy to tackle whichever part you think would be most valuable first.
|
||||
|
||||
|
||||
2. **Robustness & Testing**
|
||||
- Fix DI issues
|
||||
- Learn from fastmcp patterns
|
||||
- Markdown service
|
||||
- markdown.py
|
||||
-python-frontmatter
|
||||
- Complete test coverage
|
||||
- Expand testing across services
|
||||
- 100% coverate
|
||||
- Improve error handling and logging
|
||||
- Add comprehensive type hints
|
||||
|
||||
3. **Architecture Improvements**
|
||||
- Handle concurrent file operations safely
|
||||
- Implement proper session management
|
||||
- Balance file operations and DB sync
|
||||
- Handle markdown formatting edge cases
|
||||
|
||||
4. **Documentation & Infrastructure**
|
||||
- Document core modules
|
||||
- Implement proper backup strategy
|
||||
- Add file change versioning
|
||||
- Improve CLI interface
|
||||
|
||||
|
||||
## Ideas
|
||||
|
||||
- need update tool
|
||||
|
||||
### 2-way sync
|
||||
|
||||
- Enable updates to the markdown files to be able to be seen by AI
|
||||
- possible via tool sync
|
||||
- filesystem notifications via agent?
|
||||
- Claude can use `file_write` tool to edit Entity files also
|
||||
|
||||
### Projects
|
||||
|
||||
- support multiple projects
|
||||
- figure out flow
|
||||
- load project at startup?
|
||||
- switch project during chat?
|
||||
|
||||
### References
|
||||
|
||||
- better support for ref:// references
|
||||
- should we call them memory://<project>/<entity>
|
||||
- use Prompt to invoke reference uri
|
||||
|
||||
### Entity File format
|
||||
|
||||
- Consider using wiki link format:
|
||||
[[20241210-ai_human_collaboration_model]] improves
|
||||
|
||||
instead of
|
||||
[20241210-basic-memory] validates_design_of
|
||||
|
||||
- use frontmatter for file header
|
||||
|
||||
### Code
|
||||
|
||||
- cleanup server.py
|
||||
- use markdown.py?
|
||||
- fastmcp?
|
||||
- Entity.description
|
||||
|
||||
### Other Features
|
||||
|
||||
- Search
|
||||
- webui
|
||||
- python notebook?
|
||||
- vector eb extension for sqlite
|
||||
|
||||
#### Obsidian
|
||||
|
||||
- use as file viewer editor
|
||||
- create knowledge graph?
|
||||
|
||||
#### Save chats
|
||||
|
||||
I'll sketch out a potential schema for chat sessions in our system:
|
||||
|
||||
```
|
||||
{
|
||||
`entities`: [
|
||||
{
|
||||
`name`: `Chat_Entity_Design`,
|
||||
`entityType`: `design_proposal`,
|
||||
`observations`: [
|
||||
{
|
||||
`content`: `Entity Schema:
|
||||
type: chat_session
|
||||
date: ISO timestamp
|
||||
participants: [human, ai]
|
||||
topic: string
|
||||
context_refs: [memory://<project>/<entity_id>]
|
||||
key_decisions: [string]
|
||||
summary: string`
|
||||
},
|
||||
{
|
||||
`content`: `File Format (frontmatter):
|
||||
---
|
||||
type: chat_session
|
||||
date: 2024-12-10T10:30:00Z
|
||||
participants:
|
||||
- human: paul
|
||||
- ai: claude
|
||||
topic: Chat Session Storage Design
|
||||
context_refs:
|
||||
- memory://basic-memory/20241210-chat-entity-design
|
||||
key_decisions:
|
||||
- Store chats as first-class entities
|
||||
- Use memory:// URI scheme
|
||||
summary: Designed schema for chat storage
|
||||
---`
|
||||
},
|
||||
{
|
||||
`content`: `Example Relations:
|
||||
- chat_session references design_proposal
|
||||
- chat_session implements feature
|
||||
- chat_session discusses concept
|
||||
- chat_session continues_from previous_chat`
|
||||
},
|
||||
{
|
||||
`content`: `Auto-generation approach:
|
||||
1. At end of chat, Claude summarizes key points
|
||||
2. Creates chat entity with metadata
|
||||
3. Adds relations to referenced entities
|
||||
4. Updates any entities modified during chat`
|
||||
},
|
||||
{
|
||||
`content`: `Integration points:
|
||||
- memory:// URI scheme for references
|
||||
- Relations to track context chain
|
||||
- File format matches entity schema
|
||||
- Automatic metadata generation`
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
```
|
||||
{
|
||||
`entities`: [
|
||||
{
|
||||
`name`: `Chat_Session_Workflow`,
|
||||
`entityType`: `process`,
|
||||
`observations`: [
|
||||
{
|
||||
`content`: `Start of chat:
|
||||
- Load any referenced context via memory:// URIs
|
||||
- Initialize new chat session metadata
|
||||
- Track entities being discussed/modified`
|
||||
},
|
||||
{
|
||||
`content`: `During chat:
|
||||
- Update references as new entities are mentioned
|
||||
- Track key decisions and changes
|
||||
- Note any new relations discovered`
|
||||
},
|
||||
{
|
||||
`content`: `End of chat:
|
||||
- Generate summary and key points
|
||||
- Create chat session entity
|
||||
- Add relations to referenced entities
|
||||
- Update any modified entities`
|
||||
},
|
||||
{
|
||||
`content`: `Future chat reference:
|
||||
- Can reference previous chat via memory:// URI
|
||||
- Loads relevant context and decisions
|
||||
- Creates continues_from relation automatically`
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Key aspects of this design:
|
||||
|
||||
1. Chat Session as Entity
|
||||
|
||||
- Clear metadata (participants, date, topic)
|
||||
- Explicit references to other entities via memory:// URIs
|
||||
- Captures key decisions and summary
|
||||
- Uses frontmatter for clean file format
|
||||
|
||||
2. Rich Relations
|
||||
|
||||
- Can track chat-to-chat continuity
|
||||
- Links to entities discussed/modified
|
||||
- Captures purpose (discusses, implements, etc.)
|
||||
- Maintains context chain
|
||||
|
||||
3. Automated Workflow
|
||||
|
||||
- I could generate metadata during chat
|
||||
- Create summary and relations at end
|
||||
- Update any modified entities
|
||||
- Makes context loading explicit
|
||||
|
||||
4. Integration
|
||||
|
||||
- memory:// URI scheme fits naturally
|
||||
- File format matches our entity pattern
|
||||
- Two-way links between chats and entities
|
||||
- Clear context persistence model
|
||||
|
||||
The nice thing about this design is that it makes chat sessions "first-class citizens" in our knowledge graph while
|
||||
keeping everything in human-readable markdown files.
|
||||
|
||||
Would you like me to:
|
||||
|
||||
1. Sketch out what this chat would look like as an entity?
|
||||
2. Detail the MCP tool changes needed?
|
||||
3. Mock up the file format more precisely?
|
||||
4. Something else?
|
||||
Reference in New Issue
Block a user