# LOT 1 — Hotfix concurrence et révisions des photos POI — V1.0.3

## Objet

Ce hotfix corrige l’écart constaté pendant la recette du remplacement de photo POI : le fichier et son historique étaient correctement versionnés, mais `pois.object_version` et `events.current_revision` n’étaient pas incrémentés.

La spécification impose que l’upload, le remplacement et la restauration reçoivent `expected_poi_version` et `expected_event_revision`, puis créent atomiquement une nouvelle version du POI et une nouvelle révision complète de l’événement.

## Fichiers modifiés ou créés

- `public/index.php`
- `SRC/Files/PhotoService.php`
- `SRC/Files/PhotoSnapshotMutator.php` — nouveau
- `SRC/Collaboration/SnapshotService.php`
- `tests/run.php`
- `docs/API_WORKSPACE_V1.md`
- `VERSION`
- `MANIFEST_SHA256.txt`

## Modifications fonctionnelles

### Upload et remplacement

Le multipart doit désormais contenir :

- `photo` ;
- `expected_event_revision` ;
- `expected_poi_version`.

L’opération :

1. verrouille l’événement et le POI en base ;
2. compare les versions attendues ;
3. refuse tout décalage en HTTP `409 REVISION_CONFLICT` ;
4. crée le nouveau `file_uuid` et la nouvelle `poi_photo_version` ;
5. place l’ancienne version en corbeille pendant 30 jours ;
6. incrémente `pois.object_version` ;
7. crée une nouvelle révision complète dans `event_revisions`, `event_snapshots` et `event_revision_objects` ;
8. met à jour `photo_metadata` dans le snapshot ;
9. incrémente `events.current_revision` dans la même transaction.

### Restauration

Le corps JSON doit désormais contenir :

```json
{
  "expected_event_revision": 3,
  "expected_poi_version": 2
}
```

La restauration réactive le fichier demandé, place la photo précédemment courante en corbeille et crée atomiquement une nouvelle version du POI et une nouvelle révision d’événement.

### Quota

Le calcul du quota applicatif inclut désormais les fichiers `ACTIVE` et `TRASHED`, conformément à la règle de conservation des binaires restaurables.

## Réponses enrichies

Les réponses d’upload, remplacement et restauration contiennent désormais :

- `poi_object_version` ;
- `event_revision` ;
- `base_revision`.

## Déploiement

1. Fusionner le contenu du ZIP dans la racine `traildpsworkspace-staging`.
2. Remplacer uniquement les fichiers présents dans le ZIP.
3. Ne pas modifier `config/config.php`.
4. Aucune migration SQL n’est nécessaire.
5. Exécuter :

```bash
cd ~/programme/traildpsworkspace-staging
php -l SRC/Files/PhotoSnapshotMutator.php
php -l SRC/Files/PhotoService.php
php -l SRC/Collaboration/SnapshotService.php
php -l public/index.php
php tests/run.php
cat VERSION
```

Résultats attendus : aucune erreur de syntaxe, `10/10 tests réussis.` et version `1.0.3-lot1`.

## Reprise de la recette

La base de recette peut conserver les photos V1 et V2 déjà créées. Après déploiement, la restauration de V1 doit être appelée avec les versions courantes de l’événement et du POI. Elle doit alors :

- créer la révision d’événement suivante ;
- incrémenter la version du POI ;
- rendre V1 courante ;
- placer V2 en corbeille ;
- refuser un rejeu avec des versions obsolètes en `409 REVISION_CONFLICT`.