Skip to main content

CODITECT Track Nomenclature Standard

1. Overview​

Purpose​

The CODITECT Track Nomenclature Standard defines a hierarchical, extensible system for organizing project tasks across parallel work streams. This standard enables:

  • Consistent task identification across all CODITECT projects
  • Automated agent routing via track-to-agent mapping
  • Hierarchical task decomposition with dot-notation IDs
  • Parallel execution tracking across multiple work streams
  • Customer extensibility while maintaining framework consistency

Scope​

This standard applies to:

  • All CODITECT framework development projects
  • Customer projects using CODITECT tooling
  • Multi-agent orchestration workflows
  • Project management and execution plans
  • Task tracking and progress reporting

Design Principles​

PrincipleDescription
HierarchicalTrack.Section.Task[.Subtask] structure
Immutable CoreFramework tracks (A-F) cannot be changed
Customer ExtensibleProjects can add tracks G+ via configuration
Agent-MappedEach track maps to recommended agent types
Human-ReadableClear semantic meaning from ID alone

2. Task ID Format​

Syntax​

<Track>.<Section>.<Task>[.<Subtask>]

Components​

ComponentFormatDescriptionRequired
Track[A-Z]Single uppercase letterYes
Section[1-9][0-9]*Numeric section (1-based)Yes
Task[1-9][0-9]*Numeric task (1-based)Yes
Subtask[1-9][0-9]*Numeric subtask (1-based)No

Examples​

# Basic task
A.1.1: Setup FastAPI application structure

# Task with subtask
A.1.1.1: Create project directory structure

# Multi-level hierarchy
A.1.1.1.1: Initialize virtual environment (rarely needed)

# Different tracks
B.2.3: Implement authentication UI components
C.3.5: Configure Kubernetes cluster autoscaling
D.1.2: Implement OAuth2 token validation

Validation Regex​

^[A-Z]\.\d+\.\d+(\.\d+)?$

Valid:

  • A.1.1
  • B.2.3
  • C.10.25
  • A.1.1.1

Invalid:

  • a.1.1 (lowercase track)
  • A.0.1 (section must start at 1)
  • A.1.1.1.1 (too many levels)
  • AA.1.1 (multi-character track)

3. Tier 1: Framework Tracks (Immutable)​

Framework tracks A-F are immutable and available in all CODITECT projects. They cannot be redefined or removed.

Track A: Backend API​

Purpose: Server-side application logic, APIs, data processing

Recommended Agents:

  • senior-architect - Architecture design and planning
  • backend-engineer - Implementation and coding
  • database-architect - Data modeling and optimization
  • api-design-specialist - RESTful/GraphQL API design

Typical Sections:

  1. Setup & Configuration - Project initialization, dependencies
  2. Database Layer - Models, migrations, queries
  3. Business Logic - Services, controllers, domain logic
  4. API Endpoints - Routes, handlers, middleware
  5. Integration - External services, webhooks
  6. Optimization - Performance tuning, caching

Example Tasks:

A.1.1: Initialize FastAPI application structure
A.1.2: Configure PostgreSQL connection pooling
A.2.1: Design User and Organization data models
A.2.2: Create Alembic migration for initial schema
A.3.1: Implement authentication service layer
A.4.1: Create /api/v1/auth endpoints
A.5.1: Integrate Stripe payment processing
A.6.1: Implement Redis caching for frequently accessed data

Track B: Frontend UI​

Purpose: Client-side user interface, user experience, browser interactions

Recommended Agents:

  • frontend-react-typescript-expert - React/TypeScript development
  • ui-ux-designer - User interface and experience design
  • accessibility-specialist - WCAG compliance and a11y
  • frontend-performance-expert - Bundle optimization, Core Web Vitals

Typical Sections:

  1. Setup & Tooling - Vite, build configuration, dependencies
  2. Component Library - Reusable UI components
  3. Pages & Routing - Application views and navigation
  4. State Management - Redux/Zustand/React Query
  5. Integration - API client, authentication
  6. Optimization - Code splitting, lazy loading, caching

Example Tasks:

B.1.1: Initialize Vite + React + TypeScript project
B.1.2: Configure Tailwind CSS and design tokens
B.2.1: Create Button component with variants
B.2.2: Build DataTable component with sorting/filtering
B.3.1: Implement Dashboard page layout
B.3.2: Configure React Router with protected routes
B.4.1: Setup Zustand store for authentication state
B.5.1: Create API client with Axios interceptors
B.6.1: Implement code splitting for route-based lazy loading

Track C: DevOps/Infrastructure​

Purpose: Deployment, orchestration, infrastructure, CI/CD, monitoring

Recommended Agents:

  • devops-engineer - CI/CD pipelines, automation
  • cloud-architect - Cloud infrastructure design (AWS/GCP/Azure)
  • kubernetes-specialist - Container orchestration
  • sre-specialist - Reliability, monitoring, incident response

Typical Sections:

  1. Infrastructure as Code - Terraform, Pulumi, CloudFormation
  2. Container Orchestration - Docker, Kubernetes, Helm
  3. CI/CD Pipelines - GitHub Actions, GitLab CI, Jenkins
  4. Monitoring & Observability - Prometheus, Grafana, Jaeger
  5. Networking - Load balancers, DNS, CDN
  6. Disaster Recovery - Backups, failover, incident response

Example Tasks:

C.1.1: Define GCP infrastructure with Terraform modules
C.1.2: Create VPC network with private subnets
C.2.1: Build Docker images for backend and frontend
C.2.2: Deploy GKE cluster with autoscaling node pools
C.3.1: Configure GitHub Actions workflow for automated testing
C.3.2: Implement blue-green deployment strategy
C.4.1: Setup Prometheus + Grafana monitoring stack
C.4.2: Create alerting rules for SLO violations
C.5.1: Configure Cloud Load Balancer with SSL termination
C.6.1: Implement automated database backups to GCS

Track D: Security​

Purpose: Authentication, authorization, compliance, vulnerability management

Recommended Agents:

  • security-specialist - Security architecture and audits
  • compliance-specialist - SOC2, GDPR, HIPAA compliance
  • penetration-tester - Vulnerability assessment
  • crypto-specialist - Encryption, key management

Typical Sections:

  1. Authentication & Authorization - OAuth2, RBAC, MFA
  2. Data Protection - Encryption at rest/transit, key rotation
  3. Network Security - Firewalls, WAF, DDoS protection
  4. Compliance - Audit logs, data retention, privacy
  5. Vulnerability Management - Scanning, patching, CVE tracking
  6. Incident Response - Security monitoring, threat detection

Example Tasks:

D.1.1: Implement OAuth2 Authorization Code flow
D.1.2: Design RBAC permission model with roles and policies
D.1.3: Enable MFA using TOTP (Google Authenticator)
D.2.1: Configure AES-256 encryption for sensitive database fields
D.2.2: Implement automatic KMS key rotation (90-day cycle)
D.3.1: Configure GCP Cloud Armor WAF rules
D.4.1: Setup audit logging for all data access events
D.5.1: Run Trivy vulnerability scan on container images
D.6.1: Configure real-time alerting for suspicious activity

Track E: Testing/QA​

Purpose: Test development, quality assurance, test automation, coverage

Recommended Agents:

  • testing-specialist - Test strategy and framework design
  • qa-automation-engineer - Automated test development
  • performance-tester - Load testing, stress testing
  • accessibility-tester - a11y testing and validation

Typical Sections:

  1. Unit Testing - Component/function-level tests
  2. Integration Testing - API and service integration tests
  3. End-to-End Testing - User workflow automation
  4. Performance Testing - Load, stress, endurance tests
  5. Security Testing - OWASP ZAP, penetration testing
  6. Test Infrastructure - Test databases, mocking, fixtures

Example Tasks:

E.1.1: Setup Jest testing framework for backend
E.1.2: Write unit tests for authentication service (>90% coverage)
E.2.1: Create integration tests for /api/v1/auth endpoints
E.2.2: Test database transaction rollback scenarios
E.3.1: Implement Playwright tests for login workflow
E.3.2: Create E2E tests for complete user registration flow
E.4.1: Run k6 load test (1000 RPS sustained for 10 minutes)
E.5.1: Run OWASP ZAP security scan on staging environment
E.6.1: Setup isolated test PostgreSQL database with fixtures

