ADR-055: Licensed Docker Container Schema Design

Status: Accepted Date: January 4, 2026 Decision Makers: MoE Panel (5 experts, 2 judges) Supersedes: None Related ADRs: ADR-005 (Workstations), ADR-009 (Multi-Tenant), ADR-014 (Commerce), ADR-024 (TenantModel), ADR-052/053 (Context Sync)

Executive Summary

This ADR documents the architectural decision to support Licensed Docker Containers for paying CODITECT customers. After rigorous Mixture-of-Experts (MoE) analysis with 3 domain expert analyzers and 2 compliance judges, we selected a Hybrid Approach (Option C) that balances architectural integrity with business pragmatism.

Key Decision: Implement a phased hybrid schema with:

New ContainerImage registry table (global catalog, like Product)
Extended Session model with deployment_type discriminator
Extended License model with container_seats quota

MoE Consensus Score: 35/40 (87.5%) - Grade A

Security Architecture: No Local Customer Installations

CRITICAL CONSTRAINT: CODITECT source code must never be distributed to customer environments.

┌─────────────────────────────────────────────────────────────┐
│  CODITECT Deployment Security Model                        │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  INTERNAL ONLY (CODITECT Development Team)                  │
│  ─────────────────────────────────────────                  │
│  • Local installation on CODITECT-owned hardware            │
│  • Hardware fingerprinting for trusted machines             │
│  • Full source code access for development                  │
│  • deployment_type = 'internal'                             │
│                                                              │
│  PAYING CUSTOMERS (No Source Code Access)                   │
│  ────────────────────────────────────────                   │
│  Option 1: Google Cloud Workstations                        │
│  • CODITECT-managed GCP environment                         │
│  • Pre-configured with CODITECT binaries                    │
│  • deployment_type = 'workstation'                          │
│                                                              │
│  Option 2: Licensed Docker Containers (This ADR)            │
│  • Pre-built images from CODITECT Artifact Registry         │
│  • Customer pulls and runs in their environment             │
│  • No source code - only compiled binaries                  │
│  • deployment_type = 'container' or 'kubernetes'            │
│                                                              │
│  SOURCE CODE PROTECTION                                      │
│  ──────────────────────                                      │
│  • Customers NEVER receive source code                      │
│  • All customer deployments use pre-built containers        │
│  • Container images built by CODITECT CI/CD pipeline        │
│  • License validation required on container startup         │
│                                                              │
└─────────────────────────────────────────────────────────────┘

This security model ensures:

IP Protection: CODITECT source code never leaves controlled environments
License Enforcement: Containers validate license on startup
Audit Trail: All container pulls logged and tracked
Revocation: Invalid licenses prevent container execution

Source Code Protection Mechanisms

Overview

CRITICAL ARCHITECTURE DECISION: CODITECT is NOT compiled to binary. Protection comes entirely from the controlled environment.

Protection Philosophy

"Protect the environment, not the file format."

Source code stays as Python + Markdown (required for Claude Code)

Protection = customers cannot escape Claude Code interface

No compilation, no obfuscation, no encryption at rest

Docker Container Protection

1. Locked Environment Architecture

CODITECT containers deploy the full framework with environment-based protection:

# CODITECT Licensed Container - Full Shell Access with Protected Framework
FROM python:3.11-slim

# Install development tools - FULL SHELL ACCESS for customers
RUN apt-get update && apt-get install -y \
    nodejs npm \
    zsh bash \
    git curl wget \
    vim nano \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

# Install Claude Code
RUN npm install -g @anthropic-ai/claude-code

# Install oh-my-zsh for nice developer experience
RUN sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended

# Create non-root user with full shell access
RUN useradd -m -s /bin/zsh -u 1000 developer

# ============================================================
# CODITECT FRAMEWORK PROTECTION - Owned by root, read-only
# ============================================================

# Install CODITECT framework as ROOT (not accessible to developer user)
COPY --chown=root:root coditect-core/ /opt/coditect/

