Technology Stack Roadmap

The AEEF reference implementations currently ship complete three-tier coverage for TypeScript (Express), Python (FastAPI), and Go (Chi). These three stacks were chosen as launch targets because they represent the dominant language families in AI-assisted engineering today and cover the widest range of team profiles: startups, data/ML organizations, and infrastructure-heavy shops.

This page maps the roadmap for additional stacks. Each candidate stack is evaluated against four criteria:

1. AI tool readiness -- How well do current AI coding assistants (Copilot, Claude, Cursor, Windsurf) perform with this language and framework?
2. Enterprise adoption -- How large is the production footprint that would benefit from AEEF governance?
3. Convention density -- Does the ecosystem have strong conventions that make AI-generated code predictable and auditable?
4. AEEF standard coverage -- Can all 16 PRD-STDs be meaningfully enforced, or does the stack only support a subset?

The roadmap is ordered by priority. Community contributions are welcome for any stack at any time -- you do not need to wait for a priority slot to open.

---

1. Current Stack Coverage

The following table summarizes what exists today across all three implementation tiers.

Stack	Tier 1 (Quick Start)	Tier 2 (Transformation)	Tier 3 (Production)	Status
TypeScript / Express	Yes	Yes	Yes	Complete
Python / FastAPI	Yes	Yes	Yes	Complete
Go / Chi	Yes	Yes	Yes	Complete

Each stack includes:

• Application scaffolding with health endpoints, structured logging, and graceful shutdown
• Linter and formatter configuration mapped to AEEF quality standards
• Security scanning rules (Semgrep custom rules plus language-native SAST)
• Mutation testing configuration for code coverage validation
• Multi-stage CI/CD pipeline (7-9 jobs depending on tier)
• Agent SDLC contracts, prompts, and handoff definitions (Tier 2+)
• Monitoring, incident response, and sovereign overlays (Tier 3)
• CLAUDE.md files with stack-specific AI coding instructions

The three current stacks collectively produce ~310 files across approximately 130 (Quick Start), 130 (Transformation), and 130 (Production) per-tier repositories, plus 38 standalone config pack files.

For the complete mapping of files to standards, see the Standards Coverage Matrix.

---

2. Priority 1: Java / Spring Boot

Rationale

Java holds the highest GitHub Copilot acceptance rate of any language at 61%, meaning AI suggestions are accepted without modification more often than in any other ecosystem. This is a direct consequence of Java's verbose, convention-heavy syntax: when there is only one right way to write a Spring Boot controller or JPA repository, AI tools get it right on the first try.

Java dominates in precisely the environments where AEEF governance delivers the most value: regulated financial services, insurance, government IT, and large-scale enterprise backends. These organizations already have compliance requirements, audit trails, and multi-team coordination needs that map directly to AEEF's 16 production standards.

AI Readiness Assessment

• Training corpus: Massive. Java has been a top-3 language on GitHub for over a decade, producing billions of lines of open-source code that train every major AI model.
• Convention strength: Excellent. Spring Boot enforces strong conventions for dependency injection, configuration, and layered architecture. AI tools generate highly predictable code.
• IDE integration: IntelliJ IDEA has deep Copilot and AI Assistant integration. JetBrains AI Assistant provides Java-specific suggestions.
• Acceptance rate: 61% Copilot acceptance rate (highest measured), indicating AI generates correct code without manual editing in the majority of cases.

Framework and Toolchain

Component	Choice	Notes
Framework	Spring Boot 3.x	Latest LTS line; virtual threads (Project Loom) for reactive performance without reactive complexity
Security	Spring Security 6.x	OAuth2, JWT, CORS, CSRF built-in; maps directly to PRD-STD-003
Data	Spring Data JPA + Hibernate	Repository pattern with audit logging; maps to PRD-STD-012 compliance
Build	Maven 3.9+ or Gradle 8.x	Both supported; Maven as primary due to enterprise prevalence
Java version	Java 21 LTS	Virtual threads, pattern matching, sealed classes

Linting and Static Analysis

Java has the richest static analysis ecosystem of any language. The AEEF Java stack will ship configurations for:

• Checkstyle -- Code style enforcement with a custom AEEF ruleset derived from Google Java Style. Enforces naming conventions, import ordering, Javadoc requirements, and structural patterns. Maps to PRD-STD-006 (Technical Debt).
• SpotBugs -- Bytecode-level bug detection covering null pointer issues, resource leaks, concurrency bugs, and security vulnerabilities. The findsecbugs plugin adds 140+ security-specific detectors. Maps to PRD-STD-003 (Security) and PRD-STD-006.
• PMD -- Source-level analysis covering unused code, overcomplicated expressions, copy-paste detection (CPD), and design violations. Maps to PRD-STD-006.
• Error Prone -- Google's compile-time bug checker integrated as a Java compiler plugin. Catches common mistakes that pass compilation but fail at runtime. Includes over 500 built-in checks.

Configuration files will be provided for all four tools with AEEF-specific rulesets that can be applied independently or as a combined suite.

Testing Strategy

Layer	Tool	Purpose
Unit	JUnit 5 + AssertJ	Standard Java unit testing with fluent assertions
Mocking	Mockito 5	Mock dependencies for isolated unit tests
Integration	Testcontainers	Spin up real Postgres, Redis, Kafka in Docker for integration tests
Mutation	PIT (pitest)	Mutation testing to validate test suite effectiveness; maps to PRD-STD-003
Contract	Spring Cloud Contract or Pact	Consumer-driven contract testing for microservice boundaries
Architecture	ArchUnit	Enforce architectural rules as tests (e.g., no controller accessing repository directly)

ArchUnit is particularly valuable for AEEF because it allows teams to encode architectural decisions as executable tests. For example:

@ArchTest
static final ArchRule controllers_should_not_access_repositories =
    noClasses().that().resideInAPackage("..controller..")
        .should().accessClassesThat().resideInAPackage("..repository..");

@ArchTest
static final ArchRule all_services_must_be_annotated =
    classes().that().resideInAPackage("..service..")
        .should().beAnnotatedWith(Service.class);

