CODITECT Pilot Parallel Execution Plan

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

Task Consolidation Log

Removed Task	Consolidated Into	Date	Reason
A.7 (Workstations Provisioning)	A.11 (Workstation Broker)	2026-01-20	Duplicate scope
A.8 (Heartbeat System)	A.10.3 (Session Heartbeat)	2026-01-20	Duplicate scope

Prevention: Before creating new tasks, search existing sections for overlapping scope.

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 21, 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
Two-Database Architecture (A.14) ✅	100%	0%	No
Enhanced RBAC (A.15) ✅	100%	0%	No
Cloud Workstation Broker (A.11) ✅	100%	0%	No ✅
Team & License Management (A.12) ✅	100%	0%	No ✅
Frontend UI	90%	10%	No
Design System	98%	2%	No
Commerce UI	90%	10%	No
Container Session UI (B.4.5)	75% (MVP)	25% (MVP)	No
Permission Management UI (B.17) ✅	100%	0%	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
Secured Distribution Portal (C.9) ✅	90%	10%	No
Update & Uninstall (C.11) ✅	100%	0%	No
Time-Controlled Licensing (C.12)	100%	0%	No
Documentation	85%	15%	No
Track Nomenclature (F.4)	100%	0%	No
docs.coditect.ai Content (F.8) ✅	100%	0%	No
Framework Autonomy (H)	56%	44%	Yes
UI Components (I) ✅	75%	25%	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 12 Assessment - Updated)

C.5 Docker Registry → A.10 Container Sessions → A.12 Team Mgmt → A.11 Workstation Broker → Launch
     (100% ✅)              (100% ✅)               (100% ✅)             (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 13): F.10 (1000 Use Cases Repository & Getting Started Enhancement) COMPLETE. Created new submodule coditect-1000-use-cases/ with complete structure: 10 domain files (1000 use cases across 15 industries), templates/, mappings/, scripts/, analysis/. Created CODITECT-STANDARD-USE-CASE.md in coditect-core-standards with quality criteria and domain coverage. Created COMMAND-QUICK-REFERENCE.md (~4500 tokens) in docs/getting-started covering: First 5 commands, 5W framework, /which patterns, MoE system, Git commands, command chaining. Created docs/getting-started/CLAUDE.md with AI agent context. Fixed frontmatter on 5 documents with auto-classified generic metadata. Track F now has F.10 section with 11 completed tasks.

Progress Update (Jan 11): SESSION ASSIGNMENT UPDATE. Two parallel sessions active:

Session A (separate): Working on J.9 (Auto-Preservation/Context-Monitor) and H.5 (Codanna Code Intelligence Integration)
Session B (ad71ac9e): Resuming PILOT Critical Path execution - available for CP-10 (Security Testing), Phase 2 docs, or remaining pilot tasks

Progress Update (Jan 11): CP-10 (E.2 Security Testing) VERIFIED COMPLETE. Session ad71ac9e verified 91 security tests across 5 files in coditect-cloud-infra/backend/tests/security/: test_rate_limit.py (14 tests), test_login_protection.py (11 tests), test_security_headers.py (24 tests), test_audit_log.py (21 tests), test_input_validation.py (21 tests). Tests cover OWASP Top 10: rate limiting (429 responses), login lockout (5 attempts), security headers, audit logging, input validation. Phase 1 Critical Path now 100% complete. Remaining: B.7.1.5/B.7.2.5 (Legal review - external dependency), Phase 2 docs.

Progress Update (Jan 11): CP-11 (F.1 User Guides) VERIFIED COMPLETE. Reviewed existing guides created Jan 7: PILOT-GETTING-STARTED.md (cloud signup, workstation access), PILOT-USER-GUIDE.md (~350 lines, 9 sections), PILOT-FAQ.md (40+ FAQs). All major features documented: 2FA, Team Management with invitations/license assignment, Cloud Workstations, Container Sessions, Billing portal. Fixed F.1.1-F.1.4 checkboxes (were [ ], now [x]). Phase 2 started.

Progress Update (Jan 10): CRITICAL PATH VERIFICATION COMPLETE. Verified and marked complete: CP-6 (docs.coditect.ai content - 2,531 pages in coditect-cloud-infra/docs-site/docs/), CP-9 (CDN configuration - OpenTofu Cloud CDN module at coditect-cloud-infra/opentofu/modules/cloud-cdn/ with enable_cdn = true, cache settings, SSL configured in docs-cdn.tf), B.4.5.7 (ContainerSessionDashboard - 111 lines), B.4.5.9 (SessionMetrics - 211 lines). Total container session components: 4 files, 975 lines. Remaining Critical Path: CP-10 (Security testing, 8-12h), B.7.1.5/B.7.2.5 (Legal review - external dependency). Estimated launch ready: January 11-12, 2026.

Progress Update (Jan 10): F.8.1.13-15 (docs.coditect.ai Component Classification) COMPLETE. 75 components MoE-classified with frontmatter metadata, v1.9.1 deployed to Cloud Run. N.1 (Gateway Audit) COMPLETE - confirmed GCE Ingress (not nginx), no migration needed. Track N NOT REQUIRED for launch.

