Files
IdeA/.ideai/tickets/31/issue.md
Blomios 2fa226e413 chore(tickets): versionne le store de tickets et de sprints du projet
`.ideai/tickets/` et `.ideai/sprints/` sont le registre durable du projet (les
tickets sont déjà référencés par les messages de commit : #14, #21..#25, #28),
au même titre que `.ideai/memory/`. Ils entrent donc dans le dépôt.

À l'inverse, `.ideai/background-tasks/` (snapshots de rendez-vous headless) et
`.ideai/proposals/` (amendements de contexte en attente d'arbitrage) restent de
l'état d'exécution transitoire, de la même classe que `live-state.json` et
`.ideai/requests/` : ils doivent être ignorés (patch `.gitignore` à venir).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-08 08:38:33 +02:00

1.6 KiB
Raw Blame History

id, number, title, status, priority, sprint, links, agentRefs, createdBy, updatedBy, createdAt, updatedAt, version
id number title status priority sprint links agentRefs createdBy updatedBy createdAt updatedAt version
83d320f1-766b-4744-b518-8e39a2518e9c 31 Détection de profils séquentielle : N × 800 ms au pire, résultat potentiellement partiel open low null
target kind
#28 relatesTo
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
kind agent_id
agent a6ced819-b893-4213-b003-9e9dc79b9641
1783491197541 1783491197541 1

Origine

Relevé par Git en revue du diff du ticket #28 (merge 710fa8f), hors périmètre du fix.

Constat

Depuis #28, DetectProfiles::execute séquence les await candidat par candidat, chaque sonde bornée par tokio::time::timeout(800ms). N profils indisponibles coûtent donc N × 800 ms au pire.

Côté frontend, DETECT_TIMEOUT_MS = 3 s relâche le flag detecting. À partir de ~4 candidats muets, le tour de détection dépasse ce délai : l'indicateur « Detecting… » disparaît avant que les résultats n'arrivent.

Impact

Cosmétique. L'UI ne gèle plus (c'est bien l'objet de #28, corrigé) ; le risque résiduel est un affichage de disponibilité qui arrive après la retombée de l'indicateur.

Piste de fix

Paralléliser les sondes avec futures::future::join_all dans DetectProfiles::execute (crates/application/src/agent/usecases.rs) : le coût au pire retombe à ~800 ms quel que soit N, largement sous le timeout UI.

Validation

Test #[tokio::test(flavor = "multi_thread")] sur DetectProfiles::execute avec N candidats muets, asserting que la durée totale reste bornée par ~1 × timeout et non N ×.