CI/CD Pipeline

The Java pipeline will follow the same multi-stage pattern used in the existing stacks, adapted for Maven/Gradle:

Tier 1 (Quick Start) -- 5 stages:

1. compile -- mvn compile with Error Prone enabled
2. lint -- Checkstyle + PMD checks
3. test -- mvn test with JUnit 5, coverage via JaCoCo
4. security-scan -- SpotBugs with findsecbugs, Semgrep Java rules
5. build -- mvn package producing executable JAR

Tier 2 (Transformation) -- 9 stages:

1. compile -- mvn compile with Error Prone
2. checkstyle -- Checkstyle with AEEF ruleset
3. spotbugs -- SpotBugs + findsecbugs
4. pmd -- PMD with AEEF ruleset
5. unit-test -- JUnit 5 with JaCoCo coverage (80% minimum)
6. integration-test -- Testcontainers-based integration tests
7. mutation-test -- PIT mutation testing (70% mutation score minimum)
8. security-scan -- Semgrep Java rules + OWASP Dependency-Check
9. architecture-test -- ArchUnit rules enforcing layer boundaries
10. build -- mvn package -DskipTests (tests already passed)

Tier 3 (Production) -- adds:

• SBOM generation via CycloneDX Maven plugin
• Container image build with Jib (distroless base images)
• Deployment manifest generation (Kubernetes)
• OWASP Dependency-Check with NVD API integration
• License compliance scan via license-maven-plugin
• Provenance attestation

Security Rules

The Java Semgrep ruleset will include custom rules covering:

• SQL injection via string concatenation in JPA queries
• Insecure deserialization patterns (ObjectInputStream)
• Hardcoded credentials in Spring configuration
• Missing @Secured or @PreAuthorize on controller methods
• Disabled CSRF protection in Spring Security configuration
• Use of Math.random() for security-sensitive operations
• Missing input validation on @RequestBody parameters
• Insecure TLS/SSL configuration
• XML External Entity (XXE) injection via unmarshalling

AEEF Standards Mapping

All 16 PRD-STDs are applicable to Java/Spring Boot, with particular strength in:

Standard	Java/Spring Fit	Implementation
PRD-STD-001 (Prompt Engineering)	Strong	CLAUDE.md with Spring Boot conventions, Copilot instructions
PRD-STD-003 (Security)	Excellent	Spring Security + SpotBugs findsecbugs + Semgrep + OWASP DC
PRD-STD-006 (Technical Debt)	Excellent	Checkstyle + PMD + Error Prone + ArchUnit
PRD-STD-008 (Dependencies)	Excellent	Maven Enforcer, OWASP Dependency-Check, license-maven-plugin
PRD-STD-010 (Deployment)	Excellent	Spring Boot Actuator, Jib, Kubernetes manifests
PRD-STD-012 (Compliance)	Excellent	Spring Data JPA audit logging, CycloneDX SBOM, ArchUnit

Estimated Effort

• Files: ~150 across all three tiers
• Shared artifacts: 25-30 (agent SDLC contracts, schemas, policies reusable from existing stacks)
• Stack-specific artifacts: ~120 (application code, configs, CI pipelines, Semgrep rules, tests)
• Implementation time: 3-4 weeks for an experienced Spring Boot developer familiar with AEEF

Target Audience

• Banks and financial services (Spring Boot is the de facto standard)
• Insurance companies running on Java backends
• Government IT systems with Java mandates
• Large enterprises with existing Spring/Java investment
• Organizations migrating from Java EE/Jakarta EE to Spring Boot

---

3. Priority 2: Rust

Rationale

Rust has the highest AI tool adoption rate of any systems language: 89% of Rust developers have tried AI coding tools, and 78% actively use them in their daily workflow. This is remarkable for a language that AI tools historically struggled with due to Rust's ownership model and borrow checker. Recent improvements in AI models (particularly Claude and GPT-4) have dramatically improved Rust code generation quality.

Rust is gaining rapid adoption in infrastructure (cloud-native tooling, databases, proxies), fintech (high-frequency trading, blockchain), and security-critical systems where memory safety guarantees provide compliance advantages.

AI Readiness Assessment

• Training corpus: Good and improving. Rust's GitHub presence has grown 40%+ year-over-year. The Rust ecosystem's strong documentation culture means AI tools have high-quality training data.
• Convention strength: Excellent. Cargo enforces project structure. clippy enforces idiomatic patterns. rustfmt eliminates style debates. AI tools generate code that compiles and passes lints at increasing rates.
• Ownership model: This is both Rust's challenge and advantage for AEEF. The borrow checker provides compile-time safety guarantees that eliminate entire classes of bugs -- reducing the need for runtime security scanning while increasing the value of static analysis.
• Acceptance rate: Lower than Java/Python for Copilot (~40-45%), but Claude and Cursor show significantly higher accuracy with Rust, especially for idiomatic patterns.

Framework and Toolchain

Component	Choice	Notes
Framework	Axum (primary), Actix-web (alternative)	Axum chosen for tokio alignment and tower middleware ecosystem
Runtime	Tokio	Async runtime; industry standard
Serialization	serde + serde_json	Universal Rust serialization
Database	SQLx (compile-time checked queries)	Type-safe SQL without ORM overhead
Configuration	config crate + dotenvy	12-factor configuration
Logging	tracing + tracing-subscriber	Structured logging with span context

Axum is preferred over Actix-web because:

1. It uses the tower middleware ecosystem, which is shared with the broader Rust networking stack (tonic, hyper, etc.)
2. It has stronger AI tool support due to its simpler type signatures
3. It aligns with the tokio runtime without the actor model complexity of Actix

Linting and Static Analysis

Rust's static analysis story is uniquely strong because the compiler itself catches most bugs at compile time. The AEEF Rust stack layers additional analysis on top:

• Clippy -- The official Rust linter with 700+ lints organized into categories (correctness, style, complexity, performance, pedantic). The AEEF configuration enables the pedantic group with targeted allows for pragmatic exceptions. Maps to PRD-STD-006.
• rustfmt -- Deterministic formatting. The AEEF configuration ships a rustfmt.toml that enforces consistent style. No configuration debates.
• cargo-audit -- Checks dependencies against the RustSec Advisory Database. Maps to PRD-STD-008.
• cargo-deny -- License compliance, duplicate dependency detection, and advisory checks in a single tool. Maps to PRD-STD-008 and PRD-STD-012.
• Semgrep Rust rules -- Custom rules for unsafe block usage patterns, panic in library code, unwrap in production paths, and cryptographic misuse.

Testing Strategy

Layer	Tool	Purpose
Unit	Built-in #[test]	Rust's built-in test framework; no external dependency needed
Integration	Built-in tests/ directory	Cargo's integration test convention
Property	proptest	Property-based testing for edge case discovery
Mutation	cargo-mutants	Mutation testing; newer but functional
Fuzzing	cargo-fuzz (libFuzzer)	Fuzz testing for parsing and deserialization code
Benchmarks	criterion	Statistical benchmarking for performance-sensitive code

Rust's testing story is particularly strong because tests are first-class in the language and build system. No external test runner configuration is needed. The AEEF configuration adds:

# Cargo.toml [profile.test] additions
[profile.test]
opt-level = 0        # Fast compilation for tests
debug = true         # Full debug info for test failures

# Coverage via cargo-llvm-cov
[workspace.metadata.coverage]
branch = true
fail-under = 80.0

CI/CD Pipeline

Tier 1 (Quick Start) -- 5 stages:

1. check -- cargo check (fast compilation verification)
2. clippy -- cargo clippy -- -D warnings
3. test -- cargo test with coverage via cargo-llvm-cov
4. audit -- cargo audit + cargo deny check
5. build -- cargo build --release

Tier 2 (Transformation) -- 8 stages:

1. check -- cargo check
2. fmt -- cargo fmt --check (formatting verification)
3. clippy -- cargo clippy with AEEF pedantic config
4. unit-test -- cargo test --lib with coverage (80% minimum)
5. integration-test -- cargo test --test '*' with Testcontainers
6. mutation-test -- cargo mutants (60% mutation score minimum, lower than other stacks due to tool maturity)
7. security -- cargo audit + cargo deny + Semgrep Rust rules
8. build -- cargo build --release with LTO enabled

Tier 3 (Production) -- adds:

• SBOM generation via cargo cyclonedx
• Container image build with multi-stage Dockerfile (scratch base image)
• cargo deny license compliance with approved-license allowlist
• Fuzz testing targets for critical parsing code
• Provenance attestation

Security Rules

Rust's memory safety eliminates buffer overflows, use-after-free, and data races at compile time. The AEEF Semgrep rules focus on the remaining attack surface:

• unsafe block usage without safety documentation comments
• unwrap() and expect() in non-test code paths (panic risk in production)
• Hardcoded secrets in source code
• Missing TLS certificate verification
• SQL injection via format strings in raw SQL queries
• Cryptographic operations using deprecated algorithms
• Missing input validation on deserialized user input
• Panicking in FFI boundary code

AEEF Standards Mapping

Standard	Rust Fit	Implementation
PRD-STD-003 (Security)	Excellent	Compile-time memory safety + cargo-audit + Semgrep
PRD-STD-006 (Technical Debt)	Excellent	Clippy pedantic + compiler warnings-as-errors
PRD-STD-008 (Dependencies)	Excellent	cargo-deny (licenses, advisories, duplicates)
PRD-STD-009 (Performance)	Excellent	criterion benchmarks + release profile optimization
PRD-STD-010 (Deployment)	Strong	Minimal container images (scratch base), fast startup

Estimated Effort

• Files: ~120 across all three tiers
• Shared artifacts: 25-30 (reusable from existing stacks)
• Stack-specific artifacts: ~90 (application code, Cargo configs, CI pipelines, Semgrep rules)
• Implementation time: 3-4 weeks for an experienced Rust developer

Target Audience

• Infrastructure and platform engineering teams
• Fintech (high-frequency trading systems, payment processors)
• Blockchain and Web3 companies
• Security-focused organizations (aerospace, defense)
• Teams replacing C/C++ with memory-safe alternatives

---

4. Priority 3: .NET / C#

Rationale

Microsoft has committed to making Visual Studio 2026 an "AI-native IDE," and Semantic Kernel -- Microsoft's AI orchestration framework -- is .NET-first. The .NET ecosystem benefits from the deepest AI tooling investment of any platform vendor. Combined with a massive enterprise installed base (particularly in Windows-centric organizations and Azure-heavy deployments), .NET represents a high-value AEEF target.

AI Readiness Assessment

• Training corpus: Excellent. C# is consistently a top-5 language on GitHub, and Microsoft's investment in AI means the training data includes high-quality official samples and documentation.
• Convention strength: Excellent. .NET enforces project structure via .csproj files, namespaces mirror directory structure, and the framework provides strong conventions for dependency injection, configuration, and middleware.
• IDE integration: Visual Studio 2026 AI features, GitHub Copilot deep integration, JetBrains Rider with AI Assistant. The .NET ecosystem has more IDE-integrated AI tooling than any other platform.
• Acceptance rate: ~55% Copilot acceptance rate, second only to Java among strongly-typed languages.

Framework and Toolchain

Component	Choice	Notes
Framework	ASP.NET Core 9	Latest LTS-adjacent release with native AOT, minimal APIs
ORM	Entity Framework Core 9	Code-first migrations, audit logging interceptors
Auth	ASP.NET Core Identity + JWT Bearer	Built-in identity with JWT for API scenarios
Build	.NET SDK (dotnet CLI)	Cross-platform build, no Visual Studio dependency
Configuration	IConfiguration + Options pattern	Hierarchical configuration with validation
Logging	Microsoft.Extensions.Logging + Serilog	Structured logging with sink flexibility

Linting and Static Analysis