Progress Update (Jan 09): F.8.1.9 (Mermaid Diagrams) COMPLETE + F.8.1.10 (n8n Workflow Visualizations) ADDED. F.8.1.9: Installed @docusaurus/theme-mermaid, configured CODITECT branding (#0ea5e9 primary, #e0f2fe secondary), deployed v1.4.0-mermaid to Cloud Run. 426 mermaid diagrams across 109 files now render with branded colors. F.8.1.10: Inventoried 1,149 n8n workflow JSON files across 15 categories (industry: 496, operations: 100, creative: 100, devops: 55, developer-experience: 55, research: 51, etc.). Plan: Create workflow-to-docs.py transformer to generate mermaid flowcharts + step narratives from n8n JSON, batch transform all workflows, deploy v1.5.0-workflows. Estimated: 8-12 hours.

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 16): Track H.3.8 (Provider Flexibility) 100% COMPLETE. Created ADR-073 for single/dual/multi-provider mode support. Implemented ProviderDetector class with auto-detection from API keys. Integrated with PersonaLoader, MoEOrchestrator, and MultiModelClient. 79 tests passing. Confidence adjustments: single=-10%, dual=-5%, multi=0%. Supports Jan 2026 models (claude-sonnet-4-5, o3, gpt-4.1, deepseek-v3.2, llama-4-maverick). Created MOE-PROVIDER-CONFIGURATION-GUIDE.md customer guide. Commits: 775b8560, ac3b8081, 54fd539b, 0a512d60, e1503ba0, 7e61a747, ba74437a. Track H.3 now has 50 total tasks (42 + 8).

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	-	✅ VERIFIED (Jan 11)
~~[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	-	✅ VERIFIED (Jan 11)
~~[CP-12]~~	~~F.7.8.1-8.3~~	~~WF-107 Organization Settings docs~~	F	-	✅ DONE (Jan 11)
~~[CP-13]~~	~~F.7.9.1-9.3~~	~~WF-108 Team Role Change docs~~	F	-	✅ DONE (Jan 11)
~~[CP-14]~~	~~F.7.10.1-10.3~~	~~WF-109 License Seat Reallocation docs~~	F	-	✅ DONE (Jan 11)
~~[CP-15]~~	~~F.7.11.1-11.3~~	~~WF-110 Contractor Access Expiration docs~~	F	-	✅ DONE (Jan 11)
~~[CP-16]~~	~~F.7.12.1-12.3~~	~~WF-111 Agency Consolidated Billing docs~~	F	-	✅ DONE (Jan 11)
~~[CP-17]~~	~~F.5.5.3.1-3.12~~	~~High success rate component fixes (29-35%)~~	F	-	✅ DONE (Jan 11)
~~[CP-18]~~	~~F.5.5.4.1-4.18~~	~~Medium success rate component fixes (36-39%)~~	F	-	✅ DONE (Jan 11)
~~[CP-19]~~	~~F.5.5.5.1-5.15~~	~~Low success rate component fixes (40-48%)~~	F	-	✅ DONE (Jan 11)
~~[CP-20]~~	~~F.5.6.1-6.4~~	~~Skill Health Framework Enhancement~~	F	-	✅ DONE (Jan 11)

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	-	✅ DONE (Jan 18)
~~[CP-22]~~	~~N.2.2~~	~~Create pilot onboarding materials~~	N	-	✅ DONE (Jan 11)
[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	-	✅ DONE (Jan 18)
[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	-	✅ DONE (Jan 11)
~~[CP-28]~~	~~F.7.17-7.20~~	~~P2 Workflow docs (WF-117 to WF-119)~~	F	-	✅ DONE (Jan 11)
~~[CP-29]~~	~~F.5.7.1-7.3~~	~~Anti-Pattern Prevention System~~	F	-	✅ DONE (Jan 11)
[CP-30]	F.3.4	Discord community setup	F	`devops-engineer`	⏸️ ON HOLD

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.5.4 Status: COMPLETE (January 20, 2026) Files Created:

opentofu/modules/context-backup-scheduler/ - OpenTofu module for Cloud Scheduler
backend/context/views.py - Added scheduler dispatcher views (lines 2266-2683)
backend/context/urls.py - Added scheduler endpoints

Deployment Steps (A.5.4.9):

✅ DONE Add module to opentofu/environments/dev/main.tf:

# Context Backup Scheduler (A.5.4.6-7)
module "context_backup_scheduler" {
  source = "../../modules/context-backup-scheduler"

  project_id   = var.project_id
  environment  = var.environment
  region       = var.region
  api_base_url = "https://api.coditect.ai"  # Or var.api_base_url

  # Optional: Customize schedules
  hourly_schedule = "15 * * * *"   # Every hour at :15
  daily_schedule  = "30 2 * * *"   # Daily at 2:30 AM
  time_zone       = "America/Los_Angeles"

  # Optional: Pause during initial deployment
  paused = false

  depends_on = [module.gke]
}

✅ DONE Add variables to opentofu/environments/dev/variables.tf:

variable "api_base_url" {
  description = "Base URL for CODITECT API"
  type        = string
  default     = "https://api.coditect.ai"
}

✅ DONE Deploy Cloud Scheduler jobs:

cd opentofu/environments/dev
tofu init    # If new module
tofu plan    # Review changes
tofu apply   # Deploy scheduler jobs (completed 2026-01-20)

✅ DONE Verify deployment:

# List scheduler jobs
gcloud scheduler jobs list --location=us-central1

# Test manual trigger (optional)
gcloud scheduler jobs run coditect-context-dev-hourly-incremental \
  --location=us-central1

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 (CONSOLIDATED)

Status: ✅ Consolidated into A.11 (Workstation Broker) - January 20, 2026 See: A.11 for full implementation

A.8: Docker Image Heartbeat System (CONSOLIDATED)

Status: ✅ Consolidated into A.10.3 (Session Heartbeat) - January 20, 2026 See: A.10.3 for backend endpoint, docker/workstation/scripts/heartbeat.sh for client

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 ✅ Verified Jan 20, 2026
- 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 (distribution/licensed-docker/scripts/entrypoint.sh)
- ✅ Workstation entrypoint calls /sessions/validate with JWT (distribution/licensed-workstation/scripts/entrypoint.sh)
- ✅ Both call /sessions/heartbeat periodically via base entrypoint (5-minute interval)
- ✅ Both call /sessions/release on exit via trap handler
- Tests: distribution/tests/test_license_validation.sh (11 passed), distribution/tests/test_heartbeat.sh (13 passed)

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

A.14: Database Architecture Migration (ADR-080 + ADR-103) 🟡

Status: 🟡 LOCAL COMPLETE (75%) - Evolved to Four-Database Architecture (Jan 23, 2026) Created: January 20, 2026 Local Complete: January 21, 2026 (ADR-080), January 23, 2026 (ADR-103) Goal: Separate CODITECT Platform Data from Customer Data with semantic search boundaries ADRs:

ADR-080-two-database-architecture.md - Initial two-database separation
ADR-103-four-database-separation-architecture.md - Extended to four databases

Evolution (Jan 23, 2026): ADR-103 extends ADR-080 to address semantic search boundaries:

Problem: Customer /cxq searches could mix with framework results
Solution: Four databases with clear search boundaries

Scope Clarification (Updated Jan 23):

Phase	Status	Description
A.14.1-A.14.4	✅	Local database separation (platform.db + context.db)
A.14.5	✅	Cloud PostgreSQL replication with tenant isolation
A.15	❌ NOT STARTED	RBAC permission system (48+ permissions)
H.5.7	✅ COMPLETE	Four-Database Extension (platform-index.db + projects.db)

Blocking for Full Vision:

A.15 (RBAC) must be implemented for multi-tenant/team/project/user access control
~~H.5.7.3-H.5.7.4~~ ✅ COMPLETE (Jan 23, 2026) - Project indexing and unified search implemented

Architecture Overview (Four-Database Model - ADR-103):

~/PROJECTS/.coditect-data/context-storage/
├── platform.db         (Component metadata - 2MB, read-only)
├── platform-index.db   (Component embeddings - 50MB, read-only)  [NEW ADR-103]
├── context.db          (Sessions, messages, decisions - customer)
└── projects.db         (Project code/docs - unified, all projects) [NEW ADR-103]

Search Boundaries:
• /which "agent"        → platform-index.db (agentic search)
• /cxq "auth"           → context.db + projects.db (customer search)
• /cxq --framework      → platform.db + platform-index.db (explicit)
• /cxq --everything     → All 4 databases (opt-in unified)

Implementation Stats (Jan 23, 2026):

platform-index.db: 1,018 framework components indexed
projects.db: 248,159 project files indexed
Hash-based change tracking: ENABLED

Legacy Architecture (ADR-080 - Preserved for Reference):

┌─────────────────────────┐    ┌─────────────────────────┐
│     platform.db         │    │      context.db         │
│     (Read-Only)         │    │     (Read/Write)        │
│                         │    │                         │
│ • Components (2100+)    │    │ • Sessions              │
│ • Standards             │    │ • Tasks                 │
│ • Health scores         │    │ • Decisions             │
│ • MoE rules             │    │ • Preferences           │
└─────────────────────────┘    └─────────────────────────┘
         │                              │
         │ TTL refresh                  │ Cursor sync
         │ (daily)                      │ (realtime)
         ▼                              ▼
    CDN / Git                    api.coditect.ai

MoE Agent Invocation:

Task(subagent_type="database-architect", prompt="Implement A.14 Two-Database Architecture per ADR-080. Create platform.db schema, migrate component index, separate customer data.")

A.14.1: Phase 1 - Create platform.db (Non-Breaking) ~8h

Goal: Extract component data from context.db to new platform.db Agent: /agent database-architect "Create platform.db schema and migration script"

A.14.1.1: Create platform.db schema
- Agent: Task(subagent_type="database-architect", prompt="Create ~/PROJECTS/.coditect-data/context-storage/platform.db with components, component_search FTS5, component_dependencies tables per ADR-080")
- Tables: components, component_search (FTS5), component_dependencies
- Read-only design (no tenant FK)
A.14.1.2: Create create-platform-db.py script
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/create-platform-db.py to initialize platform.db schema with proper indexes")
- Initialize empty platform.db with schema
- Create FTS5 virtual table for search
- Add indexes on type, model, health_score
A.14.1.3: Update component-indexer.py to write to platform.db
- Agent: Task(subagent_type="senior-architect", prompt="Modify scripts/component-indexer.py to write to platform.db instead of context.db, keeping context.db as fallback")
- Primary target: platform.db
- Fallback: context.db (for backward compatibility)
- Add --target flag (platform|context|both)
A.14.1.4: Create migrate-components.py script
- Agent: Task(subagent_type="database-architect", prompt="Create scripts/migrate-components.py to copy existing component data from context.db to platform.db")
- One-time migration script
- Verify row counts match
- Log migration summary
A.14.1.5: Run migration and verify
- Agent: Task(subagent_type="devops-engineer", prompt="Run component migration, verify platform.db has all 2100+ components, test search functionality")
- Run: python3 scripts/migrate-components.py
- Verify: python3 scripts/component-indexer.py --stats --target platform
- Test: Search queries work on platform.db

A.14.2: Phase 2 - Separate Local Schemas (Non-Breaking) ~12h

Goal: Add customer data models to context.db, run cloud migrations Agent: /agent database-architect "Add customer data models per ADR-080"

A.14.2.1: Create customer_data_models.py in backend/context/
- Agent: Task(subagent_type="database-architect", prompt="Create backend/context/customer_data_models.py with SessionSummary, ActivityFeed, ProjectDecision, UserProjectPreference models per ADR-080")
- Models: SessionSummary, ActivityFeed, ProjectDecision, UserProjectPreference
- All inherit from TenantModel
- Add to context/models.py init
A.14.2.2: Extend Project model with new fields
- Agent: Task(subagent_type="database-architect", prompt="Add fields to tenants/models.py Project: progress, task_count, local_path, repository_url, last_session_id, last_activity_at per ADR-080")
- Fields: progress, task_count, local_path, repository_url, last_session_id, last_activity_at
A.14.2.3: Generate and run Django migrations
- Agent: Task(subagent_type="devops-engineer", prompt="Run makemigrations for context and tenants apps, apply to PostgreSQL, verify schema")
- python manage.py makemigrations context tenants
- python manage.py migrate
- Verify tables created in PostgreSQL
A.14.2.4: Update local context.db schema
- Agent: Task(subagent_type="database-architect", prompt="Create scripts/migrate-context-db.py to add customer data tables to local SQLite context.db")
- Add tables matching Django models
- Preserve existing messages, tasks tables
- Add sync_cursor tracking
A.14.2.5: Update cloud sync client for new models
- Agent: Task(subagent_type="senior-architect", prompt="Update scripts/core/cloud_sync_client.py to sync SessionSummary, ActivityFeed, ProjectDecision, UserProjectPreference")
- Add serializers for new models
- Add sync endpoints
- Test bidirectional sync

A.14.3: Phase 3 - API Deployment (Non-Breaking) ~16h

Goal: Deploy Platform API (read-only) and Customer API (tenant-scoped) Agent: /agent senior-architect "Deploy Platform and Customer APIs per ADR-080"

A.14.3.1: Platform API (Public, Read-Only)

A.14.3.1.1: Create PlatformComponentSerializer
- Agent: Task(subagent_type="senior-architect", prompt="Create api/v1/serializers/platform.py with PlatformComponentSerializer for component metadata")
- Fields: id, type, name, description, capabilities, model, health_score
A.14.3.1.2: Create GET /api/v1/platform/components endpoints
- Agent: Task(subagent_type="senior-architect", prompt="Create api/v1/views/platform.py with PlatformComponentListView, PlatformComponentDetailView, PlatformComponentSearchView")
- List: GET /api/v1/platform/components
- Detail: GET /api/v1/platform/components/{id}
- Search: GET /api/v1/platform/components/search?q=
A.14.3.1.3: Create GET /api/v1/platform/standards endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create PlatformStandardsView returning list of CODITECT standards from coditect-core-standards/")
A.14.3.1.4: Create GET /api/v1/platform/health endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create PlatformHealthView returning component health statistics and coverage metrics")
A.14.3.1.5: Create GET /api/v1/platform/version endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create PlatformVersionView returning current platform version, component counts, last updated")
A.14.3.1.6: Add caching layer for Platform API
- Agent: Task(subagent_type="devops-engineer", prompt="Add Redis caching to Platform API endpoints with 1-hour TTL, CDN-friendly headers")
- Cache-Control headers for CDN
- Redis caching with 1-hour TTL
- ETag support for conditional requests

A.14.3.2: Customer API (Authenticated, Tenant-Scoped)

A.14.3.2.1: Create SessionSummarySerializer and views
- Agent: Task(subagent_type="senior-architect", prompt="Create serializers and views for SessionSummary: list sessions, get session detail, create summary")
- GET /api/v1/context/sessions
- GET /api/v1/context/sessions/{id}
- POST /api/v1/context/sessions/{id}/summary
A.14.3.2.2: Create ActivityFeedSerializer and views
- Agent: Task(subagent_type="senior-architect", prompt="Create serializers and views for ActivityFeed: list activity, filter by project/user/date")
- GET /api/v1/projects/{id}/activity
- Filters: user, date_range, activity_type
A.14.3.2.3: Create ProjectDecisionSerializer and views
- Agent: Task(subagent_type="senior-architect", prompt="Create serializers and views for ProjectDecision: list decisions, create decision, get decision")
- GET /api/v1/projects/{id}/decisions
- POST /api/v1/projects/{id}/decisions
- GET /api/v1/projects/{id}/decisions/{decision_id}
A.14.3.2.4: Create UserProjectPreferenceSerializer and views
- Agent: Task(subagent_type="senior-architect", prompt="Create serializers and views for UserProjectPreference: get/update preferences (pinned, last_accessed)")
- GET /api/v1/projects/{id}/preferences
- POST /api/v1/projects/{id}/preferences
A.14.3.2.5: Add URL routes for all new endpoints
- Agent: Task(subagent_type="senior-architect", prompt="Add URL routes for Platform API and Customer API endpoints to api/v1/urls.py")
A.14.3.2.6: Update local clients to use new APIs
- Agent: Task(subagent_type="senior-architect", prompt="Update scripts/core/cloud_sync_client.py and /cxq command to use new API endpoints")

A.14.4: Phase 4 - Deprecate Mixed Access (Breaking, 30-Day Notice) ~4h

Goal: Remove component queries from context.db, require platform.db Agent: /agent senior-architect "Deprecate mixed access per ADR-080"

A.14.4.1: Add deprecation warnings to context.db component access
- Agent: Task(subagent_type="senior-architect", prompt="Add deprecation warnings when component queries hit context.db instead of platform.db")
- Log warning on component query to context.db
- Include migration instructions in warning
A.14.4.2: Create verify-db-separation.py script
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/verify-db-separation.py to verify platform.db and context.db have correct data separation")
- Check: platform.db has only components
- Check: context.db has only customer data
- Report: Any mixed data found
A.14.4.3: Update CODITECT-CORE-INITIAL-SETUP.py
- Agent: Task(subagent_type="senior-architect", prompt="Update scripts/CODITECT-CORE-INITIAL-SETUP.py to create both platform.db and context.db during installation")
- Create platform.db during setup
- Run component indexer with --target platform
- Verify both databases initialized
A.14.4.4: Remove component tables from context.db (after 30 days)
- Agent: Task(subagent_type="database-architect", prompt="After deprecation period, remove component tables from context.db schema")
- Drop: components, component_search, component_dependencies from context.db
- Update: All scripts to use platform.db only
- Note: Execute only after 30-day deprecation period
A.14.4.5: Update documentation
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Update CLAUDE.md, DATABASE-SCHEMA.md, and user guides to reflect two-database architecture")
- Update: Section 6 (Context Management) in CLAUDE.md
- Completed: Updated CLAUDE.md Key Paths and Storage sections for ADR-080
A.14.4.6: Add customer table cleanup to installation script
- Agent: Task(subagent_type="senior-architect", prompt="Update CODITECT-CORE-INITIAL-SETUP.py to clean customer data tables (session_summaries, activity_feed, project_decisions, user_project_preferences) when setting up new CODITECT customers")
- Clear: session_summaries, activity_feed, project_decisions, user_project_preferences
- Preserve: Platform data in platform.db
- Add: --clean-customer-data flag for explicit cleanup
- Log: Customer table cleanup during fresh installation
A.14.4.7: Enhance /cx to populate customer data tables (ADR-080)
- Agent: Task(subagent_type="senior-architect", prompt="Enhance unified-message-extractor.py to populate new customer data tables: session_summaries (generate AI summaries of sessions), activity_feed (session_start/end events), project_decisions (extract from session content)")
- Current: /cx writes to unified_messages.jsonl + token_economics + tool_analytics only
- Enhancement: Also populate session_summaries, activity_feed, project_decisions tables
- Generate: SessionSummary with AI-generated title/summary from session content
- Extract: Activity feed entries for session lifecycle events
- Extract: ProjectDecision records from ADR/decision discussions
- Use: content_hash for deduplication during re-extraction
- Support: sync_cursor for cloud sync polling

Dependencies:

A.9 (Cloud Context Sync) ✅ Complete - provides sync infrastructure
ADR-080 (Two-Database Architecture) ✅ Accepted

Estimated Time: 40-48 hours (spread across 2-3 weeks)

A.14.5: Cloud PostgreSQL Replication with Tenant Isolation ✅

Status: ✅ 100% COMPLETE (Jan 21, 2026) - All tasks complete including RBAC integration Goal: Replicate local dual-database structure to cloud PostgreSQL with multi-tenant RBAC governance

Verification (Jan 21, 2026):

context/models.py (25KB): ContextMessage, SyncCursor, SyncStats, TaskTracking - all TenantModel
context/customer_data_models.py (20KB): SessionSummary, ActivityFeed, ProjectDecision, UserProjectPreference
context/views.py (98KB): Push/Pull API for all customer data types
context/serializers.py (28KB): All serializers for sync operations
Tenant isolation via django-multitenant with automatic filtering Blocking: Full vision of shared context at scale

Scope:

LOCAL (Single User)                      CLOUD (Multi-Tenant at Scale)
┌─────────────────────────┐              ┌─────────────────────────────────────┐
│ platform.db (read-only) │              │ PostgreSQL: platform schema         │
│ context.db (read/write) │   ──sync──▶  │ PostgreSQL: context schema (tenant) │
└─────────────────────────┘              │ RBAC: User→Team→Project→Tenant      │
                                         └─────────────────────────────────────┘

Tasks:

A.14.5.1: Design cloud schema for platform data ✅ N/A - CDN distribution
- Decision: Platform data uses CDN/git distribution, not cloud PostgreSQL
- Platform.db remains local-only with TTL refresh from CDN/releases
- ADR-089: "Platform data distributed via CDN or git sync"
A.14.5.2: Design cloud schema for context data with tenant isolation ✅ (Jan 21)
- Implemented in context/models.py + context/customer_data_models.py
- ContextMessage, SyncCursor, SyncStats, TaskTracking, SessionSummary, ActivityFeed, ProjectDecision, UserProjectPreference
- All models use TenantModel with automatic tenant_id filtering
A.14.5.3: Create cloud sync models in Django ✅ (Jan 21)
- 8 models with tenant isolation + sync_cursor + content_hash
- Migrations applied in context/migrations/
A.14.5.4: Implement bidirectional sync ✅ (Jan 21)
- context/views.py (98KB): ContextPushView, ContextPullView, SessionSummaryPushView, etc.
- Cursor-based polling with deduplication
- Currently uses IsAuthenticated only
A.14.5.5: Integrate with A.15 RBAC ✅ (Jan 21)
- Added context:sync, context:view, context:share, context:manage, context:export permissions
- Added CONTEXT category to PermissionCategory and SYNC/SHARE actions to ActionType
- Added role mappings: super_admin (all), owner/admin (all), member (sync/view/share), viewer (view)
- Updated ContextPushView, ContextPullView, ContextStatusView, TaskView, TeamContextPushView with check_context_permission()
- Created check_context_permission() helper in context/views.py
A.14.5.6: Create context sharing API ✅ (Jan 21)
- SharedContextView, TeamContextView implemented
- RBAC integration complete (A.14.5.5 ✅)

Dependencies:

A.14.1-A.14.4 ✅ Local database separation
A.15 ✅ RBAC permission system (verified complete)
A.9 ✅ Cloud sync infrastructure

Estimated Time: 40-60 hours

A.15: Enhanced RBAC Permission System (ADR-092 Implementation) ✅

Status: ✅ COMPLETE (Jan 21, 2026) - Verified: All components implemented

Verification (Jan 21, 2026):

permissions/models.py: Permission, RolePermission, UserPermissionOverride, PermissionAuditLog (636 lines)
permissions/services.py: PermissionService with caching, check_permission(), _resolve_permission() (23KB)
permissions/views.py: PermissionViewSet, RolePermissionViewSet, UserPermissionOverrideViewSet, PermissionAuditLogViewSet, PermissionCheckViewSet (19KB)
permissions/urls.py: All endpoints registered via DefaultRouter
Migrations: 0001_initial.py, 0002_enhanced_rbac_adr092.py, 0003_seed_permissions.py
64+ permissions seeded with role-permission mappings for system/tenant/team roles

Reference: ADR-092-enhanced-rbac-permission-system.md

Goal: Implement fine-grained permission system with 48+ configurable permissions, permission inheritance, and audit logging.

Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement ADR-092 Enhanced RBAC Permission System backend: (1) Create permission tables migration; (2) Seed default role-permission mappings; (3) Create permission resolution service; (4) Add permission check decorators; (5) Create permission audit logging")

A.15.1: Permission Database Schema (Week 1)

Files to Create:

tenants/migrations/XXXX_add_permission_tables.py
tenants/models/permission.py
tenants/models/user_permission.py
tenants/models/permission_audit.py

Tasks:

A.15.1.1: Create Permission model ✅ (Verified Jan 21)
- Implemented in permissions/models.py with 11 PermissionCategory + 13 ActionType choices
- 64+ permissions defined including users:, tenants:, teams:, projects:, licenses:, billing:, workstations:, analytics:, issues:, feedback:, admin:*
A.15.1.2: Create RolePermission model ✅ (Verified Jan 21)
- Implemented with role_type (system/tenant/team), role_name, permission FK
- seed_role_permissions() function creates all role-permission mappings
A.15.1.3: Create UserPermissionOverride model ✅ (Verified Jan 21)
- Implemented with scope_type, scope_id, is_granted, expires_at, reason
- Supports platform-wide, tenant, team, and project scoped overrides
A.15.1.4: Create PermissionAuditLog model ✅ (Verified Jan 21)
- Implemented with action (granted/revoked/checked/denied/expired)
- Includes ip_address, user_agent, metadata JSON field
A.15.1.5: Run migration and verify schema ✅ (Verified Jan 21)
- 3 migrations: 0001_initial, 0002_enhanced_rbac_adr092, 0003_seed_permissions

A.15.2: Permission Seeding and Role Mapping (Week 1-2)

Files to Create:

tenants/fixtures/permissions.json
tenants/management/commands/seed_permissions.py

Tasks:

A.15.2.1: Create permissions fixture (48+ permissions) ✅ (Verified Jan 21)
- 64+ permissions defined in seed_permissions() function in models.py
- Covers all categories: users, tenants, teams, projects, licenses, billing, workstations, analytics, issues, feedback, admin
A.15.2.2: Create role-permission mappings fixture ✅ (Verified Jan 21)
- seed_role_permissions() creates system/tenant/team role mappings
- super_admin: all 64 permissions, owner: 45 permissions, admin: 40 permissions, member: 18 permissions, viewer: 12 permissions, guest: 2 permissions
A.15.2.3: Create seed_permissions management command ✅ (Verified Jan 21)
- Implemented via migration 0003_seed_permissions.py (14KB)
- Idempotent with get_or_create pattern
A.15.2.4: Integrate seeding into deployment ✅ (Verified Jan 21)
- Seeding runs automatically via Django migrations

A.15.3: Permission Resolution Service (Week 2) ✅

Files Verified:

permissions/services.py (23KB) - Full PermissionService implementation

Tasks:

A.15.3.1: Create PermissionService class ✅ (Verified Jan 21)
- Implements check_permission(), _resolve_permission(), get_user_effective_permissions()
- Permission resolution: override → system_role → tenant_role → team_role → denied
A.15.3.2: Create @require_permission decorator ✅ (Verified Jan 21)
- Implemented in services.py with scope support
A.15.3.3: Create PermissionMixin for ViewSets ✅ (Verified Jan 21)
- PermissionCheckViewSet handles permission checking
A.15.3.4: Add permission caching ✅ (Verified Jan 21)
- Redis caching with 5-minute TTL (PERMISSION_CACHE_TTL = 300)

A.15.4: Permission API Endpoints (Week 2-3) ✅

Files Verified:

permissions/views.py (19KB) - All ViewSets implemented
permissions/serializers.py (6KB) - All serializers
permissions/urls.py - Router registered

Tasks:

A.15.4.1: Create permission listing endpoints ✅ (Verified Jan 21)
- PermissionViewSet with list, categories, matrix actions
A.15.4.2: Create permission grant/revoke endpoints ✅ (Verified Jan 21)
- UserPermissionOverrideViewSet with grant/revoke actions
A.15.4.3: Create permission check endpoint ✅ (Verified Jan 21)
- PermissionCheckViewSet with check, bulk_check, explain actions
A.15.4.4: Create permission audit endpoint ✅ (Verified Jan 21)
- PermissionAuditLogViewSet with filtering

A.15.5: Migrate Existing Permission Checks (Week 3) 🔶 PARTIAL

Tasks:

A.15.5.1: Audit existing permission checks ✅ (Verified Jan 21)
- Permission system ready for integration
A.15.5.2: Migrate tenant views to new system ✅ (Jan 21)
- TenantViewSet: RBAC checks added to retrieve(), partial_update()
- ProjectViewSet: RBAC checks added to all methods (list, create, update, delete, archive, restore, transfer, pin, bulk_status, stats)
- ProjectMemberViewSet: RBAC checks for all CRUD operations
- ProjectActivityViewSet, ProjectSubmoduleViewSet, ProjectHierarchyViewSet: RBAC checks added
- ReportTemplateViewSet, ReportViewSet: RBAC checks for list(), create()
- Using PermissionService with check_tenant_permission() helper
A.15.5.3: Migrate admin views to new system ✅ (Jan 21)
- users/views.py: Admin views already use HasPermission (users:list, users:view, users:update, tenants:list, tenants:view, tenants:manage, analytics:view, admin:downloads:approve)
- releases/views.py: DownloadAnalyticsView migrated from IsSystemAdmin to HasPermission('analytics:view')
- Deprecated permission classes (IsSystemAdmin, IsSuperAdmin, IsTenantAdmin) marked as deprecated
A.15.5.4: Update API documentation ✅ (Jan 21)
- Created comprehensive API-PERMISSIONS.md with all endpoints and their required permissions
- Location: coditect-cloud-infra/docs/api/API-PERMISSIONS.md
- Covers 15+ API categories: auth, users, tenants, projects, reports, admin, permissions, etc.
- Documents 55+ permission codes across 11 categories
- Includes role-permission matrix for system, tenant, and team roles

Dependencies:

ADR-092 (Enhanced RBAC) ✅ Created
A.12 (Team & License Management) ✅ Complete - provides user/team models

Estimated Time: 32-40 hours (spread across 2-3 weeks)

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

B.13: Workstation Management UI (Gap Analysis - Critical)

Status: NEW (Jan 20, 2026)

Reference: CODITECT-UI-GAP-ANALYSIS.md

Gap: Workstation management has 0% UI completion. All backend endpoints exist but no frontend integration.

Files to Create/Modify:

src/components/workstation/WorkstationDashboardWidget.tsx (NEW)
src/components/workstation/WorkstationProvisionModal.tsx (NEW)
src/components/workstation/WorkstationControls.tsx (NEW)
src/components/workstation/IDELaunchButton.tsx (NEW)
src/components/workstation/WorkstationCard.tsx (UPDATE - currently empty shell)
src/pages/Dashboard.tsx (UPDATE - add workstation widget)

Agent Invocation:

Task(subagent_type="frontend-react-typescript-expert", prompt="Implement workstation management UI in coditect-cloud-frontend: (1) WorkstationDashboardWidget showing user's workstation with status badge; (2) WorkstationProvisionModal with tier selection from /configs/ endpoint; (3) WorkstationControls with start/stop buttons and status polling every 5s; (4) IDELaunchButton that fetches token and opens IDE URL")

Tasks:

B.13.1.1: WorkstationDashboardWidget - Shows user's workstation with status
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create WorkstationDashboardWidget using getMyWorkstation() endpoint with status badge")
- Endpoints: GET /workstations/my/
B.13.1.2: WorkstationProvisionModal - Tier selection and provisioning
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create WorkstationProvisionModal with listConfigs() dropdown and provision() on submit")
- Endpoints: GET /workstations/configs/, POST /workstations/
B.13.1.3: WorkstationControls - Start/stop with status polling
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create WorkstationControls with start/stop buttons, useInterval for status polling every 5s")
- Endpoints: GET /workstations/{id}/start/, GET /workstations/{id}/stop/, GET /workstations/{id}/status/
B.13.1.4: IDELaunchButton - Token fetch and IDE launch
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create IDELaunchButton that fetches token from POST /workstations/{id}/token/ and opens IDE URL")
- Endpoints: POST /workstations/{id}/token/

Estimated Time: 12-16 hours Priority: P0 - Critical for pilot

B.14: Container Sessions Completion (Gap Analysis - High)

Status: NEW (Jan 20, 2026)

Reference: CODITECT-UI-GAP-ANALYSIS.md

Gap: Container sessions at 28% completion. Phases 3-6 not implemented.

Files to Create/Modify:

src/components/containerSessions/SessionErrorBoundary.tsx (NEW)
src/components/containerSessions/HeartbeatTimer.tsx (NEW)
src/components/containerSessions/SessionDetailDrawer.tsx (UPDATE - currently placeholder)
src/components/containerSessions/UserSessionManager.tsx (NEW)
src/components/containerSessions/NetworkErrorAlert.tsx (NEW)

Agent Invocation:

Task(subagent_type="generative-ui-architect", prompt="Complete container session UI Phases 3-6 in coditect-cloud-frontend: (1) SessionErrorBoundary with retry logic and fallback UI; (2) HeartbeatTimer that calls POST /sessions/heartbeat/ every 30s; (3) SessionDetailDrawer with user list, heartbeat timeline, and kick functionality; (4) UserSessionManager showing active users with kick button")

Tasks:

B.14.1.1: SessionErrorBoundary - Phase 3 error handling
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create SessionErrorBoundary with retry button, fallback UI, and error reporting")
B.14.1.2: HeartbeatTimer - Phase 3 keep-alive
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create HeartbeatTimer that calls sendHeartbeat() every 30s with visual countdown")
- Endpoints: POST /sessions/heartbeat/
B.14.1.3: SessionDetailDrawer - Phase 5 detail view
- Agent: Task(subagent_type="generative-ui-architect", prompt="Implement SessionDetailDrawer with session info, user list, heartbeat timeline chart")
- Endpoints: GET /sessions/{id}/user-sessions/
B.14.1.4: UserSessionManager - Phase 6 admin
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create UserSessionManager showing active users with kick button using POST /sessions/{id}/kick-user/")
- Endpoints: POST /sessions/{id}/kick-user/

Estimated Time: 12-16 hours Priority: P1 - High

B.15: Admin License Management & Validation (Gap Analysis - High)

Status: NEW (Jan 20, 2026)

Reference: CODITECT-UI-GAP-ANALYSIS.md

Gap: License extend/revoke endpoints exist but no UI. Form validation is HTML5 only.

Files to Create/Modify:

src/components/admin/LicenseExtendModal.tsx (NEW)
src/components/admin/LicenseRevokeConfirm.tsx (NEW)
src/components/admin/AdminLicenseTable.tsx (UPDATE - add action buttons)
src/lib/validations/ (NEW directory)
src/lib/validations/adminSchemas.ts (NEW)
src/components/ui/Toaster.tsx (NEW)

Agent Invocation:

Task(subagent_type="frontend-react-typescript-expert", prompt="Add admin license management and validation in coditect-cloud-frontend: (1) LicenseExtendModal with date picker calling PATCH /admin/licenses/{id}/extend/; (2) LicenseRevokeConfirm with confirmation dialog calling DELETE /admin/licenses/{id}/revoke/; (3) Install zod and create admin form schemas; (4) Install react-hot-toast and create Toaster component")

Tasks:

B.15.1.1: LicenseExtendModal - Admin license extension
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create LicenseExtendModal with date picker, reason field, calling PATCH /admin/licenses/{id}/extend/")
- Endpoints: PATCH /admin/licenses/{id}/extend/
B.15.1.2: LicenseRevokeConfirm - Admin license revocation
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create LicenseRevokeConfirm with confirmation dialog, reason field, calling DELETE /admin/licenses/{id}/revoke/")
- Endpoints: DELETE /admin/licenses/{id}/revoke/
B.15.1.3: Zod Integration - Form validation
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Install zod and @hookform/resolvers, create adminSchemas.ts with validation for all admin forms")
- Dependencies: zod, @hookform/resolvers
B.15.1.4: Toast System - Global notifications
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Install react-hot-toast, create Toaster component, add to App.tsx layout")
- Dependencies: react-hot-toast

Estimated Time: 8-12 hours Priority: P1 - High

B.16: Frontend Infrastructure (Gap Analysis - Medium)

Status: NEW (Jan 20, 2026)

Reference: CODITECT-UI-GAP-ANALYSIS.md

Gap: Missing error boundaries, skeleton loaders, retry logic, offline detection.

Files to Create/Modify:

src/components/ui/ErrorBoundary.tsx (NEW)
src/components/ui/Skeleton.tsx (NEW)
src/lib/retryClient.ts (NEW)
src/hooks/useOnlineStatus.ts (NEW)
src/components/ui/OfflineBanner.tsx (NEW)

Agent Invocation:

Task(subagent_type="moe-ui-quality-gate-enforcer", prompt="Add frontend infrastructure to coditect-cloud-frontend: (1) Global ErrorBoundary with error reporting and retry; (2) Skeleton loader components for tables, cards, lists; (3) Axios retry logic with exponential backoff; (4) useOnlineStatus hook and OfflineBanner component")

Tasks:

B.16.1.1: ErrorBoundary - Global error catching
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create ErrorBoundary component with error reporting, retry button, and fallback UI")
B.16.1.2: SkeletonLoaders - Loading state components
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create Skeleton components: SkeletonTable, SkeletonCard, SkeletonList with pulse animation")
B.16.1.3: RetryLogic - API request retry
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create retryClient.ts with axios-retry, exponential backoff, 3 retries on 5xx errors")
- Dependencies: axios-retry
B.16.1.4: OfflineDetector - Connectivity awareness
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create useOnlineStatus hook with navigator.onLine and event listeners, OfflineBanner component")

Estimated Time: 8-10 hours Priority: P2 - Medium

B.17: Enhanced RBAC Permission System UI (ADR-092 Implementation) 🆕

Status: NEW (Jan 20, 2026)

Reference: ADR-092-enhanced-rbac-permission-system.md

Goal: Implement comprehensive permission management UI with visual permission matrix, user permission inspector, and drill-down administration.

Agent Invocation:

Task(subagent_type="frontend-react-typescript-expert", prompt="Implement ADR-092 Enhanced RBAC Permission System frontend: (1) Permission Matrix component for visual role-permission management; (2) User Permission Inspector with drill-down; (3) Permission Grant/Revoke modals; (4) Permission Audit Log viewer; (5) Integrate with existing admin panel")

B.17.1: Permission Types and API Integration (Day 1-2)

Files to Create:

src/types/permissions.ts
src/services/permission.service.ts
src/hooks/usePermissions.ts (enhance existing)

Tasks:

B.17.1.1: Define Permission types
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create permission types: Permission, PermissionCategory, RolePermission, UserPermissionOverride, PermissionAuditEntry, EffectivePermission with source tracking")
- Status: COMPLETE (Jan 20, 2026) - Created in usePermissions.ts
B.17.1.2: Create permission service
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create permission.service.ts with methods: getPermissions(), getPermissionsByCategory(), getUserEffectivePermissions(userId), grantPermission(), revokePermission(), getAuditLog()")
- Status: PARTIAL - Basic service in admin.service.ts
B.17.1.3: Enhance usePermissions hook
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Enhance usePermissions hook with can(), canAll(), canAny(), getEffectivePermissions(), hasOverride() methods")
- Status: COMPLETE (Jan 20, 2026)

B.17.2: Permission Matrix Component (Day 3-5)

Files to Create:

src/components/admin/permissions/PermissionMatrix.tsx
src/components/admin/permissions/PermissionMatrixRow.tsx
src/components/admin/permissions/PermissionCategoryHeader.tsx

Tasks:

B.17.2.1: Create PermissionMatrix component
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create PermissionMatrix component: grid with roles as columns, permissions grouped by category as rows, checkboxes for role-permission mappings, editable for super_admin")
- Columns: System roles (super_admin, support, sales, readonly, user) + Tenant roles (owner, admin, member, viewer, guest)
- Rows: Permissions grouped by category (users, tenants, teams, projects, etc.)
- Color coding: green=granted, red=denied, gray=inherited
B.17.2.2: Create PermissionMatrixRow component
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create PermissionMatrixRow for single permission: permission name, description tooltip, checkbox per role with hover state showing inheritance source")
B.17.2.3: Create PermissionCategoryHeader
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create collapsible PermissionCategoryHeader with category name, permission count, expand/collapse chevron, bulk grant/revoke for category")
B.17.2.4: Add matrix filtering and search
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Add search bar to filter permissions, category filter dropdown, show only modified toggle")

B.17.3: User Permission Inspector (Day 6-8)

Files to Create:

src/components/admin/permissions/UserPermissionInspector.tsx
src/components/admin/permissions/EffectivePermissionList.tsx
src/components/admin/permissions/PermissionOverrideCard.tsx

Tasks:

B.17.3.1: Create UserPermissionInspector component ✅ (Jan 21)
- Status: COMPLETE - 700+ line component in UserPermissionInspector.tsx
- User selector, effective permissions list with source tracking, group by category/source/alphabetical
- Uses usePermissionMatrix, useOverridesForUser from usePermissionsApi.ts
B.17.3.2: Create EffectivePermissionList ✅ (Jan 21)
- Status: COMPLETE - Implemented inline in UserPermissionInspector
- Shows permission with granted/denied icon, source tracking, expandable details
B.17.3.3: Create PermissionOverrideCard ✅ (Jan 21)
- Status: COMPLETE - Integrated in UserPermissionInspector with override management
B.17.3.4: Add permission comparison view ✅ (Jan 21)
- Status: COMPLETE - Comparison mode in UserPermissionInspector (select two users)

B.17.4: Permission Grant/Revoke Modals (Day 9-10)

Files to Create:

src/components/admin/permissions/GrantPermissionModal.tsx
src/components/admin/permissions/RevokePermissionModal.tsx
src/components/admin/permissions/BulkPermissionModal.tsx

Tasks:

B.17.4.1: Create GrantPermissionModal ✅ (Jan 21)
- Status: COMPLETE - Combined in GrantRevokePermissionDialog.tsx (mode='grant')
- Permission dropdown with category filter, scope selector, expiry date, reason field
B.17.4.2: Create RevokePermissionModal ✅ (Jan 21)
- Status: COMPLETE - Combined in GrantRevokePermissionDialog.tsx (mode='revoke')
- Uses useRevokePermission mutation, reason required
B.17.4.3: Create BulkPermissionModal ✅ (Jan 21)
- Status: COMPLETE - Bulk operations via UserPermissionOverrideManager.tsx
B.17.4.4: Add confirmation and audit logging ✅ (Jan 21)
- Status: COMPLETE - Confirmation built into dialog, audit via backend API

B.17.5: Permission Audit Log Viewer (Day 11-12)

Files to Create:

src/components/admin/permissions/PermissionAuditLog.tsx
src/components/admin/permissions/AuditLogEntry.tsx
src/components/admin/permissions/AuditLogFilters.tsx

Tasks:

B.17.5.1: Create PermissionAuditLog component ✅ (Jan 21)
- Status: COMPLETE - PermissionAuditLogViewer.tsx (~200 lines)
- Paginated table with action color coding, search, filtering via useAuditLogs
B.17.5.2: Create AuditLogFilters ✅ (Jan 21)
- Status: COMPLETE - Integrated in PermissionAuditLogViewer
- Filters: user_id, target_user_id, permission_code, action type
B.17.5.3: Create AuditLogEntry expandable row ✅ (Jan 21)
- Status: COMPLETE - Entries show timestamp, actor, action, target, permission, reason

B.17.6: Admin Panel Integration (Day 13-14)

Files to Modify:

src/components/admin/AdminPage.tsx
src/components/admin/blocks/UsersBlock.tsx
src/components/admin/blocks/UserPermissionAdminPanel.tsx

Tasks:

B.17.6.1: Add Permissions tab to AdminPage
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Add Permissions tab to AdminPage with PermissionMatrix, guard with admin:view_permissions")
- Status: COMPLETE (Jan 20, 2026) - Basic tab added
B.17.6.2: Enhance UserPermissionAdminPanel
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Enhance UserPermissionAdminPanel with drill-down to UserPermissionInspector, quick permission grant/revoke buttons")
- Status: PARTIAL (Jan 20, 2026) - Basic panel created
B.17.6.3: Add permission column to UsersBlock ✅ (Jan 21)
- Status: COMPLETE - Added "Permissions" column with "View" button
- Opens UserPermissionInspector modal when clicked
- Guarded with <Can permission="users:view">
B.17.6.4: Add permission-based UI visibility ✅ (Jan 21)
- Status: COMPLETE - AdminPage tabs now use <Can> components
- Converted isSystemAdmin && conditionals to permission-based gating
- Permissions, Provisioning, Approvals tabs all permission-gated

Dependencies:

ADR-092 (Enhanced RBAC) ✅ Created
A.15 (Backend RBAC) - API endpoints required
B.5 (Shared Components) ✅ Complete - usePermissions hook created

Estimated Time: 40-48 hours (spread across 2-3 weeks) Priority: P1 - High (blocks secure multi-tenant administration)

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: support@coditect.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)

C.7: Context Watcher Process Detection Fix

Status: 🔄 In Progress (Jan 12, 2026) Goal: Fix process detection in codi-watcher service showing 0 active Claude processes ADR: ADR-066-context-watcher-service.md

Problem Summary:

Service runs successfully (launchctl shows PID with status 0)
Auto-exports and /cx processing work correctly
Process detection consistently shows "0 active" despite Claude processes running
pgrep -x claude works from shell but detection fails in service context

Investigation Completed (Jan 12, 2026):

Binary renamed from coditect-context-watch to codi-watcher (Claude Code shell integration issue)
Added ps aux fallback in codanna (commit 7612049)
ADR-066 updated with binary naming workaround
install-context-watcher.py updated with binary verification

Root Cause Hypothesis:

pgrep works in launchd context (verified)
lsof parsing may have edge case issue
Debug logging via tracing::debug! not visible in release builds
Need to add eprintln! debugging to identify exact failure point

Tasks:

C.7.1: Debug Process Detection

C.7.1.1: Add eprintln! debugging to find_claude_processes()
- Agent: Task(subagent_type="rust-qa-specialist", prompt="Add temporary eprintln! debugging to codanna/src/watcher/context_watcher.rs find_claude_processes() to log: pgrep output, ps fallback output, lsof output, final process count")
- Add debug output after pgrep execution
- Add debug output after ps fallback
- Add debug output after lsof parsing
- Rebuild and deploy to see what's failing
C.7.1.2: Identify and fix the detection failure
- Agent: Task(subagent_type="rust-qa-specialist", prompt="Based on debug output, fix the process detection issue in codanna context_watcher.rs - may be lsof parsing, PATH issue, or environment difference")
C.7.1.3: Remove debug logging and create final release
- Agent: Task(subagent_type="devops-engineer", prompt="Remove eprintln! debugging, rebuild codi-watcher release binary, deploy and verify process detection works")
C.7.1.4: Update service documentation
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Update context watcher README and ADR-066 with final fix details")

Commits Related:

codanna 7612049: Added ps aux fallback and debug logging
coditect-core c221cf30: Updated service configs to use codi-watcher binary
coditect-core ce3d126e: ADR-066 binary naming workaround documentation

Estimated Time: 2-4 hours

Priority: P2 (Service functional for exports, process detection is nice-to-have)

C.8: GCS Binary Distribution System

Status: ✅ Phase 1 Complete, Phase 2 Pending (Jan 12, 2026) Goal: Public binary distribution via GCS with automated CI/CD upload ADR: ADR-066-context-watcher-service.md

Current Architecture (Phase 1 - Public Access):

┌─────────────────┐     ┌──────────────────────────────────────────────┐
│  GitHub Actions │────▶│  gs://coditect-dist/codi-watcher/v{VER}/    │
│  (Build + Upload)     │  (Public Read Access)                        │
└─────────────────┘     └──────────────────────────────────────────────┘
                                       │
                                       ▼
                        ┌──────────────────────────────────────────────┐
                        │  CODITECT-CORE-INITIAL-SETUP.py             │
                        │  Downloads from public GCS URL               │
                        │  https://storage.googleapis.com/coditect-dist│
                        └──────────────────────────────────────────────┘

Live URLs (v0.3.0):

macOS ARM64: https://storage.googleapis.com/coditect-dist/codi-watcher/v0.3.0/codi-watcher-darwin-arm64
macOS x86_64: https://storage.googleapis.com/coditect-dist/codi-watcher/v0.3.0/codi-watcher-darwin-x86_64
Linux x86_64: https://storage.googleapis.com/coditect-dist/codi-watcher/v0.3.0/codi-watcher-linux-x86_64

Phase 1 Completed (Jan 12, 2026):

C.8.1.1: Create GCS bucket gs://coditect-dist with public read access ✅
C.8.1.2: Upload v0.3.0 binaries for all 3 platforms ✅
C.8.1.3: Update CODITECT-CORE-INITIAL-SETUP.py to use GCS URL ✅
C.8.1.4: Add SHA256 checksum verification ✅
C.8.1.5: Add macOS code signing after download ✅
C.8.1.6: Update ADR-066 with GCS deployment architecture ✅
C.8.3.1: Add GCS upload step to release workflow ✅
- Commit: 46f64899 - Workflow now uploads to GCS after GitHub release

Tasks:

C.8.3: GitHub Actions GCS Upload (Service Account Setup) - PENDING

C.8.3.2: Create GCS service account for GitHub Actions
- Agent: Task(subagent_type="devops-engineer", prompt="Create service account codi-watcher-release@coditect-citus-prod.iam.gserviceaccount.com for GitHub Actions GCS upload")
- Commands:
```
gcloud iam service-accounts create codi-watcher-release \
  --display-name="codi-watcher Release CI" \
  --project=coditect-citus-prod
```
C.8.3.3: Grant Storage Object Admin on bucket
- Agent: Task(subagent_type="devops-engineer", prompt="Grant Storage Object Admin role to codi-watcher-release service account on gs://coditect-dist bucket")
- Commands:
```
gsutil iam ch \
  serviceAccount:codi-watcher-release@coditect-citus-prod.iam.gserviceaccount.com:objectAdmin \
  gs://coditect-dist
```
C.8.3.4: Create and export service account key
- Agent: Task(subagent_type="devops-engineer", prompt="Create JSON key for codi-watcher-release service account")
- Commands:
```
gcloud iam service-accounts keys create key.json \
  --iam-account=codi-watcher-release@coditect-citus-prod.iam.gserviceaccount.com
```
C.8.3.5: Add GCS_SA_KEY secret to GitHub repository
- Agent: Task(subagent_type="devops-engineer", prompt="Add GCS_SA_KEY secret to coditect-ai/coditect-core GitHub repository settings")
- Steps: GitHub → Settings → Secrets → Actions → New secret → Name: GCS_SA_KEY, Value: (paste key.json contents)
C.8.3.6: Test release workflow with GCS upload
- Agent: Task(subagent_type="devops-engineer", prompt="Test codi-watcher release workflow by creating tag codi-watcher-v0.3.1 and verifying binaries appear in gs://coditect-dist")

C.8.4: Phase 2 - Download Tracking (Future Enhancement)

C.8.4.1: Create BinaryDownload model for tracking
- Agent: Task(subagent_type="database-architect", prompt="Create BinaryDownload model in coditect-cloud-infra with fields: id, binary_name, version, platform, machine_id, ip_address, user_agent, downloaded_at, tenant")
C.8.4.2: Add Django API endpoint for tracked downloads
- Agent: Task(subagent_type="senior-architect", prompt="Create POST /api/v1/releases/download endpoint that logs download and returns signed URL")
C.8.4.3: Update install script to call API for tracking
- Agent: Task(subagent_type="senior-architect", prompt="Update CODITECT-CORE-INITIAL-SETUP.py to optionally call API for download tracking before falling back to public URL")

Verification:

# Test public URL access
curl -sI "https://storage.googleapis.com/coditect-dist/codi-watcher/v0.3.0/codi-watcher-darwin-arm64" | head -5

# Verify checksum
curl -sL "https://storage.googleapis.com/coditect-dist/codi-watcher/v0.3.0/codi-watcher-darwin-arm64.sha256"

# Test installation
python3 ~/.coditect/scripts/CODITECT-CORE-INITIAL-SETUP.py --verify-only

Commits Related:

coditect-core a42242d5: fix: Use GCS for codi-watcher binary distribution
coditect-core 46f64899: feat: Add GCS upload automation to codi-watcher release workflow
coditect-core 70bbae2a: docs: Update ADR-066 with GCS distribution architecture

Estimated Time: 2 hours (Phase 1 service account setup)

Priority: P1 (Required for automated releases)

C.8.5: Bootstrap Installer & Documentation Distribution (COMPLETED Jan 12, 2026)

Status: ✅ COMPLETE

Completed Tasks:

C.8.5.1: Create bootstrap installer script (install.py) for curl-based installation ✅
- Single command: curl -sL https://storage.googleapis.com/coditect-dist/install.py | python3
- GitHub CLI OAuth authentication (no PATs required)
- Auto-installs Homebrew and gh CLI if needed
- Repository cloning via gh CLI
C.8.5.2: Upload documentation to GCS ✅
- gs://coditect-dist/docs/USER-QUICK-START.md
- gs://coditect-dist/docs/PILOT-INVITATION-EMAIL.md
- gs://coditect-dist/docs/GITHUB-CLI-USER-MANAGEMENT.md
- gs://coditect-dist/LICENSE.txt
- gs://coditect-dist/install.py
C.8.5.3: Fix GitHub markdown compatibility in documentation ✅
- Added text language specifier to all terminal output code blocks
- Fixed version mismatch in footer (3.0.0 → 4.0.0)
C.8.5.4: Add CODITECT standard frontmatter to templates ✅
- Added complete YAML frontmatter to PILOT-INVITATION-EMAIL.md
- MoE classification fields included

Commits:

coditect-core bdd20c3c: refactor(install): Remove token auth, require GitHub CLI
coditect-core f820826e: docs: Fix GitHub markdown compatibility and add CODITECT frontmatter

GCS Bucket Contents:

gs://coditect-dist/
├── LICENSE.txt
├── install.py
├── docs/
│   ├── USER-QUICK-START.md
│   ├── PILOT-INVITATION-EMAIL.md
│   └── GITHUB-CLI-USER-MANAGEMENT.md
└── codi-watcher/
    └── v0.3.0/
        ├── codi-watcher-darwin-arm64
        ├── codi-watcher-darwin-x86_64
        └── codi-watcher-linux-x86_64

C.9: Secured Distribution Portal (ADR-090)

Status: ✅ INFRASTRUCTURE COMPLETE (90%) - Pending deployment & transition Goal: Require auth.coditect.ai login + admin approval to access installation instructions and download URLs Priority: P1 (Required for pilot security) ADR: ADR-090: Authenticated Downloads Portal Completed: 2026-01-21 (Backend signed URL endpoint, Frontend /downloads portal, Terraform conditional access)

Architecture Decision: Use GCS Signed URLs generated by authenticated backend API. Users must:

Register at auth.coditect.ai with email verification
Be approved by admin (or auto-approved for pilot list)
Log in to access /downloads page
Click download → Backend generates signed URL

Flow:

User → auth.coditect.ai → Login (OAuth/email)
auth.coditect.ai → /downloads page (authenticated)
User clicks download → Backend generates signed URL
Signed URL → GCS download (time-limited, single-use)

Tasks:

C.9.1: Backend Signed URL Generation

C.9.1.1: Create Django endpoint for signed URL generation
- Agent: Task(subagent_type="senior-architect", prompt="Create POST /api/v1/releases/signed-url endpoint in coditect-cloud-infra/backend that generates time-limited GCS signed URLs for authenticated users")
- Endpoint: POST /api/v1/releases/signed-url
- Request: {"binary_name": "codi-watcher", "version": "v0.3.0", "platform": "darwin-arm64"}
- Response: {"url": "https://storage.googleapis.com/coditect-dist/...", "expires_at": "2026-01-12T12:30:00Z"}
- Auth: Bearer token required
- Expiry: 15 minutes
C.9.1.2: ~~Create GCS service account~~ Using GKE Workload Identity
- Status: Backend uses django-backend Kubernetes SA with Workload Identity - automatic GCS access
- Note: No separate service account needed; backend generates signed URLs via GCS client with WI credentials
C.9.1.3: Add signed URL generation to backend
- Agent: Task(subagent_type="senior-architect", prompt="Implement google-cloud-storage signed URL generation in coditect-cloud-infra/backend using service account credentials")

C.9.2: Frontend Download Portal

C.9.2.1: Create /downloads page in auth.coditect.ai frontend
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create /downloads page in coditect-cloud-frontend that shows installation instructions, requirements, and download buttons. Requires authentication.")
- Features:
  - System requirements display
  - Platform detection (auto-select macOS/Linux/Windows)
  - Download button with signed URL fetch
  - Installation instructions inline
  - Link to USER-QUICK-START.md
C.9.2.2: Add protected route for /downloads
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Add /downloads to protected routes in coditect-cloud-frontend, redirect unauthenticated users to /login with return URL")
C.9.2.3: Update PILOT-INVITATION-EMAIL.md with auth.coditect.ai links
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Update PILOT-INVITATION-EMAIL.md to direct users to https://auth.coditect.ai/downloads instead of direct GCS URLs")

C.9.3: Download Tracking Integration

C.9.3.1: Log downloads with user info
- Agent: Task(subagent_type="senior-architect", prompt="Extend BinaryDownload model to include user_id field and log authenticated downloads in signed-url endpoint")

C.9.4: User Approval Workflow (ADR-090)

C.9.4.1: Extend User model with approval fields
- Agent: Task(subagent_type="senior-architect", prompt="Add fields to User model: email_verified, download_approved, approved_by, approved_at, company, use_case. Create migration.")
- Fields: email_verified (bool), download_approved (bool), approved_by (FK), approved_at (datetime), company (str), use_case (text)
C.9.4.2: Create DownloadableFile model
- Agent: Task(subagent_type="senior-architect", prompt="Create DownloadableFile model with name, version, platform, architecture, gcs_path, file_size, sha256, description, category, is_active, requires_approval fields")
C.9.4.3: Create DownloadLog model
- Agent: Task(subagent_type="senior-architect", prompt="Create DownloadLog model with user (FK), file (FK), downloaded_at, ip_address, user_agent, success fields for analytics")
C.9.4.4: Implement auto-approval rules
- Agent: Task(subagent_type="senior-architect", prompt="Create auto-approval logic for pilot domains (@az1.ai, @coditect.ai) and pilot email list in post_save signal")
C.9.4.5: Create admin approval endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create POST /api/v1/admin/users/{id}/approve endpoint for admin to approve user download access")

C.9.5: Admin Approval UI (Frontend)

C.9.5.1: Create /admin/users page
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create /admin/users page showing pending approval users with approve/reject buttons, company and use_case display")
C.9.5.2: Add download analytics dashboard
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Create /admin/downloads page showing download counts by file, user, platform with date filters")

C.9.6: GCS Bucket Security Migration

Status: Infrastructure Ready - Execute transition when portal deployed

C.9.6.1: Update Terraform with conditional public access (2026-01-21)
- File: distribution/.../opentofu/main.tf
- Variable: enable_public_access = true (set to false to remove public access)
- Implementation: Added count conditional on google_storage_bucket_iam_member.public_read
C.9.6.2: Configure backend for signed URLs (2026-01-21)
- Status: Backend uses GKE Workload Identity - automatic credential handling
- Added: Optional backend_service_account variable in Terraform for explicit binding
C.9.6.3: Document transition checklist (2026-01-21)
- Location: docs/session-logs/SESSION-LOG-2026-01-21.md
- Steps: Deploy portal → Test signed URLs → Set enable_public_access=false → tofu apply

⚠️ TRANSITION CHECKLIST (Execute when ready):

# 1. Deploy frontend with /downloads page
# 2. Verify: curl -I https://auth.coditect.ai/downloads (200 OK)
# 3. Test signed URL endpoint with auth token
# 4. Update tfvars: enable_public_access = false
# 5. Apply: cd opentofu && tofu plan && tofu apply
# 6. Verify public access removed (should return 403)

Verification:

# Test authentication required
curl -s https://auth.coditect.ai/api/v1/releases/signed-url \
  -H "Content-Type: application/json" \
  -d '{"binary_name":"install.py"}' | jq .
# Expected: 401 Unauthorized

# Test with auth token
curl -s https://auth.coditect.ai/api/v1/releases/signed-url \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"binary_name":"install.py"}' | jq .
# Expected: {"url": "https://storage.googleapis.com/...", "expires_at": "..."}

Estimated Time: 8 hours Priority: P1 (Required for pilot launch) Depends On: C.8.5 (bootstrap installer exists)

C.10: Email Infrastructure (Amazon SES)

Status: 🔲 NOT STARTED Goal: Enable CODITECT to send pilot invitation emails via Amazon SES Priority: P2 (Required for scaled pilot invitations)

Architecture Decision: Use Amazon SES for transactional emails. More cost-effective than SendGrid (~$0.10/1000 emails vs $0.50+), API-driven with boto3, solid deliverability. Store templates in Django, send via boto3 SES client.

Cost Comparison:

Provider	Cost per 1000 emails	Notes
Amazon SES	$0.10	Pay-as-you-go, no monthly minimum
SendGrid	$0.50-1.50	Requires paid plan for production
Google Workspace	Included	Limited to 2000/day

Tasks:

C.10.1: Amazon SES Setup

C.10.1.1: Verify sender identity in SES
- Agent: Task(subagent_type="devops-engineer", prompt="Verify coditect.ai domain in Amazon SES us-east-1 region, add DKIM CNAME records to DNS")
- Console: AWS Console → SES → Verified Identities → Create Identity → Domain
- DNS Records: Add 3 CNAME records for DKIM authentication
C.10.1.2: Request production access (move out of sandbox)
- Manual: AWS Console → SES → Account Dashboard → Request Production Access
- Justification: "Transactional emails for CODITECT pilot program invitations"
- Timeline: 24-48 hours approval
C.10.1.3: Create IAM role for SES access
- Agent: Task(subagent_type="devops-engineer", prompt="Create IAM role coditect-ses-sender with ses:SendEmail and ses:SendRawEmail permissions, attach to Cloud Run service account")
- Policy:
```
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ses:SendEmail", "ses:SendRawEmail"],
    "Resource": "*"
  }]
}
```

C.10.2: Backend Email Integration

C.10.2.1: Install boto3 and configure SES
- Agent: Task(subagent_type="senior-architect", prompt="Add boto3 to requirements.txt in coditect-cloud-infra/backend and create core/email/ses_backend.py for Django EMAIL_BACKEND")
- Config: AWS_SES_REGION_NAME = 'us-east-1'
C.10.2.2: Create EmailTemplate model
- Agent: Task(subagent_type="database-architect", prompt="Create EmailTemplate model in coditect-cloud-infra/backend with fields: id, name, subject, html_body, text_body, variables (JSON), tenant, created_at, updated_at")
C.10.2.3: Create pilot invitation template
- Agent: Task(subagent_type="codi-documentation-writer", prompt="Create HTML email template for pilot invitation based on PILOT-INVITATION-EMAIL.md, with variables: {{name}}, {{download_url}}, {{support_email}}")
C.10.2.4: Create email sending endpoint
- Agent: Task(subagent_type="senior-architect", prompt="Create POST /api/v1/admin/send-invitation endpoint in coditect-cloud-infra/backend that sends pilot invitation email via Amazon SES using boto3")
- Endpoint: POST /api/v1/admin/send-invitation
- Request: {"email": "user@example.com", "name": "John Doe"}
- Auth: Admin only

C.10.3: CLI Email Tool

C.10.3.1: Create send-pilot-invitation.py script
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/send-pilot-invitation.py that calls the backend API to send invitation emails, supports CSV input for batch sending")
- Usage: python3 send-pilot-invitation.py --email user@example.com --name "John Doe"
- Batch: python3 send-pilot-invitation.py --csv pilot-invites.csv

Verification:

# Test email sending (single)
python3 scripts/send-pilot-invitation.py \
  --email test@example.com \
  --name "Test User" \
  --dry-run

# Verify SES delivery
aws ses get-send-statistics --region us-east-1

# Check SES sending quota
aws ses get-send-quota --region us-east-1

Estimated Time: 5 hours Priority: P2 (Nice to have for pilot, required for scale) Depends On: C.9 (download portal for link generation)

C.11: Update & Uninstall Mechanism ✅

Status: ✅ COMPLETE (Jan 12, 2026) Goal: Enable users to easily update and uninstall their CODITECT installation Priority: P1 (Required for pilot - users need to get fixes)

Architecture:

/orient (session start)
    ↓
Check gs://coditect-dist/version.json
    ↓
Compare with ~/.coditect/VERSION
    ↓
Show notification if outdated: "⚠ Update available: v1.0.0 → v1.1.0. Run /update"

/update                              /uninstall
    ↓                                    ↓
git fetch origin main                Stop services
    ↓                                    ↓
Show changelog (what's new)          Remove symlinks
    ↓                                    ↓
git pull --rebase origin main        Clean Claude settings
    ↓                                    ↓
Run post-update setup (if needed)    Remove protected dir
    ↓                                    ↓
Update ~/.coditect/VERSION           "✓ Uninstalled"
    ↓
"✓ Updated to v1.1.0"

Key Design:

Updates go to protected location only (~/Library/Application Support/CODITECT/core/)
~/.coditect symlink ensures correct target
Developers with submodules are unaffected (they update via git separately)
Uninstall offers data preservation option (--keep-data)

Tasks:

C.11.1: Version Infrastructure ✅

C.11.1.1: Create VERSION file in coditect-core root ✅ (Jan 12, 2026)
- File: ~/.coditect/VERSION = 1.0.0
C.11.1.2: Create version.json on GCS ✅ (Jan 12, 2026)
- URL: https://storage.googleapis.com/coditect-dist/version.json
- Content: {"latest": "1.0.0", "released": "2026-01-12", ...}
C.11.1.3: Add version.json upload to release workflow ✅ (Jan 13, 2026)
- File: .github/workflows/release.yml
- Note: Uploads version.json to GCS after GitHub release via Workload Identity

C.11.2: /update Command ✅

C.11.2.1: Create /update command ✅ (Jan 12, 2026)
- File: ~/.coditect/commands/update.md
C.11.2.2: Create update-coditect.py script ✅ (Jan 12, 2026)
- File: ~/.coditect/scripts/update-coditect.py (407 lines)
- Features: Version check, changelog, git pull --rebase, dependency update
C.11.2.3: Add submodule detection (safety) ✅ (Jan 12, 2026)
- Message: "This appears to be a development submodule. Use git pull directly instead of /update."

C.11.3: /uninstall Command ✅ (NEW - Jan 12, 2026)

C.11.3.1: Create /uninstall command ✅
- File: ~/.coditect/commands/uninstall.md
C.11.3.2: Create uninstall-coditect.py script ✅
- File: ~/.coditect/scripts/uninstall-coditect.py (474 lines)
- Features: Stop services, remove symlinks, clean settings, backup offer, --keep-data
C.11.3.3: Document removal mechanism in ADR-066 ✅

C.11.4: Update Check in /orient ✅

C.11.4.1: Add version check to orient command ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Modify commands/orient.md to check for updates on session start by comparing local VERSION with gs://coditect-dist/version.json")
- Output: ⬆️ UPDATE AVAILABLE: v1.0.0 → v1.1.0. Run /update to get latest fixes.
- Commit: f7e788e feat(C.11.4): Add version check to /orient with 24h cache
C.11.4.2: Cache version check (rate limit) ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Add 24-hour cache for version check to avoid hitting GCS on every /orient. Store in ~/PROJECTS/.coditect-data/context-storage/version-check.json")
- Note: Implemented in check_for_updates() function with 24-hour TTL

C.11.5: Release Automation ✅

C.11.1.3: Add version.json upload to release workflow ✅ (Jan 13, 2026)
- File: .github/workflows/release.yml
- Note: Uploads version.json to GCS after GitHub release via Workload Identity
C.11.5.1: Create release checklist script ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create scripts/prepare-release.py that bumps VERSION, updates CHANGELOG, creates git tag, and uploads version.json to GCS")
- File: scripts/prepare-release.py
- Features: Version bumping, CHANGELOG update, git commit/tag, GCS upload, dry-run mode
- Commit: de19a6e feat(C.11): Complete release automation

Verification:

# Check current version
cat ~/.coditect/VERSION

# Check latest available
curl -s https://storage.googleapis.com/coditect-dist/version.json | jq .

# Test update command
/update --check

# Test uninstall (dry run)
/uninstall --dry-run

# Test release preparation (dry run)
python3 scripts/prepare-release.py --dry-run patch

Completed: January 13, 2026 (All functionality) Remaining: None - C.11 100% complete Priority: P1 (Required for pilot - users need bug fixes) Depends On: C.8.5 (installation infrastructure)

C.12: Time-Controlled Licensing System ✅

Status: ✅ COMPLETE (100% - 20/20 tasks completed Jan 13, 2026) Goal: Implement licensing system for pilot trials, subscriptions, and enterprise licensing Priority: P1 (Required for commercialization) ADR: ADR-067-time-controlled-licensing.md

Architecture:

┌─────────────────────────────────────────────────────────────────────────┐
│                    CODITECT LICENSING SYSTEM                             │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│   LOCAL                                    CLOUD                         │
│   ┌────────────────────┐                  ┌────────────────────────────┐│
│   │ ~/.coditect/       │                  │ api.coditect.ai            ││
│   │ ├── license/       │                  │                            ││
│   │ │   ├── license.json  ◄───activate───│ POST /licenses/activate    ││
│   │ │   ├── validation.json◄──validate───│ POST /licenses/validate    ││
│   │ │   └── offline.json  │              │ POST /licenses/revoke      ││
│   │ └── machine-id.json   │              │ GET  /licenses/revocations ││
│   └────────────────────┘                  └────────────────────────────┘│
│                                                                          │
│   VALIDATION FLOW (/orient)                                             │
│   ┌──────────────────────────────────────────────────────────────────┐  │
│   │ Load license.json → Verify Ed25519 sig → Check machine binding   │  │
│   │ → Check expiration → Server validate (if stale) → Grant access   │  │
│   └──────────────────────────────────────────────────────────────────┘  │
│                                                                          │
│   LICENSE STATES: ACTIVE → WARNING (7d) → GRACE (7-14d) → EXPIRED      │
│                                                                          │
└─────────────────────────────────────────────────────────────────────────┘

License Types:

Type	Duration	Grace	Offline	Devices	Price
Pilot	90 days	7 days	7 days	1	Free
Pro	Monthly/Annual	7 days	14 days	2	$29/mo
Team	Annual	3 days	7 days	Per-seat	$99/seat
Enterprise	Custom	Config	Config	Unlimited	Custom

Tasks:

C.12.1: License Infrastructure (Foundation)

C.12.1.1: Create license directory structure ✅ (Jan 12, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create ~/.coditect/licensing/ directory with license.json, validation-cache.json, and offline-log.json templates")
- Files:
  - ~/.coditect/licensing/license.json.template - License file template
  - ~/.coditect/licensing/validation-cache.json - Server check cache
  - ~/.coditect/licensing/offline-log.json - Offline period tracking
  - ~/.coditect/config/licensing.json - Tier configurations
- Note: Directory named licensing/ to avoid case-sensitivity conflict with LICENSE file
C.12.1.2: Create license validator module ✅ (Jan 12, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create scripts/core/license_validator.py with Ed25519 signature verification, machine binding check, expiration check, and grace period logic")
- Functions:
  - validate_license() - Full local validation
  - verify_signature() - Ed25519 verification
  - check_machine_binding() - Compare with machine-id.json
  - check_expiration() - State machine (ACTIVE/WARNING/GRACE/EXPIRED)
  - get_license_state() - Return current license state
- Commit: 1d10ae5 feat(C.12.1): Add licensing infrastructure
C.12.1.3: Create license CLI commands ✅ (Jan 12, 2026)
- Files:
  - commands/license-status.md - /license-status command
  - scripts/CODITECT-CORE-INITIAL-SETUP.py - Added licensing initialization step 10/10
- Commands:
  - /license-status - Show current license state
  - /license-activate - (pending - C.12.4)
  - /license-renew - (pending - C.12.4)
- Commit: f1fac92 feat(C.12.1.3): Add licensing initialization to setup script

C.12.2: Backend License API

C.12.2.1: Create License model extensions ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="database-architect", prompt="Extend License model in coditect-cloud-infra/backend with: device_bindings (JSONField), offline_tolerance_days, grace_period_days, max_devices, license_type enum (pilot/pro/team/enterprise)")
- Repository: submodules/cloud/coditect-cloud-infra/backend/
- Commit (cloud-infra): 0e1398ad feat(C.12.2.1): Extend License model with ADR-067 fields
C.12.2.2: Implement /licenses/activate endpoint ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create POST /api/v1/licenses/activate endpoint that validates license key, binds to machine UUID, and returns signed license JSON with Ed25519 signature")
- Input: {license_key, machine_uuid, device_name}
- Output: Signed license.json payload
- Commit (cloud-infra): 4388ccbf feat(C.12.2): Implement ADR-067 license API endpoints
C.12.2.3: Implement /licenses/validate endpoint ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create POST /api/v1/licenses/validate endpoint for periodic validation: check seat availability, revocation status, return refreshed license if valid")
- Input: {license_id, machine_uuid}
- Output: {valid: bool, license?: {...}, message?: string}
- Commit (cloud-infra): 4388ccbf feat(C.12.2): Implement ADR-067 license API endpoints
C.12.2.4: Implement /licenses/revoke endpoint ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create POST /api/v1/licenses/revoke endpoint for admin revocation: add to CRL, broadcast to all bound devices")
- Input: {license_id, reason}
- Admin only
- Commit (cloud-infra): 4388ccbf feat(C.12.2): Implement ADR-067 license API endpoints
C.12.2.5: Implement /licenses/revocations endpoint ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create GET /api/v1/licenses/revocations endpoint returning CRL (Certificate Revocation List) for offline checking")
- Output: {revocations: [{license_id, revoked_at, reason}], updated_at}
- Commit (cloud-infra): 4388ccbf feat(C.12.2): Implement ADR-067 license API endpoints

C.12.3: Cryptographic Signing

C.12.3.1: Setup Cloud KMS for license signing ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create Cloud KMS key ring 'coditect-licensing' with Ed25519 signing key 'license-signing-key-2026-01' in HSM protection level")
- Key: projects/coditect-citus-prod/locations/global/keyRings/coditect-licensing/cryptoKeys/license-signing-key-2026-01
- Note: Created keyring and Ed25519 signing key, granted signerVerifier role to django-backend SA
C.12.3.2: Implement license signing service ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Create backend service to sign license payloads using Cloud KMS Ed25519 key, embed signature in license.json")
- Commit (cloud-infra): 0e7fd3ae feat(C.12.3): Update KMS to Ed25519 for license signing
C.12.3.3: Embed public key in framework ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Export Ed25519 public key from Cloud KMS and embed in ~/.coditect/config/license-public-key.pem for offline verification")
- Commit (core): 276eaa2 feat(C.12.3.3): Add license public key to config

C.12.4: /orient Integration

C.12.4.1: Add license validation to /orient ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Modify commands/orient.md to run license validation on session start: check local license, validate with server if stale (>24h), show state banner")
- States:
  - ACTIVE - No banner, proceed
  - WARNING - "⚠ License expires in X days. Renew at coditect.ai/account"
  - GRACE - "⚠ License expired. Grace period: X days remaining. Some features disabled."
  - EXPIRED - "✗ License expired. Activate at coditect.ai or run /license activate"
- Commit (core): 0bc2235 feat(C.12.4.1): Add license validation to /orient
C.12.4.2: Implement offline tolerance tracking ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Track offline periods in ~/.coditect/license/offline-log.json, enforce max_offline_days limit, show warning when approaching limit")
- Commit (core): 77d38b6 feat(C.12.4.2): Implement offline tolerance tracking
C.12.4.3: Implement local revocation check ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Cache revocation list locally, check against it during offline validation, refresh on successful server contact")
- Commit (core): de4c9fa feat(C.12.4.3): Implement local CRL revocation check

C.12.5: Pilot License Generation

C.12.5.1: Create pilot license generator script ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="devops-engineer", prompt="Create scripts/generate-pilot-license.py that generates 90-day pilot licenses with email, outputs activation key")
- Usage: python3 generate-pilot-license.py --email user@company.com --name "John Doe"
- Output: License key in PILOT-XXXX-XXXX-XXXX-XXXX format
- Commit (cloud-infra): 3ccbda2e feat(C.12.5.1): Create pilot license generator script
C.12.5.2: Create license management admin UI ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="frontend-react-typescript-expert", prompt="Add license management section to Django admin: list licenses, filter by type/status, revoke, extend, view activations")
- Features: State badges, days remaining, device count, bulk actions (extend/revoke/suspend)
- Commit (cloud-infra): 057cf25f feat(C.12.5.2): Enhanced license admin UI
C.12.5.3: Integrate with pilot onboarding workflow ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="senior-architect", prompt="Update pilot onboarding to generate license key on invitation accept, include in welcome email, activate during CODITECT-CORE-INITIAL-SETUP.py")
- Files: /license-activate command, scripts/core/license-activate.py
- Commit (core): 7924d61 feat(C.12.5.3): Add /license-activate command

C.12.6: Testing

C.12.6.1: Unit tests for license validator ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="testing-specialist", prompt="Create tests for license_validator.py: signature verification, machine binding, expiration states, grace periods, offline tolerance")
- Tests: 32 unit tests covering all license states, machine binding, offline tolerance, CRL, tiers
- File: tests/core/test_license_validator.py
C.12.6.2: Integration tests for license API ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="testing-specialist", prompt="Create tests for license endpoints: activate, validate, revoke, revocations. Test with valid/invalid/expired/revoked licenses")
- File: tests/core/test_license_manager.py, distribution/tests/test_license_validation.sh
C.12.6.3: End-to-end license flow test ✅ (Jan 13, 2026)
- Agent: Task(subagent_type="testing-specialist", prompt="Create E2E test: generate pilot license → activate → validate → approach expiration → grace period → expiration")
- Tests: 16 E2E tests covering full lifecycle, activation, offline, binding, revocation, upgrades
- File: tests/core/test_license_e2e.py
- Commit (core): 1145ad3 feat(C.12.6.3): Add end-to-end license flow tests

