# TRAIL DPS - V1 collaborative SAS - LOT 1 Workspace

## Statut du livrable

Livraison incrémentielle de recette du LOT 1. Tous les fichiers de ce ZIP sont nouveaux : aucun fichier des projets PLACE, Licence, Tracking, Fil de Course ou mobile existants n'est remplacé.

Le LOT 1 doit être déployé et validé sur l'environnement de recette avant le démarrage du LOT 2 PLACE.

## Périmètre réalisé

- Nouveau projet indépendant `traildpsworkspace` en PHP 8.
- Base dédiée `synoluisharing` et migration SQL versionnée.
- Authentification workspace, access tokens signés, refresh tokens rotatifs et révocables.
- Organisations, souscriptions projetées, utilisateurs, invitations, rôles et gestion des révocations.
- Réinitialisation administrée des mots de passe avec jeton à usage unique.
- Événements collaboratifs, révisions immuables, snapshots JSON compressés, checksums SHA-256 et concurrence optimiste.
- Manifest des objets par révision et changements `CREATE`, `UPDATE`, `UNCHANGED`, `DELETE`.
- Projection normalisée des données préparatoires autorisées : courses, traces GPX, POI, configurations, liaisons, équipes, missions et course staff.
- Liste noire stricte des données LIVE, Tracking, météo, caches et secrets.
- Verrous collaboratifs consultatifs de 15 minutes.
- Idempotence des créations, publications, uploads et restaurations.
- Photos POI privées hors webroot : JPEG/PNG, 10 Mo, 8 000 x 8 000 px, hash, versions, corbeille et restauration.
- Purge des binaires après 30 jours et purge différée des métadonnées après 365 jours.
- Audit métier par organisation, événement, utilisateur, poste et request ID.
- Inventaire initial des `course_uuid` et calcul de consommation collaborative locale.
- Scripts de migration, bootstrap administrateur, purge, intégrité, usage, sauvegarde et vérification.
- Documentation de déploiement, API, tests et sauvegarde/restauration.

## Garde-fous respectés

- Aucune table LIVE ou Tracking n'est créée dans la base collaborative.
- Les clés `remote_tracking_*`, runs, incidents, positions, demandes coureur, météo, route cache, tokens devices et `photo_blob` sont rejetées dans les snapshots.
- Les applications mobiles ne sont pas modifiées et n'appellent pas le workspace.
- Aucun accès SQL distant n'est prévu depuis PLACE : le futur LOT 2 utilisera exclusivement l'API HTTPS.
- Les fichiers photo sont stockés sous `storage/private/TRAILDPS-partage`, hors du document root `public`.
- Les secrets ne sont pas livrés : `config/config.php` doit être créé localement à partir de `config/config.example.php`.

## Arborescence livrée

- `public/` : front controller, réécriture Apache et point d'entrée API.
- `SRC/Auth/` : comptes, tokens, rôles, invitations et utilisateurs.
- `SRC/Collaboration/` : événements, snapshots, projections, conflits, audit, usage et inventaire.
- `SRC/Files/` : validation, stockage et historique des photos.
- `SRC/Licence/` : entitlements et client interne préparatoire.
- `SRC/Infrastructure/` : configuration, PDO, HTTP, sécurité, HMAC, UUID, logs, migrations et idempotence.
- `sql/migrations/` : schéma initial rejouable.
- `scripts/` : exploitation et maintenance.
- `tests/` : tests automatisables sans dépendance externe.
- `storage/` : répertoires privés, quarantaine, logs et sauvegardes.
- `docs/` : suivi et procédures.

## Validations exécutées avant livraison

- `php -l` sur tous les fichiers PHP : succès.
- Tests unitaires et contractuels `tests/run.php` : 11/11 succès dans la maintenance 1.0.6-lot1 ; référence de recette 1.0.5-lot1 : 10/10.
- Contrôle UUID v4 et UUID v5 déterministe : succès.
- Contrôle JSON canonique : succès.
- Contrôle politique de mot de passe : succès.
- Contrôle image PNG réelle par `finfo` et `getimagesize` : succès.
- Contrôle statique des tables essentielles du schéma : succès.
- Contrôle de rejet d'un snapshot contenant une donnée LIVE : succès.
- Contrôle d'absence de fichier mobile et d'absence de modification des projets historiques : succès.

## Validation restant à réaliser en recette

L'environnement de génération ne dispose pas d'un serveur MySQL/MariaDB. La migration et les scénarios API avec base réelle doivent donc être exécutés sur `synoluisharing_staging` avant validation définitive du lot. Les étapes et preuves attendues sont décrites dans `TESTS_RECETTE_LOT_1.md`.

## Rollback du LOT 1

Le rollback ne supprime aucune table et ne modifie aucun service historique. Il consiste à :

1. désactiver le sous-domaine ou le pointer vers une page de maintenance ;
2. arrêter les tâches planifiées du workspace ;
3. conserver la base et le stockage privés pour analyse ;
4. restaurer uniquement depuis une sauvegarde coordonnée si une corruption est démontrée.

PLACE, Licence, Tracking et mobile restent inchangés pendant ce lot.

## Correctif de paramétrage 1.0.1 - nom de base

À la demande du porteur de projet, le nom définitif de la base collaborative est désormais `synoluisharing`.
Cette décision remplace la dénomination technique figurant dans la spécification initiale.
Pour une recette isolée, le nom recommandé est `synoluisharing_staging`.
Aucune table, colonne, migration métier ni route API n'est modifiée par ce correctif.


## Maintenance 1.0.6-lot1 préalable au LOT 2

Cette maintenance additive ne modifie ni le schéma MySQL, ni les routes API, ni les contrats PLACE/mobile. Elle ajoute `config/config.example.php`, le scanner `scan_orphan_files.php`, le service `OrphanFileScanner`, une quarantaine non destructive, un contrôle de réserve disque à 20 % dans `verify_installation.php` et des règles de package sans secret.