• .NET Analyzers -- Built into the SDK. The AEEF configuration enables AnalysisLevel = latest-All for maximum coverage. These analyzers cover API design, globalization, performance, reliability, security, and usage patterns. Maps to PRD-STD-006.
• StyleCop.Analyzers -- Code style enforcement integrated as Roslyn analyzers. Runs at compile time, no separate tool needed. The AEEF configuration ships a .editorconfig and stylecop.json with standardized rules.
• SonarAnalyzer.CSharp -- SonarSource's C# analyzer covering bugs, vulnerabilities, code smells, and security hotspots. Can run standalone or as part of SonarQube/SonarCloud.
• Microsoft.CodeAnalysis.NetAnalyzers -- Security-focused analyzers covering SQL injection, XSS, path traversal, and cryptographic weaknesses.
• Roslynator -- 500+ additional Roslyn analyzers and refactorings for code quality.

A key advantage of .NET's analyzer ecosystem is that all tools run as Roslyn analyzers integrated into the compilation pipeline. There is no separate linting step -- violations are reported as compiler warnings or errors, ensuring they cannot be bypassed.

Testing Strategy

Layer	Tool	Purpose
Unit	xUnit	.NET standard test framework with parallel execution
Mocking	NSubstitute	Clean mocking syntax without lambda complexity
Integration	WebApplicationFactory + Testcontainers	In-process API testing + real database containers
Mutation	Stryker.NET	Production-quality mutation testing for .NET
Architecture	NetArchTest	ArchUnit equivalent for .NET
Snapshot	Verify	Snapshot testing for complex object comparison

Stryker.NET is a particularly strong fit because it is the most mature mutation testing tool outside of Java's PIT. It supports full C# syntax mutation, real-time HTML reporting, and CI integration with threshold enforcement.

CI/CD Pipeline

Tier 1 (Quick Start) -- 5 stages:

1. restore -- dotnet restore (dependency resolution)
2. build -- dotnet build --no-restore -warnaserror (compilation with analyzers)
3. test -- dotnet test with Coverlet coverage collection
4. security -- dotnet list package --vulnerable + Semgrep C# rules
5. publish -- dotnet publish producing deployment artifact

Tier 2 (Transformation) -- 9 stages:

1. restore -- dotnet restore
2. build -- dotnet build -warnaserror with all analyzers enabled
3. format-check -- dotnet format --verify-no-changes
4. unit-test -- dotnet test --filter Category=Unit with Coverlet (80% minimum)
5. integration-test -- dotnet test --filter Category=Integration with Testcontainers
6. mutation-test -- Stryker.NET with 70% mutation score threshold
7. security-scan -- Semgrep C# rules + dotnet list package --vulnerable
8. architecture-test -- NetArchTest rules
9. publish -- dotnet publish with trimming enabled

Tier 3 (Production) -- adds:

• SBOM generation via CycloneDX .NET tool
• Container build with .NET's built-in container support (dotnet publish --os linux --arch x64 /t:PublishContainer)
• NuGet license compliance audit
• Native AOT compilation option for minimal container footprint
• Provenance attestation

Security Rules

The AEEF Semgrep C# ruleset will cover:

• SQL injection via string interpolation in EF Core raw queries
• Missing [ValidateAntiForgeryToken] on POST actions
• Hardcoded connection strings or credentials
• Disabled SSL/TLS certificate validation
• Insecure deserialization (BinaryFormatter, NetDataContractSerializer)
• Missing authorization attributes on controllers
• Use of MD5 or SHA1 for security purposes
• Missing input validation on model binding
• Information leakage in exception handling middleware

AEEF Standards Mapping

Standard	.NET Fit	Implementation
PRD-STD-001 (Prompt Engineering)	Strong	CLAUDE.md with .NET conventions, Copilot instructions
PRD-STD-003 (Security)	Excellent	Built-in security analyzers + ASP.NET Core Identity
PRD-STD-006 (Technical Debt)	Excellent	Roslyn analyzers run at compile time -- zero bypass risk
PRD-STD-010 (Deployment)	Excellent	Built-in container publishing, health checks, ready/liveness probes
PRD-STD-012 (Compliance)	Excellent	EF Core audit interceptors, SBOM, license scanning

Estimated Effort

• Files: ~140 across all three tiers
• Shared artifacts: 25-30 (reusable from existing stacks)
• Stack-specific artifacts: ~110 (application code, .csproj configs, CI pipelines, Semgrep rules)
• Implementation time: 3-4 weeks for an experienced .NET developer

Target Audience

• Microsoft-ecosystem enterprises (Azure, Windows Server, SQL Server)
• Government organizations with .NET mandates
• Financial services on .NET backends
• Healthcare systems running on .NET
• Organizations using Microsoft Semantic Kernel for AI orchestration

---

5. Priority 4: Ruby on Rails

Rationale

Ruby on Rails is the canonical "convention over configuration" framework. This property makes it exceptionally well-suited for AI-assisted development: when there is exactly one correct way to structure a model, controller, migration, or test, AI tools generate accurate code with minimal correction. Rails 8.0 with YJIT delivers significant performance improvements, and the framework remains dominant in startups, SaaS, and rapid product development.

AI Readiness Assessment

• Training corpus: Good. Ruby has a smaller GitHub presence than Java or Python, but the Rails ecosystem's strong conventions mean AI tools produce high-quality code despite less training data.
• Convention strength: Excellent -- arguably the highest of any framework. "The Rails Way" means there is typically one correct approach. AI tools thrive in this environment.
• Framework predictability: When you ask an AI tool to "add a users endpoint with authentication," Rails' conventions mean the generated code (model, migration, controller, routes, serializer, test) follows a predictable structure that requires minimal review.

Framework and Toolchain

Component	Choice	Notes
Framework	Rails 8.0	Latest major release with YJIT, Kamal deployment
Ruby	Ruby 3.3+ with YJIT	3x performance improvement over Ruby 2.7
Database	ActiveRecord + PostgreSQL	Rails default ORM with audit trail gems
Auth	Devise or built-in has_secure_password	Tier 1 uses built-in; Tier 2+ uses Devise
Background jobs	Solid Queue (Rails 8 default)	Database-backed job queue, no Redis dependency
API mode	rails new --api	JSON-only mode for AEEF API templates

