Introduction & Platform Philosophy
Relevant source files
The following files were used as context for generating this wiki page:
The Engineering Platform (eng-platform) is a unified system of standards, tools, and templates designed to serve as the foundation for all software projects within the organization. It consolidates innovations from various internal projects (such as LegalAI and AdHub) into a domain-agnostic ecosystem. The platform's primary purpose is to provide shared configurations, automated Model Context Protocol (MCP) servers, and AI-native workflows that ensure consistency, security, and velocity across diverse engineering teams.
By acting as a "platform" rather than just project-specific code, it establishes a bidirectional synchronization loop where projects can both consume standardized configurations and contribute new tools or patterns back to the central repository. This philosophy emphasizes "Engineering Platform" as the bedrock upon which projects are built, rather than a collection of static documents.
Sources: README.md:1-12, CONTRIBUTING.md:5-9, CHANGELOG.md:88-92
Core Platform Pillars
The platform is structured around several key pillars that define its technical philosophy: shared standards, AI-native automation, and enforced code protection.
1. Unified Engineering Standards
The platform provides a "Quick Start" for new and existing projects by offering pre-configured environments for linting, formatting, and type safety. These are not merely suggestions but are intended to be extended by projects to maintain a consistent baseline across the organization.
Sources: README.md:20-25, CHANGELOG.md:162-170
2. AI-Native Workflow (ÆtherLight)
A significant portion of the platform is dedicated to ÆtherLight, a system of "Skills" and AI contexts designed to automate the software development lifecycle. This includes voice-to-code integration, automated sprint management, and pattern-based development to prevent AI hallucinations.
Sources: skills/initialize/SKILL.md:13-20, README.md:95-103
3. Protection & Governance
The platform enforces a "Protected Code Policy." Once code is released, it is considered protected, and modifications are restricted to refactoring or extension only. This is supported by technical "Guard Hooks" that block unauthorized modifications in real-time.
Sources: skills/initialize/SKILL.md:394-420, CHANGELOG.md:105-110
Architecture Overview
The platform operates as a centralized repository that projects integrate via Git submodules. This allows for a modular architecture where the core platform can evolve independently of the projects it supports.
The diagram shows the relationship between the central Engineering Platform and a client project, highlighting how standards and tools are propagated via submodules.
Sources: README.md:52-85, CHANGELOG.md:213-220
Key Components and Features
| Component | Description | Key Files/Locations |
|---|---|---|
| Shared Configs | Enforced standards for ESLint, Prettier, TypeScript, and Git hooks. | configs/ |
| Custom MCP Servers | Domain-agnostic servers for research, context drift detection, and analytics. | mcp-servers/ |
| ÆtherLight Skills | AI-native workflow automation (e.g., /code-analyze, /sprint-plan). | skills/ |
| Tool Experimentation | A/B testing framework to measure tool effectiveness and engineer health. | experiments/, tools-registry.json |
| Protected Code | Metadata and hooks to prevent unauthorized changes to stable modules. | templates/protection-guard-hook/, PROTECTED.md |
Sources: README.md:88-150, CHANGELOG.md:14-45
The Documentation Philosophy: Chain of Thought (CoT)
A critical aspect of the platform's philosophy is the Chain of Thought (CoT) documentation standard. This standard requires that every significant code change or function be accompanied by a structured explanation of the design decision and the reasoning behind it. This ensures that the "why" is preserved alongside the "what," facilitating better AI understanding and long-term maintainability.
Required CoT Elements:
- DESIGN DECISION: The high-level approach taken.
- WHY: The justification for that specific approach.
- REASONING CHAIN: A step-by-step numbered list of the thought process.
- PATTERN: Reference to organizational patterns (e.g., Pattern-CONTEXT-002).
- PERFORMANCE: Specific targets or metrics for critical paths.
Sources: internal/agents/documentation-agent-context.md:20-45, templates/CLAUDE.md:85-100
This sequence diagram illustrates the automated validation process performed by the Documentation Agent to ensure all code adheres to the Chain of Thought standard.
Sources: internal/agents/documentation-agent-context.md:120-145
Development Workflow & Release Process
The platform follows a strict semantic versioning (Semver) strategy and a structured contribution loop.
- Major (v2.0.0): Breaking changes requiring project updates.
- Minor (v1.1.0): Backward-compatible new features.
- Patch (v1.0.1): Bug fixes and minor maintenance.
The contribution workflow encourages developers to "discover" tools in their specific projects, extract them into a domain-agnostic format, and PR them back into the platform. This cycle is supported by automated prompts that handle the "cleaning" of project-specific references.
Sources: CONTRIBUTING.md:65-75, CHANGELOG.md:52-60, README.md:154-165
Conclusion
The Engineering Platform represents a shift toward AI-native infrastructure, where development standards are not just documented but programmatically enforced through skills, hooks, and MCP servers. By prioritizing structured reasoning (CoT) and modular architecture (Git submodules), the platform ensures that the entire organization benefits from the innovations of individual teams while maintaining a stable, protected core.
Sources: README.md:210-230, CHANGELOG.md:240-250