Risks and Technical Debt
This section outlines potential architectural risks and the identified technical debt within Framework M.
11.1 Architectural Risks
| Risk | Impact | Mitigation Strategy |
|---|---|---|
| Dependency Injection Overload | Complexity in debugging and increased cognitive load for new developers. | Strict container patterns and clear create_container orchestration. |
| Protocol Fragility | Breaking the core Protocols (interfaces) will ripple across all adapters. | Semantic versioning and strict TDD for the framework-m-core package. |
| Performance Overhead | Metadata resolution and DI may add latency to high-frequency requests. | Compiled Pydantic Core (v2) and registry caching for metadata lookups. |
11.2 Identified Technical Debt
Based on the ongoing refactoring from legacy patterns (Frappe/Odoo), the following areas are identified as technical debt:
- Rate Limiting: Multi-level rate limiting (by IP and User) is planned but currently lacks a standardized middleware implementation.
- Log Redaction: Standardized processors for redacting secrets (passwords, tokens) from structured logs are in development.
- Mutation Idempotency: Support for
Idempotency-Keyheaders in mutation requests is not yet enforced across all repository implementations. - CSRF Protection: While SameSite cookies provide primary defense, a global CSRF verification middleware for distributed contexts is pending.
11.3 Debt Management
Technical debt is tracked via the anti-patterns.md registry. Every new feature implementation must pass a 10-point checklist (paginated queries, timezone-awareness, secret redaction, etc.) to prevent the accumulation of fresh architectural debt.