Native task-graph + ready-queue (beads-inspired) for cross-agent handoff: joint rec with taOSmd

[jaylfc]

Decision needed (Jay): buy vs build. Joint recommendation from @taos + @taOSmd: BUILD thin-native.

Problem

Rate-limit-hopping agents need a dependency-aware task list with a computed ready-queue (what is unblocked that I can pick up right now). Flat GitHub issues do not express dependencies or compute that. We evaluated beads (github.com/gastownhall/beads, a mature MIT Go CLI+MCP, Dolt-backed agent-native dependency-graph tracker).

Why build, not adopt beads

• SBC weight: beads needs Dolt (a versioned Go SQL engine, hundreds of MB working set, a second always-on daemon, unhappy on SD-card IO). That violates the Pi-tier lean-core mission (taosmd is stdlib + sqlite by design; the hive premise is ONE local server).
• Archive-consolidation loop: a native task layer writes its events into taosmd's zero-loss archive, so the v2 memory engine can learn over work history (what recurs, what blocks what, who finishes what). A bolted-on beads can never feed that loop. This tips build over buy despite beads maturity.
• No second source of truth: beads ships its own messaging + memory-decay; we keep our A2A bus + taosmd memory as source of truth and take only the concepts.

What we build (thin-native, in taosmd, concepts credited to beads)

• tasks table + typed dependency edges (blocks, parent-child, discovered-from, etc.)
• ready-queue as a SQL view (open tasks with no open blockers)
• collision-free content-hash IDs (same trick as taosmd /ingest/batch dedup) for concurrent multi-agent writes
• a prime endpoint emitting 1-2k tokens of ready/blocked context for session bootstrap
• CLI + MCP tools
• events land in the zero-loss archive (feeds the v2 memory engine)
• reuse what we own: A2A bus (notifications), project ids (scoping), agents registry (assignees), archive (audit trail)

What we skip

Dolt's git-like branch/merge of the task DB (it solves offline multi-clone sync; our agents share one live Pi server; archive replay covers it if ever needed).

Next

taOSmd drafts the schema + endpoints PR proposal on the taosmd side; taOS wires the Tasks-app + handoff-bootstrap consumption side. Awaiting Jay greenlight. Ties into #741 (resilience workflow) and #735 (feedback tracker shares the surface).

[jaylfc]

taOSmd task-graph contract drafted (spec: taosmd docs/superpowers/specs/2026-06-10-task-graph-design.md, commit 1cb0112, status PROPOSAL)

Recording the endpoint contract so the taOS consumption side is ready to wire on greenlight. taOSmd builds the server side; taOS builds the Tasks app + handoff-bootstrap consumption.

7 endpoints: POST /tasks, GET /tasks, GET /tasks/ready, GET /tasks/prime -> {text, tasks}, POST /tasks/{id}, edge add, edge remove.
IDs: content-hash, t- prefix, sha256(title|project|created_ts)[:12] (collision-free for concurrent multi-agent writes).
Edge types: blocks | parent | relates | duplicates, with soft-removal.
ready = open tasks with no active open blocker.
prime = token-budgeted briefing (ready / in-progress / blocked / recently-closed) for session bootstrap.
Durability: every mutation is an append-only archive event; the sqlite tables are a replayable projection (free audit trail + feeds the future consolidation engine).
Scoping: binds to the verified project_id claim from the #744 contract, so one grant gates memory AND tasks.

taOS consumption-side build (on greenlight)

1. Tasks app (desktop): render ready / in-progress / blocked / done, create + edit tasks, add/remove dependency edges. Use the frontend-design skill.
2. Handoff bootstrap: add a step that calls GET /tasks/prime so an incoming agent gets the unblocked queue injected automatically (replaces/augments the manual "pick the top unblocked issue" step in AGENT_HANDOFF.md).
3. Optional: bridge GitHub issues <-> tasks, or keep issues as the human-facing backlog and tasks as the agent execution graph (decide with Jay).