Linting and Static Analysis

• RuboCop -- The standard Ruby linter with 400+ cops. The AEEF configuration ships a .rubocop.yml that enables the rubocop-rails, rubocop-rspec, and rubocop-performance extensions. Maps to PRD-STD-006.
• Brakeman -- Rails-specific security scanner that detects SQL injection, XSS, mass assignment, and 30+ other vulnerability patterns. Maps to PRD-STD-003. Brakeman is uniquely valuable because it understands Rails conventions and can detect vulnerabilities that generic SAST tools miss.
• Reek -- Code smell detector for Ruby covering feature envy, data clumps, long parameter lists, and utility function patterns.
• Bundler Audit -- Checks Gemfile.lock against the Ruby Advisory Database. Maps to PRD-STD-008.
• Semgrep Ruby rules -- Custom rules for Rails-specific patterns not covered by Brakeman.

Testing Strategy

Layer	Tool	Purpose
Unit/Integration	RSpec 3	BDD-style testing; Rails community standard
Factories	FactoryBot	Test data factories replacing fixtures
Request specs	RSpec Rails	Full-stack request testing for API endpoints
Mutation	mutant	Production-quality mutation testing for Ruby
Coverage	SimpleCov	Code coverage with branch coverage support
System tests	Capybara (if needed)	Browser testing for full-stack Rails apps

CI/CD Pipeline

Rails stacks will ship Tier 1 and Tier 2 implementations only. Tier 3 will be added if community demand warrants it.

Tier 1 (Quick Start) -- 5 stages:

1. bundle -- bundle install with frozen lockfile
2. rubocop -- bundle exec rubocop
3. brakeman -- bundle exec brakeman --no-pager
4. test -- bundle exec rspec with SimpleCov (80% minimum)
5. build -- Docker image build

Tier 2 (Transformation) -- 7 stages:

1. bundle -- bundle install
2. rubocop -- RuboCop with AEEF configuration
3. reek -- Code smell detection
4. brakeman -- Security scanning
5. unit-test -- bundle exec rspec spec/models spec/services with coverage
6. request-test -- bundle exec rspec spec/requests with coverage
7. mutation-test -- mutant on critical business logic (60% threshold)
8. bundler-audit -- Dependency vulnerability check
9. build -- Docker image build with multi-stage Dockerfile

AEEF Standards Mapping

Standard	Rails Fit	Implementation
PRD-STD-001 (Prompt Engineering)	Strong	Rails conventions make AI prompts highly effective
PRD-STD-003 (Security)	Excellent	Brakeman is best-in-class for framework-specific SAST
PRD-STD-005 (Documentation)	Strong	Rails conventions are self-documenting
PRD-STD-006 (Technical Debt)	Strong	RuboCop + Reek provide comprehensive code quality
PRD-STD-008 (Dependencies)	Good	Bundler Audit + Gemfile.lock pinning

Estimated Effort

• Files: ~100 across 2 tiers (Tier 1 + Tier 2)
• Shared artifacts: 20-25 (subset of agent SDLC contracts, schemas)
• Stack-specific artifacts: ~75 (application code, configs, CI pipelines, Semgrep rules)
• Implementation time: 2-3 weeks for an experienced Rails developer

Target Audience

• Startups and early-stage companies
• SaaS product companies (Shopify, GitHub, Basecamp ecosystem)
• Web application development agencies
• Teams valuing rapid development with convention-based governance

---

6. Priority 5: PHP / Laravel

Rationale

PHP powers 77% of websites with a known server-side language, and Laravel is the dominant modern PHP framework with a strong convention-based architecture. Laravel's investment in AI tooling (Laravel Boost, Laravel Herd AI features) demonstrates ecosystem commitment to AI-assisted development. The AEEF PHP stack targets the large population of web agencies, e-commerce platforms, and CMS-heavy organizations that need governance for AI-generated PHP code.

AI Readiness Assessment

• Training corpus: Large. PHP's massive web presence means AI tools have extensive training data, though quality varies. Laravel-specific code is consistently high quality due to framework conventions.
• Convention strength: Good. Laravel enforces MVC structure, Eloquent ORM patterns, and routing conventions. The framework's "opinionated" approach guides AI tools toward correct code.
• Framework ecosystem: Laravel's first-party packages (Sanctum, Horizon, Telescope, Pulse) provide standardized solutions for auth, queues, debugging, and monitoring.

Framework and Toolchain

Component	Choice	Notes
Framework	Laravel 11	Streamlined application structure, per-second cron
PHP	PHP 8.3+	Enums, fibers, readonly properties, typed properties
Database	Eloquent ORM + PostgreSQL/MySQL	ActiveRecord pattern with model events for auditing
Auth	Laravel Sanctum	API token authentication, SPA authentication
Queue	Laravel Queue + Horizon	Redis-backed queue with monitoring dashboard
Build	Composer	Dependency management and autoloading

Linting and Static Analysis

• PHPStan -- Static analysis at varying strictness levels (0-9). The AEEF configuration targets level 8 for Tier 2+. Maps to PRD-STD-006.
• Larastan -- PHPStan extension with Laravel-specific rules covering Eloquent, collections, facades, and blade templates.
• Psalm -- Alternative/complementary static analyzer with taint analysis for security vulnerability detection. Maps to PRD-STD-003.
• PHP-CS-Fixer -- Formatting tool with PSR-12 and Laravel preset configurations.
• Rector -- Automated refactoring and upgrade tool. Useful for enforcing deprecation removal and modernization patterns.

Testing Strategy

Layer	Tool	Purpose
Unit	PHPUnit 11 or Pest 3	Standard PHP testing (Pest preferred for Laravel projects)
Feature	Laravel HTTP Tests	Full request/response testing with database transactions
Mutation	Infection	PHP mutation testing framework with broad operator support
Browser	Laravel Dusk	Browser testing (optional, for full-stack apps)
Coverage	Xdebug or PCOV	Code coverage collection (PCOV preferred for speed)

Pest is the recommended test framework for new Laravel AEEF projects because:

