Module conformity_response 

Track H Story H2 — Helper handlers Actix : convertir une erreur String préfixée "BUILDING_NOT_CONFORMANT:" (use-cases legacy Result<_, String>) en réponse HTTP 422 narrative compatible avec le payload <ConformityToast> / <ConformityBanner> côté frontend (Story H1).

Pourquoi cette gymnastique ? Les use-cases historiques (expense, call_for_funds, charge_distribution, etat_date) renvoient Result<_, String>. Le bridge From<BuildingNotConformantError> for String (livré par H1) sérialise l’erreur en string structurée :

"BUILDING_NOT_CONFORMANT: building <uuid> units_delta=<i32> quota_delta=<dec> quota_basis=<i32>"

Refactor signature use-case → Result<_, AppError> est hors-scope (mémoire validate-before-compute). On parse donc le préfix au niveau handler pour garder le 422 narratif (kind=building_not_conformant, details.code= BUILDING_NOT_CONFORMANT, units_delta, quota_delta, quota_basis).

Sans match du prefix, le caller fallback sur son comportement 400/500 habituel.

TODO Track H Story H2 — audit security_incident : la story exige d’insérer un row security_incidents (type BUILDING_NOT_CONFORMANT) pour chaque tentative bypass. Option 1 (middleware Actix qui inspecte le 422) hors-scope v0.1.0 — ajout middleware = nouveau layer d’application non trivial. Option 2 (inline dans chaque handler) = duplication + nécessite injection SecurityIncidentRepository dans AppState côté handlers. Reporté en Story H4 (audit middleware). Le pre-check + 422 narratif reste OK fonctionnellement — l’audit n’est que de la trace.

Functions

try_build_conformity_response

Si l’erreur use-case correspond à "BUILDING_NOT_CONFORMANT: ..." ou "ACP_NOT_CONFORMANT: ...", retourne un HttpResponse 422 avec le payload narratif. Sinon, None → caller continue son code path (400/500).