Verification:

# Check license status
/license status

# Activate with key
/license activate CODITECT-PILOT-XXXX-XXXX-XXXX

# Verify license file
cat ~/.coditect/license/license.json | jq .

# Test validation API
curl -X POST https://api.coditect.ai/api/v1/licenses/validate \
  -H "Content-Type: application/json" \
  -d '{"license_id": "...", "machine_uuid": "..."}'

# Test offline behavior (disconnect network, run /orient)

Estimated Time: 40 hours Priority: P1 (Required for commercialization) Depends On: C.11 (update mechanism), D.4 (2FA for admin)

C.13: Gitea Git Server Infrastructure (NEW - Jan 20, 2026)

Repository: submodules/cloud/coditect-cloud-infra/ Purpose: Deploy Gitea self-hosted Git server for licensed container source code distribution

C.13.1: Gitea Secrets Configuration

C.13.1.1: Generate secure Gitea database password
C.13.1.2: Generate secure Gitea admin password
C.13.1.3: Generate Gitea secret key (for session signing)
C.13.1.4: Add secrets to terraform.tfvars or environment variables

C.13.2: Gitea Infrastructure Deployment

C.13.2.1: Run tofu apply with Gitea secrets configured
C.13.2.2: Verify Gitea database user created in Cloud SQL
C.13.2.3: Verify Gitea secrets stored in Secret Manager
C.13.2.4: Deploy Gitea Kubernetes manifests to GKE