Track F: Documentation​

Purpose: Technical documentation, API docs, user guides, runbooks

Recommended Agents:

  • codi-documentation-writer - Technical documentation specialist
  • api-documentation-specialist - OpenAPI, API reference docs
  • technical-writer - User guides, tutorials, runbooks
  • doc-automation-engineer - Doc generation, automation

Typical Sections:

  1. Setup Guides - Installation, configuration, quickstart
  2. API Documentation - OpenAPI specs, endpoint reference
  3. User Guides - Feature documentation, tutorials
  4. Operational Docs - Runbooks, incident response, playbooks
  5. Architecture Docs - ADRs, C4 diagrams, system design
  6. Release Notes - Changelogs, migration guides

Example Tasks:

F.1.1: Create USER-QUICK-START.md with 10-minute onboarding
F.1.2: Document environment variable configuration
F.2.1: Generate OpenAPI 3.0 specification from FastAPI app
F.2.2: Write authentication endpoint reference documentation
F.3.1: Create step-by-step tutorial for creating first project
F.4.1: Write incident response runbook for database failover
F.5.1: Create ADR-001 for selecting PostgreSQL over MongoDB
F.5.2: Generate C4 Context diagram for system architecture
F.6.1: Write v1.0.0 release notes with breaking changes

4. Tier 2: Customer Extension (Overridable)​

Projects can extend tracks beyond A-F by creating .coditect/config/tracks.json configuration.

Configuration File​

Path: .coditect/config/tracks.json

Schema:

{
  "$schema": "https://coditect.ai/schemas/tracks-v1.schema.json",
  "version": "1.0.0",
  "tracks": [
    {
      "id": "G",
      "name": "Data Science",
      "description": "ML model training, data pipelines, analytics",
      "agents": [
        "data-scientist",
        "ml-engineer",
        "analytics-specialist"
      ],
      "sections": [
        {
          "id": 1,
          "name": "Data Collection",
          "description": "ETL pipelines, data ingestion"
        },
        {
          "id": 2,
          "name": "Feature Engineering",
          "description": "Feature extraction, transformation"
        },
        {
          "id": 3,
          "name": "Model Training",
          "description": "Model development and tuning"
        }
      ]
    }
  ]
}

JSON Schema Definition​

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "CODITECT Tracks Configuration",
  "type": "object",
  "required": ["version", "tracks"],
  "properties": {
    "version": {
      "type": "string",
      "pattern": "^\\d+\\.\\d+\\.\\d+$",
      "description": "Semantic version of tracks configuration"
    },
    "tracks": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["id", "name", "description", "agents"],
        "properties": {
          "id": {
            "type": "string",
            "pattern": "^[G-Z]$",
            "description": "Track identifier (G-Z only)"
          },
          "name": {
            "type": "string",
            "minLength": 1,
            "maxLength": 50,
            "description": "Human-readable track name"
          },
          "description": {
            "type": "string",
            "minLength": 1,
            "maxLength": 200,
            "description": "Track purpose and scope"
          },
          "agents": {
            "type": "array",
            "minItems": 1,
            "items": {
              "type": "string"
            },
            "description": "Recommended agent slugs for this track"
          },
          "sections": {
            "type": "array",
            "items": {
              "type": "object",
              "required": ["id", "name"],
              "properties": {
                "id": {
                  "type": "integer",
                  "minimum": 1
                },
                "name": {
                  "type": "string",
                  "minLength": 1
                },
                "description": {
                  "type": "string"
                }
              }
            }
          }
        }
      }
    }
  }
}

Example Configurations​

Example 1: Data Science Project​

{
  "version": "1.0.0",
  "tracks": [
    {
      "id": "G",
      "name": "Data Science",
      "description": "ML model development and data analytics",
      "agents": [
        "data-scientist",
        "ml-engineer",
        "analytics-specialist"
      ],
      "sections": [
        {"id": 1, "name": "Data Collection"},
        {"id": 2, "name": "Feature Engineering"},
        {"id": 3, "name": "Model Training"},
        {"id": 4, "name": "Model Evaluation"},
        {"id": 5, "name": "Deployment"}
      ]
    }
  ]
}

