OpenWriterControle/.opencode/context/core/task-management/standards/enhanced-task-schema.md
Darren Hinde 5a40b6fdc4
feat(context): Standardize context system with navigation, frontmatter, and MVI compliance (#209)
* feat: add OAC package refactor context file

- Add comprehensive feature context for OAC package refactor
- Document multi-IDE support architecture
- Define community component registry (shadcn-like)
- Outline flexible configuration system
- Detail context file location flexibility
- Define 7-phase implementation plan
- Include CLI commands reference
- Add community publishing guidelines

* docs: add OAC refactor quick start guide

- Add quick reference for Phase 1 implementation
- Include project structure and file locations
- Document configuration schema and defaults
- Add testing strategy and validation steps
- Include development workflow
- Reference all related resources

* feat: add critical user approval and context resolution systems

CRITICAL FEATURES ADDED:

1. User Approval & YOLO Mode
   - Default: Interactive approval for all file operations
   - Always asks: local vs global install
   - Confirms before overwriting files
   - Shows diffs and file details
   - YOLO mode (--yolo): Skip confirmations, auto-resolve, report at end
   - Conflict strategies: ask, skip, overwrite, backup, yolo
   - Safety: backups, git detection, rollback support, audit log

2. Context Resolution System
   - Layered context resolution (6 priority levels)
   - Project override (.oac/context/) - highest priority
   - Project context (.opencode/context/)
   - IDE context (.cursor/, .claude/)
   - Project docs (docs/)
   - User global (~/.config/oac/context/)
   - OAC official (~/.config/oac/official/) - lowest priority
   - Smart resolution based on agent location (global vs local)
   - preferLocal config option
   - Context merging strategies
   - CLI commands for context management
   - Environment variable overrides
   - Validation and fallback support

3. Enhanced CLI Commands
   - All commands support --yolo, --dry-run, --local, --global
   - Context management: resolve, list, validate, override, sync
   - Detailed help and examples
   - Global flags for all commands

This ensures users maintain full control over their projects while
supporting both local and global workflows with intelligent context
resolution.

* feat: add component creation wizard and IDE feature parity system

NEW FEATURES:

1. Interactive Component Creation
   - oac create (interactive wizard)
   - Create agents, skills, contexts, plugins, commands, tools
   - Template system for scaffolding
   - Auto-generate tests and boilerplate
   - Multi-IDE compatibility selection
   - Size optimization options

2. IDE Feature Parity & Capacity Management (CRITICAL)
   - Feature support matrix for all IDEs
   - OpenCode/Claude Code: Full support (all features)
   - Cursor: Limited (single file, no skills/plugins, 100KB limit)
   - Windsurf: Partial support
   - Adaptive installation based on IDE capabilities
   - Automatic feature filtering and warnings
   - Component merging for single-file IDEs (Cursor)
   - Capacity warnings and optimization
   - IDE-specific profiles

3. Enhanced CLI Commands
   - oac create [type] - Component creation wizard
   - oac templates - List available templates
   - oac compatibility <ide> - Check IDE compatibility
   - oac ides - List supported IDEs with features
   - oac ide info <ide> - Show IDE capabilities
   - oac optimize --for <ide> - Optimize for specific IDE
   - oac validate --ide <ide> - Validate IDE installation

4. Smart Installation
   - Detects IDE capabilities
   - Warns about unsupported features
   - Auto-filters components
   - Merges agents for Cursor
   - Embeds contexts for limited IDEs
   - Monitors file size limits
   - Suggests IDE-specific profiles

This ensures users can easily create components and OAC gracefully
handles different IDE capabilities with clear warnings and automatic
optimization.

* docs: add critical feedback from parallel agent review

CRITICAL FINDINGS:

Security Gaps (BLOCKER):
- No component signing or verification
- No malware/secret scanning
- No permission system
- Action: Add security layer in Phase 1

Missing Features (CRITICAL):
- Discovery (browse, search, trending)
- Lockfile for reproducibility
- Version conflict management
- Interactive onboarding
- Progress indicators
- Auto-detection for local/global

Approaches to Rethink:
- Context merging → Use composition instead
- Always asking local/global → Auto-detect with smart defaults
- Cursor agent merging → Router pattern instead

Repository Structure:
- Recommended: Monorepo with pnpm workspaces
- Packages: core, adapters, registry, security, cli
- Benefits: Shared deps, atomic commits, easier testing

Community Workflow:
- Component submission process
- Automated security scanning
- Manual review for verification
- Moderation system

Updated Priorities:
- v1.0 MVP: Add 6 critical features (discovery, lockfile, security, etc.)
- v1.1: Plugin system, workspace support, marketplace
- v2.0: Enterprise features

Documentation Needs:
- Quick Start (5-minute guide)
- CLI Reference (auto-generated)
- Recipes/Cookbook
- Component Creation Guide
- Migration Guide

Overall: Plan is 80% solid, needs 20% critical additions before Phase 1

* feat: add comprehensive agent customization and preset system

CRITICAL FEATURE: Agent Customization & Personal Presets

Problem:
- Users want to customize agent prompts for their workflow
- Users want to save personal configurations
- Updates shouldn't overwrite customizations
- Need easy way to view and edit agents

Solution: Multi-Layer Customization System

Layer 1: View Agent Configuration
- oac show agent:openagent (view in pager)
- oac edit agent:openagent (open in editor)
- oac config show agent:openagent (config only)
- oac export agent:openagent (export to file)

Layer 2: Create Personal Preset
- oac customize agent:openagent (create preset)
- Copies to ~/.config/oac/presets/agents/
- Links to base agent for updates
- Tracks customizations in metadata

Layer 3: Edit Personal Preset
- oac edit preset:my-openagent (edit in $EDITOR)
- oac customize preset:my-openagent --interactive (wizard)
- Auto-backup on save
- Track modification history

Layer 4: Use Personal Preset
- oac use preset:my-openagent (activate)
- oac use preset:my-openagent --global (set default)
- oac presets list --active (show active)
- Switch between presets and base agents

Layer 5: Update Management (CRITICAL)
- Smart update detection for base agents
- Merge strategies: manual, auto-base, auto-merge, locked
- Conflict resolution with user prompts
- Show diffs before merging
- Auto-backup before updates
- Preserve user customizations by default

Layer 6: Preset Sharing
- oac export preset:my-openagent (export)
- oac import preset ./preset.md (import)
- oac share preset:my-openagent (share with team)
- oac publish preset:my-openagent (publish to community)

Layer 7: In-Place Editing (Advanced)
- oac edit agent:openagent --in-place (risky, warns user)
- Creates backup before editing
- Warns that updates will overwrite
- Recommends preset creation instead

Update Strategies:
- manual: User reviews every update
- auto-base: Auto-update base, keep preset unchanged
- auto-merge: Auto-merge, prompt on conflicts
- locked: Never update base

Configuration:
- Preset metadata (.presets.json)
- Update strategies per preset
- Merge conflict resolution
- Backup management
- Warning preferences

Edge Cases Handled:
- In-place edits before updates
- Multiple updates behind
- Multiple presets for same base
- Preset conflicts with IDE
- Deleted base agent

Best Practices:
- Always create presets (safest)
- Document customizations
- Review updates before merging
- Keep backups
- Use descriptive names

This ensures users can safely customize agents without fear of
losing changes on updates, while still benefiting from base agent
improvements.

* docs: complete comprehensive user scenario analysis (16,014 lines)

PLANNING PHASE COMPLETE:

Documents Created (9 files, 400KB):
- 00-INDEX.md (388 lines) - Planning index and overview
- 01-main-plan.md (2,338 lines) - Complete feature specification
- 02-quickstart-guide.md (450 lines) - Phase 1 quick reference
- 03-critical-feedback.md (599 lines) - Parallel agent review
- 04-solo-developer-scenarios.md (2,106 lines) - Individual workflows
- 05-team-lead-scenarios.md (3,977 lines) - Team collaboration
- 07-content-creator-scenarios.md (2,581 lines) - Non-technical users
- 08-open-source-maintainer-scenarios.md (3,575 lines) - Community management
- 09-SYNTHESIS.md (1,000+ lines) - Consolidated findings

User Personas Analyzed (4/5):
✅ Solo Developer (Primary - 40% market)
✅ Team Lead (Secondary - 30% market)
✅ Content Creator (Emerging - 20% market)
✅ Open Source Maintainer (Future - 5% market)
⏸️ Enterprise Admin (Deferred to v2.0 - 5% market)

Key Findings:

Solo Developer (Primary User):
- Setup must be < 2 minutes or they skip
- Preview before committing (try mode)
- Safe customization (presets)
- Easy rollback/undo
- Zero docs reading to start

Team Lead (Secondary User):
- Lockfile is non-negotiable (oac.lock)
- Team configuration (oac-team.json)
- Compliance monitoring (90%+ required)
- Onboarding: 4-8 hours → 15 minutes (96% reduction)
- Staged rollouts for updates

Content Creator (Emerging - 20% market):
- CLI is intimidating (need GUI wrapper)
- Plain language mode (no jargon)
- Visual undo (version history)
- Templates and examples
- Guided setup

Open Source Maintainer (Future):
- Security scanning pipeline (ClamAV + gitleaks)
- Quality gates (70% test coverage)
- Review/approval workflow
- Deprecation workflow
- Sustainability model

Critical Additions to MVP:
1. Interactive onboarding wizard (all personas)
2. TUI browser with preview (solo dev, team lead)
3. Lockfile (oac.lock) (team lead)
4. Security scanning (all personas)
5. Try mode (solo dev)
6. Team configuration (team lead)
7. oac doctor health checks (solo dev)
8. Quality gates (maintainer)

Market Opportunity:
- v1.0: 70% market (solo + team)
- v1.1: 90% market (+ content creators with GUI)
- v2.0: 100% market (+ enterprise)

Recommended Changes:
- Expand MVP scope (+2 weeks, 9 weeks total)
- Plan v1.1 for content creators (GUI wrapper)
- Defer enterprise features to v2.0
- Build community features early (trust)

Status: Ready to finalize plan and start implementation
Confidence: Very High (95%+)
Risk: Low (comprehensive analysis complete)

* docs: add comprehensive final review of OAC planning

FINAL REVIEW COMPLETE:

Overall Assessment: CONDITIONAL GO ✅⚠️
Confidence Level: 85% (High, with conditions)
Success Probability: 75% (with modifications)

Key Strengths:
✅ Exceptional user research (16,000+ lines, 4 personas)
✅ Clear technical architecture (monorepo, TypeScript, Zod)
✅ Security-first mindset (signing, scanning, verification)
✅ Realistic scope management (v1.0 vs v1.1 vs v2.0)
✅ Comprehensive feature coverage

Critical Gaps Identified:
❌ Discovery/Onboarding not in Phase 1 (but P0 in scenarios)
❌ Lockfile not in Phase 2 (but critical for teams)
❌ Security Pipeline not detailed in phases
❌ Progress UI not in Phase 1 (but needed for UX)
❌ Auto-detection not in Phase 1 (but reduces friction)

Conditions for Go:
1. Add discovery/onboarding to Phase 1 (+3 days)
2. Add lockfile to Phase 2 (+2 days)
3. Add security pipeline to Phase 1 (+2 days)
4. Add progress UI to Phase 1 (+1 day)
5. Revise timeline: 7 weeks → 9 weeks

Critical Action Items (6 days before Phase 1):
1. Add missing features to phases (2 days)
2. Define acceptance criteria (1 day)
3. Define testing strategy (1 day)
4. Design security pipeline (1 day)
5. Create monorepo structure (1 day)

Top Risks:
🔴 Timeline Slip (70% probability, high impact)
🟡 Scope Creep (50% probability, high impact)
🟡 Context Merging Complexity (60% probability, medium impact)

Recommendation: PROCEED WITH MODIFICATIONS
- Complete 6 days of prerequisite work
- Extend timeline to 9 weeks
- Add missing features to phases
- Define acceptance criteria and testing strategy

Status: READY TO IMPLEMENT (with modifications)
Next Steps: Complete prerequisites → Setup monorepo → Start Phase 1

* feat(context): Standardize context system with navigation, frontmatter, and MVI compliance

- Add 77 navigation.md files across all context categories for token-efficient discovery
- Standardize frontmatter format on 198+ context files (HTML comment format, 2026-02-15)
- Compress 3 oversized guide files applying MVI principle (802 lines removed, 63% reduction)
- Add context system analysis and planning artifacts in context-findings/
- Add task management enhancements (stage orchestration, planning subagents)
- Document compression techniques and future optimization recommendations

Context System Improvements:
- All active directories now have navigation.md (200-300 tokens each)
- 100% frontmatter compliance with priority/version/date metadata
- Improved scannability through MVI compression (compact.md, organizing-context.md, creation.md)
- Token efficiency increased for AI agent consumption

Planning & Analysis:
- Context system implementation plan and simplification analysis
- ADR standard proposal and runtime permission architecture
- SQLite context design for future scale (deferred until 500+ files)
- Context discovery script analysis (rejected in favor of navigation-first)

Task Management:
- Enhanced task schema with stage orchestration support
- New planning subagents (ADR, Architecture, Story Mapping, Prioritization)
- Stage orchestrator for multi-stage workflow management
- Session context management and lightweight handoff patterns

Closes: context-simple-fixes task
Ref: context-system-implementation analysis

* fix: resolve markdown link validation errors in navigation files

- Remove non-existent react-patterns.md link from react/navigation.md
- Remove non-existent premium-dark-ui-quick-start.md link from design/navigation.md
- Add skip patterns for pre-existing broken links in example/template files
- Validation now passes: 215 files validated, 0 errors

* fix: resolve all 119 broken markdown links across documentation

- Update agent paths to new subagents structure (TestEngineer, ContextScout, etc.)
- Fix animation file references (animation-ui.md → animation-components.md)
- Update guide references (adding-agent.md → adding-agent-basics.md)
- Convert non-existent example paths to placeholder text format
- Add skip patterns for intentional example placeholders
- Validation now passes: 232 files validated, 0 errors

Co-authored-by: CoderAgent <coder@openagents.dev>

---------

Co-authored-by: CoderAgent <coder@openagents.dev>
2026-02-15 23:01:19 +00:00

19 KiB
Raw Blame History

Enhanced Task JSON Schema

Purpose: Extended JSON schema for multi-stage orchestration with line-number precision, domain modeling, and prioritization

Version: 2.0

Last Updated: 2026-02-14

Backward Compatible: Yes (all new fields are optional)


Overview

This schema extends the base task.json and subtask_NN.json schemas with:

  • Line-number precision for context and reference files
  • Domain modeling fields (bounded_context, module, vertical_slice)
  • Contract tracking for API/interface dependencies
  • Design artifacts linking
  • ADR references for architectural decisions
  • Prioritization scores (RICE, WSJF)
  • Release planning (release_slice)

All enhancements are optional and backward compatible with existing task files.


Enhanced task.json Schema

New Fields

Field Type Required Description
bounded_context string No DDD bounded context (e.g., "authentication", "billing")
module string No Module/package name (e.g., "@app/auth", "payment-service")
vertical_slice string No Feature slice identifier (e.g., "user-registration", "checkout-flow")
contracts array No API/interface contracts this feature depends on or provides
design_components array No Design artifacts (Figma URLs, wireframes, mockups)
related_adrs array No Architecture Decision Records (ADR file paths or IDs)
rice_score object No RICE prioritization (Reach, Impact, Confidence, Effort)
wsjf_score object No WSJF prioritization (Business Value, Time Criticality, Risk Reduction, Job Size)
release_slice string No Release identifier (e.g., "v1.2.0", "Q1-2026", "MVP")

Enhanced context_files and reference_files Format

Old format (still supported):

"context_files": [
  ".opencode/context/core/standards/code-quality.md"
]

New format (line-number precision):

"context_files": [
  {
    "path": ".opencode/context/core/standards/code-quality.md",
    "lines": "1-50",
    "reason": "Pure function patterns for service layer"
  },
  {
    "path": ".opencode/context/core/standards/security-patterns.md",
    "lines": "120-145",
    "reason": "JWT token validation rules"
  }
]

Backward Compatibility: Both formats are valid. Agents should handle both:

  • String format → read entire file
  • Object format → read specified lines only

Enhanced subtask_NN.json Schema

New Fields

Field Type Required Description
bounded_context string No Inherited from task.json or subtask-specific override
module string No Module this subtask modifies
vertical_slice string No Feature slice this subtask belongs to
contracts array No Contracts this subtask implements or depends on
design_components array No Design artifacts relevant to this subtask
related_adrs array No ADRs relevant to this subtask

TypeScript Interfaces

// Line-number precision for context files
interface ContextFileReference {
  path: string;           // File path (absolute or relative to project root)
  lines?: string;         // Line range: "10-50", "1-20,45-60", or omit for entire file
  reason?: string;        // Why this file/section is relevant (max 200 chars)
}

// Contract definition
interface Contract {
  type: 'api' | 'interface' | 'event' | 'schema';
  name: string;           // Contract identifier (e.g., "UserAPI", "AuthEvent")
  path?: string;          // File path where contract is defined
  status: 'draft' | 'defined' | 'implemented' | 'verified';
  description?: string;   // Brief description (max 200 chars)
}

// Design component reference
interface DesignComponent {
  type: 'figma' | 'wireframe' | 'mockup' | 'prototype' | 'sketch';
  url?: string;           // External URL (Figma, etc.)
  path?: string;          // Local file path
  description?: string;   // What this design covers (max 200 chars)
}

// ADR reference
interface ADRReference {
  id: string;             // ADR identifier (e.g., "ADR-001", "auth-strategy")
  path?: string;          // File path to ADR document
  title?: string;         // ADR title
  decision?: string;      // Brief summary of decision (max 200 chars)
}

// RICE prioritization
interface RICEScore {
  reach: number;          // How many users affected (per time period)
  impact: number;         // Impact score (0.25 = minimal, 0.5 = low, 1 = medium, 2 = high, 3 = massive)
  confidence: number;     // Confidence % (0-100)
  effort: number;         // Person-months of work
  score?: number;         // Calculated: (reach * impact * confidence) / effort
}

// WSJF prioritization
interface WSJFScore {
  business_value: number;     // 1-10 scale
  time_criticality: number;   // 1-10 scale
  risk_reduction: number;     // 1-10 scale
  job_size: number;           // 1-10 scale (effort estimate)
  score?: number;             // Calculated: (business_value + time_criticality + risk_reduction) / job_size
}

// Enhanced task.json
interface EnhancedTask {
  // Base fields (from task-schema.md)
  id: string;
  name: string;
  status: 'active' | 'completed' | 'blocked' | 'archived';
  objective: string;
  context_files?: (string | ContextFileReference)[];
  reference_files?: (string | ContextFileReference)[];
  exit_criteria?: string[];
  subtask_count?: number;
  completed_count?: number;
  created_at: string;
  completed_at?: string;

  // Enhanced fields
  bounded_context?: string;
  module?: string;
  vertical_slice?: string;
  contracts?: Contract[];
  design_components?: DesignComponent[];
  related_adrs?: ADRReference[];
  rice_score?: RICEScore;
  wsjf_score?: WSJFScore;
  release_slice?: string;
}

// Enhanced subtask_NN.json
interface EnhancedSubtask {
  // Base fields (from task-schema.md)
  id: string;
  seq: string;
  title: string;
  status: 'pending' | 'in_progress' | 'completed' | 'blocked';
  depends_on?: string[];
  parallel?: boolean;
  context_files?: (string | ContextFileReference)[];
  reference_files?: (string | ContextFileReference)[];
  suggested_agent?: string;
  acceptance_criteria?: string[];
  deliverables?: string[];
  agent_id?: string;
  started_at?: string;
  completed_at?: string;
  completion_summary?: string;

  // Enhanced fields
  bounded_context?: string;
  module?: string;
  vertical_slice?: string;
  contracts?: Contract[];
  design_components?: DesignComponent[];
  related_adrs?: ADRReference[];
}

Field Examples

bounded_context

Purpose: DDD bounded context for domain modeling

{
  "bounded_context": "authentication"
}

Common values:

  • "authentication" - User identity and access
  • "billing" - Payment and invoicing
  • "inventory" - Product and stock management
  • "notification" - Messaging and alerts
  • "analytics" - Reporting and insights

module

Purpose: Module or package name for code organization

{
  "module": "@app/auth"
}

Examples:

  • "@app/auth" - Authentication module
  • "payment-service" - Payment microservice
  • "ui-components" - Shared UI library
  • "core/utils" - Core utilities

vertical_slice

Purpose: Feature slice identifier for vertical slice architecture

{
  "vertical_slice": "user-registration"
}

Examples:

  • "user-registration" - Complete user signup flow
  • "checkout-flow" - End-to-end checkout
  • "dashboard-overview" - Dashboard feature
  • "report-generation" - Report creation flow

contracts

Purpose: Track API/interface dependencies and implementations

{
  "contracts": [
    {
      "type": "api",
      "name": "UserAPI",
      "path": "src/api/user.contract.ts",
      "status": "defined",
      "description": "REST API for user CRUD operations"
    },
    {
      "type": "event",
      "name": "UserCreatedEvent",
      "status": "draft",
      "description": "Event emitted when new user is created"
    }
  ]
}

Contract types:

  • "api" - REST/GraphQL API endpoints
  • "interface" - TypeScript/language interfaces
  • "event" - Event bus messages
  • "schema" - Database schemas, validation schemas

Contract statuses:

  • "draft" - Being designed
  • "defined" - Specification complete
  • "implemented" - Code written
  • "verified" - Tests passing

design_components

Purpose: Link design artifacts to implementation tasks

{
  "design_components": [
    {
      "type": "figma",
      "url": "https://figma.com/file/abc123/Login-Flow",
      "description": "Login page mockups with responsive breakpoints"
    },
    {
      "type": "wireframe",
      "path": "docs/design/checkout-wireframe.png",
      "description": "Checkout flow wireframe"
    }
  ]
}

Component types:

  • "figma" - Figma designs
  • "wireframe" - Low-fidelity wireframes
  • "mockup" - High-fidelity mockups
  • "prototype" - Interactive prototypes
  • "sketch" - Sketch files

Purpose: Reference architectural decisions that govern implementation

{
  "related_adrs": [
    {
      "id": "ADR-003",
      "path": "docs/adr/003-jwt-authentication.md",
      "title": "Use JWT for stateless authentication",
      "decision": "Implement JWT with RS256 signing and 15-minute expiry"
    },
    {
      "id": "ADR-007",
      "path": "docs/adr/007-database-choice.md",
      "title": "PostgreSQL for primary database"
    }
  ]
}

rice_score

Purpose: RICE prioritization framework (Reach × Impact × Confidence / Effort)

{
  "rice_score": {
    "reach": 5000,
    "impact": 2,
    "confidence": 80,
    "effort": 3,
    "score": 2666.67
  }
}

Calculation: (5000 × 2 × 0.80) / 3 = 2666.67

Field definitions:

  • reach: Number of users/customers affected per time period (e.g., per quarter)
  • impact: 0.25 (minimal), 0.5 (low), 1 (medium), 2 (high), 3 (massive)
  • confidence: Percentage (0-100) - how confident are you in reach/impact estimates?
  • effort: Person-months of work
  • score: Auto-calculated or manually entered

wsjf_score

Purpose: WSJF prioritization (Weighted Shortest Job First) for SAFe/Agile

{
  "wsjf_score": {
    "business_value": 8,
    "time_criticality": 6,
    "risk_reduction": 5,
    "job_size": 3,
    "score": 6.33
  }
}

Calculation: (8 + 6 + 5) / 3 = 6.33

Field definitions (all on 1-10 scale):

  • business_value: Direct business impact
  • time_criticality: How time-sensitive is this?
  • risk_reduction: Does this reduce risk/enable other work?
  • job_size: Effort estimate (1 = tiny, 10 = huge)
  • score: Auto-calculated or manually entered

release_slice

Purpose: Group tasks into releases for planning

{
  "release_slice": "v1.2.0"
}

Examples:

  • "v1.2.0" - Semantic version
  • "Q1-2026" - Quarterly release
  • "MVP" - Minimum viable product
  • "Phase-2" - Project phase
  • "Sprint-15" - Sprint identifier

Line-Number Precision Format

Purpose

Reduce cognitive load by pointing agents to exact sections of large files instead of forcing them to read entire documents.

Format

{
  "path": "path/to/file.md",
  "lines": "10-50",
  "reason": "Why these lines matter"
}

Line Range Syntax

  • "10-50" - Lines 10 through 50 (inclusive)
  • "1-20,45-60" - Lines 1-20 AND 45-60 (multiple ranges)
  • Omit lines field to read entire file

Examples

Single range:

{
  "path": ".opencode/context/core/standards/code-quality.md",
  "lines": "53-95",
  "reason": "Pure function and immutability patterns"
}

Multiple ranges:

{
  "path": ".opencode/context/core/standards/security-patterns.md",
  "lines": "1-25,120-145,200-220",
  "reason": "JWT validation rules and token refresh patterns"
}

Entire file (backward compatible):

{
  "path": ".opencode/context/core/standards/code-quality.md",
  "reason": "All coding standards"
}

Legacy string format (still supported):

".opencode/context/core/standards/code-quality.md"

Backward Compatibility Rules

Rule 1: All new fields are optional

Existing task.json and subtask_NN.json files remain valid without any changes.

Rule 2: Mixed formats allowed

You can mix old and new formats in the same file:

{
  "context_files": [
    ".opencode/context/core/standards/code-quality.md",
    {
      "path": ".opencode/context/core/standards/security-patterns.md",
      "lines": "120-145",
      "reason": "JWT validation"
    }
  ]
}

Rule 3: Agent handling

Agents MUST support both formats:

function loadContextFile(ref: string | ContextFileReference): string {
  if (typeof ref === 'string') {
    // Legacy format: read entire file
    return readFile(ref);
  } else {
    // New format: read specified lines
    const content = readFile(ref.path);
    if (ref.lines) {
      return extractLines(content, ref.lines);
    }
    return content;
  }
}

Rule 4: Gradual migration

Projects can adopt enhanced fields incrementally:

  1. Start with line-number precision for large files
  2. Add domain modeling fields (bounded_context, module) when needed
  3. Add prioritization scores when planning releases
  4. Add contracts/ADRs when formalizing architecture

Complete Example

Enhanced task.json

{
  "id": "user-authentication",
  "name": "User Authentication System",
  "status": "active",
  "objective": "Implement JWT-based authentication with refresh tokens and role-based access control",
  "context_files": [
    {
      "path": ".opencode/context/core/standards/code-quality.md",
      "lines": "53-95",
      "reason": "Pure function patterns for auth service"
    },
    {
      "path": ".opencode/context/core/standards/security-patterns.md",
      "lines": "120-145,200-220",
      "reason": "JWT validation and token refresh patterns"
    }
  ],
  "reference_files": [
    {
      "path": "src/middleware/auth.middleware.ts",
      "lines": "1-50",
      "reason": "Existing auth middleware to extend"
    },
    "package.json"
  ],
  "exit_criteria": [
    "All tests passing with >90% coverage",
    "JWT tokens signed with RS256",
    "Refresh token rotation implemented",
    "Role-based access control working"
  ],
  "subtask_count": 5,
  "completed_count": 0,
  "created_at": "2026-02-14T10:00:00Z",
  "bounded_context": "authentication",
  "module": "@app/auth",
  "vertical_slice": "user-login",
  "contracts": [
    {
      "type": "api",
      "name": "AuthAPI",
      "path": "src/api/auth.contract.ts",
      "status": "defined",
      "description": "REST endpoints for login, logout, refresh, verify"
    },
    {
      "type": "event",
      "name": "UserAuthenticatedEvent",
      "status": "draft",
      "description": "Event emitted on successful authentication"
    }
  ],
  "design_components": [
    {
      "type": "figma",
      "url": "https://figma.com/file/xyz789/Auth-Flows",
      "description": "Login and registration UI mockups"
    }
  ],
  "related_adrs": [
    {
      "id": "ADR-003",
      "path": "docs/adr/003-jwt-authentication.md",
      "title": "Use JWT for stateless authentication",
      "decision": "JWT with RS256, 15-min access tokens, 7-day refresh tokens"
    }
  ],
  "rice_score": {
    "reach": 10000,
    "impact": 3,
    "confidence": 90,
    "effort": 4,
    "score": 6750
  },
  "wsjf_score": {
    "business_value": 9,
    "time_criticality": 8,
    "risk_reduction": 7,
    "job_size": 4,
    "score": 6
  },
  "release_slice": "v1.0.0"
}

Enhanced subtask_NN.json

{
  "id": "user-authentication-02",
  "seq": "02",
  "title": "Implement JWT service with token generation and validation",
  "status": "pending",
  "depends_on": ["01"],
  "parallel": false,
  "context_files": [
    {
      "path": ".opencode/context/core/standards/code-quality.md",
      "lines": "53-72",
      "reason": "Pure function patterns"
    },
    {
      "path": ".opencode/context/core/standards/security-patterns.md",
      "lines": "120-145",
      "reason": "JWT signing and validation rules"
    }
  ],
  "reference_files": [
    {
      "path": "src/config/jwt.config.ts",
      "reason": "JWT configuration constants"
    }
  ],
  "suggested_agent": "CoderAgent",
  "acceptance_criteria": [
    "JWT tokens signed with RS256 algorithm",
    "Access tokens expire in 15 minutes",
    "Refresh tokens expire in 7 days",
    "Token validation includes signature and expiry checks",
    "Unit tests cover all token operations",
    "No secrets hardcoded in code"
  ],
  "deliverables": [
    "src/auth/jwt.service.ts",
    "src/auth/jwt.service.test.ts"
  ],
  "bounded_context": "authentication",
  "module": "@app/auth",
  "contracts": [
    {
      "type": "interface",
      "name": "JWTService",
      "path": "src/auth/jwt.service.ts",
      "status": "implemented",
      "description": "Interface for JWT operations (sign, verify, refresh)"
    }
  ],
  "related_adrs": [
    {
      "id": "ADR-003",
      "path": "docs/adr/003-jwt-authentication.md"
    }
  ]
}

Migration Guide

For TaskManager Agents

When creating new tasks:

  1. Use line-number precision for large files (>100 lines):

    {
      "path": ".opencode/context/core/standards/code-quality.md",
      "lines": "53-95",
      "reason": "Pure function patterns"
    }
    
  2. Add domain modeling fields when known:

    {
      "bounded_context": "authentication",
      "module": "@app/auth",
      "vertical_slice": "user-login"
    }
    
  3. Link design artifacts for UI tasks:

    {
      "design_components": [
        {
          "type": "figma",
          "url": "https://figma.com/...",
          "description": "Login page mockups"
        }
      ]
    }
    
  4. Reference ADRs for architectural decisions:

    {
      "related_adrs": [
        {
          "id": "ADR-003",
          "path": "docs/adr/003-jwt-authentication.md"
        }
      ]
    }
    

For Working Agents (CoderAgent, etc.)

When reading tasks:

  1. Handle both context file formats:

    const contextFiles = task.context_files || [];
    for (const ref of contextFiles) {
      if (typeof ref === 'string') {
        // Read entire file
        const content = await readFile(ref);
      } else {
        // Read specified lines
        const content = await readFileLines(ref.path, ref.lines);
        console.log(`Reading ${ref.path} (${ref.lines}): ${ref.reason}`);
      }
    }
    
  2. Use contract information to understand dependencies:

    const contracts = task.contracts || [];
    const apiContracts = contracts.filter(c => c.type === 'api');
    // Load API contract definitions before implementing
    
  3. Check ADRs before making architectural decisions:

    const adrs = task.related_adrs || [];
    for (const adr of adrs) {
      if (adr.path) {
        const decision = await readFile(adr.path);
        // Apply architectural constraints from ADR
      }
    }
    

  • task-schema.md - Base schema (backward compatible foundation)
  • ../guides/splitting-tasks.md - How to decompose features
  • ../guides/managing-tasks.md - Lifecycle workflow
  • ../lookup/task-commands.md - CLI reference