# Make framework read-only and owned by root
RUN chmod -R 444 /opt/coditect/ && \
    find /opt/coditect -type d -exec chmod 555 {} \; && \
    chown -R root:root /opt/coditect/

# Symlink for Claude Code discovery (developer can read via Claude Code, not modify)
RUN ln -s /opt/coditect /home/developer/.coditect

# ============================================================
# USER ENVIRONMENT - Full access for customer development
# ============================================================

# Switch to developer user
USER developer
WORKDIR /home/developer/workspace

# Customer gets full shell - zsh by default, bash available
ENV SHELL=/bin/zsh
CMD ["/bin/zsh"]

Protection Model: Root-Owned Framework + Non-Root User

What Customer CAN Do	What Customer CANNOT Do
✅ Use zsh/bash shell	❌ Modify /opt/coditect (owned by root)
✅ Use vim, nano, git	❌ Delete framework files
✅ Use curl, wget for their work	❌ chown/chmod protected files
✅ Install packages in home dir	❌ Write to /opt/coditect
✅ Full Claude Code access	❌ Become root (no sudo)
✅ Read framework via Claude Code	❌ Mass-copy framework (no root)

Key Protection Mechanism:

/opt/coditect/          <- Owned by root:root, mode 444/555
├── agents/             <- Developer can READ (via Claude Code)
├── commands/           <- Developer can READ (via Claude Code)
├── skills/             <- Developer can READ (via Claude Code)
├── lib/                <- Developer can READ (via Claude Code)
└── scripts/            <- Developer can READ (via Claude Code)

/home/developer/        <- Owned by developer:developer
├── workspace/          <- Full read/write access
└── .coditect -> /opt/coditect  <- Symlink for discovery

Why This Works:

Framework files owned by root - non-root user cannot modify or delete
No sudo access - developer cannot escalate to root
File permissions (444) prevent writes even if somehow owned
Claude Code can read files to function, but user cannot mass-copy
Normal development workflow fully supported

2. Artifact Registry Access Control

Access Control Policy:

# IAM policy for customer image pulls
resource "google_artifact_registry_repository_iam_member" "customer_pull" {
  location   = "us-central1"
  repository = "coditect-licensed"
  role       = "roles/artifactregistry.reader"
  member     = "serviceAccount:${each.value.service_account}"

  condition {
    title       = "Licensed Images Only"
    description = "Restrict to licensed image tags"
    expression  = "resource.name.startsWith('coditect-core:') && resource.tag.matches('v[0-9]+\\\\.[0-9]+\\\\.[0-9]+')"
  }
}

3. Runtime Container Hardening

# Kubernetes SecurityContext
apiVersion: apps/v1
kind: Deployment
metadata:
  name: coditect-workload
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 65532
        fsGroup: 65532
        seccompProfile:
          type: RuntimeDefault

      containers:
      - name: coditect
        image: us-central1-docker.pkg.dev/coditect-citus-prod/coditect-licensed/coditect-core:v2.0.0
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]

Cloud Workstations Protection

IDENTICAL protection model as Docker: Full shell access + root-owned protected framework.

Cloud Workstations use the exact same container image as Docker deployments, ensuring consistent developer experience across both deployment options.

1. Same Protection Model - Root-Owned Framework

Protection Model (Same as Docker):

What Customer CAN Do	What Customer CANNOT Do
✅ Use zsh/bash shell	❌ Modify /opt/coditect (owned by root)
✅ Use vim, nano, git	❌ Delete framework files
✅ Use curl, wget for their work	❌ chown/chmod protected files
✅ Install packages in home dir	❌ Write to /opt/coditect
✅ Full Claude Code access	❌ Become root (no sudo)
✅ Read framework via Claude Code	❌ Mass-copy framework (no root)

2. Workstation Configuration

# gcloud workstations config
apiVersion: workstations.cloud.google.com/v1
kind: WorkstationConfig
metadata:
  name: coditect-customer-config
