Core concepts

The node hierarchy, node kinds, the status lifecycle and links between nodes.

Node hierarchy

Every unit of work is a node. Nodes form a strict tree from the product down to a concrete task. Nesting is unlimited, but prefer the shallowest depth that still reads clearly.

◇project— Root of the tree — a product or initiative.

▣epic— A large body of work.

◆feature— A shippable capability — something you can release.

▤plan— Implementation plan for a feature: goals, approach, risks and an ordered task checklist in the Markdown content.

●task— Leaf of the tree — a concrete executable unit.

Node kinds

Every node has a kind that defines its role in the tree.

◇project

Root of the tree — a product or initiative. Created via create_project, has a short KEY (slug prefix, e.g. AF).

▣epic

A large body of work. Groups several features. Create one only for genuinely large scope.

◆feature

A shippable capability — something you can release. Holds implementation plans.

▤plan

Implementation plan for a feature: goals, approach, risks and an ordered task checklist in the Markdown content.

●task

Leaf of the tree — a concrete executable unit. Where real work happens; carries acceptance criteria.

▦doc

A document. A Markdown page with backlinks and references. Lives in the “Documentation” tab.

Status lifecycle

Every node has a status. Agents drive it explicitly via update_node_status. Progress (0..100) is set separately for long tasks via update_node_progress.

Backlog

backlog

Not started.

Planning

planning

Being decomposed / specced.

In progress

in_progress

Actively worked on.

Testing

testing

Implementation done, under verification.

Regression

regression

Verification found issues, being fixed.

Done

done

Complete and verified.

Blocked

blocked

Cannot proceed — always explain why in a comment.

Links between nodes

Beyond the parent → child hierarchy, nodes connect in three more ways. Every link shows up in the node detail and on the interactive graph.

Dependencies

A directed “A depends on B” edge: B is the blocker and must be finished before A. Defines execution order between tasks (add_dependency, where from_node depends on to_node).

References

Bidirectional cross-links between nodes: outgoing and incoming (backlinks). Set via set_references.

Typed relations

Semantic edges: blocks / blocked_by, depends_on / depended_by, related_to, duplicates / duplicated_by, parent_of / child_of. Bidirectional, set via add_relation.