217 lines
8 KiB
Markdown
217 lines
8 KiB
Markdown
# 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 |
|