spec:
  # Use SAME container image as Docker deployments
  container:
    image: us-central1-docker.pkg.dev/coditect-citus-prod/coditect-licensed/coditect-core:v2.0.0
    # Framework protected via root ownership, NOT read-only filesystem
    # This allows customers to install packages, use dev tools, etc.

  # Persistent storage for customer work
  persistentDirectories:
    - gcePd:
        diskType: pd-balanced
        sizeGb: 200  # Customer workspace
        reclaimPolicy: RETAIN  # Keep customer work between sessions
      mountPath: /home/developer/workspace

  # Session management
  idleTimeout: 1800s  # 30 minutes idle timeout
  runningTimeout: 43200s  # 12 hours max session

  # Security hardening (GCP-managed)
  host:
    confidentialInstanceConfig:
      enableConfidentialCompute: true
    shieldedInstanceConfig:
      enableSecureBoot: true
      enableVtpm: true
      enableIntegrityMonitoring: true

3. GCP-Managed Additional Security (Workstations Only)

Cloud Workstations benefit from additional GCP-managed security layers not available in customer Docker environments:

Protection	Docker	Cloud Workstation	Notes
Root-owned framework	✅	✅	Same protection model
Full shell access	✅	✅	Same developer experience
Confidential Compute	❌	✅	GCP encrypts VM memory
Shielded VM	❌	✅	Secure boot, vTPM
Session timeouts	Customer-managed	✅ GCP-enforced	Auto-terminate idle
Audit logging	Customer-managed	✅ Cloud Logging	GCP captures all access
Network egress	Customer-managed	✅ VPC controls	Optional network restrictions

Key Insight: The core protection is identical (root-owned framework). Cloud Workstations add GCP-managed security layers, but the customer experience is the same.

3. Workstation Startup Validation

Combined Protection Matrix

Threat	Docker Protection	Workstation Protection	Defense Depth
Source code theft	Root-owned framework (444 perms)	Same + Confidential Compute	High
Framework modification	Non-root user, no sudo	Same + no sudo	High
Container escape	Non-root, seccomp	GCP-managed VM isolation	High
License bypass	Startup validation, heartbeats	Same + OAuth2	High
Data exfiltration	Customer-managed	VPC Service Controls	Medium/High
Unauthorized access	License validation	Same + GCP IAM	High
Framework copying	Root ownership blocks mass-copy	Same + audit logging	Medium

Implementation Checklist

Claude Code Integration Requirements

Critical Constraint: No Compilation - Environment Protection Only

CODITECT runs inside Claude Code, which works by reading files into the LLM context. This means:

┌─────────────────────────────────────────────────────────────┐
│  CODITECT FRAMEWORK - NO COMPILATION                        │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ALL components stay as source code:                        │
│                                                              │
│  • Python scripts (lib/, scripts/)     - Interpreted        │
│  • Markdown agents (agents/*.md)       - LLM-readable       │
│  • Markdown commands (commands/*.md)   - LLM-readable       │
│  • Markdown skills (skills/*/SKILL.md) - LLM-readable       │
│  • Configuration (*.json, *.yaml)      - Parseable          │
│  • CLAUDE.md                           - LLM-readable       │
│                                                              │
│  PROTECTION = LOCKED ENVIRONMENT, NOT FILE FORMAT           │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Why No Compilation

Claude Code's execution model requires readable files:

Compilation would break Claude Code - the LLM cannot read binary files.

Protection Architecture: Root-Owned Framework

Both Docker containers AND Cloud Workstations use the same protection model:

Unified Protection Summary

Component	Format	Protection Method
Python lib/	Python source	Environment lockdown
Python scripts/	Python source	Environment lockdown
Agents (152)	Markdown	Environment lockdown
Commands (181)	Markdown	Environment lockdown
Skills (219)	Markdown	Environment lockdown
Hooks (61)	Python/Bash	Environment lockdown
CLAUDE.md	Markdown	Environment lockdown
Config files	JSON/YAML	Environment lockdown

Key Architecture Decision

"Protect the environment, not the file format."

❌ No compilation (Rust, Python, or otherwise)

