# Architecture et reprise du projet

Application PHP Laravel 13, Livewire 4 utilisé pour la saisie rapide ; vues Blade pour les autres écrans ; CSS et JavaScript statiques sans outil de compilation. Pas de WordPress, pas de React, pas de dépendance front distante ni de police externe embarquée.

## Principaux emplacements

- `app/Models` : données et relations.
- `app/Http/Controllers` : opérations web et validation.
- `app/Http/Middleware` : accès administrateur, compte actif, en-têtes.
- `app/Livewire/QuickCapture.php` : capture minimale avec contrôle de rôle à chaque action.
- `app/Services/ContextResolver.php` : cohérence client/projet.
- `app/Services/ImageStorage.php` : contrôle et réencodage des logos.
- `app/Services/AssistantService.php` : appels IA sans outils d’écriture.
- `app/Support/Money.php` : montants en centimes, durées en minutes et calculs déterministes.
- `routes/web.php` : aucun accès administrateur anonyme, pas d’inscription libre.
- `routes/console.php` : installation, diagnostic, récupération de mot de passe et démonstration locale.
- `resources/views` : écrans.
- `public/assets` : styles, comportement léger et icônes.
- `database/migrations` : création du schéma.
- `tests` : scénarios PHPUnit à exécuter après installation.

## Modèle de données

Un client possède plusieurs projets. Une tâche/une note peut rester sans client/projet, ou être rattachée à un projet qui impose son client. Le client d’un projet ne peut pas être changé par une simple édition, pour empêcher un transfert involontaire de documents déjà partagés.

Les comptes sont administrateurs ou clients. Un compte client est rattaché à une seule organisation. Le pilote est conçu pour un seul indépendant administrateur, pas un SaaS multi-tenant.

Un document appartient à un client, éventuellement à un projet. La route de téléchargement vérifie rôle, activation du portail, appartenance au client, partage du document et partage du projet parent. Le nom et le chemin de stockage ne viennent pas d’un paramètre libre fourni à la route.

Les projets publics dans le portail ne dévoilent que titre, statut et échéance. Les notes/documents nécessitent un partage séparé. L’administrateur garde un aperçu filtré, sans usurpation de session client.

Les créneaux sont distincts des déclarations de temps. Une confirmation de créneau crée au maximum une déclaration, protégée par contrainte unique et transaction. Les estimations de projet ne sont pas modifiées par les créneaux. Les changements numériques de budget sont conservés dans le journal d’actions, sans écran d’historique détaillé dans cette version.

Les références de facturation sont des repères manuels (projet, nature, numéro, montant déclaré, URL HTTPS). Aucune donnée n’est considérée comme synchronisée ou comptablement vérifiée.

## Assistant

Le modèle n’a aucune connexion directe à la base et aucun outil d’écriture. Le contrôleur sélectionne un projet et construit un contexte limité, visible par l’utilisateur. Les réponses sont affichées comme du texte échappé, pas du HTML actif. Les prompts provenant de notes sont des données, mais leur innocuité sémantique n’est pas garantie : l’absence de capacité d’action limite les conséquences d’une injection de prompt.

Aucun moteur ne fonctionne par défaut. Les clés restent côté serveur. Pas de repli cloud automatique depuis le local, ni d’intégration MCP livrée. Les connecteurs externes pourront être développés après stabilisation des règles métier et tests de permissions.

## Maintenabilité

Conserver le code et le lock dans un dépôt sous votre contrôle. Éviter les correctifs directement en production. Ajouter une migration à chaque évolution de structure au lieu de modifier une migration déjà exécutée. Écrire un test reproduisant un bug avant sa correction lorsque possible.

Cette archive n’installe aucun accès développeur ou « porte dérobée ». Aucun diagnostic ni télémétrie n’est envoyé automatiquement. Les appels externes éventuels sont uniquement ceux d’un moteur IA explicitement configuré et invoqué avec consentement.