Add plan 13: Taskboard/Kanban Dynamic Project Orchestration

2026-02-17 01:27:54 +00:00
parent 89e0ffbbf2
commit 97fe055b8d
1 changed files with 215 additions and 0 deletions
--- a/docs/hq/13-TASKBOARD-KANBAN-DYNAMIC-PROJECT-ORCHESTRATION.md
+++ b/docs/hq/13-TASKBOARD-KANBAN-DYNAMIC-PROJECT-ORCHESTRATION.md
@@ -0,0 +1,215 @@
+---
+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)