Example Tasks:

G.1.1: Setup Airflow DAG for daily data ingestion
G.2.1: Extract user behavior features from clickstream data
G.3.1: Train XGBoost model for churn prediction
G.4.1: Calculate precision/recall metrics on validation set
G.5.1: Deploy model to SageMaker endpoint

Example 2: Mobile Development​

{
  "version": "1.0.0",
  "tracks": [
    {
      "id": "H",
      "name": "Mobile Apps",
      "description": "iOS and Android native applications",
      "agents": [
        "ios-developer",
        "android-developer",
        "mobile-architect"
      ],
      "sections": [
        {"id": 1, "name": "iOS Development"},
        {"id": 2, "name": "Android Development"},
        {"id": 3, "name": "Cross-Platform"},
        {"id": 4, "name": "Mobile Backend"},
        {"id": 5, "name": "App Store Deployment"}
      ]
    }
  ]
}

Example Tasks:

H.1.1: Create SwiftUI views for authentication flow
H.2.1: Implement Jetpack Compose UI for dashboard
H.3.1: Setup React Native project with TypeScript
H.4.1: Implement push notification service with FCM
H.5.1: Submit iOS app to App Store Connect
H.5.2: Upload Android APK to Google Play Console

Example 3: Multi-Track Extension​

{
  "version": "1.0.0",
  "tracks": [
    {
      "id": "G",
      "name": "Data Science",
      "description": "ML and analytics",
      "agents": ["data-scientist", "ml-engineer"]
    },
    {
      "id": "H",
      "name": "Business Intelligence",
      "description": "Reporting and dashboards",
      "agents": ["bi-analyst", "data-visualization-specialist"]
    },
    {
      "id": "I",
      "name": "Content Management",
      "description": "CMS and content workflows",
      "agents": ["cms-specialist", "content-strategist"]
    }
  ]
}

Configuration Validation​

# Validate tracks configuration
python3 scripts/core/validate-tracks-config.py .coditect/config/tracks.json

# Output:
# ✓ Valid JSON syntax
# ✓ Schema validation passed
# ✓ No duplicate track IDs
# ✓ All track IDs in range G-Z
# ✓ All referenced agents exist in agents/

5. Tier 3: Project-Specific (Ephemeral)​

Project-specific tracks are defined directly in PROJECT-PLAN.md or PILOT-*.md and do not require configuration files. These are typically ephemeral - used for one-time or temporary work streams.

Definition Format​

## Track Z: Migration Tasks

**Purpose:** Migrate legacy PostgreSQL 11 → PostgreSQL 16

**Duration:** 2 weeks (ephemeral)

**Agents:** database-architect, migration-specialist

### Tasks

- Z.1.1: Analyze schema compatibility with pg_upgrade
- Z.1.2: Export production data to SQL dump
- Z.2.1: Setup PostgreSQL 16 test environment
- Z.2.2: Import data and validate integrity
- Z.3.1: Run performance benchmarks (compare P95 latency)
- Z.3.2: Update application connection strings
- Z.4.1: Execute production cutover during maintenance window

When to Use Tier 3​

ScenarioUse Tier 3
One-time migrationsYes (temporary track)
Short-lived initiativesYes (e.g., security audit sprint)
Experimental featuresYes (prototype track)
Recurring workflowsNo (use Tier 2 instead)
Core competenciesNo (use Tier 1 or Tier 2)

Examples​

# Migration track (ephemeral)
Z.1.1: Migrate Redis 6 → Redis 7
Z.2.1: Update client libraries to support RESP3

# Audit track (short-lived)
Y.1.1: Run SOC2 compliance audit
Y.2.1: Remediate identified security gaps

# Prototype track (experimental)
X.1.1: Build WebAssembly proof-of-concept
X.2.1: Benchmark WASM vs JavaScript performance

6. Agent Mapping Rules​

How Tracks Map to Agents​

Each track maintains a recommended agent list. When a task is created, the system uses this mapping to route work to appropriate agents.

