The Bridge

Valence mining crystallizes understanding. The memory bank stores it. But understanding without action is just contemplation. The task system is the bridge between knowing what you want and actually building it.

A task tracker for agentic LLM workflows needs to be:

• Simple enough that an LLM can operate it — No GUI-only interfaces. CLI-first. Text in, text out.
• Structured enough to encode dependencies — What blocks what. What order things happen in.
• Lightweight enough to not impose overhead — If the tool is heavier than the task, you've lost.

The Evolution: Beads → TD

Beads (The Conceptual Unlock)

The original insight: issues are linked beads. They have dependencies, sequence, hierarchy. An epic contains tasks. Tasks block other tasks. Completing one unblocks the next.

Beads was implemented as a full Go application — 180,000 lines, 3-5 second response times, complex architecture. It worked, but it was heavy.

TD (The Refined Implementation)

Same concept. Under 1,000 lines of Bash + SQLite. Instant response. Linear-style workflow states. Runs anywhere with a shell.

# Create a task
td create "Build landing page" -p high -t feature

# Create subtasks (epic pattern)
td sub 1 "Design header component"
td sub 1 "Implement contact form"
td sub 1 "Deploy to Cloudflare Pages"

# Move through workflow
td move 1.1 started
td close 1.1 "Header looks good"
td ready  # What's unblocked?

How It Works With LLMs

The task system is how you give an LLM a roadmap. Instead of one giant prompt, you break work into discrete steps with dependencies:

1. Mine the context — Valence mine until you understand the full scope
2. Create the epic — A parent task describing the goal
3. Break into subtasks — Each one a discrete, completable unit
4. Set dependencies — What blocks what
5. Execute sequentially — Work through the ready queue one at a time

The LLM reads the task list, picks the next unblocked item, executes it, marks it done, and checks what's newly unblocked. The human reviews, redirects, and adds tasks as new understanding emerges.

Workflow States

State	Type	Meaning
Backlog	backlog	Known but not scheduled
Todo	unstarted	Scheduled, waiting for dependencies
In Progress	started	Actively being worked
Done	completed	Finished
Canceled	canceled	No longer needed

The Epic Pattern

Tasks nest naturally using dot notation:

1    Build user dashboard (epic)
1.1  ├── Design data model
1.2  ├── Create API endpoints
1.3  ├── Build frontend components
1.3.1│   ├── Header widget
1.3.2│   ├── Activity feed
1.3.3│   └── Settings panel
1.4  └── Deploy and test

The LLM sees this hierarchy and understands: 1.1 must finish before 1.2 makes sense. 1.3's subtasks can run in parallel. 1.4 waits for everything.

Task Tracking as Transpilation Input

This is where it connects to semantic transpilation. The task list is structured intent. Each task is an issue. Issues are a specialized table. The LLM reads the issues plus the context (memory bank, docs, existing code) and transpiles them into working artifacts.

The flow:

Getting Started With TD

1. Install TD (single script, SQLite database)
2. Initialize in your project: td init
3. Create your first epic: td create "The thing you're building" -t epic
4. Break it down: td sub 1 "First step"
5. Tell Claude about it: "Read td list and work through the ready queue"