I standardized kimaki around one operational decision: todo state lives in Obsidian, not in repository markdown, and I treat the vault as the system of record for agent task flow and memory.

What We Built

• A repo policy layer (AGENTS.md + MEMORY.md) that enforces Obsidian-first task management and explicitly avoids in-repo markdown todo tracking.
• A concrete command workflow for daily execution: read open tasks, append new tasks, complete tasks by line, and report remaining open count.
• A memory-first operating pattern tied to a canonical vault path (/Users/kristian/Documents/obsidian/agent) with project-scoped fallback rules.
• Iterated operational reliability around vault access, reflected in repeated session work on external-directory permission retries and vault memory integration.

Why We Built It

• We needed one durable source of truth for active work; splitting tasks between repo files and notes had high drift risk.
• Obsidian is better aligned with ongoing recall and cross-session continuity, especially because this project expects QMD indexing and scripted prefetch before substantial work.
• The recent session pattern (multiple retries around permissions and vault integration) shows this was not theoretical cleanup; it was required to make the workflow dependable in practice.
• Keeping todo state outside the repo also protects the codebase from operational noise and keeps versioned content focused on product artifacts.

How It Works

• Before substantial work, I run the QMD prefetch script from the shared vault script path to load relevant memory context.
• For task operations, I use Obsidian CLI commands only: inspect today’s open todos, append new checklist items, and complete tasks in place.
• Default task scope is today’s daily note, unless the request targets a different note or vault.
• If Obsidian CLI emits helper-app warnings, I treat stderr carefully; prior runs documented that stdout can still contain valid results.
• There is no commit-based implementation trail yet in this snapshot, so operational intent is captured primarily through policy docs and session themes.