C.13.3: Gitea Configuration

C.13.3.1: Configure Gitea with GitHub OAuth (for SSO)
C.13.3.2: Setup repository mirroring from GitHub
C.13.3.3: Configure access control (license-based)
C.13.3.4: Setup DNS for git.coditect.ai

Files:

opentofu/environments/dev/gitea.tf - Gitea infrastructure
opentofu/environments/dev/terraform.tfvars - Secret values (gitignored)
kubernetes/gitea/ - Gitea deployment manifests

Verification:

# Check Gitea secrets created
gcloud secrets list --filter="name:gitea"

# Check Gitea database user
gcloud sql users list --instance=coditect-citus-dev

# Test Gitea endpoint
curl https://git.coditect.ai/api/v1/version

Estimated Time: 16 hours Priority: P2 (Required for licensed container distribution) Depends On: C.1 (GKE cluster), A.2 (Cloud SQL) Blocked By: tofu apply failures (missing secret values)

C.14: Git Lock Cleanup Automation (NEW - Jan 25, 2026)

Repository: submodules/core/coditect-core/ Purpose: Eliminate recurring git index.lock issues in monorepo with 97 submodules Problem: Stale index.lock files from interrupted git operations block commits Agent: git-workflow-orchestrator or devops-engineer

Root Cause Analysis:

Parallel git operations across submodules create lock contention
Claude Code tool interruptions leave orphaned lock files
Nested submodules (.git/modules/) have separate lock files

Tasks:

C.14.1: Pre-Git Command Cleanup Hook

C.14.1.1: Create hooks/pre-git-cleanup.sh script
- Agent: Task(subagent_type="devops-engineer", prompt="Create pre-git cleanup hook that finds and removes stale index.lock files older than 60 seconds in monorepo")
- Logic: Only remove locks older than threshold (avoid race conditions)
- Scope: Main repo + all .git/modules/ directories
C.14.1.2: Add cleanup to Claude Code PreToolUse:Bash hook
- Agent: Task(subagent_type="devops-engineer", prompt="Add git lock cleanup to task_id_validator.py PreToolUse hook when command contains 'git'")
- Hook: hooks/task_id_validator.py

C.14.2: Git Wrapper Script

C.14.2.1: Create scripts/safe-git.sh wrapper
- Agent: Task(subagent_type="devops-engineer", prompt="Create safe-git.sh wrapper that cleans locks before and handles errors after git operations")
- Features:
  - Pre-command lock cleanup
  - Automatic retry on lock failure
  - Proper error propagation
C.14.2.2: Add alias to shell profile installation
- Agent: Task(subagent_type="devops-engineer", prompt="Add 'alias git=safe-git.sh' to CODITECT shell profile setup")

C.14.3: Submodule Lock Management

C.14.3.1: Create recursive lock finder
- Agent: Task(subagent_type="devops-engineer", prompt="Create find-git-locks.py script that recursively finds all index.lock files in repo and submodules")
C.14.3.2: Add lock cleanup to sync-all-submodules.sh
- Agent: Task(subagent_type="devops-engineer", prompt="Add lock cleanup step to sync-all-submodules.sh before git operations")

Verification:

# Test lock detection
find /Users/halcasteel/PROJECTS/coditect-rollout-master -name "index.lock" -type f

# Test cleanup hook
python3 ~/.coditect/hooks/task_id_validator.py --test-lock-cleanup

# Test safe-git wrapper
~/.coditect/scripts/safe-git.sh status

Estimated Time: 4 hours Priority: P1 (Recurring issue blocking commits) Depends On: None (can start immediately)

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) ✅ (14 tests, 296 lines)
- File: coditect-cloud-infra/backend/tests/security/test_rate_limit.py
E.2.2: Failed login lockout test (5 attempts → lock) ✅ (11 tests, 316 lines)
- File: coditect-cloud-infra/backend/tests/security/test_login_protection.py
E.2.3: Security headers present in all responses ✅ (24 tests, 262 lines)
- File: coditect-cloud-infra/backend/tests/security/test_security_headers.py
E.2.4: Audit logs capturing all events ✅ (21 tests, 352 lines)
- File: coditect-cloud-infra/backend/tests/security/test_audit_log.py
E.2.5: Input validation boundary testing ✅ (21 tests, 399 lines)
- File: coditect-cloud-infra/backend/tests/security/test_input_validation.py

Status: ✅ VERIFIED (Jan 11, 2026) | Total: 91 tests, 1,860 lines | Repository: coditect-cloud-infra

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~~ DEPRECATED ✅ (Jan 7, 2026)
- Verified: Rust CLI help text accurate (init, start, doctor, version, config)
- Note: Rust CLI deprecated Jan 2026 - see F.9 Architecture Deprecation

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 support@coditect.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 - support@coditect.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: support@coditect.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: ✅ COMPLETE (January 11, 2026) 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.

Files Created:

hooks/skill-preflight-validator.py - Pre-execution validation hook
hooks/antipattern-detector.py - Real-time anti-pattern detection
scripts/skill-mentor.py - Skill mentorship system
docs/guides/SKILL-MENTORSHIP-GUIDE.md - Best practices guide

F.5.7.1: Pre-Execution Validation

Output: hooks/skill-preflight-validator.py