Mapping Hierarchy​

Task ID → Track → Recommended Agents → /which selection → Agent invocation

Example:

A.3.1 → Track A → [senior-architect, backend-engineer, database-architect]
        ↓
    /which "implement authentication service"
        ↓
    Recommended: senior-architect (architecture design)
        ↓
    /agent senior-architect "design authentication service architecture"

/which Command Integration​

The /which command uses track mappings to recommend agents:

$ /which A.3.1 "implement authentication service"

Task: A.3.1 - Implement authentication service
Track: A (Backend API)

Recommended Agents:
  1. senior-architect (confidence: 0.92)
     - Expertise: System architecture, design patterns
     - Reason: Auth is architectural concern

  2. backend-engineer (confidence: 0.88)
     - Expertise: FastAPI, Python, implementation
     - Reason: Service implementation in Python

  3. security-specialist (confidence: 0.85)
     - Expertise: OAuth2, JWT, security best practices
     - Reason: Authentication has security implications

Suggested invocation:
  /agent senior-architect "design authentication service architecture for A.3.1"

Multi-Track Tasks​

Some tasks span multiple tracks and require coordination:

# Cross-track task requiring backend + security
Task: Implement OAuth2 token validation
Tracks: A (implementation) + D (security review)

Invocations:
  1. /agent backend-engineer "implement OAuth2 token validation (A.4.2)"
  2. /agent security-specialist "review OAuth2 implementation for vulnerabilities (D.1.2)"

Agent Mapping Configuration​

Track-to-agent mappings are stored in:

Framework tracks: config/track-agent-mappings.json

{
  "tracks": {
    "A": {
      "name": "Backend API",
      "agents": [
        {"slug": "senior-architect", "priority": 1},
        {"slug": "backend-engineer", "priority": 2},
        {"slug": "database-architect", "priority": 3}
      ]
    },
    "B": {
      "name": "Frontend UI",
      "agents": [
        {"slug": "frontend-react-typescript-expert", "priority": 1},
        {"slug": "ui-ux-designer", "priority": 2}
      ]
    }
  }
}

Customer tracks: .coditect/config/tracks.json (see Tier 2 above)

7. Validation Requirements​

Task ID Validation​

Regex Pattern:

^[A-Z]\.\d+\.\d+(\.\d+)?$

Validation Logic:

import re

TASK_ID_PATTERN = re.compile(r'^[A-Z]\.\d+\.\d+(\.\d+)?$')

def validate_task_id(task_id: str) -> tuple[bool, str]:
    """Validate task ID format.

    Returns:
        (is_valid, error_message)
    """
    if not TASK_ID_PATTERN.match(task_id):
        return False, f"Invalid format: {task_id}. Expected: Track.Section.Task[.Subtask]"

    parts = task_id.split('.')
    track = parts[0]

    # Validate track exists
    if track in ['A', 'B', 'C', 'D', 'E', 'F']:
        return True, ""

    # Check custom tracks
    if not track_exists(track):
        return False, f"Unknown track: {track}. Define in .coditect/config/tracks.json"

    return True, ""

# Examples
validate_task_id("A.1.1")         # (True, "")
validate_task_id("G.2.3")         # (True, "") if Track G defined
validate_task_id("a.1.1")         # (False, "Invalid format...")
validate_task_id("A.0.1")         # (False, "Invalid format...")
validate_task_id("AA.1.1")        # (False, "Invalid format...")

Required Fields​

Every task in a plan must include:

FieldTypeRequiredDescription
Task IDStringYesTrack.Section.Task[.Subtask]
DescriptionStringYesHuman-readable task summary
StatusEnumYespending, in_progress, blocked, completed
TrackStringYesExtracted from Task ID
Assigned AgentStringNoAgent slug (if assigned)
DependenciesArrayNoList of Task IDs that must complete first
Estimated HoursNumberNoTime estimate

Example Task Definition:

- id: A.3.1
  description: Implement authentication service layer
  status: pending
  track: A
  assigned_agent: senior-architect
  dependencies: [A.2.1, A.2.2]
  estimated_hours: 8

Automated Validation​

