mirror of
https://github.com/azaion/annotations.git
synced 2026-04-22 10:56:31 +00:00
Refactor annotation tool from WPF desktop app to .NET API
Replace the WPF desktop application (Azaion.Suite, Azaion.Annotator, Azaion.Common, Azaion.Inference, Azaion.Loader, Azaion.LoaderUI, Azaion.Dataset, Azaion.Test) with a standalone .NET Web API in src/. Made-with: Cursor
This commit is contained in:
Oleksandr Bezdieniezhnykh
@@ -0,0 +1,281 @@
|
||||
---
|
||||
name: decompose
|
||||
description: |
|
||||
Decompose planned components into atomic implementable features with bootstrap structure plan.
|
||||
4-step workflow: bootstrap structure plan, feature decomposition, cross-component verification, and Jira task creation.
|
||||
Supports project mode (_docs/ structure), single component mode, and standalone mode (@file.md).
|
||||
Trigger phrases:
|
||||
- "decompose", "decompose features", "feature decomposition"
|
||||
- "task decomposition", "break down components"
|
||||
- "prepare for implementation"
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# Feature Decomposition
|
||||
|
||||
Decompose planned components into atomic, implementable feature specs with a bootstrap structure plan through a systematic workflow.
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **Atomic features**: each feature does one thing; if it exceeds 5 complexity points, split it
|
||||
- **Behavioral specs, not implementation plans**: describe what the system should do, not how to build it
|
||||
- **Save immediately**: write artifacts to disk after each component; never accumulate unsaved work
|
||||
- **Ask, don't assume**: when requirements are ambiguous, ask the user before proceeding
|
||||
- **Plan, don't code**: this workflow produces documents and Jira tasks, never implementation code
|
||||
|
||||
## Context Resolution
|
||||
|
||||
Determine the operating mode based on invocation before any other logic runs.
|
||||
|
||||
**Full project mode** (no explicit input file provided):
|
||||
- PLANS_DIR: `_docs/02_plans/`
|
||||
- TASKS_DIR: `_docs/02_tasks/`
|
||||
- Reads from: `_docs/00_problem/`, `_docs/01_solution/`, PLANS_DIR
|
||||
- Runs Step 1 (bootstrap) + Step 2 (all components) + Step 3 (cross-verification) + Step 4 (Jira)
|
||||
|
||||
**Single component mode** (provided file is within `_docs/02_plans/` and inside a `components/` subdirectory):
|
||||
- PLANS_DIR: `_docs/02_plans/`
|
||||
- TASKS_DIR: `_docs/02_tasks/`
|
||||
- Derive `<topic>`, component number, and component name from the file path
|
||||
- Ask user for the parent Epic ID
|
||||
- Runs Step 2 (that component only) + Step 4 (Jira)
|
||||
- Overwrites existing feature files in that component's TASKS_DIR subdirectory
|
||||
|
||||
**Standalone mode** (explicit input file provided, not within `_docs/02_plans/`):
|
||||
- INPUT_FILE: the provided file (treated as a component spec)
|
||||
- Derive `<topic>` from the input filename (without extension)
|
||||
- TASKS_DIR: `_standalone/<topic>/tasks/`
|
||||
- Guardrails relaxed: only INPUT_FILE must exist and be non-empty
|
||||
- Ask user for the parent Epic ID
|
||||
- Runs Step 2 (that component only) + Step 4 (Jira)
|
||||
|
||||
Announce the detected mode and resolved paths to the user before proceeding.
|
||||
|
||||
## Input Specification
|
||||
|
||||
### Required Files
|
||||
|
||||
**Full project mode:**
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| `_docs/00_problem/problem.md` | Problem description and context |
|
||||
| `_docs/00_problem/restrictions.md` | Constraints and limitations (if available) |
|
||||
| `_docs/00_problem/acceptance_criteria.md` | Measurable acceptance criteria (if available) |
|
||||
| `_docs/01_solution/solution.md` | Finalized solution |
|
||||
| `PLANS_DIR/<topic>/architecture.md` | Architecture from plan skill |
|
||||
| `PLANS_DIR/<topic>/system-flows.md` | System flows from plan skill |
|
||||
| `PLANS_DIR/<topic>/components/[##]_[name]/description.md` | Component specs from plan skill |
|
||||
|
||||
**Single component mode:**
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| The provided component `description.md` | Component spec to decompose |
|
||||
| Corresponding `tests.md` in the same directory (if available) | Test specs for context |
|
||||
|
||||
**Standalone mode:**
|
||||
|
||||
| File | Purpose |
|
||||
|------|---------|
|
||||
| INPUT_FILE (the provided file) | Component spec to decompose |
|
||||
|
||||
### Prerequisite Checks (BLOCKING)
|
||||
|
||||
**Full project mode:**
|
||||
1. At least one `<topic>/` directory exists under PLANS_DIR with `architecture.md` and `components/` — **STOP if missing**
|
||||
2. If multiple topics exist, ask user which one to decompose
|
||||
3. Create TASKS_DIR if it does not exist
|
||||
4. If `TASKS_DIR/<topic>/` already exists, ask user: **resume from last checkpoint or start fresh?**
|
||||
|
||||
**Single component mode:**
|
||||
1. The provided component file exists and is non-empty — **STOP if missing**
|
||||
2. Create the component's subdirectory under TASKS_DIR if it does not exist
|
||||
|
||||
**Standalone mode:**
|
||||
1. INPUT_FILE exists and is non-empty — **STOP if missing**
|
||||
2. Create TASKS_DIR if it does not exist
|
||||
|
||||
## Artifact Management
|
||||
|
||||
### Directory Structure
|
||||
|
||||
```
|
||||
TASKS_DIR/<topic>/
|
||||
├── initial_structure.md (Step 1, full mode only)
|
||||
├── cross_dependencies.md (Step 3, full mode only)
|
||||
├── SUMMARY.md (final)
|
||||
├── [##]_[component_name]/
|
||||
│ ├── [##].[##]_feature_[feature_name].md
|
||||
│ ├── [##].[##]_feature_[feature_name].md
|
||||
│ └── ...
|
||||
├── [##]_[component_name]/
|
||||
│ └── ...
|
||||
└── ...
|
||||
```
|
||||
|
||||
### Save Timing
|
||||
|
||||
| Step | Save immediately after | Filename |
|
||||
|------|------------------------|----------|
|
||||
| Step 1 | Bootstrap structure plan complete | `initial_structure.md` |
|
||||
| Step 2 | Each component decomposed | `[##]_[name]/[##].[##]_feature_[feature_name].md` |
|
||||
| Step 3 | Cross-component verification complete | `cross_dependencies.md` |
|
||||
| Step 4 | Jira tasks created | Jira via MCP |
|
||||
| Final | All steps complete | `SUMMARY.md` |
|
||||
|
||||
### Resumability
|
||||
|
||||
If `TASKS_DIR/<topic>/` already contains artifacts:
|
||||
|
||||
1. List existing files and match them to the save timing table
|
||||
2. Identify the last completed component based on which feature files exist
|
||||
3. Resume from the next incomplete component
|
||||
4. Inform the user which components are being skipped
|
||||
|
||||
## Progress Tracking
|
||||
|
||||
At the start of execution, create a TodoWrite with all applicable steps. Update status as each step/component completes.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Bootstrap Structure Plan (full project mode only)
|
||||
|
||||
**Role**: Professional software architect
|
||||
**Goal**: Produce `initial_structure.md` describing the project skeleton for implementation
|
||||
**Constraints**: This is a plan document, not code. The `implement-initial` command executes it.
|
||||
|
||||
1. Read architecture.md, all component specs, and system-flows.md from PLANS_DIR
|
||||
2. Read problem, solution, and restrictions from `_docs/00_problem/` and `_docs/01_solution/`
|
||||
3. Research best implementation patterns for the identified tech stack
|
||||
4. Document the structure plan using `templates/initial-structure.md`
|
||||
|
||||
**Self-verification**:
|
||||
- [ ] All components have corresponding folders in the layout
|
||||
- [ ] All inter-component interfaces have DTOs defined
|
||||
- [ ] CI/CD stages cover build, lint, test, security, deploy
|
||||
- [ ] Environment strategy covers dev, staging, production
|
||||
- [ ] Test structure includes unit and integration test locations
|
||||
|
||||
**Save action**: Write `initial_structure.md`
|
||||
|
||||
**BLOCKING**: Present structure plan summary to user. Do NOT proceed until user confirms.
|
||||
|
||||
---
|
||||
|
||||
### Step 2: Feature Decomposition (all modes)
|
||||
|
||||
**Role**: Professional software architect
|
||||
**Goal**: Decompose each component into atomic, implementable feature specs
|
||||
**Constraints**: Behavioral specs only — describe what, not how. No implementation code.
|
||||
|
||||
For each component (or the single provided component):
|
||||
|
||||
1. Read the component's `description.md` and `tests.md` (if available)
|
||||
2. Decompose into atomic features; create only 1 feature if the component is simple or atomic
|
||||
3. Split into multiple features only when it is necessary and would be easier to implement
|
||||
4. Do not create features of other components — only features of the current component
|
||||
5. Each feature should be atomic, containing 0 APIs or a list of semantically connected APIs
|
||||
6. Write each feature spec using `templates/feature-spec.md`
|
||||
7. Estimate complexity per feature (1, 2, 3, 5 points); no feature should exceed 5 points — split if it does
|
||||
8. Note feature dependencies (within component and cross-component)
|
||||
|
||||
**Self-verification** (per component):
|
||||
- [ ] Every feature is atomic (single concern)
|
||||
- [ ] No feature exceeds 5 complexity points
|
||||
- [ ] Feature dependencies are noted
|
||||
- [ ] Features cover all interfaces defined in the component spec
|
||||
- [ ] No features duplicate work from other components
|
||||
|
||||
**Save action**: Write each `[##]_[name]/[##].[##]_feature_[feature_name].md`
|
||||
|
||||
---
|
||||
|
||||
### Step 3: Cross-Component Verification (full project mode only)
|
||||
|
||||
**Role**: Professional software architect and analyst
|
||||
**Goal**: Verify feature consistency across all components
|
||||
**Constraints**: Review step — fix gaps found, do not add new features
|
||||
|
||||
1. Verify feature dependencies across all components are consistent
|
||||
2. Check no gaps: every interface in architecture.md has features covering it
|
||||
3. Check no overlaps: features don't duplicate work across components
|
||||
4. Produce dependency matrix showing cross-component feature dependencies
|
||||
5. Determine recommended implementation order based on dependencies
|
||||
|
||||
**Self-verification**:
|
||||
- [ ] Every architecture interface is covered by at least one feature
|
||||
- [ ] No circular feature dependencies across components
|
||||
- [ ] Cross-component dependencies are explicitly noted in affected feature specs
|
||||
|
||||
**Save action**: Write `cross_dependencies.md`
|
||||
|
||||
**BLOCKING**: Present cross-component summary to user. Do NOT proceed until user confirms.
|
||||
|
||||
---
|
||||
|
||||
### Step 4: Jira Tasks (all modes)
|
||||
|
||||
**Role**: Professional product manager
|
||||
**Goal**: Create Jira tasks from feature specs under the appropriate parent epics
|
||||
**Constraints**: Be concise — fewer words with the same meaning is better
|
||||
|
||||
1. For each feature spec, create a Jira task following the parsing rules and field mapping from `gen_jira_task_and_branch.md` (skip branch creation and file renaming — those happen during implementation)
|
||||
2. In full mode: search Jira for epics matching component names/labels to find parent epic IDs
|
||||
3. In single component mode: use the Epic ID obtained during context resolution
|
||||
4. In standalone mode: use the Epic ID obtained during context resolution
|
||||
5. Do NOT create git branches or rename files — that happens during implementation
|
||||
|
||||
**Self-verification**:
|
||||
- [ ] Every feature has a corresponding Jira task
|
||||
- [ ] Every task is linked to the correct parent epic
|
||||
- [ ] Task descriptions match feature spec content
|
||||
|
||||
**Save action**: Jira tasks created via MCP
|
||||
|
||||
---
|
||||
|
||||
## Summary Report
|
||||
|
||||
After all steps complete, write `SUMMARY.md` using `templates/summary.md` as structure.
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
- **Coding during decomposition**: this workflow produces specs, never code
|
||||
- **Over-splitting**: don't create many features if the component is simple — 1 feature is fine
|
||||
- **Features exceeding 5 points**: split them; no feature should be too complex for a single task
|
||||
- **Cross-component features**: each feature belongs to exactly one component
|
||||
- **Skipping BLOCKING gates**: never proceed past a BLOCKING marker without user confirmation
|
||||
- **Creating git branches**: branch creation is an implementation concern, not a decomposition one
|
||||
|
||||
## Escalation Rules
|
||||
|
||||
| Situation | Action |
|
||||
|-----------|--------|
|
||||
| Ambiguous component boundaries | ASK user |
|
||||
| Feature complexity exceeds 5 points after splitting | ASK user |
|
||||
| Missing component specs in PLANS_DIR | ASK user |
|
||||
| Cross-component dependency conflict | ASK user |
|
||||
| Jira epic not found for a component | ASK user for Epic ID |
|
||||
| Component naming | PROCEED, confirm at next BLOCKING gate |
|
||||
|
||||
## Methodology Quick Reference
|
||||
|
||||
```
|
||||
┌────────────────────────────────────────────────────────────────┐
|
||||
│ Feature Decomposition (4-Step Method) │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ CONTEXT: Resolve mode (full / single component / standalone) │
|
||||
│ 1. Bootstrap Structure → initial_structure.md (full only) │
|
||||
│ [BLOCKING: user confirms structure] │
|
||||
│ 2. Feature Decompose → [##]_[name]/[##].[##]_feature_* │
|
||||
│ 3. Cross-Verification → cross_dependencies.md (full only) │
|
||||
│ [BLOCKING: user confirms dependencies] │
|
||||
│ 4. Jira Tasks → Jira via MCP │
|
||||
│ ───────────────────────────────────────────────── │
|
||||
│ Summary → SUMMARY.md │
|
||||
├────────────────────────────────────────────────────────────────┤
|
||||
│ Principles: Atomic features · Behavioral specs · Save now │
|
||||
│ Ask don't assume · Plan don't code │
|
||||
└────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
@@ -0,0 +1,108 @@
|
||||
# Feature Specification Template
|
||||
|
||||
Create a focused behavioral specification that describes **what** the system should do, not **how** it should be built.
|
||||
Save as `TASKS_DIR/<topic>/[##]_[component_name]/[##].[##]_feature_[feature_name].md`.
|
||||
|
||||
---
|
||||
|
||||
```markdown
|
||||
# [Feature Name]
|
||||
|
||||
**Status**: Draft | **Date**: [YYYY-MM-DD] | **Feature**: [Brief Feature Description]
|
||||
**Complexity**: [1|2|3|5] points
|
||||
**Dependencies**: [List dependent features or "None"]
|
||||
**Component**: [##]_[component_name]
|
||||
|
||||
## Problem
|
||||
|
||||
Clear, concise statement of the problem users are facing.
|
||||
|
||||
## Outcome
|
||||
|
||||
- Measurable or observable goal 1
|
||||
- Measurable or observable goal 2
|
||||
|
||||
## Scope
|
||||
|
||||
### Included
|
||||
- What's in scope for this feature
|
||||
|
||||
### Excluded
|
||||
- Explicitly what's NOT in scope
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
**AC-1: [Title]**
|
||||
Given [precondition]
|
||||
When [action]
|
||||
Then [expected result]
|
||||
|
||||
**AC-2: [Title]**
|
||||
Given [precondition]
|
||||
When [action]
|
||||
Then [expected result]
|
||||
|
||||
## Non-Functional Requirements
|
||||
|
||||
**Performance**
|
||||
- [requirement if relevant]
|
||||
|
||||
**Compatibility**
|
||||
- [requirement if relevant]
|
||||
|
||||
**Reliability**
|
||||
- [requirement if relevant]
|
||||
|
||||
## Unit Tests
|
||||
|
||||
| AC Ref | What to Test | Required Outcome |
|
||||
|--------|-------------|-----------------|
|
||||
| AC-1 | [test subject] | [expected result] |
|
||||
|
||||
## Integration Tests
|
||||
|
||||
| AC Ref | Initial Data/Conditions | What to Test | Expected Behavior | NFR References |
|
||||
|--------|------------------------|-------------|-------------------|----------------|
|
||||
| AC-1 | [setup] | [test subject] | [expected behavior] | [NFR if any] |
|
||||
|
||||
## Constraints
|
||||
|
||||
- [Architectural pattern constraint if critical]
|
||||
- [Technical limitation]
|
||||
- [Integration requirement]
|
||||
|
||||
## Risks & Mitigation
|
||||
|
||||
**Risk 1: [Title]**
|
||||
- *Risk*: [Description]
|
||||
- *Mitigation*: [Approach]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Complexity Points Guide
|
||||
|
||||
- 1 point: Trivial, self-contained, no dependencies
|
||||
- 2 points: Non-trivial, low complexity, minimal coordination
|
||||
- 3 points: Multi-step, moderate complexity, potential alignment needed
|
||||
- 5 points: Difficult, interconnected logic, medium-high risk
|
||||
- 8 points: Too complex — split into smaller features
|
||||
|
||||
## Output Guidelines
|
||||
|
||||
**DO:**
|
||||
- Focus on behavior and user experience
|
||||
- Use clear, simple language
|
||||
- Keep acceptance criteria testable (Gherkin format)
|
||||
- Include realistic scope boundaries
|
||||
- Write from the user's perspective
|
||||
- Include complexity estimation
|
||||
- Note dependencies on other features
|
||||
|
||||
**DON'T:**
|
||||
- Include implementation details (file paths, classes, methods)
|
||||
- Prescribe technical solutions or libraries
|
||||
- Add architectural diagrams or code examples
|
||||
- Specify exact API endpoints or data structures
|
||||
- Include step-by-step implementation instructions
|
||||
- Add "how to build" guidance
|
||||
@@ -0,0 +1,113 @@
|
||||
# Initial Structure Plan Template
|
||||
|
||||
Use this template for the bootstrap structure plan. Save as `TASKS_DIR/<topic>/initial_structure.md`.
|
||||
|
||||
---
|
||||
|
||||
```markdown
|
||||
# Initial Project Structure Plan
|
||||
|
||||
**Date**: [YYYY-MM-DD]
|
||||
**Tech Stack**: [language, framework, database, etc.]
|
||||
**Source**: architecture.md, component specs from _docs/02_plans/<topic>/
|
||||
|
||||
## Project Folder Layout
|
||||
|
||||
```
|
||||
project-root/
|
||||
├── [folder structure based on tech stack and components]
|
||||
└── ...
|
||||
```
|
||||
|
||||
### Layout Rationale
|
||||
|
||||
[Brief explanation of why this structure was chosen — language conventions, framework patterns, etc.]
|
||||
|
||||
## DTOs and Interfaces
|
||||
|
||||
### Shared DTOs
|
||||
|
||||
| DTO Name | Used By Components | Fields Summary |
|
||||
|----------|-------------------|---------------|
|
||||
| [name] | [component list] | [key fields] |
|
||||
|
||||
### Component Interfaces
|
||||
|
||||
| Component | Interface | Methods | Exposed To |
|
||||
|-----------|-----------|---------|-----------|
|
||||
| [##]_[name] | [InterfaceName] | [method list] | [consumers] |
|
||||
|
||||
## CI/CD Pipeline
|
||||
|
||||
| Stage | Purpose | Trigger |
|
||||
|-------|---------|---------|
|
||||
| Build | Compile/bundle the application | Every push |
|
||||
| Lint / Static Analysis | Code quality and style checks | Every push |
|
||||
| Unit Tests | Run unit test suite | Every push |
|
||||
| Integration Tests | Run integration test suite | Every push |
|
||||
| Security Scan | SAST / dependency check | Every push |
|
||||
| Deploy to Staging | Deploy to staging environment | Merge to staging branch |
|
||||
|
||||
### Pipeline Configuration Notes
|
||||
|
||||
[Framework-specific notes: CI tool, runners, caching, parallelism, etc.]
|
||||
|
||||
## Environment Strategy
|
||||
|
||||
| Environment | Purpose | Configuration Notes |
|
||||
|-------------|---------|-------------------|
|
||||
| Development | Local development | [local DB, mock services, debug flags] |
|
||||
| Staging | Pre-production testing | [staging DB, staging services, production-like config] |
|
||||
| Production | Live system | [production DB, real services, optimized config] |
|
||||
|
||||
### Environment Variables
|
||||
|
||||
| Variable | Dev | Staging | Production | Description |
|
||||
|----------|-----|---------|------------|-------------|
|
||||
| [VAR_NAME] | [value/source] | [value/source] | [value/source] | [purpose] |
|
||||
|
||||
## Database Migration Approach
|
||||
|
||||
**Migration tool**: [tool name]
|
||||
**Strategy**: [migration strategy — e.g., versioned scripts, ORM migrations]
|
||||
|
||||
### Initial Schema
|
||||
|
||||
[Key tables/collections that need to be created, referencing component data access patterns]
|
||||
|
||||
## Test Structure
|
||||
|
||||
```
|
||||
tests/
|
||||
├── unit/
|
||||
│ ├── [component_1]/
|
||||
│ ├── [component_2]/
|
||||
│ └── ...
|
||||
├── integration/
|
||||
│ ├── test_data/
|
||||
│ └── [test files]
|
||||
└── ...
|
||||
```
|
||||
|
||||
### Test Configuration Notes
|
||||
|
||||
[Test runner, fixtures, test data management, isolation strategy]
|
||||
|
||||
## Implementation Order
|
||||
|
||||
| Order | Component | Reason |
|
||||
|-------|-----------|--------|
|
||||
| 1 | [##]_[name] | [why first — foundational, no dependencies] |
|
||||
| 2 | [##]_[name] | [depends on #1] |
|
||||
| ... | ... | ... |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Guidance Notes
|
||||
|
||||
- This is a PLAN document, not code. The `3.05_implement_initial_structure` command executes it.
|
||||
- Focus on structure and organization decisions, not implementation details.
|
||||
- Reference component specs for interface and DTO details — don't repeat everything.
|
||||
- The folder layout should follow conventions of the identified tech stack.
|
||||
- Environment strategy should account for secrets management and configuration.
|
||||
@@ -0,0 +1,59 @@
|
||||
# Decomposition Summary Template
|
||||
|
||||
Use this template after all steps complete. Save as `TASKS_DIR/<topic>/SUMMARY.md`.
|
||||
|
||||
---
|
||||
|
||||
```markdown
|
||||
# Decomposition Summary
|
||||
|
||||
**Date**: [YYYY-MM-DD]
|
||||
**Topic**: [topic name]
|
||||
**Total Components**: [N]
|
||||
**Total Features**: [N]
|
||||
**Total Complexity Points**: [N]
|
||||
|
||||
## Component Breakdown
|
||||
|
||||
| # | Component | Features | Total Points | Jira Epic |
|
||||
|---|-----------|----------|-------------|-----------|
|
||||
| 01 | [name] | [count] | [sum] | [EPIC-ID] |
|
||||
| 02 | [name] | [count] | [sum] | [EPIC-ID] |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
## Feature List
|
||||
|
||||
| Component | Feature | Complexity | Jira Task | Dependencies |
|
||||
|-----------|---------|-----------|-----------|-------------|
|
||||
| [##]_[name] | [##].[##]_feature_[name] | [points] | [TASK-ID] | [deps or "None"] |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
## Implementation Order
|
||||
|
||||
Recommended sequence based on dependency analysis:
|
||||
|
||||
| Phase | Components / Features | Rationale |
|
||||
|-------|----------------------|-----------|
|
||||
| 1 | [list] | [foundational, no dependencies] |
|
||||
| 2 | [list] | [depends on phase 1] |
|
||||
| 3 | [list] | [depends on phase 1-2] |
|
||||
| ... | ... | ... |
|
||||
|
||||
### Parallelization Opportunities
|
||||
|
||||
[Features/components that can be implemented concurrently within each phase]
|
||||
|
||||
## Cross-Component Dependencies
|
||||
|
||||
| From (Feature) | To (Feature) | Dependency Type |
|
||||
|----------------|-------------|-----------------|
|
||||
| [comp.feature] | [comp.feature] | [data / API / event] |
|
||||
| ... | ... | ... |
|
||||
|
||||
## Artifacts Produced
|
||||
|
||||
- `initial_structure.md` — project skeleton plan
|
||||
- `cross_dependencies.md` — dependency matrix
|
||||
- `[##]_[name]/[##].[##]_feature_*.md` — feature specs per component
|
||||
- Jira tasks created under respective epics
|
||||
```
|
||||
Reference in New Issue
Block a user