Versionne l'état runtime IdeA produit pendant le sprint #13 : store de tickets (dont les nouveaux #55 à #67), compteur et index, notes de mémoire projet des lots F0 à F5, et journal des tâches de fond. Séparé du code applicatif conformément à la convention du dépôt (cf.ad1f225,a244f32) : métadonnée d'orchestration last-writer-wins, sans impact sur le build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.7 KiB
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 | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1be19ee5-fd03-42ea-8df6-da18704807a9 | 20 | [Backend] Dette ticket_list — matching #ref dans text + curseur opaque/stable | closed | low | e28a4d53-8bd2-446a-b0ac-2a017373b8b2 |
|
|
|
1783331172226 | 1784049665491 | 5 |
Dette backend identifiée pendant le cadrage du sprint UI rework (gate G4), non bloquante pour la popup #18 qui démarre sur le contrat actuel.
Deux écarts sur la commande ticket_list (handler crates/app-tauri/src/tickets.rs:681, filtre store crates/infrastructure/src/issues.rs) :
-
Recherche
text: appliquée serveur sur titre (issues.rs:322) + description/carnet (issues.rs:326/465) mais PAS sur le#ref/numéro de ticket. Étendre le matchingtextàissue_refpour permettre la recherche par numéro dans la popup de sélection. -
cursor: actuellement un offset numérique parsé en usize avec fallback silencieux à 0 si invalide (tickets.rs:1231), non opaque et non stable face à des mutations entre pages. Contractualiser un curseur opaque + stable (ordre déterministe préservé).
Garde G3-bis déjà en place côté frontend : TicketPicker/useTicketSearch traitent cursor comme un token opaque (jamais construit/incrémenté côté client), donc la migration vers un curseur opaque backend n'exigera AUCUN changement frontend — cette dette est non-breaking.
statuses[]/priorities[] sont conformes (OR intra-facette, AND inter-facette, testés) — rien à faire de ce côté.