1. Its syntax is cleaner and more readable than PHPUnit
2. It provides architectural testing (expect()->toUseStrictTypes())
3. It has built-in coverage and mutation testing support

// Pest architectural test example
arch('app')
    ->expect('App\Models')
    ->toExtend('Illuminate\Database\Eloquent\Model')
    ->toHaveMethod('casts');

arch('strict types')
    ->expect('App')
    ->toUseStrictTypes();

CI/CD Pipeline

PHP/Laravel stacks will ship Tier 1 and Tier 2 implementations.

Tier 1 (Quick Start) -- 5 stages:

1. install -- composer install --no-dev --prefer-dist
2. lint -- php-cs-fixer fix --dry-run --diff
3. analyse -- phpstan analyse --level=6
4. test -- php artisan test with PCOV coverage
5. build -- Docker image build

Tier 2 (Transformation) -- 7 stages:

1. install -- composer install
2. cs-fixer -- PHP-CS-Fixer with AEEF preset
3. phpstan -- PHPStan level 8 with Larastan
4. psalm -- Psalm taint analysis for security
5. unit-test -- php artisan test --testsuite=Unit with coverage (80% minimum)
6. feature-test -- php artisan test --testsuite=Feature with coverage
7. mutation-test -- Infection with 60% mutation score threshold
8. security -- composer audit + Semgrep PHP rules
9. build -- Docker image build with multi-stage Dockerfile (FrankenPHP or PHP-FPM)

AEEF Standards Mapping

Standard	Laravel Fit	Implementation
PRD-STD-001 (Prompt Engineering)	Strong	Laravel conventions guide AI code generation
PRD-STD-003 (Security)	Good	Psalm taint analysis + Semgrep + Laravel Sanctum
PRD-STD-006 (Technical Debt)	Good	PHPStan + Larastan at high strictness levels
PRD-STD-008 (Dependencies)	Good	Composer audit + lockfile pinning
PRD-STD-012 (Compliance)	Good	Eloquent model events for audit trails

Estimated Effort

• Files: ~100 across 2 tiers (Tier 1 + Tier 2)
• Shared artifacts: 20-25 (subset of agent SDLC contracts, schemas)
• Stack-specific artifacts: ~75 (application code, configs, CI pipelines, Semgrep rules)
• Implementation time: 2-3 weeks for an experienced Laravel developer

Target Audience

• Web agencies building client projects
• E-commerce platforms (Magento, Shopify apps, WooCommerce)
• CMS-heavy organizations (WordPress, Drupal backends)
• SaaS companies on the Laravel ecosystem
• Organizations with large existing PHP codebases

---

7. Priority 6: Mobile (Kotlin + Swift)

Rationale

The global mobile app economy exceeds $935 billion in consumer spending. Both Kotlin and Swift are fully supported by GitHub Copilot and Claude, and mobile applications face unique governance challenges around data privacy, app store compliance, and platform-specific security requirements that map directly to AEEF standards.

This priority covers two parallel sub-stacks that share governance artifacts but differ in platform-specific tooling.

Kotlin / Android

AI Readiness

• Training corpus: Good. Kotlin has grown rapidly on GitHub, and Google's adoption of Kotlin-first for Android means extensive high-quality training data.
• Convention strength: Good. Kotlin's language features (data classes, sealed classes, coroutines) encourage consistent patterns. Jetpack Compose provides a single UI paradigm.
• Kotlin Multiplatform (KMP): Increasingly relevant for shared business logic between Android and iOS, reducing the governance surface area.

Toolchain

Component	Choice	Notes
Language	Kotlin 2.x	K2 compiler, Compose compiler plugin
UI	Jetpack Compose	Declarative UI, replacing XML layouts
Architecture	MVVM + Repository pattern	Google-recommended architecture
DI	Hilt (Dagger)	Compile-time dependency injection
Networking	Ktor Client or Retrofit	HTTP client with serialization
Testing	JUnit 5 + Turbine + Compose Test	Unit, flow, and UI testing
Linting	Detekt + ktlint	Static analysis + formatting
CI	Gradle + GitHub Actions	Standard Android CI

Security Considerations for Mobile

Mobile AEEF rules include platform-specific concerns:

• Certificate pinning enforcement
• Secure storage (Android Keystore) for tokens and secrets
• ProGuard/R8 obfuscation rules
• Network security configuration audit
• Biometric authentication patterns
• Data encryption at rest

Swift / iOS

AI Readiness

• Training corpus: Good. Swift is Apple's primary language with significant GitHub presence and extensive official documentation.
• Convention strength: Strong. Swift's type system, protocols, and SwiftUI enforce consistent patterns. Apple's Human Interface Guidelines provide additional convention layers.
• Swift 6: Strict concurrency checking eliminates data races at compile time, similar to Rust's ownership model benefits.

Toolchain

Component	Choice	Notes
Language	Swift 6	Strict concurrency, typed throws
UI	SwiftUI	Declarative UI framework
Architecture	MVVM + Swift Concurrency	async/await, actors for state management
Networking	URLSession + async/await	Built-in HTTP client with modern syntax
Data	SwiftData or Core Data	Persistence framework
Testing	Swift Testing framework + XCTest	Modern testing + legacy support
Linting	SwiftLint	Community-standard linter with 200+ rules
CI	xcodebuild + GitHub Actions	Standard iOS CI

Security Considerations for iOS

• App Transport Security (ATS) configuration audit
• Keychain usage for credential storage
• Biometric authentication (Face ID, Touch ID)
• Data Protection API usage verification
• Entitlements audit

CI/CD Pipelines

Kotlin/Android Tier 1 -- 5 stages:

1. assemble -- ./gradlew assembleDebug
2. detekt -- ./gradlew detekt
3. test -- ./gradlew testDebugUnitTest with JaCoCo
4. lint -- ./gradlew lintDebug (Android Lint)
5. build -- ./gradlew assembleRelease

Swift/iOS Tier 1 -- 5 stages:

1. resolve -- swift package resolve
2. swiftlint -- swiftlint lint --strict
3. test -- xcodebuild test with code coverage
4. analyse -- xcodebuild analyze
5. build -- xcodebuild archive

