00 check v3 mvp

🛠️ Architect's Audit: V3.0 Critical Priorities

The following points reinforce the specific constraints we established to maintain the performance and integrity of the Masala Lite Monolith.

  1. OpenAPI/Swagger Documentation (Item 2)

Mandate Enforcement: We must ensure the "Generic" Trap is eliminated at the API boundary. The XML documentation must explicitly link the API contract to the configuration files.

Action: When documenting the DomainId field in the DTO, the XML summary must state: "The valid set of domain IDs is entirely governed by the structure keys in masala_domains.yaml. Any change requires a configuration update and delegate recompilation by the RuleCompilerService."
  1. Structured Logging with Correlation (Item 3)

Mandate Enforcement: The context for our logging must align with the Universal Entity Model (UEM). While the file references TicketId and ProjectId, we will push the generic names into the LogContext.

Action: The correlation middleware/enricher must push three key properties into the LogContext when processing a request or a WorkItem from the channel:

    CorrelationId (Request/Operation-level tracing)

    WorkItem.Id (The unique ticket ID)

    WorkContainer.Id (The project/grouping ID)
  1. Integration Test Fixtures (Item 4)

Mandate Enforcement: This is critical for upholding SQLite Performance Discipline.

Action: The TicketBuilder.Build() method must replicate the logic of SQLite Generated Columns for any indexed JSON field. Example: If we have a generated column CustomerTier derived from CustomFieldsJson, the builder must calculate CustomerTier in C# and set it on the Ticket entity before returning it. This guarantees that any integration test using the builder will accurately reflect the production database state, preventing false negatives where tests pass locally but fail due to SQL queries relying on a missing generated column value.
  1. ML.NET Model Persistence (Item 5)

Mandate Enforcement: This directly addresses the requirement for reproducibility by linking the AI to the configuration it was trained on.

Action: The ModelPersistenceService.SaveModelAsync method must update the ModelInfo entry in the database (or a metadata file) with the current, active DomainConfigVersion.Id at the time of saving. Implementation Note: When ModelPersistenceService.LoadModel is called, it should optionally be able to check the loaded model's version against the current DomainConfigVersion to trigger an alert if the model is running on stale configuration rules.

Conclusion

The v3.0 MVP is sound and adheres to all architectural constraints. The next immediate step, as outlined in your plan, is the Configuration Hot Reload and AI Explainability API.

I have already drafted the Implementation Specification for DomainConfigService Hot Reload, including the necessary MermaidJS Sequence Diagram and the atomic swap logic (Interlocked.Exchange) required by the "Compile, Don't Interpret" mandate.

Would you like to review the draft for the Configuration Hot Reload spec now, or do you have any immediate questions about the Critical Priority mandates I just audited?