[Topic Unique] Claude by Anthropic

Le prompt est déjà solide sur l’intention fonctionnelle. Ce qui manque surtout, c’est ce qui empêche Codex de prendre des décisions d’architecture discutables à ta place.
 
Les gros manques
 
1. Le modèle exact d’un tracking actif
 
Tu ne définis pas clairement :
 
* un seul tracking par Radio ou plusieurs ;
* si un même Radio peut avoir map tracking + camera following simultanément ;
* ce que fait register si le device est déjà enregistré ;
* si un nouvel enregistrement remplace l’ancien, fusionne les actions ou throw.
 
C’est probablement le plus gros trou du prompt.
 
À préciser explicitement, par exemple :
 
A Radio device may have both map tracking and camera following active at the same time. There must never be more than one active action of each type for a given Radio. Registering an already active action should [replace it / throw].
 
⸻
 
2. L’identité canonique du device
 
Tu dis « instance of Radio class », mais le manager doit probablement indexer les trackings dans une Map.
 
Il faut dire quelle clé utiliser :
 
* object identity ;
* radio.id ;
* datasource ID ;
* autre identifiant stable.
 
Sinon Codex risque de faire :
 
new Map([[radio, tracking]])
 
alors que deux instances Radio représentant le même véhicule pourraient exister.
 
Il faut exiger :
 
Verify how Radio instances are identified across datasource refreshes and use the existing stable device identity pattern. Do not assume object identity is stable.
 
⸻
 
3. Les signatures et types doivent être découverts avant de concevoir
 
Tu dis « endpoint », puis « public method ». C’est ambigu.
 
RadioTrackerService est-il :
 
* un service frontend ?
* un manager JS interne ?
* une API HTTP ?
* un singleton ?
 
Tu devrais dire :
 
“Register endpoint” means a public service method, not an HTTP endpoint, unless the current architecture proves otherwise.
 
Sinon le mot endpoint peut l’envoyer complètement dans la mauvaise direction.
 
⸻
 
4. Sémantique exacte des événements Radio
 
Tu dis « subscribe to an emitter », mais il manque :
 
* quel événement doit déclencher le tracking ;
* payload attendu ;
* ordre garanti ou non ;
* timestamps présents ou non ;
* événements dupliqués possibles ;
* anciennes positions pouvant arriver après une nouvelle ;
* définition de off.
 
Très important pour les races.
 
Ajoute :
 
Before designing concurrency handling, inspect and document the exact Radio location/off event semantics: payload type, timestamps, ordering guarantees, duplication possibilities and lifecycle of Radio instances.
 
⸻
 
5. Tu demandes un counter, mais pas la vraie règle de concurrence
 
Le compteur de génération est bon, mais tu dois définir à quel niveau.
 
Il faut probablement un compteur :
 
* par device ;
* par action ;
* pas global.
 
Sinon une update du véhicule A pourrait invalider une requête du véhicule B.
 
Écris clairement :
 
Concurrency/version counters must be scoped per tracked device and per tracking action. An update for one Radio or one action must never invalidate work for another one.
 
Et surtout :
 
Obsolete results must not mutate state, map features or Videoapp layouts.
 
⸻
 
6. Tu ne précises pas s’il faut annuler les requêtes ou seulement ignorer les réponses
 
« discard obsolete ones » peut vouloir dire :
 
* AbortController ;
* compteur uniquement.
 
Il faut demander d’inspecter les API clients pour voir le pattern existant.
 
Prefer the existing cancellation pattern if API clients support request abortion. Otherwise use generation/version counters and discard stale results. Do not introduce a new cancellation abstraction only for this feature.
 
⸻
 
7. Le comportement en cas d’erreur API est absent
 
Que se passe-t-il si :
 
* history API fail ;
* camera proximity helper fail ;
* Videoapp GET fail ;
* Videoapp POST fail ;
* payload API invalide ?
 
Actuellement Codex doit inventer.
 
Il faut définir au minimum :
 
A transient API failure must not unregister tracking. Keep tracking active and allow the next location event to retry naturally. Do not clear the current map line or camera layout on failed refreshes. Follow existing logging/error reporting patterns.
 
Et décider si toast ou non. Personnellement : pas de toast à chaque erreur de refresh, risque de spam.
 
⸻
 
8. Le timeout d’inactivité est sous-spécifié
 
« not sending a message for more than N minutes » :
 
Message de quoi ?
 
* n’importe quel message Radio ;
* location update uniquement ;
* heartbeat ;
* datasource event ?
 
Et le timer commence :
 
* au register ;
* à la dernière position connue ;
* à la dernière nouvelle position reçue après register ?
 
