fix: ignore CVE-2026-7598 in Trivy scan (libssh2, no fix available)

[Kaiohz]

Summary

• Add CVE-2026-7598 (libssh2-1 integer overflow) to .trivyignore
• No fixed version available in Debian bookworm, status: affected
• Revert unnecessary apt-get upgrade in Dockerfile

[Kaiohz]

Code Review — PR #34: Bricks Integration + Trivy Fix

Score: 8/10 ✅

Cette PR fait beaucoup de choses mais le fait bien. Architecture propre, tests solides, documentation à jour.

---

✅ Points positifs

1. Architecture hexagonale respectée

• BricksApiPort (domain) → BricksApiAdapter (infrastructure) → Use cases → MCP tools
• Le pattern Ports & Adapters est suivi rigoureusement
• Dependency injection via dependencies.py comme les autres modules

2. Tests complets (431 lignes pour l'adapter + 224 pour le port + 97 use case + 322 MCP tools)

• Couverture des cas d'erreur (401, 403, 404, timeout, connection error)
• Tests du modèle BricksDocumentInfo avec camelCase → snake_case mapping
• Tests du dry-run dans PublishSectionVersionUseCase
• Fixtures réutilisables dans conftest.py

3. MCP tools bien structurés

• 3 outils cohérents : list_bricks_documents, read_bricks_document, publish_section_version
• Dry-run par défaut (BRICKS_PUBLISH_DRY_RUN=true) — sécurité pour le dev
• Error handling avec ToolError de FastMCP

4. Documentation README mise à jour

• Architecture diagram mis à jour avec le 4e serveur MCP
• Table de config BricksConfig documentée
• Endpoint /bricks/mcp ajouté

5. .trivyignore — CVE-2026-7598

• Commentaire clair avec date de review et raison (no fix available)
• Cohérent avec le format existant

---

⚠️ Points à améliorer

1. read_bricks_document — double appel API (MINEUR)
download_document dans l'adapter appelle d'abord list_project_documents pour résoudre l'URL du document. Pour un seul document, ça fait 2 requêtes HTTP. Pour le MVP c'est acceptable, mais à terme considérer un endpoint direct ou un cache.

2. BricksApiAdapter utilise urllib au lieu de httpx (MINEUR)
Le reste du projet utiliserait httpx (standard async Python). L'usage de urllib.request avec asyncio.to_thread fonctionne mais est moins idiomatique. Pas bloquant pour un MVP.

3. read_bricks_document — paramètres document_id + project_unique_id
L'outil MCP read_bricks_document demande les 2 paramètres. Le MCP tool README doc dit file_url comme paramètre mais le code utilise document_id + project_unique_id. La doc dans le README est cohérente avec le code, mais le parameter file_url dans la doc du README est incorrect — c'est bien document_id dans le code.

4. Fichier bricks_api_adapter.py — manque un newline final
_extract_filename → pas de newline à la fin du fichier. Mineur mais les linters flaggent ça.

5. workflow_name default incohérent (MINEUR)
Dans le MCP tool, workflow_name default = "agent-haiku-files-v1" mais dans la doc README il est dit "haiku-files". Le code et la doc devraient matcher.

6. Aucun test d'intégration / E2E pour le endpoint /bricks/mcp
Les tests unitaires sont solides mais il manque un test qui vérifie que le endpoint FastAPI est bien monté et répond. Les autres modules (query, classical) ont-ils ces tests ?

---

🏗️ Scope concern

La PR mélange deux choses :

• Feature : Intégration Bricks (4e serveur MCP)
• Fix : Trivy ignore CVE-2026-7598 + revert Dockerfile + formatting

Ce n'est pas bloquant, mais en général c'est préférable de séparer les PRs feature/fix pour faciliter les reviews et les rollbacks.

---

Résumé

Aspect	Note
Architecture	✅ Hexagonale, clean
Tests	✅ Couverture solide, erreurs testées
Documentation	✅ README à jour
Error handling	✅ Domain exceptions, ToolError
Sécurité	✅ Dry-run par défaut
Formatting	⚠️ Quelques incohérences mineures
Scope PR	⚠️ Feature + fix mélangés

Verdict : PR approuvée avec suggestions mineures. La qualité est bonne, l'architecture est cohérente avec le reste du projet. Les points d'amélioration sont non-bloquants pour le merge.