| name | madr-enforcement |
| description | > Use when this capability is needed. |
MADR Enforcement Skill
This skill ensures that code written in the CellixJS project adheres to the architectural standards, patterns,
and guidelines documented in our Markdown Any Decision Records (MADRs). All ADRs are located in
apps/docs/docs/decisions/ and represent binding architectural decisions that must be followed.
When to Use This Skill
Use this skill when:
- Writing new code - Ensure it follows established architectural patterns from ADRs
- Reviewing pull requests - Verify code compliance with documented standards
- Refactoring existing code - Align implementations with current ADRs
- Adding dependencies - Check against technology choices documented in ADRs
- Making design decisions - Verify alignment or identify need for new ADR
- Implementing features - Follow patterns from relevant domain/infrastructure ADRs
CellixJS Architectural Decisions (ADRs)
All architectural decisions are documented in apps/docs/docs/decisions/. The following ADRs define
standards that MUST be enforced in code:
Architecture & Design Patterns
ADR-0003: Domain-Driven Design (DDD)
Standards to Enforce:
-
Bounded Contexts - Code must be organized by bounded context
- Location:
packages/ocom/domain/contexts/{context-name}/
- Each context has its own ubiquitous language
-
Entity Structure - Entities must follow DDD patterns
- File:
{entity}.ts
- Must have unique identity (ID)
- Contains business logic methods
- Props interface defines state
-
Value Objects - Immutable objects defined by their values
- File:
{entity}.value-objects.ts
- Must be immutable
- Use
@lucaspaganini/value-objects framework
-
Aggregate Roots - Entry points for entity clusters
- File:
{entity}.ts (aggregate root entities)
- Enforces business rules for the aggregate
- Guards integrity of related entities
-
Unit of Work Pattern - Atomic operations on domain models
- File:
{entity}.uow.ts
- Transaction boundary for persistence
- One per aggregate root
-
Layer Separation
- Domain Layer: Business logic only, no infrastructure
- Application Service Layer: Orchestration, coordinates use cases
- Infrastructure Service Layer: External systems, third-party APIs
Code Review Checklist:
ADR-0019: MonoRepo and Turborepo
Standards to Enforce:
-
Package Organization
- Workspace structure defined in
pnpm-workspace.yaml
- Package naming:
@ocom/* or @cellix/*
-
Build System
- Use Turborepo for builds:
pnpm run build
- Respect package dependencies
- Use affected builds:
pnpm run build:affected
-
Testing
- Package-level tests in each workspace
- Use
pnpm run test:affected
- Coverage reports per package
Code Review Checklist:
Code Quality & Standards
ADR-0012: Biome for Linting
Standards to Enforce:
-
Linting and Formatting
- Use Biome (not ESLint or Prettier)
- Configuration in
biome.json
- Run before commits:
pnpm run lint
-
Type Safety
- Biome provides type-aware linting
- Strict TypeScript configuration
- No
any types without justification
-
Code Style
- Tab indentation (per biome.json)
- Follow Biome's formatting rules
- Auto-fix with
pnpm run format
Code Review Checklist:
ADR-0013: Test Suite Architecture
Standards to Enforce:
-
Test Framework
- Use Vitest for unit tests
- Test coverage via
pnpm run test:coverage
-
Test Organization
- Unit tests: Co-located with source files
- Integration tests: Separate directory
- E2E tests: SerenityJS (ADR-0007)
-
Coverage Requirements
- Coverage reports in
packages/*/coverage/
- Minimum coverage thresholds enforced
Code Review Checklist:
ADR-0022: Snyk Security Integration
Standards to Enforce:
-
Security Scanning
- Run Snyk before commits:
pnpm run snyk
- Includes SAST (code), SCA (dependencies), IaC (Bicep)
-
Vulnerability Management
- Fix critical/high vulnerabilities immediately
- Document exceptions in
.snyk file
- Get CODEOWNERS approval for ignores
-
Workflow
- Scan during development with
snyk_code_scan MCP tool
- Verify fixes with re-scan
- Pass Snyk gate before commit
Code Review Checklist:
Infrastructure & Technology
ADR-0002: OpenTelemetry
Standards to Enforce:
-
Observability
- Use
@azure/monitor-opentelemetry
- Automatic instrumentation for MongoDB, Azure Functions
- GraphQL tracing via Apollo Server
-
Integration
- Package:
@ocom/service-otel
- Configured via OpenTelemetry SDK
Code Review Checklist:
ADR-0011: Bicep for Infrastructure as Code
Standards to Enforce:
-
IaC Language
- Use Bicep (not ARM templates, Terraform)
- Location:
iac/ directory
-
Resource Naming
- Follow naming conventions in ADR-0021
- Use resource scoping strategy
-
Deployment
- Azure infrastructure deployments per ADR-0014
- CI/CD via Azure DevOps (ADR-0020)
Code Review Checklist:
ADR-0014: Azure Infrastructure Deployments
Standards to Enforce:
-
Azure Functions
- Version 4.x
- TypeScript runtime
- Registered via
cellix.registerAzureFunctionHandler()
-
Service Registration
- Use
Cellix class for DI orchestration
- Register services with
serviceRegistry.registerService()
-
Context Specification
- Define context via
setContext()
- Provide typed service access
Code Review Checklist:
Technology Choices
ADR-0004: Identity and Access Management
ADR-0005: Authorization
Standards to Enforce:
-
Authentication
- Follow IAM patterns from ADR-0004
-
Authorization
- Implement authorization per ADR-0005
Code Review Checklist:
ADR-0010: React Router Loaders
Standards to Enforce:
-
Data Loading
- Use React Router loaders for initial data
- Co-locate with route definitions
-
UI Patterns
- Loader functions return route data
- Components access via
useLoaderData()
Code Review Checklist:
Code Enforcement Workflow
When Writing New Code
-
Identify Relevant ADRs
- Search
apps/docs/docs/decisions/ for applicable standards
- Read ADRs related to your domain, technology, or pattern
-
Apply ADR Standards
- Follow file naming conventions
- Use documented patterns
- Respect layer boundaries
-
Verify Compliance
- Run linting:
pnpm run lint
- Run tests:
pnpm run test
- Run security scan:
pnpm run snyk
- Full verification:
pnpm run verify
When Reviewing Code
-
Check ADR Alignment
- Identify which ADRs apply to the changes
- Verify code follows documented patterns
-
Common Violations
- Domain logic in infrastructure layer (violates ADR-0003)
- Using ESLint instead of Biome (violates ADR-0012)
- Missing tests (violates ADR-0013)
- Unscanned dependencies (violates ADR-0022)
- Not using Bicep for infrastructure (violates ADR-0011)
-
Request Changes
- Reference specific ADR in review comments
- Explain which standard is violated
- Suggest corrective action
When Making Architectural Decisions
-
Check Existing ADRs
- Search for related decisions
- Verify no conflicts with current ADRs
-
Determine if New ADR Needed
- New framework/library adoption → Requires ADR
- New architectural pattern → Requires ADR
- Infrastructure changes → Requires ADR
- Refactoring without architectural impact → No ADR needed
-
Create ADR if Required
- Follow process in ADR-0001
- Use templates in
apps/docs/docs/decisions/
- Get approval from deciders before implementing
ADR Index by Category
Architecture & Design
- ADR-0003: Domain-Driven Design (DDD)
- ADR-0019: MonoRepo and Turborepo
Code Quality & Security
- ADR-0012: Biome linting
- ADR-0013: Test suite architecture
- ADR-0015: SonarCloud integration
- ADR-0016: SonarCloud code duplication
- ADR-0022: Snyk security integration
Infrastructure & DevOps
- ADR-0002: OpenTelemetry observability
- ADR-0011: Bicep for IaC
- ADR-0014: Azure infrastructure deployments
- ADR-0018: Docusaurus Azure pipeline
- ADR-0020: Azure DevOps monorepo pipeline
- ADR-0021: Bicep resource scoping
Technology & Tools
- ADR-0004: Identity and access management
- ADR-0005: Authorization patterns
- ADR-0006: Maps integration
- ADR-0007: SerenityJS testing
- ADR-0008: White-label architecture
- ADR-0009: Cache purging
- ADR-0010: React Router loaders
- ADR-0017: Chrome content overrides
- ADR-0023: TsGo migration
Process & Documentation
- ADR-0001: MADR for architectural decisions
Common Code Patterns by ADR
DDD Pattern (ADR-0003)
Correct Implementation:
export interface UserProps {
readonly id: UserId;
readonly email: Email;
readonly profile: UserProfile;
}
export class User implements AggregateRoot<UserProps> {
constructor(private props: UserProps) {}
get id(): UserId { return this.props.id; }
updateEmail(newEmail: Email): void {
this.props = { ...this.props, email: newEmail };
}
}
Incorrect Implementation (violates ADR-0003):
export class User {
async save(): Promise<void> {
await mongoose.model('User').save(this);
}
}
Service Registration (ADR-0014)
Correct Implementation:
Cellix.initializeServices<ApiContextSpec>((serviceRegistry) => {
serviceRegistry.registerService(new ServiceMongoose(...));
serviceRegistry.registerService(new ServiceOtel(...));
})
.setContext((serviceRegistry) => ({
domainDataSource: contextBuilder(serviceRegistry.getService(ServiceMongoose)),
telemetry: serviceRegistry.getService(ServiceOtel)
}));
Turborepo Usage (ADR-0019)
Correct Commands:
pnpm run build
pnpm run build:affected
pnpm run test
Incorrect:
cd packages/ocom/domain && npm run build
Enforcement During Code Generation
When generating code:
-
Start with ADR Review
- Identify applicable ADRs for the task
- Read relevant sections
-
Generate Code Following Standards
- Use patterns from ADRs
- Follow file naming conventions
- Respect layer boundaries
-
Verify Compliance
- Check code against ADR requirements
- Run verification suite
- Reference ADRs in comments if needed
References
Internal Documentation
- All ADRs:
apps/docs/docs/decisions/
- ADR-0001: MADR Architecture Decisions (process for creating ADRs)
- ADR Templates:
apps/docs/docs/decisions/adr-template.md
External Resources
Converted and distributed by TomeVault — claim your Tome and manage your conversions.