Use YYLO Ledger as the source of truth for agent work

A task system becomes useful to agents when its state is structured enough to query and strict enough not to depend on Markdown formatting conventions.

Separate three relationships

• blocked_by controls readiness and execution order.
• related_tasks links useful context without blocking work.
• commit_hash ties a completed response to repository evidence.

./.juno_task/scripts/kanban.sh deps TASK_ID
./.juno_task/scripts/kanban.sh ready --sort asc
./.juno_task/scripts/kanban.sh order --scores

Move through explicit states

./.juno_task/scripts/kanban.sh mark in_progress --id TASK_ID --response "Starting the exact scoped gate"
./.juno_task/scripts/kanban.sh get TASK_ID --compact
./.juno_task/scripts/kanban.sh mark done --id TASK_ID --response-file evidence.md --commit abc123

One task in progress per agent keeps ownership legible. Mark done only after the task’s gate passes; otherwise record a blocker and leave the task open.

Query deterministically

list, search, and ready share ascending/descending last_modified sorting with task ID as a tie-breaker. When status filters are supplied, their explicit group order is preserved.

Keep the response useful

A strong completion response states what changed, the exact commands and browser checks that passed, and any remaining risk. It does not paste uncurated logs or claim success from an exit code that was never observed. See the YYLO Ledger documentation for file-safe response forms.