4.9 KiB
Implementation Ticket Breakdown and Dependency Matrix
Date: 2026-04-14
Status: Draft implementation artifact
Purpose: Convert the biomimetic architecture into an execution-ready ticket graph with dependencies, gating logic, and parallelization boundaries.
1. Purpose
This document is the handoff layer between architecture and implementation management. It defines what tickets exist, what depends on what, and what can be built in parallel without creating merge chaos.
2. Dependency Rules
The system should be built in layers.
Layer 1:
- contracts
- root schema
- root repository
Layer 2:
- root gateway and routes
- colony service bootstrap
- root client and persistence facades
Layer 3:
- planner
- prompt master
- librarian
Layer 4:
- researcher
- workers
- scheduler
Layer 5:
- aggregation
- reviewer
- policy bridge
Layer 6:
- Oracle adapter
- CRM adapter
- Catalyst adapter
Layer 7:
- observability
- release operations
- operator tooling
3. Ticket Matrix
T1. Contract Layer
Scope:
- create or finalize TypeScript contracts and Zod schemas
- align contracts with mission schema doc
Depends on:
- none
Blocks:
- all runtime work
T2. Root Database Schema
Scope:
- create
backend/db/schema_colony.sql - add indexes
Depends on:
- T1
Blocks:
- repository and root APIs
T3. Root Repository
Scope:
- implement
colony_repository.py
Depends on:
- T2
Blocks:
- gateway, routes, approval flows
T4. Colony Service Bootstrap
Scope:
- scaffold
services/colony-orchestrator - add
app.ts,index.ts, health route
Depends on:
- T1
Blocks:
- service-side feature tickets
T5. Python Root Client and Persistence Facades
Scope:
- implement
python-root-client.ts - implement
mission-store.ts - implement
artifact-store.ts
Depends on:
- T3
- T4
Blocks:
- planner-through-review pipeline
T6. Root Gateway and Routes
Scope:
- implement
colony_gateway.py - implement
routes_colony.py - mount in
backend/main.py
Depends on:
- T3
- T4
Blocks:
- external mission initiation
T7. Planner
Scope:
- mission normalization
- task DAG generation
Depends on:
- T1
- T5
Blocks:
- prompt master
- worker execution
T8. Prompt Master
Scope:
- template registry
- exemplar registry
- prompt package builder
Depends on:
- T7
Blocks:
- worker execution
T9. Librarian
Scope:
- source catalog
- route-card builder
- cache index
Depends on:
- T7
Blocks:
- worker execution
T10. Researcher
Scope:
- search provider abstraction
- browser provider abstraction
- citation normalization
Depends on:
- T1
- T5
Blocks:
- research-enabled missions
T11. Workers and Scheduler
Scope:
- worker factory
- scheduler
- worker runner
Depends on:
- T8
- T9
Blocks:
- aggregation
T12. Aggregation and Review
Scope:
- aggregator
- contradiction detector
- reviewer
- release gate
Depends on:
- T11
Blocks:
- reviewed output delivery
T13. Policy and Governance Bridge
Scope:
- risk classifier
- tool policy
- model routing policy
- writeback policy
Depends on:
- T6
- T12
Blocks:
- production-grade release
T14. Oracle Adapter
Scope:
- map Oracle prompt flow to colony missions
Depends on:
- T12
- T13
T15. CRM Adapter
Scope:
- map CRM lead intelligence flow to colony missions
Depends on:
- T12
- T13
T16. Catalyst Adapter
Scope:
- map Catalyst strategy missions
Depends on:
- T12
- T13
T17. Observability and Operations
Scope:
- traces
- metrics
- runbooks
- release dashboards
Depends on:
- T6
- T12
T18. Sales Demo Readiness
Scope:
- curated demo missions
- operator script
- approval queue visibility
- artifact inspection path
Depends on:
- T14
- T15
- T17
4. Parallelization Guidance
Safe parallel tracks:
- T2 and T4 after T1
- T7 and T10 after prerequisite facades exist
- T14 and T15 after core and governance are stable
Unsafe parallel tracks:
- implementing adapters before contracts stabilize
- building reviewer before worker result contract exists
- building production demo flows before observability exists
5. Acceptance Gates by Ticket Group
Gate A:
- T1 through T6 complete
- root and service are connected
Gate B:
- T7 through T12 complete
- one reviewed mission can execute end to end
Gate C:
- T13 through T15 complete
- one Oracle and one CRM mission are governed
Gate D:
- T17 and T18 complete
- system is demo-safe and sales-usable
6. Suggested Ownership Split
- engineer 1: root schema, repository, gateway, routes
- engineer 2: service bootstrap, contracts, persistence facades
- engineer 3: planner, prompt master, librarian
- engineer 4: workers, aggregation, review
- engineer 5: governance, adapters, observability
If the team is smaller, keep ownership by layer, not by file count.
7. Bottom Line
This dependency matrix should be used to create actual tickets. It keeps the team from building the colony out of order and makes it clear what can proceed in parallel without damaging the architecture.