AEEF Standards Mapping (Mobile-Specific)

Standard	Mobile Fit	Implementation
PRD-STD-003 (Security)	Critical	Platform-specific security rules, certificate pinning, secure storage
PRD-STD-008 (Dependencies)	Strong	Gradle/SPM dependency auditing, lockfile enforcement
PRD-STD-009 (Performance)	Strong	App startup time, memory profiling, battery impact
PRD-STD-012 (Compliance)	Critical	App Store review requirements, data privacy regulations

Estimated Effort

• Files: ~80 per platform (~160 total for both Kotlin and Swift)
• Shared artifacts: 15-20 per platform (governance documents, schemas)
• Stack-specific artifacts: ~60 per platform (app code, configs, CI pipelines)
• Implementation time: 3-4 weeks per platform

Target Audience

• Mobile-first companies (fintech apps, consumer apps)
• Banks and financial services with mobile banking apps
• Healthcare with patient-facing mobile apps
• Retail and e-commerce with mobile shopping apps
• Any organization shipping to App Store or Play Store

---

8. Priority 7: Infrastructure as Code

Rationale

Infrastructure as Code governs the deployment substrate for all application stacks. Terraform holds approximately 32.8% IaC market share, and Pulumi brings real programming languages (TypeScript, Python, Go) to infrastructure definition. As AI tools increasingly generate infrastructure code, AEEF governance for IaC prevents misconfigurations that lead to security breaches, cost overruns, and compliance violations.

This priority differs from application stacks: it produces config packs rather than full application templates, since IaC is inherently configuration-centric.

Terraform

Component	Choice	Notes
Language	HCL (HashiCorp Configuration Language)	Terraform's native language
Version	Terraform 1.7+ (OpenTofu also supported)	Import blocks, removed blocks, check blocks
Linting	tflint + tflint-ruleset-aws/azurerm/google	Provider-specific rules
Security	tfsec (Aqua) + Checkov (Palo Alto)	IaC security scanning
Cost	Infracost	Cost estimation before apply
Drift	Terraform Cloud/Enterprise or driftctl	Configuration drift detection
State	Remote state (S3, Azure Blob, GCS)	Encrypted, versioned state files

Terraform CI Pipeline -- 6 stages:

1. init -- terraform init -backend=false (syntax validation)
2. fmt -- terraform fmt -check -recursive
3. validate -- terraform validate
4. tflint -- tflint with provider-specific rulesets
5. security -- tfsec + Checkov scanning
6. plan -- terraform plan (with cost estimation via Infracost)

Pulumi

Component	Choice	Notes
Languages	TypeScript, Python, Go	Real programming languages for infrastructure
AI	Pulumi AI / Pulumi Copilot	AI-assisted infrastructure generation
Testing	Built-in unit testing framework	Test infrastructure code with standard language tools
Policy	Pulumi CrossGuard	Policy-as-code for compliance enforcement
Security	Checkov (supports Pulumi)	IaC security scanning

Pulumi CI Pipeline -- 5 stages:

1. install -- Language-specific dependency installation
2. lint -- Language linter (ESLint/ruff/golangci-lint)
3. test -- Pulumi unit tests (pulumi test)
4. policy -- CrossGuard policy evaluation
5. preview -- pulumi preview (dry-run deployment)

AEEF Standards Mapping

Standard	IaC Fit	Implementation
PRD-STD-003 (Security)	Critical	tfsec/Checkov catch misconfigurations before deployment
PRD-STD-010 (Deployment)	Core	IaC is the deployment mechanism itself
PRD-STD-011 (Monitoring)	Strong	Infrastructure monitoring provisioning
PRD-STD-012 (Compliance)	Strong	Policy-as-code for regulatory requirements
PRD-STD-014 (Sovereignty)	Critical	Region pinning, data residency, cloud provider controls

Estimated Effort

• Files: ~60 in config-pack style (not a full application template)
• Terraform artifacts: ~35 (modules, CI pipelines, tflint configs, tfsec rules, Checkov policies)
• Pulumi artifacts: ~25 (templates per language, CrossGuard policies, CI pipelines)
• Implementation time: 2-3 weeks

Target Audience

• Platform engineering teams
• DevOps and SRE teams
• Cloud infrastructure teams (AWS, Azure, GCP)
• Organizations with multi-cloud deployments
• Teams adopting GitOps workflows

---

9. Community Contribution Guide

AEEF welcomes community contributions for new stacks. You do not need to wait for a priority slot -- if your organization needs an AEEF implementation for a stack not listed here (Elixir/Phoenix, Scala/Play, Dart/Flutter, etc.), you can start today.

Contribution Process

Step 1: Fork the Appropriate Tier Repository

Choose which tier(s) you are implementing:

Tier	Repository	Minimum Requirement
Tier 1 (Quick Start)	aeef-quickstart	Application scaffold + linting + testing + basic CI
Tier 2 (Transformation)	aeef-transform	Tier 1 + mutation testing + agent SDLC + security scanning + multi-stage CI
Tier 3 (Production)	aeef-production	Tier 2 + monitoring + incident response + sovereign overlays + SBOM

Most community contributions should start with Tier 1, prove the approach works, and then extend to Tier 2.

Step 2: Follow the Shared Structure

Every stack implementation must include the shared/ directory structure for cross-stack governance artifacts:

stacks/your-language/
  app/                    # Application scaffolding
  configs/                # Linter, formatter, and tool configurations
  ci/                     # CI/CD pipeline definitions
  semgrep/                # Custom Semgrep rules for your language
  tests/                  # Example tests demonstrating testing strategy
  CLAUDE.md               # AI coding assistant instructions for this stack
  README.md               # Stack-specific setup and usage instructions

The shared/ directory is inherited from the repository root and must not be duplicated. It contains:

shared/
  agent-sdlc/             # Contracts, prompts, handoffs (Tier 2+)
  schemas/                # JSON schemas for KPI records, provenance logs
  policies/               # Security, dependency, and quality policies
  quality-gates/          # Quality gate definitions
  checklists/             # Review checklists

