chore: install openagent opencode
Signed-off-by: Dmytro Stanchiev <git@dmytros.dev>
This commit is contained in:
129
.opencode/context/core/task-management/guides/managing-tasks.md
Normal file
129
.opencode/context/core/task-management/guides/managing-tasks.md
Normal file
@@ -0,0 +1,129 @@
|
||||
<!-- Context: core/managing-tasks | Priority: high | Version: 1.0 | Updated: 2026-02-15 -->
|
||||
|
||||
# Guide: Managing Task Lifecycle
|
||||
|
||||
**Purpose**: Step-by-step workflow for JSON-driven task management
|
||||
|
||||
**Last Updated**: 2026-01-11
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- TaskManager agent available
|
||||
- Feature folder created in `.tmp/tasks/` (at project root)
|
||||
|
||||
---
|
||||
|
||||
## Workflow Overview
|
||||
|
||||
```
|
||||
1. Initiation → TaskManager creates task.json + subtasks
|
||||
2. Selection → Find eligible tasks (deps satisfied)
|
||||
3. Execution → Working agent implements task
|
||||
4. Verification → TaskManager validates completion
|
||||
5. Archiving → Move to completed/ when done
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1. Initiation (TaskManager)
|
||||
|
||||
Create feature folder and files:
|
||||
```
|
||||
.tmp/tasks/{feature-slug}/
|
||||
├── task.json
|
||||
├── subtask_01.json
|
||||
├── subtask_02.json
|
||||
└── subtask_03.json
|
||||
```
|
||||
|
||||
Validate with: `task-cli.ts validate {feature}`
|
||||
|
||||
---
|
||||
|
||||
## 2. Task Selection
|
||||
|
||||
Find eligible tasks using CLI:
|
||||
```bash
|
||||
task-cli.ts next {feature} # All ready tasks
|
||||
task-cli.ts parallel {feature} # Parallelizable only
|
||||
```
|
||||
|
||||
Selection criteria:
|
||||
- `status == "pending"`
|
||||
- All `depends_on` tasks have `status == "completed"`
|
||||
|
||||
---
|
||||
|
||||
## 3. Execution (Working Agent)
|
||||
|
||||
When picking up task:
|
||||
|
||||
1. Read subtask JSON
|
||||
2. Update status:
|
||||
```json
|
||||
{
|
||||
"status": "in_progress",
|
||||
"agent_id": "coder-agent",
|
||||
"started_at": "2026-01-11T14:30:00Z"
|
||||
}
|
||||
```
|
||||
3. Load `context_files` (lazy)
|
||||
4. Implement `deliverables`
|
||||
5. Add `completion_summary` (max 200 chars)
|
||||
|
||||
---
|
||||
|
||||
## 4. Verification (TaskManager)
|
||||
|
||||
After agent signals completion:
|
||||
|
||||
1. Check each `acceptance_criteria`
|
||||
2. If all pass → Mark completed:
|
||||
```bash
|
||||
task-cli.ts complete {feature} {seq} "summary"
|
||||
```
|
||||
3. If fail → Keep in_progress, report failures
|
||||
|
||||
---
|
||||
|
||||
## 5. Archiving
|
||||
|
||||
When `completed_count == subtask_count`:
|
||||
|
||||
1. Update task.json: `status: "completed"`
|
||||
2. Move folder: `.tmp/tasks/{slug}/` → `.tmp/tasks/completed/{slug}/`
|
||||
|
||||
---
|
||||
|
||||
## Status Ownership
|
||||
|
||||
| Status | Who Sets | When |
|
||||
|--------|----------|------|
|
||||
| pending | TaskManager | Initial creation |
|
||||
| in_progress | Working agent | Picks up task |
|
||||
| completed | TaskManager | After verification |
|
||||
| blocked | Either | Dependency/issue found |
|
||||
|
||||
---
|
||||
|
||||
## CLI Commands Summary
|
||||
|
||||
| Command | Use Case |
|
||||
|---------|----------|
|
||||
| `status` | Quick overview |
|
||||
| `next` | What to work on |
|
||||
| `parallel` | Batch parallel work |
|
||||
| `deps` | Understand blockers |
|
||||
| `blocked` | Identify issues |
|
||||
| `complete` | Mark task done |
|
||||
| `validate` | Health check |
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- `../standards/task-schema.md` - JSON field reference
|
||||
- `splitting-tasks.md` - How to create subtasks
|
||||
- `../lookup/task-commands.md` - Full CLI reference
|
||||
115
.opencode/context/core/task-management/guides/splitting-tasks.md
Normal file
115
.opencode/context/core/task-management/guides/splitting-tasks.md
Normal file
@@ -0,0 +1,115 @@
|
||||
<!-- Context: core/splitting-tasks | Priority: high | Version: 1.0 | Updated: 2026-02-15 -->
|
||||
|
||||
# Guide: Splitting Features into Tasks
|
||||
|
||||
**Purpose**: How to decompose features into atomic subtasks
|
||||
|
||||
**Last Updated**: 2026-01-11
|
||||
|
||||
---
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Feature request understood
|
||||
- Context bundle loaded (project standards, patterns)
|
||||
|
||||
---
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Identify Atomic Boundaries
|
||||
|
||||
Break feature into tasks that are:
|
||||
- Completable in 1-2 hours
|
||||
- Have single, clear outcome
|
||||
- Testable independently
|
||||
- Don't overlap with other tasks
|
||||
|
||||
**Bad**: "Implement authentication" (too big)
|
||||
**Good**: "Create password hashing utility" (atomic)
|
||||
|
||||
---
|
||||
|
||||
### 2. Map Dependencies
|
||||
|
||||
For each task, ask:
|
||||
- What must exist before this can start?
|
||||
- What files/APIs does this need?
|
||||
|
||||
```
|
||||
01 → no deps (can start immediately)
|
||||
02 → depends_on: ["01"]
|
||||
03 → depends_on: ["01", "02"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Identify Parallel Tasks
|
||||
|
||||
Mark `parallel: true` when:
|
||||
- Task doesn't modify shared files
|
||||
- Task doesn't depend on runtime state from other tasks
|
||||
- Multiple agents could work simultaneously
|
||||
|
||||
Example parallel tasks:
|
||||
- Writing independent unit tests
|
||||
- Creating isolated utility functions
|
||||
- Documentation for separate features
|
||||
|
||||
---
|
||||
|
||||
### 4. Define Acceptance Criteria
|
||||
|
||||
Binary pass/fail conditions only:
|
||||
- "JWT tokens signed with RS256" ✓
|
||||
- "Tests pass" ✓
|
||||
- "Code is clean" ✗ (subjective)
|
||||
|
||||
---
|
||||
|
||||
### 5. Specify Deliverables
|
||||
|
||||
Concrete files/endpoints:
|
||||
- `src/auth/hash.ts`
|
||||
- `POST /api/login`
|
||||
- `tests/auth.test.ts`
|
||||
|
||||
---
|
||||
|
||||
### 6. Reference Context Files
|
||||
|
||||
Don't embed descriptions. Reference paths:
|
||||
```json
|
||||
"context_files": [
|
||||
"(example: .opencode/context/development/backend/auth/jwt-patterns.md)"
|
||||
]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
- [ ] Each task completable in 1-2 hours?
|
||||
- [ ] Dependencies create valid execution order?
|
||||
- [ ] Parallel tasks correctly identified?
|
||||
- [ ] Acceptance criteria are binary?
|
||||
- [ ] Deliverables are concrete files/endpoints?
|
||||
|
||||
---
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
| Mistake | Fix |
|
||||
|---------|-----|
|
||||
| Task too big | Split into 2-3 smaller tasks |
|
||||
| Circular deps | Re-order or merge tasks |
|
||||
| Missing deps | Run `task-cli.ts validate` |
|
||||
| Vague criteria | Make binary pass/fail |
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- `../standards/task-schema.md` - JSON field reference
|
||||
- `managing-tasks.md` - Lifecycle workflow
|
||||
- `../lookup/task-commands.md` - CLI reference
|
||||
204
.opencode/context/core/task-management/lookup/task-commands.md
Normal file
204
.opencode/context/core/task-management/lookup/task-commands.md
Normal file
@@ -0,0 +1,204 @@
|
||||
<!-- Context: core/task-commands | Priority: high | Version: 1.0 | Updated: 2026-02-15 -->
|
||||
|
||||
# Lookup: Task CLI Commands
|
||||
|
||||
**Purpose**: Quick reference for task-cli.ts commands
|
||||
|
||||
**Last Updated**: 2026-02-14
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
```bash
|
||||
bunx --bun ts-node .opencode/context/tasks/scripts/task-cli.ts <command> [args]
|
||||
```
|
||||
|
||||
Task files are stored in `.tmp/tasks/` at the project root.
|
||||
|
||||
---
|
||||
|
||||
## Commands
|
||||
|
||||
### status [feature]
|
||||
|
||||
Show task status summary for all features or specific feature.
|
||||
|
||||
```bash
|
||||
task-cli.ts status
|
||||
task-cli.ts status my-feature
|
||||
```
|
||||
|
||||
**Output**:
|
||||
```
|
||||
[my-feature] My Feature Name
|
||||
Status: active | Progress: 40% (2/5)
|
||||
Pending: 2 | In Progress: 1 | Completed: 2 | Blocked: 0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### next [feature]
|
||||
|
||||
Show tasks ready to work on (deps satisfied).
|
||||
|
||||
```bash
|
||||
task-cli.ts next
|
||||
task-cli.ts next my-feature
|
||||
```
|
||||
|
||||
**Output**:
|
||||
```
|
||||
=== Ready Tasks (deps satisfied) ===
|
||||
|
||||
[my-feature]
|
||||
02 - Create JWT service [sequential]
|
||||
03 - Write unit tests [parallel]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### parallel [feature]
|
||||
|
||||
Show only parallelizable tasks ready now.
|
||||
|
||||
```bash
|
||||
task-cli.ts parallel
|
||||
task-cli.ts parallel my-feature
|
||||
```
|
||||
|
||||
**Use**: Batch multiple isolated tasks for parallel execution.
|
||||
|
||||
---
|
||||
|
||||
### deps \<feature\> \<seq\>
|
||||
|
||||
Show dependency tree for a specific task.
|
||||
|
||||
```bash
|
||||
task-cli.ts deps my-feature 04
|
||||
```
|
||||
|
||||
**Output**:
|
||||
```
|
||||
=== Dependency Tree: my-feature/04 ===
|
||||
|
||||
04 - Integration tests [pending]
|
||||
├── ✓ 01 - Setup database [completed]
|
||||
└── ○ 02 - Create API [pending]
|
||||
└── ✓ 01 - Setup database [completed]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### blocked [feature]
|
||||
|
||||
Show blocked tasks and reasons.
|
||||
|
||||
```bash
|
||||
task-cli.ts blocked
|
||||
task-cli.ts blocked my-feature
|
||||
```
|
||||
|
||||
**Output**:
|
||||
```
|
||||
=== Blocked Tasks ===
|
||||
|
||||
[my-feature]
|
||||
04 - Integration tests (waiting: 02, 03)
|
||||
05 - Deploy (explicitly blocked)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### complete \<feature\> \<seq\> "summary"
|
||||
|
||||
Mark task as completed with summary (max 200 chars).
|
||||
|
||||
```bash
|
||||
task-cli.ts complete my-feature 02 "Created JWT service with RS256 signing"
|
||||
```
|
||||
|
||||
**Effect**:
|
||||
- Sets `status: "completed"`
|
||||
- Sets `completed_at` timestamp
|
||||
- Sets `completion_summary`
|
||||
- Updates `task.json` counts
|
||||
|
||||
---
|
||||
|
||||
### validate [feature]
|
||||
|
||||
Check JSON validity, dependencies, circular refs.
|
||||
|
||||
```bash
|
||||
task-cli.ts validate
|
||||
task-cli.ts validate my-feature
|
||||
```
|
||||
|
||||
**Checks**:
|
||||
- task.json exists
|
||||
- ID format correct
|
||||
- Dependencies exist
|
||||
- No circular dependencies
|
||||
- Counts match
|
||||
|
||||
**Output**:
|
||||
```
|
||||
[my-feature]
|
||||
✓ All checks passed
|
||||
|
||||
[broken-feature]
|
||||
✗ ERROR: 03: depends on non-existent task 99
|
||||
⚠ WARNING: 02: No acceptance criteria defined
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Exit Codes
|
||||
|
||||
| Code | Meaning |
|
||||
|------|---------|
|
||||
| 0 | Success |
|
||||
| 1 | Error (validate found issues, missing args) |
|
||||
|
||||
---
|
||||
|
||||
## Enhanced Schema Support
|
||||
|
||||
The CLI fully supports the enhanced task schema (v2.0) with:
|
||||
- **Line-number precision** - Context files with specific line ranges
|
||||
- **Domain modeling** - bounded_context, module, vertical_slice fields
|
||||
- **Contract tracking** - API/interface dependencies
|
||||
- **Design artifacts** - Figma, wireframes, mockups
|
||||
- **ADR references** - Architecture decision records
|
||||
- **Prioritization** - RICE/WSJF scores
|
||||
|
||||
All enhanced fields are optional and backward compatible. See `../standards/enhanced-task-schema.md` for details.
|
||||
|
||||
---
|
||||
|
||||
## Planning Workflow Integration
|
||||
|
||||
For multi-stage orchestration workflows, use these planning agents before task creation:
|
||||
|
||||
| Agent | Purpose | Output |
|
||||
|-------|---------|--------|
|
||||
| **ArchitectureAnalyzer** | DDD bounded context identification | `.tmp/architecture/contexts.json` |
|
||||
| **StoryMapper** | User journey and story mapping | `.tmp/story-maps/map.json` |
|
||||
| **PrioritizationEngine** | RICE/WSJF scoring | `.tmp/backlog/prioritized.json` |
|
||||
| **ContractManager** | API contract definition | `.tmp/contracts/{service}.json` |
|
||||
| **ADRManager** | Architecture decision records | `docs/adr/` |
|
||||
|
||||
These agents populate enhanced schema fields (bounded_context, contracts, related_adrs, rice_score, etc.) automatically.
|
||||
|
||||
See `.opencode/context/core/workflows/multi-stage-orchestration.md` for the complete workflow.
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- `../standards/task-schema.md` - Base JSON schema reference
|
||||
- `../standards/enhanced-task-schema.md` - Extended schema with advanced features
|
||||
- `../guides/managing-tasks.md` - Workflow guide
|
||||
- `../workflows/multi-stage-orchestration.md` - Planning workflow
|
||||
66
.opencode/context/core/task-management/navigation.md
Normal file
66
.opencode/context/core/task-management/navigation.md
Normal file
@@ -0,0 +1,66 @@
|
||||
<!-- Context: core/navigation | Priority: critical | Version: 1.0 | Updated: 2026-02-15 -->
|
||||
|
||||
# Task Management Navigation
|
||||
|
||||
**Purpose**: JSON-driven task breakdown and tracking system
|
||||
|
||||
**Last Updated**: 2026-02-14
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
```
|
||||
core/task-management/
|
||||
├── navigation.md
|
||||
├── standards/
|
||||
│ ├── task-schema.md # Base JSON schema (v1.0)
|
||||
│ └── enhanced-task-schema.md # Extended schema (v2.0) - line precision, domain modeling, contracts
|
||||
├── guides/
|
||||
│ ├── splitting-tasks.md # Task decomposition
|
||||
│ └── managing-tasks.md # Workflow guide
|
||||
└── lookup/
|
||||
└── task-commands.md # CLI script reference
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quick Routes
|
||||
|
||||
| Task | Path | Priority |
|
||||
|------|------|----------|
|
||||
| **Understand base schema** | `standards/task-schema.md` | ⭐⭐⭐⭐⭐ |
|
||||
| **Use enhanced features** | `standards/enhanced-task-schema.md` | ⭐⭐⭐⭐ |
|
||||
| **Split a feature** | `guides/splitting-tasks.md` | ⭐⭐⭐⭐⭐ |
|
||||
| **Manage task lifecycle** | `guides/managing-tasks.md` | ⭐⭐⭐⭐ |
|
||||
| **Use CLI commands** | `lookup/task-commands.md` | ⭐⭐⭐⭐ |
|
||||
|
||||
---
|
||||
|
||||
## Loading Strategy
|
||||
|
||||
### For Creating Basic Tasks:
|
||||
1. Load `standards/task-schema.md` (understand base structure)
|
||||
2. Load `guides/splitting-tasks.md` (decomposition approach)
|
||||
3. Reference `lookup/task-commands.md` (validate after creation)
|
||||
|
||||
### For Multi-Stage Orchestration:
|
||||
1. Load `standards/enhanced-task-schema.md` (advanced features)
|
||||
2. Load `standards/task-schema.md` (base structure reference)
|
||||
3. Load `guides/splitting-tasks.md` (decomposition approach)
|
||||
4. Reference planning agents: ArchitectureAnalyzer, StoryMapper, PrioritizationEngine, ContractManager, ADRManager
|
||||
|
||||
### For Managing Tasks:
|
||||
1. Load `guides/managing-tasks.md` (workflow)
|
||||
2. Reference `lookup/task-commands.md` (CLI usage)
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- **Active tasks** → `.tmp/tasks/{feature}/` (at project root)
|
||||
- **Completed tasks** → `.tmp/tasks/completed/{feature}/`
|
||||
- **TaskManager agent** → `.opencode/agent/subagents/core/task-manager.md`
|
||||
- **Planning agents** → `.opencode/agent/subagents/planning/` (ArchitectureAnalyzer, StoryMapper, PrioritizationEngine, ContractManager, ADRManager)
|
||||
- **Multi-stage workflow** → `../workflows/multi-stage-orchestration.md`
|
||||
- **Core navigation** → `../navigation.md`
|
||||
201
.opencode/context/core/task-management/standards/task-schema.md
Normal file
201
.opencode/context/core/task-management/standards/task-schema.md
Normal file
@@ -0,0 +1,201 @@
|
||||
<!-- Context: core/task-schema | Priority: critical | Version: 1.0 | Updated: 2026-02-15 -->
|
||||
|
||||
# Standard: Task JSON Schema
|
||||
|
||||
**Purpose**: JSON schema reference for task management files
|
||||
|
||||
**Last Updated**: 2026-02-14
|
||||
|
||||
---
|
||||
|
||||
## Core Concepts
|
||||
|
||||
Task management uses two JSON file types:
|
||||
- `task.json` - Feature-level metadata and tracking
|
||||
- `subtask_NN.json` - Individual atomic tasks with dependencies
|
||||
|
||||
Location: `.tmp/tasks/{feature-slug}/` (at project root)
|
||||
|
||||
---
|
||||
|
||||
## Schema Versions
|
||||
|
||||
This document describes the **base schema** (v1.0) that all task files must follow.
|
||||
|
||||
For **enhanced features** (line-number precision, domain modeling, contracts, ADRs, prioritization):
|
||||
- See `enhanced-task-schema.md` for extended fields and capabilities
|
||||
- All enhanced fields are **optional** and backward compatible
|
||||
- Use enhanced schema for multi-stage orchestration workflows
|
||||
|
||||
---
|
||||
|
||||
## task.json Schema
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
|-------|------|----------|-------------|
|
||||
| `id` | string | Yes | kebab-case identifier |
|
||||
| `name` | string | Yes | Human-readable name (max 100) |
|
||||
| `status` | enum | Yes | active / completed / blocked / archived |
|
||||
| `objective` | string | Yes | One-line objective (max 200) |
|
||||
| `context_files` | array | No | **Standards paths only** — coding conventions, patterns, security rules to follow |
|
||||
| `reference_files` | array | No | **Source material only** — project files to look at (existing code, config, schemas) |
|
||||
| `exit_criteria` | array | No | Completion conditions |
|
||||
| `subtask_count` | int | No | Total subtasks |
|
||||
| `completed_count` | int | No | Done subtasks |
|
||||
| `created_at` | datetime | Yes | ISO 8601 |
|
||||
| `completed_at` | datetime | No | ISO 8601 |
|
||||
|
||||
---
|
||||
|
||||
## subtask_NN.json Schema
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
|-------|------|----------|-------------|
|
||||
| `id` | string | Yes | {feature}-{seq} |
|
||||
| `seq` | string | Yes | 2-digit (01, 02) |
|
||||
| `title` | string | Yes | Task title (max 100) |
|
||||
| `status` | enum | Yes | pending / in_progress / completed / blocked |
|
||||
| `depends_on` | array | No | Sequence numbers of dependencies |
|
||||
| `parallel` | bool | No | True if can run alongside others |
|
||||
| `context_files` | array | No | **Standards paths only** — conventions and patterns to follow |
|
||||
| `reference_files` | array | No | **Source material only** — existing files to reference |
|
||||
| `suggested_agent` | string | No | Recommended agent for this task (e.g., OpenFrontendSpecialist) |
|
||||
| `acceptance_criteria` | array | No | Binary pass/fail conditions |
|
||||
| `deliverables` | array | No | Files to create/modify |
|
||||
| `agent_id` | string | No | Set when in_progress |
|
||||
| `started_at` | datetime | No | ISO 8601 |
|
||||
| `completed_at` | datetime | No | ISO 8601 |
|
||||
| `completion_summary` | string | No | What was done (max 200) |
|
||||
|
||||
---
|
||||
|
||||
## Status Transitions
|
||||
|
||||
```
|
||||
pending → in_progress (by working agent, when deps satisfied)
|
||||
in_progress → completed (by TaskManager, after verification)
|
||||
* → blocked (by either, when issue found)
|
||||
blocked → pending (when unblocked)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Parallel Flag
|
||||
|
||||
- `parallel: true` = Isolated task, can run alongside others
|
||||
- `parallel: false` = May affect shared state, run sequentially
|
||||
|
||||
Use `task-cli.ts parallel` to find all parallelizable tasks ready to run.
|
||||
|
||||
---
|
||||
|
||||
## context_files vs reference_files — The Rule
|
||||
|
||||
These two fields serve fundamentally different purposes. **Never mix them.**
|
||||
|
||||
| Field | Answers | Contains | Agent behavior |
|
||||
|-------|---------|----------|----------------|
|
||||
| `context_files` | "What rules do I follow?" | Standards, conventions, patterns from `.opencode/context/` | Load and apply as coding guidelines |
|
||||
| `reference_files` | "What existing code do I look at?" | Project source files, configs, schemas | Read to understand existing patterns |
|
||||
|
||||
**Wrong** ❌ — mixing standards and source files:
|
||||
```json
|
||||
"context_files": [
|
||||
".opencode/context/core/standards/code-quality.md",
|
||||
"package.json",
|
||||
"src/existing-auth.ts"
|
||||
]
|
||||
```
|
||||
|
||||
**Right** ✅ — clean separation:
|
||||
```json
|
||||
"context_files": [
|
||||
".opencode/context/core/standards/code-quality.md",
|
||||
".opencode/context/core/standards/security-patterns.md"
|
||||
],
|
||||
"reference_files": [
|
||||
"package.json",
|
||||
"src/existing-auth.ts"
|
||||
]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Example
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "auth-system-02",
|
||||
"seq": "02",
|
||||
"title": "Create JWT service",
|
||||
"status": "pending",
|
||||
"depends_on": ["01"],
|
||||
"parallel": false,
|
||||
"context_files": [
|
||||
".opencode/context/core/standards/code-quality.md",
|
||||
".opencode/context/core/standards/security-patterns.md"
|
||||
],
|
||||
"reference_files": [
|
||||
"src/auth/token-utils.ts"
|
||||
],
|
||||
"acceptance_criteria": ["JWT tokens signed with RS256", "Tests pass"],
|
||||
"deliverables": ["src/auth/jwt.service.ts"]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Migration to Enhanced Schema
|
||||
|
||||
The enhanced schema adds powerful features while maintaining full backward compatibility:
|
||||
|
||||
### When to Use Enhanced Schema
|
||||
|
||||
Use `enhanced-task-schema.md` when you need:
|
||||
- **Line-number precision** - Point to specific sections of large files (reduces cognitive load)
|
||||
- **Domain modeling** - Track bounded contexts, modules, vertical slices
|
||||
- **Contract tracking** - Manage API/interface dependencies
|
||||
- **Design artifacts** - Link Figma, wireframes, mockups
|
||||
- **ADR references** - Connect architectural decisions to tasks
|
||||
- **Prioritization** - RICE/WSJF scoring for release planning
|
||||
|
||||
### Migration Path
|
||||
|
||||
1. **No changes required** - Existing task files work as-is
|
||||
2. **Gradual adoption** - Add enhanced fields incrementally:
|
||||
- Start with line-number precision for large context files
|
||||
- Add domain fields (bounded_context, module) when modeling architecture
|
||||
- Add contracts when defining APIs
|
||||
- Add prioritization scores when planning releases
|
||||
3. **Mixed formats** - You can mix old and new formats in the same file
|
||||
|
||||
### Example: Adding Line-Number Precision
|
||||
|
||||
**Old format** (still valid):
|
||||
```json
|
||||
"context_files": [
|
||||
".opencode/context/core/standards/code-quality.md"
|
||||
]
|
||||
```
|
||||
|
||||
**New format** (enhanced):
|
||||
```json
|
||||
"context_files": [
|
||||
{
|
||||
"path": ".opencode/context/core/standards/code-quality.md",
|
||||
"lines": "53-95",
|
||||
"reason": "Pure function patterns for service layer"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
Both formats work. Agents handle both automatically.
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- `enhanced-task-schema.md` - Extended schema with advanced features
|
||||
- `../guides/splitting-tasks.md` - How to decompose features
|
||||
- `../guides/managing-tasks.md` - Lifecycle workflow
|
||||
- `../lookup/task-commands.md` - CLI reference
|
||||
Reference in New Issue
Block a user