F.5.7.1.1: Create pre-flight validation hook ✅ (Jan 11, 2026)
- 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 ✅ (Jan 11, 2026)
- 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 ✅ (Jan 11, 2026)
- 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 ✅ (Jan 11, 2026)
- 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 ✅ (Jan 11, 2026)
- 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 ✅ (Jan 11, 2026)
- 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 ✅ (Jan 11, 2026)
- 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 ✅ (Jan 11, 2026)
- 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 ✅ (Jan 11, 2026)
- 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 ✅ Jan 11
- 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
- File: docs/workflows/WF-112-subscription-downgrade.md
F.7.13.2: Create WF-112 Mermaid sequence diagram ✅ Jan 11 (embedded in WF-112)
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 ✅ Jan 11
- 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
- File: docs/workflows/WF-113-auditor-access-revocation.md
F.7.14.2: Create WF-113 Mermaid sequence diagram ✅ Jan 11 (embedded in WF-113)
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 ✅ Jan 11
- 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
- File: docs/workflows/WF-114-multi-opunit-access-assignment.md
F.7.15.2: Create WF-114 Mermaid sequence diagram ✅ Jan 11 (embedded in WF-114)
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 ✅ Jan 11
- 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
- File: docs/workflows/WF-115-team-deletion-archival.md
F.7.16.2: Create WF-115 Mermaid sequence diagram ✅ Jan 11 (embedded in WF-115)
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 ✅ Jan 11
- 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
- File: docs/workflows/WF-116-bulk-user-import.md
F.7.17.2: Create WF-116 Mermaid sequence diagram ✅ Jan 11 (embedded in WF-116)
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 ✅ Jan 11
- 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
- File: docs/workflows/WF-117-account-recovery.md
F.7.18.2: Create WF-117 Mermaid sequence diagram ✅ Jan 11 (embedded in WF-117)
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 ✅ Jan 11
- 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
- File: docs/workflows/WF-118-billing-dispute-resolution.md
F.7.19.2: Create WF-118 Mermaid sequence diagram ✅ Jan 11 (embedded in WF-118)
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 (app.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 app.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.1.9: Mermaid Diagrams with CODITECT Branding ✅ COMPLETE

Status: ✅ COMPLETE (Jan 9, 2026) Priority: P0 Estimated Time: 2-4 hours Goal: Enable native mermaid diagram rendering with CODITECT Design System branding

Agent Invocation:

Task(subagent_type="codi-documentation-writer", prompt="Configure Docusaurus mermaid rendering with CODITECT branding colors from ADR-002. Primary: #0ea5e9, Secondary: #e0f2fe, Line: #64748b.")

Tasks:

F.8.1.9.1: Install @docusaurus/theme-mermaid
F.8.1.9.2: Configure markdown.mermaid: true in docusaurus.config.ts
F.8.1.9.3: Add CODITECT theme variables to mermaid config
- Primary: #0ea5e9 (sky-500), Border: #0284c7 (sky-600)
- Secondary: #e0f2fe (sky-100), Tertiary: #f0f9ff (sky-50)
- Notes: #fef3c7/#f59e0b (warning yellow)
F.8.1.9.4: Create mermaid-config.json for standalone use
F.8.1.9.5: Create scripts/mermaid-to-png.py for optional PNG conversion
F.8.1.9.6: Build and deploy v1.4.0-mermaid to Cloud Run
F.8.1.9.7: Verify 426 mermaid diagrams render with CODITECT branding

Completion: 426 diagrams across 109 files now render with CODITECT branding.

F.8.1.10: n8n Workflow Visualizations 🆕

Status: 🟡 IN PROGRESS Priority: P1 Estimated Time: 8-12 hours Goal: Transform 1,149 n8n workflow JSONs into documented pages with mermaid visualizations and narratives

Agent Invocation:

Task(subagent_type="codi-documentation-writer", prompt="Create workflow documentation generator: Parse n8n JSON workflows, generate mermaid flowcharts, create step-by-step narratives with agent assignments. Transform all 1,149 workflows to docs.coditect.ai/reference/workflows/")

Inventory (1,149 workflows):

Category	Count	Description
industry	496	Legal (50+), Education, Healthcare, Finance
operations	100	Operational workflows
creative	100	Creative workflows
devops	55	CI/CD, deployment, infrastructure
developer-experience	55	Project lifecycle, testing, documentation
research	51	Intelligence gathering, market analysis
professional	50	Professional services
personal	50	Personal productivity
finance	50	Financial workflows
community	50	Community management
business	50	Business operations
Other (9 categories)	47	Security, QA, innovation, collaboration

Tasks:

F.8.1.10.1: Analysis & Design

F.8.1.10.1.1: Inventory all workflow JSON files (1,149 found)
F.8.1.10.1.2: Analyze n8n JSON structure (nodes, connections, _coditect metadata)
F.8.1.10.1.3: Design output markdown format with mermaid + narrative

F.8.1.10.2: Transform Script

F.8.1.10.2.1: Create scripts/workflow-to-docs.py - Main transformer
F.8.1.10.2.2: Implement n8n JSON parser (extract nodes, connections, metadata)
F.8.1.10.2.3: Implement mermaid flowchart generator from nodes/connections
F.8.1.10.2.4: Implement narrative generator from step notes and _coditect
F.8.1.10.2.5: Implement YAML frontmatter generator (title, tags, sidebar)
F.8.1.10.2.6: Add category index page generator

F.8.1.10.3: Batch Transform

F.8.1.10.3.1: Transform developer-experience workflows (55)
F.8.1.10.3.2: Transform devops workflows (55)
F.8.1.10.3.3: Transform research workflows (51)
F.8.1.10.3.4: Transform industry workflows (496)
F.8.1.10.3.5: Transform operations workflows (100)
F.8.1.10.3.6: Transform creative workflows (100)
F.8.1.10.3.7: Transform remaining workflows (292)
F.8.1.10.3.8: Generate 15 category index pages

F.8.1.10.4: Integration & Deploy

F.8.1.10.4.1: Update sidebars.ts with workflow categories
F.8.1.10.4.2: Update navbar Reference dropdown with workflow count
F.8.1.10.4.3: Build and test locally (npm run build)
F.8.1.10.4.4: Deploy v1.5.0-workflows to Cloud Run
F.8.1.10.4.5: Verify all 1,149 workflow pages accessible

F.8.1.15: Docs Site Deployment & Fixes (Jan 10, 2026) ✅ COMPLETE

Status: ✅ COMPLETE Priority: P0 - Production Deployment Goal: Deploy docs-site with all fixes for broken links, ADR titles, and Cloud Build pipeline

F.8.1.15.1: Cloud Build Pipeline Fixes

F.8.1.15.1.1: Fix cloudbuild.yaml push-before-deploy (images section runs after all steps)
F.8.1.15.1.2: Add explicit docker push steps before gcloud run deploy
F.8.1.15.1.3: Grant IAM roles/run.admin to Cloud Build service account
F.8.1.15.1.4: Grant IAM roles/iam.serviceAccountUser for actAs permission

F.8.1.15.2: Broken Link Fixes

F.8.1.15.2.1: Fix workflow links (/docs/workflows/ → /workflows/)
F.8.1.15.2.2: Fix empty anchor links (##) in 5 index files
F.8.1.15.2.3: Create scripts/fix-broken-anchors.py for automated anchor fixing
F.8.1.15.2.4: Fix 37 broken anchor links across documentation
F.8.1.15.2.5: Update app.coditect.ai → auth.coditect.ai (76 references)

F.8.1.15.3: ADR Title Fixes

F.8.1.15.3.1: Fix ADR-054 frontmatter (title: Untitled → ADR-054: Hierarchical Track Nomenclature)
F.8.1.15.3.2: Fix ADR-056 frontmatter (title: Untitled → ADR-056: Action-Level Task Tracking)
F.8.1.15.3.3: Fix ADR index.md with proper titles for ADR-054 and ADR-056

F.8.1.15.4: Deployments

F.8.1.15.4.1: Deploy v1.6.0-extractor-fix (datetime deprecation fix)
F.8.1.15.4.2: Deploy v1.7.0-link-fixes (broken anchor fixes)
F.8.1.15.4.3: Deploy v1.9.0-adr-titles (ADR frontmatter fixes)
F.8.1.15.4.4: Deploy v1.9.1-adr-index-fix (ADR index.md fixes)
F.8.1.15.4.5: Verify all ADRs display correct titles at docs.coditect.ai

Output Format (per workflow):

---
title: Continuous Integration Workflow
sidebar_label: Continuous Integration
tags: [ci, automation, testing, pipeline]
---

# Continuous Integration Workflow

**Category:** Developer Experience | **Complexity:** Moderate | **Duration:** 15-30m

## Overview
Set up or update CI pipeline for automated testing and validation.

## Workflow Diagram
[mermaid flowchart with CODITECT branding]

## Steps
### Step 1: Pipeline Design
**Agent:** devops-engineer
Define CI stages and jobs for the pipeline.
[... remaining steps ...]

Estimated Time: 8-12 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

F.9: Architecture Deprecation (Rust CLI → Cloud Workstation) 🆕

Status: 🆕 NEW - P1 (Jan 11, 2026) Goal: Deprecate Rust CLI and Theia IDE references, update documentation to reflect Google Cloud Workstation architecture Decision: CODITECT IDE = Google Cloud Workstation (not custom Theia on GKE, not Rust CLI)

Architecture Change Summary:

Component	OLD (Deprecated)	NEW (Current)
IDE	Custom Theia on GKE	Google Cloud Workstation
CLI	Rust `codi` binary	N/A (Cloud-native)
Container Orchestration	Custom GKE pods	GCP Workstation API
Terminal	Rust terminal integration	Cloud Workstation terminal

Files Requiring Deprecation/Update (61 files identified):

Category 1: ADRs to Mark Deprecated (19 files)

coditect-cloud-ide/docs/08-v4-reference/adrs/ADR-016-v4-codi-rust-implementation-* (2 files)
coditect-cloud-ide/docs/99-archive/ (already archived)
coditect-labs-v4-archive/docs/architecture/adrs/ADR-016-* (archive)

Category 2: docs.coditect.ai Updates (50+ files)

docs-site/docs/reference/skills/rust-backend-patterns.md
docs-site/docs/reference/commands/rust-scaffold.md
docs-site/docs/reference/agents/rust-expert-developer.md
docs-site/docs/internal/project/pilot-parallel-execution-plan.md
docs-site/docs/internal/project/codiflow-implementation-plan.md
docs-site/docs/guides/coditect-cookbook.md
Multiple standard files referencing Rust CLI

Category 3: PILOT Plan Updates (This File)

F.1.4: Remove "Rust CLI help text" reference
Update all references to "codi CLI" or "Rust CLI"

Category 4: Theia IDE References (15+ files)

coditect-cloud-ide/theia-ide/ (entire directory - archive or deprecate)
docs-site/docs/internal/project/repo-naming-convention.md
docs-site/docs/reference/skills/multi-agent-workflow.md

F.9.1: Create Architecture Change ADR

F.9.1.1: Create ADR-064 documenting Theia → Cloud Workstation migration decision
F.9.1.2: Add deprecation notices to ADR-016-v4-codi-rust-implementation-*
F.9.1.3: Update architecture diagrams to reflect Cloud Workstation

Agent Invocation:

/agent codi-documentation-writer "Create ADR-064 for architecture change: Theia IDE + Rust CLI deprecated in favor of Google Cloud Workstation. Document decision rationale, migration impact, and timeline."

F.9.2: Deprecate Rust CLI Documentation ✅ (Jan 11, 2026)

F.9.2.1: Add deprecation notice to rust-backend-patterns.md ✅
F.9.2.2: Add deprecation notice to rust-scaffold.md command ✅
F.9.2.3: Add deprecation notice to rust-expert-developer.md agent ✅
F.9.2.4: Update PILOT-PARALLEL-EXECUTION-PLAN.md F.1.4 (remove Rust CLI reference) ✅
F.9.2.5: ~~Update coditect-cookbook.md to remove Rust CLI examples~~ N/A (file not found)
F.9.2.6: Add deprecation notice to distribution/rust-cli/README.md ✅
F.9.2.7: Update distribution/rust-cli/CLAUDE.md status to deprecated ✅

Agent Invocation:

/agent codi-documentation-writer "Add deprecation notices to Rust CLI documentation: rust-backend-patterns.md, rust-scaffold.md, rust-expert-developer.md. Note: Rust CLI replaced by Google Cloud Workstation."

F.9.3: Update Theia IDE References ✅ (Jan 11, 2026)

F.9.3.1: ~~Archive theia-ide/ directory~~ N/A (directory does not exist)
F.9.3.2: Update repo-naming-convention.md (coditect-cloud-ide description) ✅
F.9.3.3: Update multi-agent-workflow.md Theia references ✅
F.9.3.4: Update remaining Theia references in skills/ ✅
- Updated: google-cloud-build, build-deploy-workflow, framework-patterns, task-complexity-analysis, deployment-archeology
- Archive files preserved as historical reference

Agent Invocation:

Task(subagent_type="codi-documentation-writer", prompt="Search docs-site/ for 'theia' or 'Theia' references and update to reflect Google Cloud Workstation architecture. Archive obsolete content.")

F.9.4: docs.coditect.ai Architecture Section Update ✅ (Jan 11, 2026)

F.9.4.1: Update C4 architecture diagrams for Cloud Workstation ✅
- Updated: internal/architecture/c4-diagrams/CODITECT-C4-ARCHITECTURE-EVOLUTION.md
- Phase 2 now documents Cloud Workstation architecture
- C2 Container diagram updated with GCP services
- C3 Component diagram updated for Cloud Workstation
F.9.4.2: Create Cloud Workstation integration guide ✅
- Created: docs/guides/CLOUD-WORKSTATION-INTEGRATION-GUIDE.md
- Covers: Architecture, APIs, configuration, troubleshooting
F.9.4.3: Update API documentation for Workstation Broker API ✅
- Included in integration guide: List, Create, Start/Stop, Delete endpoints
F.9.4.4: Update getting-started guides to reference Cloud Workstation ✅
- PILOT-GETTING-STARTED.md already references Cloud Workstation
- Integration guide linked from related documentation

Agent Invocation:

/agent software-design-architect "Update CODITECT architecture documentation for Google Cloud Workstation: (1) C4 diagrams; (2) integration patterns; (3) API reference for workstation provisioning"

F.9.5: ADR Consolidation for docs.coditect.ai

F.9.5.1: Create ADR sync script from coditect-core → docs-site
F.9.5.2: Establish ADR numbering convention to avoid conflicts
F.9.5.3: Document ADR consolidation workflow
F.9.5.4: Add ADR-063 (Email Infrastructure) to docs-site

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Create GitHub Action or script to sync ADRs from coditect-core/internal/architecture/adrs/ and coditect-cloud-infra/docs/architecture/adrs/ to docs-site/docs/architecture/adrs/ with conflict resolution")

Estimated Time:

F.9.1 (ADR): 2-4 hours
F.9.2 (Rust CLI): 4-6 hours
F.9.3 (Theia): 4-6 hours
F.9.4 (Architecture docs): 8-12 hours
F.9.5 (ADR sync): 4-6 hours
Total: 22-34 hours

F.10: ADR Glossary Compliance 🆕

Standard: CODITECT-STANDARD-ADR.md Section 6.3 Template: ADR-TEMPLATE.md Reference ADRs: ADRs 108-112 (already compliant with glossary sections)

Audit Summary (Jan 25, 2026):

124 ADRs audited
5 ADRs compliant (ADRs 108-112)
118 ADRs need glossary sections (95.2%)
Estimated effort: ~30 hours (15 min/ADR)

Compliance Criteria (Section 6.3.1):

3+ acronyms (even if defined inline) → REQUIRES glossary
Domain-specific technical terms → REQUIRES glossary
CODITECT-specific terminology (MoE, RLS, PILOT, etc.) → REQUIRES glossary

F.10.1: Phase 1 - Critical ADRs (90+ acronyms) 🔴 P0

Highest-impact ADRs requiring immediate glossary addition:

F.10.1.1: ADR-047-coditect-platform-foundation (381 acronyms)
F.10.1.2: ADR-009-multi-tenant-saas-architecture (114 acronyms)
F.10.1.3: ADR-012-data-isolation-strategy (108 acronyms)
F.10.1.4: ADR-005-work-item-hierarchy (102 acronyms)
F.10.1.5: ADR-100-unified-nomenclature-standard (102 acronyms)
F.10.1.6: ADR-024-multi-tenant-platform-architecture (96 acronyms)
F.10.1.7: ADR-010-cloud-workstations-architecture (92 acronyms)

Agent Invocation:

/agent codi-documentation-writer "Add glossary section to ADR-047-coditect-platform-foundation.md following CODITECT-STANDARD-ADR.md Section 6.3. Use ADR-112 as template. Include all acronyms (MoE, RLS, SSOT, etc.) and CODITECT-specific terms."

Estimated Time: 2-3 hours (7 ADRs × 15-20 min)

F.10.2: Phase 2 - High Priority ADRs (60-90 acronyms) 🟠 P1

F.10.2.1: ADR-015-auth-coditect-ai-website-architecture (90 acronyms)
F.10.2.2: ADR-021-multi-tenant-architecture-layers (85 acronyms)
F.10.2.3: ADR-034-service-mesh-architecture (82 acronyms)
F.10.2.4: ADR-103-four-database-separation-architecture (78 acronyms)
F.10.2.5: ADR-057-coditect-core-initial-setup (75 acronyms)
F.10.2.6: ADR-033-kubernetes-deployment-strategy (72 acronyms)
F.10.2.7: ADR-037-api-versioning-strategy (68 acronyms)
F.10.2.8: ADR-067-context-extraction-architecture (65 acronyms)

Agent Invocation:

/agent codi-documentation-writer "Add glossary sections to Phase 2 ADRs (015, 021, 034, 103, 057, 033, 037, 067) following Section 6.3 glossary requirements. Reference ADR-108-112 as templates."

Estimated Time: 2 hours (8 ADRs × 15 min)

F.10.3: Phase 3 - Medium Priority ADRs (40-60 acronyms) 🟡 P2

Agent Invocation:

Task(subagent_type="general-purpose", prompt="Add glossary sections to Phase 3 ADRs in internal/architecture/adrs/. Use ADR-112 as template. Batch process 15 ADRs following Section 6.3 requirements.")

Estimated Time: 4 hours (15 ADRs × 15 min)

F.10.4: Phase 4 - Remaining ADRs (<40 acronyms) 🟢 P3

88 remaining ADRs with lower acronym density. Process in batches:

F.10.4.1: Batch 1 - ADRs 001-019 (excluding already done)
F.10.4.2: Batch 2 - ADRs 020-039 (excluding already done)
F.10.4.3: Batch 3 - ADRs 040-059 (excluding already done)
F.10.4.4: Batch 4 - ADRs 060-079 (excluding already done)
F.10.4.5: Batch 5 - ADRs 080-099 (excluding already done)
F.10.4.6: Batch 6 - ADRs 100-124 (excluding 108-112)

Agent Invocation:

Task(subagent_type="general-purpose", prompt="Add glossary sections to Batch N ADRs (ADR-0XX to ADR-0XX) in internal/architecture/adrs/. Skip ADRs 108-112 (already compliant). Use ADR-110 as template for health/monitoring ADRs, ADR-111 for economics ADRs.")

Estimated Time: 22 hours (88 ADRs × 15 min)

F.10.5: Glossary Validation & Consistency

F.10.5.1: Create glossary-audit-report.md documenting compliance status
F.10.5.2: Add /moe-judges validation for glossary completeness
F.10.5.3: Update component-indexer.py to extract glossary terms
F.10.5.4: Create master-glossary.md consolidating all ADR terms
F.10.5.5: Add CI check for glossary presence in new ADRs

Agent Invocation:

/agent qa-reviewer "Validate glossary sections in all ADRs against CODITECT-STANDARD-ADR.md Section 6.3 requirements. Check for: (1) term completeness, (2) consistent formatting, (3) no undefined acronyms in body text."

Estimated Time: 4 hours

F.10.6: Documentation Inventory Update

Update documentation references to reflect new glossary sections:

F.10.6.1: Update docs/reference/COMPONENT-REFERENCE.md with ADR glossary status
F.10.6.2: Update docs/reference/database/DATABASE-SCHEMA.md glossary terms
F.10.6.3: Update internal/architecture/adrs/README.md with glossary requirements
F.10.6.4: Add glossary section links to ADR index page
F.10.6.5: Update CODITECT-STANDARD-ADR.md with compliance statistics
F.10.6.6: Regenerate component-counts.json with glossary metadata

Agent Invocation:

/agent codi-documentation-writer "Update documentation inventory files to reflect ADR glossary compliance work: (1) COMPONENT-REFERENCE.md, (2) ADR README.md, (3) component-counts.json. Add glossary status tracking."

Estimated Time: 2 hours

F.10.7: Publish to docs.coditect.ai

Sync updated ADRs with glossary sections to the public documentation site:

F.10.7.1: Run ADR sync script (coditect-core → docs-site)
F.10.7.2: Verify glossary sections render correctly in MkDocs
F.10.7.3: Update docs-site ADR navigation with glossary anchors
F.10.7.4: Run Cloud Build deployment pipeline
F.10.7.5: Verify deployment at https://docs.coditect.ai/architecture/adrs/
F.10.7.6: Update sitemap with new glossary term pages (if applicable)

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Deploy updated ADRs with glossary sections to docs.coditect.ai: (1) Sync ADRs from coditect-core to docs-site repo, (2) Trigger Cloud Build, (3) Verify deployment. Reference F.9.5 ADR sync workflow.")

Deployment Commands:

# Sync ADRs to docs-site
cd ~/PROJECTS/coditect-rollout-master/submodules/docs/docs-site
./scripts/sync-adrs.sh

# Trigger deployment
gcloud builds submit --config=cloudbuild.yaml --substitutions=_DEPLOY_ENV=prod

# Verify
curl -s https://docs.coditect.ai/architecture/adrs/ADR-112-ralph-wiggum-database-architecture/ | grep -q "Glossary" && echo "✓ Glossary visible"

Estimated Time: 2 hours

F.10.8: Common Terms Reference

Terms appearing across multiple ADRs (define consistently):

Term	Definition	ADRs Using
ADR	Architecture Decision Record - immutable document capturing decisions	All
MoE	Mixture of Experts - multi-model evaluation pattern	060, 074, 100+
PILOT	Project Intelligence Lab - execution framework with 7 tracks	054, 057, 100+
RLS	Row-Level Security - PostgreSQL tenant isolation	002, 089, 103, 108-112
SSOT	Single Source of Truth - canonical data source	054, 100+
ACID	Atomicity, Consistency, Isolation, Durability	002, 089, 108, 112
CX/CXQ	Context Extraction/Query - memory system	052, 053, 067
MCP	Model Context Protocol - Anthropic tool standard	109, 060
HITL	Human-in-the-Loop - approval workflows	060, 074

Total Estimated Time for F.10: 38 hours

Phases 1-4 (glossary additions): 30 hours
F.10.5 (validation): 4 hours
F.10.6 (inventory update): 2 hours
F.10.7 (docs.coditect.ai publish): 2 hours

F.11: Architectural Alignment Audit 🆕

Purpose: Ensure earlier ADRs, TDDs, and SDDs align with current architectural decisions and design state.

Context: As the CODITECT platform evolved, some earlier architectural documents contain outdated references (e.g., FoundationDB → PostgreSQL per ADR-002, Rust CLI → Cloud Workstation per F.9). This section ensures all documentation reflects the current accepted architecture.

Key Documents:

SDD: internal/architecture/SDD-CODITECT-MULTI-TENANT-SAAS.md (56KB)
TDD: internal/architecture/TDD-CODITECT-MULTI-TENANT-SAAS.md (61KB)
ADRs: internal/architecture/adrs/ (124 files)

F.11.1: ADR Alignment Audit 🔴 P0

Identify and flag ADRs with outdated architectural references:

F.11.1.1: Scan all ADRs for FoundationDB references → should be PostgreSQL (ADR-002)
F.11.1.2: Scan all ADRs for Rust CLI references → should be Cloud Workstation (F.9)
F.11.1.3: Scan all ADRs for Theia IDE references → should be Cloud Workstation
F.11.1.4: Identify ADRs referencing superseded ADRs without noting supersession
F.11.1.5: Create ADR-ALIGNMENT-AUDIT-REPORT.md with findings
F.11.1.6: Prioritize ADRs by impact (critical path, customer-facing, etc.)

Agent Invocation:

Task(subagent_type="Explore", prompt="Audit all ADRs in internal/architecture/adrs/ for outdated references: (1) FoundationDB (should be PostgreSQL per ADR-002), (2) Rust CLI (deprecated per F.9), (3) Theia IDE (deprecated), (4) superseded ADRs. Report findings with file paths and line numbers.")

Estimated Time: 4 hours

F.11.2: ADR Revision - Database Architecture 🔴 P0

Update ADRs with incorrect database references to align with ADR-002/ADR-089/ADR-112:

F.11.2.1: ADR-053 (Cloud Context Sync) - verify PostgreSQL alignment
F.11.2.2: ADR-052 (Intent-Aware Context) - verify two-database architecture
F.11.2.3: ADR-067 (Context Extraction) - update storage references
F.11.2.4: ADR-103 (Four-Database Separation) - reconcile with ADR-112
F.11.2.5: ADR-047 (Platform Foundation) - update database sections
F.11.2.6: Any ADRs referencing FoundationDB key structures
F.11.2.7: Add "Revised" status and revision notes to updated ADRs

Agent Invocation:

/agent senior-architect "Review and update database-related ADRs to align with ADR-002 (PostgreSQL), ADR-089 (Two-Database), and ADR-112 (Ralph Wiggum DB Architecture). Add revision notes documenting changes. Reference ADR-112 as the consolidation point."

Estimated Time: 8 hours

F.11.3: ADR Revision - Deployment Architecture 🟠 P1

Update ADRs with deprecated Rust CLI / Theia references per F.9 deprecation:

F.11.3.1: ADR-010 (Cloud Workstations) - update to current GCP Workstation architecture
F.11.3.2: ADR-057 (Initial Setup) - remove Rust CLI references
F.11.3.3: ADR-033 (Kubernetes Deployment) - align with current GKE config
F.11.3.4: ADR-034 (Service Mesh) - verify current Istio/Anthos alignment
F.11.3.5: Any ADRs referencing local CLI installation flow
F.11.3.6: Add deprecation notices to superseded deployment patterns

Agent Invocation:

/agent devops-engineer "Update deployment-related ADRs to reflect Cloud Workstation architecture (not Rust CLI). Reference F.9 deprecation decisions. Update ADR-010, ADR-057, ADR-033, ADR-034 as needed."

Estimated Time: 6 hours

F.11.4: ADR Revision - Authentication & Multi-Tenant 🟠 P1

Ensure auth and multi-tenant ADRs reflect current Supabase/PostgreSQL RLS architecture:

F.11.4.1: ADR-009 (Multi-Tenant SaaS) - verify RLS implementation details
F.11.4.2: ADR-012 (Data Isolation) - align with ADR-089 two-database model
F.11.4.3: ADR-015 (Auth Website Architecture) - verify Supabase Auth alignment
F.11.4.4: ADR-024 (Multi-Tenant Platform) - reconcile with ADR-009
F.11.4.5: ADR-021 (Multi-Tenant Layers) - update tenant isolation patterns
F.11.4.6: Verify consistent tenant_id / organization_id terminology

Agent Invocation:

/agent security-specialist "Audit and update authentication and multi-tenant ADRs for consistency with current Supabase Auth + PostgreSQL RLS architecture. Ensure ADR-009, ADR-012, ADR-015, ADR-024, ADR-021 are aligned."

Estimated Time: 6 hours

F.11.5: TDD Alignment 🟠 P1

Update Technical Design Document to align with current ADR decisions:

File: internal/architecture/TDD-CODITECT-MULTI-TENANT-SAAS.md

F.11.5.1: Update Section 3 (Data Models) - align with ADR-089, ADR-103, ADR-112
F.11.5.2: Update Section 4 (API Specifications) - align with current endpoints
F.11.5.3: Update Section 5 (Database Schema) - PostgreSQL + SQLite two-tier
F.11.5.4: Update Section 6 (Authentication) - Supabase Auth flow
F.11.5.5: Update Section 7 (Multi-Tenant) - RLS policies per ADR-009
F.11.5.6: Add ADR cross-references to each section
F.11.5.7: Update revision history with alignment changes

Agent Invocation:

/agent software-design-architect "Update TDD-CODITECT-MULTI-TENANT-SAAS.md to align with current ADR decisions: (1) ADR-002/089/112 for database, (2) ADR-009/012/024 for multi-tenant, (3) ADR-015 for auth. Add ADR cross-references."

Estimated Time: 8 hours

F.11.6: SDD Alignment 🟠 P1

Update Software Design Document to align with current ADR decisions:

File: internal/architecture/SDD-CODITECT-MULTI-TENANT-SAAS.md

F.11.6.1: Update C4 Context Diagram - current system boundaries
F.11.6.2: Update C4 Container Diagram - Cloud Workstation, not Rust CLI
F.11.6.3: Update C4 Component Diagram - current service architecture
F.11.6.4: Update Section 4 (Component Design) - align with current agents/skills
F.11.6.5: Update Section 5 (Integration Points) - current external services
F.11.6.6: Update Section 6 (Deployment View) - GKE + Cloud Workstation
F.11.6.7: Add ADR cross-references to each section
F.11.6.8: Update revision history with alignment changes

Agent Invocation:

/agent software-design-architect "Update SDD-CODITECT-MULTI-TENANT-SAAS.md C4 diagrams and component design to reflect current architecture: Cloud Workstation (not Rust CLI), PostgreSQL (not FoundationDB), current GKE deployment. Add ADR cross-references."

Estimated Time: 10 hours

F.11.7: Cross-Reference Validation 🟡 P2

Ensure bidirectional references between ADRs, TDD, and SDD are consistent:

F.11.7.1: Validate all ADR related_adrs frontmatter references
F.11.7.2: Validate all ADR supersedes references point to valid ADRs
F.11.7.3: Validate TDD references to ADRs are accurate
F.11.7.4: Validate SDD references to ADRs are accurate
F.11.7.5: Create cross-reference matrix (ADR ↔ TDD ↔ SDD)
F.11.7.6: Add missing bidirectional references

Agent Invocation:

/agent qa-reviewer "Validate cross-references between ADRs, TDD, and SDD. Check: (1) related_adrs frontmatter accuracy, (2) supersedes chains, (3) TDD→ADR references, (4) SDD→ADR references. Report broken or missing links."

Estimated Time: 4 hours

F.11.8: ADR Status Reconciliation 🟡 P2

Ensure ADR statuses accurately reflect current state:

F.11.8.1: Identify ADRs with status "proposed" that are actually implemented
F.11.8.2: Identify ADRs with status "accepted" that have been superseded
F.11.8.3: Update statuses: proposed → accepted → deprecated → superseded
F.11.8.4: Add supersession notes to deprecated ADRs
F.11.8.5: Create ADR-STATUS-RECONCILIATION-REPORT.md

ADR Status Definitions:

Status	Meaning
`proposed`	Under discussion, not yet implemented
`accepted`	Approved and implemented
`deprecated`	No longer recommended, replacement available
`superseded`	Replaced by newer ADR (reference in `supersedes`)
`rejected`	Considered but not adopted

Agent Invocation:

Task(subagent_type="general-purpose", prompt="Reconcile ADR statuses in internal/architecture/adrs/. Update 'proposed' to 'accepted' for implemented decisions. Mark superseded ADRs. Create status reconciliation report.")

Estimated Time: 4 hours

F.11.9: Publish Aligned Documentation 🟢 P3

Deploy updated TDD, SDD, and revised ADRs to docs.coditect.ai:

F.11.9.1: Sync revised ADRs to docs-site repository
F.11.9.2: Sync updated TDD to docs-site
F.11.9.3: Sync updated SDD to docs-site
F.11.9.4: Verify C4 diagrams render correctly
F.11.9.5: Run Cloud Build deployment
F.11.9.6: Verify at https://docs.coditect.ai/architecture/

Agent Invocation:

Task(subagent_type="devops-engineer", prompt="Deploy aligned architecture documentation to docs.coditect.ai: (1) Revised ADRs, (2) Updated TDD, (3) Updated SDD. Verify C4 diagrams and cross-references render correctly.")

Estimated Time: 2 hours

Total Estimated Time for F.11: 52 hours

F.11.1 (ADR audit): 4 hours
F.11.2 (Database ADRs): 8 hours
F.11.3 (Deployment ADRs): 6 hours
F.11.4 (Auth/Multi-tenant ADRs): 6 hours
F.11.5 (TDD alignment): 8 hours
F.11.6 (SDD alignment): 10 hours
F.11.7 (Cross-reference validation): 4 hours
F.11.8 (Status reconciliation): 4 hours
F.11.9 (Publish): 2 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: ~77% Complete (100/130 tasks) - Updated Jan 28, 2026 (H.8.5.4, H.8.8 added) Recent: H.8.5.4 Cloud Sync COMPLETE (Jan 28), H.8.8 Business Templates (21 tasks) added ADRs: H.8 implements ADRs 108-112 (Checkpoint, Browser, Health, Token, DB Architecture)

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)")

H.3.8: Provider Flexibility - Single to Multi-Provider Modes (CREATE)

Goal: Support customers with 1, 2, or 3+ LLM providers with graceful degradation Status: 100% Complete (8/8 tasks) - All tasks completed Jan 16, 2026 ADR: ADR-073-moe-provider-flexibility.md

H.3.8.1: Create ADR-073-moe-provider-flexibility.md - 4h ✅ Completed Jan 16, 2026
- Documented provider modes (single/dual/multi), confidence adjustments, model tier diversity
- Commit: 775b8560
H.3.8.2: Implement ProviderDetector class - 8h ✅ Completed Jan 16, 2026
- Created scripts/moe_classifier/core/provider_detector.py with auto-detection from API keys
- Supports ANTHROPIC, OPENAI, DEEPSEEK, GOOGLE, ALIBABA, META providers
- 23 unit tests passing
- Commit: ac3b8081
H.3.8.3: Integrate ProviderDetector with PersonaLoader - 4h ✅ Completed Jan 16, 2026
- Added provider_aware parameter to get_model_for_persona()
- Added adjust_confidence_for_provider_mode() method
- 19 integration tests passing
- Commit: 54fd539b
H.3.8.4: Integrate ProviderDetector with MoEOrchestrator - 4h ✅ Completed Jan 16, 2026
- Updated OrchestratorConfig with provider settings
- Added confidence adjustment to classify() method
- Added provider fields to ConsensusResult
- 15 integration tests passing
- Commit: 0a512d60
H.3.8.5: Integrate ProviderDetector with MultiModelClient - 4h ✅ Completed Jan 16, 2026
- Updated MODEL_PROVIDERS with Jan 2026 models (o3, gpt-4.1, claude-sonnet-4-5, etc.)
- Added get_model_for_persona() method
- Added provider mode properties and refresh method
- 22 integration tests passing
- Commit: e1503ba0
H.3.8.6: Update ADR-073 status to implemented - 1h ✅ Completed Jan 16, 2026
- Changed status from "accepted" to "implemented"
- Added implementation commits and test coverage summary
- Commit: 7e61a747
H.3.8.7: Create MOE-PROVIDER-CONFIGURATION-GUIDE.md - 4h ✅ Completed Jan 16, 2026
- Customer guide for configuring provider modes
- Covers single/dual/multi modes, environment variables, best practices
- Commit: ba74437a
H.3.8.8: Run full integration test suite - 2h ✅ Completed Jan 16, 2026
- All 79 provider detection tests passing
- Tested classification with all three modes
- Verified confidence adjustments: single=-10%, dual=-5%, multi=0%

H.3.8 Summary:

Total Tests: 79 (23 + 19 + 15 + 22)
Confidence Adjustments: Single=-10%, Dual=-5%, Multi=0%
Diversity Strategies: model_tier_diversity, provider_alternation, full_diversity
Models Supported: Jan 2026 (claude-sonnet-4-5, o3, gpt-4.1, deepseek-v3.2, llama-4-maverick, gemini-3-pro)

Total Estimated Time: ~180h + 31h = ~211h

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

H.5: Codanna Code Intelligence Integration (ADR-065, ADR-103) ✅

Source: ADR-065-codanna-code-intelligence-integration.md, ADR-103-four-database-separation-architecture.md Goal: Integrate codanna semantic code search, call graph analysis, and four-database architecture via MCP protocol Status: ✅ ~98% Complete (H.5.1-H.5.7 COMPLETE, H.5.5.3-H.5.5.5 remaining) MoE Council Verdict: INTEGRATE (Score: 80/100, Confidence: 81%)

Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement Track H.5 Codanna Integration per ADR-065: (1) fork to coditect-ai org; (2) create MCP wrapper; (3) implement P0 security; (4) create /code-index and /code-search commands")

H.5.1: ADR-065 Creation and MoE Council Evaluation ✅

H.5.1.1: Create ADR-065 for codanna integration - 4h ✅ Completed Jan 11, 2026
H.5.1.2: Assemble 6-agent MoE Council panel - 2h ✅ Completed Jan 11, 2026
H.5.1.3: Fork codanna to coditect-ai org - 1h ✅ Completed Jan 11, 2026
H.5.1.4: Create integration analysis documents - 4h ✅ Completed Jan 11, 2026
- CODANNA-INTEGRATION-ANALYSIS.md
- SECURITY-ASSESSMENT.md

Commits: ec270b2a feat(codanna): Fork to coditect-ai org and add ADR-065

H.5.2: Code Intelligence Integration Phase 1 ✅

H.5.2.1: Create /code-index command - 2h ✅ Completed Jan 11, 2026
H.5.2.2: Create /code-search command - 2h ✅ Completed Jan 11, 2026
H.5.2.3: Create codanna-mcp-wrapper.py script - 4h ✅ Completed Jan 11, 2026
H.5.2.4: Create MCP wrapper unit tests - 2h ✅ Completed Jan 11, 2026
H.5.2.5: Create config/codanna.template.json - 1h ✅ Completed Jan 11, 2026
H.5.2.6: Create config/schemas/codanna-config.schema.json - 2h ✅ Completed Jan 11, 2026
H.5.2.7: Create config/templates/mcp-codanna.json - 1h ✅ Completed Jan 11, 2026

Commits: 8f6b49da feat(codanna): Add code intelligence integration Phase 1

H.5.3: P0 MCP Security Implementation ✅

H.5.3.1: Implement TOCTOU protection in codanna - 4h ✅ Completed Jan 11, 2026
H.5.3.2: Add symlink blocking for path traversal prevention - 2h ✅ Completed Jan 11, 2026
H.5.3.3: Create MCP security wrapper for multi-tenant - 4h ✅ Completed Jan 11, 2026
H.5.3.4: Add hmac/hex dependencies for tenant HMAC - 1h ✅ Completed Jan 11, 2026
H.5.3.5: Update SECURITY-ASSESSMENT with P0 status - 2h ✅ Completed Jan 11, 2026

Commits:

0bd1087 (codanna) security: Add TOCTOU protection and symlink blocking
76b7aed9 feat(security): Add P0 MCP security wrapper for multi-tenant support
ac8e4b38 docs(security): Update SECURITY-ASSESSMENT with P0 implementation status
43e2a94 (codanna) feat(security): Add hmac and hex dependencies

H.5.4: Security Vulnerability Remediation ✅

H.5.4.1: Review Dependabot alerts (30 vulnerabilities) - 0.5h ✅ Completed Jan 11, 2026
H.5.4.2: Analyze vulnerability source (examples/typescript/react/) - 0.5h ✅ Completed Jan 11, 2026
H.5.4.3: Remove vulnerable React example app - 0.5h ✅ Completed Jan 11, 2026
H.5.4.4: Verify Dependabot alerts resolved (30→0) - 0.5h ✅ Completed Jan 11, 2026

Commits:

ba1c59f (codanna) chore(examples): Remove vulnerable React example app
c22ec1a2 chore(codanna): Update submodule - remove vulnerable React example

Security Posture After:

Metric	Before	After
Dependabot Alerts	30 (2 critical)	0
npm Dependencies	50+	0
TOCTOU Protection	No	Yes
Symlink Blocking	No	Yes
Multi-tenant HMAC	No	Yes

H.5.5: Phase 2 - Enhanced MCP Tools (Code Intelligence) ✅ CRITICAL FOR COMPETITIVE PARITY

H.5.5.1: Implement semantic search via embeddings - 8h ✅ (MCP server, hybrid RRF search, 26 tests, 100% embedding coverage)
H.5.5.2: Add call graph navigation tools - 8h ✅ (Memory-linked call graph, tree-sitter AST, 22 tests, 5,590 functions indexed)
H.5.5.3: Create impact analysis MCP tool - 8h (Decision-aware impact analysis)
H.5.5.4: Add document RAG integration - 8h (Cross-session doc retrieval)
H.5.5.5: Performance benchmarking - 4h

H.5.5.2 Implementation Details (Completed Jan 17, 2026):

MCP Tool	Description
`index_file`	Index source file into call graph
`index_directory`	Batch index directory
`get_callers`	Find functions that call a given function
`get_callees`	Find functions called by a given function
`call_chain`	Find call paths between functions
`memory_linked_search`	CODITECT UNIQUE - call graph with memory context
`call_graph_stats`	Database statistics

Current Index Stats:

Functions: 5,590
Call Edges: 55,548
Files Indexed: 441

Competitive Position (Updated Jan 17, 2026):

╔═══════════════════════════════════════════════════════════════════════════╗
║                     CODITECT's True Moat                                  ║
╠═══════════════════════════════════════════════════════════════════════════╣
║  Competitors (Cursor, JetBrains, Code Pathfinder):                        ║
║    ✓ AST parsing           ← Table stakes                                 ║
║    ✓ Call graph            ← Table stakes                                 ║
║    ✗ Cross-session memory  ← Missing                                      ║
║    ✗ Decision awareness    ← Missing                                      ║
╠═══════════════════════════════════════════════════════════════════════════╣
║  CODITECT:                                                                ║
║    ✓ AST parsing           ← Now implemented (tree-sitter)                ║
║    ✓ Call graph            ← Now implemented (H.5.5.2)                    ║
║    ✓ Cross-session memory  ← Unique (memory_linked_search)                ║
║    ✓ Decision awareness    ← Unique (ADR integration)                     ║
╚═══════════════════════════════════════════════════════════════════════════╝

Files Created:

tools/mcp-call-graph/server.py - MCP server (700+ lines)
tools/mcp-call-graph/CLAUDE.md - Documentation
tests/tools/test_mcp_call_graph.py - 22 unit tests

Commits:

4a76063c (coditect-core) - feat(mcp): Add memory-linked call graph server - H.5.5.2
056e6a49 (coditect-core) - docs: Add Code Intelligence section - H.5.5.1/H.5.5.2

Total Estimated Time: ~60h (Phase 1: ~40h COMPLETE, Phase 2: ~20h remaining)

H.5.6: Impact Analysis MCP Tool (Decision-Aware)

Goal: Create MCP tool for decision-aware impact analysis before code changes Agent: /agent senior-architect "Create impact analysis MCP tool with ADR integration" Status: ✅ COMPLETE (Jan 23, 2026)

H.5.6.1: Implement analyze_impact tool - 4h ✅ Completed Jan 23, 2026
- Agent: Task(subagent_type="senior-architect", prompt="Create impact analysis MCP tool that combines call graph with decision awareness")
- Output: tools/mcp-impact-analysis/server.py
- Features: Blast radius calculation, ADR constraints, historical issues, risk scoring
H.5.6.2: Implement analyze_file_impact tool - 2h ✅ Completed Jan 23, 2026
- Aggregates impact for all functions in a file
- Used for file-level refactoring
H.5.6.3: Implement find_decisions tool - 2h ✅ Completed Jan 23, 2026
- Links code to ADRs and design decisions
- Essential for understanding "why" code is structured
H.5.6.4: Implement assess_risk tool - 2h ✅ Completed Jan 23, 2026
- Risk factors: blast radius, decision constraints, historical issues
- Returns: low, medium, high, critical

MCP Tool	Description
`analyze_impact`	Function impact with blast radius and ADR awareness
`analyze_file_impact`	Aggregate file-level impact analysis
`find_decisions`	Link code to architectural decisions
`assess_risk`	Calculate change risk score
`impact_stats`	System statistics

Files Created:

tools/mcp-impact-analysis/server.py - MCP server
.mcp.json - Updated with impact analysis server

Estimated Time: ~10h

H.5.7: Four-Database Separation Architecture (ADR-103) ✅ COMPLETE

Source: ADR-103-four-database-separation-architecture.md Goal: Separate CODITECT framework (platform + index) from customer data (context + project) Status: ✅ 100% COMPLETE (H.5.7.1-H.5.7.5 ALL COMPLETE - Jan 23, 2026) Created: January 23, 2026

Architecture Overview:

FOUR-DATABASE ARCHITECTURE

~/PROJECTS/.coditect-data/context-storage/
├── platform.db        (Component metadata - 2MB, read-only)
├── platform-index.db  (Component embeddings - 50MB, read-only)
├── context.db         (Sessions, messages, decisions - customer data)
└── projects.db        (Project code/docs + embeddings - unified)

Key Design Decisions:

Unified projects.db: Single database for ALL projects (not per-project .coditect/project.db)
Cloud Integration: Projects registered with CODITECT cloud for UUID assignment
Hash-Based Tracking: Content hash for incremental updates (no re-indexing unchanged files)
Search Boundaries: Clear separation between agentic (framework) and user (project) search

MoE Agent Invocation:

Task(subagent_type="database-architect", prompt="Implement ADR-103 Four-Database Architecture: (1) Create platform-index.db with hash tracking; (2) Create projects.db with cloud integration; (3) Update search coordinator")

H.5.7.1: platform-index.db Creation (Hash-Based Change Tracking) ✅ COMPLETE

Goal: Create platform-index.db with embeddings for framework components Status: ✅ COMPLETE (Jan 23, 2026) Agent: /agent database-architect "Create platform-index.db schema and hash tracking"

H.5.7.1.1: Create platform-index.db schema - 2h ✅ Completed Jan 23, 2026
- Tables: component_embeddings, component_hashes, embedding_models
- Indexes for efficient queries
H.5.7.1.2: Implement hash-based change tracking - 4h ✅ Completed Jan 23, 2026
- SHA256 content hash for each component file
- Skip re-embedding unchanged files
- Track last_indexed timestamp
H.5.7.1.3: Generate framework embeddings - 4h ✅ Completed Jan 23, 2026
- Model: all-MiniLM-L6-v2 (384 dimensions)
- Results: 1,018 framework components indexed
- Storage: ~50MB for embeddings
H.5.7.1.4: Update component indexer for dual-write - 2h ✅ Completed Jan 23, 2026
- Metadata → platform.db
- Embeddings → platform-index.db
- --target flag for selective indexing

Implementation Notes (Jan 23, 2026):

platform-index.db initialized with schema from ADR-103
1,018 framework components indexed with embeddings
Hash-based tracking enabled for incremental updates

Files Created/Updated:

scripts/platform-index-db.py - Database management
internal/architecture/adrs/ADR-103-four-database-separation-architecture.md
internal/architecture/adrs/ADR-045-* - Updated with ADR-103 integration note
internal/architecture/adrs/ADR-089-* - Updated with ADR-103 integration note
internal/architecture/adrs/ADR-102-* - Updated with ADR-103 integration note

Estimated Time: ~12h

H.5.7.2: projects.db Infrastructure (Unified Project Database)

Goal: Create unified projects.db for all project code/doc embeddings Status: ✅ COMPLETE (Jan 23, 2026) Agent: /agent database-architect "Create projects.db schema with cloud integration"

H.5.7.2.1: Create projects.db schema - 4h ✅ Completed Jan 23, 2026
- Tables: projects, content_hashes, project_embeddings
- Tables: global_exclude_patterns, project_exclude_patterns
- Cloud integration: project_uuid, tenant_id, team_id, owner_user_id
- GitHub integration: github_repo_url, github_org, github_repo_name
H.5.7.2.2: Implement project registration - 4h ✅ Completed Jan 23, 2026
- --register command for new projects
- --offline mode for local-only registration
- --parent for subproject hierarchy
H.5.7.2.3: Cloud API integration - 4h ✅ Completed Jan 23, 2026
- POST /api/v1/projects/register → returns project_uuid
- Offline mode: local UUID, sync_status='pending'
- --sync-pending to sync offline projects
H.5.7.2.4: Auto-detect project metadata - 2h ✅ Completed Jan 23, 2026
- Git remote → github_repo_url, github_org, github_repo_name
- Project root detection (git root or explicit)
- Project slug generation from path

Implementation Notes (Jan 23, 2026):

projects.db initialized and functional
248,159 project files indexed (coditect-rollout-master + submodules)
project_uuid used consistently for cloud integration
Parent/child relationships working for monorepo support

Files Created:

scripts/projects-db.py - Database management (~800 lines)

Estimated Time: ~14h

H.5.7.3: Project Indexing (Code + Docs)

Goal: Index project code and documents into projects.db Status: ✅ COMPLETE (Jan 23, 2026) Agent: /agent senior-architect "Implement project file indexing"

H.5.7.3.1: File discovery with exclude patterns - 2h ✅
- Global excludes: node_modules, pycache, .git, .env, etc.
- Per-project excludes configurable
H.5.7.3.2: Content type detection - 2h ✅
- Code: .py, .ts, .js, .go, .rs, .java, etc.
- Document: .md, .txt, .rst
- Config: .json, .yaml, .toml
- Test: *_test.py, *.spec.ts
H.5.7.3.3: Chunking strategies - 4h ✅ Completed Jan 23, 2026
- Content-type-aware chunking (code by functions, docs by sections)
- chunk_text_simple, chunk_code_by_functions, chunk_document_by_sections
- Configurable chunk_size (default 1000) and chunk_overlap (default 200)
H.5.7.3.4: Embedding generation - 4h ✅ Completed Jan 23, 2026
- Uses sentence-transformers all-MiniLM-L6-v2 (384 dimensions)
- Batch embedding generation for efficiency
- CLI: --embed PROJECT_UUID, --embed-all, --force-embed
H.5.7.3.5: Hash-based incremental updates - 2h ✅ Completed Jan 23, 2026
- cleanup_orphaned_records removes deleted files
- cleanup_stale_chunks handles chunk count changes
- CLI: --index-status shows what needs updating

Estimated Time: ~14h ✅ COMPLETE

H.5.7.4: Unified Search Coordinator ✅ COMPLETE

Goal: Implement search coordinator with scope flags Status: ✅ COMPLETE (Jan 23, 2026) Agent: /agent senior-architect "Create unified search coordinator"

H.5.7.4.1: Search scope determination - 4h ✅
- --framework → platform.db + platform-index.db
- --project → projects.db only
- --context → context.db only
- --all → All 4 databases
- (default) → context.db + current project
- File: scripts/unified-search.py (SearchScope dataclass)
H.5.7.4.2: Parallel search execution - 4h ✅
- ThreadPoolExecutor for concurrent queries
- Timeout handling per database
- File: scripts/unified-search.py (execute_parallel_search)
H.5.7.4.3: RRF result merging - 4h ✅
- Reciprocal Rank Fusion scoring
- Source grouping: [CONTEXT], [PROJECT], [FRAMEWORK]
- File: scripts/unified-search.py (merge_results_rrf, compute_rrf_score)
H.5.7.4.4: Update /cxq command - 4h ✅
- Add scope flags: --multi-db, --scope-framework, --scope-project, --scope-context
- Integrated search coordinator via subprocess
- Files: scripts/context-db.py, commands/cxq.md

Estimated Time: ~16h ✅ COMPLETE

H.5.7 Total Estimated Time: ~56h (H.5.7.1: 12h ✅, H.5.7.2: 14h ✅, H.5.7.3: 14h ✅, H.5.7.4: 16h ✅) - ALL COMPLETE

H.5.7.5: Install Script Four-Database Support ✅ COMPLETE

Source: ADR-103-four-database-separation-architecture.md Goal: Update CODITECT install script to initialize all 4 databases per ADR-103 Status: ✅ COMPLETE (January 23, 2026) Created: January 23, 2026

Completed State:

Install script v2.7.0 creates all 4 databases per ADR-103
GCS deployed: gs://coditect-dist/coditect-install.py
Automation components created for future maintenance
H.5.7.5.1: Add platform-index.db initialization - 2h ✅ Completed Jan 23, 2026
- Schema: component_embeddings, component_hashes, embedding_models
- Empty initialization (embeddings generated by /cx --reindex-framework)
- Commit: 909162f2
H.5.7.5.2: Add projects.db initialization - 2h ✅ Completed Jan 23, 2026
- Schema: projects, content_hashes, project_embeddings
- Schema: global_exclude_patterns, project_exclude_patterns
- 50+ default global excludes populated
- Commit: 909162f2
H.5.7.5.3: Update install script version to v2.7.0 - 1h ✅ Completed Jan 23, 2026
- Version: 2.6.0 → 2.7.0
- Steps: 14 → 16
- Commit: 909162f2
H.5.7.5.4: Upload updated script to GCS - 0.5h ✅ Completed Jan 23, 2026
- gs://coditect-dist/coditect-install.py (v2.7.0)
- Verified public access
H.5.7.5.5: Create maintenance automation components - 2h ✅ Completed Jan 23, 2026
- Agent: install-script-maintainer (haiku model)
- Skill: install-script-lifecycle (error→fix→deploy patterns)
- Workflow: install-script-deployment (7-phase workflow)
- Command: /install-maintain (aliases: /im, /install-fix)
- Hook: install-script-validator.py (validation on edit)
- Commit: 21d137d8

Commits:

909162f2 feat(install): Implement ADR-103 four-database architecture v2.7.0
21d137d8 feat(components): Add install script maintenance workflow automation

Automation Workflow:

/install-maintain "error report" → Analyze → Fix → Cross-check → Git → Deploy GCS

Actual Time: ~7.5h

H.5.8: Four-Database Setup Integration ✅ COMPLETE

Source: ADR-103-four-database-separation-architecture.md, PLAN-H.5.8-four-db-setup-integration.md Goal: Update setup script to auto-discover and register projects during installation Status: ✅ COMPLETE (January 23, 2026) Created: January 23, 2026

Problem Solved:

Setup script created database schemas but didn't register any projects
Customers/partners have different needs than internal contributors
Multi-project directories (e.g., ~/PROJECTS/) need interactive selection

Implementation:

Project discovery: Scans CWD for .git directories up to 2 levels deep
User type detection: Internal (coditect-* markers) vs customer projects
Interactive selection: Users choose which projects to register
Non-interactive mode: Skips registration (CI/automation friendly)
H.5.8.1: Add project discovery to setup script - 2h ✅ Completed Jan 23, 2026
- discover_projects() method scans for .git directories
- Smart directory skipping (node_modules, venv, etc.)
- User type detection (internal/customer)
H.5.8.2: Add interactive project selection - 2h ✅ Completed Jan 23, 2026
- prompt_project_selection() with numbered list
- Options: comma-separated numbers, 'all', 'skip'
- TTY detection for non-interactive environments
H.5.8.3: Auto-register selected projects - 2h ✅ Completed Jan 23, 2026
- register_projects() calls projects-db.py --register
- Offline mode for setup without cloud sync
- Shows next steps for indexing
H.5.8.4: Update post-setup instructions - 1h ✅ Completed Jan 23, 2026
- Clear messaging for registered vs skipped projects
- Index commands shown after registration
- Deferred embedding instructions

Files Modified:

scripts/CODITECT-CORE-INITIAL-SETUP.py - v2.8.0
- Added: discover_projects(), prompt_project_selection(), register_projects()
- Updated: initialize_projects_database() with discovery flow
- Updated: __init__ with non_interactive parameter

Actual Time: ~7h

H.6: RLM+Superpowers Framework Integration (ADR-074 to ADR-079)

Source: Analysis of submodules/rlm (alexzhang13/rlm) and submodules/superpowers (obra/superpowers) Goal: Integrate proven patterns from RLM and Superpowers to enhance CODITECT agent orchestration, governance, and debugging Status: ~90% Complete (~84/93 tasks) - Updated Jan 16, 2026 ADRs: ADR-074, ADR-075, ADR-076, ADR-077, ADR-078, ADR-079 Created: January 16, 2026 Key Completions: H.6.1 Governance Hooks (46 tests), H.6.2 Token Tracking (51 tests), H.6.3 Two-Stage Review (25 tests), H.6.4 Recursive Chains (44 tests), H.6.5 Context Isolation (29 tests), H.6.6 Trajectory System (79 tests, MoE 8.5/10)

MoE Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement Track H.6 RLM+Superpowers Integration per ADRs 074-079. Execute tasks atomically with TDD (tests first). Use /moe-judges for verification.")

H.6.1: SessionStart Governance Hook (ADR-074) - Priority: P0 ✅ COMPLETE

Goal: Implement mandatory skill checking at session start Agent: /agent coditect-adr-specialist "Implement ADR-074 SessionStart Governance Hook" Status: ✅ Core implementation complete (46 tests passing) - Jan 16, 2026

H.6.1.1: Governance Skill Creation

H.6.1.1.1: Create skills/coditect-governance/ directory structure
H.6.1.1.2: Write TDD tests for governance skill loading (tests/skills/test_coditect_governance.py)
H.6.1.1.3: Create skills/coditect-governance/SKILL.md with The Rule content
H.6.1.1.4: Add red flags rationalization table to SKILL.md
H.6.1.1.5: Add task ID protocol section to SKILL.md
H.6.1.1.6: Run tests, verify SKILL.md loads correctly

H.6.1.2: SessionStart Hook Implementation

H.6.1.2.1: Write TDD tests for session-start-governance hook (tests/hooks/test_session_start_governance.py)
H.6.1.2.2: Create hooks/session_start_governance.py hook script
H.6.1.2.3: Implement load_governance_skill() function
H.6.1.2.4: Implement main() with hookSpecificOutput injection
H.6.1.2.5: Run tests, verify hook outputs valid JSON (18 tests)
H.6.1.2.6: Add fallback content when SKILL.md missing

H.6.1.3: Task ID Validator Hook Implementation

H.6.1.3.1: Write TDD tests for task-id-validator hook (tests/hooks/test_task_id_validator.py)
H.6.1.3.2: Create hooks/task_id_validator.py PreToolUse hook
H.6.1.3.3: Implement TASK_ID_PATTERN regex validation
H.6.1.3.4: Implement validate_task_id() function
H.6.1.3.5: Run tests, verify validation patterns (28 tests)
H.6.1.3.6: Add hook registration to ~/.claude/settings.json

H.6.1.4: Integration and Documentation

H.6.1.4.1: Update config/component-counts.json with new skill
H.6.1.4.2: Update CLAUDE.md to reference governance hook
H.6.1.4.3: Create integration test scenario
H.6.1.4.4: Run MoE judges verification (/moe-judges ADR-074)

Estimated Time: ~16h

H.6.2: Token Usage Tracking System (ADR-075) - Priority: P1 ✅ COMPLETE

Goal: Implement unified token tracking across all LLM providers Agent: /agent senior-architect "Implement ADR-075 Token Usage Tracking" Status: ✅ Core implementation complete (51/51 tests passing) - Jan 16, 2026

H.6.2.1: Core Data Structures

H.6.2.1.1: Write TDD tests for ModelUsageSummary (tests/core/test_usage_tracking.py)
H.6.2.1.2: Write TDD tests for UsageSummary dataclass
H.6.2.1.3: Write TDD tests for UsageTracker singleton
H.6.2.1.4: Create scripts/core/usage_tracking.py module
H.6.2.1.5: Implement ModelUsageSummary dataclass
H.6.2.1.6: Implement UsageSummary with add_usage() and merge()
H.6.2.1.7: Implement thread-safe UsageTracker singleton
H.6.2.1.8: Run tests, verify thread safety

H.6.2.2: Cost Estimation

H.6.2.2.1: Write TDD tests for cost estimation (tests/core/test_cost_estimator.py)
H.6.2.2.2: Create scripts/core/cost_estimator.py module
H.6.2.2.3: Create config/model-pricing.json with January 2026 pricing
H.6.2.2.4: Implement estimate_cost() function
H.6.2.2.5: Run tests, verify cost calculations

H.6.2.3: Integration

H.6.2.3.1: Integrate UsageTracker into multi_model_client.py
H.6.2.3.2: Add usage metrics to /export output
H.6.2.3.3: Create /usage command documentation
H.6.2.3.4: Run MoE judges verification (/moe-judges ADR-075)

Estimated Time: ~12h

H.6.3: Two-Stage Review with MoE Integration (ADR-076) - Priority: P1 ✅ COMPLETE

Goal: Implement spec compliance → code quality review separation Agent: /agent coditect-adr-specialist "Implement ADR-076 Two-Stage Review" Status: ✅ Core implementation complete (25/25 tests passing) - Jan 16, 2026

H.6.3.1: Core Review System

H.6.3.2: Skill and Documentation

H.6.3.2.1: Create skills/two-stage-review/SKILL.md
H.6.3.2.2: Create config/review-judge-assignment.json
H.6.3.2.3: Update commands/moe-judges.md with two-stage mode
H.6.3.2.4: Run MoE judges verification (MoE 9.0/10 APPROVED) (/moe-judges ADR-076)

Estimated Time: ~14h

H.6.4: Recursive Agent Chain Architecture (ADR-077) - Priority: P2 ✅ COMPLETE

Goal: Enable agents to spawn sub-agents with llm_query() pattern Agent: /agent senior-architect "Implement ADR-077 Recursive Agent Chains" Status: ✅ Core implementation complete (44 tests) - Jan 16, 2026

H.6.4.1: Core Chain Implementation

H.6.4.2: Skill and Integration

H.6.4.2.1: Create skills/chunking-strategies/SKILL.md
H.6.4.2.2: Create config/agent-chain-config.json
H.6.4.2.3: Integrate with agent_dispatcher.py
H.6.4.2.4: Run MoE judges verification (MoE 9.2/10 APPROVED) (/moe-judges ADR-077)

Estimated Time: ~18h

H.6.5: Subagent Context Isolation Pattern (ADR-078) - Priority: P1 ✅ COMPLETE

Goal: Ensure subagents receive clean, task-specific context Agent: /agent senior-architect "Implement ADR-078 Context Isolation" Status: 13/14 tasks complete (Jan 16, 2026) - 29 tests passing Files: scripts/core/context_isolation.py, tests/core/test_context_isolation.py, skills/subagent-context-isolation/SKILL.md

H.6.5.1: Context Classes ✅ COMPLETE (Jan 16, 2026)

H.6.5.2: Skill and Integration

H.6.5.2.1: Create skills/subagent-context-isolation/SKILL.md
H.6.5.2.2: Update agents/controller.md reference
H.6.5.2.3: Integrate with agent_dispatcher.py
H.6.5.2.4: Run MoE judges verification (MoE 9.3/10 APPROVED) (/moe-judges ADR-078)

Estimated Time: ~14h

H.6.6: Trajectory Visualization System (ADR-079) - Priority: P2 - ✅ COMPLETE

Goal: Implement execution trace logging and visualization Agent: /agent senior-architect "Implement ADR-079 Trajectory Visualization" Status: 20/20 tasks complete (Jan 16, 2026) - 79 tests passing - Commits c9841d7d, 57e4a6ff, ee0aa1e5, d664edd6 Files: scripts/core/trajectory_logging.py, tests/core/test_trajectory_logging.py, commands/trajectory.md, tools/trajectory-visualizer/, hooks/trajectory_logger_hook.py MoE Score: 8.5/10 APPROVED - All 4 recommendations implemented (secret redaction, ADR status, file rotation, async writes)

H.6.6.1: Core Logging ✅ COMPLETE (Jan 16, 2026) - Commit `c9841d7d`

H.6.6.2: Visualizer ✅ COMPLETE (Jan 16, 2026)

H.6.6.2.1: Create tools/trajectory-visualizer/ directory
H.6.6.2.2: Setup Node.js + TypeScript + Vite + Tailwind project
H.6.6.2.3: Implement TrajectoryViewer component
H.6.6.2.4: Implement Timeline view
H.6.6.2.5: Implement CallGraph view
H.6.6.2.6: Implement DetailPanel component

H.6.6.3: Integration ✅ COMPLETE (Jan 16, 2026) - 79 tests

H.6.6.3.1: Integrate TrajectoryLogger into post-tool-use hook ✅ (hooks/trajectory_logger_hook.py, 35 tests)
H.6.6.3.2: Create /trajectory command
H.6.6.3.3: Reference in /cx output
H.6.6.3.4: Run MoE judges verification (/moe-judges ADR-079) ✅ Score: 8.5/10 APPROVED
- P1: Secret redaction for API keys/credentials ✅ (22 tests)
- P2: ADR-079 status updated to Accepted ✅
- P2: File rotation/cleanup policy ✅ (8 tests)
- P3: Async writes for high-volume scenarios ✅ (6 tests)

Estimated Time: ~20h

Track H.6 Total Estimated Time: ~94h (54 atomic tasks)

Track H.6 Dependencies:

H.6.2 (Token Tracking) required by H.6.4 (Recursive Chains)
H.6.5 (Context Isolation) enhances H.6.3 (Two-Stage Review)
H.6.6 (Trajectory) integrates with all other subsystems

H.7: Self-Validating Ecosystem (ADR-080 to ADR-082)

Source: MoE Analysis of agentic-finance-review integration (2026-01-20) Goal: Extend self-validating agent patterns from finance to entire CODITECT component ecosystem Status: 0% Complete (0/733 tasks) Created: January 20, 2026 Updated: January 20, 2026 (Expanded with full MoE inventory analysis) Pattern: Focused Agent + Specialized Validation = Trusted Automation

MoE Agent Invocation:

Task(subagent_type="senior-architect", prompt="Implement Track H.7 Self-Validating Ecosystem. Create validators, add hooks to agents/commands, and verify with /moe-judges.")

Complete Inventory Analysis (MoE 4-Agent Scan):

Component Type	Total	With Hooks	Need Hooks	Coverage
Agents	178	6	172	3.4%
Commands	238	9	34 (P0-P1)	3.8%
Scripts	432	0	100 (P0-P2)	0%
Skills	250	13	117 (high-risk)	5.2%
Workflows	15	0	15	0%
Validators Needed	-	6	63	-

Priority Distribution (Agents):

P0 Critical: 42 agents (DevOps, Security, Testing, Orchestration)
P1 High: 76 agents (Code Quality, Documentation, Design)
P2 Medium: 42 agents (Analysis, Research)
P3 Low: 18 agents (Web Research, External)

Implementation Phases:

Phase 1 (Weeks 1-2): P0 Validators + P0 Agents = 27% coverage
Phase 2 (Weeks 3-4): P1 Validators + P1 Agents = 70% coverage
Phase 3 (Weeks 5-8): P2-P3 Components = 100% coverage

H.7.1: Critical Validators - Phase 1 (P0) - ~24h

Goal: Create validators for production-critical file types Agent: /agent senior-architect "Create critical validators for H.7.1"

H.7.1.1: Shell Script Validator (CRITICAL - 1,881 scripts)

H.7.1.1.1: Write TDD tests for shellcheck-validator.py
H.7.1.1.2: Create hooks/validators/shellcheck-validator.py
H.7.1.1.3: Implement shellcheck discovery (brew, apt, path)
H.7.1.1.4: Implement JSON output with error location
H.7.1.1.5: Run tests, verify validation

H.7.1.2: JavaScript/TypeScript Validator (Frontend-critical)

H.7.1.2.1: Write TDD tests for eslint-validator.py
H.7.1.2.2: Create hooks/validators/eslint-validator.py
H.7.1.2.3: Implement ESLint discovery and execution
H.7.1.2.4: Support --fix mode for auto-correction
H.7.1.2.5: Run tests, verify validation

H.7.1.3: YAML Schema Validator (K8s, CloudBuild, CI/CD)

H.7.1.3.1: Write TDD tests for yaml-validator.py
H.7.1.3.2: Create hooks/validators/yaml-validator.py
H.7.1.3.3: Implement YAML syntax validation
H.7.1.3.4: Add schema validation support (optional)
H.7.1.3.5: Run tests, verify validation

H.7.1.4: Kubernetes Manifest Validator

H.7.1.4.1: Write TDD tests for kubernetes-validator.py
H.7.1.4.2: Create hooks/validators/kubernetes-validator.py
H.7.1.4.3: Implement kubectl --dry-run validation
H.7.1.4.4: Add kubeval schema validation
H.7.1.4.5: Run tests, verify validation

H.7.1.5: CloudBuild Config Validator

H.7.1.5.1: Write TDD tests for cloudbuild-validator.py
H.7.1.5.2: Create hooks/validators/cloudbuild-validator.py
H.7.1.5.3: Implement YAML + schema validation
H.7.1.5.4: Validate substitution variables
H.7.1.5.5: Run tests, verify validation

Estimated Time: ~24h

H.7.2: High-Priority Validators - Phase 2 (P1) - ~30h ✅ COMPLETE

Status: ✅ 100% Complete (30/30 tasks) - All 6 validators created with tests (Jan 20, 2026) Goal: Create validators for quality and governance Agent: /agent senior-architect "Create high-priority validators for H.7.2"

H.7.2.1: Markdown Structure Validator (1,072+ ADRs) ✅ COMPLETE

H.7.2.1.1: Write TDD tests for markdown-validator.py ✅ (Jan 20, 2026)
H.7.2.1.2: Create hooks/validators/markdown-validator.py ✅ (428 lines)
H.7.2.1.3: Implement frontmatter YAML validation ✅
H.7.2.1.4: Implement heading hierarchy validation ✅
H.7.2.1.5: Implement link validation ✅
H.7.2.1.6: Run tests, verify validation ✅

H.7.2.2: Rust Cargo Validator (77 Rust projects) ✅ COMPLETE

H.7.2.2.1: Write TDD tests for rust-validator.py ✅ (Jan 20, 2026)
H.7.2.2.2: Create hooks/validators/rust-validator.py ✅ (396 lines)
H.7.2.2.3: Implement cargo check validation ✅
H.7.2.2.4: Implement cargo clippy validation ✅
H.7.2.2.5: Run tests, verify validation ✅

H.7.2.3: ADR Compliance Validator ✅ COMPLETE

H.7.2.3.1: Write TDD tests for adr-validator.py ✅ (Jan 20, 2026)
H.7.2.3.2: Create hooks/validators/adr-validator.py ✅ (382 lines)
H.7.2.3.3: Validate ADR frontmatter (status, date) ✅
H.7.2.3.4: Validate required sections (Context, Decision, Consequences) ✅
H.7.2.3.5: Run tests, verify validation ✅ (38 tests pass)

H.7.2.4: JSON Schema Validator ✅ COMPLETE

H.7.2.4.1: Write TDD tests for json-schema-validator.py ✅ (Jan 20, 2026)
H.7.2.4.2: Create hooks/validators/json-schema-validator.py ✅ (385 lines)
H.7.2.4.3: Implement JSON syntax validation ✅
H.7.2.4.4: Add JSON Schema support (optional) ✅
H.7.2.4.5: Run tests, verify validation ✅ (38 tests pass)

H.7.2.5: API Response Validator ✅ COMPLETE

H.7.2.5.1: Write TDD tests for api-validator.py ✅ (Jan 20, 2026)
H.7.2.5.2: Create hooks/validators/api-validator.py ✅ (402 lines)
H.7.2.5.3: Validate against OpenAPI specs ✅
H.7.2.5.4: Check response status codes ✅
H.7.2.5.5: Run tests, verify validation ✅ (38 tests pass)

H.7.2.6: Database Migration Validator ✅ COMPLETE

H.7.2.6.1: Write TDD tests for migration-validator.py ✅ (Jan 20, 2026)
H.7.2.6.2: Create hooks/validators/migration-validator.py ✅ (368 lines)
H.7.2.6.3: Check for reversibility ✅
H.7.2.6.4: Detect dangerous operations (DROP TABLE) ✅
H.7.2.6.5: Run tests, verify validation ✅ (38 tests pass)

Estimated Time: ~30h

H.7.3: P0 Critical Agent Hooks (42 agents) - ~84h - 100% Complete ✅

Status: ✅ 100% Complete (42/42 agents) - Jan 21, 2026 Goal: Add self-validation hooks to P0 critical agents Note: 11 planned agents marked N/A - covered by existing agents with equivalent hooks Agent: /agent component-enhancer "Add self-validation hooks to P0 agents"

H.7.3.1: DevOps/Infrastructure Agents (12 agents) - 100% Complete ✅

H.7.3.2: Security Agents (12 agents) - 100% Complete ✅

H.7.3.3: Testing/QA Agents (9 agents) - 100% Complete ✅

H.7.3.3.1: Add hooks to testing-specialist.md (python-ruff-validator, tdd-validator) ✅
H.7.3.3.2: Add hooks to codi-test-engineer.md (python-ruff-validator, eslint-validator) ✅
H.7.3.3.3: Add hooks to qa-reviewer.md (markdown-validator, adr-validator) ✅
H.7.3.3.4: Add hooks to unit-testing.md (python-ruff-validator, tdd-validator) ✅
H.7.3.3.5: ~~integration-testing.md~~ N/A - covered by testing-specialist.md (has tdd-validator) ✅
H.7.3.3.6: Add hooks to codi-qa-specialist.md (python-ruff-validator, eslint-validator) ✅
H.7.3.3.7: Add hooks to component-qa-reviewer.md (markdown-validator, yaml-validator) ✅
H.7.3.3.8: Add hooks to component-qa-validator.md (yaml-validator, markdown-validator) ✅
H.7.3.3.9: Add hooks to rust-qa-specialist.md (rust-validator, cargo-validator) ✅

H.7.3.4: Orchestration Agents (9 agents) - 100% Complete ✅

H.7.3.4.1: Add hooks to orchestrator.md (yaml-validator, json-schema-validator) ✅
H.7.3.4.2: Add hooks to difficulty-aware-orchestrator.md (json-schema-validator, yaml-validator) ✅
H.7.3.4.3: Add hooks to moe-ui-hitl-orchestrator.md (json-schema-validator, yaml-validator) ✅
H.7.3.4.4: Add hooks to council-orchestrator.md (json-schema-validator, yaml-validator) ✅
H.7.3.4.5: Add hooks to council-chairman.md (json-schema-validator, yaml-validator) ✅
H.7.3.4.6: Add hooks to workflow-orchestrator.md (yaml-validator, json-schema-validator) ✅
H.7.3.4.7: Add hooks to uncertainty-orchestrator.md (json-schema-validator, yaml-validator) ✅
H.7.3.4.8: Add hooks to multi-agent-coordinator.md (yaml-validator, json-schema-validator) ✅
H.7.3.4.9: Add hooks to production-cleanup-orchestrator.md (json-schema-validator, yaml-validator) ✅

H.7.3.5: Additional P0 Orchestrators (Bonus) - 100% Complete ✅

H.7.3.5.1: Add hooks to git-workflow-orchestrator.md (shellcheck-validator, yaml-validator) ✅
H.7.3.5.2: Add hooks to submodule-orchestrator.md (shellcheck-validator, yaml-validator) ✅
H.7.3.5.3: Add hooks to project-builder-orchestrator.md (json-schema-validator, yaml-validator) ✅
H.7.3.5.4: Add hooks to file-reorganization-orchestrator.md (yaml-validator, json-schema-validator) ✅
H.7.3.5.5: Add hooks to adk-orchestrator.md (json-schema-validator, python-ruff-validator) ✅
H.7.3.5.6: Add hooks to orchestrator-code-review.md (adr-validator, json-schema-validator) ✅
H.7.3.5.7: Add hooks to orchestrator-detailed-backup.md (json-schema-validator, yaml-validator) ✅

H.7.3.6: Architecture Agents (Bonus) - 100% Complete ✅

H.7.3.6.1: Add hooks to senior-architect.md (adr-validator, json-schema-validator) ✅
H.7.3.6.2: Add hooks to database-architect.md (migration-validator, json-schema-validator) ✅
H.7.3.6.3: Add hooks to foundationdb-expert.md (migration-validator, json-schema-validator) ✅
H.7.3.6.4: Add hooks to codebase-analyzer.md (markdown-validator, json-schema-validator) ✅
H.7.3.6.5: Add hooks to code-reviewer.md (python-ruff-validator, eslint-validator) ✅
H.7.3.6.6: Add hooks to adr-compliance-specialist.md (adr-validator, markdown-validator) ✅
H.7.3.6.7: Add hooks to performance-profiler.md (python-ruff-validator, json-schema-validator) ✅
H.7.3.6.8: Add hooks to application-performance.md (python-ruff-validator, json-schema-validator) ✅

Estimated Time: ~84h (42 agents × 2h each)

H.7.4: P1 High-Priority Agent Hooks (76 agents) - ~152h - 79% Complete

Status: 79% Complete (60/76 agents) - Jan 20, 2026 Goal: Add self-validation hooks to P1 high-priority agents Agent: /agent component-enhancer "Add self-validation hooks to P1 agents"

H.7.4.1: Code Generation Agents (15 agents) - 40% Complete

H.7.4.1.A: Frontend Development Agents (Bonus) - 100% Complete ✅

H.7.4.1.A.1: Add hooks to frontend-development-agent.md (eslint-validator, typescript-validator) ✅
H.7.4.1.A.2: Add hooks to frontend-mobile-development.md (eslint-validator, typescript-validator) ✅
H.7.4.1.A.3: Add hooks to react-native-developer.md (eslint-validator, typescript-validator) ✅
H.7.4.1.A.4: Add hooks to copilotkit-frontend-builder.md (eslint-validator, typescript-validator) ✅

H.7.4.2: Documentation Agents (8 agents) - 50% Complete

H.7.4.2.1: Add hooks to codi-documentation-writer.md (markdown-validator, yaml-validator) ✅
H.7.4.2.2: Add hooks to readme-generator.md (markdown-validator, yaml-validator) ✅
H.7.4.2.3: Add hooks to coditect-adr-specialist.md (adr-validator, markdown-validator) ✅
H.7.4.2.4: Add hooks to documentation-generation.md (markdown-validator, yaml-validator) ✅
H.7.4.2.4: Add hooks to software-design-document-specialist.md (sdd-validator)
H.7.4.2.5: Add hooks to api-documentation.md (openapi-validator)
H.7.4.2.6: Add hooks to technical-writer.md (markdown-validator)
H.7.4.2.7: Add hooks to changelog-writer.md (changelog-validator)
H.7.4.2.8: Add hooks to release-notes-writer.md (release-validator)

H.7.4.3: Architecture Agents (11 agents)

H.7.4.4: Frontend Agents (11 agents)

H.7.4.5: Backend Agents (12 agents)

H.7.4.6: Database Agents (7 agents)

H.7.4.6.1: Add hooks to postgresql-specialist.md (postgres-validator)
H.7.4.6.2: Add hooks to mysql-specialist.md (mysql-validator)
H.7.4.6.3: Add hooks to mongodb-specialist.md (mongo-validator)
H.7.4.6.4: Add hooks to redis-specialist.md (redis-validator)
H.7.4.6.5: Add hooks to elasticsearch-specialist.md (elastic-validator)
H.7.4.6.6: Add hooks to migration-specialist.md (migration-validator)
H.7.4.6.7: Add hooks to query-optimizer.md (query-validator)

H.7.4.7: Configuration Agents (12 agents) - 8% Complete

Estimated Time: ~152h (76 agents × 2h each)

H.7.5: P2-P3 Agent Hooks (60 agents) - ~60h

Goal: Add self-validation hooks to P2-P3 agents (lighter validation) Agent: /agent component-enhancer "Add self-validation hooks to P2-P3 agents"

H.7.5.1: Research/Analysis Agents (30 agents - P2)

H.7.5.2: External/Web Agents (18 agents - P3)

H.7.5.3: Finance Agents - ALREADY COMPLETE (6 agents)

H.7.5.3.1: finance-account-merger.md (csv-structure-validator) ✅
H.7.5.3.2: finance-csv-normalizer.md (csv-balance-validator) ✅
H.7.5.3.3: finance-csv-editor.md (csv-validator) ✅
H.7.5.3.4: finance-dashboard-generator.md (html-structure-validator) ✅
H.7.5.3.5: finance-graph-generator.md (graph-file-validator) ✅
H.7.5.3.6: finance-transaction-categorizer.md (csv-validator) ✅

Estimated Time: ~60h (48 new agents × 1h each + 12h buffer)

H.7.6: P0-P1 Command Hooks (34 commands) - ~68h

Goal: Add validation hooks to P0-P1 critical commands Agent: /agent component-enhancer "Add validation hooks to commands"

H.7.6.1: File Manipulation Commands - P0 (14 commands)

H.7.6.2: Git/Version Control Commands - P0 (5 commands)

H.7.6.2.1: Add hooks to /commit (commit-message-validator) ✅
H.7.6.2.2: Add hooks to /git-sync (git-sync-validator) ✅
H.7.6.2.3: Add hooks to /smart-merge (merge-conflict-validator)
H.7.6.2.4: Add hooks to /create-worktree (worktree-isolation-validator)
H.7.6.2.5: Add hooks to /worktree (worktree-validator)

H.7.6.3: Cloud/Deployment Commands - P0 (7 commands)

H.7.6.3.1: Add hooks to /deploy-site (deployment-safety-validator)
H.7.6.3.2: Add hooks to /docs-deploy (docs-deployment-validator)
H.7.6.3.3: Add hooks to /submodule-init (submodule-init-validator)
H.7.6.3.4: Add hooks to /backup (backup-integrity-validator) ✅
H.7.6.3.5: Add hooks to /license-status (license-status-validator)
H.7.6.3.6: Add hooks to /orient (orient-context-validator) ✅
H.7.6.3.7: Add hooks to /cloud-build (cloud-build-validator)

H.7.6.4: Context/Memory Commands - P1 (4 commands)

H.7.6.4.1: Add hooks to /cx (context-extraction-validator) ✅
H.7.6.4.2: Add hooks to /cxq (context-query-validator) ✅
H.7.6.4.3: Add hooks to /cxs (context-save-validator)
H.7.6.4.4: Add hooks to /cx-recall (context-recall-validator)

H.7.6.5: Finance Commands - ALREADY COMPLETE (9 commands)

H.7.6.5.1: /finance-import (csv-structure-validator) ✅
H.7.6.5.2: /finance-merge (csv-balance-validator) ✅
H.7.6.5.3: /finance-normalize (csv-validator) ✅
H.7.6.5.4: /finance-categorize (transaction-validator) ✅
H.7.6.5.5: /finance-report (report-validator) ✅
H.7.6.5.6: /finance-dashboard (html-structure-validator) ✅
H.7.6.5.7: /finance-graph (graph-file-validator) ✅
H.7.6.5.8: /finance-export (export-validator) ✅
H.7.6.5.9: /finance-analyze (analysis-validator) ✅

Estimated Time: ~68h (30 new commands × 2h each + 8h integration)

H.7.7: Critical Scripts Validation (33 scripts) - ~66h

Goal: Add validation to P0-P1 critical scripts Agent: /agent devops-engineer "Add validation to critical scripts"

H.7.7.1: P0 Critical Scripts (8 scripts)

H.7.7.1.1: Validate CODITECT-CORE-INITIAL-SETUP.py (path-whitelist + signature)
H.7.7.1.2: Validate CODITECT-DEVELOPER-SETUP.py (git-sanity + path)
H.7.7.1.3: Validate uninstall-coditect.py (deletion-whitelist + dry-run)
H.7.7.1.4: Validate backup-context-db.sh (shellcheck + cloud-auth)
H.7.7.1.5: Validate deploy-website.sh (shellcheck + deployment-target)
H.7.7.1.6: Validate docs-deploy.sh (shellcheck + docs-path)
H.7.7.1.7: Validate update-coditect.py (git-version + path)
H.7.7.1.8: Validate install-context-watcher.py (plist-syntax + service-permission)

H.7.7.2: P1 Database Scripts (12 scripts)

H.7.7.3: P1 Git/Config Scripts (8 scripts)

H.7.7.3.1: Validate create-checkpoint.py (git-tag-validation)
H.7.7.3.2: Validate update-project-plan.py (yaml-schema)
H.7.7.3.3: Validate setup-new-submodule.py (gh-auth + repo-name)
H.7.7.3.4: Validate sync-submodules.py (git-sync)
H.7.7.3.5: Validate update-submodule-refs.py (ref-validation)
H.7.7.3.6: Validate init-project.py (path-validation)
H.7.7.3.7: Validate clone-project.py (git-url-validation)
H.7.7.3.8: Validate archive-project.py (archive-path)

H.7.7.4: P1 File Operation Scripts (5 scripts)

H.7.7.4.1: Validate cleanup-phase1.sh (safe-find-patterns)
H.7.7.4.2: Validate cleanup-phase2.sh (shellcheck)
H.7.7.4.3: Validate cleanup-phase3.sh (shellcheck)
H.7.7.4.4: Validate component-create.sh (path-whitelist)
H.7.7.4.5: Validate submodule-init.sh (shellcheck)

Estimated Time: ~66h (33 scripts × 2h each)

H.7.8: High-Risk Skills Validation (50 skills) - ~50h

Goal: Add embedded validation to top 50 high-risk skills Agent: /agent component-enhancer "Add embedded validation to high-risk skills"

H.7.8.1: Deployment/Cloud Skills (10 skills)

H.7.8.2: Security Skills (10 skills)

H.7.8.3: Code Quality Skills (10 skills)

H.7.8.4: Documentation Skills (10 skills)

H.7.8.5: Orchestration Skills (10 skills)

Estimated Time: ~50h (50 skills × 1h each)

H.7.9: Workflow Pre-Flight Validation (15 workflows) - ~30h

Goal: Add pre-flight validation to all workflows Agent: /agent devops-engineer "Add pre-flight validation to workflows"

H.7.9.1: DevOps Workflows (5 workflows)

H.7.9.1.1: Add pre-flight to devops/adk-agent-development.yaml
H.7.9.1.2: Add pre-flight to devops/ci-cd-pipeline.yaml
H.7.9.1.3: Add pre-flight to devops/deployment-pipeline.yaml
H.7.9.1.4: Add pre-flight to devops/infrastructure-provisioning.yaml
H.7.9.1.5: Add pre-flight to devops/rollback-procedure.yaml

H.7.9.2: Quality Assurance Workflows (5 workflows)

H.7.9.2.1: Add pre-flight to quality-assurance/llm-evaluation.yaml
H.7.9.2.2: Add pre-flight to quality-assurance/code-review-pipeline.yaml
H.7.9.2.3: Add pre-flight to quality-assurance/test-automation.yaml
H.7.9.2.4: Add pre-flight to quality-assurance/security-scan.yaml
H.7.9.2.5: Add pre-flight to quality-assurance/compliance-check.yaml

H.7.9.3: Developer Experience Workflows (5 workflows)

H.7.9.3.1: Add pre-flight to developer-experience/batch-processing-pipeline.yaml
H.7.9.3.2: Add pre-flight to developer-experience/onboarding.yaml
H.7.9.3.3: Add pre-flight to developer-experience/local-development.yaml
H.7.9.3.4: Add pre-flight to performance/context-optimization.yaml
H.7.9.3.5: Add pre-flight to performance/query-optimization.yaml

Estimated Time: ~30h (15 workflows × 2h each)

H.7.10: Validator Library (63 validators) - ~126h

Goal: Create complete validator library Agent: /agent senior-architect "Create validator library"

H.7.10.1: Infrastructure Validators (8 validators) - P0

H.7.10.1.1: Create hooks/validators/shellcheck-validator.py
H.7.10.1.2: Create hooks/validators/terraform-validator.py
H.7.10.1.3: Create hooks/validators/kubernetes-validator.py
H.7.10.1.4: Create hooks/validators/dockerfile-validator.py
H.7.10.1.5: Create hooks/validators/cloudbuild-validator.py
H.7.10.1.6: Create hooks/validators/ansible-validator.py
H.7.10.1.7: Create hooks/validators/helm-validator.py
H.7.10.1.8: Create hooks/validators/pulumi-validator.py

H.7.10.2: Security Validators (9 validators) - P0

H.7.10.2.1: Create hooks/validators/secrets-validator.py
H.7.10.2.2: Create hooks/validators/cve-validator.py
H.7.10.2.3: Create hooks/validators/sarif-validator.py
H.7.10.2.4: Create hooks/validators/owasp-validator.py
H.7.10.2.5: Create hooks/validators/rbac-validator.py
H.7.10.2.6: Create hooks/validators/encryption-validator.py
H.7.10.2.7: Create hooks/validators/auth-validator.py
H.7.10.2.8: Create hooks/validators/pii-validator.py
H.7.10.2.9: Create hooks/validators/compliance-validator.py

H.7.10.3: Code Quality Validators (11 validators) - P1

H.7.10.4: Documentation Validators (12 validators) - P1

H.7.10.5: Data Format Validators (7 validators) - P1

H.7.10.5.1: Create hooks/validators/json-schema-validator.py
H.7.10.5.2: Create hooks/validators/yaml-validator.py
H.7.10.5.3: Create hooks/validators/xml-validator.py
H.7.10.5.4: Create hooks/validators/toml-validator.py
H.7.10.5.5: Create hooks/validators/ini-validator.py
H.7.10.5.6: Create hooks/validators/env-validator.py
H.7.10.5.7: Create hooks/validators/properties-validator.py

H.7.10.6: API Validators (6 validators) - P1

H.7.10.6.1: Create hooks/validators/rest-api-validator.py
H.7.10.6.2: Create hooks/validators/grpc-validator.py
H.7.10.6.3: Create hooks/validators/websocket-validator.py
H.7.10.6.4: Create hooks/validators/sse-validator.py
H.7.10.6.5: Create hooks/validators/webhook-validator.py
H.7.10.6.6: Create hooks/validators/api-response-validator.py

H.7.10.7: Build/Compilation Validators (6 validators) - P2

H.7.10.7.1: Create hooks/validators/webpack-validator.py
H.7.10.7.2: Create hooks/validators/vite-validator.py
H.7.10.7.3: Create hooks/validators/esbuild-validator.py
H.7.10.7.4: Create hooks/validators/rollup-validator.py
H.7.10.7.5: Create hooks/validators/cargo-validator.py
H.7.10.7.6: Create hooks/validators/gradle-validator.py

H.7.10.8: Data Integrity Validators (4 validators) - P2

H.7.10.8.1: Create hooks/validators/migration-validator.py
H.7.10.8.2: Create hooks/validators/schema-validator.py
H.7.10.8.3: Create hooks/validators/backup-validator.py
H.7.10.8.4: Create hooks/validators/export-validator.py

Estimated Time: ~126h (63 validators × 2h each)

H.7.11: Orchestration & Documentation - ~32h

Goal: Create validation orchestration and documentation Agent: /agent senior-architect "Create validation orchestration"

H.7.11.1: Validation Orchestrator Agents (4 agents)

H.7.11.1.1: Create agents/validation-orchestrator.md
H.7.11.1.2: Create agents/pre-commit-validator.md
H.7.11.1.3: Create agents/pr-quality-gate.md
H.7.11.1.4: Create agents/ci-validation-agent.md

H.7.11.2: Validation Commands (6 commands)

H.7.11.2.1: Create /validate command (generic validation)
H.7.11.2.2: Create /validate-all command (full validation suite)
H.7.11.2.3: Create /validate-component command (component validation)
H.7.11.2.4: Create /check-security command (security checks)
H.7.11.2.5: Create /audit-compliance command (compliance audits)
H.7.11.2.6: Create /lint-all command (all linters)

H.7.11.3: Validation Skills (8 skills)

H.7.11.3.1: Create skills/json-schema-validation/SKILL.md
H.7.11.3.2: Create skills/yaml-validation-patterns/SKILL.md
H.7.11.3.3: Create skills/dockerfile-best-practices/SKILL.md
H.7.11.3.4: Create skills/terraform-validation-patterns/SKILL.md
H.7.11.3.5: Create skills/kubernetes-validation-patterns/SKILL.md
H.7.11.3.6: Create skills/external-validator-integration/SKILL.md
H.7.11.3.7: Create skills/validation-result-aggregation/SKILL.md
H.7.11.3.8: Create skills/validation-error-recovery/SKILL.md

H.7.11.4: Architecture Decisions (3 ADRs)

H.7.11.4.1: Create ADR-083-self-validating-ecosystem.md
H.7.11.4.2: Create ADR-084-validator-library-architecture.md
H.7.11.4.3: Create ADR-085-validation-orchestration-patterns.md

H.7.11.5: Standards & Guides (4 documents)

H.7.11.5.1: Create CODITECT-STANDARD-VALIDATION.md
H.7.11.5.2: Create docs/guides/SELF-VALIDATING-AGENT-GUIDE.md
H.7.11.5.3: Create docs/guides/VALIDATOR-DEVELOPMENT-GUIDE.md
H.7.11.5.4: Update CLAUDE.md with validation section

Estimated Time: ~32h

Track H.7 Summary (COMPLETE):

Phase	Tasks	Hours	Priority	Coverage
H.7.1 Critical Validators	25	24h	P0	Foundation ✅
H.7.2 High-Priority Validators	30	30h	P1	Foundation ✅
H.7.3 P0 Agent Hooks	55	84h	P0	76% Complete (32/42 + 13 bonus)
H.7.4 P1 Agent Hooks	76	152h	P1	79% Complete (60/76)
H.7.5 P2-P3 Agent Hooks	60	60h	P2	100% agents
H.7.6 Command Hooks	34	68h	P0-P1	100% commands
H.7.7 Script Validation	33	66h	P0-P1	33 scripts
H.7.8 Skill Validation	50	50h	P1	50 skills
H.7.9 Workflow Validation	15	30h	P1	100% workflows
H.7.10 Validator Library	63	126h	P0-P2	63 validators
H.7.11 Orchestration & Docs	25	32h	P2	Complete
Total	733	~722h	-	100%

Expected Outcomes:

63 new validators covering all major file types
172 agents with self-validation hooks (from 6 → 178)
34 commands with validation hooks (from 9 → 43)
33 scripts with validation
50 skills with embedded validation
15 workflows with pre-flight validation
4 orchestration agents
6 validation commands
8 validation skills
3 new ADRs (083, 084, 085)
3 new standards/guides

Quality Gate:

All validators must pass MoE judges verification (≥8.5/10)
Each agent/command hook must include:
- Validator matching appropriate output type
- JSON output format compliance
- Exit code handling (0=success, 2=blocking)
- Self-correction flow documentation

H.8: Ralph Wiggum Autonomous Agent Infrastructure (ADRs 108-112)

Source: Gap Analysis (Jan 25, 2026) + Implementation Requirements docs Goal: Enable autonomous agent loops with fresh-context iterations per Ralph Wiggum technique Status: 35% Complete - Python modules + DB schema (SQLite + PostgreSQL) done, integration + testing pending ADRs: ADR-108 (Checkpoint), ADR-109 (Browser), ADR-110 (Health), ADR-111 (Token), ADR-112 (DB) Key Insight: "Single-context loops degrade; fresh-context iterations maintain quality."

Existing Assets (Jan 24-25):

scripts/core/ralph_wiggum/ - Python implementation (3,462 lines across 5 modules)
analyze-new-artifacts/CODITECT-Ralph-Wiggum-technique/ - Analysis docs (~2,000 lines)
ADRs 108-112 - Architecture decisions with MoE frontmatter

H.8.1: Checkpoint Protocol Integration (ADR-108) - ~32h

Agent: /agent senior-architect "Integrate checkpoint protocol with context.db"

H.8.2: Browser Automation Integration (ADR-109) - ~24h

Agent: /agent qa-automation-specialist "Integrate browser automation for visual verification"

H.8.2.1: Create browser_automation.py module (~898 lines) ✅ Jan 24
H.8.2.2: Define FlowStep, QAAgentBrowserTools classes ✅ Jan 24
H.8.2.3: Implement visual verification flow ✅ Jan 24
H.8.2.4: Configure Playwright MCP server integration - 4h
- Agent: /agent devops-engineer "Configure playwright-mcp-server in ~/.claude/settings.json for browser automation"
H.8.2.5: Create visual regression baseline workflow - 8h
- Agent: /agent qa-automation-specialist "Create workflow for visual baseline capture and comparison using Playwright"
H.8.2.6: Integrate with /qa-review command - 4h
- Agent: /agent senior-architect "Add browser verification step to /qa-review command"
H.8.2.7: Write unit tests for QAAgentBrowserTools (target: 20 tests) - 8h
- Agent: Task(subagent_type="testing-specialist", prompt="Create test_browser_automation.py with mocked Playwright tests")

H.8.3: Health Monitoring Integration (ADR-110) - ~24h

Agent: /agent senior-architect "Integrate health monitoring with MCP status"

H.8.3.1: Create health_monitoring.py module (~806 lines) ✅ Jan 24
H.8.3.2: Implement 5-state health model (starting, healthy, degraded, recovering, failed) ✅ Jan 24
H.8.3.3: Implement CircuitBreaker with 3-state machine ✅ Jan 24
H.8.3.4: Implement RecoveryService with intervention levels ✅ Jan 24
H.8.3.5: Create health metrics table in context.db ✅ Jan 25
- Included in unified migration add-ralph-wiggum-tables.sql
- health_events table with: agent_id, session_id, previous_state, new_state, heartbeat_data, intervention, circuit_breaker
H.8.3.6: Integrate with context-watcher daemon - 8h
- Agent: /agent senior-architect "Add health monitoring to coditect-context-watch Rust binary. Emit heartbeats, detect stagnation."
H.8.3.7: Create /health-status command - 4h
- Agent: /component-create command health-status "Display current agent health status and circuit breaker state"
H.8.3.8: Write unit tests for HealthMonitoringService (target: 25 tests) - 8h
- Agent: Task(subagent_type="testing-specialist", prompt="Create test_health_monitoring.py with circuit breaker, state transition, recovery tests")

H.8.4: Token Economics Integration (ADR-111) - ~24h

Agent: /agent senior-architect "Integrate token economics with cost tracking"

H.8.4.1: Create token_economics.py module (~781 lines) ✅ Jan 24
H.8.4.2: Implement TokenRecord, Budget, CostBreakdown classes ✅ Jan 24
H.8.4.3: Implement TokenEconomicsService with hierarchical budgets ✅ Jan 24
H.8.4.4: Create token_records table in context.db ✅ Jan 25
- Included in unified migration add-ralph-wiggum-tables.sql
- token_records + budgets tables with hierarchical budget enforcement
H.8.4.5: Integrate with /token-status command - 4h
- Agent: /agent senior-architect "Enhance /token-status to show budget utilization, cost breakdown by task"
H.8.4.6: Add budget enforcement to Task tool calls - 8h
- Agent: /agent senior-architect "Add PreToolUse hook to check budget before agent spawns. Block if budget exceeded."
H.8.4.7: Create cost attribution reports - 4h
- Agent: /agent senior-architect "Create /cost-report command showing token usage by task, track, session"
H.8.4.8: Write unit tests for TokenEconomicsService (target: 25 tests) - 4h
- Agent: Task(subagent_type="testing-specialist", prompt="Create test_token_economics.py with budget, cost, efficiency metric tests")

H.8.5: Database Architecture Reconciliation (ADR-112) - ~16h

Agent: /agent database-architect "Reconcile Ralph Wiggum DB with ADR-002/ADR-089"

H.8.5.1: Create ADR-112 reconciling FoundationDB refs with PostgreSQL ✅ Jan 25
H.8.5.2: Update ADRs 108-111 to reference PostgreSQL/SQLite ✅ Jan 25
H.8.5.3: Create unified schema migration script ✅ Jan 25
- scripts/migrate-ralph-wiggum-schema.py - Python runner with --status, --verify, --dry-run
- scripts/migrations/add-ralph-wiggum-tables.sql - 5 tables, 4 views, 2 triggers
- Commit: f32b9ff2 (4,122 lines added)
H.8.5.4: Create cloud sync for Ralph Wiggum tables ✅ Jan 28
- Agent: /agent senior-architect "Add Ralph Wiggum tables to ADR-053 cloud sync protocol. Include in sync_queue."
- Client: scripts/core/ralph_wiggum_sync_client.py (~650 lines)
- Serializers: 20 serializers (5 models × 4 types) in backend/context/serializers.py
- Views: backend/context/ralph_wiggum_views.py (~580 lines)
- URLs: 10 endpoints in backend/context/urls.py
- Pattern: Batch push/cursor-based pull per ADR-053/089/103

H.8.6: Autonomous Loop Orchestration - ~40h

Agent: /agent senior-architect "Create autonomous loop orchestrator"

H.8.6.1: Create ralph_loop_orchestrator.py module - 16h
- Agent: /agent senior-architect "Create orchestrator combining checkpoint, health, token services for autonomous execution loop"
H.8.6.2: Create /ralph-loop command - 4h
- Agent: /component-create command ralph-loop "Start autonomous agent loop with health monitoring and checkpointing"
H.8.6.3: Create ralph-loop-monitor agent - 8h
- Agent: /component-create agent ralph-loop-monitor "Monitor autonomous loops, trigger interventions on degradation"
H.8.6.4: Integrate with PILOT plan task execution - 8h
- Agent: /agent senior-architect "Enable Ralph loop for PILOT task execution with automatic fresh-context iteration"
H.8.6.5: Create loop termination criteria - 4h
- Agent: /agent senior-architect "Define loop termination: budget exhausted, goal achieved, max iterations, health failed"

H.8.7: Documentation & Testing - ~24h

Agent: /agent codi-documentation-writer "Document Ralph Wiggum integration"

H.8.7.1: Create docs/guides/RALPH-WIGGUM-GUIDE.md - 4h
- Agent: /agent codi-documentation-writer "Create user guide for autonomous agent loops with checkpointing"
H.8.7.2: Create internal/architecture/RALPH-WIGGUM-ARCHITECTURE.md - 4h
- Agent: /agent codi-documentation-writer "Create architecture doc linking ADRs 108-112 with implementation"
H.8.7.3: Add Ralph Wiggum section to CLAUDE.md - 2h
- Agent: /agent codi-documentation-writer "Add autonomous loop section to CLAUDE.md quick commands"
H.8.7.4: Create integration test suite - 8h
- Agent: Task(subagent_type="testing-specialist", prompt="Create test_ralph_wiggum_integration.py testing full checkpoint-health-token flow")
H.8.7.5: Create MoE evaluation for Ralph Wiggum components - 4h
- Agent: /moe-judges "Evaluate Ralph Wiggum Python modules against ADR requirements"
H.8.7.6: Update component-counts.json and framework-registry.json - 2h
- Agent: python3 scripts/update-component-counts.py

H.8.8: Business Templates Verification - ~84h

Added: January 26, 2026 Agent: /agent senior-architect "Verify business templates in skills/"

Business Plan Tasks:

Gap Tasks (Pending):

H.8.8.13: Create automation-roadmap skill - 4h
H.8.8.14: Create feature-development skill - 4h
H.8.8.15: Create prototype skill - 4h
H.8.8.16: Create sprint skill - 4h
H.8.8.17: Create epic skill - 4h
H.8.8.18: Create project skill - 4h
H.8.8.19: Create motion skill - 4h
H.8.8.20: Create founder-mode skill - 4h
H.8.8.21: Create pilot skill - 4h

H.8 Summary:

Phase	Tasks	Hours	Priority	Status
H.8.1 Checkpoint Protocol	10	32h	P0	60% (6/10)
H.8.2 Browser Automation	7	24h	P1	43% (3/7)
H.8.3 Health Monitoring	8	24h	P0	63% (5/8)
H.8.4 Token Economics	8	24h	P0	50% (4/8)
H.8.5 DB Reconciliation	4	16h	P0	✅ 100% (4/4)
H.8.6 Loop Orchestration	5	40h	P1	0% (0/5)
H.8.7 Documentation	6	24h	P2	0% (0/6)
H.8.8 Business Templates	21	84h	P1	Verification Pending
Total	69	~268h	-	42% (29/69)

Dependencies:

ADR-002 (PostgreSQL), ADR-089 (Two-Database) - COMPLETE ✅
ADR-053 (Cloud Context Sync) - COMPLETE ✅
context.db schema extensions - PENDING
context-watcher daemon updates - PENDING

Agent Invocations for Next Steps:

# Phase 1: Database schema (P0)
/agent database-architect "Create migration adding checkpoints, health_events, token_records tables to context.db per ADRs 108-111"

# Phase 2: Integration (P0)
/agent senior-architect "Integrate checkpoint protocol with /cx context extraction"

# Phase 3: Testing (P1)
Task(subagent_type="testing-specialist", prompt="Create comprehensive test suite for scripts/core/ralph_wiggum/ modules")

Track I: UI Components Library (V2 E002)

Source: MoE UI/UX Agent System Implementation Plan (2026-01-19) Goal: Professional enterprise-grade UI generation with MoE agent coordination Status: 100% Complete (41/41 tasks) - ALL PHASES COMPLETE ✅ Updated: January 20, 2026

I.1: MoE UI Agent System ✅ COMPLETE

Agent: /agent adk-agent-builder Completed: January 19, 2026

I.1.1: Create moe-ui-quality-gate-enforcer agent - 1h ✅
I.1.2: Create moe-ui-design-system-enforcer agent - 1h ✅
I.1.3: Create moe-ui-hitl-orchestrator agent - 1h ✅
I.1.4: Create moe-ui-navigation-optimizer agent - 1h ✅
I.1.5: Create moe-ui-visual-design-specialist agent - 1h ✅
I.1.6: Create moe-ui-a2ui-renderer agent - 1h ✅
I.1.7: Create moe-ui-agui-event-coordinator agent - 1h ✅
I.1.8: Create moe-ui-component-library-curator agent - 1h ✅

I.2: MoE UI Skills ✅ COMPLETE

Agent: /component-create skill Completed: January 19, 2026

I.2.1: Create moe-ui-design-validation skill - 1h ✅
I.2.2: Create moe-ui-hitl-approval-flow skill - 1h ✅
I.2.3: Create moe-ui-a2ui-patterns skill - 1h ✅
I.2.4: Create moe-ui-agui-streaming skill - 1h ✅
I.2.5: Create moe-ui-navigation-patterns skill - 1h ✅

I.3: MoE UI Commands ✅ COMPLETE

Agent: /component-create command Completed: January 19, 2026

I.3.1: Create /ui-optimize command - 0.5h ✅
I.3.2: Create /ui-design-system command - 0.5h ✅
I.3.3: Create /ui-a2ui-render command - 0.5h ✅
I.3.4: Create /ui-approve command - 0.5h ✅
I.3.5: Create /ui-quality command - 0.5h ✅

I.4: UI/UX Standards ✅ COMPLETE

Agent: /agent codi-documentation-writer Completed: January 19, 2026

I.4.1: Create CODITECT-STANDARD-DESIGN-TOKENS.md - 2h ✅
I.4.2: Create CODITECT-STANDARD-ACCESSIBILITY.md - 2h ✅
I.4.3: Create CODITECT-STANDARD-COMPONENT-LIBRARY.md - 2h ✅
I.4.4: Create CODITECT-STANDARD-UI-UX.md - 2h ✅

I.5: Architecture Decision Records ✅ COMPLETE

Agent: /agent senior-architect Completed: January 19, 2026

I.5.1: Create ADR-084-moe-ui-agent-architecture.md - 1.5h ✅
I.5.2: Create ADR-085-atomic-design-component-library.md - 1.5h ✅
I.5.3: Create ADR-086-ag-ui-event-protocol-integration.md - 1.5h ✅
I.5.4: Create ADR-087-hitl-approval-workflow-ui-changes.md - 1.5h ✅

I.6: Component Library (Proto-Code) ✅ COMPLETE

Agent: /agent generative-ui-code-generator Completed: January 19, 2026 Updated: January 20, 2026 (Gap analysis additions)

Original Implementation (39 components):

I.6.1: Create design tokens CSS/TS - 2h ✅
I.6.2: Create Button atom proto-code - 1h ✅
I.6.3: Create FormField molecule proto-code - 1h ✅
I.6.4: Create Card organism proto-code - 1h ✅
I.6.5: Create DashboardGrid template proto-code - 1h ✅

Gap Analysis Additions (14 components - January 20, 2026):

New Atoms (5):

I.6.6: Create Select atom (dropdown select input) - 0.5h ✅
I.6.7: Create Textarea atom (multiline input) - 0.5h ✅
I.6.8: Create Skeleton atom (loading placeholder) - 0.5h ✅
I.6.9: Create Link atom (styled anchor) - 0.5h ✅
I.6.10: Create Tooltip atom (hover tooltip) - 0.5h ✅

New Molecules (6):

I.6.11: Create Alert molecule (feedback message) - 0.5h ✅
I.6.12: Create Dropdown molecule (menu with keyboard nav) - 0.5h ✅
I.6.13: Create Tabs molecule (tabbed interface) - 0.5h ✅
I.6.14: Create Accordion molecule (collapsible sections) - 0.5h ✅
I.6.15: Create Popover molecule (positioned overlay) - 0.5h ✅
I.6.16: Create DatePicker molecule (date selection) - 0.5h ✅

New Organisms (3):

I.6.17: Create Drawer organism (slide-out panel) - 0.5h ✅
I.6.18: Create Stepper organism (wizard navigation) - 0.5h ✅
I.6.20: Create TreeView organism (hierarchical list) - 0.5h ✅

New Templates (1):

I.6.19: Create AuthPage template (login/register layout) - 0.5h ✅

P1 Improvements (January 20, 2026):

I.6.21: Create atoms/index.ts barrel export (18 components + types) - 0.5h ✅
I.6.22: Create molecules/index.ts barrel export (17 components + types) - 0.5h ✅
I.6.23: Create organisms/index.ts barrel export (12 components + types) - 0.5h ✅
I.6.24: Create templates/index.ts barrel export (7 components + types) - 0.5h ✅
I.6.25: Add token utility functions to tokens.ts (getTokenValue, space, color, etc.) - 1h ✅
I.6.26: Create root index.ts barrel export with all 54 components + metadata - 0.5h ✅

Component Library Totals:

Level	Original	Added	Total
Atoms	13	5	18
Molecules	11	6	17
Organisms	9	3	12
Templates	6	1	7
Total	39	15	54

Quality Metrics (January 20, 2026):

Documentation: 98% (all 54 components have JSDoc headers)
Accessibility: 94% (WCAG 2.1 AA compliance)
Token Compliance: 100% (all use --coditect-* tokens)
TypeScript: 100% (all components fully typed)

I.7: Index and Activate ✅ COMPLETE

Agent: Bash + /classify Completed: January 20, 2026

I.7.1: Run component-indexer.py - 0.5h ✅ (2299 components indexed)
I.7.2: Verify all components indexed - 0.5h ✅ (54 UI components verified)
I.7.3: Run /classify on all new docs - 1h ✅
I.7.4: Update component-counts.json - 0.5h ✅

I.8: Full Component Implementation (Remaining)

Agent: /agent generative-ui-code-generator Status: Proto-code complete (54/54 components done)

All Complete (January 20, 2026):

I.8.1: Implement TreeView organism - 0.5h ✅
I.8.2: Create Storybook documentation (54 story files) - 12h ✅
I.8.3: Create component tests (54 test files) - 20h ✅
I.8.4: Production deployment to coditect-cloud-frontend (d266511) - 8h ✅

Track I Summary: ✅ 100% COMPLETE (January 20, 2026)

8 MoE UI agents created
5 supporting skills created
5 slash commands created
4 standards documents created
4 ADRs created (ADR-084 through ADR-087)
54 production components (18 atoms, 17 molecules, 12 organisms, 7 templates) ✅
54 Storybook stories (documentation with variants) ✅
54 unit tests (Vitest + Testing Library) ✅
Barrel exports (4 level index.ts + 1 root index.ts) ✅
Token utilities (getTokenValue, space, color, isDarkMode, etc.) ✅
Production deployed to coditect-cloud-frontend (d266511) ✅
Quality metrics: 98% docs, 94% a11y, 100% tokens, 100% TypeScript
Reference documents: FRONTEND-REFERENCES.md, FRONTEND-COMPONENT-INVENTORY.md

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

J.8: Auto-Session Preservation Architecture ✅ COMPLETE

Source: Codanna integration security work (76b7aed9) Goal: Automatic session export before context loss Status: 100% Complete Related: H.5 Codanna Integration, Claude Code bug #17433

J.8.1: Create /session-export command - 2h ✅ Completed Jan 11, 2026
- Workaround for Claude Code /export emoji crash bug
J.8.2: Create hooks/context-threshold-monitor.py - 4h ✅ Completed Jan 11, 2026
- Monitors context usage percentage
- Triggers auto-export at configurable threshold
J.8.3: Create scripts/session-exporter.py - 4h ✅ Completed Jan 11, 2026
- Automated session export with timestamp naming
- Handles emoji-safe export (avoids UTF-8 boundary issues)
J.8.4: Create docs/guides/AUTO-SESSION-PRESERVATION-ARCHITECTURE.md - 2h ✅ Completed Jan 11, 2026
J.8.5: Add auto-preservation trigger to setup script - 1h ✅ Completed Jan 11, 2026

Commits:

76b7aed9 feat(security): Add P0 MCP security wrapper for multi-tenant support
95114f1a feat(statusline): Add auto-preservation trigger to setup script

Bug Report Filed: Claude Code #17433 - /export crashes on emoji characters

J.9: Export Pipeline Standardization ✅ COMPLETE

Source: Auto-export bug investigation (Jan 11, 2026) Goal: Consistent export file locations for reliable /cx processing Status: 100% Complete (8/8 tasks) Related: J.8 Auto-Session Preservation

Problem: Auto-export hook was failing silently because:

--quiet flag didn't exist in session-exporter.py
session-exporter.py defaulted to cwd, but hook looked in exports-archive
No standard "pending" directory for unprocessed exports

J.9.1: Fix --quiet flag bug in context-threshold-monitor.py - 0.5h ✅ Completed Jan 11, 2026
- Removed invalid --quiet flag causing exit code 2
J.9.2: Create standard exports-pending directory - 0.5h ✅ Completed Jan 11, 2026
- Location: ~/PROJECTS/.coditect-data/context-storage/exports-pending/
- All exports go here before /cx processing
J.9.3: Update session-exporter.py default output - 0.5h ✅ Completed Jan 11, 2026
- Default to exports-pending instead of cwd
J.9.4: Update unified-message-extractor.py search paths - 0.5h ✅ Completed Jan 11, 2026
- Add exports-pending as primary search location
J.9.5: Update context-threshold-monitor.py verification - 0.5h ✅ Completed Jan 11, 2026
- Look for exports in exports-pending after triggering
J.9.6: Update CODITECT-CORE-INITIAL-SETUP.py - 0.5h ✅ Completed Jan 11, 2026
- Create exports-pending directory during installation
J.9.7: Move stray export files to exports-pending - 0.5h ✅ Completed Jan 11, 2026
- Moved 4 unprocessed exports from project directories
J.9.8: Test full auto-export → /cx pipeline - 1h ✅ Completed Jan 11, 2026
- Verified end-to-end workflow

Commits:

8d763d6a fix: Remove invalid --quiet flag from session-exporter call
1a5d07f2 feat(J.9): Standardize export pipeline with exports-pending directory

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 ✅ (Jan 18, 2026)
- Created coditect-pilot namespace in GKE cluster
- Resource quotas: 12 CPU, 24Gi RAM, 40 pods, 150Gi storage
- Network policies: Default deny with allowed DB/Redis/DNS traffic
- Documentation: docs/pilot/PILOT-INFRASTRUCTURE-SETUP.md
N.2.2: Create pilot onboarding materials - 24h ✅ (Jan 11, 2026)
- Created PILOT-ONBOARDING-CHECKLIST.md
- Created PILOT-WELCOME-EMAIL-TEMPLATE.md (5 templates)
- Created PILOT-SUPPORT-GUIDE.md
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 ✅ (Jan 18, 2026)
- Created Django feedback app: backend/feedback/
- Models: Feedback, FeedbackVote, FeedbackComment (multi-tenant)
- Types: bug, feature, performance, docs, ux, other
- API endpoints: submit, list, vote, stats, respond
- Admin interface with filters and bulk actions
- Documentation: docs/pilot/PILOT-FEEDBACK-COLLECTION-SETUP.md
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

Extension Track: CODX - Codex Integration (Added Jan 28, 2026)

Status: 80% Complete (4/5 tasks) ADRs: ADR-122 (Unified LLM Architecture), ADR-123 (Session Export), ADR-124 (Watcher) Repository: coditect-core/codex/

CODX.2: Codex Session Export Management (ADR-123)

CODX.2.1: Create ADR-123 for Codex session export management ✅ Jan 28
CODX.2.2: Create scripts/extract-codex-session.py ✅ Jan 28
CODX.2.3: Create codex/skills/codex-session-export/SKILL.md ✅ Jan 28
CODX.2.4: Create codex/commands/codex-session-export.md ✅ Jan 28

CODX.3: Codex Session Export Watcher (ADR-124)

CODX.3.1: Create ADR-124 for Codex watcher daemon ✅ Jan 28
CODX.3.2: Create codex/codi-codex-watcher/ Rust binary ✅ Jan 28
CODX.3.3: Create systemd/launchd service configs ✅ Jan 28

CODX.5: Export Filtering (Date Support)

CODX.5.1: Add --date YYYY-MM-DD filtering to extract-codex-session.py ✅ Jan 28
CODX.5.2: Update ADR-123 with date filter documentation ✅ Jan 28

Extension Track: OPS - Operations (Added Jan 28, 2026)

Status: 75% Complete (3/4 tasks) ADR: ADR-125 (Centralized Logging Architecture) Repository: coditect-core/

OPS.2: Centralized Logging (ADR-125)

OPS.2.1: Create ADR-125 for centralized logging architecture ✅ Jan 28
OPS.2.2: Update service log paths to ~/.coditect-data/logs/ ✅ Jan 28
- scripts/services/ai.coditect.context-watcher.plist
- codex/codi-codex-watcher/scripts/services/ai.coditect.codex-watcher.plist
OPS.2.3: Create scripts/migrate-logs.py ✅ Jan 28
OPS.2.4: Execute log migration script (deferred - requires coordination)
- Command: python3 scripts/migrate-logs.py
- Note: Must be run with explicit approval; ensure target ~/PROJECTS/.coditect-data/logs/ exists

Extension Track: ARCH - Architecture (Added Jan 28, 2026)

Status: 100% Complete (1/1 tasks) ADR: ADR-122 (Unified LLM Component Architecture)

ARCH.3: Multi-LLM Portability (ADR-122)

ARCH.3.1: Create ADR-122 for unified LLM component architecture ✅ Jan 28
- Defines portable component spec for Claude, Codex, Gemini
- Canonical spec → LLM-specific compilers
ARCH.3.2: Create interoperability/compilers/ ✅ Jan 28
- compile_claude.py - Claude Code compiler
- compile_codex.py - OpenAI Codex compiler
- compile_gemini.py - Google Gemini compiler

Extension Track: GEMINI - Gemini Integration (Added Jan 27, 2026)

Status: 100% Complete (8/8 tasks) ADRs: ADR-126 (Session Export), ADR-127 (Watcher) Repository: coditect-core/gemini/

GEMINI.2: Gemini Session Export Management (ADR-126)

GEMINI.2.1: Create ADR-126 for Gemini session export management ✅ Jan 27
- Defines automated Gemini session export with context-threshold triggers
- Mirrors ADR-123 pattern for Codex
- Specifies history file locations and export format
GEMINI.2.2: Create gemini/scripts/extract-gemini-session.py ✅ Jan 27
- Multi-location history file discovery
- Date filtering support (--since, --until, --date)
- JSONL export format
GEMINI.2.3: Create gemini/skills/gemini-session-export/SKILL.md ✅ Jan 27
- Skill definition for Gemini session export
- Pattern-based invocation
GEMINI.2.4: Create gemini/commands/gemini-session-export.md ✅ Jan 27
- Command documentation
- Usage examples

GEMINI.3: Gemini Session Export Watcher (ADR-127)

GEMINI.3.1: Create ADR-127 for Gemini watcher ✅ Jan 27
- Defines Rust binary codi-gemini-watcher
- Specifies thresholds: 80% warn, 85% export, 30s interval
GEMINI.3.2: Create gemini/codi-gemini-watcher/ Rust binary ✅ Jan 27
- Cargo.toml, main.rs, paths.rs, gemini_watcher.rs
- Background daemon mode
- One-shot check mode for hooks
GEMINI.3.3: Create systemd/launchd service configs ✅ Jan 27
- ai.coditect.gemini-watcher.plist (macOS launchd)
- coditect-gemini-watcher.service (Linux systemd)
GEMINI.3.4: Create notify hook for post-turn context check ✅ Jan 27
- gemini-notify-hook.py - Triggers single context check

Extension Track: UNIFY - Unified LLM Session Management (Added Jan 28, 2026)

Purpose: Consolidate fragmented LLM session extraction and context watching into unified systems. Related ADRs: ADR-122 (Unified LLM Component Architecture), ADR-128 (proposed) Primary Agent: senior-architect Supporting Agents: backend-architect, rust-development-specialist, devops-engineer

UNIFY.1: Architecture & ADR

Goal: Define unified architecture for all LLM session management

UNIFY.1.1: Create ADR-128 Unified LLM Session Management
- Single /cx command for Claude, Codex, Gemini
- Single codi-watcher binary for all LLM context watching
- Auto-detection logic for LLM source
- Migration path from separate scripts

UNIFY.2: Unified Extractor (`/cx`)

Goal: Single unified-message-extractor.py for all LLMs

UNIFY.2.1: Add llm_source and llm_model fields to messages schema ✅ Jan 28
UNIFY.2.2: Update create_unified_message() with LLM identification ✅ Jan 28
UNIFY.2.3: Update JSONLExtractor with llm_source parameter ✅ Jan 28
UNIFY.2.4: Update EnhancedExportExtractor with llm_source parameter ✅ Jan 28
UNIFY.2.5: Add CodexExtractor class to unified-message-extractor.py
- Port extraction logic from extract-codex-session.py
- Support both ~/.codex/history.jsonl and ~/.codex/sessions/ formats
- Auto-set llm_source='codex'
UNIFY.2.6: Add GeminiExtractor class to unified-message-extractor.py
- Port extraction logic from extract-gemini-session.py
- Support ~/.gemini/history.jsonl and config locations per ADR-126
- Auto-set llm_source='gemini'
UNIFY.2.7: Add LLM auto-detection by path pattern
- ~/.claude/ → llm_source='claude'
- ~/.codex/ → llm_source='codex'
- ~/.gemini/ → llm_source='gemini'
UNIFY.2.8: Update /cx command to scan all LLM session directories
- Add --llm claude|codex|gemini|all option (default: all)
- Update cx.md documentation
UNIFY.2.9: Deprecate standalone extract scripts (keep as thin wrappers)
- extract-codex-session.py → calls unified-message-extractor.py
- extract-gemini-session.py → calls unified-message-extractor.py

UNIFY.3: Unified Watcher (`codi-watcher`)

Goal: Single Rust binary for all LLM context watching

UNIFY.3.1: Extend tools/context-watcher for multi-LLM support
- Add LLM process detection (claude, codex, gemini)
- Unified threshold configuration per LLM
- Single state file with per-LLM sections
UNIFY.3.2: Merge codi-codex-watcher into context-watcher
- Move Codex-specific detection into main watcher
- Remove codex/codi-codex-watcher/ as standalone binary
UNIFY.3.3: Merge codi-gemini-watcher into context-watcher
- Move Gemini-specific detection into main watcher
- Remove gemini/codi-gemini-watcher/ as standalone binary
UNIFY.3.4: Update watcher CLI interface
- codi-watcher --status → Shows all LLM states
- codi-watcher --llm claude → Monitor specific LLM
- codi-watcher --threshold 80 --export 85 → Unified thresholds
UNIFY.3.5: Consolidate service configurations
- Single ai.coditect.context-watcher.plist (macOS)
- Single coditect-context-watcher.service (Linux)
- Remove LLM-specific service files

UNIFY.3.6: Update watcher state file format

{
  "claude": {"last_export": "...", "context_percent": 45},
  "codex": {"last_export": "...", "context_percent": 30},
  "gemini": {"last_export": "...", "context_percent": 25}
}

UNIFY.4: Documentation & Testing

UNIFY.4.1: Update CLAUDE.md with unified extraction architecture
UNIFY.4.2: Update /cx command documentation (cx.md) ✅ Jan 28 - v3.0.0 with multi-LLM support
UNIFY.4.2b: Update /cxq command documentation (cxq.md) ✅ Jan 28 - v5.0.0 with --llm filter
UNIFY.4.3: Update context-watcher README.md
UNIFY.4.4: Add unified extraction tests
UNIFY.4.5: Add multi-LLM watcher tests

UNIFY Summary

Task	Description	Status
UNIFY.1	Architecture ADR	⏳ Pending
UNIFY.2.1-2.4	Schema fields + migration	✅ Complete (Jan 28)
UNIFY.2.5-2.9	Extractor consolidation	⏳ Pending
UNIFY.3.1-3.6	Watcher consolidation	⏳ Pending
UNIFY.4.1	CLAUDE.md update	⏳ Pending
UNIFY.4.2-4.2b	/cx and /cxq command docs	✅ Complete (Jan 28)
UNIFY.4.3-4.5	Watcher docs & tests	⏳ Pending

Architecture:

BEFORE (Fragmented):                    AFTER (Unified):
├── unified-message-extractor.py        ├── unified-message-extractor.py
│   └── Claude only                     │   ├── ClaudeExtractor
├── extract-codex-session.py            │   ├── CodexExtractor
├── extract-gemini-session.py           │   └── GeminiExtractor
├── context-watcher (Claude)            ├── context-watcher (ALL LLMs)
├── codi-codex-watcher                  │   ├── Claude detection
└── codi-gemini-watcher                 │   ├── Codex detection
                                        │   └── Gemini detection

Document Control:

Created: December 29, 2025
Updated: January 28, 2026 (UNIFY extension track added)
Author: CODITECT Engineering Team
Version: 1.13.0
Review: Before starting parallel execution
Next Update: After H.8.8 Business Templates completion

Recent Updates:

v1.13.0: UNIFY extension track added - Unified LLM session extraction (/cx) and unified context watcher for Claude/Codex/Gemini (Jan 28, 2026)
v1.12.0: GEMINI extension track added - ADR-126, ADR-127, full framework parity with Codex (Jan 27, 2026)
v1.11.0: H.8.5.4 Cloud Sync COMPLETE, H.8.8 Business Templates added, CODX/OPS/ARCH extension tracks added (Jan 28, 2026)
v1.10.1: H.8 Ralph Wiggum - H.8.5.4 cloud sync for Ralph Wiggum tables COMPLETE - views, serializers, URLs (Jan 28)
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

Task Consolidation Log
Executive Summary
- Current Status (Jan 21, 2026)
- 🚨 Critical Path (Jan 12 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~~ (CONSOLIDATED)
- ~~A.8: Docker Image Heartbeat System~~ (CONSOLIDATED)
- 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)
- A.14: Database Architecture Migration (ADR-080 + ADR-103) 🟡
- A.15: Enhanced RBAC Permission System (ADR-092 Implementation) ✅
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
- B.13: Workstation Management UI (Gap Analysis - Critical)
- B.14: Container Sessions Completion (Gap Analysis - High)
- B.15: Admin License Management & Validation (Gap Analysis - High)
- B.16: Frontend Infrastructure (Gap Analysis - Medium)
- B.17: Enhanced RBAC Permission System UI (ADR-092 Implementation) 🆕
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)
- C.7: Context Watcher Process Detection Fix
- C.8: GCS Binary Distribution System
- C.9: Secured Distribution Portal (ADR-090)
- C.10: Email Infrastructure (Amazon SES)
- C.11: Update & Uninstall Mechanism ✅
- C.12: Time-Controlled Licensing System ✅
- C.13: Gitea Git Server Infrastructure (NEW - Jan 20, 2026)
- C.14: Git Lock Cleanup Automation (NEW - Jan 25, 2026)
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 🆕
- F.9: Architecture Deprecation (Rust CLI → Cloud Workstation) 🆕
- F.10: ADR Glossary Compliance 🆕
- F.11: Architectural Alignment Audit 🆕
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)
- H.5: Codanna Code Intelligence Integration (ADR-065, ADR-103) ✅
- H.6: RLM+Superpowers Framework Integration (ADR-074 to ADR-079)
- H.7: Self-Validating Ecosystem (ADR-080 to ADR-082)
- H.8: Ralph Wiggum Autonomous Agent Infrastructure (ADRs 108-112)
Track I: UI Components Library (V2 E002)
- I.1: MoE UI Agent System ✅ COMPLETE
- I.2: MoE UI Skills ✅ COMPLETE
- I.3: MoE UI Commands ✅ COMPLETE
- I.4: UI/UX Standards ✅ COMPLETE
- I.5: Architecture Decision Records ✅ COMPLETE
- I.6: Component Library (Proto-Code) ✅ COMPLETE
- I.7: Index and Activate ✅ COMPLETE
- I.8: Full Component Implementation (Remaining)
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)
- J.8: Auto-Session Preservation Architecture ✅ COMPLETE
- J.9: Export Pipeline Standardization ✅ COMPLETE
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)
Extension Track: CODX - Codex Integration (Added Jan 28, 2026)
- CODX.2: Codex Session Export Management (ADR-123)
- CODX.3: Codex Session Export Watcher (ADR-124)
- CODX.5: Export Filtering (Date Support)
Extension Track: OPS - Operations (Added Jan 28, 2026)
- OPS.2: Centralized Logging (ADR-125)
Extension Track: ARCH - Architecture (Added Jan 28, 2026)
- ARCH.3: Multi-LLM Portability (ADR-122)
Extension Track: GEMINI - Gemini Integration (Added Jan 27, 2026)
- GEMINI.2: Gemini Session Export Management (ADR-126)
- GEMINI.3: Gemini Session Export Watcher (ADR-127)
Extension Track: UNIFY - Unified LLM Session Management (Added Jan 28, 2026)
- UNIFY.1: Architecture & ADR
- UNIFY.2: Unified Extractor (/cx)
- UNIFY.3: Unified Watcher (codi-watcher)
- UNIFY.4: Documentation & Testing
- UNIFY Summary
Appendix C: Frontend Repository Reference
- Main Platform (coditect.ai)
- Auth Portal (auth.coditect.ai)
- DMS (dms.coditect.ai)

