---
tags:
  - Project/Atomizer
  - Agentic
  - Orchestration
  - Plan
date: 2026-02-17
status: planning
owner: 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.

```json
{
  "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:
```markdown
## [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 `#project-dashboard`
- 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 |
| `#project-dashboard` | 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 `#project-dashboard` 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)