harbor/obsidian-ai-memory-strategy.md

8 KiB

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:

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

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

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