CODITECT Agentic Communication Standard

Standard ID: CODITECT-STD-001 Version: 1.1.0 Status: Approved Effective Date: January 1, 2026 Updated: January 4, 2026 Owner: Hal Casteel, Founder/CEO/CTO, AZ1.AI INC

---

1. Purpose

This standard establishes the unified nomenclature for all CODITECT agentic systems, ensuring:

1. Consistent communication between AI agents, humans, and automated systems
2. Zero ambiguity in task references across planning documents
3. Parallel execution without collision through clear ownership boundaries
4. Traceable progress with hierarchical task identifiers

---

2. Scope

This standard applies to:

• All PROJECT-PLAN.md and PILOT-PARALLEL-EXECUTION-PLAN.md documents (SSOT)
• All agent prompts and invocations
• All session logs and checkpoints
• All progress reporting and status updates
• All CI/CD pipeline references
• All inter-agent communication

---

3. Track Nomenclature

3.1 Track Definition

A Track is a parallel execution domain with:

• Clear ownership boundary (single repository or component)
• No collision with other tracks (can run simultaneously)
• Explicit dependencies when sequential execution required

3.2 Official Track Registry

Track	Domain	Repository/Component	Owner
Track A	Backend API	coditect-cloud-infra/backend	Backend Team
Track B	Frontend UI	coditect-cloud-frontend	Frontend Team
Track C	DevOps & Deployment	Infrastructure/K8s	DevOps Team
Track D	Security Hardening	Cross-cutting	Security Team
Track E	Integration Testing	Test suites	QA Team
Track F	Documentation	Docs sites	Docs Team
Track G	DMS Integration	Document Management	Product Team

3.3 Track Identifier Format

Track <LETTER>.<MAJOR>.<MINOR>

Examples:
- Track A.1      → Backend: Heartbeat System
- Track A.1.1    → Backend: Heartbeat: Background thread implementation
- Track B.3.4.2  → Frontend: Commerce UI: Entitlements: Product access badges
- Track D.2.3    → Security: P1 Security: Error response hardening

Rules:

1. Track letter is UPPERCASE (A-Z)
2. Numbers are dot-separated, starting from 1
3. Maximum 4 levels of hierarchy (Track X.Y.Z.W)
4. Each level represents increasing specificity

3.4 Hierarchical Track Nomenclature System (ADR-054)

CODITECT uses a 3-tier hierarchical track nomenclature system for customer extensibility while maintaining framework consistency.

Task ID Format: Track.Section.Task[.Subtask]

Examples:

• A.9.1 - Track A (Backend), Section 9, Task 1
• A.9.1.1 - Track A, Section 9, Task 1, Subtask 1
• B.3.2 - Track B (Frontend), Section 3, Task 2
• G.1.5.2 - Track G (Customer-defined), Section 1, Task 5, Subtask 2

Tier 1: Framework Tracks (Immutable)

Tracks A-F are reserved for CODITECT framework and cannot be redefined:

Track	Domain	Primary Agents
A	Backend API	senior-architect, backend-engineer, database-architect
B	Frontend UI	frontend-react-typescript-expert, ui-ux-designer
C	DevOps/Infra	devops-engineer, cloud-architect, kubernetes-specialist
D	Security	security-specialist, compliance-specialist
E	Testing/QA	testing-specialist, qa-automation-engineer
F	Documentation	codi-documentation-writer, api-documentation-specialist

Tier 2: Customer Extension (Overridable)

Customers can define tracks G+ in .coditect/config/tracks.json:

{
  "tracks": {
    "G": {
      "name": "Machine Learning",
      "description": "ML model training, data pipelines, MLOps",
      "agents": ["data-scientist", "ml-engineer"]
    },
    "H": {
      "name": "Business Intelligence",
      "description": "Analytics, reporting, dashboards",
      "agents": ["bi-analyst", "data-visualization-specialist"]
    }
  }
}

Tier 3: Project-Specific (Ephemeral)

Temporary tracks (X, Y, Z) defined in PROJECT-PLAN.md for one-time efforts:

## Track X: Legacy Migration (Sprint 3 Only)
**Purpose:** Migrate PostgreSQL 11 → PostgreSQL 16
**Agents:** database-architect, migration-specialist