Il faut définir.
 
Par exemple :
 
Inactivity means no location event received from the tracked Radio. The inactivity timer starts at registration and is reset on every accepted location event.
 
Il faut aussi préciser si N = 0 désactive le timeout.
 
⸻
 
9. Cleanup incomplet
 
Quand tu unregister :
 
* unsubscribe emitter ;
* cancel timer ;
* invalidate in-flight generations ;
* supprimer la line feature ?
* restaurer caméra layout précédent ?
* ne rien restaurer ?
 
Le map tracking est particulièrement ambigu.
 
Tu dis temporaire layer, mais est-ce que la ligne disparaît à l’unregister ? Probablement oui.
 
Pour les caméras, ne surtout pas laisser Codex décider s’il restaure l’ancien layout.
 
Ajoute :
 
On unregister, fully release listeners, timers and per-action state and invalidate in-flight work. Map tracking must remove its temporary feature. Camera following must not restore any previous Videoapp layout unless an existing application pattern explicitly requires it.
 
⸻
 
10. La création de la feature map n’est pas décrite
 
Tu expliques comment l’update, mais pas :
 
* quand elle est créée ;
* geometry initiale ;
* ID/properties ;
* style ;
* quelle temporary layer ;
* si elle existe déjà.
 
Tu devrais imposer :
 
Inspect the existing temporary feature/layer APIs and reuse their feature creation, identification and removal patterns. The plan must identify exactly how a tracking feature is created, looked up, updated and removed.
 
⸻
 
11. Ramer-Douglas-Peucker est probablement mal nommé et insuffisamment défini
 
Le nom courant est Ramer–Douglas–Peucker.
 
Surtout, tu dis « parameters », sans nommer :
 
* epsilon/tolerance ;
* unité ;
* éventuellement max points ?
 
Codex ne doit pas inventer le contrat API.
 
Il faut écrire :
 
Do not infer the Radio history API parameters from the algorithm name. Inspect the backend/API contract or existing generated API definitions and document the exact parameter names, units and validation ranges.
 
⸻
 
12. La règle de dédup caméra est encore ambiguë
 
Tu dis :
 
or just switch them 1 becomes 2 and 2 becomes 1
 
Donc tu sembles dire que l’ordre des caméras ne compte pas pour décider si on POST.
 
Mais ensuite en merge mode, les first two entries sont remplacées. Là l’ordre peut changer le layout.
 
Il faut définir clairement la comparaison.
 
Probablement :
 
Camera selection deduplication must compare camera identities as an unordered set. A pure permutation of the same selected cameras must not trigger a layout update.
 
Mais attention : si l’ordre représente la proximité, alors ne pas publier le changement signifie que la caméra la plus proche ne passe pas en tile 1. C’est une décision métier réelle.
 
C’est un point que ton prompt doit explicitement laisser comme question ouverte dans le plan.
 
⸻
 
13. Que mettre dans les tiles manquantes ?
 
Cas demandé : 4 caméras, seulement 2 trouvées.
 
Full takeover :
 
* layout de 2 tiles ?
* layout de 4 avec 2 tiles vides ?
* répéter ?
* placeholders ?
 
Tu sembles dire « complete layout with only the two cameras found », donc layout réduit à 2. Mais tes tailles full takeover autorisées sont 1, 4, 9, 10, 16.
 
Contradiction.
 
Exemple :
 
* requested count = 9 ;
* only 6 nearby cameras exist.
 
Quel layout POSTER ?
 
C’est une ambiguïté majeure.
 
⸻
 
14. wanted number of tiles et number of cameras sont mélangés
 
Ce ne sont pas nécessairement les mêmes concepts.
 
Tu utilises :
 
* wanted number of tiles ;
* wanted number of cameras ;
* cameras count ;
* requested count.
 
Il faut choisir un concept et un nom métier unique.
 
Par exemple :
 
cameraCount
 
= maximum number of nearby cameras selected and published.
 
Puis expliquer ce que devient le layout avec moins de résultats.
 
⸻
 
15. Définition exacte de « close cameras »
 
Tu dis « camera service helper », mais il faut interdire de recréer l’algorithme.
 
Reuse the existing camera proximity helper and its existing ordering semantics. Do not implement a new geographic distance or camera-ranking algorithm.
 
Il faut aussi vérifier si le helper renvoie :
 
* enabled cameras ;
* accessible cameras ;
* sorted by distance ;
* doublons éventuels.
 
Le plan doit le documenter.
 
⸻
 
16. Race critique en merge mode
 
Scénario :
 
1. position A ;
2. GET layout ;
3. position B ;
4. GET layout ;
5. B POST ;
6. A POST.
 
