# 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 |