### Tasks
- X.1.1: Analyze schema compatibility
- X.2.1: Setup PostgreSQL 16 test environment
- X.3.1: Execute production cutover

Validation Regex:

^[A-Z]\.\d{1,2}\.\d{1,3}(\.\d{1,3})*$

Cross-References:

• Standard: CODITECT-STANDARD-TRACK-NOMENCLATURE.md
• ADR: ADR-054: Hierarchical Track Nomenclature with Customer Extensibility

---

4. Complete Track Hierarchy

Track A: Backend API

Track A: Backend API (coditect-cloud-infra/backend)
├── A.1: Heartbeat System
│   ├── A.1.1: Background heartbeat thread implementation
│   ├── A.1.2: Automatic reconnection logic
│   ├── A.1.3: Network failure graceful degradation
│   └── A.1.4: Unit tests for heartbeat system
├── A.2: Admin Endpoints
│   ├── A.2.1: GET /api/v1/admin/users endpoint
│   ├── A.2.2: GET /api/v1/admin/licenses endpoint
│   ├── A.2.3: GET /api/v1/admin/analytics endpoint
│   └── A.2.4: Unit tests for admin endpoints
├── A.3: Commerce API ✅ COMPLETE
│   ├── A.3.1: Product catalog endpoints
│   ├── A.3.2: Shopping cart endpoints
│   ├── A.3.3: Checkout/payment endpoints
│   └── A.3.4: Stripe webhook handlers
├── A.4: Context Sync API
│   ├── A.4.1-A.4.8: Context sync models and endpoints
│   └── A.4.9-A.4.12: Migrations and tests
├── A.5: Team/Project Context Sync
│   ├── A.5.1: Team context models
│   ├── A.5.2: Team context endpoints
│   ├── A.5.3: Project context endpoints
│   └── A.5.4: GCS backup integration
└── A.6: Reference Data ✅ COMPLETE
    └── A.6.1: ISO standard models (Country, Currency, etc.)

Track B: Frontend UI

Track B: Frontend UI (coditect-cloud-frontend)
├── B.1: Core Setup
│   ├── B.1.1: React 18 + TypeScript strict mode
│   ├── B.1.2: Vite build optimizations
│   └── B.1.3-B.1.5: API client, React Query, Router
├── B.2: Auth Pages
│   ├── B.2.1: Landing page
│   ├── B.2.2: Register page
│   ├── B.2.3: Login page
│   └── B.2.4-B.2.6: Email verify, auth context, protected routes
├── B.3: Commerce UI
│   ├── B.3.1: Product catalog ✅
│   ├── B.3.2: Shopping cart ✅
│   ├── B.3.3: Checkout page ✅
│   └── B.3.4: Entitlement display
├── B.4: Dashboard
│   ├── B.4.1: Dashboard layout
│   ├── B.4.2: License display
│   └── B.4.3-B.4.5: Download, sessions, billing
├── B.5: Design System
│   └── B.5.1-B.5.5: Components, layout, colors, dark mode
├── B.6: Dark Mode ✅ COMPLETE
├── B.7: Legal Pages ✅ COMPLETE
├── B.8: Product Pages ✅ COMPLETE
├── B.9: Changelog ✅ COMPLETE
├── B.10: Careers
└── B.12: Design System Package
    ├── B.12.1-B.12.2: Compliance fixes ✅
    └── B.12.3: @coditect/ui package

Track C: DevOps & Deployment

Track C: DevOps & Deployment
├── C.1: Backend Deployment
│   ├── C.1.1: Backend Docker image
│   ├── C.1.2: GKE deployment manifest
│   ├── C.1.3: Service/Ingress for api.coditect.ai
│   ├── C.1.4: SSL certificate
│   └── C.1.5: Secret Manager integration
├── C.2: Frontend Deployment
│   ├── C.2.1: Frontend Docker image
│   ├── C.2.2: GKE deployment manifest
│   ├── C.2.3: Service/Ingress for auth.coditect.ai
│   ├── C.2.4: SSL certificate
│   └── C.2.5: CDN configuration
├── C.3: DNS & SSL
│   ├── C.3.1: DNS for api.coditect.ai
│   ├── C.3.2: DNS for auth.coditect.ai
│   ├── C.3.3: DNS for coditect.ai
│   ├── C.3.4: SSL verification
│   └── C.3.5: External endpoint testing
└── C.4: External Sites
    ├── C.4.1: docs.coditect.ai deployment
    ├── C.4.2: workflow.coditect.ai deployment
    └── C.4.3: Email infrastructure