Le compteur doit être vérifié avant le POST, mais potentiellement aussi après le GET et avant toute mutation.
 
Plus subtil : un utilisateur modifie manuellement Videoapp entre GET et POST.
 
Ton système peut écraser son changement avec un layout obsolète.
 
Il manque une décision sur cette race externe.
 
À minima :
 
The plan must explicitly analyse the read-modify-write race in merge mode. Verify whether Videoapp exposes revision/version/ETag semantics. If not, document the unavoidable race rather than pretending the generation counter solves concurrent external layout changes.
 
Ça, c’est important techniquement.
 
⸻
 
17. Dédup basée sur quoi ?
 
Il faut définir les identifiants caméra utilisés pour comparer.
 
Pas les objets complets, sinon un changement de metadata peut provoquer un POST.
 
Deduplicate camera selections using the stable camera identity already used by Videoapp/layout payloads, not object equality or full serialized camera objects.
 
⸻
 
18. État UI et service pas défini comme réactif
 
Tu dis :
 
If tracking is already active, show instead a button to unregister it.
 
Comment le composant sait qu’il est actif ?
 
Il faut probablement :
 
* query method isTracking(...) ;
* observable/emitter ;
* reactive state.
 
Sinon Codex va bricoler avec un state local du popup, qui devient faux si self-unregister intervient.
 
Très gros manque.
 
Ajoute :
 
UI tracking state must come from RadioTrackerService, not local component state, because tracking can self-unregister asynchronously. Inspect existing reactive service/state patterns and use one of them so open UI components update when tracking starts or stops.
 
⸻
 
19. Popup détruite/recréée
 
Lié au point précédent.
 
Le popup peut fermer puis rouvrir. Le bouton doit toujours afficher le vrai état.
 
Il faut l’imposer explicitement.
 
⸻
 
20. Map et camera doivent probablement avoir deux boutons d’arrêt distincts
 
Si map + camera peuvent être actifs ensemble, ton texte :
 
show instead a button to unregister it
 
est insuffisant.
 
Unregister quoi ?
 
* tout le device ;
* map seulement ;
* camera seulement ?
 
Donc tu dois d’abord définir le modèle d’action du point 1.
 
⸻
 
21. Validation insuffisamment spécifiée
 
Tu parles de validate*, mais il faut demander les invariants métier :
 
* timeout > 0 ;
* cameraCount appartient à la liste selon mode ;
* Videoapp client valide ;
* start timestamp valide ;
* RDP params ;
* action discriminée correctement.
 
Je demanderais un discriminated action payload, si le style du code le permet :
 
{
    type: 'map',
    ...
}
 
ou
 
{
    type: 'camera',
    ...
}
 
Mais il faut dire de vérifier les conventions existantes avant.
 
⸻
 
22. Pas de critères d’acceptation
 
C’est l’autre gros manque.
 
Sans acceptance criteria, Codex peut considérer le travail terminé avec des cas limites cassés.
 
Je mettrais obligatoirement :
 
Acceptance criteria
 
* Two different Radio devices can be tracked concurrently without interfering with each other.
* Map and camera actions do not invalidate each other’s asynchronous work.
* Stale API results never mutate the map or publish Videoapp layouts.
* Self-unregister releases all listeners and timers and stale pending work becomes harmless.
* UI immediately reflects a self-unregister.
* Reopening a Radio popup reflects the real current service state.
* A failed refresh keeps tracking active.
* An unchanged camera selection does not POST a new layout.
* A pure permutation of camera selection [does/does not] POST — explicitly decide during planning.
* Existing tests, lint and type checks pass.
 
⸻
 
23. Tests
 
Tu n’en parles quasiment pas.
 
Vu le niveau de concurrence, les tests sont obligatoires.
 
Ajoute :
 
The implementation plan must include focused tests for per-device concurrency, stale async results, unregister during in-flight work, inactivity timeout reset, Radio off events, camera deduplication, merge behavior for layouts smaller/equal/larger than requested count, and UI state after self-unregister. Use fake timers where appropriate and follow the existing test stack.
 
⸻
 
24. Tu devrais explicitement interdire de coder au premier tour
 
Ton introduction dit qu’il faut planifier, mais Codex peut quand même commencer les modifications.
 
Ajoute tout à la fin :
 
For this first iteration, do not modify any file. Inspect the repository and return only:
 
1. the relevant existing architecture and patterns,
2. exact files/classes involved,
3. ambiguities or contradictions found in this request,
4. a proposed state model and public API,
5. a phased implementation plan,
6. questions that require a product decision.
 