# Validate all tasks in a plan
python3 scripts/core/validate-project-plan.py \
  docs/project-management/PROJECT-PLAN.md

# Output:
# ✓ 127 tasks validated
# ✗ 3 errors found:
#   - Task B.2.5: Missing required field 'description'
#   - Task X.1.1: Unknown track 'X' (not in tracks.json)
#   - Task A.3.5: Invalid dependency 'B.99.99' (task does not exist)

8. Migration Guide​

For Existing Projects​

If your project uses an older task numbering scheme, follow this migration path:

Step 1: Analyze Current Scheme​

# Extract all task IDs from current plan
grep -E '^\s*-\s*\[.\]' docs/project-management/PROJECT-PLAN.md | \
  sed 's/.*\[\(.\)\] \([A-Z0-9.-]*\).*/\2/' | \
  sort | uniq

Common Legacy Patterns:

# Sequential numbering
1, 2, 3, 4, ...

# Section-based
1.1, 1.2, 2.1, 2.2, ...

# Component prefixes
BE-001, FE-002, DB-003, ...

# Mixed formats
TASK-123, Feature-456, BUG-789

Step 2: Create Mapping​

Map legacy IDs to new track-based IDs:

# mapping.yaml
legacy_to_track:
  # Backend tasks → Track A
  BE-001: A.1.1
  BE-002: A.1.2
  TASK-123: A.3.1

  # Frontend tasks → Track B
  FE-001: B.1.1
  FE-002: B.2.1

  # Infrastructure → Track C
  INFRA-001: C.1.1
  INFRA-002: C.2.1

Step 3: Run Migration Script​

python3 scripts/core/migrate-task-ids.py \
  --input docs/project-management/PROJECT-PLAN.md \
  --mapping mapping.yaml \
  --output docs/project-management/PROJECT-PLAN-v2.md \
  --backup

Script Actions:

  1. Backup original file
  2. Replace legacy IDs with track-based IDs
  3. Update cross-references and dependencies
  4. Validate new format
  5. Generate migration report

Step 4: Update Linked Documents​

# Find all references to old task IDs
grep -r "BE-001" docs/

# Update references in:
# - ADRs (architectural decision records)
# - Session logs
# - Git commit messages (add note in next commit)
# - External documentation

Step 5: Validate Migration​

# Validate new plan
python3 scripts/core/validate-project-plan.py \
  docs/project-management/PROJECT-PLAN-v2.md

# Check for broken references
python3 scripts/core/check-task-references.py \
  docs/project-management/PROJECT-PLAN-v2.md

Migration Checklist​

- [ ] Analyze current task ID scheme
- [ ] Create legacy-to-track mapping (mapping.yaml)
- [ ] Run migration script with --backup flag
- [ ] Review generated PROJECT-PLAN-v2.md
- [ ] Update cross-references in ADRs and docs
- [ ] Validate migrated plan (no errors)
- [ ] Test /which command with new task IDs
- [ ] Update team documentation
- [ ] Archive legacy plan as PROJECT-PLAN-legacy.md
- [ ] Rename PROJECT-PLAN-v2.md → PROJECT-PLAN.md

For large projects, migrate incrementally:

# Week 1: Migrate Track A (Backend) only
A.1.1, A.1.2, A.2.1, ... (new format)
BE-003, BE-004, ...       (legacy format - not migrated yet)

# Week 2: Migrate Track B (Frontend)
B.1.1, B.1.2, ...         (new format)
FE-005, FE-006, ...       (legacy format)

# Week 3: Complete migration
All tasks in new format

9. Best Practices​

Task Decomposition​

LevelGranularityExample
SectionMajor phase or componentA.1: Setup & Configuration
TaskDeliverable work unit (2-8 hours)A.1.1: Initialize FastAPI project
SubtaskImplementation detail (<2 hours)A.1.1.1: Create virtual environment

Avoid subtasks when possible. Most tasks should be at the Task level (3 parts).

Parallel Execution​

Tasks across different tracks can execute in parallel:

# These can run simultaneously
A.3.1: Implement auth service (backend)
B.2.1: Build login UI component (frontend)
C.2.1: Setup Kubernetes secrets (devops)
D.1.1: Design OAuth2 flow (security review)

