Add Obsidian AI memory strategy
This commit is contained in:
parent
2042782d83
commit
5e3cbdcf43
1 changed files with 217 additions and 0 deletions
217
obsidian-ai-memory-strategy.md
Normal file
217
obsidian-ai-memory-strategy.md
Normal file
|
|
@ -0,0 +1,217 @@
|
|||
# Obsidian as AI Memory — Strategy
|
||||
|
||||
## Why Obsidian for AI Memory
|
||||
|
||||
Obsidian is a local-first, markdown-based knowledge base. This makes it the ideal AI memory layer because:
|
||||
|
||||
1. **Markdown is AI-native** — Every AI model reads/writes markdown natively. No format conversion needed.
|
||||
2. **Local-first** — Your data stays on your infrastructure, not in someone else's cloud.
|
||||
3. **Graph structure** — Obsidian's `[[wikilinks]]` create a knowledge graph that mirrors how AI context works — interconnected nodes of information.
|
||||
4. **Git-syncable** — Vaults are just folders of `.md` files. Push to Forgejo for backup and versioning.
|
||||
5. **Plugin ecosystem** — Community plugins for AI integration, templating, and automation.
|
||||
6. **Searchable** — Full-text search + tags + frontmatter metadata = fast retrieval.
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ Obsidian Vault │
|
||||
│ (Docker on casa / synced to Forgejo) │
|
||||
│ │
|
||||
│ 📁 Memory/ │
|
||||
│ ├── sessions/ ← AI conversation logs│
|
||||
│ ├── decisions/ ← Why we chose X │
|
||||
│ ├── infrastructure/ ← Network, servers │
|
||||
│ ├── agents/ ← Agent definitions │
|
||||
│ ├── runbooks/ ← How-to procedures │
|
||||
│ └── incidents/ ← What broke & fixes │
|
||||
│ │
|
||||
│ 📁 Projects/ │
|
||||
│ ├── oracle-dc-tech/ │
|
||||
│ ├── samjam-tech/ │
|
||||
│ └── homelab/ │
|
||||
│ │
|
||||
│ 📁 Templates/ │
|
||||
│ ├── session-log.md │
|
||||
│ ├── decision-record.md │
|
||||
│ ├── incident-report.md │
|
||||
│ └── agent-definition.md │
|
||||
│ │
|
||||
│ 📁 Daily/ ← Daily notes │
|
||||
│ └── 2026-05-04.md │
|
||||
└─────────────────────────────────────────────┘
|
||||
│ │
|
||||
▼ ▼
|
||||
Forgejo Repo AI Agent reads
|
||||
(git backup) (context injection)
|
||||
```
|
||||
|
||||
## Memory Types
|
||||
|
||||
### 1. Session Memory (Short-term)
|
||||
**What**: Logs of AI conversations with key decisions and outcomes.
|
||||
**When**: After each significant AI session.
|
||||
**Format**:
|
||||
```markdown
|
||||
---
|
||||
date: 2026-05-04
|
||||
tags: [session, infrastructure, casaos]
|
||||
agents: [kiro, harbor]
|
||||
---
|
||||
# Session: Fix cloud connectivity + deploy code-server
|
||||
|
||||
## Context
|
||||
Cloud server unreachable from internet...
|
||||
|
||||
## Decisions
|
||||
- Fixed keepalived health check (ping -I flag broken)
|
||||
- Changed cloud gateway to VIP 192.168.122.1
|
||||
- Deployed code-server on casa
|
||||
|
||||
## Artifacts
|
||||
- [[harbor]] agent created
|
||||
- [[casa-app-workflow]] documented
|
||||
|
||||
## Follow-up
|
||||
- [ ] Make libvirt default network persistent
|
||||
- [ ] Investigate casaos guest agent
|
||||
```
|
||||
|
||||
### 2. Decision Records (Long-term)
|
||||
**What**: Why a specific technical choice was made.
|
||||
**Why**: So future-you (or future-AI) doesn't re-debate settled questions.
|
||||
**Format**:
|
||||
```markdown
|
||||
---
|
||||
date: 2026-05-04
|
||||
tags: [decision, networking]
|
||||
status: accepted
|
||||
---
|
||||
# Decision: Use VIP as default gateway for all bridge hosts
|
||||
|
||||
## Context
|
||||
Cloud server was pointing at pre's base IP (.2) instead of VIP (.1).
|
||||
|
||||
## Options
|
||||
A. VIP (.1) — automatic failover ✅
|
||||
B. Direct (.2) — no failover
|
||||
C. Dual routes — overcomplicated
|
||||
|
||||
## Decision
|
||||
Option A. VRRP exists for this exact purpose.
|
||||
```
|
||||
|
||||
### 3. Infrastructure Memory
|
||||
**What**: Current state of all systems, IPs, services, configs.
|
||||
**Why**: Single source of truth that AI can reference.
|
||||
**Maps to**: Your existing `steering/infrastructure.md` but richer with Obsidian links.
|
||||
|
||||
### 4. Agent Memory
|
||||
**What**: Agent definitions, capabilities, deployment history.
|
||||
**Why**: Agents can reference their own history and learn from past deployments.
|
||||
**Maps to**: `agents/harbor/` etc.
|
||||
|
||||
### 5. Incident Memory
|
||||
**What**: What broke, root cause, fix applied.
|
||||
**Why**: Pattern recognition — if the same symptom appears, AI finds the prior fix.
|
||||
**Format**:
|
||||
```markdown
|
||||
---
|
||||
date: 2026-05-04
|
||||
tags: [incident, networking, dns]
|
||||
severity: high
|
||||
systems: [cloud, pre, netbird]
|
||||
---
|
||||
# Incident: Cloud server unreachable from internet
|
||||
|
||||
## Symptoms
|
||||
- NetBird disconnected on cloud
|
||||
- DNS resolution failing
|
||||
- Incoming traffic dead
|
||||
|
||||
## Root Cause Chain
|
||||
1. Pre's ping binary changed from iputils to inetutils (no -I flag)
|
||||
2. Keepalived health check always failing → VIP never assigned
|
||||
3. Cloud DNS stub resolver (127.0.0.53) broken
|
||||
4. NetBird can't resolve management server → tunnel down
|
||||
|
||||
## Fix
|
||||
- Removed -I flag from check_internet.sh
|
||||
- Changed cloud gateway to VIP
|
||||
- Pointed resolv.conf at 127.0.0.54
|
||||
- Restarted NetBird
|
||||
|
||||
## Prevention
|
||||
- Monitor keepalived VIP assignment
|
||||
- Alert on NetBird peer count drops
|
||||
```
|
||||
|
||||
## Implementation Plan
|
||||
|
||||
### Phase 1: Deploy Obsidian (Week 1)
|
||||
1. Deploy `linuxserver/obsidian` Docker container on casa via Harbor workflow
|
||||
- Or use **Obsidian Livesync** (CouchDB-based) for multi-device sync
|
||||
- Or simply use a git-synced vault folder
|
||||
2. Create vault structure (Memory/, Projects/, Templates/, Daily/)
|
||||
3. Migrate existing steering docs into vault
|
||||
4. Set up Forgejo repo `sam/vault` for git backup
|
||||
|
||||
### Phase 2: AI Integration (Week 2)
|
||||
1. **Kiro steering files** → symlink or copy from vault
|
||||
- `.kiro/steering/*.md` can be generated from vault content
|
||||
2. **Session logging** → After each AI session, save a session note
|
||||
3. **Context injection** → Before starting work, AI reads relevant vault notes
|
||||
4. **Harbor manifest** → Lives in vault, updated after each deployment
|
||||
|
||||
### Phase 3: Automation (Week 3)
|
||||
1. **Git auto-sync** — Cron job or Obsidian Git plugin pushes to Forgejo daily
|
||||
2. **Template automation** — Templater plugin auto-fills dates, tags
|
||||
3. **AI search** — Use Obsidian's Smart Connections plugin or similar for semantic search across notes
|
||||
4. **Cross-reference** — Link incidents to infrastructure notes, decisions to sessions
|
||||
|
||||
## Key Plugins
|
||||
|
||||
| Plugin | Purpose |
|
||||
|---|---|
|
||||
| **Obsidian Git** | Auto-commit and push to Forgejo |
|
||||
| **Templater** | Auto-fill templates for sessions, incidents |
|
||||
| **Dataview** | Query notes like a database (list all incidents, open follow-ups) |
|
||||
| **Smart Connections** | AI-powered semantic search across vault |
|
||||
| **Kanban** | Track follow-up tasks from sessions |
|
||||
|
||||
## Sync Strategy
|
||||
|
||||
```
|
||||
Obsidian (casa Docker) ←→ Forgejo (sam/vault)
|
||||
↕ ↕
|
||||
Local editing Backup + versioning
|
||||
(browser via NPM) (git history)
|
||||
↕
|
||||
AI reads vault
|
||||
(steering files / context injection)
|
||||
```
|
||||
|
||||
**Option A: Git-based** (simplest)
|
||||
- Vault lives at `/DATA/AppData/obsidian/vault/`
|
||||
- Cron or Obsidian Git plugin pushes to `sam/vault` on Forgejo
|
||||
- Other machines clone the repo
|
||||
|
||||
**Option B: Livesync** (real-time)
|
||||
- Deploy CouchDB alongside Obsidian
|
||||
- Real-time sync between devices
|
||||
- Still git-backup to Forgejo periodically
|
||||
|
||||
**Recommendation**: Start with Option A. Git sync is simple, reliable, and you already have Forgejo. Add Livesync later if you need real-time multi-device editing.
|
||||
|
||||
## What Goes Where
|
||||
|
||||
| Content | Vault Location | AI Access |
|
||||
|---|---|---|
|
||||
| Server IPs, configs | `Memory/infrastructure/` | Steering files |
|
||||
| Agent definitions | `Memory/agents/` | Agent context |
|
||||
| Deployment history | `Memory/agents/harbor/manifest.md` | Harbor workflow |
|
||||
| Session logs | `Memory/sessions/` | On-demand lookup |
|
||||
| Decisions | `Memory/decisions/` | On-demand lookup |
|
||||
| Incidents | `Memory/incidents/` | Pattern matching |
|
||||
| Daily notes | `Daily/` | Recent context |
|
||||
| Project docs | `Projects/` | Project-specific |
|
||||
Loading…
Add table
Reference in a new issue