The Setup: Week 2’s Hidden Debt
After building seven CRM domain models with a custom DynamoDB macro and full API layer, I thought the foundation was solid. Initial reality check: Event logs showed something wrong.The Journey: Following the Event Trail
The Event That Revealed Everything
I opened a fresh Evaluator session to investigate:Evaluator's Detection Logic
Evaluator's Detection Logic
Pattern analysis:
- Scanned 2,847 events across auth, CRM, and catalog services
- Extracted event schemas by grouping events by type
- Compared field patterns across related events
- Flagged inconsistencies where similar operations had different fields
The Macro Compliance Sweep
With the event analysis showing 6 entities missing capsule isolation, I realized: our DynamoDB macro didn’t enforce this pattern. The macro we built:capsule_id, but didn’t require
it.
Builder sessions for RoleAssignment and SecurityGroup entities simply… forgot to include it.
Next task: Make capsule isolation mandatory at compile time.
Compile-Time Enforcement
Builder session:What We Built
Macro Enhancements
DynamoDB Macro:
- Compile-time capsule isolation enforcement
- Nested struct field validation
- Clear error messages
- Removed automatic parameter inference
- Explicit path/query parameter declarations
- OpenAPI spec correctness guarantees
Capsule Isolation Fixes
Entities updated:
- RoleAssignment
- SecurityGroup
- Entitlement
- Session (auth)
- Federal compliance data (CRM)
Documentation
CLAUDE.md improvements:
- 12 architectural patterns documented
- DynamoDB entity guidelines
- API route conventions
- Repository patterns
- Event naming conventions
Infrastructure Principles
New ADR added:
- ADR-0010: Capsule Isolation Enforcement
- Infrastructure Principles §2.1: API Capsule Context Resolution
- 72 commits
- 6 entities fixed for capsule isolation
- 23 API routes refactored
- 2 macros enhanced
- 5 documentation files improved
- 0 new features (all refinement)
What We Learned: Event Sourcing as a Verification Tool
Learning 1: Events Reveal Inconsistencies Humans Miss
The traditional approach:- Write code
- Write tests
- Code review
- Merge
Learning 2: Macros Are Force Multipliers - For Good and Bad
Before enforcement: DynamoDB macro made it easy to create entities. Also made it easy to forget capsule isolation. Impact:- 6 entities created without proper isolation
- Each one a potential data leak
- All passed code review (including AI verification)
- Reduces repetition
- Enforces correctness
- Fails at compile time (not runtime)
- Generates helpful error messages
- Just saves typing
- Allows incorrect patterns
- “Helpful” inference that’s sometimes wrong
Learning 3: Documentation Changes AI Behavior
Before CLAUDE.md patterns: Builder would ask: “Should this entity be capsule-isolated?” Verifier would check: “Does the implementation match the plan?” Problem: Neither had a reference for “what’s the standard pattern?” After CLAUDE.md patterns: Builder reads patterns first, applies them by default. Verifier checks: “Does this match the documented standard pattern?” Concrete example: Before (EntitlementEntity):Learning 4: Verification Is Not Just “Does It Work?”
Builder’s verification focus:- Does it compile? ✅
- Do tests pass? ✅
- Does it meet requirements? ✅
- Is this consistent with other entities?
- Does this follow documented patterns?
- What are the edge cases?
- What could go wrong in production?
Principles We Established
Principle 1: Compile-Time Enforcement > Runtime Checks
Principle 1: Compile-Time Enforcement > Runtime Checks
What we learned: Capsule isolation bugs made it to production because enforcement was runtime-only (tests).New rule: Architectural invariants MUST be enforced at compile time via macros or type system.Example:
Principle 2: Events Are the Truth, State Is the Cache
Principle 2: Events Are the Truth, State Is the Cache
What we learned: Event logs revealed bugs that state-based testing missed.New rule: When debugging data consistency issues, always start with event logs, not database state.Practice:
- Every operation emits events
- Event schemas are validated
- Schema inconsistencies = architectural violations
- AI agents analyze event patterns during verification
Principle 3: Documentation Is AI Context
Principle 3: Documentation Is AI Context
What we learned: CLAUDE.md patterns changed how Builder and Verifier approached tasks.New rule: Document architectural patterns proactively. AI will reference them.Format:
- Pattern name
- When to use it
- Code example
- Anti-patterns (what NOT to do)
- Rationale (why this pattern?)
Principle 4: Macros Must Fail Loudly
Principle 4: Macros Must Fail Loudly
What we learned: Macros that silently accept incorrect patterns are worse than no macros.New rule: Macros should validate ALL invariants and produce clear compile errors.Checklist for new macros:
- Validates all required fields exist
- Validates field types are correct
- Validates attribute patterns (e.g., PK format)
- Produces helpful error messages
- Has tests for invalid inputs (should not compile)
The Event Schema Validator
That event log warning wasn’t from production. It was from our test environment’s event analysis system. Event Schema Validator (Lambda function):Code Examples (Sanitized)
Here’s the final capsule-isolated entity pattern we established:- Zero capsule isolation bugs after enforcement
- Consistent PK/SK patterns across all entities
- Compile-time guarantees for security boundaries
- Clear audit trail via event sourcing metadata
Metrics
- Velocity
- Quality
- Cost
- Pattern Adoption
Planned work: Fix capsule isolation gapsActual work:
- 6 entities fixed for isolation ✅
- DynamoDB macro enhanced ✅
- API macro refactored ✅
- 23 routes updated ✅
- CLAUDE.md patterns added ✅
- Infrastructure ADR written ✅