Do not provide generic recommendations. Ground every architectural statement in the actual repository with file and symbol references.
 
Mon avis critique
 
Les 5 points réellement dangereux actuellement sont :
 
1. Tu n’as pas défini si map et camera peuvent coexister pour un même Radio.
2. Tu n’as pas défini l’identité stable d’un Radio.
3. La sémantique caméra quand moins de N caméras existent est contradictoire avec les tailles de layout autorisées.
4. L’UI n’a aucun mécanisme défini pour apprendre un self-unregister.
5. Le compteur de concurrence ne résout pas la race GET → merge → POST avec une modification externe du Videoapp.
 
Le reste est améliorable. Ces cinq-là peuvent réellement conduire à une architecture fausse

# Goal

I need to add a system being able to track a vehicle/user (device) in this application.
A tracked device is an instance of Radio class coming from datasource.

A tracked device can lead to two different actions:
- Show its tracking as a line string on a temporary map layer
- Follow its live position, refresh close cameras and publish the cameras to a selected videoapp target

This is quite a complex task so we'll have to work on a plan and we'll stop and resume on multiple iterations. Don't rush, we'll have to refine the plan from a global overview to implementation details of each part, step after step.

# Architecture

## Manager

A new RadioTrackerService should be added and its lifecycle will be managed by Services.Manager

This manager will have an endpoint to register an instance of Radio device from datasource and target action (map tracking of camera following).
Another public method exists to unregister one device.

For both actions, you'll have to subscribe to an emitter from Radio datasource to be notified of new locations. If the emitter system does not exist yet, you'll have to add one, look at other datasources, similar patterns already exist.

### Map tracking

When a new location is received from the emitter, you'll have to call the Radio API client to download the history of locations.

You'll have to pass the instance of the API client from ServicesManager to new manager constructor. I think the proper method to download tracking history is not yet implemented so you'll have to add this. When adding a new method, match the style of other API clients: be sure to document all throws and make sure to validate payload and return class instances, not raw non-validated payload from the API itself.
Of course, the API is going to request for start timestamp and some parameters from the Ramer Douglas Pucker algorithm so this has to be part of the registered action definition.

When history has been updated, find the corresponding feature on the temporary layer and update the associated line string.

Of course, please handle concurrent API calls to get the history with a counter to discard obsolete ones if updated locations come faster than API response

### Camera following

When a new location is received from the emitter you'll have to call camera service helper to figure out which cameras are close to the tracked device and you need to POST to camera API to target Videoapp client and wanted number of tiles.

It means both target Videoapp client and wanted number of cameras must be part of payload defining the tracking action. Also, you could add a boolean to overwrite the full display layout or only the N requested cameras. For instance, if this feature is defined as NOT overwriting and you've requested two cameras, target Videoapp layout will be requested and only the first two entries will be overwriten. If the current layout is less than two it will be extended to two, if more than two, it stays on original size and current layout is merged so the first two cameras only are changed. If full takeover is enabled, current active layout is not requested at all and we publish a complete layout with only the two cameras found.

When updating close cameras, you need to dedup the payload, it's possible that less than request count cameras exist and it's possible the updated location does not update the target cameras (or just switch them 1 becomes 2 and 2 becomes one 1, or we had 1 and 2 cameras and now only 1). In this case don't update the camera layout.

Just like for map tracking, you need to take care of concurrent calls and discard super-seeded ones of if too long and a new position is already there.

### Self unregister

Manager should automatically discard vehicle tracking (map and cameras) if the Radio indicates the device is off or if it's not sending a message for more than N minutes, make this a parameter of tracking action.
Pass toast service to manager constructor and toast a message when tracking is self-disabling

## Tracking start

Tracking should be enabled from Radio vehicle popup, you should add two child components to request camera or map tracking and provide required parameters for tracking action. For map action, Ramer Douglas parameters should be hardoded there to something reasonable. Same for self-unregistering, you should default to 5 minutes. Other parameters should be configurable there.
For cameras following, a list of existing videoapp clients should be shown and a toggle switch is there to enable full layout takeout or merge mode. In full takeover, cameras count can be 1, 4, 9, 10, 16, in merge mode, 1,2,3,4.

If tracking is already active, show instead a button to unregister it.

# Guidelines

Make sure to follow the style of existing code. Don't wrap JSDoc too early, line length is 160. Break a line between sentences, document parameters, throws and returns. For public methods, perform runtime validation using custom validate* functions and make sure the thrown message is self-explanatory.

In case on any doubts, please ask a question, or write in the plan the possible options and prompt me later for that. Never guess anything, verify the actual code, and if you are still unsure, ask me