Tasks within the same track often have dependencies:

# These must run sequentially
A.2.1: Create User model
  ↓ (dependency)
A.2.2: Create migration for User table
  ↓ (dependency)
A.3.1: Implement user service using User model

Track Selection Guidelines​

Work TypeRecommended Track
API endpoint creationTrack A (Backend)
React componentTrack B (Frontend)
Database migrationTrack A (Backend)
UI design systemTrack B (Frontend)
Kubernetes deploymentTrack C (DevOps)
OAuth2 implementationTrack D (Security)
Integration testTrack E (Testing)
API documentationTrack F (Documentation)
Data pipelineTrack G (if configured)
One-time migrationTrack Z (ephemeral)

Naming Conventions​

Task Descriptions:

# Good (starts with verb, specific)
A.3.1: Implement user authentication service with JWT
B.2.3: Create responsive navigation component with mobile support
C.4.1: Configure Prometheus alerting rules for API latency

# Bad (vague, no verb)
A.3.1: Authentication
B.2.3: Navigation
C.4.1: Monitoring

Agent Invocations:

# Good (includes task ID, specific scope)
/agent senior-architect "design user authentication service architecture for A.3.1"
/agent frontend-react-typescript-expert "implement responsive navbar component for B.2.3"

# Bad (no context, too vague)
/agent senior-architect "design authentication"
/agent frontend-react-typescript-expert "make navbar"

10. Tooling Support​

Command-Line Tools​

# Create new task in plan
coditect task create A.3.1 \
  --description "Implement authentication service" \
  --track A \
  --status pending \
  --estimate 8

# Assign agent to task
coditect task assign A.3.1 --agent senior-architect

# Mark task complete
coditect task complete A.3.1

# List all tasks in track
coditect task list --track A --status pending

# Validate task ID
coditect task validate A.3.1

IDE Integration​

VS Code Extension: coditect-task-tracker

Features:

  • Syntax highlighting for task IDs in Markdown
  • Hover tooltips showing task details
  • Auto-completion for track IDs
  • Inline validation errors
  • Quick actions (assign agent, mark complete)

Git Commit Messages​

Include task IDs in commit messages:

git commit -m "feat(A.3.1): implement JWT-based authentication service

- Add FastAPI dependency for JWT handling
- Create auth service with login/refresh endpoints
- Implement token validation middleware

Task: A.3.1
Track: A (Backend API)
Agent: senior-architect"

11. Frequently Asked Questions​

Can I redefine framework tracks A-F?​

No. Framework tracks A-F are immutable across all CODITECT projects. This ensures consistency and enables shared tooling.

How do I add a custom track?​

Create .coditect/config/tracks.json and define tracks G-Z. See Tier 2: Customer Extension.

Can I skip tracks (e.g., use Track A and Track H but not B-G)?​

Yes. Only define the tracks you need. Unused tracks (B-G in this example) remain available but unassigned.

What's the maximum number of tracks?​

26 total (A-Z). Framework uses A-F (6 tracks), leaving G-Z (20 tracks) for customer use.

Should I use subtasks (4-part IDs)?​

Rarely. Most work should be at the task level (3-part IDs). Use subtasks only for complex tasks requiring detailed decomposition.

How do I handle cross-track dependencies?​

Use the dependencies field:

- id: B.3.1
  description: Implement login UI
  dependencies: [A.3.1]  # Depends on backend auth service

Can tasks in the same section run in parallel?​

Yes, if they have no dependencies:

A.2.1: Create User model       # Can run in parallel
A.2.2: Create Organization model  # Can run in parallel
A.2.3: Create Project model       # Can run in parallel

What happens if a track isn't defined in tracks.json?​

Validation will fail:

✗ Error: Task X.1.1 references undefined track 'X'
  Fix: Add track 'X' to .coditect/config/tracks.json

12. References​

External Resources​

Changelog​

VersionDateChanges
1.0.02026-01-04Initial standard release

Standard Owner: AZ1.AI INC Maintained By: Hal Casteel License: Proprietary (CODITECT Framework) Status: Active Next Review: 2026-04-04 (quarterly)