Blomios
2fa226e413
`.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>
26 lines
1.7 KiB
Markdown
26 lines
1.7 KiB
Markdown
---
|
|
id: "1be19ee5-fd03-42ea-8df6-da18704807a9"
|
|
number: 20
|
|
title: "[Backend] Dette ticket_list — matching #ref dans text + curseur opaque/stable"
|
|
status: "open"
|
|
priority: "low"
|
|
sprint: null
|
|
links: [{"target":"#18","kind":"relatesTo"}]
|
|
agentRefs: []
|
|
createdBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
|
updatedBy: {"kind":"agent","agent_id":"a6ced819-b893-4213-b003-9e9dc79b9641"}
|
|
createdAt: 1783331172226
|
|
updatedAt: 1783331176736
|
|
version: 2
|
|
---
|
|
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`) :
|
|
|
|
1. 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 matching `text` à `issue_ref` pour permettre la recherche par numéro dans la popup de sélection.
|
|
|
|
2. `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é. |