Track D: Security Hardening

Track D: Security Hardening ✅ COMPLETE
├── D.1: P0 Security ✅ COMPLETE
│   ├── D.1.1: Rate limiting middleware ✅
│   ├── D.1.2: Security headers middleware ✅
│   └── D.1.3: Login protection middleware ✅
└── D.2: P1 Security ✅ COMPLETE
    ├── D.2.1: Audit logging ✅
    ├── D.2.2: Input validation hardening ✅
    └── D.2.3: Error response hardening ✅

Track E: Integration Testing

Track E: Integration Testing
├── E.1: E2E Flow Testing
│   ├── E.1.1: Signup → payment → activation flow
│   ├── E.1.2: License validation cross-platform
│   ├── E.1.3: Webhook reliability (100 events)
│   ├── E.1.4: Offline mode (72-hour grace)
│   └── E.1.5: Activation limit (max seats)
├── E.2: Security Testing
│   ├── E.2.1: Rate limiting verification
│   ├── E.2.2: Login lockout test
│   ├── E.2.3: Security headers verification
│   ├── E.2.4: Audit log verification
│   └── E.2.5: Input validation boundary testing
└── E.3: Platform Testing
    ├── E.3.1: macOS Intel
    ├── E.3.2: macOS ARM (Apple Silicon)
    ├── E.3.3: Linux x64
    ├── E.3.4: Windows x64
    └── E.3.5: npm install verification

Track F: Documentation

Track F: Documentation
├── F.1: API Documentation
├── F.2: User Guides
├── F.3: Developer Guides
└── F.4: Architecture Documentation

Track G: DMS Integration

Track G: DMS Integration
├── G.1: SSO from coditect.ai
├── G.2: GitHub OAuth integration
└── G.3: Frontend GUI

---

5. Document Structure Standards

5.1 PROJECT-PLAN.md Structure

# Project Plan

## Executive Summary
| Track | Progress | Status |
|-------|----------|--------|
| Track A: Backend | 95% | Active |
| Track B: Frontend | 80% | Active |
...

## Track A: Backend API
### A.1: Heartbeat System
### A.2: Admin Endpoints
...

## Track B: Frontend UI
### B.1: Core Setup
...

5.2 PILOT-PARALLEL-EXECUTION-PLAN.md Structure (SSOT)

Note: As of January 2026, TASKLIST.md is deprecated. All task tracking uses the PILOT plan as Single Source of Truth (SSOT). See CODITECT-STANDARD-AUTOMATION.md Principle #11.

# PILOT-PARALLEL-EXECUTION-PLAN.md

## Track A: Backend API

### A.1: Heartbeat System

**Tasks:**
- [ ] A.1.1: Background heartbeat thread implementation
  - **Agent:** `Task(subagent_type="senior-architect", prompt="Implement A.1.1...")`
- [ ] A.1.2: Automatic reconnection logic
  - **Agent:** `Task(subagent_type="senior-architect", prompt="Implement A.1.2...")`
- [x] A.1.3: Network failure graceful degradation ✅
  - **Completed:** 2026-01-03

### A.2: Admin Endpoints
- [ ] A.2.1: GET /api/v1/admin/users endpoint
  - **Agent:** `/agent codi-documentation-writer "Create API endpoint..."`
...

Key Differences from deprecated TASKLIST.md:

1. Agent invocations included directly in task items
2. Completion dates recorded inline
3. Dependencies documented per-section
4. Estimated hours per track

5.3 Session Log Entries

#### 2026-01-01T19:00:00Z - Track D.2.3 Error Response Hardening COMPLETE