Step 3: Implement Stack-Specific Artifacts

At minimum, a Tier 1 contribution must include:

1. Application scaffold -- A minimal but functional API application with:

   • Health endpoint (GET /health)
   • Structured JSON logging
   • Graceful shutdown handling
   • Environment-based configuration
   • Error handling middleware

2. Linter configuration -- At least one linter configured with an AEEF-specific ruleset. Document which PRD-STDs the rules enforce.

3. Test configuration -- Unit test framework configured with:

   • Coverage collection enabled
   • 80% line coverage minimum
   • At least one example test

4. Security scanning -- At least one of:

   • Custom Semgrep rules (3+ rules minimum)
   • Language-native SAST tool configuration
   • Dependency vulnerability scanning

5. CI pipeline -- GitHub Actions workflow with at minimum:

   • Build/compile step
   • Lint step
   • Test step with coverage
   • Security scan step

6. CLAUDE.md -- AI coding assistant instructions covering:

   • Language and framework conventions
   • Project structure explanation
   • Testing instructions
   • Common patterns to follow
   • Patterns to avoid

Step 4: Map to AEEF Standards

Create a coverage table showing which PRD-STDs your implementation enforces:

| PRD-STD | Enforced | Mechanism | File(s) |
|---------|----------|-----------|---------|
| PRD-STD-001 | Yes | CLAUDE.md instructions | CLAUDE.md |
| PRD-STD-003 | Yes | Semgrep rules + [tool] | semgrep/*.yml, configs/[tool].yml |
| PRD-STD-006 | Yes | [Linter] configuration | configs/[linter].yml |
| ...     | ...      | ...       | ...     |

Step 5: Submit PR with CI Proof

Your pull request must include:

1. Working CI pipeline -- The GitHub Actions workflow must pass on the PR itself, demonstrating that the pipeline works.
2. Coverage report -- Test coverage results showing the 80% minimum is met.
3. Linting proof -- Clean linter run with no violations.
4. Security scan proof -- Clean security scan or documented accepted risks.
5. Standards coverage table -- The mapping from Step 4.
6. CHANGELOG entry -- Describing the new stack addition.

Contribution Quality Checklist

Before submitting, verify:

• Application starts and responds to GET /health with a 200 status
• All linter rules pass without suppression comments (or suppressions are documented)
• Test suite passes with 80%+ coverage
• At least 3 custom Semgrep rules are included
• CI pipeline has 5+ stages
• CLAUDE.md includes stack-specific AI coding instructions
• Coverage table maps to at least 5 PRD-STDs
• Docker build produces a working container image
• README includes setup instructions that work from a clean clone

Getting Help

• Open a GitHub Discussion in the aeef-quickstart or aeef-transform repository to discuss your stack before starting
• Reference the existing TypeScript, Python, or Go implementations as templates
• The AEEF team will review PRs and provide feedback within 2 weeks

---

10. Timeline

The following timeline reflects current planning priorities. Dates are targets, not commitments, and may shift based on community contributions and demand signals.

Stack	Target Quarter	Status	Notes
Java / Spring Boot	Q2 2026	Planning	Highest enterprise demand; first community contributions expected
Rust	Q2 2026	Planning	Strong AI tool adoption signals; infrastructure/fintech demand
.NET / C#	Q3 2026	Planned	Microsoft AI-native investment; enterprise Windows demand
Ruby on Rails	Q3 2026	Planned	Convention density advantage; startup/SaaS demand
PHP / Laravel	Q4 2026	Planned	Massive web install base; Laravel AI tooling investment
Mobile (Kotlin)	Q4 2026	Planned	Android-first; may launch alongside Swift
Mobile (Swift)	Q4 2026	Planned	iOS companion to Kotlin; shared governance artifacts
IaC (Terraform)	Q1 2027	Planned	Config-pack style; pairs with any application stack
IaC (Pulumi)	Q1 2027	Planned	Multi-language IaC; leverages existing TypeScript/Python/Go stacks

Accelerating the Timeline

Community contributions can accelerate any stack on this roadmap. If your organization has a pressing need for a specific stack:

1. Contribute directly -- Follow the Community Contribution Guide above to submit a Tier 1 implementation.
2. Sponsor development -- Contact the AEEF team to discuss sponsored development of priority stacks.
3. Signal demand -- Star the relevant GitHub Discussion to help prioritize.

Stacks Under Consideration (Not Yet Scheduled)

The following stacks have been discussed but are not yet on the formal roadmap. Community contributions or demand signals could promote them:

Stack	Consideration	Blocker
Elixir / Phoenix	Strong concurrency model, growing AI tool support	Smaller community size
Scala / Play or ZIO	JVM ecosystem, functional programming	Complexity of multiple paradigms
Dart / Flutter	Cross-platform mobile + web	Flutter-specific governance unclear
Zig	Systems language alternative to C	Very early AI tool support
Gleam	Type-safe BEAM language	Very new, small ecosystem
V / Vlang	C alternative with simplicity	Too early for enterprise governance

---

Summary

The AEEF stack roadmap prioritizes languages and frameworks based on AI tool readiness, enterprise adoption, convention density, and standards coverage. The current three-stack foundation (TypeScript, Python, Go) covers the majority of greenfield AI-assisted projects. The seven priority stacks on this roadmap will extend coverage to enterprise Java, systems-level Rust, the Microsoft ecosystem, convention-driven Ruby and PHP, mobile platforms, and infrastructure as code.

Every new stack follows the same three-tier maturity model, reuses the shared governance artifacts (agent SDLC contracts, schemas, policies, quality gates), and maps explicitly to the 16 AEEF production standards. This ensures consistency across stacks while respecting the idioms and tooling of each ecosystem.

To get started with a contribution, see the Community Contribution Guide above, or browse the existing implementations:

• Quick Start (Tier 1) -- TypeScript, Python, Go
• Transformation (Tier 2) -- TypeScript, Python, Go
• Production (Tier 3) -- TypeScript, Python, Go
• Standards Coverage Matrix -- Complete PRD-STD to file mapping