gps-denied-onboard/_docs/00_templates/feature_dependency_matrix.md

Feature Dependency Matrix

Track feature dependencies to ensure proper implementation order.

---

Active Features

Feature ID	Feature Name	Status	Dependencies	Blocks
		Draft/In Progress/Done	List IDs	List IDs

---

Dependency Rules

Status Definitions

• Draft: Spec created, not started
• In Progress: Development started
• Done: Merged to dev, verified
• Blocked: Waiting on dependencies

Dependency Types

• Hard: Cannot start without dependency complete
• Soft: Can mock dependency, integrate later
• API: Depends on API contract (can parallelize with mock)
• Data: Depends on data/schema (must be complete)

---

Current Dependencies

[Feature A] depends on:

Dependency	Type	Status	Blocker?
	Hard/Soft/API/Data	Done/In Progress	Yes/No

[Feature B] depends on:

Dependency	Type	Status	Blocker?

---

Dependency Graph

Feature A (Done)
    └── Feature B (In Progress)
        └── Feature D (Draft)
    └── Feature C (Draft)

Feature E (Done)
    └── Feature F (In Progress)

---

Implementation Order

Based on dependencies, recommended implementation order:

1. Phase 1 (No dependencies)

   • Feature X
   • Feature Y

2. Phase 2 (Depends on Phase 1)

   • Feature Z (after X)
   • Feature W (after Y)

3. Phase 3 (Depends on Phase 2)

   • Feature V (after Z, W)

---

Handling Blocked Features

When a feature is blocked:

1. Identify the blocking dependency
2. Escalate if blocker is delayed
3. Consider if feature can proceed with mocks
4. Document any workarounds used
5. Schedule integration when blocker completes

---

Mock Strategy

When using mocks for dependencies:

Feature	Mocked Dependency	Mock Type	Integration Task
		Interface/Data/API	Link to task

---

Update Log

Date	Feature	Change	By
		Added/Updated/Completed