Atomizer/docs/hq/13-TASKBOARD-KANBAN-DYNAMIC-PROJECT-ORCHESTRATION.md

tags, date, status, owner

tags	date	status	owner
Project/Atomizer Agentic Orchestration Plan	2026-02-17	planning	Antoine + Mario

13 — Taskboard / Kanban / Dynamic Project Orchestration

Problem Statement

The current orchestration is broken. Agents exist, delegation works mechanically (hooks API), but there's no structured workflow tying it together. PROJECT_STATUS.md is a flat file that Manager edits manually — it's not a real kanban. There's no enforced flow from task creation → assignment → execution → deliverable → summary. Deliverables land wherever instead of in the right Discord channels. Antoine has no visibility into what Manager is planning or how agents are being pulled.

What we need: A file-based taskboard that serves as the orchestration backbone — agents read it, update it, and Manager uses it to drive all collaboration. The frontend dashboard is secondary; the data and workflow come first.

---

Architecture

1. Taskboard: shared/taskboard.json

Single source of truth for all active work. JSON array of task objects.

{
  "version": 1,
  "lastUpdated": "2026-02-17T01:00:00Z",
  "updatedBy": "manager",
  "tasks": [
    {
      "id": "TASK-001",
      "title": "Research Clearceram-Z HS thermal properties",
      "description": "Full thermal property comparison: CTE, conductivity, diffusivity for CCZ HS vs Zerodur Class 0",
      "status": "in-progress",
      "priority": "high",
      "assignee": "webster",
      "requestedBy": "manager",
      "project": "gigabit-m2",
      "deliverable": {
        "type": "analysis",
        "targetChannel": "technical",
        "format": "Discord post with data table"
      },
      "created": "2026-02-17T01:00:00Z",
      "updated": "2026-02-17T01:15:00Z",
      "dueBy": null,
      "notes": [],
      "completedAt": null
    }
  ]
}

Task Schema

Field	Type	Description
id	string	Auto-incremented TASK-NNN
title	string	Short description
description	string	Full context for the assignee
status	enum	backlog → todo → in-progress → review → done → cancelled
priority	enum	critical, high, medium, low
assignee	string	Agent name (or antoine for CEO tasks)
requestedBy	string	Who created it
project	string	Project tag for grouping
deliverable.type	enum	document, code, analysis, recommendation, review, data
deliverable.targetChannel	string	Discord channel where result gets posted
deliverable.format	string	Expected output format
created	ISO datetime	When task was created
updated	ISO datetime	Last status change
dueBy	ISO datetime or null	Deadline if any
notes	array of strings	Status updates, blockers, progress notes
completedAt	ISO datetime or null	When marked done

Status Flow

backlog → todo → in-progress → review → done
                      ↓                   
                  cancelled              

• backlog: Identified but not yet prioritized
• todo: Ready to be picked up
• in-progress: Agent is actively working
• review: Deliverable produced, awaiting Manager/Antoine review
• done: Accepted and posted to Discord
• cancelled: Dropped (with reason in notes)

2. Orchestration Plan: shared/orchestration-log.md

Append-only log where Manager posts orchestration plans before kicking off work. This gives Antoine visibility into what's happening and why.

Format:

## [2026-02-17 01:00] Orchestration: Material Comparison for M2/M3

**Objective:** Compare Zerodur Class 0 vs Clearceram-Z HS for M2/M3 mirrors
**Tasks created:** TASK-001, TASK-002, TASK-003
**Agent assignments:**
- Webster → material property research (TASK-001)
- Tech-Lead → structural impact analysis (TASK-002)  
- Secretary → compile final comparison report (TASK-003, after 001+002)

**Dependencies:** TASK-003 waits on TASK-001 + TASK-002
**Expected output:** Comparison report in #reports, raw data in #technical
**ETA:** ~2 hours

---

3. Agent Protocols

Manager (orchestrator)

