381 lines
4.9 KiB
Markdown
381 lines
4.9 KiB
Markdown
# 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.
|