IdeA/.ideai/tickets/75/issue.md

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
d54a1f20-03e6-4925-982b-923a37331749	75	Écran d'appairage web : clavier numérique sur mobile alors que le code contient des lettres	closed	medium	null	target kind #69 relatesTo target kind #74 relatesTo		kind agent_id agent a6ced819-b893-4213-b003-9e9dc79b9641	kind user	1784277353320	1784449082160	3

Symptôme (constaté live, téléphone)

Sur l'écran d'appairage web (PairingScreen), le clavier virtuel qui s'ouvre est un pavé numérique uniquement, alors que le code d'appairage à saisir contient des lettres. Impossible de saisir le code sans changer de clavier à la main.

Cause racine (confirmée)

Le code généré côté serveur est hexadécimal, 8 caractères, majuscules (0-9A-F) :

// crates/web-server/src/lib.rs:2220
fn new_pairing_code() -> String {
    Uuid::new_v4().simple().to_string().chars().take(8)
        .collect::<String>().to_ascii_uppercase()
}

Or frontend/src/features/web/PairingScreen.tsx:79 force inputMode="numeric" (introduit par #69 en supposant un code purement chiffré), et le placeholder p. ex. 4821-93 (ligne 74) décrit un format qui n'existe pas.

Attendu

• Le clavier mobile permet de saisir lettres et chiffres.
• Le placeholder reflète le format réel (hex 8 caractères majuscules).
• La saisie reste sans autocorrection ni capitalisation surprise ; le code étant en majuscules, la casse ne doit pas être un piège pour l'utilisateur.

Périmètre

Frontend pur. Le format du code côté serveur n'est pas remis en cause par ce ticket.

DoD

• Saisie possible au clavier mobile standard, lettres incluses.
• Placeholder cohérent avec new_pairing_code().
• Test de non-régression sur le champ.