- **Track:** D.2.3 (P1 Security - Error Response Hardening)
- **Changes:** Production-safe error handling
- **Files Modified:**
  - `backend/core/exceptions.py`
  - `backend/users/serializers.py`
- **Status:** Track D.2 COMPLETE (100%)

5.4 Agent Invocations

# Standard format for agent invocation
Task(
    subagent_type="security-specialist",
    prompt="Implement Track D.2.3: Error response hardening - no stack traces in production, generic auth messages"
)

# Reference format in prompts
"Complete Track A.1.1 (Heartbeat: Background thread implementation)"
"Review Track B.3 (Commerce UI) for design system compliance"

---

6. Communication Protocols

6.1 Progress Reporting

Standard Format:

Track <ID>: <Name> - <STATUS>
Progress: <PERCENTAGE>%
Blocking: <YES/NO>

Example:

Track D.2: P1 Security - COMPLETE
Progress: 100%
Blocking: No

6.2 Status Indicators

Indicator	Meaning
[ ]	Not started
[~]	In progress
[x]	Complete
✅	Complete (visual)
⚡	Active/Current focus
⏸️	Paused/Blocked
🚫	Blocked

6.3 Inter-Agent Communication

When agents communicate about tasks:

# Referencing a task
"Completing Track A.1.1"
"Track D.2 is blocking Track E.1"
"Handoff: Track B.3 ready for Track E.1 testing"

# Status updates
"Track A.3 COMPLETE - ready for Track E integration"
"Track C.1 blocked by Track A (backend not deployed)"

---

7. Dependency Declaration

7.1 Dependency Format

**Depends On:** Track A.3, Track B.2
**Blocks:** Track E.1, Track E.2
**No Collision With:** Track F, Track G

7.2 Dependency Matrix

Track	Depends On	Blocks
Track A	None	Track C.1, Track E
Track B	None	Track C.2, Track E
Track C	Track A, Track B	Track E
Track D	None	Track E.2
Track E	Track A, B, C, D	None
Track F	None	None
Track G	Track A	None

---

8. Migration Guide

8.1 From Legacy Nomenclature

Legacy	New
Phase 0: Foundation	Track A-F (foundation tasks)
Phase 1: Beta	Track E (testing)
P0 Critical Path	Track D.1 (P0 Security)
License Server MVP	Track A (Backend API)
Frontend MVP	Track B (Frontend UI)

8.2 Document Updates Required

1. PROJECT-PLAN.md → Strategic overview (milestones, budget, timeline)
2. PILOT-PARALLEL-EXECUTION-PLAN.md → Tactical tasks with Track IDs (SSOT)
3. TASKLIST.md → DEPRECATED (archived to archive/PHASE-0-COMPLETION-ARCHIVE.md)
4. Session logs → Use Track references
5. Agent prompts → Reference Track IDs

---

9. Compliance

9.1 Required for All Documents

• Use Track nomenclature (Track X.Y.Z format)
• Include progress percentage per track
• Declare dependencies explicitly
• Use standard status indicators
• Reference authoritative source (PILOT-PARALLEL-EXECUTION-PLAN.md)

9.2 Authoritative Source

PILOT-PARALLEL-EXECUTION-PLAN.md is the single source of truth for:

• Track definitions
• Task assignments
• Progress tracking
• Completion criteria

Location: coditect-core/internal/project/plans/PILOT-PARALLEL-EXECUTION-PLAN.md

---

10. Version History

Version	Date	Changes
1.1.0	2026-01-04	Added Section 3.4: Hierarchical Track Nomenclature System (3-tier) referencing ADR-054
1.0.0	2026-01-01	Initial standard release

---

11. Related Standards

• CODITECT-STANDARD-TRACK-NOMENCLATURE.md: Complete specification of 3-tier hierarchical track system
• ADR-054: Hierarchical Track Nomenclature with Customer Extensibility
• ADR-047: CODITECT-PLATFORM Foundation Architecture
• CODITECT CLAUDE.md Standard v1.0.0: AI agent configuration
• MoE Task Execution Skill: Agent orchestration methodology

---

Standard Owner: Hal Casteel, Founder/CEO/CTO, AZ1.AI INC Review Cycle: Quarterly Next Review: April 1, 2026