Archive legacy codebase for clean migration

[jonahgabriel]

Archive Legacy Codebase

This PR archives all legacy ONEX infrastructure components to enable clean domain-specific PR reviews.

What's Being Archived (286 files)

• Complete legacy source code from src_archived/
• Infrastructure nodes: postgres, consul, kafka adapters and orchestrators
• Models: health, infrastructure, observability, security, workflow
• Tests: integration, unit, load testing, and e2e
• Scripts: validation, migration, and intelligence hooks
• Documentation: templates, guides, and architectural decisions
• Deployment configs: Docker, database migrations, infrastructure

Why This Approach

• Clean Review Process: Separates code preservation from new implementation
• Manageable PR Size: Reduces main PR from 411 files to ~125 implementation files
• Clear Intent: Archive shows what's being replaced vs. what's being added
• Historical Preservation: All legacy code remains accessible in archive/

Next Steps After Merge

1. Create domain-specific PRs for new implementation:
   • Core health models (protocol-based architecture)
   • Infrastructure enums and shared components
   • Testing infrastructure and validation
2. Each domain PR will be focused and reviewable (~20-30 files)

Legacy Components Archived

• Service Adapters: Consul, Kafka, PostgreSQL, Vault integrations
• Processing Nodes: Compute, aggregation, wrapper components
• Architecture: Reducers, orchestrators, workflow coordination
• Monitoring: Health monitors, observability, metrics collection
• Security: Audit logging, encryption, rate limiting, TLS
• Testing: Comprehensive test suites for all components

This archival enables Phase 2 infrastructure migration to contract-driven ONEX architecture with strong typing and zero backwards compatibility.

[github-actions]

🔍 Pull Request Review for Archive Separation

I've completed a comprehensive review of PR #10 - Archive legacy codebase for clean migration.

✅ Overall Assessment: APPROVED with Recommendations

This is a well-structured archival PR that properly preserves legacy code while enabling clean migration to the ONEX contract-driven architecture. The approach aligns perfectly with the ZERO BACKWARDS COMPATIBILITY policy outlined in CLAUDE.md.

---

🎯 Strengths

1. Clean Separation Strategy

• ✅ Excellent approach to archive 286 legacy files rather than deleting them
• ✅ Preserves historical context while enabling fresh implementation
• ✅ Makes domain-specific PRs more manageable (~20-30 files each)

2. Architectural Alignment

• ✅ Follows ONEX infrastructure migration plan from CLAUDE.md
• ✅ Supports transition to contract-driven node architecture
• ✅ Enables strong typing enforcement (no Any types)

3. Code Organization

• ✅ Proper archival structure with clear categorization
• ✅ Maintains test suites for reference during migration
• ✅ Preserves documentation and templates for future use

---

🔒 Security Observations

Positive Security Practices

• ✅ No hardcoded credentials found in sampled files
• ✅ Proper use of environment variables and Docker secrets
• ✅ Security-first approach with credential manager fallback pattern

Example from postgres_connection_manager.py:79-100:

• Correctly reads credentials from environment or Docker secrets file
• Proper error handling with OnexError chaining
• No default passwords or connection strings

---

⚠️ Areas Requiring Attention

1. Import Path Inconsistencies

Some files show partial migration to omnibase_core:

• Line 19 in postgres_connection_manager.py: Correctly uses omnibase_core
• However, relative imports on line 54 suggest incomplete migration
• Recommendation: Since this is archive, these inconsistencies are acceptable but should be noted for new implementation

2. Pydantic V2 Migration

Observed use of legacy Pydantic patterns:

• Config class instead of model_config
• Field() patterns that may need updating
• Impact: Not critical for archive, but new implementations must use Pydantic V2

3. Missing Shared Model Pattern

Current structure doesn't fully implement the shared model pattern from CLAUDE.md:

• Models are node-specific rather than shared across infrastructure
• Next Steps: Phase 2 implementation should extract shared models to src/omnibase_infra/models/{service}/

---

📊 Performance Considerations

Connection Pooling Configuration

The ConnectionConfig shows good defaults:

• Min connections: 5
• Max connections: 50
• Inactive connection lifetime: 300s
• Recommendation: Document these settings for new implementation reference

---

🚀 Recommendations for Next Steps

1. Phase 1: PostgreSQL Adapter Node (Per CLAUDE.md)

Create message bus bridge pattern implementation:

• Contract-first approach with contract.yaml
• Shared models in src/omnibase_infra/models/postgres/
• Node-specific adapter models only

2. Domain-Specific PR Strategy

Suggested PR breakdown for Phase 2:

1. Core health models with protocol-based architecture
2. Infrastructure enums and shared components
3. Service adapters (Consul, Kafka, Vault)
4. Processing nodes and orchestrators
5. Testing infrastructure

3. Migration Validation Checklist

For each new implementation PR:

• Contract-driven with complete contract.yaml
• Strong typing (zero Any usage)
• Proper OnexError chaining with CoreErrorCode
• Shared model pattern implementation
• Container injection pattern (ONEXContainer)

---

💡 Best Practices Observed

1. Error Handling: Proper use of OnexError with chaining
2. Documentation: Comprehensive docstrings and type hints
3. Security: No hardcoded secrets, proper credential management
4. Testing: Preserved test suites for migration reference

---

✅ Conclusion

This archival PR successfully preserves legacy infrastructure while setting up for clean contract-driven migration. The approach reduces review complexity and maintains historical context.

Approval Recommendation: Merge this PR to unblock domain-specific implementation work.

---

Review conducted following ONEX Infrastructure standards and ZERO BACKWARDS COMPATIBILITY policy