Architecture Decision Records (ADRs)
This directory contains Architecture Decision Records that document significant design decisions in Tasker Core. Each ADR captures the context, decision, and consequences of a specific architectural choice.
ADR Index
Active Decisions
| ADR | Title | Date | Status |
|---|---|---|---|
| ADR-001 | Actor-Based Orchestration Architecture | 2025-10 | Accepted |
| ADR-002 | Bounded MPSC Channels | 2025-10 | Accepted |
| ADR-003 | Processor UUID Ownership Removal | 2025-10 | Accepted |
| ADR-004 | Backoff Strategy Consolidation | 2025-10 | Accepted |
| ADR-005 | Worker Dual-Channel Event System | 2025-12 | Accepted |
| ADR-006 | Worker Actor-Service Decomposition | 2025-12 | Accepted |
| ADR-007 | FFI Over WASM for Language Workers | 2025-12 | Accepted |
| ADR-008 | Handler Composition Pattern | 2025-12 | Accepted |
Root Cause Analyses
| Document | Title | Date |
|---|---|---|
| RCA | Parallel Execution Timing Bugs | 2025-12 |
ADR Template
When creating a new ADR, use this template:
# ADR: [Title]
**Status**: [Proposed | Accepted | Deprecated | Superseded]
**Date**: YYYY-MM-DD
**Ticket**: TAS-XXX
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?
### Positive
- Benefit 1
- Benefit 2
### Negative
- Trade-off 1
- Trade-off 2
### Neutral
- Side effect that is neither positive nor negative
## Alternatives Considered
What other options were considered and why were they rejected?
### Alternative 1: [Name]
Description and why it was rejected.
### Alternative 2: [Name]
Description and why it was rejected.
## References
- Related documents
- External references
When to Create an ADR
Create an ADR when:
- Making a significant architectural change that affects multiple components
- Choosing between alternatives with meaningful trade-offs
- Establishing a pattern that should be followed consistently
- Removing or deprecating an existing pattern or approach
- Learning from an incident (RCA format)
Don’t create an ADR for:
- Minor implementation details
- Bug fixes without architectural impact
- Documentation updates
- Routine refactoring
Related Documentation
- Tasker Core Tenets - Core design principles