❌ No obfuscation or encryption

✅ All source stays readable (required for Claude Code)

✅ Protection = customers cannot escape Claude Code interface

✅ Same protection model for Docker AND Cloud Workstations

Context
Decision Drivers
Options Considered
MoE Analysis Process
Decision Outcome
Architecture Design
Implementation Plan
Consequences
Compliance Validation

Context

Business Requirement

CODITECT requires a secure distribution mechanism for paying customers that protects intellectual property while enabling flexible deployment options.

Primary Driver: Source Code Protection

Unlike traditional software distribution, CODITECT cannot offer local installations to customers because:

Source code exposure risk is unacceptable
License enforcement is difficult on customer-controlled machines
Support burden increases with uncontrolled environments

Solution: Container-Based Distribution

Licensed Docker containers provide:

Binary-Only Distribution: Pre-compiled code, no source exposure
License Validation: Container startup requires valid license
Controlled Updates: Customers pull new versions from CODITECT registry
Enterprise Flexibility: Customers deploy in their own K8s/Docker environments
Air-Gapped Support: Containers can be mirrored to private registries

Customer Deployment Options

Option	Environment	Managed By	Source Code
Cloud Workstations	GCP	CODITECT	Never exposed
Docker Containers	Customer Docker	Customer	Never exposed
Kubernetes	Customer K8s	Customer	Never exposed
Local Installation	N/A	N/A	Not available to customers

Technical Context

The existing database schema supports:

License Management: 3 models (License, Session, Activation)
Workstation Broker: 6 models per ADR-005
Multi-Tenant Isolation: django-multitenant with TenantModel
Commerce: Product, Order, Entitlement per ADR-014

Problem Statement

How should the database schema be extended to support licensed Docker containers while:

Maintaining source code protection

Enforcing license validation on container startup

Preserving multi-tenant isolation guarantees

Tracking container deployments for audit and billing

Decision Drivers

Driver	Weight	Description
Multi-Tenant Isolation	Critical	Must maintain tenant isolation per ADR-009/024
Schema Normalization	High	Avoid schema bloat and nullable field pollution
Migration Safety	High	Zero risk to existing production data
Future Extensibility	High	Support K8s, Swarm, Compose variations
Time to Market	Medium	Balance speed with architectural quality
Operational Simplicity	Medium	Minimize new operational overhead

Options Considered

Option A: New `containers` Django App (3 New Tables)

Create dedicated Django app with:

ContainerImage - Docker image registry (global)
ContainerActivation(TenantModel) - Per-tenant container instances
ContainerPullCredential(TenantModel) - Registry access tokens

Option B: Extend Existing Models

Add fields to existing models:

Session.deployment_type, Session.container_id
License.container_seats, License.allow_docker
No new tables required

Option C: Hybrid Approach (Selected)

Balanced design:

New: ContainerImage registry table (global catalog)
Extend: Session with deployment_type discriminator
Extend: License with container_seats quota

MoE Analysis Process

Phase 1: Expert Analyzer Panel

Three domain experts analyzed all options in parallel:

Analyzer Scores Summary

Expert	Option A	Option B	Option C
Database Architect	8.5/10	5.5/10	7.5/10
Multi-Tenant Architect	9.5/10	6.5/10	8.5/10
Senior Architect	7.5/10	5.0/10	8.5/10
Average	8.5/10	5.7/10	8.2/10

Phase 2: Judge Panel Scoring

Two compliance judges applied CODITECT v4 40/40 scoring:

Judge Panel 40/40 Scores

Category	Max	Option A	Option B	Option C
Architectural Integrity	10	9.5	5.0	8.5
Security and Isolation	10	10.0	6.0	9.0
Implementation Quality	10	8.0	5.5	8.5
Business Value	10	7.5	6.0	9.0
TOTAL	40	35.0	22.5	35.0

Judge Recommendations

Judge	Recommendation	Confidence
ADR Compliance Judge	Option A	High (90%)
CODITECT Standards Judge	Option C	High (87.5%)

