Pilot Parallel Execution Plan

CODITECT Pilot Parallel Execution Plan

Document Version: 1.9.21 Created: December 29, 2025 Updated: January 09, 2026 Status: Active Implementation Owner: Hal Casteel, Founder/CEO/CTO, AZ1.AI INC

Executive Summary

This document consolidates ALL remaining pilot tasks from 181+ TASKLIST files and 185+ PROJECT-PLAN files into a single parallel execution plan designed for multi-agent agentic execution with:

Zero collision between parallel sessions
No re-work or gaps through clear ownership boundaries
Clear dependencies mapped for sequential tasks
Parallel tracks that can run simultaneously

Current Status (Jan 09, 2026)

Component	Complete	Remaining	Blocking
License Server Backend	98%	2%	No
Data Models	100%	0%	No
Reference Data (ISO)	100%	0%	No
Commerce API	100%	0%	No
Cloud Context Sync (A.9) ✅	100%	0%	No
Container Session Lifecycle (A.10) ✅	100%	0%	No
Cloud Workstation Broker (A.11) ✅	100%	0%	No ✅
Team & License Management (A.12) ✅	100%	0%	No ✅
Frontend UI	85%	15%	No
Design System	98%	2%	No
Commerce UI	90%	10%	No
Container Session UI (B.4.5)	75% (MVP)	25% (MVP)	No
Security Hardening	100%	0%	No
Two-Factor Auth (2FA)	100%	0%	No
Integration Testing	100%	0%	No ✅
Production Deployment	85%	15%	No
Licensed Docker Registry (C.5)	100%	0%	No ✅
Licensed Container Build (C.6)	100%	0%	No
Documentation	85%	15%	No
Track Nomenclature (F.4)	100%	0%	No
docs.coditect.ai Content (F.8)	0%	100%	No
Framework Autonomy (H)	100%	0%	No ✅
UI Components (I)	0%	100%	No
Memory Intelligence (J)	55%	45%	No
Workflow Automation (K)	0%	100%	No
Extended Testing (L)	0%	100%	No
Extended Security (M)	0%	100%	No
GTM & Launch (N)	15%	85%	No

🚨 Critical Path (Jan 6 Assessment - Updated)

C.5 Docker Registry → A.10 Container Sessions → A.12 Team Mgmt → A.11 Workstation Broker → Launch
     (100% ✅)              (100% ✅)               (75% ✅)              (100% ✅)

Why These Block Launch:

C.5 (Docker Registry): Users cannot pull licensed container images ✅ COMPLETE (Jan 5, 2026)
A.10 (Container Sessions): Container lifecycle API for license enforcement ✅ COMPLETE (Jan 6, 2026)
A.12 (Team Management): Invitation + License Assignment APIs + Frontend + Testing ✅ COMPLETE (Jan 9, 2026)
- A.12.1-A.12.3 (Backend + UI) complete Jan 7
- A.12.4 (Testing) complete Jan 9 - 3 test files: test_invitation_api.py, test_license_assignment_api.py, test_invitation_license_flow.py
A.11 (Workstation Broker): Complete workstation provisioning system ✅ COMPLETE (Jan 7, 2026)
- All subtasks complete: Infrastructure, Django app, API endpoints, auto-provision, testing, frontend UI

User Journey (Fully Unblocked):

User → Buys License → ✅ License → ✅ Workstation Auto-Provisioned → ✅ Welcome Email → ✅ Launch IDE

User Journey (Complete Flow):

User → Buys License → ✅ License → ✅ Workstation Provisioned → ✅ Team Invited → ✅ Working

Progress Update (Jan 09): F.8 docs.coditect.ai Content Development ADDED. Created comprehensive 3-phase documentation plan based on Diátaxis framework. Recursive search discovered 3,458 documentable components: 776 agents, 445 skills, 377 commands, 581 scripts, 118 hooks, 1,153 workflows, 52 standards, 58+ ADRs. Phase 1 (Auto-Transform, P0): 8-12h - script-based conversion of existing component markdown to Docusaurus. Phase 2 (Enhancement, P1): 40-60h - add examples, cross-references, use cases. Phase 3 (Full Content, P2): 120-160h - tutorials, how-to guides, explanations. Total: 176-244 hours. Inventory saved to docs-site/coditect-documentation-inventory.md.

Progress Update (Jan 09): H.4.3 Agent Field Routing COMPLETE. Added agent field to 12 skills for specialized agent routing (Claude Code 2.1.0 feature). Mappings: codebase-analysis-patterns→codebase-analyzer, pattern-finding→codebase-pattern-finder, security-scanning-patterns→security-scanning, naming-enforcement→naming-convention-enforcer, moe-content-classification→moe-content-classifier, codebase-navigation→codebase-locator, documentation-quality→documentation-quality-agent, code-review-patterns→orchestrator-code-review, component-improvement→component-enhancer, submodule-validation→submodule-orchestrator, project-organization-patterns→project-organizer, architect-review-methodology→architect-review. Track H now 100% complete (65/65 tasks).

Progress Update (Jan 09): H.4 Skills Optimization (Claude Code 2.1.0) 100% COMPLETE. Analyzed Claude Code 2.1.0 release for new context: fork frontmatter capability. Updated 13 skills with context: fork and allowed-tools in frontmatter. Tier 1 (6 skills): codebase-analysis-patterns, pattern-finding, security-scanning-patterns, naming-enforcement, moe-content-classification, codebase-navigation. Tier 2 (7 skills): documentation-quality, code-review-patterns, component-improvement, submodule-validation, explain, project-organization-patterns, architect-review-methodology. All versions bumped to 1.1.0/3.1.0.

Progress Update (Jan 09): CP-5 (@coditect/ui package) COMPLETE. Created shared UI component library in coditect-cloud-frontend/packages/ui/ with: 7 components (Button, Input/Textarea, Card with 5 sub-components, Modal with 6 sub-components + ConfirmModal, Badge/DotBadge, Spinner/LoadingOverlay/LoadingPlaceholder, Tabs/TabsList/TabsTrigger/TabsContent), Tailwind preset (tailwind.preset.js), Vite library mode build config, TypeScript types, cn() utility. Build output: ES module + CommonJS + sourcemaps. Package ready for npm publish. Remaining Phase 1: CP-6 (docs content), CP-9 (CDN optional), CP-10 (Security testing).

Progress Update (Jan 09): PHASE 1 CRITICAL PATH CLEANUP. Verified and marked complete: CP-2 (A.4.9-A.4.12 Context Sync - CustomTokenObtainPairSerializer already exists in coditect-cloud-infra with tenant_id JWT claims), CP-7 (F.3.1 Support email monitoring - pilot-adequate with aliases to 1@az1.ai), CP-8 (A.12.4 Team Management Testing - 3 test files already exist: test_invitation_api.py, test_license_assignment_api.py, test_invitation_license_flow.py). Remaining Phase 1: CP-5 (@coditect/ui package), CP-6 (docs content), CP-9 (CDN optional), CP-10 (Security testing).

Progress Update (Jan 09): A.13.5 (Audit & Security) COMPLETE. Created AdminAuditLogListView in api/v1/views/admin.py for GET /api/v1/admin/audit-log/ endpoint. Features: filtering by action, resource_type, user_email, organization_id, from_date, to_date; pagination; admin-only access. AuditLog model and logging already existed. Track A.13 now 100% complete. CP-11B marked DONE.

Progress Update (Jan 09): CRITICAL PATH ANALYSIS COMPLETE. Added "Critical Path Execution Order (January 9, 2026)" section with [CP-#] identifiers for all remaining tasks. BLOCKER RESOLVED: C.4.3.0 Email Infrastructure simplified to aliases forwarding to 1@az1.ai (no dedicated Google Workspace needed). Remaining: 9 Phase 1 tasks (parallel), 10 Phase 2 tasks (docs/quality), 10 Phase 3 tasks (launch prep), 15 DMS Product tasks (parallel track), 10 Extended tracks (post-launch). Total remaining: 564-742 hours raw, 200-256 hours wall-clock with max parallelization. ✅ NO BLOCKERS - Ready for parallel execution.

Progress Update (Jan 08): H.2.5 (Retry Engine with Exponential Backoff) COMPLETE. Created scripts/core/retry_engine.py (~1,160 lines) with RetryEngine, RetryPolicy, RetryConfig, RetryWithCircuitBreaker, and @retry decorator. Backoff strategies: Exponential, Linear, Fixed, Fibonacci, Decorrelated (AWS-style). Jitter types: None, Full, Equal, Decorrelated (thundering herd prevention). Features: sync/async execution, metrics tracking, predefined configs (aggressive/standard/conservative/quick/database/api), CircuitBreaker integration. Tests: 110 tests in test_retry_engine.py - all passing. Track H now at 94% complete (H.2.1-H.2.6 done, H.2.7-H.2.8 remaining).

Progress Update (Jan 08): H.2.4 (Circuit Breaker Pattern) COMPLETE. Created scripts/core/circuit_breaker.py (~975 lines) with CircuitBreaker state machine (CLOSED → OPEN → HALF_OPEN), CircuitBreakerRegistry for managing multiple breakers, AgentCircuitBreaker with fallback routing integration, @circuit_breaker decorator, and CircuitBreakerHealthCheck. Features: configurable failure thresholds and recovery timeouts, sliding window failure counting, exception filtering (include/exclude), state change callbacks, metrics collection, thread-safe operations. Tests: 60 tests in test_circuit_breaker.py - all passing. Track H now at 90% complete.

Progress Update (Jan 08): H.2.3 (Priority Queue Routing) COMPLETE. Created scripts/core/priority_queue_router.py (950 lines) with PriorityQueueRouter, LocalPriorityQueueRouter classes. Features: 4 named queues (critical/high/normal/background), configurable routing rules with lambda/expression conditions, 4 dequeue strategies (strict priority, weighted, round-robin, fair-share), priority boosting for aging tasks (linear/exponential/stepped policies). Tests: 47 tests in test_priority_queue_router.py - all passing. Track H now at 88% complete.

Progress Update (Jan 08): Track H.3 (MoE Verification Layer) ADDED with 42 tasks (~180h). Based on MOE-JUDGES-RESEARCH and CLAUDE-CODE-EVAL-LOOPS analysis: (1) H.3.1 Judge Persona Specifications (CREATE 8 tasks); (2) H.3.2 ADR-to-Rubric Generator (CREATE 6 tasks); (3) H.3.3 Consensus Enhancement - Debate Protocol (UPDATE 6 tasks); (4) H.3.4 Provenance Enhancement (UPDATE 6 tasks); (5) H.3.5 Multi-Model Judge Panel (UPDATE 6 tasks); (6) H.3.6 Self-Improving Eval Loop (CREATE 7 tasks); (7) H.3.7 ADR & Documentation (CREATE 2 tasks). Component matrix: CREATE 4 new components (judge-personas.json, adr-rubric-generator.py, skills/self-improving-eval/, ADR-060), UPDATE 4 existing (consensus.py, models.py, moe-judges.md, evaluation-framework/SKILL.md), EXTEND 2 (calibration.py, evaluation_rubrics.md). Track H now has 58 total tasks.

Progress Update (Jan 08): C.4.1.5 (Docs Links Verification) COMPLETE. Tested all 11 docs.coditect.ai links in Docs.tsx - all return HTTP 200. Links verified: root URL, 4 quick links (getting-started, agents, workflows, api), and 6 popular topics (first-project, concepts/agents, session-continuity, troubleshooting, best-practices, faq).

Progress Update (Jan 08): B.4.6 (Subscription Status & Billing Portal) COMPLETE. Backend: Created BillingPortalView (POST /subscriptions/billing-portal/) and create_billing_portal_session method in StripeService. Frontend: Created SubscriptionStatus component (~280 lines) displaying current plan, subscription status badges, seat usage, billing period dates, renewal/cancellation warnings, Stripe portal link. Integrated into Dashboard sidebar. Updated subscription.service.ts with getCurrentSubscription and getBillingPortalUrl methods, added CurrentSubscription type. Commits: backend 9431ca2, frontend 5aa1d95.

Progress Update (Jan 08): C.4.4.3 (GitHub Discussions Setup) COMPLETE. Enabled GitHub Discussions on coditect-ai/coditect-core via gh api PATCH request. Default categories configured: Announcements, General, Ideas, Polls, Q&A (answerable), Show and tell. Note: Repo remains private - Discussions work on private repos for organization members.

Progress Update (Jan 08): Track E (Integration Testing) 100% COMPLETE. E.3 (Platform Testing) implemented: Created comprehensive cross-platform test framework in coditect-cloud-backend/tests/platform/ with ~1,170 lines across 4 files. conftest.py includes Platform enum, PlatformInfo dataclass, platform detection, skip markers, fixtures. test_cross_platform.py tests all 4 platforms (macOS Intel/ARM, Linux x64, Windows x64) with platform-specific tests (Keychain, Registry, glibc, etc.). test_npm_install.py verifies Node.js 18+/npm 9+ prerequisites, package installation, registry connectivity, and performance. Total: 35+ tests covering E.3.1-E.3.5. Track E now joins A, C, D as 100% complete.

Progress Update (Jan 08): F.3.2 + F.3.3 COMPLETE: (1) Created GitHub issue templates in .github/ISSUE_TEMPLATE/ - bug_report.yml, feature_request.yml, support_request.yml with YAML forms, severity selection, component dropdowns; config.yml with contact links to docs, discussions, Discord, email. (2) Created internal/operations/EMERGENCY-RESPONSE-PLAYBOOK.md (~600 lines) with SEV-1 to SEV-4 definitions, incident response process (detection → mitigation → resolution), 6 runbooks (API errors, database issues, license validation, high latency, GKE issues, security incidents), communication templates, escalation matrix, post-mortem template. Track F.3 (Support Preparation) now 50% complete (2/4 tasks). Remaining: F.3.1 (email monitoring), F.3.4 (Discord setup) - require DevOps.

Progress Update (Jan 08): F.2.3 COMPLETE: Created docs/INTEGRATION-GUIDE.md (~1,270 lines). Comprehensive developer integration guide with Python (requests), JavaScript/TypeScript (fetch/axios), and cURL examples. Covers authentication flow, license session management with heartbeat patterns, error handling strategies, rate limiting, webhooks, and SDK best practices. Track F.2 (API Documentation) now 100% complete. All 3 tasks done: F.2.1 (OpenAPI decorators), F.2.2 (API Reference), F.2.3 (Integration Guide).

Progress Update (Jan 08): Tasks completed: A.1.2. Updated via auto-discovery.

Progress Update (Jan 8): Track F.2 (API Documentation) advanced to 66%. F.2.1 COMPLETE: Added @extend_schema decorators to all views, fixing 64 OpenAPI schema errors → 0 errors. Modified auth.py, subscription.py, license_delivery.py, health.py views. Fixed api/v1/serializers/user.py invalid field names (subscription_tier → plan). Generated openapi-schema-generated.yaml (OpenAPI 3.0.3, 19 endpoints). F.2.2 COMPLETE: Created docs/API-REFERENCE.md (~660 lines) covering Health, Auth, Subscription, License, Seat Management endpoints with request/response examples. Documentation track now at 85%. Remaining: F.2.3 (Integration Guide).

Progress Update (Jan 6 - Evening): Track A.11 (Cloud Workstation Broker) advanced to 90%. Completed A.11.4 (Auto-Provision Webhook): Stripe webhook extended to detect product_type == 'workstation', triggers provision_workstation_for_user.delay() Celery task, GCP provisioning via provision_workstation_in_gcp.delay(), status polling via check_workstation_status.delay(). Welcome email implemented (send_workstation_welcome_email Celery task with HTML template). Product catalog updated with 3 workstation tiers: Standard ($99/mo), Power ($199/mo), AI ($399/mo). Files: workstations/tasks.py (362 lines), commerce/tasks.py (270 lines), commerce/views.py extended, seed_products.py updated. Commits: f0c8360, 2fb3319. Remaining: A.11.1.1 (OpenTofu module), A.11.5 (E2E testing).

Progress Update (Jan 6 - Morning): Track A.11 (Cloud Workstation Broker) advanced to 80%. Discovered workstations Django app was already fully implemented: 6 models (WorkstationConfig, Workstation, SharedWorkstation, WorkstationUserAccess, WorkstationSession, WorkstationUsageRecord), WorkstationBrokerService with GCP API integration (495 lines), 15 API views (643 lines), all URLs registered. Applied migrations. Updated admin.py with all models. Remaining: A.11.1 (GCP infrastructure deployment), A.11.4 (auto-provision webhook), A.11.5 (testing). Critical path updated: C.5 ✅ → A.11 (80%) → A.12 (0%).

Progress Update (Jan 5 - Night): HOLISTIC REBALANCING COMPLETE. Critical path assessment identified 3 major gaps blocking Cloud Workstation launch: (1) A.11 Cloud Workstation Broker (ADR-005, 0% implemented); (2) A.12 Team & License Management (invitations, assignments); (3) C.5 Docker Registry (URGENT - P0). B.4.5 Container Session UI rebalanced: MVP reduced from 28 to 8 components (6 done, 2 remaining), 20 components deferred to v1.1. New tracks A.11 (~20 tasks) and A.12 (~17 tasks) added. C.5 upgraded from P1 to P0 URGENT.

Progress Update (Jan 5 - Evening): Track B.4.5 (Container Session UI) architecture complete. Created ADR-056-container-session-ui-architecture.md defining 28-component dashboard. 5 components COMPLETE: TypeScript interfaces (containerSession.ts), API service (containerSession.service.ts), ContainerSessionList, ContainerSessionCard, UserSessionManager, useContainerSessions hook. UI Requirements spec created. PILOT plan updated with full B.4.5.1-B.4.5.30 + F.5.1-F.5.2 task inventory.

Progress Update (Jan 5): Track C.6 (Licensed Container Image Build) 100% COMPLETE. C.6.6.3 Docker Content Trust implemented: Cloud KMS keyring + signing key (EC_SIGN_P384_SHA384, HSM), Cosign v2.2.2 in GitHub Actions, customer signature verification docs, 10 new tests (93 total). ADR-055 fully implemented. Commit: f26cdcb2. 28 granular sub-tasks added to PILOT plan for C.6.6.3 (proper nomenclature per ADR-054).

Progress Update (Jan 4 - Night 3): Gap analysis complete. 4 gaps identified and fixed: (1) D.1.4 added for session endpoint rate limiting; (2) A.10.4.3 added for license expiration → container session termination webhook; (3) A.10.1.6 added for max_containers field on License model; (4) B.4.4-B.4.5 split for device vs container session management UI. Multi-user container model added to A.10 architecture (ContainerSession + ContainerUserSession). Total new tasks from gap fixes: 6.

Progress Update (Jan 4 - Night 2): Track C.6 (Licensed Container Image Build) and Track A.10 (Container Session Lifecycle API) ADDED per ADR-055. C.6: 28 tasks for shared base image, Docker-specific, Workstation-specific builds with root-owned framework protection. A.10: 18 tasks for Django sessions app with /sessions/validate, /sessions/heartbeat, /sessions/release endpoints. Total new tasks: 46. Container deployment infrastructure now fully planned. Dependency chain: A.3 (complete) → A.10 (sessions API) → C.5 (registry) → C.6 (images).

Progress Update (Jan 4 - Night): V2-tasklist-with-checkboxes.md MERGED into PILOT plan. Added Tracks H-N (7 new tracks, ~94 tasks) from V2 epics E001-E010. E006 (Deployment), E007 (Documentation), E009 (Analytics) marked complete as reference. V2-TASKLIST archived to archive/v2-reference/. SSOT consolidation complete - single authoritative task document.

Progress Update (Jan 4 - Evening): Track A.9 (Cloud Context Task Sync) 25% complete. A.9.1.1 and A.9.1.2 DONE: Created TaskTracking and TaskMessage Django models in coditect-cloud-infra/backend/context/models.py (~250 lines). Schema now aligned between local SQLite and Django PostgreSQL. Track F.4 (Track Nomenclature Standard) 100% COMPLETE: ADR-054, CODITECT-STANDARD-TRACK-NOMENCLATURE.md, tracks.template.json all created. CLAUDE.md updated with Section 4 (Track Nomenclature) and Section 12 (Task Tracking). Critical path identified: A.9.1.3 (migrations) → A.9.2 (API endpoints) → A.9.3 (integration) → C.5 (Docker) → Cloud Workstations.

Progress Update (Jan 2 - Evening): Track C (DevOps) verified at 80%. Domain verification confirmed (coditect.ai, az1.ai). All endpoints working: docs.coditect.ai (Cloud Run), auth.coditect.ai (GKE), api.coditect.ai/health/ (GKE). SSL certificates Active. GKE pods healthy (10 backend, 2 frontend, 1 celery). Orphan coditect-frontend Cloud Run service identified (not needed - frontend runs on GKE). Only C.5 (Licensed Docker Registry) remaining. Production Deployment NO LONGER BLOCKING.

Progress Update (Jan 2 - Afternoon): Track D.3 (2FA Authentication) COMPLETE (100%). Implemented TOTP-based two-factor authentication with pyotp. Backend: CustomTokenObtainPairSerializer returns temp_token when 2FA enabled, TwoFactorLoginVerifyView for code verification, 10 API endpoints for 2FA management. Frontend: Login.tsx 2FA challenge form with Shield/Smartphone icons, 6-digit code input. Created ADR-016-two-factor-authentication.md documenting architecture, security considerations, and migration path. Deployed v1.16.0-2fa-login to GKE. Frontend UI now at 85%.

Progress Update (Jan 1 - Night 3): Track E.1 COMPLETE (100%). Created 5 E2E test files totaling ~2,200 lines and 70 tests: (1) test_signup_activation_flow.py for signup → payment → activation; (2) test_cross_platform_validation.py for cross-platform license validation; (3) test_webhook_reliability.py for 100-event webhook reliability; (4) test_offline_mode.py for 72-hour grace period; (5) test_activation_limits.py for max seat enforcement. Integration Testing now at 80%.

Progress Update (Jan 1 - Night 2): Track D.2 COMPLETE (100%). D.2.2 Input Validation: Created core/serializers.py with InputLimits class (RFC 5321 email, bcrypt DoS password limits), StrictSerializerMixin (rejects unknown fields), validated field types (ValidatedEmailField, ValidatedPasswordField, ValidatedLicenseKeyField). Updated users/serializers.py and licenses/serializers.py with strict mode. D.2.3 Error Response Hardening: Enhanced core/exceptions.py with ErrorCodes, GenericMessages (prevent enumeration), secure exception handler (no stack traces in production, generic auth errors). Updated CustomTokenObtainPairSerializer to use generic error messages for all auth failures. Security Hardening COMPLETE.

Progress Update (Jan 1 - Night): Track D.2.1 Audit Logging COMPLETE. Created comprehensive audit logging system in backend/core/: AuditLog model with 40+ action types (AuditLogAction enum), 5 severity levels (AuditLogLevel enum), immutable design (save/delete overrides), request context tracking (IP, user agent, method, path), multi-tenant support (tenant_id). Created AuditLogMiddleware with configurable paths, action detection, duration tracking. Created read-only AuditLogAdmin with colored badges, CSV export, comprehensive filtering. Security Hardening now at 75%.

Progress Update (Jan 1 - Evening): Reference Data app COMPLETE. Created backend/reference_data/ with ISO standard models: Country (ISO 3166-1), State (ISO 3166-2), City, PostalCode, Currency (ISO 4217), PhoneCountryCode (ITU-T E.164), Timezone (IANA). Updated Organization and LegalEntity models with FK references for autopopulated contact management. Added seed_reference_data management command with 50+ countries, 67 states, 30 currencies, 30 phone codes, 29 timezones.

Progress Update (Jan 1 - Afternoon): Track D.1 (P0 Security) COMPLETE. Created core/middleware/ with rate_limit.py, security_headers.py, login_protection.py. Security Hardening now at 50%. Entity hierarchy models (ADR-047) implemented with Platform, Organization, LegalEntity, OperatingUnit.

Progress Update (Jan 1 - Morning): Added agent invocations to Track C.1-C.4.1 (DevOps & Deployment). All tracks now have complete agent invocations for MoE Task Execution workflow.

Progress Update (Dec 31 - Night): Backend Commerce API (Track A.3) COMPLETE. Added StripeWebhookView with 5 event handlers (checkout.session.completed/expired, subscription updates, payment failures), entitlement revocation endpoint, HMAC-SHA256 signature verification, and 25 unit tests. All 22 A.3 tasks complete. License Server Backend now at 95%.

Progress Update (Dec 31): Frontend UI advanced to 80% - Commerce UI (B.3.1-B.3.3) COMPLETE including ProductCatalog, ShoppingCart, GooglePayButton, StripeCheckout, and dedicated Checkout page. Only entitlement display (B.3.4.2-4) and @coditect/ui package (B.12.3) remaining.

New Addition (Dec 29): Multi-product commerce system with shopping cart, Google Pay + Stripe checkout, and entitlement provisioning added to Tracks A and B. See ADR-014 and COMMERCE-CHECKOUT-WORKFLOWS.md.

New Addition (Dec 29 - Evening): Track G (DMS Integration) added for CODITECT Document Management System product launch. Includes SSO from coditect.ai, GitHub OAuth for document intake, and full frontend GUI. DMS backend already deployed at https://dms.coditect.ai (Track C complete).

New Addition (Dec 29 - Late): Comprehensive checkout process documentation created. See CHECKOUT-PROCESS-DETAILED.md for complete end-to-end flow integrating 14 commerce workflows, 6 billing narratives (WF-001 through WF-025), API endpoints, sequence diagrams, and error handling.

New Addition (Dec 29 - Evening): Track A.4 (Context Sync API) implemented. Unified Django API with JWT authentication for context sync, workstations (ADR-005), and repositories (ADR-006). MoE consensus selected Custom REST Sync architecture over PowerSync, Litestream, and Electric SQL alternatives.

New Addition (Dec 30): Complete data model implementation per TDD Sections 6.1.1-6.1.10. Created 4 new Django apps: organizations/ (Team, Membership, TeamMembership, Project), commerce/ (Product, Cart, Order, Entitlement), subscriptions/ (Subscription, Invoice, UsageMetric), permissions/ (Permission with RBAC). All migrations generated. 24 models total across 11 apps. 95% data model complete.

New Addition (Dec 30 - Late): Track A.5 (Team/Project Context Sync) added per ADR-045. Extends ADR-044 device-level sync to support team-level context sharing, project-level isolation, and hierarchical backup to GCS. Includes user/tenant/team/project backup hierarchy with RBAC permission model.

New Addition (Dec 30 - Evening): Website content architecture complete. ADR-015 defines 32 total links across auth.coditect.ai (22 exist, 10 missing). Track B expanded with B.6 (Dark Mode - COMPLETE), B.7 (Legal/Account P0), B.8 (Product/Company P1), B.9 (Changelog P2), B.10 (Careers P3). Total 26 hours website content work. See WEBSITE-CONTENT-tasklist.md.

New Addition (Dec 30 - Late Night): Frontend website pages implementation complete. Created 6 reusable page templates (PageHeader, StaticPageLayout, LegalPageLayout, ProductLandingLayout, CompanyPageLayout, FormPageLayout). Implemented 7 new pages: Privacy.tsx, Terms.tsx, ForgotPassword.tsx, About.tsx, Security.tsx, Docs.tsx, Changelog.tsx. Deployed v1.5.0-website-pages to GKE. Track B.7, B.8, B.9 now COMPLETE. ADR-015 updated with customer content flows.

New Addition (Dec 31 - Morning): External sites and infrastructure inventory complete. Added Track C.4 with 17 tasks covering: docs.coditect.ai deployment (5 tasks), workflow.coditect.ai deployment (4 tasks), email infrastructure verification (6 tasks), and GitHub/external services (3 tasks). Created EXTERNAL-LINKS-INVENTORY.md documenting all 5 CODITECT sites, 6 email addresses, 10 documentation paths, and 16 internal routes. ADR-015 v1.1.0 updated with customer flow diagrams and external site mapping.

New Addition (Dec 31 - Afternoon): Website-builder framework components complete. Created 7 new components: website-builder agent, website-builder skill (SKILL.md + automation), 3 commands (/build-website, /deploy-site, /site-health), website-scaffold script, 3 workflows (rapid-site-deployment, content-migration, multi-site-management). docs.coditect.ai scaffolded at /docs-site/. All components registered and activated.

New Addition (Dec 31 - Evening): Design system compliance audit complete. Frontend (coditect-cloud-frontend) audited against ui-design-system.md and ADR-002. 93% compliant overall: Colors 100%, Dark Mode 100%, Layout 100%, Typography 90% (Inter vs system fonts), Components 90% (rounded-lg vs rounded-md, missing focus-offset-2), Icons 80% (inline SVGs vs Lucide). Added Track B.12 for design system fixes and @coditect/ui package creation.

New Addition (Dec 31 - Night): Commerce UI implementation complete (Track B.3.1-B.3.3). Created StripeCheckout.tsx component with Stripe Elements integration, dedicated Checkout.tsx page with order summary and dual payment options (Google Pay + Stripe). Fixed ShoppingCart.tsx Google Pay success handler. All commerce UI components now functional: ProductCatalog, ProductCard, ShoppingCart, CartItem, CartSummary, GooglePayButton, StripeCheckout, CheckoutSuccess. Design system updated to 98% compliant (B.12.1-B.12.2 complete). Frontend UI now at 80%.

New Addition (Jan 1 - Afternoon): ADR-047 (CODITECT-PLATFORM Foundation Architecture Discovery) COMPLETE. 46-question discovery interview across 10 domains captured full enterprise vision: 6-level entity hierarchy, full PBAC, hybrid multi-tenant isolation, multi-currency billing, ASC 606 revenue recognition, 6 compliance frameworks, white-label support, Stripe-style API versioning, and active-active DR. See Roadmap Alignment section below.

ADR-047 Roadmap Alignment

Reference: coditect-core/internal/architecture/adrs/ADR-047-coditect-platform-foundation.md

Principle: Not every feature is required for Pilot launch, but every implemented feature MUST build toward the full CODITECT-PLATFORM vision captured in ADR-047.

Vision Summary (ADR-047)

Domain	Full Vision	MVP Scope
Organization Types	Individual → White-Label Partner (7 levels)	Individual, Team, Company
Entity Hierarchy	Platform → Org → LegalEntity → OpUnit → Dept → Team → User	Tenant → User (current)
RBAC	Full PBAC with rules engine	Role-based (owner, admin, member, viewer)
Multi-Tenant	Hybrid isolation (shared → dedicated)	Shared database, tenant_id isolation
Billing	Multi-currency + FX + Usage-based + Services	Single currency (USD), Stripe subscriptions
Accounting	Multi-book, multi-segment COA, ASC 606	N/A (post-pilot)
Compliance	SOC 2 + GDPR + HIPAA + PCI DSS + ISO 27001 + FedRAMP	SOC 2 Type I (in progress)
White-Label	Full customization, hybrid revenue model	N/A (post-pilot)
API Versioning	Stripe-style dated (/api/2026-01-01/)	/api/v1/ (upgrade path ready)
Disaster Recovery	Active-active multi-region	Daily backups, single region

MVP → Full Vision Migration Path

Each Pilot implementation is designed for seamless upgrade:

Current Implementation	Built-For Upgrade Path	ADR-047 Target
`Tenant` model	Add `Organization`, `LegalEntity`, `OperatingUnit` as parents	6-level hierarchy
`TenantMembership.role` (CharField)	Add `Permission` model + `PolicyRule` engine	Full PBAC
Single `tenant_id` isolation	Add schema-per-tenant option for enterprise tier	Hybrid isolation
USD-only Stripe billing	Add `currency` field, FX service, multi-book ledger	Multi-currency
Basic RBAC (4 roles)	Expand roles, add scope constraints, inheritance	Granular permissions
`/api/v1/` endpoints	Add date-based routing, version negotiation	Stripe-style versioning

Track → ADR-047 Domain Mapping

Track	Primary ADR-047 Domain	Secondary Domains
A: Backend	Multi-Tenant (3), Billing (4)	RBAC (2), Integration (8)
B: Frontend	User Management (2)	Reporting (9), Operations (10)
C: DevOps	Operations (10), Compliance (6)	Disaster Recovery (10.5)
D: Security	Compliance (6), RBAC (2)	Data Isolation (6)
E: Testing	All domains (quality gate)	-
F: Documentation	All domains (customer-facing)	-
G: DMS	Integration (8), Multi-Tenant (3)	-

Future Tracks (Post-Pilot)

Track	ADR-047 Domain	Target Quarter
H: Accounting Foundation	Accounting (5)	Q1 2026
I: Multi-Currency	Billing (4), Accounting (5)	Q1 2026
J: Entity Hierarchy Upgrade	Organization (1)	Q2 2026
K: White-Label Platform	White-Label (7)	Q2 2026
L: Advanced RBAC (PBAC)	User Management (2)	Q2 2026
M: Multi-Region DR	Operations (10)	Q3 2026
N: Gateway API Migration	Operations (10)	~~Q1 2026 (URGENT)~~ DEFERRED

Track N: Gateway API Migration - ✅ NOT REQUIRED (Jan 7, 2026 Audit)

Original Alert: Kubernetes community announced retirement of ingress-nginx controller (EOL March 2026)

Reference: https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/

Audit Result (Jan 7, 2026): ✅ CODITECT production does NOT use ingress-nginx

Finding	Details
Live Ingress Resources	2 resources, both using `gce` class
ingress-nginx controller	NOT deployed in cluster
Production domains	api.coditect.ai, auth.coditect.ai - all GCE
Impact	NONE - Production unaffected by ingress-nginx EOL

GKE Live State (verified):

NAMESPACE      NAME                    CLASS   HOSTS
coditect-dev   coditect-api-ingress    gce     api.coditect.ai
coditect-dev   coditect-auth-ingress   gce     auth.coditect.ai

Files with nginx references (NOT production):

Archive/legacy files (coditect-v4-archive/)
Documentation examples
coditect-cloud-backend/k8s/ingress.yaml - targets api.coditect.com (different domain, not deployed)

Tasks:

N.1: Audit current GKE ingress-nginx usage ✅ (Jan 7, 2026)
- N.1.1: Inventory all Ingress resources in GKE clusters ✅
- N.1.2: Document annotations and custom configs ✅
- N.1.3: Identify dependencies on ingress-nginx specific features ✅ NONE
N.2-N.4: DEFERRED - Production uses GCE Ingress, not affected by ingress-nginx EOL

Important Distinction:

Component	Type	Status	Affected by EOL?
`ingress-nginx`	Kubernetes Ingress Controller	NOT USED	N/A (we use GCE)
`nginx:1.25-alpine`	Container reverse proxy	USED in `coditect-cloud-frontend`	❌ NO - standard nginx, actively maintained
`nginx` apt package	Container reverse proxy	USED in `coditect-cloud-ide`	❌ NO - standard nginx, actively maintained

The nginx used inside containers for SPA routing (FROM nginx:1.25-alpine) is the standard NGINX Open Source web server, which is actively maintained by F5/NGINX Inc. This is completely separate from the ingress-nginx Kubernetes controller being retired.

Conclusion: Track N work is optional future cleanup of legacy/archive files. Not blocking for pilot launch

Frontend Repository Mapping

Product	Repository	Framework	Status
coditect.ai IDE	`submodules/cloud/coditect-cloud-ide/`	React 18 + Chakra UI + Theia	Production
Auth/License Portal	`submodules/cloud/coditect-cloud-frontend/`	React + Vite + Tailwind	In Progress
DMS	`submodules/ops/coditect-document-management/src/frontend/`	React + Vite + Tailwind	NEW

coditect.ai API Endpoints (Discovered)

/health                → {"status":"healthy","service":"coditect-combined-v5"}
/api/v5/*              → Main API (JWT auth required)
/api/auth/login        → Login
/api/auth/register     → Register
/api/auth/refresh      → Token refresh
/api/files/*           → File operations
/api/profile/*         → User profile
/api/v1/support/ticket → Support tickets

DMS API Endpoints (Live at dms.coditect.ai)

/health/live           → {"status":"alive"}
/api/v1/documents/*    → Document CRUD
/api/v1/search/*       → Semantic/hybrid/GraphRAG search
/api/v1/analytics/*    → Dashboard metrics
/api/v1/tenants/*      → Multi-tenant management

Architecture: Parallel Session Tracks

                    ┌─────────────────────────────────────────────────────┐
                    │            PARALLEL EXECUTION TRACKS                │
                    └─────────────────────────────────────────────────────┘
                                            │
        ┌───────────────────────────────────┼───────────────────────────────────┐
        │                                   │                                   │
        ▼                                   ▼                                   ▼
┌───────────────┐                 ┌───────────────┐                 ┌───────────────┐
│   TRACK A     │                 │   TRACK B     │                 │   TRACK C     │
│   Backend     │                 │   Frontend    │                 │   DevOps      │
│   Complete    │                 │   Build       │                 │   Deploy      │
└───────┬───────┘                 └───────┬───────┘                 └───────┬───────┘
        │                                   │                                   │
        ▼                                   ▼                                   ▼
┌───────────────┐                 ┌───────────────┐                 ┌───────────────┐
│   TRACK D     │                 │   TRACK E     │                 │   TRACK F     │
│   Security    │                 │   Testing     │                 │   Docs        │
│   Hardening   │                 │   E2E         │                 │   Support     │
└───────────────┘                 └───────────────┘                 └───────────────┘
                                            │
                                            ▼
                              ┌───────────────────────┐
                              │     INTEGRATION       │
                              │    (Sequential)       │
                              └───────────────────────┘
                                            │
                                            ▼
                              ┌───────────────────────┐
                              │      LAUNCH           │
                              └───────────────────────┘

Critical Path Execution Order (January 9, 2026)

Assessment Date: January 9, 2026 Goal: Optimal task execution order for Cloud Workstation Launch and Platform Readiness Method: Dependency analysis + blocker identification + parallelization opportunities

✅ BLOCKERS (Resolved)

CP-ID	Task ID	Description	Status	Resolution
~~[CP-0]~~	C.4.3.0	Configure email infrastructure for coditect.ai	✅ RESOLVED	Email aliases to 1@az1.ai

Resolution (Jan 9, 2026): All coditect.ai email addresses (support@, hello@, security@, etc.) configured as aliases forwarding to 1@az1.ai. No dedicated Google Workspace needed for pilot.

Phase 1: Critical Infrastructure [CP-1 to CP-13]

Can execute in parallel - no inter-dependencies

CP-ID	Task ID	Description	Track	Agent	Est. Hours
~~[CP-1]~~	~~C.4.3.0.1-0.7~~	~~Email infrastructure~~	C	-	✅ DONE (aliases)
~~[CP-1A]~~	~~A.13.1.1-1.5~~	~~License Provisioning Override (Backend)~~	A	-	✅ DONE
~~[CP-1B]~~	~~A.13.2.1-2.3~~	~~Workstation Provisioning Override (Backend)~~	A	-	✅ DONE
~~[CP-1C]~~	~~A.13.3.1-3.2~~	~~Pilot Customer Batch Provisioning~~	A	-	✅ DONE
~~[CP-2]~~	~~A.4.9-A.4.12~~	~~Context Sync (all complete in coditect-cloud-infra)~~	A	-	✅ DONE (Jan 9)
~~[CP-3]~~	~~D.1.4~~	~~Rate limiting for container session endpoints~~	D	-	✅ DONE (Jan 9)
~~[CP-4]~~	~~B.5~~	~~All components styled and responsive~~	B	-	✅ DONE (Jan 8)
~~[CP-5]~~	~~B.12.3.1-3.7~~	~~Create @coditect/ui package~~	B	-	✅ DONE (Jan 9)
[CP-6]	B.12.5.1-5.5	docs.coditect.ai content pages	B	`codi-documentation-writer`	16-20h
~~[CP-7]~~	~~F.3.1~~	~~Support email monitoring~~	F	-	✅ DONE (Jan 9)
~~[CP-8]~~	~~A.12.4~~	~~Team Management Testing~~	A	-	✅ DONE (Jan 9)
[CP-9]	C.2.5	CDN configuration (optional)	C	`devops-engineer`	4h
[CP-10]	E.2	Security testing	E	`security-specialist`	8-12h
~~[CP-11A]~~	~~A.13.4.1-4.5~~	~~Admin UI (Frontend)~~	B	-	✅ DONE (Jan 9)
~~[CP-11B]~~	~~A.13.5.1-5.3~~	~~Audit & Security~~	D	-	✅ DONE (Jan 9)

Phase 2: Documentation & Quality [CP-11 to CP-20]

Depends on Phase 1 backend/frontend completion

CP-ID	Task ID	Description	Track	Agent	Est. Hours
[CP-11]	F.1.1-1.3	User guides updated	F	`codi-documentation-writer`	8-12h
[CP-12]	F.7.8.1-8.3	WF-107 Organization Settings docs	F	`codi-documentation-writer`	4-6h
[CP-13]	F.7.9.1-9.3	WF-108 Team Role Change docs	F	`codi-documentation-writer`	4-6h
[CP-14]	F.7.10.1-10.3	WF-109 License Seat Reallocation docs	F	`codi-documentation-writer`	4-6h
[CP-15]	F.7.11.1-11.3	WF-110 Contractor Access Expiration docs	F	`codi-documentation-writer`	4-6h
[CP-16]	F.7.12.1-12.3	WF-111 Agency Consolidated Billing docs	F	`codi-documentation-writer`	4-6h
[CP-17]	F.5.5.3.1-3.12	High success rate component fixes (29-35%)	F	`senior-architect`	8-12h
[CP-18]	F.5.5.4.1-4.18	Medium success rate component fixes (36-39%)	F	`senior-architect`	12-16h
[CP-19]	F.5.5.5.1-5.15	Low success rate component fixes (40-48%)	F	`senior-architect`	10-14h
[CP-20]	F.5.6.1-6.4	Skill Health Framework Enhancement	F	`senior-architect`	12-16h

Phase 3: Launch Preparation [CP-21 to CP-30]

Depends on Phase 2 - GTM and Pilot activities

CP-ID	Task ID	Description	Track	Agent	Est. Hours
[CP-21]	N.2.1	Setup pilot customer infrastructure	N	`devops-engineer`	32h
[CP-22]	N.2.2	Create pilot onboarding materials	N	`codi-documentation-writer`	24h
[CP-23]	N.2.3	Recruit first 10 pilot customers	N	(manual)	40h
[CP-24]	N.2.4	Onboard pilot customers	N	(manual)	80h
[CP-25]	N.2.5	Setup feedback collection system	N	`devops-engineer`	24h
[CP-26]	N.2.6	Provide dedicated pilot support	N	(manual)	160h
[CP-27]	F.7.13-7.16	P1 Workflow docs (WF-112 to WF-116)	F	`codi-documentation-writer`	20-30h
[CP-28]	F.7.17-7.20	P2 Workflow docs (WF-117 to WF-119)	F	`codi-documentation-writer`	12-18h
[CP-29]	F.5.7.1-7.3	Anti-Pattern Prevention System	F	`senior-architect`	16-20h
[CP-30]	F.3.4	Discord community setup	F	`devops-engineer`	4h

Phase 4: DMS Product (Parallel Track) [CP-D1 to CP-D15]

Track G - Independent from main platform, can run in parallel

CP-ID	Task ID	Description	Track	Agent	Est. Hours
[CP-D1]	G.1.1.1-1.6	SSO Token Validation (coditect.ai JWT)	G	`senior-architect`	8-10h
[CP-D2]	G.1.2.1-2.4	Entitlement Verification	G	`senior-architect`	4-6h
[CP-D3]	G.2.1.1-1.5	GitHub OAuth Flow	G	`senior-architect`	10-12h
[CP-D4]	G.2.2.1-2.5	Repository Connection	G	`senior-architect`	8-10h
[CP-D5]	G.2.3.1-3.8	Document Ingestion Pipeline	G	`senior-architect`	16-20h
[CP-D6]	G.3.1.1-1.6	DMS Frontend Project Setup	G	`frontend-react-typescript-expert`	6-8h
[CP-D7]	G.3.2.1-2.7	SSO Landing & Auth	G	`frontend-react-typescript-expert`	8-10h
[CP-D8]	G.3.3.1-3.6	Document Management Pages	G	`frontend-react-typescript-expert`	12-16h
[CP-D9]	G.3.4.1-4.6	GitHub Integration Pages	G	`frontend-react-typescript-expert`	8-10h
[CP-D10]	G.3.5.1-5.4	Settings & Admin Pages	G	`frontend-react-typescript-expert`	6-8h
[CP-D11]	G.3.6.1-6.10	Shared Components	G	`frontend-react-typescript-expert`	12-16h
[CP-D12]	G.4.1-4.5	DMS Frontend Deployment	G	`devops-engineer`	4-6h
[CP-D13]	G.5.1-5.6	File Upload & Storage (GCS)	G	`cloud-architect`	6-8h
[CP-D14]	G.6	DMS E2E Testing	G	`testing-specialist`	8-12h
[CP-D15]	G.7	DMS User Documentation	G	`codi-documentation-writer`	8-12h

Phase 5: Extended Tracks (Post-Launch) [CP-X1 to CP-X10]

Tracks I, J, K, L, M - Deferred to post-pilot launch

CP-ID	Task ID	Description	Track	Priority	Est. Hours
[CP-X1]	I.1.1-1.5	React Component Library	I	P2	204h
[CP-X2]	I.2.1-2.4	Generative UI Engine	I	P3	120h
[CP-X3]	I.3.1-3.4	Accessibility & Storybook	I	P2	136h
[CP-X4]	J.1.1-1.5	Enhanced Context Database	J	P2	112h
[CP-X5]	J.2.1-2.3	Decision Extraction Automation	J	P2	96h
[CP-X6]	J.3.1-3.4	Knowledge Graph	J	P3	128h
[CP-X7]	J.4.1-4.3	Enhanced /cxq Query System	J	P2	96h
[CP-X8]	K.1-K.4	Workflow Automation (all)	K	P3	412h
[CP-X9]	L.1-L.4	Extended Testing (all)	L	P2	384h
[CP-X10]	M.1-M.4	Extended Security (all)	M	P2	536h

Execution Summary

Phase	Tasks	Parallelizable	Total Hours	Wall-Clock (Max Parallel)
Blockers	1 0	✅ RESOLVED	~~4-6h~~ 0h	✅ Done
Phase 1	14 (was 10)	Yes (12 parallel)	108-152h	28-40h
Phase 2	10	Yes (6 parallel)	72-100h	16-24h
Phase 3	10	Partial (4 parallel)	412-524h	160-200h
DMS (parallel)	15	Yes (sequential G.1→G.7)	108-148h	68-88h
Extended	10	Yes	~2,168h	Post-launch

Total Critical Path (Phases 1-3): 592-776 hours raw, 204-264 hours wall-clock with parallelization DMS Product Launch: Additional 68-88 hours wall-clock (can run parallel to main platform) ✅ No Blockers Remaining - Email infrastructure resolved via aliases to 1@az1.ai 🆕 A.13 System Admin Added - License & Workstation provisioning override for pilot customers (+28-40h)

Recommended Execution Order

Week 1: [CP-1A to CP-1C] Admin Override APIs (P0 - Pilot Prerequisite)
        [CP-2 to CP-10] Phase 1 parallel
        [CP-D1 to CP-D5] DMS Backend parallel
Week 2: [CP-11A to CP-11B] Admin UI + Security
        [CP-12 to CP-20] Phase 2 parallel
        [CP-D6 to CP-D11] DMS Frontend parallel
Week 3: [CP-21 to CP-30] Phase 3
        [CP-D12 to CP-D15] DMS Deployment & Testing
Week 4+: GTM activities, Extended tracks as capacity allows

Track A: Backend Completion

Repository: submodules/cloud/coditect-cloud-backend/ Isolation Boundary: All /backend/ code changes No Collision With: Tracks B, C, F (different repos) Depends On: Nothing (can start immediately)

A.1: Step 7 - Client Heartbeat System

Files to Create/Modify:

client/heartbeat.py (NEW)
client/reconnection.py (NEW)
client/cli.py (ADD heartbeat commands)

Tasks:

A.1.1: Background heartbeat thread implementation
- Start thread on license acquire
- Send heartbeat every 5 minutes
- Handle failures gracefully
- Stop thread on release
A.1.2: Automatic reconnection logic ✅ (Jan 08, 2026)
- Retry heartbeat on network failure (3 retries, exponential backoff)
- Attempt re-acquire if all retries fail
- Graceful degradation to offline mode
A.1.3: Network failure graceful degradation
- Continue in offline mode for 30 minutes
- Display warning to user
- Attempt reconnection every 5 minutes
A.1.4: Unit tests for heartbeat system

Estimated Time: 8-12 hours

A.2: Step 9 - Admin Dashboard API

Files to Create/Modify:

api/v1/views/admin.py (NEW)
api/v1/urls.py (ADD admin routes)

Tasks:

A.2.1: GET /api/v1/admin/users endpoint
- List all users (paginated)
- Filter by status
- Search by email, company_name
A.2.2: GET /api/v1/admin/licenses endpoint
- List all licenses (paginated)
- Filter by status
- Search by license_key, user_email
A.2.3: GET /api/v1/admin/analytics endpoint
- Total revenue (MRR, ARR)
- Active subscriptions count
- Churn rate, new signups
A.2.4: Unit tests for admin endpoints

Estimated Time: 4-6 hours

A.3: Commerce API (Multi-Product Checkout) ✅ COMPLETE

Architecture Reference: ADR-014, SDD Section 4.2.1, TDD Sections 6.1.7-6.1.10 Process Documentation: CHECKOUT-PROCESS-DETAILED.md - Complete end-to-end checkout flow Status: ✅ COMPLETE (Dec 31, 2025)

Files Created/Modified:

commerce/models.py - Product, Cart, Order, Entitlement models ✅
commerce/views.py - Commerce API endpoints + StripeWebhookView ✅
commerce/serializers.py - DRF serializers ✅
commerce/urls.py - URL routing ✅
commerce/tests.py - 25 unit tests ✅
commerce/management/commands/seed_products.py - Product seeding ✅
coditect_license/urls.py - Commerce + webhook routes ✅

Database Migrations:

products table (slug, name, type, price_cents, stripe_price_id, features, requires, subdomain) ✅
carts table (user_id, session_id, items JSONB, total_cents, status, expires_at) ✅
orders table (user_id, stripe_payment_intent_id, payment_method, line_items, status) ✅
entitlements table (org_id, product_id, order_id, status, granted_at, expires_at) ✅

Tasks:

A.3.1: Product Catalog API ✅ COMPLETE

A.3.1.1: Product model with type enum (base, addon, bundle) ✅ (Dec 30, 2025)
A.3.1.2: GET /api/v1/products - List all active products ✅ (Dec 30, 2025)
A.3.1.3: GET /api/v1/products/{slug} - Product details ✅ (Dec 30, 2025)
A.3.1.4: Product seed data (Core, DMS, Workflow, Enterprise) ✅ (Dec 30, 2025)
A.3.1.5: Unit tests for product endpoints ✅ (Dec 31, 2025)

A.3.2: Shopping Cart API ✅ COMPLETE

A.3.2.1: Cart model with JSONB items and Redis caching ✅ (Dec 30, 2025)
A.3.2.2: POST /api/v1/cart/items - Add product to cart ✅ (Dec 30, 2025)
A.3.2.3: GET /api/v1/cart - Get current cart ✅ (Dec 30, 2025)
A.3.2.4: DELETE /api/v1/cart/items/{id} - Remove item ✅ (Dec 30, 2025)
A.3.2.5: DELETE /api/v1/cart - Clear cart ✅ (Dec 30, 2025)
A.3.2.6: Cart dependency validation (DMS requires Core) ✅ (Dec 30, 2025)
A.3.2.7: Cart expiration (24 hours) ✅ (Dec 30, 2025)
A.3.2.8: Unit tests for cart endpoints ✅ (Dec 31, 2025)

A.3.3: Checkout & Payment API ✅ COMPLETE

A.3.3.1: POST /api/v1/checkout - Create Stripe Checkout Session ✅ (Dec 30, 2025)
A.3.3.2: POST /api/v1/checkout/google-pay - Process Google Pay token ✅ (Dec 30, 2025)
A.3.3.3: GET /api/v1/checkout/success - Post-payment redirect ✅ (Dec 30, 2025)
A.3.3.4: POST /api/v1/webhooks/stripe - Stripe webhook handler ✅ (Dec 31, 2025)
A.3.3.5: Order model and creation on payment success ✅ (Dec 30, 2025)
A.3.3.6: Webhook signature verification (HMAC-SHA256) ✅ (Dec 31, 2025)
A.3.3.7: Unit tests for checkout endpoints ✅ (Dec 31, 2025)

A.3.4: Entitlement System API ✅ COMPLETE

A.3.4.1: Entitlement model with status enum ✅ (Dec 30, 2025)
A.3.4.2: GET /api/v1/entitlements - List user entitlements ✅ (Dec 30, 2025)
A.3.4.3: GET /api/v1/entitlements/{slug} - Check specific entitlement ✅ (Dec 30, 2025)
A.3.4.4: Entitlement provisioning on order completion ✅ (Dec 31, 2025)
A.3.4.5: Entitlement revocation on cancellation/refund ✅ (Dec 31, 2025)
A.3.4.6: Unit tests for entitlement endpoints ✅ (Dec 31, 2025)

Completed: December 31, 2025 (16 hours actual)

A.4: Context Sync API (Multi-Device Session Sync)

Repository: submodules/cloud/coditect-cloud-infra/backend/ Architecture Decision: Custom REST Sync (MoE Consensus: 9/10 DevOps, 39/50 Security) Status: ✅ COMPLETE (Dec 29, 2025)

Files Created:

context/__init__.py - App initialization
context/apps.py - Django app config
context/models.py - ContextMessage, SyncCursor, SyncStats models
context/serializers.py - Push/Pull/Status serializers
context/views.py - API views
context/urls.py - URL routing
context/migrations/__init__.py - Migration package

Files Modified:

requirements.txt - Added djangorestframework-simplejwt==5.3.1
coditect_license/settings.py - JWT auth config, context app registration
coditect_license/urls.py - JWT + Context sync routes

API Endpoints:

Endpoint	Method	Description
`/api/v1/auth/token/`	POST	Obtain JWT access + refresh tokens
`/api/v1/auth/token/refresh/`	POST	Refresh access token
`/api/v1/auth/token/verify/`	POST	Verify token validity
`/api/v1/context/push`	POST	Push messages from client to cloud
`/api/v1/context/pull`	GET	Pull messages from cloud to client
`/api/v1/context/status`	GET	Get sync status and stats
`/api/v1/context/messages`	DELETE	Delete old messages

Sync Architecture:

SQLite (local) ──REST API──▶ PostgreSQL (cloud) ──REST API──▶ SQLite (all clients)
     │                              │                              │
     └── Polling (30s) ─────────────┴──────────────────────────────┘

Key Features:

✅ JWT authentication with tenant_id claims
✅ Content-hash deduplication (SHA256)
✅ Cursor-based polling (30s intervals)
✅ Multi-tenant isolation
✅ Unified auth with Workstations API (ADR-005)
✅ Unified auth with Repositories API (ADR-006)

Tasks Completed:

A.4.1: ContextMessage model with content_hash deduplication
A.4.2: SyncCursor model for per-device tracking
A.4.3: POST /api/v1/context/push endpoint
A.4.4: GET /api/v1/context/pull endpoint with cursor
A.4.5: GET /api/v1/context/status endpoint
A.4.6: DELETE /api/v1/context/messages endpoint
A.4.7: JWT auth integration with SimpleJWT
A.4.8: Unified authentication across all APIs

Remaining Tasks:

A.4.9: Run database migrations ✅ (Migrations 0001-0005 in coditect-cloud-infra/backend/context/)
A.4.10: Create CustomTokenObtainPairSerializer with tenant_id claims ✅ (Exists in coditect-cloud-infra/backend/users/serializers.py - adds tenant_id, email, system_role to JWT)
A.4.11: Unit tests for context sync endpoints ✅ (Tests exist in views with authentication)
A.4.12: Integration test with local SQLite client ✅ (cloud_sync_client.py created Jan 4, 2026)

Note (Jan 9, 2026): A.4 Context Sync overlaps with A.9 Cloud Context Task Sync. A.9 is the authoritative section. ALL A.4 TASKS COMPLETE (Jan 9, 2026): A.4.10 (CustomTokenObtainPairSerializer) discovered in coditect-cloud-infra/backend/users/serializers.py with tenant_id, email, system_role JWT claims and CustomTokenObtainPairView at /api/v1/auth/login/.

Estimated Time: 12-16 hours ✅ COMPLETE

A.5: Team/Project Context Sync (Multi-Level Backup)

Architecture Reference: ADR-045, ADR-044 (Extended) Repository: submodules/cloud/coditect-cloud-infra/backend/ Status: NEW (Dec 30, 2025)

Purpose: Extend context sync to support team-level sharing and project-level isolation with hierarchical backup to GCS.

Files to Create/Modify:

context/models.py (ADD TeamContext, ProjectContext)
context/serializers.py (ADD team/project serializers)
context/views.py (ADD team/project endpoints)
context/urls.py (ADD team/project routes)
context/services/backup.py (NEW) - GCS backup service
context/tasks.py (NEW) - Scheduled backup jobs

Database Migrations:

team_contexts table (tenant_id, team_id, message_type, content, content_hash, metadata)
project_contexts table (tenant_id, project_id, message_type, content, content_hash, metadata)
team_sync_cursors table (team_id, user_id, device_id, cursor_position)
project_sync_cursors table (project_id, user_id, device_id, cursor_position)

Tasks:

A.5.1: Database Schema (Week 1)

A.5.1.1: Create TeamContext model with RLS
A.5.1.2: Create ProjectContext model with RLS
A.5.1.3: Create TeamSyncCursor model
A.5.1.4: Create ProjectSyncCursor model
A.5.1.5: Generate and run migrations

A.5.2: Team Context API (Week 2)

A.5.2.1: TeamContext serializers (push/pull/status)
A.5.2.2: POST /api/v1/teams/{id}/context/push endpoint
A.5.2.3: GET /api/v1/teams/{id}/context/pull endpoint
A.5.2.4: GET /api/v1/teams/{id}/context/status endpoint
A.5.2.5: Team context permission checks (team membership)
A.5.2.6: Unit tests for team context endpoints

A.5.3: Project Context API (Week 3)

A.5.3.1: ProjectContext serializers (push/pull/status)
A.5.3.2: POST /api/v1/projects/{id}/context/push endpoint
A.5.3.3: GET /api/v1/projects/{id}/context/pull endpoint
A.5.3.4: GET /api/v1/projects/{id}/context/status endpoint
A.5.3.5: Project context permission checks (project membership)
A.5.3.6: Unit tests for project context endpoints

A.5.4: Backup System (Week 4)

A.5.4.1: GCS backup service (context/services/backup.py)
A.5.4.2: POST /api/v1/teams/{id}/context/backup endpoint
A.5.4.3: POST /api/v1/teams/{id}/context/restore endpoint
A.5.4.4: POST /api/v1/projects/{id}/context/backup endpoint
A.5.4.5: POST /api/v1/projects/{id}/context/restore endpoint
A.5.4.6: Cloud Scheduler job for hourly incremental backups
A.5.4.7: Cloud Scheduler job for daily full backups
A.5.4.8: Backup/restore integration tests

Estimated Time: 32-40 hours (4 weeks part-time)

A.6: Reference Data - ISO Standard Contact Management ✅ COMPLETE

Status: COMPLETE (January 1, 2026) Files Created:

reference_data/__init__.py (NEW)
reference_data/apps.py (NEW)
reference_data/models.py (NEW) - 7 models with full ISO compliance
reference_data/admin.py (NEW) - Admin interface for all models
reference_data/management/commands/seed_reference_data.py (NEW) - Seed command
reference_data/migrations/0001_initial.py (NEW)

ISO Standards Implemented:

ISO 3166-1: Country codes (alpha-2, alpha-3, numeric) - 50+ countries
ISO 3166-2: State/Province codes (US states, Canadian provinces) - 67 entries
ISO 4217: Currency codes with symbols and decimal places - 30+ currencies
ITU-T E.164: Phone country codes with format patterns - 30+ codes
IANA: Timezone identifiers with DST info - 29 major timezones

Models Created:

Country - Full country data with postal code patterns, state labels
State - State/Province with type classification (state, province, territory)
City - City with population, timezone, alternate names for autocomplete
PostalCode - ZIP/postal code mapping for autopopulation
Currency - Currency with symbol, decimal digits, major flag
PhoneCountryCode - Calling code with format patterns, length validation
Timezone - Timezone with UTC offset, DST info

Entity Model Updates:

Organization model: Added FK fields for country_ref, state_ref, city_ref, currency_ref, phone_country_code, timezone_ref
LegalEntity model: Added FK fields for country_ref, state_ref, city_ref, functional_currency_ref, timezone_ref
Dual-field pattern: FK + CharField for backwards compatibility and incremental adoption

Tasks:

Usage:

# Seed reference data
python manage.py seed_reference_data

# Clear and reseed
python manage.py seed_reference_data --clear

Estimated Time: 4 hours Actual Time: 3 hours

A.7: Cloud Workstations Provisioning API (P1)

Status: 🆕 Not Started (Jan 2, 2026) Goal: Auto-provision Google Cloud Workstations upon license purchase

Files to Create/Modify:

backend/workstations/ (NEW Django app)
backend/workstations/models.py - WorkstationInstance model
backend/workstations/services.py - GCP Workstations API integration
backend/workstations/views.py - User workstation management API
backend/commerce/webhooks.py (MODIFY) - Add workstation provisioning trigger

Agent Invocation:

Task(subagent_type="rust-expert-developer", prompt="Implement Track A.7 Cloud Workstations Provisioning API: (1) create workstations Django app; (2) integrate GCP Workstations API for provisioning; (3) create WorkstationInstance model tracking user workstations; (4) add Stripe webhook handler to trigger provisioning on successful payment; (5) create API endpoints for users to view/manage their workstations")

Tasks:

A.7.1: Create workstations Django app
- Agent: Task(subagent_type="senior-architect", prompt="Create Django app for Cloud Workstations management with models, views, serializers")
A.7.2: WorkstationInstance model
- Agent: Task(subagent_type="database-architect", prompt="Create WorkstationInstance model: user FK, workstation_id, status, gcp_project, region, created_at, last_accessed")
- Fields: user, license, workstation_id, status (provisioning/ready/stopped/deleted), gcp_region, created_at
A.7.3: GCP Workstations API integration
- Agent: Task(subagent_type="cloud-architect", prompt="Integrate GCP Workstations API: create workstation config, provision workstation, start/stop/delete operations")
- Use google-cloud-workstations Python SDK
- Create workstation config with coditect-core pre-installed
- Handle async provisioning (can take 5-10 minutes)
A.7.4: Stripe webhook provisioning trigger
- Agent: Task(subagent_type="senior-architect", prompt="Add workstation provisioning to Stripe checkout.session.completed webhook handler")
- On successful payment for Workstation product → queue provisioning job
- Send email notification when workstation ready
A.7.5: User workstation management API
- Agent: Task(subagent_type="senior-architect", prompt="Create REST API endpoints: GET /workstations/, POST /workstations/{id}/start, POST /workstations/{id}/stop")
- GET /api/v1/workstations/ - List user's workstations
- POST /api/v1/workstations/{id}/start - Start stopped workstation
- POST /api/v1/workstations/{id}/stop - Stop running workstation
- GET /api/v1/workstations/{id}/connect - Get connection URL
A.7.6: Workstation cleanup on license expiration
- Agent: Task(subagent_type="devops-engineer", prompt="Create scheduled job to stop/delete workstations when license expires")
- Celery task to check license status daily
- Grace period: 7 days after expiration before deletion

Estimated Time: 16-20 hours

A.8: Docker Image Heartbeat System (P1)

Status: 🆕 Not Started (Jan 2, 2026) Goal: Runtime license verification for Docker containers (not just startup)

Files to Create/Modify:

docker/scripts/heartbeat-daemon.py (NEW)
docker/scripts/validate-license.py (MODIFY) - Add heartbeat mode
docker/entrypoint.sh (MODIFY) - Start heartbeat daemon
backend/licenses/views.py (MODIFY) - Add heartbeat endpoint

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Implement Track A.8 Docker Image Heartbeat System: (1) create background heartbeat daemon for Docker containers; (2) periodic license verification every 15 minutes; (3) graceful warning/shutdown on license invalidation; (4) heartbeat API endpoint on backend; (5) offline grace period handling")

Tasks:

A.8.1: Heartbeat daemon script
- Agent: Task(subagent_type="devops-engineer", prompt="Create Python daemon script that sends heartbeat every 15 minutes to license API")
- Background thread/process running in container
- Send POST /api/v1/licenses/heartbeat/ every 15 minutes
- Include: license_key, container_id, hostname, IP
A.8.2: Backend heartbeat endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create POST /api/v1/licenses/heartbeat/ endpoint that validates license and records activity")
- POST /api/v1/licenses/heartbeat/
- Validate license is active
- Record last_heartbeat timestamp in database
- Return: status (ok/warning/expired), message, grace_period_remaining
A.8.3: Graceful degradation on license issues
- Agent: Task(subagent_type="devops-engineer", prompt="Implement graceful warning system: desktop notification on license warning, countdown to shutdown")
- Warning state: Show notification "License expires in X days"
- Expired state: Show warning, allow 1-hour grace to save work
- Revoked state: Immediate graceful shutdown with save prompt
A.8.4: Offline grace period
- Agent: Task(subagent_type="devops-engineer", prompt="Implement 72-hour offline grace period with cached license validation")
- Cache last successful validation
- Allow 72 hours offline operation
- After 72 hours, require network validation
A.8.5: Entrypoint integration
- Agent: Task(subagent_type="devops-engineer", prompt="Modify Docker entrypoint.sh to start heartbeat daemon as background process")
- Start heartbeat-daemon.py in background
- Ensure daemon restarts on failure
- Log heartbeat activity to /var/log/coditect-heartbeat.log
A.8.6: Heartbeat monitoring dashboard
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Add heartbeat status to user dashboard showing active containers and last heartbeat times")
- Show active containers on user dashboard
- Display last heartbeat time
- Alert if container hasn't heartbeated in >30 minutes

Estimated Time: 12-16 hours

A.9: Cloud Context Task Sync (ADR-053 Implementation)

Status: 🆕 NEW (Jan 4, 2026) Architecture Reference: ADR-053 (Cloud Context Sync Architecture), ADR-052 (Intent-Aware Context Management), ADR-046 (Continual Learning System) Goal: Extend local context sync to cloud for multi-tenant, multi-user, multi-device collaboration

Repository Files:

coditect-cloud-infra/backend/context/models.py (MODIFY - add TaskTracking)
coditect-cloud-infra/backend/context/views.py (MODIFY - add task endpoints)
coditect-cloud-infra/backend/context/serializers.py (MODIFY - add task serializers)
coditect-cloud-infra/backend/context/urls.py (MODIFY - add task routes)
coditect-core/hooks/dispatcher.sh (CREATED ✅)
coditect-core/scripts/core/cloud_sync_client.py (CREATED ✅)
coditect-core/config/config.template.json (CREATED ✅)

Completed Work (Jan 4, 2026):

A.9.0.1: Create ADR-053 Cloud Context Sync Architecture
A.9.0.2: Create multi-tenant hook dispatcher (dispatcher.sh)
A.9.0.3: Create cloud_sync_client.py for local-cloud sync
A.9.0.4: Create config.template.json for cloud configuration
A.9.0.5: Fix task-plan-sync.py TASK_ID_PATTERN bug
A.9.0.6: Fix hook path portability (--root auto-detection)

Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement Track A.9 Cloud Context Task Sync per ADR-053: (1) add TaskTracking model to context app; (2) create task sync endpoints; (3) integrate with existing django-multitenant isolation; (4) test end-to-end sync from hooks → cloud")

Tasks:

A.9.1: TaskTracking Model (Week 1)

A.9.1.1: Create TaskTracking model in context/models.py ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="database-architect", prompt="Create TaskTracking(TenantModel) with: task_id, description, status, outcome, outcome_score, tool counts, timestamps, content_hash")
- Fields per ADR-053: tenant FK, user_id, task_id, description, active_form, project_id, status, outcome, outcome_score, tool_success_count, tool_error_count, user_corrections, started_at, completed_at, synced_at, updated_at, content_hash, sync_cursor
- Completed: Added TaskTracking(TenantModel) with STATUS_CHOICES, OUTCOME_CHOICES, auto-timestamp updates on status change
A.9.1.2: Create TaskMessage model for task-message relationship ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="database-architect", prompt="Create TaskMessage model linking TaskTracking to ContextMessage for message-task correlation")
- Completed: Added TaskMessage(TenantModel) with task FK, message FK, sequence ordering, tenant isolation
A.9.1.3: Generate and run migrations
- Agent: Task(subagent_type="devops-engineer", prompt="Run makemigrations context && migrate for TaskTracking model")
A.9.1.4: Add admin interface for TaskTracking
- Agent: Task(subagent_type="senior-architect", prompt="Create TaskTrackingAdmin with filters, search, readonly fields for audit")

A.9.2: Task Sync API Endpoints (Week 2)

A.9.2.1: Create TaskTrackingSerializer
- Agent: Task(subagent_type="senior-architect", prompt="Create DRF serializer for TaskTracking with content_hash deduplication")
A.9.2.2: Create POST /api/v1/context/tasks/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create TaskPushView for pushing task data with deduplication and tenant isolation")
A.9.2.3: Create GET /api/v1/context/tasks/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create TaskListView with filters: project_id, status, date range, pagination")
A.9.2.4: Create GET /api/v1/context/tasks/{id}/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create TaskDetailView for retrieving single task with related messages")
A.9.2.5: Add task endpoints to context/urls.py
- Agent: Task(subagent_type="senior-architect", prompt="Register task endpoints in URL patterns")
A.9.2.6: Unit tests for task sync endpoints
- Agent: Task(subagent_type="testing-specialist", prompt="Write pytest tests for task push/pull/list endpoints with tenant isolation verification")

A.9.3: Local-Cloud Integration (Week 3)

A.9.3.1: Update cloud_sync_client.py with authentication
- Agent: Task(subagent_type="senior-architect", prompt="Add license key → JWT authentication flow to cloud_sync_client.py")
A.9.3.2: Integrate sync_task() with hooks
- Agent: Task(subagent_type="senior-architect", prompt="Wire task-plan-sync.py PostToolUse hook to call cloud_sync_client.sync_task()")
A.9.3.3: Implement offline queue processing
- Agent: Task(subagent_type="senior-architect", prompt="Add background sync for queued tasks when connection restored")
A.9.3.4: End-to-end integration test
- Agent: Task(subagent_type="testing-specialist", prompt="Test full flow: TodoWrite → hook → cloud_sync_client → Django API → PostgreSQL")

A.9.4: Multi-Tenant Verification (Week 4)

A.9.4.1: Test tenant isolation with multiple tenants
- Agent: Task(subagent_type="testing-specialist", prompt="Create test fixtures with 3 tenants, verify complete data isolation")
A.9.4.2: Test team-level sharing within tenant
- Agent: Task(subagent_type="testing-specialist", prompt="Test that team members within same tenant can see shared context")
A.9.4.3: Test project-level isolation within team
- Agent: Task(subagent_type="testing-specialist", prompt="Test that project context is isolated from other projects in same team")
A.9.4.4: Deploy to GKE staging environment
- Agent: Task(subagent_type="devops-engineer", prompt="Deploy updated context app to GKE staging, run smoke tests")
A.9.4.5: Deploy to GKE production
- Agent: Task(subagent_type="devops-engineer", prompt="Deploy to GKE production after staging verification")

Estimated Time: 24-32 hours (4 weeks part-time)

A.10: Container Session Lifecycle API (ADR-055) ✅ 100%

Status: ✅ COMPLETE (Jan 6, 2026) Goal: Django backend API endpoints for container session validation, heartbeat, and release ADR: adr-055-licensed-docker-container-schema.md

Architecture Summary: Container lifecycle requires three API endpoints:

Session Validate - Container startup → validate license → get session token
Session Heartbeat - Periodic (5 min) → verify session still valid
Session Release - Container shutdown → graceful cleanup

Multi-User Container Model:

A container (especially Cloud Workstation) may serve multiple licensed users
ContainerSession tracks the container itself (organization/team license)
ContainerUserSession tracks individual users within a container
License limits apply at organization level, not per-container

Files:

backend/sessions/ (NEW Django app)
backend/sessions/models.py - ContainerSession, ContainerUserSession models
backend/sessions/serializers.py - Session request/response
backend/sessions/views.py - Session API views
backend/sessions/urls.py - URL routing
backend/licenses/models.py (MODIFY) - Add max_containers field
backend/organizations/models.py (MODIFY) - Add container session FK

Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement Track A.10 Container Session Lifecycle API per ADR-055: (1) create sessions Django app; (2) ContainerSession model with license FK, container_id, status, heartbeat tracking; (3) POST /api/v1/sessions/validate endpoint; (4) POST /api/v1/sessions/heartbeat endpoint; (5) POST /api/v1/sessions/release endpoint; (6) integrate with existing license validation")

Tasks:

A.10.1: Sessions Django App (Day 1-2)

A.10.1.1: Create sessions Django app
- Agent: Task(subagent_type="senior-architect", prompt="Create backend/sessions/ Django app with __init__, apps, admin, models, serializers, views, urls")
- Run: python manage.py startapp sessions
- Register in INSTALLED_APPS
A.10.1.2: Create ContainerSession model (container-level)
- Agent: Task(subagent_type="database-architect", prompt="Create ContainerSession(TenantModel) for tracking containers: organization FK, license FK, container_id (unique), container_type, session_token, status, max_users, current_user_count, heartbeat tracking")
- Fields:
  - organization = ForeignKey(Organization) - Organization owning container
  - license = ForeignKey(License) - License authorizing container
  - container_id = CharField(max_length=64, unique=True)
  - container_type = CharField(choices=['docker', 'workstation'])
  - session_token = UUIDField(default=uuid4)
  - status = CharField(choices=['active', 'expired', 'released'])
  - max_users = IntegerField(default=1) - Max concurrent users (from license tier)
  - current_user_count = IntegerField(default=0) - Current active users
  - created_at = DateTimeField(auto_now_add=True)
  - last_heartbeat_at = DateTimeField(null=True)
  - released_at = DateTimeField(null=True)
  - ip_address = GenericIPAddressField(null=True)
  - hostname = CharField(max_length=255, null=True)
A.10.1.3: Create ContainerUserSession model (user-level) 🆕 (Jan 4, 2026)
- Agent: Task(subagent_type="database-architect", prompt="Create ContainerUserSession(TenantModel) for tracking users within containers: container_session FK, user FK, user_token, started_at, last_activity_at, ended_at")
- Fields:
  - container_session = ForeignKey(ContainerSession)
  - user = ForeignKey(User) - Individual user in container
  - user_token = UUIDField(default=uuid4) - User's session token within container
  - started_at = DateTimeField(auto_now_add=True)
  - last_activity_at = DateTimeField(null=True)
  - ended_at = DateTimeField(null=True)
- Increment container_session.current_user_count on create
- Decrement on ended_at set
A.10.1.4: Generate and run migrations
- Agent: Task(subagent_type="devops-engineer", prompt="Run makemigrations sessions && migrate")
A.10.1.5: Create ContainerSessionAdmin and ContainerUserSessionAdmin
- Agent: Task(subagent_type="senior-architect", prompt="Create ContainerSessionAdmin and ContainerUserSessionAdmin with list_display, list_filter, search_fields, readonly_fields")
A.10.1.6: Add max_containers field to License model 🆕 (Jan 4, 2026)
- Agent: Task(subagent_type="database-architect", prompt="Add max_containers IntegerField to License model with tier defaults: Starter=1, Pro=5, Enterprise=unlimited (-1)")
- Starter tier: max_containers = 1
- Professional tier: max_containers = 5
- Enterprise tier: max_containers = -1 (unlimited)
- Used by A.10.2.2 to enforce container limits

A.10.2: Session Validation Endpoint (Day 3-4)

A.10.2.1: Create SessionValidateSerializer
- Agent: Task(subagent_type="senior-architect", prompt="Create SessionValidateSerializer with: license_key (required), container_id (required), container_type, hostname, ip_address")
- Input: license_key, container_id, container_type, hostname, ip_address
- Output: session_token, license_tier, tenant_id, expires_at
A.10.2.2: Create POST /api/v1/sessions/validate endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create SessionValidateView: validate license_key active, check container seat limit, create ContainerSession, return session_token")
- Validate license_key is active
- Check max concurrent containers not exceeded
- Create ContainerSession record
- Return session_token for subsequent heartbeats
A.10.2.3: Handle Docker-specific validation
- Agent: Task(subagent_type="senior-architect", prompt="Add Docker-specific validation: CODITECT_LICENSE_KEY env var validation, container_id from Docker")
- Input: CODITECT_LICENSE_KEY environment variable
- Validate license exists and is active
- Check max_containers limit on license tier
A.10.2.4: Handle Workstation-specific validation
- Agent: Task(subagent_type="senior-architect", prompt="Add Workstation-specific validation: GCP OAuth JWT token validation, map to user, get license from user")
- Input: GCP OAuth JWT token
- Validate JWT signature with Google public keys
- Map GCP user to CODITECT user
- Get user's active license

A.10.3: Session Heartbeat Endpoint (Day 5-6)

A.10.3.1: Create SessionHeartbeatSerializer
- Agent: Task(subagent_type="senior-architect", prompt="Create SessionHeartbeatSerializer with: session_token header auth, optional metrics (cpu, memory, uptime)")
A.10.3.2: Create POST /api/v1/sessions/heartbeat endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create SessionHeartbeatView: validate session_token, check license still active, update last_heartbeat_at, return status")
- Auth: Bearer session_token
- Validate session exists and is active
- Check underlying license is still active
- Update last_heartbeat_at timestamp
- Return: status (ok/warning/expired), grace_period_remaining, message
A.10.3.3: Session expiration logic
- Agent: Task(subagent_type="senior-architect", prompt="Implement session expiration: mark expired if no heartbeat for 30 minutes, allow 72-hour offline grace period")
- Mark session 'expired' if no heartbeat for 30 minutes
- 72-hour offline grace period (configurable per tier)
- Return warning status if approaching expiration

A.10.4: Session Release Endpoint (Day 7)

A.10.4.1: Create POST /api/v1/sessions/release endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create SessionReleaseView: validate session_token, mark session released, set released_at timestamp")
- Auth: Bearer session_token
- Mark session status = 'released'
- Set released_at timestamp
- Free up container slot for license
A.10.4.2: Cleanup orphaned sessions
- Agent: Task(subagent_type="devops-engineer", prompt="Create Celery task to cleanup orphaned sessions: sessions with no heartbeat for 24 hours, mark as expired")
- Celery beat task running daily
- Find sessions with last_heartbeat_at > 24 hours ago
- Mark as 'expired' and log
A.10.4.3: License expiration webhook handler ✅ (Jan 9, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create webhook handler for license.expired and license.revoked events that marks all active ContainerSessions for that license as expired and sends push notification to containers")
- Status: COMPLETE - License.terminate_container_sessions() method in licenses/models.py
- Webhook Handlers:
  - _handle_subscription_deleted() in subscription.py:706 - calls on subscription cancel
  - _handle_payment_failed() in subscription.py:835 - calls on 3rd payment failure
- Celery Task: expire_licenses_and_terminate_sessions in licenses/tasks.py - scheduled scan for expired licenses
- Tests: 435 lines in tests/test_api/test_license_expiration_webhook.py
- WebSocket/SSE notification deferred (optional enhancement)

A.10.5: Integration & Testing (Day 8-10)

A.10.5.1: Add URL routes
- Agent: Task(subagent_type="senior-architect", prompt="Add session endpoints to backend/sessions/urls.py and include in main urls.py")
- POST /api/v1/sessions/validate
- POST /api/v1/sessions/heartbeat
- POST /api/v1/sessions/release
A.10.5.2: Unit tests for session endpoints
- Agent: Task(subagent_type="testing-specialist", prompt="Write pytest tests for session validate/heartbeat/release endpoints with license state variations")
- Test: Valid license → session created
- Test: Invalid license → 403 error
- Test: Max containers exceeded → 429 error
- Test: Heartbeat updates timestamp
- Test: Release marks session released
A.10.5.3: Integration with C.6 entrypoints
- Agent: Task(subagent_type="devops-engineer", prompt="Verify C.6 container entrypoints call A.10 session endpoints correctly")
- Docker entrypoint calls /sessions/validate with license_key
- Workstation entrypoint calls /sessions/validate with JWT
- Both call /sessions/heartbeat periodically
- Both call /sessions/release on exit

Dependencies:

A.3 (License model must exist) ✅ Complete
C.6 (Container entrypoints consume these endpoints)

Estimated Time: 16-24 hours (2 weeks part-time)

A.11: Cloud Workstation Broker Service (ADR-005 Implementation) ✅ 100%

Status: ✅ 100% Complete (Jan 7, 2026) Goal: Implement Workstation Broker to provision Cloud Workstations for licensed users ADR: ADR-005-workstation-broker-pattern.md Blocking: ~~Users cannot get Cloud Workstations without this~~ UNBLOCKED

Architecture Summary: ADR-005 defines the architecture. Implementation status:

Broker Service - FastAPI service managing workstation lifecycle
Terraform Modules - GCP Cloud Workstations infrastructure
Auto-Provision Webhook - License purchase → Workstation creation
User Access - JWT token generation for IDE access

User Journey (Currently Broken):

✅ User buys license → ✅ License provisioned → ❌ STUCK (No workstation)

User Journey (After A.11):

✅ User buys license → ✅ License provisioned → ✅ Workstation auto-provisioned → ✅ User clicks "Launch IDE"

Files to Create:

submodules/cloud/coditect-workstation-broker/ (NEW repository or service)
opentofu/modules/cloud-workstations/ - Terraform/OpenTofu modules
backend/workstations/ - Django app for workstation management
backend/workstations/models.py - Workstation, WorkstationAssignment models
backend/workstations/broker.py - GCP Cloud Workstations API client
backend/workstations/views.py - REST API endpoints

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Implement Track A.11 Cloud Workstation Broker per ADR-005: (1) create GCP Cloud Workstation cluster via Terraform; (2) implement broker service for provisioning/starting/stopping workstations; (3) webhook handler to auto-provision on license purchase; (4) IDE access token generation")

Tasks:

A.11.1: GCP Cloud Workstation Infrastructure (Week 1) ✅ 100% COMPLETE (Jan 7, 2026)

A.11.1.1: Create OpenTofu module for Cloud Workstation cluster ✅
- Agent: Task(subagent_type="devops-engineer", prompt="Create opentofu/modules/cloud-workstations/ with cluster, config, and workstation resources for us-central1")
- Implemented: opentofu/modules/cloud-workstations/ - Combined module with cluster, configs (standard/power/AI), IAM bindings, service account
- Cluster: coditect-ws-cluster in us-central1
- Config: coditect-standard-dev (e2-standard-4, 100GB SSD)
- IAM bindings for service account
A.11.1.2: Deploy workstation cluster to GCP ✅
- Agent: Task(subagent_type="devops-engineer", prompt="Apply OpenTofu to create Cloud Workstation cluster in coditect-citus-prod project")
- Run: tofu apply -target=module.cloud_workstations
- Verify cluster is RUNNING in GCP Console
- Verified: Cluster coditect-ws-dev running in us-central1
A.11.1.3: Create custom workstation container image ✅
- Agent: Task(subagent_type="devops-engineer", prompt="Create Dockerfile.workstation with CODITECT pre-installed, Claude Code, dev tools. Push to gcr.io/coditect-cloud-infra/workstation:latest")
- Base: us-docker.pkg.dev/cloud-workstations-images/predefined/code-oss:latest
- Add: CODITECT framework at /opt/coditect
- Add: Claude Code CLI pre-configured
- Add: Git, Python, Node.js dev tools
- Implemented: docker/workstation/Dockerfile, docker/workstation/scripts/setup-project.sh
A.11.1.4: Configure workstation startup script ✅
- Agent: Task(subagent_type="devops-engineer", prompt="Create startup script that validates license on workstation boot via A.10 /sessions/validate endpoint")
- On boot: Call /api/v1/sessions/validate with license
- Start heartbeat loop (every 5 minutes)
- On shutdown: Call /api/v1/sessions/release
- Implemented: docker/workstation/scripts/coditect-license-client.sh

A.11.2: Workstation Django App (Week 1-2) ✅ COMPLETE (Jan 6, 2026)

A.11.2.1: Create workstations Django app ✅
- Agent: Task(subagent_type="senior-architect", prompt="Create backend/workstations/ Django app with models, serializers, views, urls")
- App already exists at backend/workstations/
- Registered in INSTALLED_APPS: 'workstations.apps.WorkstationsConfig'
A.11.2.2: Create Workstation model ✅
- Agent: Task(subagent_type="database-architect", prompt="Create Workstation(TenantModel) with gcp_workstation_id, status, user FK, license FK, cluster, config, created_at, last_accessed_at")
- Models implemented in models.py (457 lines):
  - WorkstationConfig - Configuration tiers (standard, power, ai)
  - Workstation - Per-user dedicated workstations
  - SharedWorkstation - Multi-user shared workstations (ADR-005)
  - WorkstationUserAccess - User access with Linux isolation
  - WorkstationSession - Session tracking
  - WorkstationUsageRecord - Usage records for billing
A.11.2.3: Create GCP Cloud Workstations API client ✅
- Agent: Task(subagent_type="senior-architect", prompt="Create workstations/broker.py with GCP Cloud Workstations API client: create_workstation, start_workstation, stop_workstation, delete_workstation, get_access_token")
- Implemented in services.py (495 lines):
  - WorkstationBrokerService with full GCP integration
  - Methods: get_or_create_workstation, start, stop, status, generate_access_token, list_tenant
  - Uses google-cloud-workstations library
A.11.2.4: Generate and run migrations ✅
- Agent: Task(subagent_type="devops-engineer", prompt="Run makemigrations workstations && migrate")
- Migration 0001_initial.py created and applied

A.11.3: Workstation API Endpoints (Week 2) ✅ COMPLETE (Jan 6, 2026)

A.11.3.1: POST /api/v1/workstations/provision endpoint ✅
- Agent: Task(subagent_type="senior-architect", prompt="Create WorkstationProvisionView: validate license, check workstation limit, call GCP API to create workstation, return workstation_id")
- Implemented: WorkstationProvisionView in views.py
- URL: /api/v1/workstations/provision/
A.11.3.2: POST /api/v1/workstations/{id}/start endpoint ✅
- Agent: Task(subagent_type="senior-architect", prompt="Create WorkstationStartView: validate ownership, call GCP API to start workstation")
- Implemented: WorkstationStartView in views.py
- URL: /api/v1/workstations/<id>/start/
A.11.3.3: POST /api/v1/workstations/{id}/stop endpoint ✅
- Agent: Task(subagent_type="senior-architect", prompt="Create WorkstationStopView: validate ownership, call GCP API to stop workstation")
- Implemented: WorkstationStopView in views.py
- URL: /api/v1/workstations/<id>/stop/
A.11.3.4: GET /api/v1/workstations/{id}/token endpoint ✅
- Agent: Task(subagent_type="senior-architect", prompt="Create WorkstationTokenView: validate ownership, generate short-lived access token for IDE access")
- Implemented: WorkstationTokenView in views.py
- URL: /api/v1/workstations/<id>/token/
A.11.3.5: GET /api/v1/workstations/ endpoint (list user's workstations) ✅
- Agent: Task(subagent_type="senior-architect", prompt="Create WorkstationListView: return user's workstations with status")
- Implemented: MyWorkstationView, TenantWorkstationsView, AvailableWorkstationsView
- URLs: /api/v1/workstations/me/, /api/v1/workstations/tenant/, /api/v1/workstations/me/available/
A.11.3.6: POST /api/v1/workstations/{id}/connect endpoint ✅ (BONUS - shared workstation support)
- Agent: ADR-005 shared workstation enhancement
- Implemented: WorkstationConnectView for dedicated + shared workstation access
- URL: /api/v1/workstations/<id>/connect/
- Plus: ActiveSessionsView, WorkstationDisconnectView, SetDefaultWorkstationView

Additional Endpoints Implemented (ADR-005 Shared Workstation Support):

GET /api/v1/workstations/configs/ - List workstation configurations
GET /api/v1/workstations/shared/ - List shared workstations for tenant
GET /api/v1/workstations/sessions/ - List active sessions
POST /api/v1/workstations/sessions/<id>/disconnect/ - Disconnect from session
POST /api/v1/workstations/me/default/ - Set default workstation

A.11.4: Auto-Provision Webhook (Week 2) ✅ COMPLETE (Jan 6, 2026)

A.11.4.1: Extend Stripe webhook handler for workstation provisioning ✅
- Agent: Task(subagent_type="senior-architect", prompt="Extend StripeWebhookView to auto-provision workstation on checkout.session.completed for products that include workstation access")
- On checkout.session.completed:
  - Check if product includes workstation (e.g., Pro, Enterprise tiers)
  - Call WorkstationProvisionView internally
  - Store workstation_id on license/user
- Implemented: _create_entitlements() detects product_type == 'workstation', triggers provision_workstation_for_user.delay()
- Files: commerce/views.py, workstations/tasks.py
A.11.4.2: Send welcome email with workstation instructions ✅
- Agent: Task(subagent_type="senior-architect", prompt="Send email via SendGrid when workstation is provisioned with access instructions and 'Launch IDE' button")
- Template: workstation-ready.html
- Include: Access URL, getting started guide link
- Implemented: send_workstation_welcome_email Celery task with HTML template
- Files: commerce/tasks.py (270 lines)

A.11.5: Integration & Testing (Week 3)

A.11.5.1: Unit tests for workstation endpoints ✅ COMPLETE (Jan 7, 2026)
- Implemented: Created comprehensive test suite tests/integration/test_workstation_api.py (500+ lines):
  - 25 tests covering all workstation API endpoints
  - TestWorkstationProvisionEndpoint (4 tests) - provision success, default config, unauthenticated, error handling
  - TestWorkstationStartEndpoint (3 tests) - start success, unauthenticated, not found
  - TestWorkstationStopEndpoint (2 tests) - stop success, unauthenticated
  - TestWorkstationTokenEndpoint (3 tests) - token success, unauthenticated, stopped workstation
  - TestWorkstationStatusEndpoint (2 tests) - status success, unauthenticated
  - TestWorkstationConfigEndpoint (3 tests) - list configs, unauthenticated, only active configs
  - TestWorkstationModel (5 tests) - ID generation, unique per user, is_running property, start/end session
  - TestWorkstationSerializers (3 tests) - serializer output, provision request validation
- Patterns: AsyncMock for GCP broker, pytest-mock fixtures, django_db marker
- Dependencies: Installed pytest-mock package for mocker fixture
A.11.5.2: E2E test: Purchase → Workstation → IDE access
- Agent: Task(subagent_type="testing-specialist", prompt="Create Playwright E2E test: complete checkout → wait for webhook → verify workstation created → click Launch IDE → verify IDE loads")
- Stripe test mode checkout
- Wait for webhook processing
- Verify workstation appears in dashboard
- Click "Launch IDE" → verify IDE loads
A.11.5.3: Frontend WorkstationCard component ✅ COMPLETE (Jan 7, 2026)
- Implemented: Created complete workstation UI system:
  - src/types/workstation.ts (160 lines) - TypeScript types for Workstation, WorkstationConfig, status helpers
  - src/services/workstation.service.ts (190 lines) - API client for provision, start, stop, token, polling
  - src/components/workstations/WorkstationCard.tsx (380 lines) - Full card with compact/expanded views
- Features: Status indicators (CREATING/STARTING/RUNNING/STOPPING/STOPPED/ERROR), tier badges, specs display, action buttons with loading states, error messages
- Show: status (provisioning/running/stopped)
- Buttons: Start, Stop, Launch IDE
- Link: access_url opens IDE in new tab

Dependencies:

A.3 (License model) ✅ Complete
A.10 (Container Session API) - for workstation license validation
C.5 (Docker Registry) - for custom workstation image

Estimated Time: 40-60 hours (2-3 weeks)

A.12: Team & License Management ✅ 90%

Status: 90% Complete - Backend APIs and Frontend UI done, Testing pending (Jan 7, 2026) Goal: Enable org admins to invite team members and assign licenses Blocking: No longer blocking - A.12.1 and A.12.2 complete

Current Gap:

Org admin buys 10 licenses → ❌ Cannot invite team → ❌ Cannot assign licenses → Team blocked

After A.12:

Org admin buys 10 licenses → ✅ Invites team via email → ✅ Assigns licenses → ✅ Team accesses CODITECT

Files to Create/Modify:

backend/organizations/views.py (MODIFY) - Add invite endpoints
backend/organizations/serializers.py (MODIFY) - Add invite serializers
backend/organizations/models.py (MODIFY) - Add Invitation model
backend/licenses/views.py (MODIFY) - Add assignment endpoints
backend/licenses/serializers.py (MODIFY) - Add assignment serializers
frontend/src/pages/TeamManagement.tsx (NEW)
frontend/src/components/team/InviteUserModal.tsx (NEW)
frontend/src/components/team/TeamMembersList.tsx (NEW)
frontend/src/components/team/LicenseAssignment.tsx (NEW)

Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement Track A.12 Team & License Management: (1) invitation system with email; (2) license assignment to team members; (3) frontend team management page")

Tasks:

A.12.1: Invitation System (Week 1)

A.12.1.1: Create Invitation model
- Agent: Task(subagent_type="database-architect", prompt="Create Invitation(TenantModel) with email, role, invited_by, token, status, expires_at, accepted_at")
- Fields:
  - email = EmailField()
  - role = CharField(choices=['admin', 'member', 'viewer'])
  - invited_by = ForeignKey(User)
  - token = UUIDField(default=uuid4, unique=True)
  - status = CharField(choices=['pending', 'accepted', 'expired', 'revoked'])
  - expires_at = DateTimeField() - 7 days from creation
  - accepted_at = DateTimeField(null=True)
A.12.1.2: POST /api/v1/organizations/{org_id}/invites/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create InviteCreateView: validate org admin, create invitation, send email via SendGrid")
- Validate: User is org admin
- Create: Invitation with 7-day expiry
- Send: Email with invite link via SendGrid
- Return: invitation_id, email, expires_at
A.12.1.3: GET /api/v1/organizations/{org_id}/invites/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create InviteListView: list pending and recent invitations for org")
- Filter: Current org, status in ['pending', 'accepted']
- Return: List of invitations with status
A.12.1.4: DELETE /api/v1/organizations/{org_id}/invites/{id}/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create InviteRevokeView: revoke pending invitation")
- Validate: User is org admin, invitation is pending
- Update: status = 'revoked'
- Return: 204 No Content
A.12.1.5: POST /api/v1/invites/{token}/accept/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create InviteAcceptView: validate token, create user if needed, add to org membership")
- Validate: Token valid, not expired
- Create: User if doesn't exist (or link existing)
- Add: TenantMembership with invited role
- Update: invitation status = 'accepted'
- Return: Redirect to dashboard
A.12.1.6: Invite email template
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create SendGrid email template for team invitation with org name, inviter name, role, and accept button")
- Template: invitation.html
- Variables: org_name, inviter_name, role, accept_url

A.12.2: License Assignment (Week 1-2)

A.12.2.1: Create LicenseAssignment model (if not exists)
- Agent: Task(subagent_type="database-architect", prompt="Create LicenseAssignment model linking License to User with assigned_by, assigned_at")
- Fields:
  - license = ForeignKey(License)
  - user = ForeignKey(User)
  - assigned_by = ForeignKey(User, related_name='assignments_made')
  - assigned_at = DateTimeField(auto_now_add=True)
- Constraint: One user per license seat
A.12.2.2: POST /api/v1/licenses/{license_id}/assign/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create LicenseAssignView: validate org admin, check seats available, assign license to user")
- Validate: User is org admin, license belongs to org
- Check: Seats available (device_limit - assigned_count)
- Create: LicenseAssignment
- Return: assignment_id, user, license
A.12.2.3: DELETE /api/v1/licenses/{license_id}/assign/{user_id}/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create LicenseUnassignView: remove license assignment from user")
- Validate: User is org admin
- Delete: LicenseAssignment
- Terminate: Any active sessions for that user/license
- Return: 204 No Content
A.12.2.4: GET /api/v1/licenses/{license_id}/assignments/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create LicenseAssignmentListView: list users assigned to license")
- Return: List of users with assignment date

A.12.3: Frontend Team Management (Week 2) ✅ COMPLETE (Discovered Jan 7, 2026)

A.12.3.1: Create TeamManagement.tsx page ✅ PRE-EXISTING
- Already Implemented: Team management integrated into Dashboard.tsx and Profile.tsx pages
- Components use TeamMemberList from @/components/team
- Full CRUD functionality via useTeamMembers, useInviteMember, useUpdateMemberRole, useRemoveMember hooks
A.12.3.2: Create InviteUserModal.tsx ✅ PRE-EXISTING
- Already Implemented: src/components/team/InviteMemberModal.tsx (6.8KB)
- Form: email, role (admin/member/viewer/guest)
- Validation: Email format
- Uses teamService.inviteMember() API
A.12.3.3: Create TeamMembersList.tsx ✅ PRE-EXISTING
- Already Implemented: src/components/team/TeamMemberList.tsx (19.8KB)
- Features: Search, role badges (owner/admin/member/viewer/guest), role change dropdown, remove member
- Includes pending invitations display with resend/revoke
A.12.3.4: Create LicenseAssignment.tsx (Deferred)
- Deferred to post-pilot: License assignment UI exists in Admin.tsx
- Core functionality available via Commerce/License pages
A.12.3.5: Add Team link to navigation ✅ PRE-EXISTING
- Already Implemented: Team section visible in Dashboard sidebar
- src/services/team.service.ts (70 lines) - Full API client
- src/hooks/useTeamMembers.ts (86 lines) - React Query hooks

A.12.4: Testing (Week 2)

A.12.4.1: Unit tests for invitation endpoints
- Agent: Task(subagent_type="testing-specialist", prompt="Write pytest tests for invite create/list/revoke/accept endpoints")
- Test: Invite creates pending invitation
- Test: Accept adds user to org
- Test: Expired invite cannot be accepted
- Test: Non-admin cannot invite
A.12.4.2: Unit tests for license assignment endpoints
- Agent: Task(subagent_type="testing-specialist", prompt="Write pytest tests for license assign/unassign endpoints")
- Test: Assign creates assignment
- Test: Cannot exceed seat limit
- Test: Unassign removes assignment
A.12.4.3: E2E test: Admin invites user → User accepts → User gets license
- Agent: Task(subagent_type="testing-specialist", prompt="Create Playwright E2E test for full invitation flow")

Dependencies:

A.3 (License model) ✅ Complete
B.2 (Auth pages) ✅ Complete

Estimated Time: 24-32 hours (1-2 weeks)

A.13: System Administration - License & Workstation Override 🆕 (Jan 9, 2026)

Status: ✅ BACKEND COMPLETE - P0 (Critical for Pilot Customer Onboarding) Progress (Jan 9, 2026): A.13.1 (License Backend) 100% COMPLETE, A.13.2 (Workstation Admin) 100% COMPLETE, A.13.3 (Batch Provisioning) 100% COMPLETE. Admin can provision pilot customers AND workstations via API. Remaining: A.13.4 (UI), A.13.5 (Audit). Goal: Admin capability to provision licenses and Cloud Workstations without requiring customer payment Use Case: Pilot customers, trials, complimentary access, internal testing

Why Needed:

Pilot customers need Cloud Workstations without going through Stripe checkout
Internal testing requires license provisioning without payment
Complimentary/trial licenses for demos and evaluations
Manual override for special pricing arrangements

Architecture:

Admin Portal → System Admin API → License + Workstation Provisioning
                                      ↓
                               Skip Stripe Payment
                                      ↓
                               Auto-provision Workstation
                                      ↓
                               Send Welcome Email

Files to Create/Modify:

backend/admin_api/views.py (NEW) - System admin endpoints
backend/licenses/models.py (MODIFY) - Add provisioning_type field
backend/licenses/admin_service.py (NEW) - Admin provisioning logic
backend/workstations/admin_service.py (NEW) - Admin workstation provisioning
frontend/src/pages/Admin/SystemAdmin.tsx (NEW) - Admin UI

Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement Track A.13 System Administration Override: (1) admin endpoint to provision licenses without payment; (2) admin endpoint to provision workstations without payment; (3) provisioning_type field (paid, pilot, trial, comp, internal); (4) audit trail for admin actions; (5) simple admin UI for pilot customer onboarding")

Tasks:

A.13.1: License Provisioning Override (Backend)

A.13.1.1: Add provisioning_type field to License model
- Agent: Task(subagent_type="database-architect", prompt="Add provisioning_type CharField to License model with choices: paid, pilot, trial, comp, internal. Default='paid'. Add provisioned_by FK to User for admin provisioning.")
- Choices: paid (default), pilot, trial, comp (complimentary), internal
- provisioned_by = ForeignKey(User, null=True) - Admin who provisioned
- provisioning_notes = TextField(null=True) - Admin notes
A.13.1.2: POST /api/v1/admin/licenses/provision/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create AdminLicenseProvisionView: validate system admin role, create license with specified tier/duration without Stripe, set provisioning_type, log audit trail")
- Auth: Require is_superuser or system_admin role
- Payload: { email, tier, duration_days, provisioning_type, notes, auto_provision_workstation }
- Actions:
  1. Create/find user by email
  2. Create License with specified tier and expiry
  3. Set provisioning_type and provisioned_by
  4. Optionally trigger workstation auto-provision
  5. Send welcome email
- Return: { license_id, user_id, workstation_id (if provisioned) }
A.13.1.3: GET /api/v1/admin/licenses/ endpoint (list admin-provisioned)
- Agent: Task(subagent_type="senior-architect", prompt="Create AdminLicenseListView: list all licenses with provisioning_type != 'paid', filterable by type")
- Filter by provisioning_type
- Show: email, tier, type, provisioned_by, created_at, expires_at
A.13.1.4: POST /api/v1/admin/licenses/{id}/extend/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create AdminLicenseExtendView: extend license expiry by specified days, log reason")
- Payload: { days, reason }
- Update expiry_date
- Log in audit trail
A.13.1.5: POST /api/v1/admin/licenses/{id}/revoke/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create AdminLicenseRevokeView: revoke license, terminate sessions, optionally delete workstation")
- Terminate all active sessions
- Mark license inactive
- Optionally delete workstation

A.13.2: Workstation Provisioning Override (Backend)

A.13.2.1: POST /api/v1/admin/workstations/provision/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create AdminWorkstationProvisionView: provision Cloud Workstation for user without license payment check")
- Auth: Require system admin
- Payload: { user_email, config_tier, license_id (optional) }
- Actions:
  1. Find/create user
  2. Create workstation via GCP API (reuse A.11 broker)
  3. Link to license if provided
  4. Send access email
- Return: { workstation_id, access_url }
A.13.2.2: GET /api/v1/admin/workstations/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create AdminWorkstationListView: list all workstations with user, license, status, config tier")
- Show: user email, license, status, config, created_at, last_accessed
A.13.2.3: POST /api/v1/admin/workstations/{id}/delete/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create AdminWorkstationDeleteView: delete workstation via GCP API, cleanup records")
- Delete from GCP
- Mark record as deleted
- Log audit trail

A.13.3: Pilot Customer Batch Provisioning

A.13.3.1: POST /api/v1/admin/pilot/batch-provision/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create PilotBatchProvisionView: provision multiple pilot customers from CSV/JSON with license + workstation in one call")
- Payload: { customers: [{ email, name, tier, duration_days }], send_emails: true }
- For each customer:
  1. Create user if not exists
  2. Create license (provisioning_type='pilot')
  3. Provision workstation
  4. Queue welcome email
- Return: { success: [], failed: [], total: N }
A.13.3.2: GET /api/v1/admin/pilot/customers/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create PilotCustomerListView: list all pilot customers with license and workstation status")
- Completed: Jan 9, 2026 - Created AdminPilotCustomerListView with filtering by provisioning_type, status, search. Includes workstation and session count info.

A.13.4: Admin UI (Frontend) ✅ COMPLETE (Jan 9, 2026)

A.13.4.1: Create SystemAdmin.tsx page
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create SystemAdmin page with tabs: Pilot Customers, Licenses, Workstations. Include provision forms and list tables.")
- Route: /admin/system
- Tabs: Pilot Customers | Licenses | Workstations
- Require: is_superuser or system_admin role
A.13.4.2: Create PilotProvisionForm.tsx component
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create PilotProvisionForm for single pilot customer: email, name, tier dropdown, duration, checkbox for auto-provision workstation")
- Fields: email, name, tier (dropdown), duration_days, auto_provision_workstation (checkbox)
- Submit: Call /admin/licenses/provision/
A.13.4.3: Create BatchProvisionUpload.tsx component
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create BatchProvisionUpload for CSV upload of pilot customers with preview table and provision button")
- Upload: CSV with columns (email, name, tier, duration_days)
- Preview: Table showing parsed data
- Submit: Call /admin/pilot/batch-provision/
A.13.4.4: Create AdminLicenseTable.tsx component
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create AdminLicenseTable showing all admin-provisioned licenses with actions: extend, revoke")
- Columns: Email, Tier, Type, Status, Expires, Provisioned By, Actions
- Actions: Extend, Revoke
A.13.4.5: Add System Admin link to navigation (superuser only)
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Add System Admin link to sidebar navigation, visible only to superusers")
- Conditional render based on user.is_superuser

A.13.5: Audit & Security ✅ COMPLETE (Jan 9, 2026)

A.13.5.1: Create AdminAuditLog model
- Agent: Task(subagent_type="database-architect", prompt="Create AdminAuditLog model: admin FK, action, target_type, target_id, details JSON, ip_address, timestamp")
- Status: EXISTING - AuditLog model already in licenses/models.py with organization, user, action, resource_type, resource_id, metadata, created_at fields
- Track all admin provisioning actions
- Immutable (no update/delete)
A.13.5.2: Log all admin actions to audit trail
- Agent: Task(subagent_type="senior-architect", prompt="Add audit logging to all A.13 admin endpoints via decorator or middleware")
- Status: EXISTING - Admin views already log to AuditLog via AuditLog.objects.create() calls
A.13.5.3: GET /api/v1/admin/audit-log/ endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create AdminAuditLogView: list audit log entries, filterable by action type, admin, date range")
- Status: COMPLETE - AdminAuditLogListView in api/v1/views/admin.py with filtering by action, resource_type, user_email, organization_id, from_date, to_date
- URL: path('admin/audit-log/', AdminAuditLogListView.as_view(), name='admin-audit-log')

Dependencies:

A.11 (Workstation Broker) ✅ Complete
A.12 (Team Management) ✅ Complete

Related ADRs:

ADR-061: Provisioning Strategies - License & Workstation (created Jan 9, 2026)

Estimated Time: 20-28 hours

Track B: Frontend Build

Repository: submodules/cloud/coditect-cloud-frontend/ Isolation Boundary: All /frontend/ code and static assets No Collision With: Tracks A, D, F (different repos) Depends On: Track A (backend APIs must exist)

B.1: Project Setup Enhancement

Files to Verify/Update:

package.json
vite.config.ts
tailwind.config.js
tsconfig.json

Tasks:

B.1.1: Verify React 18 + TypeScript strict mode
B.1.2: Configure Vite build optimizations
B.1.3: Set up API client with axios interceptors
B.1.4: Configure React Query for server state
B.1.5: Set up React Router v6 with protected routes

Estimated Time: 2-3 hours

B.2: Authentication Pages

Files to Create:

src/pages/Landing.tsx
src/pages/Register.tsx
src/pages/Login.tsx
src/pages/VerifyEmail.tsx
src/components/auth/RegisterForm.tsx
src/components/auth/LoginForm.tsx
src/hooks/useAuth.ts
src/services/authService.ts

Tasks:

B.2.1: Landing page with hero, features, pricing table, CTA ✅
B.2.2: Register page with form validation (email, password, name, company) ✅
B.2.3: Login page with JWT token handling (+ 2FA support) ✅
B.2.4: Email verification callback page ✅ (Jan 8, 2026 - EmailVerification.tsx)
B.2.5: Auth context/provider for global auth state ✅ (authService + localStorage)
B.2.6: Protected route wrapper component ✅ (ProtectedRoute.tsx)

Estimated Time: 12-16 hours

B.3: Commerce & Multi-Product Checkout

Architecture Reference: ADR-014, SDD Section 4.2.1, TDD Sections 6.1.7-6.1.10 Process Documentation: CHECKOUT-PROCESS-DETAILED.md - Complete end-to-end checkout flow

Files to Create:

src/pages/Pricing.tsx
src/components/products/ProductCatalog.tsx
src/components/products/ProductCard.tsx
src/components/cart/ShoppingCart.tsx
src/components/cart/CartItem.tsx
src/components/cart/CartSummary.tsx
src/components/checkout/GooglePayButton.tsx
src/components/checkout/StripeCheckout.tsx
src/components/checkout/CheckoutSuccess.tsx
src/hooks/useCart.ts
src/hooks/useProducts.ts
src/hooks/useEntitlements.ts
src/services/commerceService.ts
src/types/commerce.ts

Backend API Requirements (Track A):

GET /api/v1/products - List all products
POST /api/v1/cart/items - Add to cart
GET /api/v1/cart - Get cart
DELETE /api/v1/cart/items/{id} - Remove from cart
POST /api/v1/checkout - Initiate checkout
POST /api/v1/checkout/google-pay - Google Pay token
POST /api/v1/webhooks/stripe - Stripe webhook
GET /api/v1/entitlements - User entitlements

Tasks:

B.3.1: Product Catalog ✅ COMPLETE

B.3.1.1: ProductCatalog component with grid layout ✅ (Dec 31, 2025)
B.3.1.2: ProductCard with name, price, features, "Add to Cart" ✅ (Dec 31, 2025)
B.3.1.3: Product type badges (base, addon, bundle) ✅ (Dec 31, 2025)
B.3.1.4: Product dependency display (requires field in ProductCard) ✅ (Dec 31, 2025)
B.3.1.5: useProducts hook with React Query ✅ (Dec 31, 2025)

B.3.2: Shopping Cart ✅ COMPLETE

B.3.2.1: ShoppingCart sidebar component ✅ (Dec 31, 2025)
B.3.2.2: CartItem with quantity, remove button ✅ (Dec 31, 2025)
B.3.2.3: CartSummary with subtotal, total ✅ (Dec 31, 2025)
B.3.2.4: Dependency validation (backend validates, frontend displays) ✅ (Dec 31, 2025)
B.3.2.5: useCart hook with local + API sync ✅ (Dec 31, 2025)
B.3.2.6: Cart persistence (useLocalCart + localStorage) ✅ (Dec 31, 2025)

B.3.3: Dual Payment Integration ✅ COMPLETE

B.3.3.1: GooglePayButton with Payment Request API ✅ (Dec 31, 2025)
B.3.3.2: Google Pay availability detection ✅ (Dec 31, 2025)
B.3.3.3: StripeCheckout component (redirect + embedded) ✅ (Dec 31, 2025)
B.3.3.4: Payment method selection UI (Checkout.tsx page) ✅ (Dec 31, 2025)
B.3.3.5: CheckoutSuccess page with order confirmation ✅ (Dec 31, 2025)
B.3.3.6: Payment error handling and retry ✅ (Dec 31, 2025)

B.3.4: Entitlement Display

Agent Invocation:

Task(subagent_type="frontend-react-typescript-expert", prompt="Implement B.3.4 Entitlement Display in submodules/cloud/coditect-cloud-frontend/: (1) product access badges in dashboard showing active entitlements; (2) subdomain links to dms.coditect.ai and workflow.coditect.ai for entitled products; (3) upgrade/add product CTAs for non-entitled products")

B.3.4.1: useEntitlements hook ✅ (Dec 31, 2025)
B.3.4.2: Product access badges in dashboard ✅ (Jan 7, 2026) - EntitlementBadge.tsx + ProductAccessCard.tsx
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create EntitlementBadge component showing product access status in Dashboard.tsx")
B.3.4.3: Subdomain links (dms.coditect.ai, workflow.coditect.ai) ✅ (Jan 7, 2026) - Added PRODUCT_URLS to EntitlementsList.tsx
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Add subdomain links in dashboard for entitled products - dms.coditect.ai, workflow.coditect.ai")
B.3.4.4: Upgrade/add product CTAs ✅ (Jan 7, 2026) - ProductAccessCard.tsx with upgrade/renew CTAs
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create UpgradeProductCTA component for non-entitled products linking to /pricing")

CODITECT Products:

Product	Slug	Type	Price	Subdomain
CODITECT Core	`core`	base	$49/mo	-
CODITECT DMS	`dms`	addon	$29/mo	dms.coditect.ai
Workflow Analyzer	`workflow`	addon	$19/mo	workflow.coditect.ai
Enterprise Bundle	`enterprise`	bundle	$149/mo	All products

Estimated Time: 16-20 hours

B.4: Dashboard & License Management

Files to Create:

src/pages/Dashboard.tsx
src/components/dashboard/LicenseCard.tsx
src/components/dashboard/SessionManager.tsx
src/components/dashboard/LicenseDownload.tsx
src/services/licenseService.ts

Tasks:

Estimated Time: 12-16 hours

B.5: Shared Components & Styling ✅ COMPLETE

Status: ✅ COMPLETE (Jan 8, 2026)

Files Created:

src/components/ui/Button.tsx - Button component with variants (primary/secondary/outline/ghost/danger/link), sizes, loading state
src/components/ui/Input.tsx - Input and Textarea components with labels, errors, icons
src/components/ui/Card.tsx - Card component with CardHeader, CardTitle, CardDescription, CardContent, CardFooter
src/components/ui/Modal.tsx - Modal with ModalHeader, ModalBody, ModalFooter, ConfirmModal helper
src/components/ui/Badge.tsx - Badge and DotBadge for status indicators
src/components/ui/Spinner.tsx - Spinner, LoadingOverlay, LoadingPlaceholder
src/components/ui/index.ts - Unified exports
src/lib/utils.ts - cn() utility for Tailwind class merging

Pre-existing Components Verified:

src/components/Layout.tsx - Header, Footer, mobile responsive menu
src/components/ui/Tabs.tsx - Tab components
src/components/ui/CollapsibleCard.tsx - Collapsible card variant
src/hooks/useDarkMode.ts - Dark mode with localStorage + cross-subdomain sync
tailwind.config.js - Primary brand colors (sky blue), Inter + JetBrains Mono fonts

Tasks:

B.5.1: Design system components (Button, Input, Card, Modal) ✅ (Jan 8, 2026)
B.5.2: Layout components (Header, Footer, Sidebar) ✅ PRE-EXISTING
B.5.3: AZ1.AI brand colors and typography ✅ PRE-EXISTING
B.5.4: Dark mode support ✅ PRE-EXISTING (useDarkMode hook)
B.5.5: Mobile responsive design (320px - 1920px+) ✅ PRE-EXISTING

Dependencies Added: clsx, tailwind-merge (for cn() utility)

B.6: Dark Mode & UI Polish

Status: ✅ COMPLETE (Dec 30, 2025)

Tasks Completed:

B.6.1: Dark mode toggle in header
B.6.2: localStorage persistence for dark mode preference
B.6.3: Pre-React inline script to prevent flash
B.6.4: Landing page dark mode support (all sections)
B.6.5: Pricing page dark mode support
B.6.6: Login/Register pages dark mode support
B.6.7: Dashboard dark mode support

B.7: Legal & Account Pages (P0 - BLOCKING)

Status: ✅ COMPLETE (Dec 30, 2025)

Architecture Reference: ADR-015-auth-coditect-ai-website-architecture.md Task Reference: WEBSITE-CONTENT-tasklist.md

Files Created:

src/pages/Privacy.tsx ✅
src/pages/Terms.tsx ✅
src/pages/ForgotPassword.tsx ✅
src/components/templates/LegalPageLayout.tsx ✅ (reusable template)
src/components/templates/FormPageLayout.tsx ✅ (reusable template)

Tasks Completed:

B.7.1: Privacy Policy Page (`/privacy`)

B.7.1.1: Create Privacy.tsx component ✅
B.7.1.2: Add route to App.tsx ✅
B.7.1.3: Content: Data collection, usage, user rights (GDPR/CCPA) ✅
B.7.1.4: Dark mode support ✅
B.7.1.5: Legal review approval (PENDING - awaiting legal)

B.7.2: Terms of Service Page (`/terms`)

B.7.2.1: Create Terms.tsx component ✅
B.7.2.2: Add route to App.tsx ✅
B.7.2.3: Content: Service agreement, liability, IP ✅
B.7.2.4: Dark mode support ✅
B.7.2.5: Legal review approval (PENDING - awaiting legal)

B.7.3: Forgot Password Page (`/forgot-password`) ✅ COMPLETE (Jan 8, 2026)

B.7.3.1: Create ForgotPassword.tsx component ✅
B.7.3.2: Add route to App.tsx ✅
B.7.3.3: Email form with validation ✅
B.7.3.4: Success/error states ✅
B.7.3.5: API integration with backend reset endpoint ✅
B.7.3.6: Dark mode support ✅
B.7.3.7: Create ResetPassword.tsx component ✅ (Jan 8, 2026)
- Commit: 185084c
- Password strength indicators (length, uppercase, lowercase, number)
- Show/hide password toggles
- Token validation with error handling
- Route at /reset-password

Actual Time: ~5 hours (vs 10 estimated - reusable templates accelerated development)

B.8: Product & Company Pages (P1 - Pre-Launch)

Status: ✅ COMPLETE (Dec 30, 2025)

Files Created:

src/pages/Docs.tsx ✅
src/pages/About.tsx ✅
src/pages/Security.tsx ✅
src/components/templates/StaticPageLayout.tsx ✅ (reusable template)
src/components/templates/CompanyPageLayout.tsx ✅ (reusable template)
src/components/templates/ProductLandingLayout.tsx ✅ (reusable template for DMS/Workflow sites)

Tasks Completed:

B.8.1: Documentation Hub (`/docs`)

B.8.1.1: Create Docs.tsx component ✅
B.8.1.2: Add route to App.tsx ✅
B.8.1.3: Quick start links + redirect to docs.coditect.ai ✅
B.8.1.4: Dark mode support ✅

B.8.2: About Page (`/about`)

B.8.2.1: Create About.tsx component ✅
B.8.2.2: Add route to App.tsx ✅
B.8.2.3: Content: Mission, problem, solution, leadership ✅
B.8.2.4: Hal Casteel founder bio ✅
B.8.2.5: Company values section (6 values) ✅
B.8.2.6: Dark mode support ✅

B.8.3: Security Page (`/security`)

B.8.3.1: Create Security.tsx component ✅
B.8.3.2: Add route to App.tsx ✅
B.8.3.3: Content: Encryption, access control, audit logging ✅
B.8.3.4: GCP infrastructure trust signals ✅
B.8.3.5: Responsible disclosure contact ✅
B.8.3.6: Dark mode support ✅

Actual Time: ~3 hours (vs 10 estimated - reusable templates accelerated development)

B.9: Post-Launch Pages (P2)

Status: ✅ COMPLETE (Dec 30, 2025)

Files Created:

src/pages/Changelog.tsx ✅
src/components/templates/PageHeader.tsx ✅ (reusable header component)
src/components/templates/index.ts ✅ (barrel export)

Tasks Completed:

B.9.1: Changelog Page (`/changelog`)

B.9.1.1: Create Changelog.tsx component ✅
B.9.1.2: Add route to App.tsx ✅
B.9.1.3: Version + date timeline format ✅
B.9.1.4: Features, improvements, bug fixes sections ✅
B.9.1.5: "Coming soon" preview section ✅
B.9.1.6: Dark mode support ✅

Notes: Includes 5 releases documented (v1.0.0 - v1.4.3) with release type badges (major, minor, patch).

Actual Time: ~1 hour (vs 4 estimated - reusable templates accelerated development)

B.10: Future Pages (P3)

Files to Create:

src/pages/Careers.tsx ✅

Tasks:

B.10.1: Careers Page (`/careers`) ✅ COMPLETE (Jan 08, 2026)

B.10.1.1: Create Careers.tsx component ✅
B.10.1.2: Add route to App.tsx ✅
B.10.1.3: Culture description ✅
B.10.1.4: Contact email for applications (careers@coditect.ai) ✅
B.10.1.5: Dark mode support ✅

Features:

6 value cards (Ship Fast, AI-First, Small Team, Remote-First, Customer Obsession, Bias for Action)
Culture section with company description
Open positions section (currently not hiring)
Contact CTA with careers@coditect.ai
Full dark mode support
Commit: a69eec7 (coditect-cloud-frontend)

Estimated Time: 2 hours | Actual: ~30 min (reusable templates)

B.11: Reusable Page Templates (BONUS)

Status: ✅ COMPLETE (Dec 30, 2025)

Architecture Achievement: Created reusable template system that accelerated B.7-B.9 by 60% (8 hours vs 24 estimated).

Templates Created:

Template	Purpose	Used By
`PageHeader.tsx`	Consistent page headers with badge, title, subtitle	All pages
`StaticPageLayout.tsx`	Content pages with prose styling	Security.tsx
`LegalPageLayout.tsx`	Legal documents with TOC	Privacy.tsx, Terms.tsx
`ProductLandingLayout.tsx`	Product marketing pages	DMS, Workflow sites (future)
`CompanyPageLayout.tsx`	Company pages with mission/team/values	About.tsx
`FormPageLayout.tsx`	Authentication/account forms	ForgotPassword.tsx

Files Created:

src/components/templates/PageHeader.tsx ✅
src/components/templates/StaticPageLayout.tsx ✅
src/components/templates/LegalPageLayout.tsx ✅
src/components/templates/ProductLandingLayout.tsx ✅
src/components/templates/CompanyPageLayout.tsx ✅
src/components/templates/FormPageLayout.tsx ✅
src/components/templates/index.ts ✅

Benefits:

Dark mode support built-in to all templates
Consistent visual language across all pages
Rapid page creation for future content
Ready for DMS and Workflow product sites

Tasks Completed:

B.11.1: Create PageHeader reusable component ✅
B.11.2: Create StaticPageLayout for content pages ✅
B.11.3: Create LegalPageLayout with TOC generation ✅
B.11.4: Create ProductLandingLayout for product sites ✅
B.11.5: Create CompanyPageLayout with team/values sections ✅
B.11.6: Create FormPageLayout with form helpers ✅
B.11.7: Create barrel export index.ts ✅

B.12: Design System Compliance & @coditect/ui Package

Status: NEW (Dec 31, 2025)

Reference Documents:

ui-design-system.md - Complete design system (920+ lines)
adr-002-coditect-unified-design-system.md - Architecture decision

Audit Results: 93% compliant (Dec 31, 2025)

Category	Compliance	Notes
Colors	100%	Primary #0ea5e9 matches exactly
Dark Mode	100%	Class-based toggle working
Layout	100%	Header h-16, footer grid correct
Typography	90%	Uses Inter vs pure system fonts
Components	90%	rounded-lg vs rounded-md, missing focus-offset-2
Icons	80%	Inline SVGs vs Lucide React

Files to Modify:

src/index.css (UPDATE) - Fix component classes
tailwind.config.js (UPDATE) - Adjust font stack if needed
src/components/**/*.tsx (UPDATE) - Add focus:ring-offset-2

Tasks:

B.12.1: Fix Minor Discrepancies (P1)

B.12.1.1: Add focus:ring-offset-2 to all button classes in src/index.css ✅ (Dec 31, 2025)
B.12.1.2: Update border radius from rounded-lg to rounded-md per style guide ✅ (Dec 31, 2025)
B.12.1.3: Document Inter font as intentional brand choice (not system fonts) ✅ (Dec 31, 2025)
B.12.1.4: Test all components for visual consistency

B.12.2: Icon Migration (P2) ✅ COMPLETE

B.12.2.1: Install lucide-react package ✅ (Dec 31, 2025)
B.12.2.2: Use direct Lucide imports (wrapper not needed) ✅ (Dec 31, 2025)
B.12.2.3: Replace inline SVGs with Lucide icons (all pages complete) ✅ (Dec 31, 2025)
B.12.2.4: Verify all icons render correctly in light/dark mode ✅ (Dec 31, 2025)

B.12.3: @coditect/ui Package (P2) - Per ADR-002 ✅ COMPLETE (Jan 09, 2026)

Status: Created shared UI component library in coditect-cloud-frontend/packages/ui/

Package Contents:

7 component families: Button, Input/Textarea, Card (5 sub-components), Modal (6 sub-components + ConfirmModal), Badge/DotBadge, Spinner/LoadingOverlay/LoadingPlaceholder, Tabs (4 sub-components)
Tailwind preset (tailwind.preset.js) with CODITECT brand colors, typography, animations
Vite library mode build configuration (ES module + CommonJS + sourcemaps)
Full TypeScript types exported
cn() utility for class merging (clsx + tailwind-merge)
README with usage documentation
B.12.3.1: Create packages/ui/ directory structure ✅ (Jan 09, 2026)
B.12.3.2: Extract shared components (Button, Input, Card, Modal, Badge, Spinner, Tabs) ✅ (Jan 09, 2026)
B.12.3.3: Create @coditect/tailwind-config preset (tailwind.preset.js) ✅ (Jan 09, 2026)
B.12.3.4: Set up package.json with proper exports (ESM/CJS) ✅ (Jan 09, 2026)
B.12.3.5: Add build configuration (Vite library mode) ✅ (Jan 09, 2026)
B.12.3.6: Write component documentation (README.md) ✅ (Jan 09, 2026)
B.12.3.7: Publish to npm registry (optional - package ready, publish when needed)

B.12.4: Apply Style Guide to docs.coditect.ai (P1) ✅ COMPLETE

Status: COMPLETE (January 1, 2026) Live URL: https://docs-coditect-374018874256.us-central1.run.app

Agent Invocation:

Task(subagent_type="frontend-react-typescript-expert", prompt="Apply CODITECT style guide to docs.coditect.ai: (1) configure Tailwind with brand colors; (2) add dark mode support; (3) create consistent header/footer matching auth.coditect.ai; (4) test style guide compliance")

Files Created/Modified:

docs-site/src/index.css - Added @theme block with primary color palette (Tailwind CSS v4)
docs-site/src/components/Layout.tsx - Created shared Layout with header, footer, dark mode toggle
docs-site/src/pages/DocsHome.tsx - Updated with dark mode classes, icons, improved design
docs-site/src/pages/DocPage.tsx - Updated with dark mode classes, breadcrumbs
docs-site/index.html - Added Inter + JetBrains Mono fonts, dark mode inline script
docs-site/tailwind.config.js - Added font families (kept for reference, v4 uses @theme)

Tasks:

B.12.4.1: Configure Tailwind with CODITECT colors in docs-site ✅ (Jan 1, 2026)
- Added primary color palette using Tailwind CSS v4 @theme syntax
- Configured Inter and JetBrains Mono fonts
B.12.4.2: Apply dark mode support to docs-site ✅ (Jan 1, 2026)
- Dark mode toggle with localStorage persistence
- Inline script to prevent flash of wrong theme
- Default to dark mode (matching auth.coditect.ai)
B.12.4.3: Create consistent header/footer matching auth.coditect.ai ✅ (Jan 1, 2026)
- Fixed header with nav links and mobile menu
- Fixed compact footer with copyright and links
- Dark mode toggle button in header
B.12.4.4: Deploy updated docs-site v1.1.0 to Cloud Run ✅ (Jan 1, 2026)
- Built with docker buildx --platform linux/amd64
- Deployed to coditect-cloud-infra project

Completed: January 1, 2026 (4 hours actual)

B.12.5: docs.coditect.ai Content Pages (P1) - WIP

Status: 🚧 Work In Progress (Jan 2, 2026) Repository: submodules/cloud/coditect-cloud-infra/docs-site/ Goal: Create comprehensive documentation content for docs.coditect.ai

Agent Invocation:

Task(subagent_type="codi-documentation-writer", prompt="Create comprehensive documentation content for docs.coditect.ai: (1) Getting Started guide with quickstart, installation, and first steps; (2) API Reference with endpoint documentation; (3) User Guides for common workflows; (4) Integration guides for third-party services; (5) FAQ and troubleshooting")

Tasks:

B.12.5.1: Getting Started Guide
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create Getting Started guide for CODITECT: quickstart, installation, account setup, first project")
- Content: Installation, account setup, first project, quickstart tutorial
B.12.5.2: API Reference Documentation
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create API Reference for CODITECT: authentication endpoints, license management, commerce APIs")
- Content: Authentication, licenses, commerce, webhooks, rate limits
B.12.5.3: User Guides
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create User Guides for CODITECT: license management, billing, team administration")
- Content: License management, billing, team admin, settings
B.12.5.4: Integration Guides
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create Integration Guides: Stripe payments, Google Cloud, CI/CD pipelines")
- Content: Stripe, Google Cloud, CI/CD, SDKs
B.12.5.5: FAQ and Troubleshooting
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create FAQ and Troubleshooting guide for common issues and questions")
- Content: Common issues, error codes, support contact

Estimated Time: 8-12 hours Priority: P1 - Required for pilot launch documentation

Track C: DevOps & Deployment

Repository: submodules/cloud/coditect-cloud-infra/ Isolation Boundary: Infrastructure, K8s manifests, CI/CD No Collision With: Tracks A, B, D, F Depends On: Track A (backend), Track B (frontend containers)

C.1: Backend Deployment

Files to Create/Modify:

kubernetes/backend/deployment.yaml
kubernetes/backend/service.yaml
kubernetes/backend/ingress.yaml
.github/workflows/deploy-backend.yaml

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Implement Track C.1 Backend Deployment in submodules/cloud/coditect-cloud-infra/: (1) create backend Docker image build with Cloud Build; (2) create GKE deployment manifest with HPA (min 2, max 10 replicas); (3) configure Service and Ingress for api.coditect.ai; (4) set up managed SSL certificate; (5) integrate Secret Manager for database credentials and API keys")

Tasks:

C.1.1: Backend Docker image build and push ✅ (verified Jan 2, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create Cloud Build config for Django backend Docker image with multi-stage build")
C.1.2: GKE deployment manifest with HPA ✅ (10 replicas running)
- Agent: Task(subagent_type="k8s-statefulset-specialist", prompt="Create GKE deployment manifest with HPA min 2, max 10 replicas, resource limits")
C.1.3: Service and Ingress for api.coditect.ai ✅ (136.110.222.220)
- Agent: Task(subagent_type="devops-engineer", prompt="Create Service and Ingress for api.coditect.ai with GCE ingress class")
C.1.4: SSL certificate configuration ✅ (coditect-api-cert Active)
- Agent: Task(subagent_type="devops-engineer", prompt="Configure Google-managed SSL certificate for api.coditect.ai")
C.1.5: Secret Manager integration ✅
- Agent: Task(subagent_type="security-specialist", prompt="Integrate GCP Secret Manager for database credentials, Stripe keys, JWT secrets")

Estimated Time: 6-8 hours Status: ✅ COMPLETE (verified Jan 2, 2026)

C.2: Frontend Deployment

Files to Create/Modify:

kubernetes/frontend/deployment.yaml
kubernetes/frontend/service.yaml
kubernetes/frontend/ingress.yaml
docker/frontend/Dockerfile
docker/frontend/nginx.conf
.github/workflows/deploy-frontend.yaml

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Implement Track C.2 Frontend Deployment in submodules/cloud/coditect-cloud-frontend/: (1) create multi-stage Dockerfile (Node build → Nginx serve); (2) create GKE deployment manifest; (3) configure Service and Ingress for auth.coditect.ai; (4) set up managed SSL certificate; (5) optional CDN with Cloud CDN")

Tasks:

C.2.1: Frontend Docker image (Node build → Nginx serve) ✅ (verified Jan 2, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create multi-stage Dockerfile for React frontend: npm build then Nginx serve")
C.2.2: GKE deployment manifest ✅ (2 replicas running)
- Agent: Task(subagent_type="devops-engineer", prompt="Create GKE deployment manifest for frontend with 2-5 replicas")
C.2.3: Service and Ingress for auth.coditect.ai ✅ (34.102.254.2)
- Agent: Task(subagent_type="devops-engineer", prompt="Create Service and Ingress for auth.coditect.ai with GCE ingress class")
C.2.4: SSL certificate for auth.coditect.ai ✅ (auth-coditect-ssl Active)
- Agent: Task(subagent_type="devops-engineer", prompt="Configure Google-managed SSL certificate for auth.coditect.ai")
C.2.5: CDN configuration (optional)
- Agent: Task(subagent_type="cloud-architect", prompt="Configure Cloud CDN for auth.coditect.ai static assets")

Estimated Time: 4-6 hours Status: ✅ COMPLETE (verified Jan 2, 2026) - CDN optional

C.3: DNS & Networking

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Implement Track C.3 DNS & Networking: (1) configure DNS A records for api.coditect.ai, auth.coditect.ai, coditect.ai pointing to GKE ingress IP; (2) verify SSL certificates are provisioned and valid; (3) test all endpoints externally with curl")

Tasks:

C.3.1: Configure DNS for api.coditect.ai ✅ Verified Jan 2
- Agent: Task(subagent_type="devops-engineer", prompt="Configure DNS A record for api.coditect.ai pointing to GKE ingress IP")
C.3.2: Configure DNS for auth.coditect.ai ✅ Verified Jan 2
- Agent: Task(subagent_type="devops-engineer", prompt="Configure DNS A record for auth.coditect.ai pointing to GKE ingress IP")
C.3.3: Configure DNS for coditect.ai (landing) ✅ Verified Jan 2
- Agent: Task(subagent_type="devops-engineer", prompt="Configure DNS A record for coditect.ai pointing to GKE ingress IP")
C.3.4: Verify SSL certificates working ✅ All Active (Jan 2)
- Agent: Task(subagent_type="devops-engineer", prompt="Verify Google-managed SSL certificates are Active for all domains")
C.3.5: Test all endpoints externally ✅ All responding (Jan 2)
- Agent: Task(subagent_type="testing-specialist", prompt="Test all endpoints externally: api.coditect.ai/health, auth.coditect.ai, coditect.ai")

Estimated Time: 2-3 hours Status: ✅ COMPLETE (verified Jan 2, 2026)

C.4: External Sites & Subdomains

Reference: EXTERNAL-LINKS-INVENTORY.md

Architecture: Product subdomains per ADR-014, customer flows per ADR-015 Appendix

Sites to Deploy:

Site	URL	Status	Priority
Documentation	https://docs.coditect.ai	PLANNED	P0
DMS Product	https://dms.coditect.ai	LIVE	-
Workflow Product	https://workflow.coditect.ai	PLANNED	P1

Tasks:

C.4.1: Documentation Site (docs.coditect.ai) - P0

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Deploy docs.coditect.ai: (1) build docs site from coditect-core/docs/ using Docusaurus or VitePress; (2) configure subdomain DNS; (3) deploy to Cloud Run; (4) configure SSL; (5) verify all docs links work")

C.4.1.1: Create docs site from coditect-core/docs/ - COMPLETE (2026-01-01)
- File: docs-site/ with React + Vite + Tailwind
- Components: DocsHome.tsx, DocPage.tsx, Dockerfile (Node 20), cloudbuild.yaml
- Build: Verified local npm build + Docker build succeeds
C.4.1.2: Configure docs.coditect.ai subdomain DNS ✅ COMPLETE (2026-01-02)
- Verified: Domain coditect.ai verified in GCP
- DNS: docs.coditect.ai resolving to Cloud Run
C.4.1.3: Deploy docs site to Cloud Run - COMPLETE (2026-01-01)
- URL: https://docs.coditect.ai (custom domain)
- Image: us-central1-docker.pkg.dev/coditect-cloud-infra/coditect-docker/docs-coditect:latest
C.4.1.4: Configure SSL certificate for docs.coditect.ai ✅ COMPLETE (2026-01-02)
- Verified: HTTPS working, HTTP/2 200 response
C.4.1.5: Verify all 11 docs.coditect.ai links in Docs.tsx work ✅ COMPLETE (2026-01-08)
- Verified: All 11 URLs return HTTP 200 (root + 4 quick links + 6 popular topics)

C.4.2: Workflow Product Site (workflow.coditect.ai) - P1

C.4.2.1: Configure workflow.coditect.ai subdomain DNS ✅ ALREADY CONFIGURED (verified Jan 08, 2026)
- DNS: workflow.coditect.ai → 34.54.33.106 (GKE Load Balancer)
- Status: HTTP 200 OK
C.4.2.2: Create workflow product landing page ✅ ALREADY DEPLOYED (verified Jan 08, 2026)
- App: Coditect AgentFlow Workflow Analyzer
- Source: submodules/labs/prototypes/coditect-labs-workflow/
- URL: https://workflow.coditect.ai
C.4.2.3: Configure SSL certificate for workflow.coditect.ai ✅ ALREADY CONFIGURED (verified Jan 08, 2026)
- Status: HTTPS working, valid certificate
C.4.2.4: Implement SSO redirect from useEntitlements.ts ✅ COMPLETE (2026-01-08)
- Hook: useEntitlements → redirectToProduct(), openProductInNewTab()
- Auth: JWT passed via sso_token query param with timestamp
- Security: Domain allowlist validation, entitlement check required
- Commit: 26b2644 (coditect-cloud-frontend)

C.4.3: Email Infrastructure ✅ RESOLVED (Jan 9, 2026)

✅ RESOLVED (Jan 09, 2026): Simplified email approach - all coditect.ai addresses configured as aliases forwarding to 1@az1.ai.

Solution: Email aliases to existing az1.ai Google Workspace

No dedicated Google Workspace needed for coditect.ai

All 15 addresses → 1@az1.ai forwarding

MX records point to az1.ai domain (already configured)

C.4.3.0: ~~BLOCKER~~ Configure email infrastructure for coditect.ai ✅ RESOLVED
- C.4.3.0.1-0.7: ✅ SIMPLIFIED - Email aliases to 1@az1.ai instead of dedicated Google Workspace
C.4.3.1: 1@az1.ai → 1@az1.ai alias ✅
C.4.3.2: privacy@coditect.ai → 1@az1.ai alias ✅
C.4.3.3: security@coditect.ai → 1@az1.ai alias ✅
C.4.3.4: pilot@coditect.ai → 1@az1.ai alias ✅
C.4.3.5: feedback@coditect.ai → 1@az1.ai alias ✅
C.4.3.6: All 15 email addresses configured as aliases ✅

Email Alias List (all → 1@az1.ai):

Critical (7): support@, privacy@, security@, legal@, noreply@, pilot@, feedback@
Secondary (8): admin@, developer@, release@, research@, team@, product@, ir@, business@

C.4.4: External Services

C.4.4.1: ~~Verify GitHub repo coditect-ai/coditect-core is public~~ N/A - Repo remains PRIVATE (not open source)
C.4.4.2: Configure GitHub organization settings ✅ COMPLETE (Jan 08, 2026)
- Profile: description, blog (coditect.ai), location (SF), company (AZ1.AI INC)
- Security: Dependabot alerts, secret scanning, push protection enabled
- ⚠️ Note: 2FA requirement needs manual enable via GitHub web UI
C.4.4.3: Set up GitHub Discussions for community support ✅ COMPLETE (Jan 08, 2026)

Estimated Time: 12-16 hours

C.5: Licensed Docker Registry Setup ✅

Status: ✅ 100% Complete (Jan 7, 2026) Critical Path: YES - Blocks A.11 (Workstation Broker) and all container deployments Goal: Private Docker registry with license-based access control ADR: ADR-017-licensed-docker-registry.md

Why URGENT (Jan 5 Assessment):

Without C.5, licensed users cannot pull Docker images
Blocks A.11 (Cloud Workstation Broker) which provisions workstations with licensed images
Blocks container-based deployment entirely
User flow breaks: Buy license → ❌ Cannot get container image → Stuck

Architecture Summary:

GCP Artifact Registry with license-gated access
Short-lived Docker pull tokens (24h expiration) tied to license status
Automatic token revocation on license expiration
Tiered access: Pro gets base images, Enterprise gets extended images

Files to Create/Modify:

opentofu/modules/artifact-registry/ (NEW) - Infrastructure as Code
backend/licenses/models.py (MODIFY) - Add DockerPullToken model
backend/licenses/docker_auth.py (NEW) - Docker token generation service
backend/licenses/views.py (MODIFY) - Add Docker auth endpoints
frontend/src/components/DockerTokenGenerator.tsx (NEW) - Dashboard UI

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Implement Track C.5 Licensed Docker Registry: (1) create GCP Artifact Registry for coditect Docker images; (2) implement Docker registry auth tied to license status; (3) create pull token generation API; (4) automate token revocation on license expiration")

Tasks:

C.5.1: GCP Artifact Registry setup
- Agent: Task(subagent_type="devops-engineer", prompt="Create Artifact Registry repository for coditect-core Docker images with proper IAM")
- Create us-docker.pkg.dev/coditect-cloud-infra/coditect-images
- Configure IAM for service accounts
- Set up image vulnerability scanning
C.5.2: Docker pull token generation API
- Agent: Task(subagent_type="senior-architect", prompt="Create API endpoint that generates short-lived Docker pull tokens for licensed users")
- POST /api/v1/licenses/{id}/docker-token/
- Validate license is active
- Generate GCP service account key or short-lived token
- Token expires in 24 hours (requires re-auth daily)
C.5.3: Docker login flow documentation
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create user guide for Docker login: get token from dashboard, docker login command")
- User visits dashboard → clicks "Get Docker Token"
- Runs: docker login -u _json_key -p "$(cat token.json)" us-docker.pkg.dev
- Document in docs.coditect.ai
C.5.4: Token revocation on license events
- Agent: Task(subagent_type="devops-engineer", prompt="Implement automatic Docker token revocation when license expires or is revoked")
- Webhook handler for license.expired, license.revoked events
- Revoke all Docker tokens for that license
- Log revocation for audit trail
C.5.5: Docker image versioning and tagging
- Agent: Task(subagent_type="devops-engineer", prompt="Set up Docker image CI/CD: build on release, tag with version, push to Artifact Registry")
- GitHub Actions workflow for image build
- Tag: coditect-core:latest, coditect-core:v1.0.0
- Multi-arch support (amd64, arm64)
C.5.6: License tier image access ✅ (Jan 5, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create tier-based Artifact Registry repositories")
- Created us-central1-docker.pkg.dev/coditect-cloud-infra/coditect-images (Pro tier)
- Created us-central1-docker.pkg.dev/coditect-cloud-infra/coditect-enterprise (Enterprise tier)
- Created docker-pull-dev service account with reader access to both repos
- License.get_docker_repositories() scopes access by tier (already implemented)

Estimated Time: 10-14 hours

C.6: Licensed Container Image Build (ADR-055)

Status: 🆕 Not Started (Jan 4, 2026) Goal: Build protected container images for Docker and Cloud Workstation deployments ADR: adr-055-licensed-docker-container-schema.md

Architecture Summary (ADR-055 v1.5.0):

Shared base image with unified protection model
Root-owned framework at /opt/coditect (444/555 permissions)
Non-root developer user (uid 1000) with full shell access
Same protection for Docker AND Cloud Workstations
No compilation - protection via environment lockdown

Protection Model:

┌─────────────────────────────────────────────────────────────┐
│  What Customer HAS          │  What Customer CANNOT Do      │
├─────────────────────────────┼───────────────────────────────┤
│  ✅ zsh/bash shell          │  ❌ Modify /opt/coditect      │
│  ✅ Dev tools (git,vim,curl)│  ❌ Delete framework files    │
│  ✅ Full Claude Code access │  ❌ Become root (no sudo)     │
│  ✅ Read framework files    │  ❌ chown/chmod protected     │
└─────────────────────────────┴───────────────────────────────┘

Files to Create/Modify:

distribution/base/Dockerfile.base (NEW) - Shared base with protection
distribution/base/scripts/entrypoint-base.sh (NEW) - Base entrypoint
distribution/base/scripts/healthcheck.sh (NEW) - Health check
distribution/base/scripts/welcome.sh (NEW) - Welcome message
distribution/licensed-docker/Dockerfile (NEW) - Docker-specific
distribution/licensed-docker/entrypoint.sh (NEW) - Docker entrypoint
distribution/licensed-docker/cloudbuild.yaml (NEW) - Cloud Build
distribution/licensed-workstation/Dockerfile (NEW) - Workstation-specific
distribution/licensed-workstation/entrypoint.sh (NEW) - Workstation entrypoint
distribution/licensed-workstation/cloudbuild.yaml (NEW) - Cloud Build
distribution/local-dev/ (MOVE) - Move existing docker/ here

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Implement Track C.6 Licensed Container Image Build per ADR-055: (1) create shared base Dockerfile with root-owned framework protection; (2) create Docker-specific and Workstation-specific Dockerfiles extending base; (3) implement license validation entrypoints; (4) set up Cloud Build pipelines for both images; (5) add security tests verifying protection model")

Tasks:

C.6.1: Shared Base Image Architecture

C.6.1.1: Create distribution directory structure ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution directory structure: base/, licensed-docker/, licensed-workstation/, local-dev/")
- Create: distribution/base/, distribution/base/scripts/, distribution/base/config/
- Create: distribution/licensed-docker/, distribution/licensed-workstation/
- Create: distribution/local-dev/ (for existing development Dockerfile)
C.6.1.2: Create base Dockerfile with protection model ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/base/Dockerfile.base with: Python 3.11-slim, Node.js 20, Claude Code, zsh/bash, dev tools, non-root developer user (uid 1000), /opt/coditect mount point for framework")
- Base: python:3.11-slim
- Install: Node.js 20 LTS, Claude Code, zsh, bash, git, vim, nano, curl, wget
- Create: developer user (uid 1000) with zsh shell
- Prepare: /opt/coditect mount point for framework
- NO sudo access
C.6.1.3: Create base entrypoint script ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/base/scripts/entrypoint-base.sh with: session validation, heartbeat startup, framework protection verification, graceful shutdown handler")
- Validate CODITECT_SESSION_TOKEN environment variable
- Start heartbeat background process
- Verify /opt/coditect owned by root
- Trap SIGTERM/SIGINT for graceful shutdown
- Release session on exit
C.6.1.4: Create healthcheck script ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/base/scripts/healthcheck.sh checking: Claude Code accessible, framework readable, heartbeat running, session valid")
- Check: claude --version works
- Check: /opt/coditect/CLAUDE.md readable
- Check: Heartbeat process running (if started)
- Check: Session token valid (API call)
C.6.1.5: Create welcome script ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/base/scripts/welcome.sh displaying: CODITECT banner, license tier, tenant info, quick start commands")
- Display CODITECT ASCII banner
- Show license tier and tenant
- Show quick start: claude, /orient
- Show workspace: /home/developer/workspace

C.6.2: Docker-Specific Image

C.6.2.1: Create Docker Dockerfile extending base ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/licensed-docker/Dockerfile extending base: copy coditect-core to /opt/coditect, set root ownership with 444/555 permissions, configure Docker-specific entrypoint")
- FROM base image
- COPY coditect-core/ to /opt/coditect/
- RUN chown -R root:root /opt/coditect
- RUN chmod -R 444 files, 555 directories
- ENTRYPOINT docker-specific entrypoint
C.6.2.2: Create Docker entrypoint ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/licensed-docker/entrypoint.sh: validate CODITECT_LICENSE_KEY env var, call license API for session token, set CODITECT_SESSION_TOKEN, call base entrypoint")
- Read CODITECT_LICENSE_KEY from environment
- Read CODITECT_API_URL (default: https://api.coditect.ai)
- POST /api/v1/sessions/validate with license_key, container_id
- On success: set CODITECT_SESSION_TOKEN, call base entrypoint
- On failure: exit with error message
C.6.2.3: Create Docker Compose for testing ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/licensed-docker/docker-compose.yml for local testing with license key injection and volume mounts")
- Service: coditect
- Environment: CODITECT_LICENSE_KEY, CODITECT_API_URL
- Volumes: workspace mount
- Ports: 3000, 8000, 8080
C.6.2.4: Create Cloud Build for Docker image ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/licensed-docker/cloudbuild.yaml: build base, build docker image, push to Artifact Registry with version tags")
- Step 1: Build base image
- Step 2: Build docker image FROM base
- Step 3: Push to us-central1-docker.pkg.dev/coditect-citus-prod/coditect-licensed/coditect-docker:$TAG
- Tags: latest, v$VERSION, $SHORT_SHA

C.6.3: Cloud Workstation-Specific Image

C.6.3.1: Create Workstation Dockerfile extending base
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/licensed-workstation/Dockerfile extending base: copy coditect-core, set root ownership, configure GCP metadata integration, workstation-specific entrypoint")
- FROM base image
- COPY coditect-core/ to /opt/coditect/
- RUN chown -R root:root /opt/coditect
- RUN chmod -R 444 files, 555 directories
- Install: GCP metadata client for service account
- ENTRYPOINT workstation-specific entrypoint
C.6.3.2: Create Workstation entrypoint
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/licensed-workstation/entrypoint.sh: get user identity from GCP metadata, validate with OAuth2, get session token, call base entrypoint")
- Get service account token from GCP metadata server
- Get user identity from workstation metadata
- POST /api/v1/sessions/validate with jwt_token, workstation_id
- On success: set CODITECT_SESSION_TOKEN, call base entrypoint
- On failure: show error, terminate workstation
C.6.3.3: Create Workstation config template
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/licensed-workstation/workstation-config.yaml template for GCP Workstations API with our container image, persistent disk, idle timeout")
- Container image: our licensed-workstation image
- Persistent directories: /home/developer/workspace
- Idle timeout: 30 minutes
- Max runtime: 12 hours
- Confidential compute: enabled
- Shielded VM: enabled
C.6.3.4: Create Cloud Build for Workstation image ✅ (Jan 4, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create distribution/licensed-workstation/cloudbuild.yaml: build base, build workstation image, push to Artifact Registry")
- Step 1: Build base image
- Step 2: Build workstation image FROM base
- Step 3: Push to us-central1-docker.pkg.dev/coditect-citus-prod/coditect-licensed/coditect-workstation:$TAG
- Tags: latest, v$VERSION, $SHORT_SHA

C.6.4: Framework Protection Implementation

C.6.4.1: Configure root ownership in build
- Agent: Task(subagent_type="devops-engineer", prompt="Ensure Cloud Build runs COPY and chmod as root, framework files owned by root:root with 444 (files) and 555 (directories) permissions")
- Verify COPY --chown=root:root works
- Verify find -type f -exec chmod 444
- Verify find -type d -exec chmod 555
- Test: developer user cannot write to /opt/coditect
C.6.4.2: Remove sudo from container
- Agent: Task(subagent_type="security-specialist", prompt="Verify no sudo, su, or privilege escalation tools in licensed containers. Remove if present.")
- Verify: which sudo returns nothing
- Verify: which su returns nothing or disabled
- Verify: developer user not in sudoers
- Verify: no SUID binaries that allow escalation
C.6.4.3: Create symlink for Claude Code discovery
- Agent: Task(subagent_type="devops-engineer", prompt="Create /home/developer/.coditect symlink pointing to /opt/coditect for Claude Code framework discovery")
- ln -s /opt/coditect /home/developer/.coditect
- Verify Claude Code can read agents/, commands/, skills/
- Verify CLAUDE.md is discoverable

C.6.5: Security Validation Tests

C.6.5.1: Create protection model test suite
- Agent: Task(subagent_type="testing-specialist", prompt="Create distribution/tests/test_protection_model.py with tests: developer cannot write to /opt/coditect, cannot chown, cannot chmod, cannot delete framework files")
- Test: touch /opt/coditect/test.txt fails with permission denied
- Test: rm /opt/coditect/CLAUDE.md fails with permission denied
- Test: chmod 777 /opt/coditect fails with operation not permitted
- Test: chown developer /opt/coditect fails with operation not permitted
C.6.5.2: Create Claude Code integration test
- Agent: Task(subagent_type="testing-specialist", prompt="Create distribution/tests/test_claude_code.py verifying Claude Code can read framework, execute commands, but user cannot modify via shell")
- Test: Claude Code can read /opt/coditect/agents/*.md
- Test: Claude Code can read /opt/coditect/CLAUDE.md
- Test: /home/developer/workspace is writable
- Test: Shell cannot write to /opt/coditect
C.6.5.3: Create license validation test
- Agent: Task(subagent_type="testing-specialist", prompt="Create distribution/tests/test_license_validation.py testing: valid license starts container, invalid license exits, expired license shows warning")
- Test: Valid license key → container starts, session token set
- Test: Invalid license key → container exits with error
- Test: Expired license → warning message, grace period
- Test: No license key → container exits immediately
C.6.5.4: Create heartbeat test
- Agent: Task(subagent_type="testing-specialist", prompt="Create distribution/tests/test_heartbeat.py testing: heartbeat process starts, sends periodic heartbeats, handles API failures gracefully")
- Test: Heartbeat process starts on container start
- Test: Heartbeat sends POST every 5 minutes
- Test: API 200 response → heartbeat continues
- Test: API 401/403 → warning logged, container continues with grace
- Test: API unreachable → offline grace period applies

C.6.6: CI/CD Integration

C.6.6.1: Create GitHub Actions workflow for image build
- Agent: Task(subagent_type="devops-engineer", prompt="Create .github/workflows/build-licensed-images.yml: on release, build and push both Docker and Workstation images to Artifact Registry")
- Trigger: on release publish
- Build: base image first
- Build: licensed-docker image
- Build: licensed-workstation image
- Push: both to Artifact Registry with version tags
- Notify: Slack/Discord on success/failure
C.6.6.2: Create image vulnerability scanning
- Agent: Task(subagent_type="security-specialist", prompt="Configure Artifact Registry vulnerability scanning for licensed images, fail build on HIGH/CRITICAL CVEs")
- Enable: Artifact Registry vulnerability scanning
- Policy: Block images with HIGH or CRITICAL CVEs
- Report: Generate vulnerability report on each build
- Alert: Notify security team on new CVEs
C.6.6.3: Create image signing with Docker Content Trust ✅ (Jan 5, 2026)
- Agent: Task(subagent_type="security-specialist", prompt="Set up Docker Content Trust signing for licensed images using Cloud KMS")
- Commit: f26cdcb2 - feat(distribution): Add Docker Content Trust image signing (C.6.6.3)

C.6.6.3.1: OpenTofu KMS Infrastructure

C.6.6.3.1.1: Add enable_image_signing variable to artifact-registry module
- Variable: enable_image_signing (bool, default: true)
- Variable: signing_key_rotation_days (number, default: 90)
- Variable: signing_key_protection_level (string, default: "HSM")
C.6.6.3.1.2: Create KMS keyring resource
- Resource: google_kms_key_ring.container_signing
- Name: coditect-container-signing
- Location: us-central1
C.6.6.3.1.3: Create asymmetric signing key
- Resource: google_kms_crypto_key.cosign_signing_key
- Algorithm: EC_SIGN_P384_SHA384 (ECDSA P-384)
- Protection: HSM (Hardware Security Module)
- Rotation: 90 days automatic
C.6.6.3.1.4: Add IAM bindings for Cloud Build
- cloudkms.signerVerifier → Cloud Build service account
- cloudkms.signerVerifier → Default Cloud Build service account
C.6.6.3.1.5: Add public key viewer IAM binding
- cloudkms.publicKeyViewer → allUsers
- Enables customers to verify signatures without authentication
C.6.6.3.1.6: Add KMS outputs to module
- Output: signing_key_id (full resource ID)
- Output: signing_key_name (gcpkms:// URI for Cosign)
- Output: signing_keyring_id (keyring resource ID)
- Output: cosign_verify_command (customer verification command)
- Output: public_key_url (https://coditect.ai/.well-known/cosign.pub)

C.6.6.3.2: GitHub Actions Cosign Integration

C.6.6.3.2.1: Add sign-images job to workflow
- Job: sign-images
- Runs after: build-base, build-docker, build-workstation
- Condition: github.event_name == 'release' || github.event.inputs.push == 'true'
C.6.6.3.2.2: Install Cosign in workflow
- Action: sigstore/cosign-installer@v3
- Version: v2.2.2
C.6.6.3.2.3: Sign base image by digest
- Command: cosign sign --key $COSIGN_KEY --yes $IMAGE@$DIGEST
- Key: gcpkms://projects/coditect-citus-prod/locations/us-central1/keyRings/coditect-container-signing/cryptoKeys/cosign-signing-key
C.6.6.3.2.4: Sign docker image by digest
- Same pattern as base image
- Uses digest from build-docker job output
C.6.6.3.2.5: Sign workstation image by digest
- Same pattern as base image
- Uses digest from build-workstation job output
C.6.6.3.2.6: Generate signing summary
- Lists all signed images with digests
- Provides verification command for customers
- Links to public key URL
C.6.6.3.2.7: Update summary job dependencies
- Added sign-images to summary job needs
- Added signature verification section to release summary

C.6.6.3.3: Customer Documentation

C.6.6.3.3.1: Add signature verification step to Quick Start
- Step 3 (new): Verify Image Signature (Recommended)
- Install cosign command (brew/manual)
- Verification command with KMS key URI
C.6.6.3.3.2: Add Image Signing section to Security Notes
- Explains Docker Content Trust (DCT)
- Table: Protection vs Threat Mitigated
- Commands for online and offline verification
C.6.6.3.3.3: Add signature verification troubleshooting
- Error: no matching signatures
- Solutions: version check, network, public key file
- Warning: Do NOT pull if verification fails

C.6.6.3.4: Verification Tests

C.6.6.3.4.1: Create test_signature_verification.sh
- File: distribution/tests/test_signature_verification.sh
- Tests: 10 signature verification tests
- Total: 83 → 93 tests in ADR-055 suite
C.6.6.3.4.2: Test cosign installation check
- Verifies cosign is installed
- Reports version
C.6.6.3.4.3: Test KMS key access
- Verifies can access KMS signing key
- Tests public key retrieval
C.6.6.3.4.4: Test key algorithm verification
- Verifies EC_SIGN_P384_SHA384 algorithm
- Checks HSM protection level
C.6.6.3.4.5: Test image signature verification
- Tests coditect-docker image signature
- Tests coditect-base image signature
- Tests coditect-workstation image signature
C.6.6.3.4.6: Test unsigned image rejection
- Verifies unsigned images are correctly rejected
- Uses known public unsigned image as test case

C.6.6.3.5: ADR-055 Updates

C.6.6.3.5.1: Add Docker Content Trust section to ADR-055
- Signing flow diagram (ASCII)
- Security value table (5 threats)
- Why REQUIRED rationale (5 points)
C.6.6.3.5.2: Add implementation code examples to ADR-055
- OpenTofu KMS setup code
- GitHub Actions Cosign code
- Customer verification command
C.6.6.3.5.3: Add cost analysis and ROI to ADR-055
- Cost: ~$2-5/month (KMS + operations)
- ROI: Enables 60%+ enterprise deals at $50K+
C.6.6.3.5.4: Update implementation status in ADR-055
- All 4 steps marked Complete
- Added implementation date: 2026-01-05
C.6.6.3.5.5: Update test count in ADR-055
- Updated: 83 → 93 tests
- Added test_signature_verification.sh to test table
C.6.6.3.5.6: Add positive consequences for image signing
- Added: Cryptographic signing enables enterprise compliance
- Added: Supply chain security prevents tampering

C.6.7: Local Development Dockerfile Migration

C.6.7.1: Move existing docker/ to local-dev/
- Agent: Task(subagent_type="devops-engineer", prompt="Move distribution/docker/* to distribution/local-dev/, update paths in documentation")
- Move: Dockerfile, Dockerfile.lean, Dockerfile.chainguard
- Move: entrypoint.sh and related scripts
- Update: README.md with new paths
- Update: Any CI/CD referencing old paths
C.6.7.2: Update local-dev README
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create distribution/local-dev/README.md explaining this is for INTERNAL development only, not customer deployment")
- Clarify: This is for CODITECT team development
- Clarify: Customers use licensed-docker or licensed-workstation
- Document: Build and run instructions for developers

C.6.8: Documentation

C.6.8.1: Create distribution README
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create distribution/README.md explaining the layered architecture: base/, licensed-docker/, licensed-workstation/, local-dev/")
- Explain: Layered architecture and why
- Explain: Protection model (ADR-055)
- Document: Build process for each image
- Link: ADR-055 for full details
C.6.8.2: Update ADR-055 with implementation paths
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Update ADR-055 Implementation Checklist with actual file paths from distribution/")
- Add: File paths for each Dockerfile
- Add: Cloud Build paths
- Add: Test file paths
- Mark: Completed items as implementation progresses
C.6.8.3: Create customer Docker deployment guide
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create docs/guides/DOCKER-DEPLOYMENT-GUIDE.md for customers: get license, get pull token, docker pull, docker run with license key")
- Step 1: Purchase license from coditect.ai
- Step 2: Get Docker pull token from dashboard
- Step 3: docker login to Artifact Registry
- Step 4: docker pull coditect-docker image
- Step 5: docker run with CODITECT_LICENSE_KEY
- Troubleshooting section

Dependencies:

C.5 (Artifact Registry must exist for image push)
A.10 (Container Session Lifecycle API - validate/heartbeat/release endpoints)

Note: A.10 supersedes A.8 for container deployments. A.8 covers client-side heartbeat daemon, A.10 covers backend API endpoints.

Estimated Time: 24-32 hours

Priority: P0 (BLOCKING for customer Docker/Workstation deployments)

Track D: Security Hardening

Repository: submodules/cloud/coditect-cloud-backend/ Isolation Boundary: Security middleware, auth logic (NO business logic changes) No Collision With: Track A (different files) Depends On: Nothing (can start immediately)

D.1: P0 Security (BLOCKING for Launch)

Files to Create/Modify:

api/middleware/rate_limit.py (NEW)
api/middleware/security_headers.py (NEW)
api/middleware/login_protection.py (NEW)
requirements.txt (ADD slowapi)

Agent Invocation:

Task(subagent_type="security-specialist", prompt="Implement Track D.1 P0 Security in submodules/cloud/coditect-cloud-infra/backend/: (1) rate limiting middleware with slowapi - /auth/login 5/min, /auth/signup 3/min, /licenses/validate 60/min, /licenses/activate 10/hour; (2) security headers middleware - X-Content-Type-Options, X-Frame-Options, HSTS, CSP; (3) failed login protection - track by email, lock after 5 failures for 15 min, log with IP")

Tasks:

D.1.1: Rate limiting middleware ✅ (Jan 1, 2026)
- /auth/login: 5/minute per IP
- /auth/register: 3/minute per IP
- /licenses/validate: 60/minute per key
- /licenses/activate: 10/hour per key
- Implementation: core/middleware/rate_limit.py with Redis-based sliding window
D.1.2: Security headers middleware ✅ (Jan 1, 2026)
- X-Content-Type-Options, X-Frame-Options
- Strict-Transport-Security (HSTS)
- Content-Security-Policy
- Implementation: core/middleware/security_headers.py with OWASP-compliant headers
D.1.3: Failed login protection ✅ (Jan 1, 2026)
- Track failed attempts by email
- Lock after 5 failures (15 min cooldown)
- Log all failed attempts with IP
- Implementation: core/middleware/login_protection.py with Redis-based lockout
D.1.4: Rate limiting for container session endpoints ✅ (Jan 9, 2026)
- /sessions/validate: 30/minute per license_key (prevent brute force)
- /sessions/heartbeat: 20/minute per session_token (normal: 1 per 5 min)
- /sessions/release: 10/minute per session_token (prevent abuse)
- Implementation: api/v1/throttles.py with custom LicenseKeyThrottle and SessionTokenThrottle classes

Completed: January 9, 2026 (D.1.1-D.1.4 done)

D.2: P1 Security (High Priority)

Files to Create/Modify:

models/audit_log.py (NEW)
api/middleware/audit.py (NEW)
api/v1/serializers/*.py (ADD validation limits)

Agent Invocation:

Task(subagent_type="security-specialist", prompt="Implement Track D.2 P1 Security in submodules/cloud/coditect-cloud-infra/backend/: (1) audit logging - create models/audit_log.py and api/middleware/audit.py, log signup/login/logout/failed_login/license events with timestamp, user_id, IP, user_agent; (2) input validation - max lengths for email 254, password 128, license_key 50, strict mode; (3) error hardening - no stack traces in production, generic auth errors")

Tasks:

D.2.1: Audit logging table and middleware ✅ COMPLETE (Jan 1)
- Log: signup, login, logout, failed_login
- Log: license_activate, license_validate
- Include: timestamp, user_id, IP, user_agent, action, result
- Implementation: core/models.py (AuditLog, AuditLogAction, AuditLogLevel), core/middleware/audit_log.py, core/admin.py
- Agent: Task(subagent_type="security-specialist", prompt="Create audit logging system with models/audit_log.py and api/middleware/audit.py")
D.2.2: Input validation hardening ✅ COMPLETE (Jan 1)
- Max email length: 254 chars (RFC 5321)
- Max password length: 128 chars (bcrypt DoS prevention)
- Max license key length: 50 chars
- Reject unexpected fields (strict mode via StrictSerializerMixin)
- Implementation: core/serializers.py (InputLimits, StrictSerializer, validated field types), users/serializers.py, licenses/serializers.py
- Agent: Task(subagent_type="security-specialist", prompt="Add strict input validation to all serializers with max length constraints")
D.2.3: Error response hardening ✅ COMPLETE (Jan 1)
- No stack traces in production (DEBUG=False hides traces)
- Generic auth error messages (prevents email enumeration)
- Don't reveal email existence (same error for all auth failures)
- Implementation: core/exceptions.py (ErrorCodes, GenericMessages, secure exception handler), users/serializers.py (generic login errors)
- Agent: Task(subagent_type="security-specialist", prompt="Implement production error handling - no stack traces, generic auth messages")

Estimated Time: 4-6 hours Completed: January 1, 2026 (D.2 complete - Security Hardening 100%)

D.3: Two-Factor Authentication (2FA) ✅ COMPLETE

Architecture Reference: ADR-016-two-factor-authentication.md Repository: submodules/cloud/coditect-cloud-infra/backend/ + submodules/cloud/coditect-cloud-frontend/ Status: ✅ COMPLETE (Jan 2, 2026)

Files Created/Modified:

Backend:

users/models.py - 2FA fields (two_factor_enabled, totp_secret, backup_codes)
users/views_2fa.py - 10 view classes for 2FA endpoints (~700 lines)
users/serializers.py - 2FA serializers, CustomTokenObtainPairSerializer 2FA check
coditect_license/urls.py - 2FA URL routes

Frontend:

src/pages/Login.tsx - 2FA challenge form with conditional rendering
src/services/auth.service.ts - 2FA API methods
src/pages/Profile.tsx - Security tab with 2FA management

API Endpoints:

Endpoint	Method	Auth	Description
`/api/v1/auth/2fa/status/`	GET	JWT	Get 2FA status
`/api/v1/auth/2fa/setup/`	POST	JWT	Start 2FA setup
`/api/v1/auth/2fa/qr-code/`	GET	JWT	Get QR code
`/api/v1/auth/2fa/verify/`	POST	JWT	Verify and enable
`/api/v1/auth/2fa/disable/`	POST	JWT	Disable 2FA
`/api/v1/auth/2fa/backup-codes/`	GET	JWT	Get backup codes
`/api/v1/auth/2fa/regenerate-backup-codes/`	POST	JWT	Regenerate codes
`/api/v1/auth/2fa/login-verify/`	POST	None	Verify 2FA on login

Tasks:

Estimated Time: 8-12 hours Completed: January 2, 2026 (v1.16.0-2fa-login deployed to GKE)

Track E: Integration Testing

Repository: Multiple (test suites in each repo) Isolation Boundary: Test files only No Collision With: All other tracks Depends On: Tracks A, B, C, D (all features must be implemented)

E.1: End-to-End Flow Testing

Agent Invocation:

Task(subagent_type="testing-specialist", prompt="Implement Track E.1 E2E testing: (1) full signup → email verify → payment → activation flow with Playwright/Cypress; (2) license validation across platforms; (3) Stripe webhook reliability test with 100 events; (4) offline mode test for 72-hour grace period; (5) activation limit test for max seats")

Tasks:

E.1.1: Full signup → email verify → payment → activation flow ✅ COMPLETE (Jan 1, 2026)
- Agent: Task(subagent_type="testing-specialist", prompt="Create E2E test for complete user signup through payment activation flow")
- Implemented: tests/e2e/test_signup_activation_flow.py (450 lines, 10 tests, 3 classes)
E.1.2: License validation across platforms (macOS, Linux, Windows) ✅ COMPLETE (Jan 1, 2026)
- Agent: Task(subagent_type="testing-specialist", prompt="Create cross-platform license validation tests for macOS, Linux, Windows")
- Implemented: tests/e2e/test_cross_platform_validation.py (350 lines, 15 tests, 4 classes)
E.1.3: Webhook reliability test (100 events) ✅ COMPLETE (Jan 1, 2026)
- Agent: Task(subagent_type="testing-specialist", prompt="Create Stripe webhook reliability test sending 100 events and verifying processing")
- Implemented: tests/e2e/test_webhook_reliability.py (500 lines, 14 tests, 4 classes)
E.1.4: Offline mode test (72-hour grace period) ✅ COMPLETE (Jan 1, 2026)
- Agent: Task(subagent_type="testing-specialist", prompt="Create offline mode test verifying 72-hour grace period functionality")
- Implemented: tests/e2e/test_offline_mode.py (400 lines, 15 tests, 5 classes)
E.1.5: Activation limit test (max seats) ✅ COMPLETE (Jan 1, 2026)
- Agent: Task(subagent_type="testing-specialist", prompt="Create test for license activation limits and max seat enforcement")
- Implemented: tests/e2e/test_activation_limits.py (450 lines, 16 tests, 4 classes)

Estimated Time: 8-12 hours

E.2: Security Testing

Agent Invocation:

Task(subagent_type="testing-specialist", prompt="Implement Track E.2 Security testing: (1) rate limiting verification expecting 429 responses; (2) failed login lockout after 5 attempts; (3) security headers present in all responses; (4) audit logs capturing all events; (5) input validation boundary testing")

Tasks:

E.2.1: Rate limiting verification (expect 429 responses) - COMPLETE (15 tests, 296 lines)
- File: backend/tests/security/test_rate_limit.py
E.2.2: Failed login lockout test (5 attempts → lock) - COMPLETE (14 tests, 315 lines)
- File: backend/tests/security/test_login_protection.py
E.2.3: Security headers present in all responses - COMPLETE (18 tests, 258 lines)
- File: backend/tests/security/test_security_headers.py
E.2.4: Audit logs capturing all events - COMPLETE (17 tests, 348 lines)
- File: backend/tests/security/test_audit_log.py
E.2.5: Input validation boundary testing - COMPLETE (24 tests, 395 lines)
- File: backend/tests/security/test_input_validation.py

Status: COMPLETE | Total: 88 tests, 1,622 lines | Completed: 2026-01-01

E.3: Platform Testing ✅ COMPLETE

Status: ✅ COMPLETE (Jan 08, 2026) Repository: coditect-cloud-backend/tests/platform/

Agent Invocation:

Task(subagent_type="testing-specialist", prompt="Implement Track E.3 Platform testing: verify installation and license validation on (1) macOS Intel; (2) macOS ARM/Apple Silicon; (3) Linux x64; (4) Windows x64; (5) npm install verification on all platforms")

Tasks:

E.3.1: macOS Intel testing ✅ (Jan 08, 2026)
- File: tests/platform/test_cross_platform.py - TestMacOSIntel class
- Tests: x86_64 detection, Keychain access, Library paths, codesign, Rosetta check
E.3.2: macOS ARM (Apple Silicon) testing ✅ (Jan 08, 2026)
- File: tests/platform/test_cross_platform.py - TestMacOSARM class
- Tests: arm64 detection, native execution (not Rosetta 2), Apple Silicon features
E.3.3: Linux x64 testing ✅ (Jan 08, 2026)
- File: tests/platform/test_cross_platform.py - TestLinuxX64 class
- Tests: XDG paths, secret storage, systemd, permissions, glibc 2.17+
E.3.4: Windows x64 testing ✅ (Jan 08, 2026)
- File: tests/platform/test_cross_platform.py - TestWindowsX64 class
- Tests: Registry access, Credential Manager, long paths, PowerShell
E.3.5: npm install verification on all platforms ✅ (Jan 08, 2026)
- File: tests/platform/test_npm_install.py (~420 lines, 6 test classes)
- Tests: Node.js 18+/npm 9+ prereqs, package install, registry, package.json validation, node_modules, performance

Files Created:

tests/platform/__init__.py - Package docstring
tests/platform/conftest.py (~270 lines) - Platform detection, fixtures, utilities
tests/platform/test_cross_platform.py (~470 lines) - Platform-specific tests
tests/platform/test_npm_install.py (~420 lines) - npm verification tests

Total: ~1,170 lines, 4 files, 35+ tests

Track F: Documentation & Support

Repository: submodules/core/coditect-core/ and submodules/docs/ Isolation Boundary: Documentation files only No Collision With: All development tracks Depends On: Tracks A, B (features must be documented)

F.1: User Documentation

Files to Create/Modify:

docs/guides/PILOT-INSTALLATION-GUIDE.md
docs/guides/PILOT-USER-GUIDE.md
docs/guides/PILOT-FAQ.md

Agent Invocation:

/agent codi-documentation-writer "Create Track F.1 User Documentation: (1) update PILOT-INSTALLATION-GUIDE.md with current installation steps; (2) create PILOT-USER-GUIDE.md for dashboard usage; (3) create PILOT-FAQ.md with common issues; (4) verify CLI help text accuracy"

Tasks:

F.1.1: Create PILOT-GETTING-STARTED.md ✅ (Jan 7, 2026)
- Created: docs/guides/PILOT-GETTING-STARTED.md - Cloud signup, workstation access, first session
F.1.2: Create PILOT-USER-GUIDE.md ✅ (Jan 7, 2026)
- Created: docs/guides/PILOT-USER-GUIDE.md - Dashboard, workstations, licenses, team, billing
F.1.3: Create PILOT-FAQ.md ✅ (Jan 7, 2026)
- Created: docs/guides/PILOT-FAQ.md - 40+ FAQs covering all common issues
F.1.4: Verify CLI help text ✅ (Jan 7, 2026)
- Verified: Rust CLI help text accurate (init, start, doctor, version, config)

Estimated Time: 4-6 hours

F.2: API Documentation

Agent Invocation:

/agent codi-documentation-writer "Create Track F.2 API Documentation: (1) update OpenAPI spec with all commerce, auth, and license endpoints; (2) generate API reference documentation; (3) create integration guide for developers"

Tasks:

F.2.1: Add @extend_schema decorators to all views ✅ (Jan 8, 2026)
- Fixed: 64 OpenAPI schema errors → 0 errors via drf-spectacular decorators
- Modified: api/v1/views/auth.py, api/v1/views/subscription.py, api/v1/views/license_delivery.py, api/v1/health.py
- Fixed: api/v1/serializers/user.py - Invalid field names (subscription_tier → plan)
- Generated: openapi-schema-generated.yaml (OpenAPI 3.0.3, 19 endpoints)
F.2.2: Generate API reference documentation ✅ (Jan 8, 2026)
- Created: docs/API-REFERENCE.md (~660 lines)
- Coverage: Health, Auth, Subscription, License, Seat Management endpoints with request/response examples
F.2.3: Create integration guide for developers ✅ (Jan 08, 2026)
- Created: docs/INTEGRATION-GUIDE.md (~1,270 lines)
- Coverage: Python (requests), JavaScript/TypeScript (fetch/axios), cURL examples
- Features: Authentication flow, license session management, error handling, rate limiting, webhooks, SDK best practices

Estimated Time: 4-6 hours

F.3: Support Preparation

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Set up Track F.3 Support infrastructure: (1) configure support email monitoring for 1@az1.ai; (2) create GitHub issue templates for bug reports; (3) prepare emergency response playbook; (4) set up Discord support channel")

Tasks:

F.3.1: Set up support email monitoring ✅ (Jan 09, 2026)
- Status: Pilot-adequate - 1@az1.ai → 1@az1.ai (owner inbox monitoring)
- Note: All coditect.ai emails forward to 1@az1.ai with native email client notifications
- Future: Automated ticketing (Zendesk/Freshdesk) when user count exceeds 100
F.3.2: Create issue template for bug reports ✅ (Jan 08, 2026)
- Created: .github/ISSUE_TEMPLATE/ with 4 files:
  - bug_report.yml - Bug report with severity, component selection
  - feature_request.yml - Feature request with priority, contribution interest
  - support_request.yml - Support request with urgency, pre-checklist
  - config.yml - Template chooser with contact links
F.3.3: Prepare emergency response playbook ✅ (Jan 08, 2026)
- Created: internal/operations/EMERGENCY-RESPONSE-PLAYBOOK.md (~600 lines)
- Coverage: SEV levels, incident process, 6 runbooks, communication templates, escalation matrix
F.3.4: ~~Create Slack/Discord support channel~~ DEFERRED (Jan 08, 2026)
Deferral Decision: Discord/Slack community support channel is not being implemented for pilot launch.

Rationale:
1. Pilot Scale: Initial pilot has limited users; GitHub Discussions + email sufficient
2. Support Overhead: Real-time chat requires dedicated moderation resources
3. Signal-to-Noise: GitHub Discussions provides better searchability and threading
4. Security: Enterprise customers prefer formal support channels over public Discord
5. Resource Focus: Engineering resources better spent on product stability
Current Support Channels (Sufficient for Pilot):
- GitHub Discussions (Q&A, announcements, feature requests)
- GitHub Issues (bug reports, support requests)
- Email: 1@az1.ai (pending MX configuration)
Re-evaluation Criteria:
- User count exceeds 100 active users
- Community requests Discord/Slack in feedback
- Dedicated community manager hired
Post-Launch Consideration: Q2 2026

Estimated Time: 2-3 hours

F.4: Track Nomenclature Standard (Customer Extensibility) ✅ COMPLETE

Status: ✅ COMPLETE (Jan 4, 2026) Goal: Define hierarchical track nomenclature with customer override capability Architecture Reference: ADR-054

Files Created:

internal/architecture/adrs/ADR-054-track-nomenclature-extensibility.md ✅
coditect-core-standards/CODITECT-STANDARD-TRACK-NOMENCLATURE.md ✅ (~19KB)
config/tracks.template.json ✅
config/schemas/tracks-v1.schema.json ✅
coditect-core-standards/AGENTIC-COMMUNICATION-STANDARD.md ✅ (v1.0.0 → v1.1.0)

Document Hierarchy:

ADR-054 (WHY) ──▶ STANDARD (WHAT) ──▶ TEMPLATE (HOW)
                       │
                       ▼
         AGENTIC-COMMUNICATION-STANDARD (REFERENCE)

Tasks:

F.4.1: ADR-054 Track Nomenclature Extensibility ✅

F.4.1.1: Create ADR-054-track-nomenclature-extensibility.md ✅ (Jan 4, 2026)
- Completed: Created ~400 line ADR documenting 3-tier hierarchical system

F.4.2: CODITECT-STANDARD-TRACK-NOMENCLATURE.md ✅

F.4.2.1: Create full track nomenclature specification ✅ (Jan 4, 2026)
- Completed: Created ~19KB specification with Task ID format, validation regex, agent mappings

F.4.3: TRACKS-CONFIG-TEMPLATE.json ✅

F.4.3.1: Create customer starter template ✅ (Jan 4, 2026)
- Completed: Created tracks.template.json + JSON Schema for validation

F.4.4: Update AGENTIC-COMMUNICATION-STANDARD.md ✅

F.4.4.1: Add Track Nomenclature section with cross-reference ✅ (Jan 4, 2026)
- Completed: Updated to v1.1.0 with Track Nomenclature section

Completed: January 4, 2026 (3 hours with parallel MoE execution)

Parallelization Strategy:

┌─────────────────────────────────────────────────────────────────┐
│                    PARALLEL EXECUTION                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│   Phase 1 (Parallel):                                           │
│   ┌──────────────┐     ┌──────────────┐                         │
│   │ F.4.1.1      │     │ F.4.2.1      │                         │
│   │ ADR-054      │     │ STANDARD     │                         │
│   │ (architect)  │     │ (docs)       │                         │
│   └──────┬───────┘     └──────┬───────┘                         │
│          │                    │                                  │
│          └────────┬───────────┘                                  │
│                   ▼                                              │
│   Phase 2 (Sequential - needs Phase 1):                         │
│   ┌──────────────┐     ┌──────────────┐                         │
│   │ F.4.3.1      │     │ F.4.4.1      │                         │
│   │ TEMPLATE     │     │ UPDATE STD   │                         │
│   │ (architect)  │     │ (docs)       │                         │
│   └──────────────┘     └──────────────┘                         │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Estimated Time: 4-6 hours (2-3 hours with parallel execution)

F.5: Component Quality Improvement (Agents, Skills)

Status: ✅ COMPLETE (Jan 4, 2026) Script: scripts/component-improvement-orchestrator.py Standard: coditect-core-standards/SKILL-QUALITY-STANDARD.md Depends On: F.4 (Track Nomenclature for task IDs)

Objective: Add 6 quality sections to all components:

Success Output
Completion Checklist
Failure Indicators
When NOT to Use
Anti-Patterns
Principles

Progress:

✅ Commands: 181 complete (Cycles 1-32, Jan 4 2026)
✅ Agents: 152 complete (Batches 1-27, Jan 4 2026)
✅ Skills: 219 complete (Batches 1-37, Jan 4 2026)

Total Components Updated: 552/552 (100%)

Primary Agent: component-enhancer or codi-documentation-writer MoE Pattern: Parallel batch processing (5 agents per batch)

F.5.1: Agent Quality Improvement - Batches 1-10

Status: ✅ COMPLETE (Jan 4, 2026)

Batch 1 (5 agents):

F.5.1.1: actix-web-specialist - Add 6 quality sections
F.5.1.2: adr-compliance-specialist - Add 6 quality sections
F.5.1.3: ai-curriculum-specialist - Add 6 quality sections
F.5.1.4: ai-specialist - Add 6 quality sections
F.5.1.5: application-performance - Add 6 quality sections

Invocation:

Task(subagent_type="codi-documentation-writer", prompt="Add 6 quality sections (Success Output, Completion Checklist, Failure Indicators, When NOT to Use, Anti-Patterns, Principles) to agents: actix-web-specialist, adr-compliance-specialist, ai-curriculum-specialist, ai-specialist, application-performance. Follow SKILL-QUALITY-STANDARD.md format.")

Batch 2 (5 agents):

F.5.1.6: architect-review - Add 6 quality sections
F.5.1.7: assessment-creation-agent - Add 6 quality sections
F.5.1.8: audit-trail-manager - Add 6 quality sections
F.5.1.9: backend-api-security - Add 6 quality sections
F.5.1.10: backend-architect - Add 6 quality sections

Batch 3 (5 agents):

F.5.1.11: backend-development - Add 6 quality sections
F.5.1.12: binary-distribution-architect - Add 6 quality sections
F.5.1.13: biographical-researcher - Add 6 quality sections
F.5.1.14: blockchain-developer - Add 6 quality sections
F.5.1.15: business-analytics - Add 6 quality sections

Batch 4 (5 agents):

F.5.1.16: business-intelligence-analyst - Add 6 quality sections
F.5.1.17: cicd-automation - Add 6 quality sections
F.5.1.18: claude-research-agent - Add 6 quality sections
F.5.1.19: cloud-architect-code-reviewer - Add 6 quality sections
F.5.1.20: cloud-architect - Add 6 quality sections

Batch 5 (5 agents):

F.5.1.21: code-documentation - Add 6 quality sections
F.5.1.22: code-reviewer - Add 6 quality sections
F.5.1.23: code-signing-specialist - Add 6 quality sections
F.5.1.24: codebase-analyzer - Add 6 quality sections
F.5.1.25: codebase-locator - Add 6 quality sections

Batch 6 (5 agents):

F.5.1.26: codebase-pattern-finder - Add 6 quality sections
F.5.1.27: codi-devops-engineer - Add 6 quality sections
F.5.1.28: codi-documentation-writer - Add 6 quality sections
F.5.1.29: codi-qa-specialist - Add 6 quality sections
F.5.1.30: codi-test-engineer - Add 6 quality sections

Batch 7 (5 agents):

F.5.1.31: coditect-adr-specialist - Add 6 quality sections
F.5.1.32: coditect-onboarding - Add 6 quality sections
F.5.1.33: competitive-analyst - Add 6 quality sections
F.5.1.34: competitive-market-analyst - Add 6 quality sections
F.5.1.35: complexity-assessor - Add 6 quality sections

Batch 8 (5 agents):

F.5.1.36: compliance-checker-agent - Add 6 quality sections
F.5.1.37: component-analyzer - Add 6 quality sections
F.5.1.38: component-enhancer - Add 6 quality sections
F.5.1.39: component-qa-reviewer - Add 6 quality sections
F.5.1.40: component-qa-validator - Add 6 quality sections

Batch 9 (5 agents):

F.5.1.41: comprehensive-review - Add 6 quality sections
F.5.1.42: compression-evaluator - Add 6 quality sections
F.5.1.43: content-marketing - Add 6 quality sections
F.5.1.44: context-health-analyst - Add 6 quality sections
F.5.1.45: context-snapshot-generator - Add 6 quality sections

Batch 10 (5 agents):

F.5.1.46: council-chairman - Add 6 quality sections
F.5.1.47: council-orchestrator - Add 6 quality sections
F.5.1.48: data-engineering - Add 6 quality sections
F.5.1.49: database-architect - Add 6 quality sections
F.5.1.50: deep-research - Add 6 quality sections

F.5.2: Agent Quality Improvement - Batches 11-20

Status: ✅ COMPLETE (Jan 4, 2026)

Batch 11-20: (50 agents)

F.5.2.1-F.5.2.50: Agents 51-100 quality sections

F.5.3: Agent Quality Improvement - Batches 21-27

Status: ✅ COMPLETE (Jan 4, 2026)

Batch 21-27: (52 agents)

F.5.3.1-F.5.3.52: Agents 101-152 quality sections

F.5.4: Skills Quality Improvement

Status: ✅ COMPLETE (Jan 4, 2026)

F.5.4.1-F.5.4.219: Skills quality sections (219 skills)

Completed Time:

Agents: ~4 hours (parallel MoE execution)
Skills: ~6 hours (parallel MoE execution)

F.5.5: Low-Scoring Component Remediation

Status: ✅ COMPLETED (2026-01-08) Priority: P0 - Critical Owner: codi-documentation-writer Depends On: F.5.4 (Quality sections complete) Estimate: 8-10 hours (parallel execution) Progress (2026-01-08): F.5.5.1 ✅ (32/32), F.5.5.2 ✅ (7/7) - All high/medium priority batches complete Commits: 1c9e6363, d4bdd31c, fcedde5c, a25bc874, 7ce8328d

Objective: Fix components scoring <50% in retrospective analysis using targeted anti-pattern remediation.

Retrospective Data Summary:

Total Invocations: 9,847
Success Rate: 12%
Components <50%: 89 components
Components at 0%: 20 skills (likely never invoked or always failing)

F.5.5.1: Critical - 0% Success Rate + High-Impact Components (32 tasks)

Issue: These skills have 0% success rate - either never successfully invoked or fundamental issues. Expanded from 20 to 32 tasks with proactive high-impact improvements (2026-01-08). Anti-Pattern: incomplete_output, hallucination_risk Fix Strategy: Add mandatory output templates, verification steps, pre-flight checks.

Batch 1 (5 skills) - Security & Compliance: ✅ COMPLETED 2026-01-08

F.5.5.1.1: multi-tenant-security - Added tenant isolation checklist, scope boundaries
F.5.5.1.2: vulnerability-assessment - Added OWASP reference, output template
F.5.5.1.3: security-scanning-patterns - Added tool requirements (trivy, snyk)
F.5.5.1.4: compliance-validation - Added compliance framework mapping (SOC2/HIPAA/GDPR/PCI DSS cross-reference)
F.5.5.1.5: advanced-evaluation - Added evaluation criteria template with YAML schema

Invocation F.5.5.1.1-5:

Task(subagent_type="codi-documentation-writer", prompt="Fix 0% success rate security skills. For each of: multi-tenant-security, vulnerability-assessment, security-scanning-patterns, compliance-validation, advanced-evaluation - Add: 1) ## Pre-flight Checklist with required context, 2) ## Output Template with mandatory sections, 3) ## Verification Steps to confirm success, 4) ## Required Tools section. These skills are failing due to incomplete_output and hallucination_risk anti-patterns.")

Batch 2 (5 skills) - Infrastructure: ✅ COMPLETED 2026-01-08

F.5.5.1.6: adaptive-retry - Added quick scenario configuration table with copy-paste configs
F.5.5.1.7: error-handling-resilience - Added error handling decision matrix
F.5.5.1.8: cloud-infrastructure-patterns - Added Cloud Provider Selection Matrix (GCP/AWS/Azure)
F.5.5.1.9: dynamic-capability-router - Added Routing Decision Tree and Quick Reference
F.5.5.1.10: efficiency-optimization - Added Baseline Metrics Template with YAML schema

Invocation F.5.5.1.6-10:

Task(subagent_type="codi-documentation-writer", prompt="Fix 0% success rate infrastructure skills. For each of: adaptive-retry, error-handling-resilience, cloud-infrastructure-patterns, dynamic-capability-router, efficiency-optimization - Add: 1) ## Scope Boundaries with explicit limits, 2) ## Required Context listing prerequisites, 3) ## Decision Tree for routing/selection, 4) ## Output Template. Fix context_confusion anti-pattern.")

Batch 3 (5 skills) - Analysis & Evaluation: ✅ COMPLETED 2026-01-08

F.5.5.1.11: evaluation-framework - Added rubric selection guide with customization decision tree
F.5.5.1.12: codebase-analysis-patterns - Added Analysis Scope Decision Matrix and Scope Validation Checklist
F.5.5.1.13: wasm-optimization-patterns - Added WASM Optimization Checklist with build/deployment/performance validation
F.5.5.1.14: educational-content-patterns - Added Content Structure Template with Bloom's Taxonomy reference
F.5.5.1.15: cicd-automation-patterns - Added Pipeline Stage Requirements Matrix and deployment strategy selection

Invocation F.5.5.1.11-15:

Task(subagent_type="codi-documentation-writer", prompt="Fix 0% success rate analysis skills. For each of: evaluation-framework, codebase-analysis-patterns, wasm-optimization-patterns, educational-content-patterns, cicd-automation-patterns - Add: 1) ## Scope Limits with explicit boundaries, 2) ## Input Requirements checklist, 3) ## Output Template with all required sections, 4) ## Verification Steps. Fix incomplete_output anti-pattern.")

Batch 4 (5 agents) - 0% Agents: ✅ COMPLETED 2026-01-08

F.5.5.1.16: quality-gate-enforcer agent - Added Quick Start Guide and Gate Check Severity Guide
F.5.5.1.17: react-native-developer agent - Added Platform Decision Matrix and State Management Selection
F.5.5.1.18: readme-generator agent - Added Template Selection Guide and Complexity Matrix
F.5.5.1.19: rust-qa-specialist agent - Added QA Review Checklist and Review Priority Matrix
F.5.5.1.20: sample-budget-aware-agent agent - Added Budget Level Decision Guide and Cost Optimization Tips

Invocation F.5.5.1.16-20:

Task(subagent_type="codi-documentation-writer", prompt="Fix 0% success rate agents. For each of: quality-gate-enforcer, react-native-developer, readme-generator, rust-qa-specialist, sample-budget-aware-agent - Add: 1) ## Pre-flight Checklist, 2) ## Required Context, 3) ## Output Template with mandatory fields, 4) ## Verification Steps, 5) ## When NOT to Use with alternatives. These agents are failing completely.")

Batch 5 (7 skills) - Resilience & Architecture (Proactive - 2026-01-08): ✅ COMPLETED

F.5.5.1.21: circuit-breaker-patterns - Added state transition diagram (ASCII)
F.5.5.1.22: multi-provider-llm-fallback - Added provider comparison quick reference (Anthropic/OpenAI/Google/Azure/Local)
F.5.5.1.23: context-degradation - Added degradation diagnostic flowchart
F.5.5.1.24: framework-migration-patterns - Added migration readiness checklist with go/no-go criteria
F.5.5.1.25: auto-trigger-framework - Added trigger configuration quick reference with YAML snippets
F.5.5.1.26: software-design-patterns - Added pattern selection decision tree (GoF patterns)
F.5.5.1.27: microservices-patterns - Added service communication decision matrix (REST/gRPC/Kafka/RabbitMQ)

Batch 6 (5 agents) - Core Agents (Proactive - 2026-01-08): ✅ COMPLETED Prioritized high-traffic core agents over 0% agents to maximize impact.

F.5.5.1.28: orchestrator agent - Added task routing quick reference
F.5.5.1.29: senior-architect agent - Added architecture review checklist
F.5.5.1.30: codi-documentation-writer agent - Added documentation type selection guide with quality checklist
F.5.5.1.31: devops-engineer agent - Added deployment strategy selection matrix (rolling/blue-green/canary/feature flags)
F.5.5.1.32: testing-specialist agent - Added test type selection guide with coverage strategy by risk

Commits: 1c9e6363, d4bdd31c, fcedde5c

F.5.5.2: Severe - 17-25% Success Rate (7 components) ✅ COMPLETED 2026-01-08

Issue: Very low success rate indicates fundamental scope or trigger issues. Anti-Pattern: context_confusion, tool_misuse Fix Strategy: Narrow scope, add explicit triggers, tool requirements.

Components:

F.5.5.2.1: terminal-integration-specialist agent (17%) - Added WebSocket/WASM scope limits matrix and technology requirements
F.5.5.2.2: script-utility-analyzer agent (25%) - Added Script Type Boundaries and Dangerous Pattern Detection
F.5.5.2.3: performance-profiler agent (25%) - Added Profiling Tool Requirements Matrix by language
F.5.5.2.4: git-workflow-automation skill (25%) - Added Git Operation Boundaries and Task Isolation Limits
F.5.5.2.5: project-discovery-specialist agent (25%) - Added Discovery Scope Limits and Stop Conditions
F.5.5.2.6: production-readiness-auditor agent (25%) - Added Quick Audit Checklist Template
F.5.5.2.7: difficulty-aware-orchestrator agent (25%) - Added Difficulty Mapping Reference with task type defaults

Invocation F.5.5.2.1-7:

Task(subagent_type="codi-documentation-writer", prompt="Fix 17-25% success rate components. For each of: terminal-integration-specialist (17%), script-utility-analyzer (25%), performance-profiler (25%), git-workflow-automation (25%), project-discovery-specialist (25%), production-readiness-auditor (25%), difficulty-aware-orchestrator (25%) - Add: 1) ## Scope Boundaries with EXPLICIT limits (what this DOES and DOES NOT do), 2) ## Required Tools section listing exact tools to use, 3) ## Trigger Conditions when to invoke, 4) ## Pre-flight Checklist. Fix context_confusion anti-pattern.")

F.5.5.3: High - 29-35% Success Rate (12 components)

Issue: Low success rate from unclear instructions or missing context. Anti-Pattern: excessive_retries, context_confusion Fix Strategy: Add clear examples, recovery steps, context requirements.

Batch 1 (6 components):

F.5.5.3.1: hello command (29%) - Add explicit purpose, expected output
F.5.5.3.2: coditect-adr-specialist agent (30%) - Add ADR template, review criteria
F.5.5.3.3: build-installers command (31%) - Add platform requirements
F.5.5.3.4: agent-dispatcher command (32%) - Add routing decision tree
F.5.5.3.5: mermaid-diagram-fixing skill (33%) - Add diagram syntax rules
F.5.5.3.6: codebase-pattern-finder agent (33%) - Add search scope limits

Invocation F.5.5.3.1-6:

Task(subagent_type="codi-documentation-writer", prompt="Fix 29-33% success rate components. For: hello (29%), coditect-adr-specialist (30%), build-installers (31%), agent-dispatcher (32%), mermaid-diagram-fixing (33%), codebase-pattern-finder (33%) - Add: 1) ## Clear Examples with input/output pairs, 2) ## Recovery Steps for common failures, 3) ## Context Requirements checklist, 4) Strengthen ## When NOT to Use. Fix excessive_retries anti-pattern.")

Batch 2 (6 components):

F.5.5.3.7: context-optimization skill (33%) - Add optimization scope
F.5.5.3.8: moe-enhancement skill (33%) - Add MoE-specific boundaries
F.5.5.3.9: research-agent agent (33%) - Add research scope limits
F.5.5.3.10: codi-test-engineer agent (33%) - Add test framework requirements
F.5.5.3.11: codi-devops-engineer agent (35%) - Add infra scope boundaries
F.5.5.3.12: implement-plan command (35%) - Add plan format requirements

Invocation F.5.5.3.7-12:

Task(subagent_type="codi-documentation-writer", prompt="Fix 33-35% success rate components. For: context-optimization (33%), moe-enhancement (33%), research-agent (33%), codi-test-engineer (33%), codi-devops-engineer (35%), implement-plan (35%) - Add: 1) ## Scope Boundaries, 2) ## Input Format requirements, 3) ## Pre-flight Checklist, 4) ## Recovery Steps. Fix context_confusion anti-pattern.")

F.5.5.4: Medium - 36-39% Success Rate (18 components)

Issue: Inconsistent success from tool misuse or incomplete output. Anti-Pattern: tool_misuse, incomplete_output Fix Strategy: Add tool requirements, output validation checklist.

Batch 1 (6 components):

F.5.5.4.1: analyze-complexity command (36%) - Add complexity metrics template
F.5.5.4.2: debug command (37%) - Add debugging context requirements
F.5.5.4.3: analyze-hooks command (37%) - Add hook analysis scope
F.5.5.4.4: deploy-site command (37%) - Add deployment checklist
F.5.5.4.5: evaluate-response command (37%) - Add evaluation rubric
F.5.5.4.6: context-restore command (35%) - Add restore verification

Invocation F.5.5.4.1-6:

Task(subagent_type="codi-documentation-writer", prompt="Fix 35-37% success rate commands. For: analyze-complexity (36%), debug (37%), analyze-hooks (37%), deploy-site (37%), evaluate-response (37%), context-restore (35%) - Add: 1) ## Required Tools section (use Read/Edit not Bash), 2) ## Output Validation Checklist, 3) ## Examples with expected output. Fix tool_misuse anti-pattern.")

Batch 2 (6 components):

F.5.5.4.7: implement command (38%) - Add implementation scope
F.5.5.4.8: thinking-budget-manager agent (38%) - Add budget parameters
F.5.5.4.9: a11y command (38%) - Add accessibility checklist
F.5.5.4.10: prototype command (38%) - Add prototype scope limits
F.5.5.4.11: build-site command (38%) - Add build requirements
F.5.5.4.12: doc-generate command (38%) - Add doc template requirements

Invocation F.5.5.4.7-12:

Task(subagent_type="codi-documentation-writer", prompt="Fix 38% success rate commands. For: implement (38%), thinking-budget-manager (38%), a11y (38%), prototype (38%), build-site (38%), doc-generate (38%) - Add: 1) ## Scope Limits with boundaries, 2) ## Required Input format, 3) ## Output Template, 4) ## Verification Steps. Fix incomplete_output anti-pattern.")

Batch 3 (6 components):

F.5.5.4.13: security-scanning command (38%) - Add scanner tool requirements
F.5.5.4.14: create-handoff command (38%) - Add handoff template
F.5.5.4.15: cxq command (39%) - Add query syntax examples
F.5.5.4.16: action command (39%) - Add action type boundaries
F.5.5.4.17: code-indexer command (39%) - Add indexing scope
F.5.5.4.18: codi-qa-specialist agent (39%) - Add QA checklist

Invocation F.5.5.4.13-18:

Task(subagent_type="codi-documentation-writer", prompt="Fix 38-39% success rate commands. For: security-scanning (38%), create-handoff (38%), cxq (39%), action (39%), code-indexer (39%), codi-qa-specialist (39%) - Add: 1) ## Syntax Examples with valid queries, 2) ## Tool Requirements, 3) ## Output Format template, 4) ## Common Errors section. Fix tool_misuse anti-pattern.")

F.5.5.5: Low - 40-48% Success Rate (15 components)

Issue: Near-threshold components needing minor improvements. Anti-Pattern: incomplete_output Fix Strategy: Strengthen output templates, add verification steps.

Batch 1 (5 components):

F.5.5.5.1: commit command (40%) - Add commit message template
F.5.5.5.2: project-builder-orchestrator skill (40%) - Add orchestration checklist
F.5.5.5.3: production-cleanup-orchestrator skill (40%) - Add cleanup scope
F.5.5.5.4: cloud-architect-code-reviewer agent (40%) - Add review checklist
F.5.5.5.5: ai-review command (40%) - Add review criteria

Invocation F.5.5.5.1-5:

Task(subagent_type="codi-documentation-writer", prompt="Fix 40% success rate components. For: commit (40%), project-builder-orchestrator (40%), production-cleanup-orchestrator (40%), cloud-architect-code-reviewer (40%), ai-review (40%) - Add: 1) ## Output Template with all required fields, 2) ## Verification Steps checklist, 3) ## Examples showing complete output. Target >60% success rate.")

Batch 2 (5 components):

F.5.5.5.6: build-project command (40%) - Add build requirements
F.5.5.5.7: component-scaffold command (40%) - Add scaffold template
F.5.5.5.8: work-discovery-analyst agent (41%) - Add discovery scope
F.5.5.5.9: production-audit command (41%) - Add audit checklist
F.5.5.5.10: production-cleanup command (41%) - Add cleanup verification

Invocation F.5.5.5.6-10:

Task(subagent_type="codi-documentation-writer", prompt="Fix 40-41% success rate components. For: build-project (40%), component-scaffold (40%), work-discovery-analyst (41%), production-audit (41%), production-cleanup (41%) - Add: 1) ## Completion Checklist with all required outputs, 2) ## Verification Steps, 3) ## Common Pitfalls section.")

Batch 3 (5 components):

F.5.5.5.11: codi-documentation-writer agent (48%) - Add scope boundaries
F.5.5.5.12: how command (48%) - Add trigger specificity
F.5.5.5.13: document command (48%) - Add document types
F.5.5.5.14: component-viewer command (48%) - Add viewer scope
F.5.5.5.15: analyze command (48%) - Add analysis boundaries

Invocation F.5.5.5.11-15:

Task(subagent_type="codi-documentation-writer", prompt="Fix 48% success rate components (near threshold). For: codi-documentation-writer (48%), how (48%), document (48%), component-viewer (48%), analyze (48%) - Add: 1) ## Scope Boundaries clarifying limits, 2) ## Trigger Conditions for when to use, 3) ## Verification Steps. Push these above 60% threshold.")

Verification Protocol:

# After each batch, run retrospective
cd /Users/halcasteel/PROJECTS/coditect-rollout-master/submodules/core/coditect-core
source .venv/bin/activate
python3 hooks/session-retrospective.py --event session.end

# Check specific skill scores
python3 scripts/skill-pattern-analyzer.py --skill script-utility-analyzer

# Verify improvements
python3 scripts/skill-pattern-analyzer.py --dashboard | grep -E "(0%|[12][0-9]%|3[0-9]%|4[0-9]%)"

Success Criteria:

All 0% skills reach >25%
All 17-25% skills reach >40%
All 29-39% skills reach >50%
All 40-48% skills reach >60%

F.5.6: Skill Health Framework Enhancement

Status: 🔲 PENDING Priority: P2 - Medium Owner: senior-architect Depends On: F.5.5 (Low-scoring fixes complete) Estimate: 6-8 hours

Objective: Implement infrastructure for ongoing skill health monitoring and continuous improvement.

F.5.6.1: Skill Health Tracking System

Output: context-storage/skill-health.json, docs/reference/SKILL-HEALTH-TRACKER.md

F.5.6.1.1: Create scripts/skill-health-tracker.py
- Store historical scores per skill per session
- Calculate rolling averages (7-day, 30-day)
- Track improvement/degradation trends

Invocation F.5.6.1.1:

Task(subagent_type="senior-architect", prompt="Create scripts/skill-health-tracker.py that: 1) Reads skill scores from retrospective output, 2) Stores historical scores in context-storage/skill-health.json with schema {skill_name: {scores: [{date, score, invocations}], rolling_7d, rolling_30d, trend}}, 3) Calculates trends (improving/stable/degrading), 4) Provides CLI --dashboard, --skill <name>, --export options.")

F.5.6.1.2: Extend skill-learnings.json schema
- Add health_score field per skill
- Add baseline_score for regression detection
- Add last_improvement_date for staleness detection

Invocation F.5.6.1.2:

Task(subagent_type="senior-architect", prompt="Extend context-storage/skill-learnings.json schema. For each skill, add: health_score (0-100), baseline_score (score when F.5.5 completed), last_improvement_date, trend (improving/stable/degrading), invocations_since_baseline. Update hooks/session-retrospective.py to populate these fields.")

F.5.6.1.3: Create baseline snapshot
- Capture current scores for all 552 components
- Store in context-storage/skill-baseline-2026-01-04.json
- Use as reference for regression detection

Invocation F.5.6.1.3:

Task(subagent_type="codi-documentation-writer", prompt="Create baseline snapshot of all skill scores. Run retrospective to get current scores, save to context-storage/skill-baseline-2026-01-04.json with format {skill_name: {score, invocations, date}}. Document in docs/reference/SKILL-HEALTH-TRACKER.md.")

F.5.6.2: /which Command Health Integration

Output: Updated commands/which.md

F.5.6.2.1: Add health score to /which output
- Show [85%] next to skill recommendations
- Color-code: green >75%, yellow 50-75%, red <50%
- Show trend indicator (↑↓→)

Invocation F.5.6.2.1:

Task(subagent_type="codi-documentation-writer", prompt="Update commands/which.md to show health scores in output. Add to PRIMARY RECOMMENDATION section: 'Health: [XX%] ↑/↓/→'. Add health score query to the script that reads from skill-health.json. Add color coding guidance in documentation.")

F.5.6.2.2: Add health warnings
- Warn when primary recommendation <50%
- Suggest healthier alternatives
- Include improvement status

Invocation F.5.6.2.2:

Task(subagent_type="codi-documentation-writer", prompt="Add health warnings to /which command. When recommending skill <50%: 1) Show ⚠️ warning, 2) List healthier alternatives from same category, 3) Note if skill is queued for F.5.5 remediation. Update commands/which.md and relevant scripts.")

F.5.6.2.3: Health-aware routing
- Factor health score into agent selection
- Prefer >75% agents over <50% for critical tasks
- Log when unhealthy agent selected

Invocation F.5.6.2.3:

Task(subagent_type="senior-architect", prompt="Implement health-aware routing in /which and agent-dispatcher. When multiple agents match: prefer health_score >75%, penalize <50% in ranking. Add --prefer-healthy flag. Update agent selection algorithm to weight: capability_match * 0.6 + health_score * 0.4.")

F.5.6.3: Regression Detection System

Output: hooks/skill-regression-detector.py

F.5.6.3.1: Create regression detection hook
- Compare current scores to baseline
- Flag skills dropping >10% from baseline
- Run after each retrospective

Invocation F.5.6.3.1:

Task(subagent_type="senior-architect", prompt="Create hooks/skill-regression-detector.py that: 1) Loads baseline from skill-baseline-*.json, 2) Compares current retrospective scores, 3) Flags skills with score_drop > 10%, 4) Outputs regression report to context-storage/regressions/. Hook into PostToolUse:retrospective event.")

F.5.6.3.2: Alert system for regressions
- Output clear regression warnings
- Include regression details (before/after/delta)
- Suggest investigation steps

Invocation F.5.6.3.2:

Task(subagent_type="codi-documentation-writer", prompt="Add regression alerts to skill-regression-detector.py output. Format: '⚠️ REGRESSION: {skill} dropped {delta}% ({before}% → {after}%)'. Include: 1) When regression started, 2) Possible causes (recent changes), 3) Investigation steps (check skill file, check learnings).")

F.5.6.3.3: Auto-create improvement tasks
- Generate F.5.5-style tasks for regressed skills
- Add to PILOT plan automatically
- Assign appropriate anti-pattern fix

Invocation F.5.6.3.3:

Task(subagent_type="orchestrator", prompt="Extend skill-regression-detector.py to auto-create improvement tasks. When regression detected: 1) Identify likely anti-pattern (from recent failures), 2) Generate task in F.5.5 format with invocation, 3) Optionally append to PILOT-PARALLEL-EXECUTION-PLAN.md in F.5.5 section. Require --auto-task flag.")

F.5.6.4: Skill Health Dashboard

Output: commands/skill-health.md, scripts/skill-health-dashboard.py

F.5.6.4.1: Create /skill-health command
- Show all skills sorted by health score
- Filter by category, score range, trend
- Highlight skills needing attention

Invocation F.5.6.4.1:

Task(subagent_type="codi-documentation-writer", prompt="Create commands/skill-health.md and scripts/skill-health-dashboard.py. Command shows: 1) Summary stats (total, healthy >75%, warning 50-75%, critical <50%), 2) Skills sorted by score, 3) Filter options: --category, --min-score, --max-score, --trend. Format as table with Score, Trend, Invocations, Last Used.")

F.5.6.4.2: Trend visualization
- Show 7-day trend sparkline
- Indicate improving/degrading direction
- Highlight recently improved skills

Invocation F.5.6.4.2:

Task(subagent_type="codi-documentation-writer", prompt="Add trend visualization to /skill-health command. Show ASCII sparkline of 7-day scores: '▁▂▃▅▆▇█'. Add trend indicators: '↑ Improving', '↓ Degrading', '→ Stable'. Highlight skills improved by F.5.5 with ✨ indicator.")

F.5.6.4.3: Export health report
- Generate markdown report for docs/
- Include recommendations
- Weekly summary suitable for stakeholders

Invocation F.5.6.4.3:

Task(subagent_type="codi-documentation-writer", prompt="Add --export option to /skill-health command. Generate docs/reports/SKILL-HEALTH-REPORT-YYYY-MM-DD.md with: 1) Executive summary, 2) Health distribution chart (ASCII), 3) Top 10 improved, 4) Top 10 needing attention, 5) Regression alerts, 6) Recommendations. Suitable for weekly stakeholder review.")

F.5.7: Anti-Pattern Prevention System

Status: 🔲 PENDING Priority: P3 - Low Owner: orchestrator Depends On: F.5.6 (Health framework) Estimate: 4-6 hours

Objective: Proactive detection and prevention of skill anti-patterns before they cause failures.

F.5.7.1: Pre-Execution Validation

Output: hooks/skill-preflight-validator.py

F.5.7.1.1: Create pre-flight validation hook
- Read skill's Pre-flight Checklist section
- Verify required context exists
- Block execution if missing requirements

Invocation F.5.7.1.1:

Task(subagent_type="senior-architect", prompt="Create hooks/skill-preflight-validator.py that: 1) Parses ## Pre-flight Checklist from skill SKILL.md, 2) Validates each checklist item (file exists, context available), 3) Returns PASS/FAIL with missing items. Hook into PreToolUse:Skill event. Output: {valid: bool, missing: [], warnings: []}.")

F.5.7.1.2: Context validation engine
- Check for required files referenced in skill
- Verify environment variables
- Validate tool availability

Invocation F.5.7.1.2:

Task(subagent_type="senior-architect", prompt="Add context validation to skill-preflight-validator.py. Parse ## Required Context from skill, validate: 1) Files: check existence with Glob, 2) Env vars: check os.environ, 3) Tools: verify tool availability (python, npm, etc.). Return detailed validation report.")

F.5.7.1.3: Graceful blocking with guidance
- Don't just fail - explain what's missing
- Suggest how to fix the issue
- Offer to run prerequisite skills

Invocation F.5.7.1.3:

Task(subagent_type="codi-documentation-writer", prompt="Add graceful blocking to skill-preflight-validator.py. When validation fails: 1) List each missing requirement, 2) Suggest fix (e.g., 'Run /cx to capture context'), 3) Offer prerequisite skills (e.g., 'Run /orient first'). Never just 'BLOCKED' - always provide actionable guidance.")

F.5.7.2: Real-Time Anti-Pattern Detection

Output: hooks/antipattern-detector.py

F.5.7.2.1: Excessive retry detector
- Track retry attempts per skill per session
- Alert after 3 retries on same task
- Suggest alternative approaches

Invocation F.5.7.2.1:

Task(subagent_type="senior-architect", prompt="Create hooks/antipattern-detector.py with excessive_retry detection. Track: {skill: {task_hash: retry_count}}. After 3 retries: 1) Log warning, 2) Suggest: break down task, use different skill, check prerequisites. Store in session state for retrospective analysis.")

F.5.7.2.2: Context confusion detector
- Monitor skill output vs. expected scope
- Detect when skill does unrelated work
- Flag potential scope creep

Invocation F.5.7.2.2:

Task(subagent_type="senior-architect", prompt="Add context_confusion detection to antipattern-detector.py. Compare skill output against ## Scope Boundaries from SKILL.md. Flag: 1) Output mentions topics outside scope, 2) Tool usage outside allowed list, 3) Files modified outside expected paths. Use keyword matching + path validation.")

F.5.7.2.3: Real-time correction suggestions
- Provide inline suggestions during execution
- Link to relevant documentation
- Offer to switch to better-suited skill

Invocation F.5.7.2.3:

Task(subagent_type="codi-documentation-writer", prompt="Add real-time suggestions to antipattern-detector.py. When detecting anti-pattern: 1) Output inline suggestion (not blocking), 2) Link to skill's ## Anti-Patterns section, 3) Suggest alternative if available: 'Consider using X skill instead for this type of task'. Keep suggestions concise - 1-2 lines max.")

F.5.7.3: Skill Mentorship System

Output: scripts/skill-mentor.py, docs/guides/SKILL-MENTORSHIP-GUIDE.md

F.5.7.3.1: Pattern extraction from high-scoring skills
- Analyze 100% success rate skills
- Extract common patterns (structure, sections, examples)
- Document best practices

Invocation F.5.7.3.1:

Task(subagent_type="codi-documentation-writer", prompt="Create scripts/skill-mentor.py that analyzes 100% success rate skills. Extract: 1) Common section structure, 2) Example patterns that work, 3) Pre-flight checklist patterns, 4) Output template patterns. Generate docs/guides/SKILL-MENTORSHIP-GUIDE.md with best practices from high-performers.")

F.5.7.3.2: Automated pattern transfer
- Identify low-scoring skills missing patterns
- Suggest specific additions from mentors
- Generate improvement diff

Invocation F.5.7.3.2:

Task(subagent_type="senior-architect", prompt="Add pattern transfer to skill-mentor.py. For low-scoring skill (<50%): 1) Find similar high-scoring skill (same category), 2) Diff their structures, 3) Identify missing sections/patterns, 4) Generate suggested additions as diff. Output: 'Add from mentor X: ## Pre-flight Checklist with items [...]'.")

F.5.7.3.3: Improvement PR generation
- Generate PRs for skill improvements
- Include mentor skill as reference
- Auto-assign for review

Invocation F.5.7.3.3:

Task(subagent_type="orchestrator", prompt="Add --generate-pr option to skill-mentor.py. For each improvement suggestion: 1) Create branch skill-improvement/{skill-name}, 2) Apply suggested changes, 3) Create PR with body: 'Mentor: {high_scorer}, Patterns added: [...], Expected improvement: +X%'. Require manual PR merge for safety.")

F.6: SSOT Consolidation (Single Source of Truth)

Status: ✅ COMPLETE (January 4, 2026) Priority: P0 - Critical ADR: ADR-054 Track Nomenclature Extensibility Standard: CODITECT-STANDARD-AUTOMATION.md Principle #11

Purpose: Establish PILOT-PARALLEL-EXECUTION-PLAN.md as the Single Source of Truth for task tracking. Retire redundant tasklist.md files.

Files Modified:

coditect-core-standards/CODITECT-STANDARD-AUTOMATION.md (v1.1.0 → v1.2.0)
coditect-core-standards/AGENTIC-COMMUNICATION-STANDARD.md (v1.0.0 → v1.1.0)
coditect-core-standards/TEMPLATES/TASKLIST-WITH-CHECKBOXES-TEMPLATE.md (deprecated)
3x CLAUDE.md files (coditect-core, rollout-master, project-management)

Files Created:

docs/project-management/archive/PHASE-0-COMPLETION-ARCHIVE.md
docs/project-management/archive/TASKLIST-DEPRECATED-2026-01-04.md

F.6.1: Standards Updates

F.6.1.1: Add Principle #11 (SSOT) to CODITECT-STANDARD-AUTOMATION.md
F.6.1.2: Update AGENTIC-COMMUNICATION-STANDARD.md to reference PILOT plan

F.6.2: Archive Creation

F.6.2.1: Create PHASE-0-COMPLETION-ARCHIVE.md (historical content preservation)
F.6.2.2: Archive tasklist.md to TASKLIST-DEPRECATED-2026-01-04.md

F.6.3: Template Deprecation

F.6.3.1: Deprecate TASKLIST-WITH-CHECKBOXES-TEMPLATE.md with notice

F.6.4: CLAUDE.md Updates

F.6.4.1: Update coditect-core-standards/CLAUDE.md (SSOT refs)
F.6.4.2: Update rollout-master/CLAUDE.md (SSOT refs)
F.6.4.3: Update docs/project-management/CLAUDE.md (PILOT plan refs)

New SSOT Hierarchy:

Layer	Document	Purpose
Strategic	project-plan.md	Vision, milestones, budget, timeline
Tactical	PILOT-PARALLEL-EXECUTION-PLAN.md	Active tasks (SSOT)
Archive	archive/*.md	Historical records only

F.7: User Workflow Documentation 🆕

Status: 🆕 NEW - P1 (Jan 5, 2026) Goal: Document all user persona workflows with narratives, Mermaid diagrams, and n8n JSON files Architecture Reference: internal/architecture/USER-WORKFLOW-architecture.md Impact: Informs A.11 (Workstation Broker), A.12 (Team Management), B.4 (UI components)

Directory Structure:

docs-site/content/workflows/
├── INDEX.md                           # Workflow catalog
├── narratives/
│   ├── WF-101-single-user-onboarding.md ✅
│   ├── WF-102-team-member-invitation.md ✅
│   ├── WF-103-consultant-multi-tenant.md ✅
│   ├── WF-104-agency-managed-tenant.md ✅
│   ├── WF-105-enterprise-sso-provisioning.md ✅
│   ├── WF-106-context-switching.md ✅
│   ├── WF-107-organization-settings-management.md 🆕
│   ├── WF-108-team-role-change.md 🆕
│   ├── WF-109-license-seat-reallocation.md 🆕
│   ├── WF-110-contractor-access-expiration.md 🆕
│   ├── WF-111-agency-consolidated-billing.md 🆕
│   ├── WF-112-subscription-downgrade.md 🆕
│   ├── WF-113-auditor-access-revocation.md 🆕
│   ├── WF-114-multi-opunit-access-assignment.md 🆕
│   ├── WF-115-team-deletion-archival.md 🆕
│   ├── WF-116-bulk-user-import.md 🆕
│   ├── WF-117-account-recovery.md 🆕
│   ├── WF-118-billing-dispute-resolution.md 🆕
│   └── WF-119-resource-quota-management.md 🆕
├── diagrams/
│   └── (matching .mmd files for each workflow)
└── n8n/
    └── (matching .json files for each workflow)

Workflow Priority Matrix:

Priority	Workflows	Count	Description
P0	WF-101 to WF-106	6	Core user journeys (COMPLETE ✅)
P0	WF-107 to WF-111	5	Admin/operations workflows
P1	WF-112 to WF-116	5	Lifecycle management workflows
P2	WF-117 to WF-119	3	Edge cases and support workflows

F.7.1: WF-101 Single User Onboarding ✅ COMPLETE

F.7.1.1: Create WF-101-single-user-onboarding.md narrative ✅
F.7.1.2: Create WF-101 Mermaid sequence diagram ✅
F.7.1.3: Create WF-101 n8n workflow JSON ✅

Completed: Jan 5, 2026 Location: docs-site/content/workflows/{narratives,diagrams,n8n}/WF-101-*

F.7.2: WF-102 Team Member Invitation ✅ COMPLETE

F.7.2.1: Create WF-102-team-member-invitation.md narrative ✅
F.7.2.2: Create WF-102 Mermaid sequence diagram ✅
F.7.2.3: Create WF-102 n8n workflow JSON ✅

Completed: Jan 5, 2026 Location: docs-site/content/workflows/{narratives,diagrams,n8n}/WF-102-*

F.7.3: WF-103 Consultant Multi-Tenant Access ✅ COMPLETE

F.7.3.1: Create WF-103-consultant-multi-tenant.md narrative ✅
F.7.3.2: Create WF-103 Mermaid sequence diagram ✅
F.7.3.3: Create WF-103 n8n workflow JSON ✅

Completed: Jan 5, 2026 Location: docs-site/content/workflows/{narratives,diagrams,n8n}/WF-103-*

F.7.4: WF-104 Agency Managed Tenant ✅ COMPLETE

F.7.4.1: Create WF-104-agency-managed-tenant.md narrative ✅
F.7.4.2: Create WF-104 Mermaid sequence diagram ✅
F.7.4.3: Create WF-104 n8n workflow JSON ✅

Completed: Jan 5, 2026 Location: docs-site/content/workflows/{narratives,diagrams,n8n}/WF-104-*

F.7.5: WF-105 Enterprise SSO Provisioning ✅ COMPLETE

F.7.5.1: Create WF-105-enterprise-sso-provisioning.md narrative ✅
F.7.5.2: Create WF-105 Mermaid sequence diagram ✅
F.7.5.3: Create WF-105 n8n workflow JSON ✅

Completed: Jan 5, 2026 Location: docs-site/content/workflows/{narratives,diagrams,n8n}/WF-105-*

F.7.6: WF-106 Context Switching ✅ COMPLETE

F.7.6.1: Create WF-106-context-switching.md narrative ✅
F.7.6.2: Create WF-106 Mermaid sequence diagram ✅
F.7.6.3: Create WF-106 n8n workflow JSON ✅

Completed: Jan 5, 2026 Location: docs-site/content/workflows/{narratives,diagrams,n8n}/WF-106-*

F.7.7: Workflow Index Creation ✅ COMPLETE

F.7.7.1: Create INDEX.md with WF-101 through WF-106 ✅
F.7.7.2: Add user persona cross-reference table ✅
F.7.7.3: Link workflows to UI components (B.4) and APIs (A.11, A.12) ✅

Completed: Jan 5, 2026 Location: docs-site/content/workflows/INDEX.md

F.7.8: WF-107 Organization Settings Management 🆕 P0

F.7.8.1: Create WF-107-organization-settings-management.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-107 for org settings: name, branding, billing info, security settings, API keys, subscription management")
- Org admin updates settings
- Billing info and payment methods
- Security policy configuration
- API key generation/rotation
F.7.8.2: Create WF-107 Mermaid sequence diagram
F.7.8.3: Create WF-107 n8n workflow JSON

F.7.9: WF-108 Team Role Change 🆕 P0

F.7.9.1: Create WF-108-team-role-change.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-108 for team role changes: promotion, demotion, role inheritance, permission propagation, audit logging")
- Admin changes user role
- Permission recalculation
- Notification to affected user
- Audit log entry
F.7.9.2: Create WF-108 Mermaid sequence diagram
F.7.9.3: Create WF-108 n8n workflow JSON

F.7.10: WF-109 License Seat Reallocation 🆕 P0

F.7.10.1: Create WF-109-license-seat-reallocation.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-109 for license seat reallocation: remove from inactive user, assign to new user, seat pool management, grace period")
- Admin removes seat from user
- Seat returns to pool
- Assign to different user
- Deactivated user access revoked
F.7.10.2: Create WF-109 Mermaid sequence diagram
F.7.10.3: Create WF-109 n8n workflow JSON

F.7.11: WF-110 Contractor Access Expiration 🆕 P0

F.7.11.1: Create WF-110-contractor-access-expiration.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-110 for contractor access expiration: automatic deactivation at expires_at, notification workflow, extension request, data handoff")
- Cron job checks expires_at
- Pre-expiration warning (7 days, 1 day)
- Automatic membership deactivation
- Optional extension workflow
F.7.11.2: Create WF-110 Mermaid sequence diagram
F.7.11.3: Create WF-110 n8n workflow JSON

F.7.12: WF-111 Agency Consolidated Billing 🆕 P0

F.7.12.1: Create WF-111-agency-consolidated-billing.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-111 for agency consolidated billing: invoice generation, child tenant rollup, usage attribution, markup/discount application")
- Monthly billing cycle for agency
- Child tenant usage aggregation
- Single invoice to agency
- Markup/margin application
F.7.12.2: Create WF-111 Mermaid sequence diagram
F.7.12.3: Create WF-111 n8n workflow JSON

F.7.13: WF-112 Subscription Downgrade 🆕 P1

F.7.13.1: Create WF-112-subscription-downgrade.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-112 for subscription downgrade: plan change, seat reduction, feature restriction, grace period, prorated billing")
- User requests downgrade
- Excess seat handling (if reducing)
- Feature access restriction
- Prorated credit calculation
F.7.13.2: Create WF-112 Mermaid sequence diagram
F.7.13.3: Create WF-112 n8n workflow JSON

F.7.14: WF-113 Auditor Access Revocation 🆕 P1

F.7.14.1: Create WF-113-auditor-access-revocation.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-113 for auditor access revocation: read-only access removal, audit trail preservation, compliance reporting")
- Audit engagement complete
- Remove auditor read-only access
- Preserve audit trail
- Generate compliance report
F.7.14.2: Create WF-113 Mermaid sequence diagram
F.7.14.3: Create WF-113 n8n workflow JSON

F.7.15: WF-114 Multi-OpUnit Access Assignment 🆕 P1

F.7.15.1: Create WF-114-multi-opunit-access-assignment.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-114 for multi-OpUnit access: user assigned to multiple operating units, cross-OpUnit permissions, consolidated view")
- User works across OpUnits
- Different roles per OpUnit
- Cross-OpUnit visibility rules
- Consolidated dashboard
F.7.15.2: Create WF-114 Mermaid sequence diagram
F.7.15.3: Create WF-114 n8n workflow JSON

F.7.16: WF-115 Team Deletion/Archival 🆕 P1

F.7.16.1: Create WF-115-team-deletion-archival.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-115 for team deletion: member reassignment, project migration, data archival, soft delete with recovery period")
- Admin initiates team deletion
- Member reassignment workflow
- Project/data migration
- 30-day soft delete recovery
F.7.16.2: Create WF-115 Mermaid sequence diagram
F.7.16.3: Create WF-115 n8n workflow JSON

F.7.17: WF-116 Bulk User Import 🆕 P1

F.7.17.1: Create WF-116-bulk-user-import.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-116 for bulk user import: CSV upload, validation, team assignment, invitation sending, progress tracking")
- Admin uploads CSV
- Validation and error reporting
- Batch invitation sending
- Team/role assignment
F.7.17.2: Create WF-116 Mermaid sequence diagram
F.7.17.3: Create WF-116 n8n workflow JSON

F.7.18: WF-117 Account Recovery 🆕 P2

F.7.18.1: Create WF-117-account-recovery.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-117 for account recovery: identity verification, password reset, MFA reset, support escalation")
- User locked out
- Identity verification steps
- Password and/or MFA reset
- Support ticket escalation
F.7.18.2: Create WF-117 Mermaid sequence diagram
F.7.18.3: Create WF-117 n8n workflow JSON

F.7.19: WF-118 Billing Dispute Resolution 🆕 P2

F.7.19.1: Create WF-118-billing-dispute-resolution.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-118 for billing disputes: dispute submission, investigation, resolution, credit/refund issuance")
- User submits dispute
- Finance team investigation
- Resolution determination
- Credit/refund processing
F.7.19.2: Create WF-118 Mermaid sequence diagram
F.7.19.3: Create WF-118 n8n workflow JSON

F.7.20: WF-119 Resource Quota Management 🆕 P2

F.7.20.1: Create WF-119-resource-quota-management.md narrative
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create WF-119 for resource quota: workstation limits, storage limits, API rate limits, quota alerts, upgrade prompts")
- Quota limit approaching
- Warning notifications
- Hard limit enforcement
- Upgrade path presentation
F.7.20.2: Create WF-119 Mermaid sequence diagram
F.7.20.3: Create WF-119 n8n workflow JSON

Estimated Time: 52-60 hours (19 workflows × 3 artifacts each)

F.8: docs.coditect.ai Content Development 🆕

Status: 🔴 NOT STARTED Priority: P1 - Critical for Launch Repository: submodules/cloud/coditect-cloud-infra/docs-site/ Site URL: https://docs.coditect.ai Source Content: ~/.coditect/ (coditect-core components) Architecture: Diátaxis Framework (Tutorials, How-To, Reference, Explanation) Inventory: coditect-documentation-inventory.md

Component Totals (Discovered Jan 9, 2026):

Category	Count	Documentation Type
Agents	157	Reference + Tutorials
Skills	223	Reference + How-To
Commands	186	Reference + Quick Start
Scripts	360	Reference + Examples
Hooks	62	Reference
Workflows	1,152	Reference + Use Cases
Standards	52	Reference (Contributor)
ADRs	58+	Reference (Architecture)
TOTAL	2,145+	Multi-tier Documentation

Diátaxis Structure Target:

docs.coditect.ai/
├── tutorials/           # Learning-oriented (getting started, first agent)
├── how-to/              # Task-oriented (agent guides, skill creation)
├── reference/           # Information-oriented (all 3,458 components)
│   ├── agents/          # 776 agent reference pages
│   ├── skills/          # 445 skill reference pages
│   ├── commands/        # 377 command reference pages
│   ├── scripts/         # Script reference
│   ├── hooks/           # Hook reference
│   ├── workflows/       # Workflow reference
│   ├── standards/       # 52 standards documents
│   └── api/             # API reference
└── explanation/         # Understanding-oriented (architecture, concepts)

F.8.1: Phase 1 - Auto-Transform (Option 1) 🆕 P0

Status: 🔴 NOT STARTED Priority: P0 - Immediate Estimated Time: 8-12 hours Goal: Get 2,145+ reference pages live immediately via automated conversion

Agent Invocation:

Task(subagent_type="codi-documentation-writer", prompt="Create Phase 1 Auto-Transform: Build script to convert existing coditect-core component markdown files (agents/*.md, skills/*/SKILL.md, commands/*.md) to Docusaurus format. Preserve frontmatter, add sidebar config, generate category pages.")

Tasks:

F.8.1.1: Create Transform Script

F.8.1.1.1: Create scripts/docs-transform.py - Main transformation script
- Parse coditect-core component frontmatter (YAML)
- Convert markdown to Docusaurus MDX format
- Generate sidebar configuration
- Handle cross-references between components
F.8.1.1.2: Create scripts/docs-sidebar-generator.py - Sidebar generation
- Generate sidebars.ts from component structure
- Create category indexes with descriptions
F.8.1.1.3: Create scripts/docs-validate.py - Validation script
- Check for broken links
- Validate frontmatter schema
- Report missing required sections

F.8.1.2: Transform Agents (157)

F.8.1.2.1: Transform agents batch 1-50 to docs/reference/agents/
F.8.1.2.2: Transform agents batch 51-100 to docs/reference/agents/
F.8.1.2.3: Transform agents batch 101-157 to docs/reference/agents/
F.8.1.2.4: Generate agents category index page

F.8.1.3: Transform Skills (223)

F.8.1.3.1: Transform skills batch 1-75 to docs/reference/skills/
F.8.1.3.2: Transform skills batch 76-150 to docs/reference/skills/
F.8.1.3.3: Transform skills batch 151-223 to docs/reference/skills/
F.8.1.3.4: Generate skills category index page

F.8.1.4: Transform Commands (186)

F.8.1.4.1: Transform commands batch 1-60 to docs/reference/commands/
F.8.1.4.2: Transform commands batch 61-120 to docs/reference/commands/
F.8.1.4.3: Transform commands batch 121-186 to docs/reference/commands/
F.8.1.4.4: Generate commands category index page

F.8.1.5: Transform Standards (52)

F.8.1.5.1: Transform all 52 standards to docs/reference/standards/
F.8.1.5.2: Generate standards category index page
F.8.1.5.3: Migrate HOW-TO-CREATE-* guides to docs/how-to/create/

F.8.1.6: Transform Supporting Content

F.8.1.6.1: Transform hooks reference (118 hooks)
F.8.1.6.2: Transform scripts reference (key scripts only - ~50)
F.8.1.6.3: Transform workflow categories (19 categories)
F.8.1.6.4: Generate master reference index page

F.8.1.7: Deploy Phase 1

F.8.1.7.1: Build and test locally (npm run build)
F.8.1.7.2: Deploy to Cloud Run (docs.coditect.ai)
F.8.1.7.3: Verify all 2,145+ pages accessible
F.8.1.7.4: Submit sitemap to Google Search Console

F.8.1.8: Documentation Quality Fixes 🔴 P0 (Jan 9, 2026)

Status: 🔴 IN PROGRESS Priority: P0 - Critical (no broken links allowed) Goal: Fix all broken links, implement working search, add missing components

Agent Invocation:

Task(subagent_type="codi-documentation-writer", prompt="Fix documentation quality issues: (1) Fix Dashboard URL to auth.coditect.ai, (2) Fix all broken internal links in transform script, (3) Implement open source local search, (4) Add missing component types, (5) Redeploy with zero broken links.")

Issues Identified:

Dashboard URL incorrect (auth.coditect.ai → auth.coditect.ai)
~1000+ broken internal links to non-existent pages
Search not working (requires open source solution only)
Missing component types: getting-started, internal docs, hooks-python, shell-scripts

Tasks:

F.8.1.8.1: Fix Dashboard URL from auth.coditect.ai to auth.coditect.ai
F.8.1.8.2: Update transform script to neutralize all broken links
- Remove links to non-existent ADRs, hooks, standards
- Keep link text but use # for unavailable targets
- Add comprehensive link validation
F.8.1.8.3: Add missing component types to transform script
- getting-started (6 docs)
- internal-architecture, internal-deployment, etc. (426 docs)
- hooks-python (30 Python hooks)
- shell-scripts (35 shell scripts)
F.8.1.8.4: Replace search with open source solution (CODITECT custom or OSS only)
- Option A: docusaurus-lunr-search - Lunr-based, simple
- Option B: @cmfcmf/docusaurus-search-local - Better autocomplete UI
- Option C: CODITECT custom search using component-indexer.py
F.8.1.8.5: Re-transform all components with updated script
F.8.1.8.6: Build and verify zero broken links (npm run build with onBrokenLinks: 'throw')
F.8.1.8.7: Redeploy to Cloud Run (docs.coditect.ai)
F.8.1.8.8: Verify search functionality working

Open Source Search Options (No Algolia/Proprietary):

Option	Package	Features
A	`docusaurus-lunr-search`	Lunr.js based, simple, language support
B	`@cmfcmf/docusaurus-search-local`	Algolia-like UI, good autocomplete
C	CODITECT Custom	Use existing component-indexer.py with frontend

Sources:

Estimated Time: 4-6 hours

F.8.2: Phase 2 - Enhancement (Option 2) 🆕 P1

Status: 🔴 NOT STARTED Priority: P1 - Post Phase 1 Estimated Time: 40-60 hours Goal: Enhance reference pages with examples, cross-references, and use cases Depends On: F.8.1 (Phase 1 complete)

Agent Invocation:

Task(subagent_type="codi-documentation-writer", prompt="Create Phase 2 Enhancement: For each component reference page, add: (1) Real-world examples, (2) Cross-references to related components, (3) Common use cases, (4) Troubleshooting tips, (5) Video/diagram links where applicable.")

Tasks:

F.8.2.1: Agent Enhancement (Priority Agents)

F.8.2.1.1: Enhance top 20 agents by usage (add examples, use cases)
- orchestrator, senior-architect, codi-documentation-writer, devops-engineer, testing-specialist
- codebase-analyzer, security-specialist, database-architect, frontend-development, backend-development
F.8.2.1.2: Add cross-references to related agents
F.8.2.1.3: Add "See Also" sections with related skills/commands

F.8.2.2: Skill Enhancement (Priority Skills)

F.8.2.2.1: Enhance top 30 skills by usage (add code examples)
- moe-task-execution, api-design-patterns, testing-strategies, debugging-patterns
F.8.2.2.2: Add "When to Use" decision trees
F.8.2.2.3: Add "Composes With" sections showing skill combinations

F.8.2.3: Command Enhancement (Priority Commands)

F.8.2.3.1: Enhance top 25 commands (add CLI examples, screenshots)
- /orient, /cx, /cxq, /agent, /which, /commit, /checkpoint
F.8.2.3.2: Add "Common Workflows" combining multiple commands
F.8.2.3.3: Add troubleshooting sections for common errors

F.8.2.4: Cross-Reference System

F.8.2.4.1: Build component relationship graph
F.8.2.4.2: Auto-generate "Related Components" sections
F.8.2.4.3: Create "Component Finder" search page

F.8.2.5: Search Enhancement (Open Source Only)

F.8.2.5.1: Configure open source local search (docusaurus-lunr-search or @cmfcmf/docusaurus-search-local)
- Note: No Algolia/proprietary - CODITECT custom or OSS only
F.8.2.5.2: Index all component metadata for search
F.8.2.5.3: Add search facets by component type
F.8.2.5.4: Implement CODITECT custom search page using component-indexer.py (optional)

Estimated Time: 40-60 hours

F.8.3: Phase 3 - Full Content Creation (Option 3) 🆕 P2

Status: 🔴 NOT STARTED Priority: P2 - Comprehensive Documentation Estimated Time: 120-160 hours Goal: Create complete Diátaxis documentation with tutorials, how-to guides, explanations Depends On: F.8.2 (Phase 2 complete)

Agent Invocation:

Task(subagent_type="orchestrator", prompt="Coordinate Phase 3 Full Content Creation using MoE agent panel: (1) codi-documentation-writer for tutorials, (2) senior-architect for architecture explanations, (3) testing-specialist for testing tutorials, (4) devops-engineer for deployment guides.")

Tasks:

F.8.3.1: Tutorials (Learning-Oriented)

F.8.3.1.1: Create "Getting Started" tutorial (10-minute setup)
F.8.3.1.2: Create "Your First Agent" tutorial
F.8.3.1.3: Create "Your First Skill" tutorial
F.8.3.1.4: Create "Your First Command" tutorial
F.8.3.1.5: Create "Context Management Basics" tutorial
F.8.3.1.6: Create "MoE Orchestration Tutorial"
F.8.3.1.7: Create "Building a Complete Workflow" tutorial
F.8.3.1.8: Create video walkthroughs (Loom/YouTube) - Optional

F.8.3.2: How-To Guides (Task-Oriented)

F.8.3.3: Explanations (Understanding-Oriented)

F.8.3.3.1: Create "CODITECT Architecture Overview" explanation
F.8.3.3.2: Create "Agent System Deep Dive" explanation
F.8.3.3.3: Create "Context Management Philosophy" explanation
F.8.3.3.4: Create "MoE Verification Layer" explanation
F.8.3.3.5: Create "Continual Learning System" explanation
F.8.3.3.6: Create "Track Nomenclature Design" explanation
F.8.3.3.7: Create "Component Lifecycle" explanation
F.8.3.3.8: Migrate ADRs to explanation format (key 20 ADRs)

F.8.3.4: API Documentation

F.8.3.4.1: Generate API reference from OpenAPI spec
F.8.3.4.2: Create authentication guide
F.8.3.4.3: Create rate limiting documentation
F.8.3.4.4: Create webhook documentation
F.8.3.4.5: Create SDK documentation (Python, TypeScript)

F.8.3.5: Contributor Documentation

F.8.3.5.1: Migrate standards to contributor section
F.8.3.5.2: Create contribution guidelines
F.8.3.5.3: Create code style guide
F.8.3.5.4: Create testing guidelines
F.8.3.5.5: Create release process documentation

F.8.3.6: Interactive Elements

F.8.3.6.1: Add code playgrounds (Docusaurus playground plugin)
F.8.3.6.2: Add interactive component explorer
F.8.3.6.3: Add "Try it Now" buttons for commands
F.8.3.6.4: Add copy-to-clipboard for all code blocks

Estimated Time: 120-160 hours

F.8.4: Ongoing Maintenance 🆕 P3

Status: 🔴 NOT STARTED Priority: P3 - Continuous Goal: Keep documentation synchronized with component changes

Tasks:

F.8.4.1: Create GitHub Action for auto-sync on component changes
F.8.4.2: Create documentation quality metrics dashboard
F.8.4.3: Set up broken link monitoring
F.8.4.4: Create documentation review process

Estimated Time: 8-12 hours initial + ongoing maintenance

F.8 Total Estimated Time:

Phase 1 (Auto-Transform): 8-12 hours
Phase 2 (Enhancement): 40-60 hours
Phase 3 (Full Content): 120-160 hours
Maintenance Setup: 8-12 hours
Total: 176-244 hours

Track G: DMS Integration (CODITECT Document Management System)

Repository: submodules/ops/coditect-document-management/ Isolation Boundary: DMS frontend, auth integration, GitHub OAuth No Collision With: Tracks A-F (different product/repo) Depends On: Track B (SSO requires coditect.ai auth), Track C (DMS backend deployed)

Current Status:

✅ Backend API deployed at https://dms.coditect.ai
✅ Database migrations applied (pgvector 1536 dimensions)
✅ Celery workers running (3 API pods, 2 workers, 1 beat)
❌ Frontend GUI (0% - BLOCKING)
❌ SSO from coditect.ai (0% - BLOCKING)
❌ GitHub integration (0%)

G.1: DMS Auth Routes (Backend)

Files to Create/Modify:

src/backend/api/routes/auth.py (NEW)
src/backend/services/sso_service.py (NEW)
src/backend/api/routes/__init__.py (ADD auth routes)

Tasks:

G.1.1: SSO Token Validation

G.1.1.1: POST /api/v1/auth/sso - Validate coditect.ai JWT
G.1.1.2: JWT public key fetch from coditect.ai/.well-known/jwks.json
G.1.1.3: Claims extraction (user_id, email, org_id, entitlements)
G.1.1.4: Auto-provision DMS tenant on first SSO login
G.1.1.5: Return DMS-specific JWT with tenant context
G.1.1.6: Unit tests for SSO flow

G.1.2: Entitlement Verification

G.1.2.1: GET /api/v1/auth/entitlements - Check DMS entitlement
G.1.2.2: Middleware to reject users without dms entitlement
G.1.2.3: Graceful redirect to coditect.ai/pricing if no entitlement
G.1.2.4: Unit tests for entitlement checks

Estimated Time: 8-10 hours

G.2: GitHub OAuth Integration (Backend)

Files to Create/Modify:

src/backend/api/routes/github.py (NEW)
src/backend/services/github_service.py (NEW)
src/backend/services/document_ingestion.py (NEW)
src/backend/models/github_connection.py (NEW)

Tasks:

G.2.1: GitHub OAuth Flow

G.2.1.1: GET /api/v1/github/authorize - Redirect to GitHub OAuth
G.2.1.2: GET /api/v1/github/callback - Handle OAuth callback
G.2.1.3: Store GitHub access token (encrypted) per tenant
G.2.1.4: Token refresh handling
G.2.1.5: Unit tests for OAuth flow

G.2.2: Repository Connection

G.2.2.1: GET /api/v1/github/repos - List user's repositories
G.2.2.2: POST /api/v1/github/repos/{id}/connect - Connect repo for sync
G.2.2.3: DELETE /api/v1/github/repos/{id}/disconnect - Disconnect repo
G.2.2.4: GET /api/v1/github/connections - List connected repos
G.2.2.5: github_connections table (tenant_id, repo_id, repo_name, branch, last_sync)

G.2.3: Document Ingestion Pipeline

G.2.3.1: POST /api/v1/github/repos/{id}/sync - Manual sync trigger
G.2.3.2: Webhook handler for push events (POST /api/v1/webhooks/github)
G.2.3.3: File type filtering (md, txt, pdf, docx)
G.2.3.4: Celery task for async document processing
G.2.3.5: Chunking + embedding pipeline integration
G.2.3.6: Document metadata (source: github, repo, path, commit_sha)
G.2.3.7: Incremental sync (only changed files)
G.2.3.8: Unit tests for ingestion pipeline

Estimated Time: 16-20 hours

G.3: DMS Frontend Build

Files to Create:

src/frontend/src/App.tsx (NEW)
src/frontend/src/main.tsx (NEW)
src/frontend/src/pages/ (NEW - all pages)
src/frontend/src/components/ (NEW - all components)
src/frontend/src/services/ (NEW - API services)
src/frontend/src/hooks/ (NEW - React hooks)
src/frontend/src/stores/ (NEW - Zustand stores)
src/frontend/vite.config.ts (NEW)
src/frontend/tailwind.config.js (NEW)
src/frontend/tsconfig.json (NEW)

Tasks:

G.3.1: Project Setup

G.3.1.1: Vite + React 18 + TypeScript strict mode
G.3.1.2: Tailwind CSS configuration
G.3.1.3: React Router v6 with protected routes
G.3.1.4: TanStack Query for server state
G.3.1.5: Zustand for client state
G.3.1.6: API client with axios interceptors

G.3.2: SSO Landing & Auth

G.3.2.1: Landing page with "Sign in with CODITECT" button
G.3.2.2: SSO redirect to coditect.ai/auth/authorize?client_id=dms
G.3.2.3: Callback handler /auth/callback
G.3.2.4: Token storage and refresh
G.3.2.5: Auth context provider
G.3.2.6: Protected route wrapper
G.3.2.7: Logout flow (clear tokens, redirect to coditect.ai)

G.3.3: Document Management Pages

G.3.3.1: Dashboard page (document counts, search stats, recent activity)
G.3.3.2: Documents list page (paginated, filterable, sortable)
G.3.3.3: Document detail page (content, chunks, metadata)
G.3.3.4: Document upload page (drag-drop, multi-file)
G.3.3.5: Search page (semantic search with filters)
G.3.3.6: Search results with relevance highlighting

G.3.4: GitHub Integration Pages

G.3.4.1: GitHub connections page (list connected repos)
G.3.4.2: "Connect GitHub" button → OAuth flow
G.3.4.3: Repository browser (select repos to connect)
G.3.4.4: Sync status display (last sync, document count)
G.3.4.5: Manual sync trigger button
G.3.4.6: Disconnect confirmation modal

G.3.5: Settings & Admin

G.3.5.1: Settings page (API keys, preferences)
G.3.5.2: API key management (create, revoke, copy)
G.3.5.3: Usage metrics display
G.3.5.4: Tenant info (org name, plan, limits)

G.3.6: Shared Components

Estimated Time: 24-32 hours

G.4: DMS Deployment Updates

Files to Create/Modify:

deploy/kubernetes/frontend-deployment.yaml (NEW)
deploy/docker/Dockerfile.frontend (NEW)
deploy/kubernetes/ingress.yaml (UPDATE for frontend)
.github/workflows/deploy-frontend.yaml (NEW)

Tasks:

G.4.1: Frontend Docker image (Node build → Nginx serve)
G.4.2: GKE deployment manifest for frontend
G.4.3: Update ingress for dms.coditect.ai (/ → frontend, /api → backend)
G.4.4: GitHub Actions workflow for frontend CI/CD
G.4.5: Environment configuration (API URL, SSO URL)

Estimated Time: 4-6 hours

G.5: File Upload & Storage

Files to Create/Modify:

src/backend/services/storage_service.py (NEW)
src/backend/api/routes/upload.py (NEW)

Tasks:

G.5.1: GCS bucket creation for document storage
G.5.2: POST /api/v1/upload - Signed URL generation
G.5.3: Document processing trigger on upload complete
G.5.4: File type validation (pdf, docx, md, txt, html)
G.5.5: Max file size limits per plan tier
G.5.6: Virus scanning integration (optional)

Estimated Time: 6-8 hours

Track H: Framework Autonomy (V2 E001)

Source: V2-tasklist-with-checkboxes.md (merged 2026-01-04) Goal: Enable agents to discover, communicate, and coordinate without human intervention Status: 100% Complete (65/65 tasks) - Updated Jan 9, 2026 (H.4.3 Agent Routing COMPLETE)

H.1: Component Activation System

H.1.1: Inventory all components (1,716 total) ✅
H.1.2: Implement activation status tracking (component-activation-status.json) ✅
H.1.3: Create component activation API ✅
H.1.4: Activate first 50 critical components - 24h ✅ Completed Jan 8, 2026
- Commit: d9500bf3
- Components: 8 agents, 7 commands, 6 prompts, 1 hook, 28 skills
- Script: scripts/activate-critical-components.py
- Results: Activation rate 91% → 94% (1482/1577 activated)
H.1.5: Create component discovery service (Redis-backed) - 32h ✅ Completed Jan 8, 2026
- Commit: efa65b89
- Files: scripts/core/discovery_service.py (650 lines), test_discovery_service.py (22 tests), discovery_health_check.py
- Features: Redis/local backends, capability discovery, load balancing, health checks, heartbeat TTL
- CLI: python3 scripts/core/discovery_service.py --local register|list|find|stats
H.1.6: Implement capability-based agent discovery - 24h ✅ COMPLETE (Jan 8, 2026)
- Commit: 8c50241c
- Files: scripts/core/capability_discovery.py (742 lines), test_capability_discovery.py (30 tests)
- Features: Multi-signal capability extraction, FTS5 search, domain/action keywords, DiscoveryService sync
- CLI: python3 scripts/core/capability_discovery.py "task" / --domain security / --sync
H.1.7: Build component metadata registry - 16h ✅ COMPLETE (Jan 8, 2026)
- Commit: 76c5067e
- Files: scripts/core/component_metadata_registry.py (902 lines), test_component_metadata_registry.py (35 tests)
- Features: Unified registry consolidating 5 metadata sources, type/capability indexes, get/list/search API
- CLI: python3 scripts/core/component_metadata_registry.py --stats|--get|--list|--search
H.1.8: Test activation of 290 target components - 40h ✅ COMPLETE (Jan 8, 2026)
- Commit: e9bd1e28
- Files: scripts/core/activation_test_suite.py (806 lines), reports/activation-test-report.{json,html}
- Features: 8 test categories (file existence, readability, frontmatter, required fields, description quality, database registration, activation consistency)
- Results: 67.2% pass rate (285 passed, 34 failed, 105 warnings) out of 424 critical components
- Issues Found: 34 components with real issues (phantom test agents, missing titles, duplicate entries)
- CLI: python3 scripts/core/activation_test_suite.py [--verbose] [--report-format json|html]

H.2: Inter-Agent Communication Infrastructure

H.2.1: Deploy RabbitMQ message bus (dev environment) - 16h ✅ COMPLETE (Jan 8, 2026)
- Commit: fcedde5c
- Docker: docker/docker-compose.rabbitmq.yml, docker/rabbitmq/{rabbitmq.conf,definitions.json}
- Python: scripts/core/message_bus.py (841 lines), message_bus_health.py (782 lines)
- Tests: scripts/core/test_message_bus.py (33 tests, all passing)
- Exchanges: agent.tasks (topic), agent.broadcasts (fanout), agent.responses (direct), agent.events (topic)
- Features: Priority queues, TTL, correlation IDs, local fallback mode
- Usage: docker-compose -f docker/docker-compose.rabbitmq.yml up -d
H.2.2: Implement task queue manager (Redis + RQ) - 32h ✅ COMPLETE (Jan 8, 2026)
- Commit: 117744f0
- Python: scripts/core/task_queue_manager.py (~750 lines)
- Tests: scripts/core/test_task_queue_manager.py (43 tests, all passing)
- Features: Task lifecycle (pending→running→completed/failed/cancelled), priority levels (LOW to CRITICAL)
- Dependency Resolution: Automatic child unblocking, deadlock detection (DFS cycle detection)
- Retry Logic: Configurable exponential backoff (2^retry_count seconds)
- Redis: Uses existing Redis from docker/docker-compose.postgresql.yml
- Local Fallback: Heap-based priority queue for development without Redis
H.2.3: Create priority queue routing - 24h ✅ COMPLETE (Jan 8, 2026)
- Part A - Queue Router (Commit 0da5c956):
  - Files: scripts/core/priority_queue_router.py (950 lines), test_priority_queue_router.py (47 tests)
  - Features: Multiple named queues (critical/high/normal/background), 4 dequeue strategies (strict/weighted/round-robin/fair-share), priority boosting
- Part B - Agent Router (Commit bc3365ea):
  - Files: scripts/core/priority_router.py (~950 lines), test_priority_router.py (55 tests)
  - Features: AgentDiscoveryService (registry with capabilities/health/load), PriorityRouter (6 strategies)
  - Routing Strategies: least-loaded, round-robin, priority-first, capability-match, cost-optimized, latency-optimized
  - Integration: IntegratedRouter combines discovery + routing + optional MessageBus/TaskQueue
H.2.4: Implement circuit breaker pattern (PyBreaker) - 24h ✅ COMPLETE (Jan 8, 2026)
- Commit: 5ff62ffe
- Files: scripts/core/circuit_breaker.py (~975 lines), test_circuit_breaker.py (60 tests)
- Components: CircuitBreaker (state machine), CircuitBreakerRegistry, AgentCircuitBreaker, @circuit_breaker decorator, CircuitBreakerHealthCheck
- States: CLOSED → OPEN → HALF_OPEN with configurable thresholds and recovery timeouts
- Features: Sliding window failure counting, exception filtering, state callbacks, metrics, thread-safe, fallback routing
H.2.5: Build retry engine with exponential backoff - 16h ✅ COMPLETE (Jan 8, 2026)
- Commit: f54e593a (impl) + ad4c476d (test import fix)
- Files: scripts/core/retry_engine.py (~1,160 lines), test_retry_engine.py (~1,440 lines, 110 tests)
- Components: RetryEngine, RetryPolicy, RetryConfig, RetryWithCircuitBreaker, @retry decorator
- Backoff Strategies: Exponential, Linear, Fixed, Fibonacci, Decorrelated (AWS-style)
- Jitter Types: None, Full, Equal, Decorrelated (thundering herd prevention)
- Features: Sync/async execution, metrics tracking, predefined configs (aggressive/standard/conservative/quick/database/api), CircuitBreaker integration
H.2.6: Test agent-to-agent task delegation - 24h ✅ COMPLETE (2026-01-08)
- Test File: scripts/core/test_agent_delegation.py (42 tests)
- Coverage: All H.2 components (MessageBus, TaskQueue, Discovery, Router, CircuitBreaker, RetryEngine)
- Test Categories: Integration, Full Delegation Flow, Fault Tolerance, Performance, End-to-End
- Throughput: >100 delegations/sec (local mode)
H.2.7: Validate <5s task dispatch latency - 8h ✅ COMPLETE (2026-01-08)
- Commit: 2f98532a (test import fix)
- Test File: scripts/core/test_dispatch_latency.py (17 tests)
- Benchmark Results: scripts/core/latency_benchmark_results.json
- P99 Latency: <0.031ms (target: <5000ms) - SLA EXCEEDED BY 160,000x
- Throughput: >45,000 tasks/second (local mode)
- Coverage: Single dispatch, sequential, concurrent, burst, high-throughput scenarios
- Component Budgets: All components well under budget (Discovery, Routing, TaskQueue, MessageBus)
H.2.8: Deploy to GKE production cluster - 16h ✅ COMPLETE (2026-01-08)
- Directory: coditect-cloud-infra/kubernetes/agent-messaging/
- Base Manifests: namespace, secrets, configmaps, statefulsets, services, rbac, networkpolicies, pdbs
- Kustomize Overlays: dev (1 replica), staging (2 replicas), production (3 replicas)
- RabbitMQ: 3-node cluster with HA policies, pre-configured exchanges (agent.tasks, agent.broadcasts, agent.responses, agent.events)
- Redis: 3-node cluster with AOF+RDB persistence, Prometheus exporter sidecar
- Documentation: README.md with deployment, verification, troubleshooting guides

H.3: MoE Verification Layer (Constitutional Court Architecture)

Source: MOE-JUDGES-RESEARCH + CLAUDE-CODE-EVAL-LOOPS (Jan 8, 2026) Goal: Multi-model judge panels with ADR-derived rubrics and self-improving evaluation Status: 100% Complete (41/41 tasks) ✅ VERIFIED (2026-01-08) Research: analyze-new-artifacts/MOE-JUDGES-RESEARCH/, analyze-new-artifacts/CLAUDE-CODE-EVAL-LOOPS/ ADR: internal/architecture/adrs/ADR-060-moe-verification-layer.md ✅ Test Results: 243 tests passing across 6 test files Components:

config/judge-personas.json - 6 judge personas with model routing
config/judge-model-routing.json - Multi-model routing configuration
config/generated-rubrics/ - 27 ADR-derived rubric files
scripts/adr-rubric-generator.py - ADR constraint extraction
scripts/moe_classifier/core/ - persona_loader, rubric_merger, debate, consensus, models, multi_model_client
skills/self-improving-eval/ - Self-improving evaluation skill with eval_runner, critic_agent, improvement_applier, eval_loop

Architecture Overview:

┌─────────────────────────────────────────────────────────────────────┐
│                     CODITECT VERIFICATION LAYER                      │
├─────────────────────────────────────────────────────────────────────┤
│  SOLUTION MoE OUTPUT → JUDGE PANEL ORCHESTRATOR                      │
│                              │                                       │
│        ├───────────────┬─────┴─────┬───────────────┐                │
│        ▼               ▼           ▼               ▼                │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐  ┌───────────┐        │
│  │ Technical │  │Compliance │  │ Security  │  │  Domain   │        │
│  │ Architect │  │ Auditor   │  │ Analyst   │  │  Expert   │        │
│  │ (Claude)  │  │ (GPT-4o)  │  │(DeepSeek) │  │ (Qwen)    │        │
│  └───────────┘  └───────────┘  └───────────┘  └───────────┘        │
│        │               │           │               │                │
│        └───────────────┴─────┬─────┴───────────────┘                │
│                              ▼                                       │
│                    CONSENSUS ENGINE (2/3 threshold)                  │
│                    + DEBATE PROTOCOL (2-3 rounds)                    │
│                    + DISSENT RECORDING                               │
└─────────────────────────────────────────────────────────────────────┘

Component Impact Matrix:

Action	Component	Location	Priority
CREATE	`judge-personas.json`	`config/`	P0
CREATE	`adr-rubric-generator.py`	`scripts/`	P0
CREATE	`skills/self-improving-eval/`	`skills/`	P1
CREATE	ADR-060	`internal/architecture/adrs/`	P0
UPDATE	`consensus.py`	`scripts/moe_classifier/core/`	P0
UPDATE	`models.py`	`scripts/moe_classifier/core/`	P0
UPDATE	`moe-judges.md`	`commands/`	P1
UPDATE	`evaluation-framework/SKILL.md`	`skills/`	P1
EXTEND	`calibration.py`	`scripts/moe_classifier/core/`	P2
EXTEND	`evaluation_rubrics.md`	`skills/evaluation-framework/templates/`	P1

Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement Track H.3 MoE Verification Layer per MOE-JUDGES-RESEARCH: (1) create judge persona specifications; (2) implement ADR-to-Rubric generator; (3) add debate protocol to consensus; (4) enhance provenance tracking; (5) integrate multi-model judge panel")

H.3.1: Judge Persona Specifications (CREATE)

Goal: Detailed persona configs with evaluation dimensions, strictness, rubric weights Research: judge-persona-design-methodology.md, coditect-judge-implementation-guide.md

H.3.1.1: Create config/judge-personas.json schema - 4h ✅ (Jan 8, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Design JSON schema for judge personas with: persona_id, name, role, experience, evaluation_dimensions[], evaluation_style{strictness, focus, tolerance}, rubric_weights{}, red_flags[], prompt_template")
- Completed: Created comprehensive 450-line schema with configuration, diversity requirements, consensus mapping, verdict types, model routing
H.3.1.2: Implement Technical Architect persona - 4h ✅ (Jan 8, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create Technical Architect persona 'Marcus Rivera' with 22 years exp, HIGH strictness, focus on architecture/patterns/performance/ADR compliance, red_flags for god classes, tight coupling, hardcoded config")
- Completed: Marcus Rivera with 5 evaluation dimensions (architectural_soundness, design_patterns, error_handling, performance, adr_compliance), 7 red flags, claude-sonnet-4 routing
H.3.1.3: Implement Compliance Auditor persona - 4h ✅ (Jan 8, 2026)
- Agent: Task(subagent_type="compliance-specialist", prompt="Create Compliance Auditor persona 'Dr. Patricia Okonkwo' with CISA/CISSP/HCISPP certs, VERY HIGH strictness, HIPAA/FDA/SOC2 framework mappings, zero tolerance for gaps")
- Completed: Dr. Okonkwo with HIPAA 164.308/310/312, FDA 21 CFR Part 11, SOC2 references, gpt-4o routing, binary PASS/FAIL dimensions
H.3.1.4: Implement Security Analyst persona - 4h ✅ (Jan 8, 2026)
- Agent: Task(subagent_type="security-specialist", prompt="Create Security Analyst persona 'James Nakamura' with OSCP/GWAPT/CEH certs, ADVERSARIAL evaluation style, OWASP Top 10 checklist, assume-breach mindset")
- Completed: James Nakamura with full OWASP Top 10 (A01-A09:2021), severity classification (CRITICAL/HIGH/MEDIUM/LOW), deepseek-v3 routing
H.3.1.5: Implement Domain Expert persona (Healthcare) - 4h ✅ (Jan 8, 2026)
- Agent: Task(subagent_type="healthcare-domain-expert", prompt="Create Domain Expert persona 'Dr. Elena Vasquez' with MD/MS Biomedical Informatics, HIGH strictness, HL7 FHIR/SNOMED CT/LOINC expertise, patient safety focus")
- Completed: Dr. Vasquez with 5 patient safety red flags, clinical terminology (ICD-10/SNOMED/LOINC/RxNorm), qwen2.5-72b routing
H.3.1.6: Implement QA Evaluator persona - 4h ✅ (Jan 8, 2026)
- Agent: Task(subagent_type="codi-qa-specialist", prompt="Create QA Evaluator persona 'Priya Sharma' with ISTQB Advanced cert, METHODICAL style, test coverage dimensions, edge case focus")
- Completed: Priya Sharma with 5 testing dimensions, coverage targets (80%+ unit, 100% critical paths), claude-haiku-4-5 routing
H.3.1.7: Create persona loader utility - 4h ✅ (Jan 8, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/moe_classifier/core/persona_loader.py with load_persona(persona_id), get_prompt_template(persona, artifact, context), validate_persona_schema()")
- Completed: Created 900-line persona_loader.py with:
  - PersonaLoader class with full persona registry support
  - Model routing with 4-level priority: runtime override → env vars → routing config → persona config
  - get_prompt_template() with artifact/context injection
  - validate_persona_schema() and verify_panel_diversity()
  - Created config/judge-model-routing.json for separate model management
  - Updated init.py with all exports
H.3.1.8: Write persona unit tests - 4h ✅ Completed Jan 8, 2026
- Agent: Task(subagent_type="testing-specialist", prompt="Create tests/test_judge_personas.py with tests for: persona loading, schema validation, prompt template rendering, weight normalization")
- Output: scripts/moe_classifier/test_persona_loader.py
- Results: 48 tests across 12 test classes - all passing
- Coverage: Persona loading, schema validation, prompt templates, model routing, diversity verification, weight normalization, verdict mapping, trigger conditions, convenience functions, configuration access, reload, evaluation dimensions
- Bug Fix: Fixed JudgePersona hashability issue in get_personas_for_artifact() deduplication

H.3.2: ADR-to-Rubric Generator (CREATE)

Goal: Automatically extract evaluation rubrics from Architecture Decision Records Research: judge-persona-design-methodology.md Part 4

H.3.2.1: Create scripts/adr-rubric-generator.py - 8h ✅ Completed Jan 8, 2026
- Agent: Task(subagent_type="senior-architect", prompt="Create ADR rubric generator that: parses ADR Decision section, extracts MUST/SHOULD/MAY constraints via regex, generates evaluation rubrics with 1-3 scoring scales, outputs to config/generated-rubrics/")
- Output: scripts/adr-rubric-generator.py (~700 lines)
- Features: ADRParser, RubricGenerator, ADRRubricCLI classes
H.3.2.2: Implement constraint extraction regex patterns - 4h ✅ Completed Jan 8, 2026
- Agent: Task(subagent_type="senior-architect", prompt="Create constraint patterns: MUST = (must|shall|required|mandatory|will), SHOULD = (should|recommended|preferred), MAY = (may|optional|can). Extract technical requirements: encryption, TLS, AES, HIPAA, FHIR, FoundationDB, event sourcing")
- Completed: Implemented in ADRParser.CONSTRAINT_PATTERNS and TECHNICAL_PATTERNS
H.3.2.3: Implement rubric generation logic - 8h ✅ Completed Jan 8, 2026
- Agent: Task(subagent_type="senior-architect", prompt="Create GeneratedRubric dataclass with: source_adr, dimension, scale[1,2,3], score_descriptions{}, evaluation_steps[], weight. Generate from constraints with proper scoring boundaries.")
- Completed: GeneratedRubric, RubricDimension, Constraint dataclasses with G-EVAL pattern
H.3.2.4: Create rubric merge utility - 4h ✅ Completed Jan 8, 2026
- Agent: Task(subagent_type="senior-architect", prompt="Create merge_rubrics(base_rubric, generated_rubrics) that augments persona rubrics with ADR-specific dimensions, renormalizes weights")
- Output: scripts/moe_classifier/core/rubric_merger.py (~450 lines)
- Classes: RubricMerger, MergeStrategy, MergeConfig, MergeResult, MergedDimension
- Features: 4 merge strategies, conflict resolution, weight normalization, MUST constraint preservation
- Convenience: merge_rubrics(), merge_persona_with_adrs(), batch_merge_all_personas()
- Output: config/merged-rubrics/ with 5 merged persona files
H.3.2.5: Batch process all ADRs - 4h ✅ Completed Jan 8, 2026
- Agent: Task(subagent_type="senior-architect", prompt="Create batch command: python scripts/adr-rubric-generator.py --adr-dir internal/architecture/adrs/ --output config/generated-rubrics/")
- Results: 53 ADRs processed, 27 rubrics generated, 80 constraints/dimensions
- Output: config/generated-rubrics/ with 27 rubric files + _index.json
H.3.2.6: Write ADR generator tests - 4h ✅ Completed Jan 8, 2026
- Agent: Task(subagent_type="testing-specialist", prompt="Create tests/test_adr_rubric_generator.py with tests for: constraint extraction, rubric generation, weight normalization, batch processing, edge cases (no constraints, invalid ADR)")
- Output: scripts/moe_classifier/test_adr_rubric_generator.py
- Results: 39 tests across 12 test classes - all passing
- Coverage: ADR parsing, constraint extraction (MUST/SHOULD/MAY), technical terms, rubric generation, weight normalization, edge cases, rubric merger, merge strategies, convenience functions, serialization

H.3.3: Consensus Enhancement - Debate Protocol (UPDATE)

Goal: Add multi-round debate when judges disagree Research: coditect-judge-implementation-guide.md Part 3

H.3.3.1: Create DebateOrchestrator class - 8h
- Agent: Task(subagent_type="senior-architect", prompt="Add DebateOrchestrator to consensus.py with: MAX_DEBATE_ROUNDS=3, CONVERGENCE_THRESHOLD=0.8, orchestrate_debate(evaluations, artifact), _identify_disagreements(), _prepare_debate_context()")
H.3.3.2: Implement disagreement detection - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Create _identify_disagreements(evaluations) that detects: verdict-level disagreement (different verdicts), dimension-level disagreement (score gap >= 1.5)")
H.3.3.3: Implement debate context preparation - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Create _prepare_debate_context(evaluations, disagreements, round_num) that formats: AREAS OF DISAGREEMENT, per-persona positions with rationale excerpts, INSTRUCTIONS for debate")
H.3.3.4: Implement debate round execution - 8h
- Agent: Task(subagent_type="senior-architect", prompt="Create _conduct_debate_round(evaluations, debate_context, artifact) that sends debate context to each judge, collects updated evaluations, tracks convergence")
H.3.3.5: Integrate debate into calculate_consensus - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Modify calculate_consensus to: detect disagreement after initial voting, trigger debate if agreement < threshold, return final consensus after debate rounds")
H.3.3.6: Write debate protocol tests - 4h
- Agent: Task(subagent_type="testing-specialist", prompt="Create tests/test_debate_protocol.py with tests for: disagreement detection, debate context formatting, convergence checking, max rounds limit, final consensus after debate")
- Completion: Jan 08, 2026. Created scripts/moe_classifier/core/debate.py (~450 lines) with: DebateOrchestrator, DebateConfig, DebateResult, JudgeEvaluation, Verdict, Disagreement. Updated consensus.py with enable_debate_protocol(), convert_decisions_to_evaluations(), apply_judge_decisions_with_debate(). Created test_debate_protocol.py with 44 tests covering: agreement calculation, disagreement detection (verdict/dimension), context preparation, debate round execution, orchestration, summary generation, consensus integration. All tests pass.

H.3.4: Provenance Enhancement (UPDATE)

Goal: Full audit trail with model, timestamp, token usage per judge Research: coditect-judge-implementation-guide.md ConsensusResult

H.3.4.1: Enhance JudgeDecision model - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Update models.py JudgeDecision to add: model_used (str), timestamp (datetime), token_usage (int), raw_response (str), evaluation_start_time, evaluation_end_time")
H.3.4.2: Enhance ConsensusResult model - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Update models.py ConsensusResult to add: provenance_chain (List[Dict]), dissenting_views (List[Dict]), total_token_usage (int), total_latency_ms (int)")
H.3.4.3: Build provenance chain in consensus - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Update calculate_consensus to build provenance_chain with: persona, model, verdict, confidence, timestamp, token_usage for each evaluation")
H.3.4.4: Implement dissent recording - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Create _extract_dissent(evaluations, final_verdict) that captures: persona, verdict, confidence, rationale, key_concerns for dissenting judges")
H.3.4.5: Add provenance to classification log - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Update ClassificationResult.to_dict() to include full provenance_chain, dissenting_views, token_usage metrics")
H.3.4.6: Write provenance tests - 4h
- Agent: Task(subagent_type="testing-specialist", prompt="Create tests/test_provenance.py with tests for: provenance chain building, dissent extraction, token usage tracking, timestamp accuracy")
- Completion: Jan 08, 2026. Enhanced models.py with full provenance tracking: JudgeDecision (+7 fields: model_used, timestamp, token_usage, raw_response, evaluation_start_time, evaluation_end_time, dimension_scores, +latency_ms property, +to_provenance_dict()). Created DissentingView dataclass for audit trail. ConsensusResult (+5 fields: provenance_chain, dissenting_views, total_token_usage, total_latency_ms, debate_metadata, +build_provenance_chain(), +extract_dissent(), +get_provenance_summary()). ClassificationResult.to_dict() enhanced with provenance output, +build_full_provenance(). Created test_provenance.py with 35 tests. Total: 166 tests passing across all H.3.1-H.3.4 components.

H.3.5: Multi-Model Judge Panel (UPDATE)

Goal: Support diverse model families (Claude, GPT-4o, DeepSeek, Qwen) per PoLL research Research: moe-judge-architecture-analysis.md, PoLL pattern

H.3.5.1: Create model router configuration - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Create config/judge-model-routing.json with: persona_id → primary_model, backup_model. Example: technical_architect → claude-sonnet-4 / claude-opus-4.5, compliance_auditor → gpt-4o / claude-opus-4.5")
H.3.5.2: Implement multi-provider client - 8h
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/moe_classifier/core/multi_model_client.py with: get_completion(model, prompt, persona), supports: anthropic (Claude), openai (GPT-4o), together (DeepSeek), openrouter (Qwen)")
H.3.5.3: Update judge invocation for multi-model - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Update judges/base.py to use multi_model_client, route persona to configured model, fallback to backup on failure")
H.3.5.4: Implement model diversity verification - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Create verify_panel_diversity(judges) that ensures: min 3 model families, no single model > 40% weight. Raise error if diversity requirements not met.")
H.3.5.5: Update /moe-judges command - 4h
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Update commands/moe-judges.md to document: multi-model support, persona-to-model routing, diversity requirements, fallback behavior")
H.3.5.6: Write multi-model tests - 4h
- Agent: Task(subagent_type="testing-specialist", prompt="Create tests/test_multi_model_panel.py with tests for: model routing, fallback behavior, diversity verification, provider error handling")

H.3.6: Self-Improving Eval Loop (CREATE)

Goal: Automated eval-improve cycle with critic agent and F1 scoring Research: anthropic claude code eval loop example.md

H.3.6.1: Create skill structure - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Create skills/self-improving-eval/ with: SKILL.md, templates/, scripts/. Define skill purpose: automated eval execution, failure analysis, prompt improvement suggestions.")
H.3.6.2: Implement eval runner - 8h
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/self-improving-eval/eval_runner.py with: run_evals(prompt, test_cases), calculate_f1_score(results), save_results_to_db()")
H.3.6.3: Implement critic agent - 8h
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/self-improving-eval/critic_agent.py with: analyze_failures(results), propose_prompt_changes(failures), propose_eval_changes(failures). Returns structured improvement suggestions.")
H.3.6.4: Implement improvement applier - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/self-improving-eval/improvement_applier.py with: apply_prompt_changes(prompt, suggestions), apply_eval_changes(evals, suggestions), validate_changes()")
H.3.6.5: Create eval loop orchestrator - 8h
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/self-improving-eval/eval_loop.py with: run_improvement_cycle(prompt, evals, max_iterations=5), track F1 scores per iteration, stop on convergence or max iterations")
H.3.6.6: Add CI integration - 4h
- Agent: Task(subagent_type="devops-engineer", prompt="Create .github/workflows/eval-improvement.yml that: runs on schedule (weekly), executes eval loop, commits prompt/eval improvements if F1 improves, creates PR for review")
H.3.6.7: Write eval loop tests - 4h
- Agent: Task(subagent_type="testing-specialist", prompt="Create tests/test_self_improving_eval.py with tests for: F1 calculation, critic analysis, improvement application, loop termination, CI integration")

H.3.7: ADR and Documentation (CREATE)

Goal: Document verification layer architecture decisions

H.3.7.1: Create ADR-060-moe-verification-layer.md - 4h
- Agent: Task(subagent_type="senior-architect", prompt="Create ADR-060 documenting: Context (need for multi-perspective verification), Decision (Constitutional Court architecture), Consequences (multi-model costs, improved accuracy). Reference MOE-JUDGES-RESEARCH.")
H.3.7.2: Update CLAUDE.md with H.3 commands - 2h
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Add H.3 MoE Verification commands to CLAUDE.md: /moe-judges (updated), /adr-rubric-gen (new), /eval-improve (new)")

Total Estimated Time: ~180h (4.5 weeks at 40h/week)

H.4: Skills Optimization (Claude Code 2.1.0 Adoption)

Source: Claude Code 2.1.0 Release Analysis (Jan 9, 2026) Goal: Adopt context: fork frontmatter for heavy-scanning skills to prevent context pollution Status: 100% Complete (15/15 tasks) - H.4.1 + H.4.2 + H.4.3 COMPLETE (Jan 9, 2026) Reference: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md (2.1.0)

Background: Claude Code 2.1.0 introduced context: fork frontmatter option that runs skills in isolated sub-agent contexts. This prevents context pollution from heavy file scanning operations. Analysis of 229 CODITECT skills identified 6 Tier 1 candidates (heavy codebase scanning) and 7 Tier 2 candidates (batch analysis).

Tier Classification:

Tier	Criteria	Skills Count
Tier 1	Heavy codebase scanning (AST, security, naming)	6
Tier 2	Batch analysis (docs, components, architecture)	7
Tier 3	Situational (cloud, debugging, testing)	4

H.4.1: Tier 1 Skills - context:fork Migration (P0)

H.4.1.1: Update codebase-analysis-patterns skill - 0.5h
- Add context: fork and allowed-tools to frontmatter
- Skill scans entire codebase for architecture, dependencies, metrics
- Agent: Task(subagent_type="senior-architect", prompt="Add context: fork to skills/codebase-analysis-patterns/SKILL.md frontmatter with allowed-tools: Glob(*), Read(*), Grep(*)")
H.4.1.2: Update pattern-finding skill - 0.5h
- Add context: fork and allowed-tools to frontmatter
- Skill does AST parsing, clone detection across all files
- Agent: Task(subagent_type="senior-architect", prompt="Add context: fork to skills/pattern-finding/SKILL.md frontmatter")
H.4.1.3: Update security-scanning-patterns skill - 0.5h
- Add context: fork and allowed-tools to frontmatter
- Skill runs SAST/DAST scanning all code for vulnerabilities
- Agent: Task(subagent_type="security-specialist", prompt="Add context: fork to skills/security-scanning-patterns/SKILL.md frontmatter")
H.4.1.4: Update naming-enforcement skill - 0.5h
- Add context: fork and allowed-tools to frontmatter
- Skill checks every file against naming conventions
- Agent: Task(subagent_type="senior-architect", prompt="Add context: fork to skills/naming-enforcement/SKILL.md frontmatter")
H.4.1.5: Update moe-content-classification skill - 0.5h
- Add context: fork and allowed-tools to frontmatter
- Skill batch classifies documents, writes frontmatter
- Agent: Task(subagent_type="senior-architect", prompt="Add context: fork to skills/moe-content-classification/SKILL.md frontmatter")
H.4.1.6: Update codebase-navigation skill - 0.5h
- Add context: fork and allowed-tools to frontmatter
- Skill explores directory structure, indexes files
- Agent: Task(subagent_type="senior-architect", prompt="Add context: fork to skills/codebase-navigation/SKILL.md frontmatter")

H.4.2: Tier 2 Skills - context:fork Migration (P1)

H.4.2.1: Update documentation-quality skill - 0.5h
H.4.2.2: Update code-review-patterns skill - 0.5h
H.4.2.3: Update component-improvement skill - 0.5h
H.4.2.4: Update submodule-validation skill - 0.5h
H.4.2.5: Update explain skill - 0.5h
H.4.2.6: Update project-organization-patterns skill - 0.5h
H.4.2.7: Update architect-review-methodology skill - 0.5h

H.4.3: Agent Field Routing (Claude Code 2.1.0)

H.4.3.1: Add agent field to Tier 1 skills - 0.5h ✅ COMPLETE (2026-01-09)
- codebase-analysis-patterns → codebase-analyzer
- pattern-finding → codebase-pattern-finder
- security-scanning-patterns → security-scanning
- naming-enforcement → naming-convention-enforcer
- moe-content-classification → moe-content-classifier
- codebase-navigation → codebase-locator
H.4.3.2: Add agent field to Tier 2 skills - 0.5h ✅ COMPLETE (2026-01-09)
- documentation-quality → documentation-quality-agent
- code-review-patterns → orchestrator-code-review
- component-improvement → component-enhancer
- submodule-validation → submodule-orchestrator
- project-organization-patterns → project-organizer
- architect-review-methodology → architect-review
- explain → (general purpose, no specific agent)

Total Estimated Time: ~7h

Track I: UI Components Library (V2 E002)

Source: V2-tasklist-with-checkboxes.md (merged 2026-01-04) Goal: Integrate Toon design system with generative UI capabilities Status: 0% Complete (0/13 tasks)

I.1: React Component Library

I.1.1: Setup React + TypeScript project structure - 8h
I.1.2: Import Toon design tokens (colors, typography, spacing) - 16h
I.1.3: Build foundational components (Button, Input, Card, etc.) - 80h
I.1.4: Create form components with validation - 40h
I.1.5: Build data display components (Table, List, Grid) - 60h

I.2: Generative UI Engine

I.2.1: Design generative UI architecture - 24h
I.2.2: Implement LLM-to-component mapping - 40h
I.2.3: Build UI preview and refinement workflow - 32h
I.2.4: Create demo applications - 24h

I.3: Accessibility & Documentation

I.3.1: Implement ARIA attributes across components - 40h
I.3.2: Keyboard navigation support - 32h
I.3.3: Setup Storybook with all components - 24h
I.3.4: WCAG 2.1 AA compliance audit and fixes - 40h

Track J: Memory Intelligence (V2 E003)

Source: V2-tasklist-with-checkboxes.md (merged 2026-01-04) Goal: Eliminate context loss across sessions with intelligent memory Status: 55% Complete (18/33 tasks) - J.5, J.6, J.7 COMPLETE ✅ Updated: January 09, 2026

J.1: Enhanced Context Database

J.1.1: Design enhanced context.db schema - 16h
J.1.2: Implement dual-write (SQLite → FDB) pattern - 32h
J.1.3: Migrate existing 76,390 messages to new schema - 24h
J.1.4: Implement FDB multi-tenant key schema - 24h
J.1.5: Validate data integrity post-migration - 16h

J.2: Decision Extraction Automation

J.2.1: Build LLM-based decision extraction pipeline - 40h
J.2.2: Create decision validation workflow - 24h
J.2.3: Implement automated tagging and categorization - 32h

J.3: Knowledge Graph

J.3.1: Design knowledge graph schema - 24h
J.3.2: Implement graph relationship extraction - 40h
J.3.3: Build 10K+ relationship dataset - 32h
J.3.4: Create graph query API - 32h

J.4: Enhanced /cxq Query System

J.4.1: Implement semantic search over messages - 40h
J.4.2: Add vector search with pgvector - 32h
J.4.3: Optimize query performance to <100ms p95 - 24h

J.5: Reasoning Trace Capture (Agentic Metadata P0)

Agent: reasoning-trace-specialist Priority: P0 (Critical for debugging & continuous improvement) Source: CONTEXT-MEMORY-OPTIMIZATION-ANALYSIS-2026-01-06.md

J.5.1: Create reasoning_traces schema in context.db - 8h
J.5.2: Add trace extraction to unified-message-extractor.py - 16h
J.5.3: Implement /cxq --traces query command - 8h
J.5.4: Build trace visualization output - 8h
J.5.5: Create failure pattern detection - 16h
J.5.6: Integrate with session-retrospective hook - 8h

J.6: Token Economics Dashboard (Agentic Metadata P0)

Agent: token-economics-analyst Priority: P0 (Critical for cost visibility & optimization) Source: CONTEXT-MEMORY-OPTIMIZATION-ANALYSIS-2026-01-06.md

J.6.1: Create token_economics schema in context.db - 8h
J.6.2: Add token extraction to unified-message-extractor.py - 16h
J.6.3: Implement /cxq --costs query command - 8h
J.6.4: Build daily cost report generator - 8h
J.6.5: Create optimization recommendation engine - 16h
J.6.6: Add budget alert system - 8h

J.7: Tool Call Analytics (Agentic Metadata P1)

Agent: tool-analytics-specialist Priority: P1 (Important for workflow optimization) Source: CONTEXT-MEMORY-OPTIMIZATION-ANALYSIS-2026-01-06.md

J.7.1: Create tool_analytics schema in context.db - 8h
J.7.2: Add tool extraction to unified-message-extractor.py - 16h
J.7.3: Implement /cxq --tools query command - 8h
J.7.4: Build tool sequence detector - 16h
J.7.5: Create success rate dashboard - 8h
J.7.6: Add workflow optimization recommendations - 16h

Track K: Workflow Automation (V2 E004)

Source: V2-tasklist-with-checkboxes.md (merged 2026-01-04) Goal: Business process automation with visual workflow designer Status: 0% Complete (0/10 tasks)

K.1: Custom Workflow Engine

K.1.1: Design workflow engine architecture - 24h
K.1.2: Implement workflow parser (YAML/JSON) - 32h
K.1.3: Build state machine execution logic - 40h

K.2: Workflow Templates Library

K.2.1: Create 25+ workflow templates (CI/CD, testing, deployment) - 80h
K.2.2: Build template customization UI - 40h

K.3: Visual Workflow Designer

K.3.1: Design visual workflow editor UI - 40h
K.3.2: Implement drag-and-drop workflow builder - 60h

K.4: Approval Routing System

K.4.1: Implement approval routing logic - 32h
K.4.2: Build notification system (email, Slack) - 24h
K.4.3: Build workflow analytics dashboard - 40h

Track L: Extended Testing (V2 E005)

Source: V2-tasklist-with-checkboxes.md (merged 2026-01-04) Goal: Comprehensive automated testing and quality gates Status: 0% Complete (0/10 tasks) Note: Complements Track E with framework-level testing infrastructure

L.1: Test Framework Infrastructure

L.1.1: Expand test suite beyond 78 existing tests - 80h
L.1.2: Implement code coverage tracking (pytest-cov) - 16h
L.1.3: Achieve 80%+ code coverage across codebase - 120h

L.2: Git Hooks & Quality Gates

L.2.1: Activate pre-commit hooks (38 defined) - 24h
L.2.2: Implement pre-push test validation - 16h

L.3: Performance Testing

L.3.1: Build load testing suite (Locust/K6) - 40h
L.3.2: Implement performance benchmarks - 32h

L.4: Security Testing

L.4.1: Integrate SAST tools (Bandit, Semgrep) - 24h
L.4.2: Setup DAST scanning (OWASP ZAP) - 32h
L.4.3: Implement dependency vulnerability scanning - 16h

Track M: Extended Security (V2 E008)

Source: V2-tasklist-with-checkboxes.md (merged 2026-01-04) Goal: Enterprise-grade security and audit compliance Status: 0% Complete (0/15 tasks) Note: Some tasks may overlap with Track D - verify before starting

M.1: Identity Platform & Authentication

M.1.1: Setup GCP Identity Platform - 24h
M.1.2: Configure OAuth2/OIDC providers (Google, GitHub) - 32h
M.1.3: Setup DNS A record: auth.coditect.ai → 136.110.206.100 - 4h
M.1.4: Activate SSL certificate for auth.coditect.ai - 8h
M.1.5: Build auth.coditect.ai frontend (React + Stripe) - 60h
M.1.6: Implement JWT middleware for API authentication - 24h

M.2: License Management System

M.2.1: Design license key generation algorithm - 16h
M.2.2: Build license issuance workflow - 32h
M.2.3: Implement license validation API - 24h
M.2.4: Create license revocation system - 16h

M.3: Secret Management & Audit

M.3.1: Integrate GCP Secret Manager - 24h
M.3.2: Implement comprehensive audit logging - 32h
M.3.3: Build compliance reports (SOC2, GDPR prep) - 40h

M.4: Security Testing

M.4.1: Conduct penetration testing - 80h
M.4.2: Remediate security findings - 60h

Track N: GTM & Launch (V2 E010)

Source: V2-tasklist-with-checkboxes.md (merged 2026-01-04) Goal: Public launch with beta testing and pilot programs Status: 15% Complete (3/20 tasks)

N.1: Beta Testing Program ✅ COMPLETE

N.1.1: Recruit 50 beta users ✅
N.1.2: Conduct 4-week beta testing ✅
N.1.3: Analyze beta feedback (Dec 10 analysis) ✅

N.2: Pilot Phase 1 (Dec 24 - Jan 21)

N.2.1: Setup pilot customer infrastructure - 32h
N.2.2: Create pilot onboarding materials - 24h
N.2.3: Recruit first 10 pilot customers - 40h
N.2.4: Onboard pilot customers (Week 4-5) - 80h
N.2.5: Setup feedback collection system - 24h
N.2.6: Provide dedicated pilot support - 160h

N.3: Pilot Phase 2 (Jan 21 - Feb 18)

N.3.1: Recruit additional 40 pilot customers - 60h
N.3.2: Onboard Pilot Phase 2 customers - 160h
N.3.3: Iterate on pilot feedback (weekly releases) - 120h
N.3.4: Build enterprise features based on requests - 80h
N.3.5: Conduct pilot customer interviews for case studies - 40h

N.4: GTM Preparation & Launch (Feb 18 - Mar 11)

N.4.1: Write 3-5 pilot customer case studies - 60h
N.4.2: Create marketing materials (website, collateral) - 80h
N.4.3: Build launch event plan and materials - 40h
N.4.4: Conduct launch readiness review (Mar 4) - 16h
N.4.5: Execute public launch event (Mar 11) - 24h
N.4.6: Setup post-launch support (90 days) - 40h

V2 Completed Tracks (Reference Only)

The following V2 epics are 100% complete and preserved for reference:

E006: Deployment Infrastructure ✅ COMPLETE

FDB 3-node StatefulSet: ✅
CODITECT API v5: ✅
Theia IDE: ✅
Cloud SQL PostgreSQL: ✅
Redis Memorystore: ✅
ArgoCD GitOps: ✅
Gitea Git server: ✅
Uptime: >99.9% (79 days)
Monthly cost: $280

E007: Documentation System ✅ COMPLETE

456K+ words documentation
10 getting started guides
15 user guides
ADRs + C4 diagrams
1,716 component reference

E009: Analytics & Observability ✅ COMPLETE

Prometheus server: ✅
Custom metrics exporters: ✅
Jaeger tracing: ✅
OpenTelemetry instrumentation: ✅
Loki log aggregation: ✅
Grafana dashboards: ✅
PagerDuty integration: ✅

Dependency Graph & Execution Order

PHASE 1: PARALLEL START (No Dependencies)
├── Track A.1: Backend Heartbeat System ────┐
├── Track B.1: Frontend Setup ──────────────┼──┐
├── Track D.1: P0 Security Hardening ───────┼──┼──┐
├── Track F.1: User Documentation ──────────┘  │  │
└── Track G.1: DMS Auth Routes ─────────────────┘  │  (DMS backend already deployed)
                                               │  │
PHASE 2: PARALLEL BUILD (Track A → B dependency)
├── Track A.2: Admin Dashboard API ─────────────┤
├── Track A.3: Commerce API ────────────────────┤
├── Track B.2: Auth Pages ◄─────────────────────┘
├── Track B.3: Commerce/Checkout Pages ─────────┤
├── Track D.2: P1 Security ─────────────────────┤
├── Track F.2: API Documentation ───────────────┤
├── Track G.2: GitHub OAuth Integration ────────┤  (DMS - parallel)
└── Track G.3.1: DMS Frontend Setup ────────────┘  (DMS - parallel)

PHASE 3: PARALLEL BUILD (Continues)
├── Track B.4: Dashboard Pages ─────────────────┤
├── Track B.5: Shared Components ───────────────┤
├── Track C.1: Backend Deployment ──────────────┤
├── Track G.3.2-3.4: DMS Pages ─────────────────┤  (DMS frontend build)
└── Track G.5: File Upload & Storage ───────────┘  (DMS)

PHASE 4: DEPLOYMENT (Track A, B complete)
├── Track C.2: Frontend Deployment ◄────────────┤
├── Track C.3: DNS & Networking ────────────────┤
└── Track G.4: DMS Frontend Deployment ─────────┘  (DMS)

PHASE 5: INTEGRATION (All Tracks Complete)
├── Track E.1: E2E Flow Testing ────────────────┤
├── Track E.2: Security Testing ────────────────┤
├── Track E.3: Platform Testing ────────────────┤
└── Track G.6: DMS E2E Testing ─────────────────┘  (DMS SSO + GitHub flow)

PHASE 6: LAUNCH
├── Track F.3: Support Preparation ─────────────┤
└── Track G.7: DMS Documentation ───────────────┘  (DMS user guide)

Session Assignment Matrix

Core Platform Sessions (Tracks A-F)

Session	Track(s)	Agent Type	Files/Dirs Owned	Est. Hours
S1	A.1, A.2, A.3, A.4	`senior-architect`	`backend/client/`, `backend/api/v1/views/admin.py`, `backend/commerce/`, `backend/context/*`	24-34
S2	B.1, B.2	`frontend-react-typescript-expert`	`frontend/src/pages/auth/*`, `frontend/src/hooks/useAuth.ts`	14-19
S3	B.3, B.4	`frontend-react-typescript-expert`	`frontend/src/pages/dashboard/`, `frontend/src/services/`	16-20
S4	B.5	`frontend-react-typescript-expert`	`frontend/src/components/`, `frontend/src/styles/`	8-10
S5	C.1, C.2	`devops-engineer`	`infra/kubernetes/`, `infra/docker/`	10-14
S6	C.3	`cloud-architect`	`infra/terraform/dns/*`, GCP Console	2-3
S7	D.1, D.2	`security-specialist`	`backend/api/middleware/*`, `backend/models/audit_log.py`	8-12
S8	E.1, E.2, E.3	`testing-specialist`	`/tests/`, test scripts	18-26
S9	F.1, F.2, F.3	`codi-documentation-writer`	`docs/guides/`, `docs/reference/`	10-15

DMS Product Sessions (Track G)

Session	Track(s)	Agent Type	Files/Dirs Owned	Est. Hours
S10	G.1	`senior-architect`	`dms/src/backend/api/routes/auth.py`, `dms/src/backend/services/sso_service.py`	8-10
S11	G.2	`senior-architect`	`dms/src/backend/api/routes/github.py`, `dms/src/backend/services/github_service.py`	16-20
S12	G.3.1-G.3.2	`frontend-react-typescript-expert`	`dms/src/frontend/src/pages/auth/`, `dms/src/frontend/src/stores/`	10-12
S13	G.3.3-G.3.4	`frontend-react-typescript-expert`	`dms/src/frontend/src/pages/documents/`, `dms/src/frontend/src/pages/github/`	14-18
S14	G.3.5-G.3.6	`frontend-react-typescript-expert`	`dms/src/frontend/src/components/`, `dms/src/frontend/src/pages/settings/`	10-14
S15	G.4	`devops-engineer`	`dms/deploy/kubernetes/`, `dms/deploy/docker/`	4-6
S16	G.5	`cloud-architect`	`dms/src/backend/services/storage_service.py`, GCS bucket	6-8

Total Estimated Hours (Core): 106-147 hours (parallelized to ~35-45 hours wall-clock) Total Estimated Hours (DMS): 68-88 hours (parallelized to ~20-25 hours wall-clock) Grand Total: 174-235 hours (parallelized to ~45-55 hours wall-clock with max concurrency)

Collision Prevention Rules

File Ownership

Each session owns specific directories/files. NEVER modify files owned by another session.

Path Pattern	Owned By
`backend/client/*`	S1
`backend/api/v1/views/admin.py`	S1
`backend/api/middleware/*`	S7
`backend/models/audit_log.py`	S7
`frontend/src/pages/auth/*`	S2
`frontend/src/pages/dashboard/*`	S3
`frontend/src/components/*`	S4
`frontend/src/services/*`	S3
`infra/kubernetes/*`	S5
`infra/terraform/*`	S6
`docs/guides/*`	S9
`/tests/`	S8

Shared File Protocol

For files that must be modified by multiple sessions:

requirements.txt: Each session adds dependencies in a separate PR, merged sequentially
package.json: Same as above
README.md: Only S9 (docs) modifies
.env.example: Only S5 (DevOps) modifies

Branch Strategy

main
├── feature/backend-heartbeat (S1)
├── feature/backend-admin-api (S1)
├── feature/frontend-auth-pages (S2)
├── feature/frontend-dashboard (S3)
├── feature/frontend-components (S4)
├── feature/deploy-backend (S5)
├── feature/deploy-frontend (S5)
├── feature/security-hardening (S7)
├── feature/integration-tests (S8)
└── feature/pilot-docs (S9)

Pre-Launch Checklist

Before proceeding to launch, ALL tracks must be complete:

Backend Complete (Track A)

Frontend Complete (Track B)

DevOps Complete (Track C)

C.1: Backend deployed to GKE ✅ (Jan 2)
C.2: Frontend deployed to GKE ✅ (Jan 2)
C.3: DNS configured and SSL working ✅ (Jan 2)
C.5: Licensed Docker Registry Setup ✅ (Jan 7, 2026)
C.6: Licensed Container Image Build (ADR-055) ✅ (Jan 5, 2026)
- C.6.1-C.6.3: Base, Docker, Workstation Dockerfiles with root-owned protection
- C.6.4-C.6.5: Framework protection implementation & security tests (83 tests)
- C.6.6-C.6.8: CI/CD, Docker Content Trust (Cosign/KMS), local dev migration, documentation (93 tests total)

Security Complete (Track D)

D.1: P0 security (rate limiting, headers, login protection) ✅ (Jan 9 - D.1.4 rate limiting added)
D.2: P1 security (audit logging, input validation) ✅ (Jan 1)
D.3: 2FA Authentication ✅ (Jan 2) - v1.16.0-2fa-login deployed

Testing Complete (Track E)

E.1: E2E flow tested ✅ (Jan 1) - 5 test files, ~2,200 lines, 70 tests
E.2: Security tested
E.3: All platforms tested

Documentation Complete (Track F)

F.1: User guides updated
F.2: API docs generated
F.3: Support ready

DMS Product Complete (Track G)

Appendix A: Source Documents Consolidated

Document	Location	Key Tasks Extracted
PILOT-LAUNCH-CONSOLIDATED-PLAN.md	`internal/project/plans/`	Backend Phases 0-4
PILOT-LAUNCH-CHECKLIST.md	`internal/project/`	Day-by-day checklist
coditect-cloud-backend/tasklist.md	`submodules/cloud/`	273 tasks, 128 complete
coditect-cloud-frontend/project-plan.md	`submodules/cloud/`	50 tasks, 0 complete
Stripe/tasklist-with-checkboxes.md	`submodules/integrations/`	171 tasks, 3 complete
E010-ROLLOUT-GTM/tasklist.md	`internal/project/v2/epics/`	3189 tasks (template)
docs/project-management/tasklist.md	`docs/`	1629 master tasks

Appendix B: Agent Assignment Recommendations

Core Platform (Tracks A-F)

Track	Recommended Agent	Reason
A.1, A.2, A.3	`senior-architect`	Backend patterns, async Python, commerce
B.1-B.5	`frontend-react-typescript-expert`	React 18, TypeScript, TailwindCSS
C.1-C.3	`devops-engineer` + `k8s-statefulset-specialist`	GKE, Kubernetes, Terraform
D.1, D.2	`security-specialist`	Rate limiting, audit logging
E.1-E.3	`testing-specialist`	E2E, integration, platform tests
F.1-F.3	`codi-documentation-writer`	User guides, API docs

DMS Product (Track G)

Track	Recommended Agent	Reason
G.1	`senior-architect`	SSO/JWT integration, FastAPI
G.2	`senior-architect`	OAuth flows, webhook handlers
G.3.1-G.3.6	`frontend-react-typescript-expert`	React 18, Vite, TailwindCSS
G.4	`devops-engineer`	Docker, GKE deployment
G.5	`cloud-architect`	GCS buckets, IAM, signed URLs
G.6	`testing-specialist`	E2E flows with SSO + GitHub
G.7	`codi-documentation-writer`	DMS user guide

Document Control:

Created: December 29, 2025
Updated: January 2, 2026 (Product delivery tracks added)
Author: CODITECT Engineering Team
Version: 1.10.0
Review: Before starting parallel execution
Next Update: After Cloud Workstations or Docker Registry implementation

Recent Updates:

v1.9.4: Track F.2 (API Documentation) - F.2.1 & F.2.2 COMPLETE, @extend_schema decorators + API-REFERENCE.md created, Documentation 85%
v1.10.0: A.7 (Cloud Workstations Provisioning), A.8 (Docker Heartbeat), C.5 (Licensed Docker Registry) added - 18 new tasks for product delivery
v1.9.2: B.12.5 (docs.coditect.ai content pages) added - 5 content tasks marked WIP, agent invocations ready
v1.9.1: Added explicit agent invocations as sub-tasks for Tracks D, E, F, B.3.4, B.12.3, B.12.4 - copy-paste ready for MoE execution
v1.9.0: Track A.3 (Commerce API) COMPLETE - Stripe webhook, entitlement revocation, 25 unit tests
v1.8.0: Track B.3 (Commerce UI) COMPLETE - ProductCatalog, ShoppingCart, Checkout page, GooglePay + Stripe, 70% frontend
v1.7.1: B.12.1 (focus-offset, border-radius, font doc) & B.12.2 (Lucide icons) COMPLETE - 98% design system compliance
v1.7.0: Track B.12 (Design System Compliance) added - 93% audit complete, @coditect/ui package planned
v1.6.0: Track C.4 (External Sites) added - docs.coditect.ai, workflow.coditect.ai, email infrastructure
v1.5.1: Website-builder framework components - agent, skill, commands, scripts, workflows created
v1.5.0: Track B.7, B.8, B.9 COMPLETE - 7 new pages, 6 reusable templates, v1.5.0-website-pages deployed
v1.4.0: Track B.6 COMPLETE - Dark mode support, ADR-015 website architecture with customer flows
v1.3.0: Track A.4 (Context Sync API) added - JWT unified auth, push/pull sync, MoE architecture decision
v1.2.0: Added CHECKOUT-PROCESS-DETAILED.md reference, linked A.3 and B.3 to checkout documentation
v1.1.0: Track G (DMS Integration) added - SSO, GitHub OAuth, frontend GUI
v1.0.0: Initial 6-track parallel execution plan

Appendix C: Frontend Repository Reference

Main Platform (coditect.ai)

Location: submodules/cloud/coditect-cloud-ide/

Component	Details
Framework	React 18.2 + Vite + TypeScript
UI Library	Chakra UI 2.8.2
IDE	Eclipse Theia 1.65
State	Zustand 4.4.7
Routing	React Router 6.21
Data	TanStack Query 5.17

Key Pages:

src/pages/LoginPage.tsx - Login
src/pages/RegisterPage.tsx - Registration
src/pages/ConversationListPage.tsx - Conversations
src/pages/DocumentationPage.tsx - Docs
src/stores/authStore.ts - Auth state

Auth Portal (auth.coditect.ai)

Location: submodules/cloud/coditect-cloud-frontend/

Component	Details
Framework	React 18 + Vite + TypeScript
UI Library	Tailwind CSS
State	TBD

Key Pages:

src/pages/Landing.tsx
src/pages/Pricing.tsx
src/pages/Register.tsx
src/pages/Login.tsx
src/pages/Dashboard.tsx

DMS (dms.coditect.ai)

Location: submodules/ops/coditect-document-management/src/frontend/

Component	Details
Framework	React 18 + Vite + TypeScript
UI Library	Tailwind CSS
State	Zustand
Data	TanStack Query

Current Components (analytics only):

components/analytics/Dashboard.tsx
components/analytics/MetricCard.tsx
components/analytics/SearchAnalyticsChart.tsx

To Build (Track G):

Full application shell
SSO auth flow
Document management pages
GitHub integration pages
Settings pages

Executive Summary
- Current Status (Jan 09, 2026)
- 🚨 Critical Path (Jan 6 Assessment - Updated)
ADR-047 Roadmap Alignment
- Vision Summary (ADR-047)
- MVP → Full Vision Migration Path
- Track → ADR-047 Domain Mapping
- Future Tracks (Post-Pilot)
- Track N: Gateway API Migration - ✅ NOT REQUIRED (Jan 7, 2026 Audit)
Frontend Repository Mapping
- coditect.ai API Endpoints (Discovered)
- DMS API Endpoints (Live at dms.coditect.ai)
Architecture: Parallel Session Tracks
Critical Path Execution Order (January 9, 2026)
- ✅ BLOCKERS (Resolved)
- Phase 1: Critical Infrastructure [CP-1 to CP-13]
- Phase 2: Documentation & Quality [CP-11 to CP-20]
- Phase 3: Launch Preparation [CP-21 to CP-30]
- Phase 4: DMS Product (Parallel Track) [CP-D1 to CP-D15]
- Phase 5: Extended Tracks (Post-Launch) [CP-X1 to CP-X10]
- Execution Summary
- Recommended Execution Order
Track A: Backend Completion
- A.1: Step 7 - Client Heartbeat System
- A.2: Step 9 - Admin Dashboard API
- A.3: Commerce API (Multi-Product Checkout) ✅ COMPLETE
- A.4: Context Sync API (Multi-Device Session Sync)
- A.5: Team/Project Context Sync (Multi-Level Backup)
- A.6: Reference Data - ISO Standard Contact Management ✅ COMPLETE
- A.7: Cloud Workstations Provisioning API (P1)
- A.8: Docker Image Heartbeat System (P1)
- A.9: Cloud Context Task Sync (ADR-053 Implementation)
- A.10: Container Session Lifecycle API (ADR-055) ✅ 100%
- A.11: Cloud Workstation Broker Service (ADR-005 Implementation) ✅ 100%
- A.12: Team & License Management ✅ 90%
- A.13: System Administration - License & Workstation Override 🆕 (Jan 9, 2026)
Track B: Frontend Build
- B.1: Project Setup Enhancement
- B.2: Authentication Pages
- B.3: Commerce & Multi-Product Checkout
- B.4: Dashboard & License Management
- B.5: Shared Components & Styling ✅ COMPLETE
- B.6: Dark Mode & UI Polish
- B.7: Legal & Account Pages (P0 - BLOCKING)
- B.8: Product & Company Pages (P1 - Pre-Launch)
- B.9: Post-Launch Pages (P2)
- B.10: Future Pages (P3)
- B.11: Reusable Page Templates (BONUS)
- B.12: Design System Compliance & @coditect/ui Package
Track C: DevOps & Deployment
- C.1: Backend Deployment
- C.2: Frontend Deployment
- C.3: DNS & Networking
- C.4: External Sites & Subdomains
- C.5: Licensed Docker Registry Setup ✅
- C.6: Licensed Container Image Build (ADR-055)
Track D: Security Hardening
- D.1: P0 Security (BLOCKING for Launch)
- D.2: P1 Security (High Priority)
- D.3: Two-Factor Authentication (2FA) ✅ COMPLETE
Track E: Integration Testing
- E.1: End-to-End Flow Testing
- E.2: Security Testing
- E.3: Platform Testing ✅ COMPLETE
Track F: Documentation & Support
- F.1: User Documentation
- F.2: API Documentation
- F.3: Support Preparation
- F.4: Track Nomenclature Standard (Customer Extensibility) ✅ COMPLETE
- F.5: Component Quality Improvement (Agents, Skills)
- F.6: SSOT Consolidation (Single Source of Truth)
- F.7: User Workflow Documentation 🆕
- F.8: docs.coditect.ai Content Development 🆕
Track G: DMS Integration (CODITECT Document Management System)
- G.1: DMS Auth Routes (Backend)
- G.2: GitHub OAuth Integration (Backend)
- G.3: DMS Frontend Build
- G.4: DMS Deployment Updates
- G.5: File Upload & Storage
Track H: Framework Autonomy (V2 E001)
- H.1: Component Activation System
- H.2: Inter-Agent Communication Infrastructure
- H.3: MoE Verification Layer (Constitutional Court Architecture)
- H.4: Skills Optimization (Claude Code 2.1.0 Adoption)
Track I: UI Components Library (V2 E002)
- I.1: React Component Library
- I.2: Generative UI Engine
- I.3: Accessibility & Documentation
Track J: Memory Intelligence (V2 E003)
- J.1: Enhanced Context Database
- J.2: Decision Extraction Automation
- J.3: Knowledge Graph
- J.4: Enhanced /cxq Query System
- J.5: Reasoning Trace Capture (Agentic Metadata P0)
- J.6: Token Economics Dashboard (Agentic Metadata P0)
- J.7: Tool Call Analytics (Agentic Metadata P1)
Track K: Workflow Automation (V2 E004)
- K.1: Custom Workflow Engine
- K.2: Workflow Templates Library
- K.3: Visual Workflow Designer
- K.4: Approval Routing System
Track L: Extended Testing (V2 E005)
- L.1: Test Framework Infrastructure
- L.2: Git Hooks & Quality Gates
- L.3: Performance Testing
- L.4: Security Testing
Track M: Extended Security (V2 E008)
- M.1: Identity Platform & Authentication
- M.2: License Management System
- M.3: Secret Management & Audit
- M.4: Security Testing
Track N: GTM & Launch (V2 E010)
- N.1: Beta Testing Program ✅ COMPLETE
- N.2: Pilot Phase 1 (Dec 24 - Jan 21)
- N.3: Pilot Phase 2 (Jan 21 - Feb 18)
- N.4: GTM Preparation & Launch (Feb 18 - Mar 11)
V2 Completed Tracks (Reference Only)
- E006: Deployment Infrastructure ✅ COMPLETE
- E007: Documentation System ✅ COMPLETE
- E009: Analytics & Observability ✅ COMPLETE
Dependency Graph & Execution Order
Session Assignment Matrix
- Core Platform Sessions (Tracks A-F)
- DMS Product Sessions (Track G)
Collision Prevention Rules
- File Ownership
- Shared File Protocol
- Branch Strategy
Pre-Launch Checklist
- Backend Complete (Track A)
- Frontend Complete (Track B)
- DevOps Complete (Track C)
- Security Complete (Track D)
- Testing Complete (Track E)
- Documentation Complete (Track F)
- DMS Product Complete (Track G)
Appendix A: Source Documents Consolidated
Appendix B: Agent Assignment Recommendations
- Core Platform (Tracks A-F)
- DMS Product (Track G)
Appendix C: Frontend Repository Reference
- Main Platform (coditect.ai)
- Auth Portal (auth.coditect.ai)
- DMS (dms.coditect.ai)

Executive Summary​

Current Status (Jan 09, 2026)​

🚨 Critical Path (Jan 6 Assessment - Updated)​

ADR-047 Roadmap Alignment​

Vision Summary (ADR-047)​

MVP → Full Vision Migration Path​

Track → ADR-047 Domain Mapping​

Future Tracks (Post-Pilot)​

Track N: Gateway API Migration - ✅ NOT REQUIRED (Jan 7, 2026 Audit)​

Frontend Repository Mapping​

coditect.ai API Endpoints (Discovered)​

DMS API Endpoints (Live at dms.coditect.ai)​

Architecture: Parallel Session Tracks​

Critical Path Execution Order (January 9, 2026)​

✅ BLOCKERS (Resolved)​

Phase 1: Critical Infrastructure [CP-1 to CP-13]​

Phase 2: Documentation & Quality [CP-11 to CP-20]​

Phase 3: Launch Preparation [CP-21 to CP-30]​

Phase 4: DMS Product (Parallel Track) [CP-D1 to CP-D15]​

Phase 5: Extended Tracks (Post-Launch) [CP-X1 to CP-X10]​

Execution Summary​

Recommended Execution Order​

Track A: Backend Completion​

A.1: Step 7 - Client Heartbeat System​

A.2: Step 9 - Admin Dashboard API​

A.3: Commerce API (Multi-Product Checkout) ✅ COMPLETE​

A.3.1: Product Catalog API ✅ COMPLETE​

A.3.2: Shopping Cart API ✅ COMPLETE​

A.3.3: Checkout & Payment API ✅ COMPLETE​

A.3.4: Entitlement System API ✅ COMPLETE​

A.4: Context Sync API (Multi-Device Session Sync)​

A.5: Team/Project Context Sync (Multi-Level Backup)​

A.5.1: Database Schema (Week 1)​

A.5.2: Team Context API (Week 2)​

A.5.3: Project Context API (Week 3)​

A.5.4: Backup System (Week 4)​

A.6: Reference Data - ISO Standard Contact Management ✅ COMPLETE​

A.7: Cloud Workstations Provisioning API (P1)​

A.8: Docker Image Heartbeat System (P1)​

A.9: Cloud Context Task Sync (ADR-053 Implementation)​

A.9.1: TaskTracking Model (Week 1)​

A.9.2: Task Sync API Endpoints (Week 2)​

A.9.3: Local-Cloud Integration (Week 3)​

A.9.4: Multi-Tenant Verification (Week 4)​

A.10: Container Session Lifecycle API (ADR-055) ✅ 100%​

A.10.1: Sessions Django App (Day 1-2)​

A.10.2: Session Validation Endpoint (Day 3-4)​

A.10.3: Session Heartbeat Endpoint (Day 5-6)​

A.10.4: Session Release Endpoint (Day 7)​

A.10.5: Integration & Testing (Day 8-10)​

A.11: Cloud Workstation Broker Service (ADR-005 Implementation) ✅ 100%​

A.11.1: GCP Cloud Workstation Infrastructure (Week 1) ✅ 100% COMPLETE (Jan 7, 2026)​

A.11.2: Workstation Django App (Week 1-2) ✅ COMPLETE (Jan 6, 2026)​

A.11.3: Workstation API Endpoints (Week 2) ✅ COMPLETE (Jan 6, 2026)​

A.11.4: Auto-Provision Webhook (Week 2) ✅ COMPLETE (Jan 6, 2026)​

A.11.5: Integration & Testing (Week 3)​

A.12: Team & License Management ✅ 90%​

A.12.1: Invitation System (Week 1)​

A.12.2: License Assignment (Week 1-2)​

A.12.3: Frontend Team Management (Week 2) ✅ COMPLETE (Discovered Jan 7, 2026)​

A.12.4: Testing (Week 2)​

A.13: System Administration - License & Workstation Override 🆕 (Jan 9, 2026)​

A.13.1: License Provisioning Override (Backend)​

A.13.2: Workstation Provisioning Override (Backend)​

A.13.3: Pilot Customer Batch Provisioning​

A.13.4: Admin UI (Frontend) ✅ COMPLETE (Jan 9, 2026)​

A.13.5: Audit & Security ✅ COMPLETE (Jan 9, 2026)​

Track B: Frontend Build​

B.1: Project Setup Enhancement​

B.2: Authentication Pages​

B.3: Commerce & Multi-Product Checkout​

B.3.1: Product Catalog ✅ COMPLETE​

B.3.2: Shopping Cart ✅ COMPLETE​

B.3.3: Dual Payment Integration ✅ COMPLETE​

B.3.4: Entitlement Display​

B.4: Dashboard & License Management​

B.5: Shared Components & Styling ✅ COMPLETE​

B.6: Dark Mode & UI Polish​

B.7: Legal & Account Pages (P0 - BLOCKING)​

B.7.1: Privacy Policy Page (/privacy)​

Executive Summary

Current Status (Jan 09, 2026)

🚨 Critical Path (Jan 6 Assessment - Updated)

ADR-047 Roadmap Alignment

Vision Summary (ADR-047)

MVP → Full Vision Migration Path

Track → ADR-047 Domain Mapping

Future Tracks (Post-Pilot)

Track N: Gateway API Migration - ✅ NOT REQUIRED (Jan 7, 2026 Audit)

Frontend Repository Mapping

coditect.ai API Endpoints (Discovered)

DMS API Endpoints (Live at dms.coditect.ai)

Architecture: Parallel Session Tracks

Critical Path Execution Order (January 9, 2026)

✅ BLOCKERS (Resolved)

Phase 1: Critical Infrastructure [CP-1 to CP-13]

Phase 2: Documentation & Quality [CP-11 to CP-20]

Phase 3: Launch Preparation [CP-21 to CP-30]

Phase 4: DMS Product (Parallel Track) [CP-D1 to CP-D15]

Phase 5: Extended Tracks (Post-Launch) [CP-X1 to CP-X10]

Execution Summary

Recommended Execution Order

Track A: Backend Completion

A.1: Step 7 - Client Heartbeat System

A.2: Step 9 - Admin Dashboard API

A.3: Commerce API (Multi-Product Checkout) ✅ COMPLETE

A.3.1: Product Catalog API ✅ COMPLETE

A.3.2: Shopping Cart API ✅ COMPLETE

A.3.3: Checkout & Payment API ✅ COMPLETE

A.3.4: Entitlement System API ✅ COMPLETE

A.4: Context Sync API (Multi-Device Session Sync)

A.5: Team/Project Context Sync (Multi-Level Backup)

A.5.1: Database Schema (Week 1)

A.5.2: Team Context API (Week 2)

A.5.3: Project Context API (Week 3)

A.5.4: Backup System (Week 4)

A.6: Reference Data - ISO Standard Contact Management ✅ COMPLETE

A.7: Cloud Workstations Provisioning API (P1)

A.8: Docker Image Heartbeat System (P1)

A.9: Cloud Context Task Sync (ADR-053 Implementation)

A.9.1: TaskTracking Model (Week 1)

A.9.2: Task Sync API Endpoints (Week 2)

A.9.3: Local-Cloud Integration (Week 3)

A.9.4: Multi-Tenant Verification (Week 4)

A.10: Container Session Lifecycle API (ADR-055) ✅ 100%

A.10.1: Sessions Django App (Day 1-2)

A.10.2: Session Validation Endpoint (Day 3-4)

A.10.3: Session Heartbeat Endpoint (Day 5-6)

A.10.4: Session Release Endpoint (Day 7)

A.10.5: Integration & Testing (Day 8-10)

A.11: Cloud Workstation Broker Service (ADR-005 Implementation) ✅ 100%

A.11.1: GCP Cloud Workstation Infrastructure (Week 1) ✅ 100% COMPLETE (Jan 7, 2026)

A.11.2: Workstation Django App (Week 1-2) ✅ COMPLETE (Jan 6, 2026)

A.11.3: Workstation API Endpoints (Week 2) ✅ COMPLETE (Jan 6, 2026)

A.11.4: Auto-Provision Webhook (Week 2) ✅ COMPLETE (Jan 6, 2026)

A.11.5: Integration & Testing (Week 3)

A.12: Team & License Management ✅ 90%

A.12.1: Invitation System (Week 1)

A.12.2: License Assignment (Week 1-2)

A.12.3: Frontend Team Management (Week 2) ✅ COMPLETE (Discovered Jan 7, 2026)

A.12.4: Testing (Week 2)

A.13: System Administration - License & Workstation Override 🆕 (Jan 9, 2026)

A.13.1: License Provisioning Override (Backend)

A.13.2: Workstation Provisioning Override (Backend)

A.13.3: Pilot Customer Batch Provisioning

A.13.4: Admin UI (Frontend) ✅ COMPLETE (Jan 9, 2026)

A.13.5: Audit & Security ✅ COMPLETE (Jan 9, 2026)

Track B: Frontend Build

B.1: Project Setup Enhancement

B.2: Authentication Pages

B.3: Commerce & Multi-Product Checkout

B.3.1: Product Catalog ✅ COMPLETE

B.3.2: Shopping Cart ✅ COMPLETE

B.3.3: Dual Payment Integration ✅ COMPLETE

B.3.4: Entitlement Display

B.4: Dashboard & License Management

B.5: Shared Components & Styling ✅ COMPLETE

B.6: Dark Mode & UI Polish

B.7: Legal & Account Pages (P0 - BLOCKING)

B.7.1: Privacy Policy Page (`/privacy`)