crm-bot-architecture-governance

To enforce ADR/RFC governance for crm_bot changes, identify the architectural scope and apply boundary rules across domain, application, and infrastructure layers. Changes touching architecture, domain boundaries, or deployment pipelines require an ADR or RFC, while minor updates need only a simple patch.

Architectural boundary governance separates domain, application, and infrastructure layers in crm_bot development to prevent regressions. It enforces ADR/RFC-aware boundary rules before patching code, ensuring changes align with existing architectural decisions.

Create an implementation plan for crm_bot changes by detailing affected files, boundary impacts, and ADR references. The plan must include validation steps and rollback options before patching, ensuring alignment with OpenAPI, frontends, auth, and queue/runtime contracts.

You need an ADR versus an RFC for code review changes based on architectural scope. Changes affecting domain boundaries, knowledge/RAG/eval pipelines, or deployment require RFCs, while specific architectural decisions need ADRs. Minor patches require neither, only standard code review.

You can patch crm_bot domain layers without an ADR only if the change does not alter architectural boundaries or infrastructure. Simple patches that stay within existing boundaries and do not touch deployment pipelines bypass the ADR/RFC governance process.

Required validation steps before patching crm_bot infrastructure include verifying alignment with OpenAPI/frontends, auth, and queue/runtime contracts. You must produce an implementation plan detailing affected files, boundaries, ADR references, and rollback options before applying the patch.