Tie Resolution: Option C selected due to superior Business Value score (9.0 vs 7.5) while matching Option A on total score.

Decision Outcome

Selected Option: C (Hybrid Approach)

CODITECT Grade: A (35/40 = 87.5%)

Rationale

Business Pragmatism: Phase 1 delivers customer value in 1 week vs 2-3 weeks for Option A
Architectural Equivalence: Final state achieves same clean separation as Option A
Risk Mitigation: Validates container demand before major architectural investment
Time to Market: 50% faster initial delivery without sacrificing long-term quality
CODITECT Compliance: Achieves 40/40 standards in Phase 2

Why Not Option A?

Option A scored equally on architecture (35/40) but lower on Business Value (7.5 vs 9.0). For a revenue-generating feature, faster time to market with guaranteed architectural cleanup (Phase 2) is preferable to slower perfect implementation.

Why Not Option B?

Option B failed on multiple criteria:

22.5/40 total score (Grade C+)
Violates Separation of Concerns (ADR-054)
Creates technical debt requiring future refactoring
Schema pollution with nullable container fields on Session model

Architecture Design

System Context (C1)

Container Architecture (C2)

Database Schema (ERD)

License Validation Workflow

Deployment Type Discriminator Pattern

Deployment Type Access Control:

Type	Who Can Use	Source Code	License Required
`internal`	CODITECT team only	Yes	No (dev license)
`workstation`	Paying customers	No	Yes
`container`	Paying customers	No	Yes
`kubernetes`	Paying customers	No	Yes

Implementation Plan

Phase 1: Quick Win (Week 1)

Goal: Deliver Docker container access to customers immediately

Migrations:

# licenses/migrations/0005_add_container_fields.py
class Migration(migrations.Migration):
    operations = [
        migrations.AddField(
            model_name='license',
            name='container_seats',
            field=models.PositiveIntegerField(default=0),
        ),
        migrations.AddField(
            model_name='license',
            name='allow_docker',
            field=models.BooleanField(default=False),
        ),
        migrations.AddField(
            model_name='session',
            name='deployment_type',
            field=models.CharField(
                max_length=20,
                choices=[
                    # INTERNAL: CODITECT team only (has source code access)
                    ('internal', 'Internal Development'),
                    # CUSTOMER OPTIONS: No source code, pre-built containers only
                    ('workstation', 'Cloud Workstation'),
                    ('container', 'Docker Container'),
                    ('kubernetes', 'Kubernetes Pod'),
                ],
                default='workstation',  # Customers default to managed workstation
            ),
        ),
        migrations.AddField(
            model_name='session',
            name='container_id',
            field=models.CharField(max_length=64, blank=True),
        ),
        migrations.AddField(
            model_name='session',
            name='container_image_id',
            field=models.ForeignKey(
                'containers.ContainerImage',
                null=True, blank=True,
                on_delete=models.PROTECT,
            ),
        ),
    ]

Deployment Type Validation:

# licenses/models.py
class Session(TenantModel):
    DEPLOYMENT_CHOICES = [
        ('internal', 'Internal Development'),
        ('workstation', 'Cloud Workstation'),
        ('container', 'Docker Container'),
        ('kubernetes', 'Kubernetes Pod'),
    ]

    def clean(self):
        # Internal deployment only for CODITECT team
        if self.deployment_type == 'internal':
            if not self.user.is_coditect_staff:
                raise ValidationError(
                    "Internal deployment type reserved for CODITECT team"
                )

        # Container/K8s requires container_image
        if self.deployment_type in ('container', 'kubernetes'):
            if not self.container_image_id:
                raise ValidationError(
                    "Container deployment requires container_image"
                )
            if not self.license.allow_docker:
                raise ValidationError(
                    "License does not permit container deployment"
                )

Phase 2: Architectural Excellence (Weeks 2-4)

Goal: Achieve full 40/40 CODITECT compliance

New Models (Phase 2):