Task Consolidation Log​

Executive Summary​

Current Status (Jan 21, 2026)​

🚨 Critical Path (Jan 12 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 (CONSOLIDATED)​

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

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)​

A.14: Database Architecture Migration (ADR-080 + ADR-103) 🟡​

A.14.1: Phase 1 - Create platform.db (Non-Breaking) ~8h​

A.14.2: Phase 2 - Separate Local Schemas (Non-Breaking) ~12h​

A.14.3: Phase 3 - API Deployment (Non-Breaking) ~16h​

A.14.3.1: Platform API (Public, Read-Only)​

A.14.3.2: Customer API (Authenticated, Tenant-Scoped)​

A.14.4: Phase 4 - Deprecate Mixed Access (Breaking, 30-Day Notice) ~4h​

A.14.5: Cloud PostgreSQL Replication with Tenant Isolation ✅​

A.15: Enhanced RBAC Permission System (ADR-092 Implementation) ✅​

A.15.1: Permission Database Schema (Week 1)​

A.15.2: Permission Seeding and Role Mapping (Week 1-2)​

A.15.3: Permission Resolution Service (Week 2) ✅​

Task Consolidation Log

Executive Summary

Current Status (Jan 21, 2026)

🚨 Critical Path (Jan 12 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 (CONSOLIDATED)

A.8: Docker Image Heartbeat System (CONSOLIDATED)

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)

A.14: Database Architecture Migration (ADR-080 + ADR-103) 🟡

A.14.1: Phase 1 - Create platform.db (Non-Breaking) ~8h

A.14.2: Phase 2 - Separate Local Schemas (Non-Breaking) ~12h

A.14.3: Phase 3 - API Deployment (Non-Breaking) ~16h

A.14.3.1: Platform API (Public, Read-Only)

A.14.3.2: Customer API (Authenticated, Tenant-Scoped)

A.14.4: Phase 4 - Deprecate Mixed Access (Breaking, 30-Day Notice) ~4h

A.14.5: Cloud PostgreSQL Replication with Tenant Isolation ✅

A.15: Enhanced RBAC Permission System (ADR-092 Implementation) ✅

A.15.1: Permission Database Schema (Week 1)

A.15.2: Permission Seeding and Role Mapping (Week 1-2)

A.15.3: Permission Resolution Service (Week 2) ✅