Kid needs a snack. Session interrupted. 6 hours later, you sit back down and your AI coding agent needs to know exactly where you were. What task was in progress. What was blocked. What the next step should be.
Your task system is your time machine. If it can’t answer those questions deterministically — without you remembering anything — it’s not a task system. It’s a to-do list with anxiety.
The Problem: Interrupted Work Destroys Local Memory
Most task management systems are built for continuous attention. You open the board, move the card, close the board. The assumption is that you remember context between sessions — what “Fix auth flow” actually means, which file you were in, what decision you were about to make.
That assumption collapses under three conditions:
- Frequent interruptions — parenting, ADHD, executive function variability, anything that pulls you out mid-thought
- Multi-project switching — 17 active repositories, each with its own state
- AI session handoffs — every Claude session starts at zero with no memory of the last one
Under these conditions, the failure mode isn’t “I forgot a task.” It’s “I forgot the context around the task.” The work item is still on the board. But the meaning attached to it — why it matters, what it depends on, where I was in it — evaporated when the session ended.
This isn’t a feature request for a better Kanban plugin. It’s an architecture problem.
The Architecture: Source of Truth + Derived Views
The solution has three layers, each with a single job:
Source of Truth Dynamic View Snapshot View
───────────────── ───────────────── ─────────────────
ProjectName/ SideProjects.md Kanban-YYYY-MM-DD.md
ProjectName.md ──> (Dataview queries ──> (Obsidian Kanban
(YAML frontmatter) frontmatter live) plugin, static)Layer 1: Project frontmatter (source of truth). Each project has one canonical file in Obsidian. Its YAML frontmatter holds everything: status, stack, last commit date, last audit date, next tasks, blockers. This is the only layer that gets written to directly.
Layer 2: Dataview dashboard (dynamic view). A single Obsidian note with Dataview queries that pull from all project files’ frontmatter. Always live. Never edited directly. Shows the current state of every project without opening 17 files.
Layer 3: Kanban snapshot (point-in-time view). A dated Kanban board generated from the current state of all project frontmatter. Static once created. Shows what the world looked like on February 14th, or February 20th, or whenever the last audit ran. Historical record.
One principle holds this together: project files are canonical. Everything else derives from them.
| Layer | Mutable? | Purpose | Source authority |
|---|---|---|---|
| Project frontmatter | Yes | Canonical project state | Highest |
| Dataview dashboard | Derived | Live operational view | Mirrors source |
| Kanban snapshot | Derived | Historical checkpoint | Mirrors source-at-time |
Why Three Layers, Not One
A single task list can’t serve three competing needs simultaneously.
The source of truth needs to be atomic. YAML frontmatter is readable and writable by both humans and AI agents. A Claude agent can parse next-tasks: from frontmatter, do the work, and update the field — no GUI, no API, no sync protocol. Just text.
The live view needs to be derived. If the dashboard is editable, it becomes a second source of truth that drifts from the project files. Dataview queries enforce read-only derivation. The dashboard can never be wrong because it can never be independently edited.
The snapshot needs to be immutable. When I look at last Tuesday’s Kanban board, I need to see last Tuesday’s state — not today’s state with last Tuesday’s date. Snapshots are generated, dated, and never modified. They’re a commit log for project state.
Each layer answers a different question:
-
Frontmatter: “What is the current state of this one project?”
-
Dashboard: “What is the current state of everything?”
-
Snapshot: “What was the state of everything on this date?”
No single view handles all three. Attempting to make one view do everything is how you get sync conflicts, stale boards, and the ambient dread that your task system is lying to you.
The Refresh Pipeline
State doesn’t stay current on its own. Git logs accumulate. Blockers appear. Projects go dormant without anyone noticing. The pipeline that keeps the system honest:
/gh-cleanup skill Project frontmatter Dataview dashboard Kanban snapshot
(audits repos, ──> (updates all ──> (auto-updates ──> (regenerate
extracts blockers, fields) live) on demand)
tags #human/#pc)/gh-cleanup is a Claude skill that audits repositories in batches of 2 (9 batches across 17 repos). It reads git history, checks for staleness, extracts blockers, and writes the results back to project frontmatter. The Dataview dashboard updates automatically because it’s just queries. The Kanban snapshot is regenerated on demand from the now-current frontmatter.
Every task in next-tasks: gets one of two tags:
-
#human— Requires human action: smoke testing on a physical device, entering credentials, making a design decision -
#pc— Claude can handle autonomously: refactoring, fixing a type error, writing tests
No untagged tasks. The tags force a decision about who owns the next step. When I sit down after three days away, I don’t have to read every task and figure out which ones need me. I filter on #human and know exactly what’s blocked on a person.
Interruption Recovery: The Actual Flow
Here’s what “picking up after an interruption” looks like in practice:
flowchart LR
A[Interrupted session] --> B[Read project frontmatter]
B --> C[Open live Dataview dashboard]
C --> D[Check latest Kanban snapshot]
D --> E[Resume next task with context restored]Step B is the critical one. The frontmatter contains everything a new session needs: what’s in progress, what’s blocked, what the last commit was, when the last audit ran. A Claude agent reading this file gets the same context recovery I get. No explanation needed. No “let me catch you up.” The file is the catch-up.
Step D is the safety net. If the frontmatter looks suspicious — a last-audit date from two weeks ago, a next-tasks field that doesn’t match recent git history — the snapshot from the last known-good audit shows what changed. Diff the snapshot against the current dashboard and you see exactly where drift happened.
What This Actually Looks Like in Frontmatter
A project file’s YAML frontmatter:
status: active
stack: Tauri v2, Svelte 5, Rust
last-commit: 2026-02-20
last-audit: 2026-02-20
next-tasks:
- "Smoke test recurrence engine on real calendar data #human"
- "Fix TypeScript strict mode errors in date utils #pc"
- "PORTFOLIO: Implement natural language date parsing"
blockers:
- "WebKitGTK select element re-render bug (workaround in place)"That’s the entire project state for scheduling purposes. Seventeen of these files, one Dataview dashboard, and a dated Kanban snapshot. The system is three tiers of plain text.
No database. No API. No sync service. Plain text files in a synced folder. The durability of this approach is that it degrades gracefully: if Dataview breaks, the frontmatter is still there. If Obsidian breaks, the YAML is still readable by any text editor or any AI agent.
The Insight: Context Recovery, Not Productivity
The temptation with any task system is to optimize for throughput. More tasks completed. Faster cycle time. Better burndown charts.
That framing is wrong for interrupted work.
The metric that matters is: can I pick this up after 3 days away? Not “how many tasks did I close this week” but “when I sit back down, how long until I’m productive again?” If that number is under 5 minutes, the system is working. If it’s 30 minutes of re-reading code and trying to remember what I was doing, the system has failed regardless of how many checkboxes it has.
This is the distinction between a task system and a context recovery system. A task system tracks what needs to happen. A context recovery system tracks what needs to happen and preserves enough state to resume it without human memory.
The three-layer architecture isn’t clever. It’s the minimum viable design for that guarantee. One source of truth so there’s nothing to reconcile. Derived views so the dashboard can’t drift. Immutable snapshots so you can always answer “what did I think was true on Tuesday?”
Who This Is Actually For
Neurodivergent workflows — ADHD, autism, parenting interruptions — are not edge cases. They’re common patterns that mainstream task systems ignore because they violate the assumption of continuous attention.
But the architecture applies beyond neurodivergence. Anyone working with AI coding agents across multiple projects has this problem: sessions are stateless, projects are not. Anyone managing more projects than they can hold in working memory has this problem: the board says “in progress” but your brain says “I have no idea what that means anymore.”
The answer isn’t discipline. It’s architecture. One source of truth, multiple derived views, zero sync conflicts.
Don’t build a task system. Build a context recovery system. The difference is whether it works when you remember everything, or whether it works when you remember nothing.
The second one is the one you actually need.
Part of the Building for Humans series. See also: ContextMax for the knowledge transfer layer that sits on top of this architecture, /gh-cleanup for the maintenance workflow that keeps it current, Closing the Loop IS the Reward for why this design philosophy matters for neurodivergent collaboration, and “We Don’t Have Any” for the origin story that started all of it.