# containers/models.py
class ContainerImage(models.Model):
    """
    Licensed Docker image registry.
    Global catalog with tenant-scoped visibility.
    """
    id = models.UUIDField(primary_key=True, default=uuid.uuid4)

    # Image identification
    image_name = models.CharField(max_length=255)
    image_tag = models.CharField(max_length=100)
    image_digest = models.CharField(max_length=100, unique=True)

    # Registry location
    registry_url = models.CharField(max_length=500)

    # License requirements
    minimum_tier = models.CharField(max_length=20, choices=[
        ('starter', 'Starter'),
        ('professional', 'Professional'),
        ('enterprise', 'Enterprise'),
    ])

    # Feature flags
    features = models.JSONField(default=list)

    # Visibility (public catalog or private to tenant)
    visibility = models.CharField(max_length=20, choices=[
        ('public', 'Public'),
        ('private', 'Private'),
    ], default='public')
    owner_tenant = models.ForeignKey(
        'tenants.Tenant',
        null=True, blank=True,
        on_delete=models.CASCADE,
    )

    # Metadata
    is_active = models.BooleanField(default=True)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        db_table = 'container_images'
        indexes = [
            models.Index(fields=['image_name', 'image_tag']),
            models.Index(fields=['visibility', 'is_active']),
        ]

Consequences

Positive

Customer Value: Docker container licensing available in Week 1
Architectural Integrity: Phase 2 achieves 40/40 CODITECT compliance
Multi-Tenant Isolation: TenantModel pattern preserved
Future Extensibility: Easy to add K8s, Swarm, Compose support
Revenue Growth: Unlocks new licensing tier for containers

Negative

Temporary Complexity: Phase 1 introduces fields that Phase 2 refactors
Migration Coordination: Two-phase deployment requires careful orchestration
Documentation Burden: Must document both Phase 1 and Phase 2 states

Risks and Mitigations

Risk	Probability	Impact	Mitigation
Phase 1 data loss during Phase 2 migration	Low	High	Automated backup before migration
Customer confusion during transition	Medium	Medium	Clear communication and deprecation timeline
Container quota bypass attack	Low	High	Redis atomic counting with Lua scripts
Source code extraction from container	Low	Critical	Multi-layer obfuscation, no debug symbols
License bypass in air-gapped environment	Medium	High	Time-limited offline tokens, periodic validation

Container Startup License Validation

Every CODITECT container must validate its license before allowing operation:

Container Environment Variables:

Variable	Required	Description
`CODITECT_LICENSE_KEY`	Yes	License key for validation
`CODITECT_API_URL`	No	API endpoint (default: api.coditect.ai)
`CODITECT_OFFLINE_TOKEN`	No	Pre-signed token for air-gapped mode

Air-Gapped Mode:

For environments without internet access, customers can request time-limited offline tokens:

Customer requests offline token via web dashboard
Token is cryptographically signed with expiration (max 30 days)
Container validates signature locally using embedded public key
Token cannot be renewed without internet access

Compliance Validation

ADR Alignment

ADR	Requirement	Compliance
ADR-005	Workstation broker pattern	Session extension follows same pattern
ADR-009	Multi-tenant architecture	TenantModel for ContainerImage (private)
ADR-014	Commerce product catalog	ContainerImage mirrors Product pattern
ADR-024	TenantModel enforcement	All tenant-scoped models use TenantModel
ADR-052	Intent-aware context	Container sessions track context sync
ADR-053	Cloud sync architecture	Container activations sync to cloud

40/40 Quality Gate

Category	Score	Evidence
Architectural Integrity	8.5/10	Hybrid approach preserves SoC
Security and Isolation	9.0/10	TenantModel + Redis atomic counting
Implementation Quality	8.5/10	Phased migration with rollback
Business Value	9.0/10	Week 1 delivery + long-term quality
TOTAL	35/40	Grade A (87.5%)

Appendix

A. MoE Panel Composition

Analyzers:

database-architect - Schema design and query optimization
multi-tenant-architect - Tenant isolation patterns
senior-architect - System integration and API design

Judges:

adr-compliance-specialist - ADR standards and quality scoring
coditect-adr-specialist - 40/40 CODITECT methodology

B. Option Comparison Matrix

Criterion	Option A	Option B	Option C
Schema Normalization	Excellent	Poor	Good
Query Performance	Good	Excellent	Very Good
Migration Complexity	High	Low	Medium
Future Extensibility	Excellent	Poor	Very Good
Multi-Tenant Compliance	Excellent	Good	Very Good
Time to Market	2-3 weeks	1 week	1 week Phase 1
Technical Debt	Zero	High	Low
CODITECT Grade	A- (88%)	C+ (70%)	A (87.5%)

database-schema.md - Complete schema reference
database-architecture.md - Architecture overview
database-integration-guide.md - Integration patterns

Document Version: 1.5.0 Created: January 4, 2026 Revised: January 4, 2026 Author: MoE Panel (CODITECT AI) Review Status: Accepted Next Review: March 2026

Revision History:

Version	Date	Changes
1.0.0	2026-01-04	Initial MoE analysis and decision
1.1.0	2026-01-04	Added security model: no customer local installations, source code protection, container startup validation
1.2.0	2026-01-04	Added comprehensive Source Code Protection Mechanisms section with Docker multi-stage builds, Artifact Registry IAM, VPC Service Controls, Cloud Workstations configuration
1.3.0	2026-01-04	Added Claude Code Integration Requirements section clarifying that framework components (agents, commands, skills) must remain as readable markdown; protection comes from controlled environment, not file compilation
1.4.0	2026-01-04	MAJOR REVISION: Removed all Rust/binary compilation references. Clarified that NO compilation occurs - protection is 100% environment-based. Updated Dockerfile to show full shell access + root-owned framework approach
1.5.0	2026-01-04	UNIFIED MODEL: Updated Cloud Workstations section to use IDENTICAL protection model as Docker (full shell access + root-owned framework). Both deployment options now share same container image and developer experience. Updated diagrams and protection matrices for consistency

Executive Summary​

Security Architecture: No Local Customer Installations​

Source Code Protection Mechanisms​

Overview​

Protection Philosophy​

Docker Container Protection​

1. Locked Environment Architecture​

2. Artifact Registry Access Control​

3. Runtime Container Hardening​

Cloud Workstations Protection​

1. Same Protection Model - Root-Owned Framework​

2. Workstation Configuration​

3. GCP-Managed Additional Security (Workstations Only)​

3. Workstation Startup Validation​

Combined Protection Matrix​

Implementation Checklist​

Claude Code Integration Requirements​

Critical Constraint: No Compilation - Environment Protection Only​

Why No Compilation​

Protection Architecture: Root-Owned Framework​

Unified Protection Summary​

Key Architecture Decision​

Table of Contents​

Context​

Business Requirement​

Customer Deployment Options​

Technical Context​

Problem Statement​

Decision Drivers​

Options Considered​

Option A: New containers Django App (3 New Tables)​

Option B: Extend Existing Models​

Option C: Hybrid Approach (Selected)​

MoE Analysis Process​

Phase 1: Expert Analyzer Panel​

Analyzer Scores Summary​

Phase 2: Judge Panel Scoring​

Judge Panel 40/40 Scores​

Judge Recommendations​

Decision Outcome​

Selected Option: C (Hybrid Approach)​

Rationale​

Why Not Option A?​

Why Not Option B?​

Architecture Design​

System Context (C1)​

Container Architecture (C2)​

Database Schema (ERD)​

License Validation Workflow​

Deployment Type Discriminator Pattern​

Implementation Plan​

Phase 1: Quick Win (Week 1)​

Phase 2: Architectural Excellence (Weeks 2-4)​

Consequences​

Positive​

Negative​

Risks and Mitigations​

Container Startup License Validation​

Compliance Validation​

ADR Alignment​

40/40 Quality Gate​

Appendix​

A. MoE Panel Composition​

B. Option Comparison Matrix​

C. Related Documentation​