• ONLY writer of taskboard.json (creates, assigns, updates status)
• Posts orchestration plans to orchestration-log.md before delegating
• Posts orchestration summaries to Discord #feed
• Reviews deliverables before marking tasks done
• Reads project_log.md for agent status updates

Assigned Agents (executor)

• Read their tasks from taskboard.json (filter by assignee)
• Append progress to shared/project_log.md (append-only, never edit taskboard directly)
• Post deliverables to the deliverable.targetChannel specified in the task
• Log format: [YYYY-MM-DD HH:MM] [agent] TASK-NNN: <update>

Secretary (condensation)

• After orchestration chains complete, Secretary must be the final step
• Reads completed tasks + deliverables from the chain
• Produces a condensation/summary
• Posts distillate to Discord #reports
• Updates shared/orchestration-log.md with completion status

4. Deliverable Routing

Every deliverable has a home. Manager specifies the target channel when creating the task.

Deliverable Type	Default Channel	Description
document	#reports	Reports, summaries, formal docs
code	#technical	Scripts, configs, implementations
analysis	#technical	FEA results, data analysis, comparisons
recommendation	#reports	Decision support, trade studies
review	#reports	Audits, quality checks
data	#knowledge-base	Raw data, material properties, reference info

Manager can override the default channel per task.

5. Discord Channel Usage (refined)

Channel	Purpose	Who Posts
#reports	Final summaries, orchestration distillates	Secretary (primary), Manager
#feed	Orchestration plans, sprint status, kanban snapshots	Manager
#technical	Technical work, analysis results, code	Tech-Lead, Optimizer, NX-Expert, Webster
#knowledge-base	Permanent reference data, lessons learned	Any agent
#announcements	Major decisions, milestones	Manager, Antoine
#agent-logs	Verbose process logs (not for Antoine)	Any agent

---

Implementation Plan

Phase 1: Foundation (immediate)

1. Create shared/taskboard.json with empty task list
2. Create shared/orchestration-log.md
3. Create shared/skills/taskboard/ — shell scripts for agents to:
   • read-tasks.sh <agent> — list my assigned tasks
   • update-status.sh <task-id> <status> [note] — log progress (appends to project_log.md)
   • create-task.sh — Manager only, adds task to taskboard
   • complete-task.sh <task-id> — Manager only, marks done
4. Update Manager's AGENTS.md with orchestration protocol
5. Update Secretary's AGENTS.md with condensation protocol
6. Update all agents' AGENTS.md with task-reading protocol

Phase 2: Workflow enforcement

1. Manager HEARTBEAT checks taskboard for stale tasks (in-progress > 4h with no updates)
2. Secretary HEARTBEAT checks for completed orchestration chains needing condensation
3. Kanban snapshot posted to #feed by Manager (daily or on-demand)

Phase 3: Dashboard integration (later, CEO view)

1. Dashboard backend reads taskboard.json directly
2. Frontend renders kanban board
3. Antoine can view/filter tasks, see agent activity
4. Eventually: approve/reject deliverables from dashboard

---

Key Principles

1. File-based, not API-based — taskboard.json is the single source of truth. No database needed. Every agent can read it. Only Manager writes it.
2. Append-only logs — Agents never edit shared state directly. They append to project_log.md. Manager synthesizes.
3. Orchestration plans are visible — Manager always posts the plan before executing. Antoine sees what's coming.
4. Secretary is always the last step — Every orchestration chain ends with Secretary producing a readable summary for Discord.
5. Deliverables go to the right place — Target channel is part of the task definition, not an afterthought.
6. Progressive automation — Start with scripts + protocols. Dashboard frontend comes later when the workflow is proven.

---

Dependencies

• Delegate skill already works (hooks API)
• Discord channels exist
• Agent workspaces exist
• project_log.md append pattern already in use

Risks

• Agents may not reliably read taskboard on every session (mitigate: add to HEARTBEAT.md)
• JSON file corruption if multiple writers (mitigate: Manager is sole writer)
• Task staleness if agents don't report progress (mitigate: Manager heartbeat checks)