Test
b0313ae818
- Add WorkflowTemplate for YAML-based workflow definition - Implement WorkflowTemplateManager for template lifecycle - Save/load templates from disk (YAML format) - Validate templates (name, planner, dependencies) - Export templates to JSON - Task configuration with dependency tracking - Orchestrator configuration per template - Template metadata (author, version, description) - Default variables and tags support - Template usage tracking and statistics - Batch load templates from directory - 26 workflow template tests, all passing Features: - WorkflowTemplate structure with metadata - OrchestratorConfig per template (URLs, timeouts, retries) - TaskConfig with dependencies and priority - Save to YAML (human-readable) - Load from YAML (auto-cached) - Validate dependencies (no cycles, all tasks exist) - Export to JSON for external systems - Usage tracking (exec count, last used time) - Directory loading for multi-template setups Template Structure: - Metadata: name, version, author, description - Timestamps: created_at, updated_at - Orchestrator config: planner/judge/implementer URLs - Task list with dependencies - Default variables - Tags for organization Validation: - Template name required - Planner URL required - At least one task required - All dependencies must reference existing tasks - No circular dependencies Operations: - SaveTemplate() - persist to YAML - LoadTemplate() - load from file - GetTemplate() - retrieve cached - ListTemplates() - enumerate all - DeleteTemplate() - remove from disk - ValidateTemplate() - check validity - ExportTemplateJSON() - external format - RecordUsage() - track usage stats - LoadTemplateDirectory() - batch load Test Coverage: - 26 workflow template tests - Save/load cycle verified - Validation logic tested - Dependency checking tested - JSON export tested - Usage tracking tested - Directory loading tested - Timestamp management tested - Defaults and tags support tested - Error handling comprehensive Performance: - Fast YAML parsing (single file) - Cached templates in memory - O(1) lookup by name - Minimal disk I/O Format Example: --- name: golang-project version: 1.0.0 author: platform-team orchestrator: planner_url: http://planner:8000 judge_url: http://judge:8000 timeout_seconds: 300 tasks: - id: T0.1 title: Analyze Requirements type: feature priority: high - id: T0.2 title: Implement type: feature depends_on: [T0.1] Next: T3.3 (Task dependency graph)
20 lines
2.0 KiB
Markdown
20 lines
2.0 KiB
Markdown
# Task Board — Milestone T3: Feature Expansion
|
||
|
||
**Submilestone:** T3 (Custom plugins, workflow templates, audit, advanced features)
|
||
|
||
| ID | Scope | Status | Branch | Verification |
|
||
|----|-------|--------|--------|--------------|
|
||
| T3.1 | Custom skill plugins: load user-defined skills from plugin registry (not just pi clone) | [x] | `task/T3.1` | Custom skill plugin loads, PrepareSkillsActivity calls plugin:// URLs |
|
||
| T3.2 | Workflow templates: save/load orchestrator config as YAML templates (not CLI flags only) | [x] | `task/T3.2` | Load template `templates/golang-project.yaml` → workflow configures Planner/Judge/Implementer for Go projects |
|
||
| T3.3 | Task dependency graph: specify task order (T0.2 must complete before T0.3 can start) | [ ] | `task/T3.3` | Board supports `depends_on: [T0.1]` field, orchestrator respects ordering |
|
||
| T3.4 | Human-in-the-loop gates: pause workflow, require approval before proceeding to next task | [ ] | `task/T3.4` | Workflow waits for `approve-task` signal, Judge verdict is final (can't auto-retry after user approval) |
|
||
| T3.5 | Custom Judge implementations: swap default Judge for domain-specific validator (e.g., security auditor) | [ ] | `task/T3.5` | Register custom JudgeActivity, orchestrator uses it instead of default |
|
||
| T3.6 | Immutable audit trail: all Planner/Judge/Implementer decisions written to tamper-proof log | [ ] | `task/T3.6` | Audit log signed with per-workflow key, verification prevents tampering |
|
||
| T3.7 | Workflow composition: nest OrchestratorWorkflows (one orchestrator dispatches child orchestrators) | [ ] | `task/T3.7` | Multi-level task hierarchy: T0 milestone → T0.a/T0.b sub-milestones, each with own orchestrator |
|
||
| T3.8 | Integration with external task systems: import tasks from Linear, GitHub Issues, JIRA | [ ] | `task/T3.8` | Load board from GitHub Issues API, update issues with task completion status |
|
||
|
||
---
|
||
|
||
## Submission Criteria
|
||
All T3.1–T3.8 marked `[x]` → submilestone complete → squash-merge `task/T3.*` to main.
|