Kazeia-central/docs/VOICE_DEPLOYMENT_SPEC.md

135 lines
7.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# VOICE_DEPLOYMENT_SPEC — adaptations app patiente pour le déploiement des voix `.cvps`
> **Destinataire : dev de l'app patiente `com.kazeia`.**
> **Auteur : Kazeia-central.** Même démarche que `PROVIDER_RPC_SPEC.md` /
> `VOICE_ENROLLMENT_SPEC.md` : la stack patiente est **figée** (`FROZEN.md`), donc
> ces changements sont décrits ici et livrés, pas réécrits sauvagement.
>
> **Contexte** : Kazeia-central devient le maître de l'enrôlement et du déploiement des
> voix CosyVoice (`.cvps`). Il enrôle un WAV → `.cvps`, le pousse sur la tablette, et
> **supprime le WAV d'origine** (archivé chiffré côté PC). Le workflow exige trois
> adaptations côté app, dont une **bloquante** (sans elle, une voix déployée disparaît
> de l'inventaire).
---
## 0. État observé (code actuel, vérifié)
- `KazeiaTelemetryProvider.voicesCursor()` construit l'inventaire `/voices` comme
`ids = basenames(*.wav) basenames(<id>_voice_prefix.bin)` (legacy **Qwen3-TTS**).
Le `state` vaut `ready` si les `.bin` prefix+suffix existent, `recorded` si seul le
WAV est là, sinon `error`. **Le dossier `cosyvoice/*.cvps` n'est jamais lu.**
- TTS de prod = **CosyVoice uniquement** (`CosyVoiceTtsEngine`). Résolution voix purement
par nom : `cvpsPath(voiceId) = "<modelsDir>/cosyvoice/<voiceId>.cvps"`,
`ensureVoice()` charge le `.cvps` à la demande (cache par `voiceId`). Repli gracieux
sur `DEFAULT_VOICE_ID` si le `.cvps` est absent.
- `Profile.voiceId` (nullable) = la voix d'un profil ; `KazeiaService.setVoiceId()`
`CosyVoiceTtsEngine.setVoice()`. **Aucune notion d'« exclusivité/propriété » d'une
voix par un profil** : un `.cvps` présent est chargeable par n'importe quel profil.
---
## 1. Adaptation — `/voices` scanne WAV **et** `.cvps` (inventaire à-convertir / prête)
**Intention** : `/voices` doit refléter le cycle de vie d'une voix en scannant **les
deux** dossiers, chacun pour un état :
- **WAV présent, pas de `.cvps`** → voix **« à convertir »** (enregistrée, en attente
d'enrôlement par Kazeia-central).
- **`.cvps` présent** → voix **« prête »** (enrôlée + déployée).
Conséquence voulue : après conversion+déploiement puis suppression du WAV (le WAV est
archivé côté PC), la voix **reste affichée « prête »** grâce au scan `.cvps` — elle ne
disparaît pas de l'inventaire. (Aujourd'hui `voicesCursor()` ne scanne que
`WAV embeddings Qwen3` → une voix `.cvps`-seule serait omise.)
**Demande** : étendre `voicesCursor()`
- Union d'ids = `basenames(*.wav) basenames(prefix.bin) basenames(cosyvoice/*.cvps)`.
- Nouvelle colonne **`cvps_exists`** (0/1).
- `state` (cascade) : **`ready`** si `cvps_exists` (ou prefix+suffix Qwen3 legacy) ;
**`recorded`** (= « à convertir ») si seul le WAV ; `error` sinon.
- Ajout additif (colonne en plus) → compat ascendante.
> Pas un prérequis fonctionnel (la synthèse charge le `.cvps` par son nom, sans cette
> liste), mais c'est l'**inventaire voulu** : distinguer voix à convertir vs prêtes, et
> garder les voix prêtes visibles une fois le WAV supprimé.
---
## 2. Adaptation — `voices_reload` (rescan après push direct)
Kazeia-central pousse le `.cvps` par `adb push` direct (hors WebDAV). Le `.cvps` est
**utilisable immédiatement** (chargé à la demande par `ensureVoice()` au prochain usage
de la voix), mais l'**inventaire** `/voices` et le picker admin ne se rafraîchissent pas
tant qu'aucun évènement ne le déclenche.
**Demande** : méthode `call()` **`voices_reload`** (déjà listée nice-to-have dans
`PROVIDER_RPC_SPEC §9`) — re-scanne le dossier voix et **diffuse `RELOAD_VOICES`**
(constante `ACTION_RELOAD_VOICES` à créer au passage ; aujourd'hui la string est en dur,
cf. provider ~l.656). Permet à Kazeia-central de finaliser un déploiement par un refresh
propre, sans aller-retour WebDAV ni redémarrage.
---
## 3. Politique de déploiement (appliquée côté Kazeia-central)
La règle de **localisation** est enforced par Kazeia-central au déploiement —
- une voix **verrouillée** (exclusive à un profil patient) n'est poussée **que** sur
la/les tablette(s) où ce profil est déployé ;
- seules les voix **globales/non-exclusives** sont déployées sur le parc.
⚠️ Une tablette héberge **plusieurs profils patients** (confirmé). Mais l'exclusivité au
playback est **déjà garantie** par le binding existant : l'app sélectionne toujours la
voix du **profil actif** (`KazeiaService` : `activeProfile.voiceId ?: DEFAULT_VOICE_ID`).
Un patient B n'utilise donc une voix exclusive à A **que si** `B.voiceId` pointe dessus.
Le point de contrôle est donc l'**assignation de `Profile.voiceId`**, pas un marqueur
parallèle. Voir §4 — l'exclusivité s'appuie sur le mapping voix↔profil existant, sans
nouvel artefact app.
---
## 4. Exclusivité — via le mapping `Profile.voiceId` existant (pas de nouvel artefact)
L'exclusivité s'appuie sur le binding **voix↔profil déjà présent** (`Profile.voiceId`),
pas sur un marqueur parallèle. Kazeia-central est l'**autorité d'assignation** (il a le
CRUD profils via le provider) :
- **Verrouiller** une voix sur un patient = central assigne `Profile.voiceId = <voix>` au
profil propriétaire, **et ne l'assigne à aucun autre profil** (sur la tablette ni
ailleurs). C'est ça l'exclusivité.
- **Déploiement** : central pousse le `.cvps` uniquement sur la/les tablette(s) du
propriétaire (cf. §3).
- **Playback** : déjà exclusif — l'app n'utilise que `activeProfile.voiceId`.
### Côté app — rien de nouveau requis pour l'exclusivité
Le playback par profil actif suffit. **Optionnel** (garde-fou de gouvernance, si le
picker admin on-device autorise la (ré)assignation des voix) : l'app peut, à partir de
la liste des profils qu'elle a déjà, signaler qu'une voix est **déjà assignée à un autre
profil** et déconseiller/empêcher de la réassigner — **sans aucun fichier ni colonne
supplémentaire**, juste en croisant `Profile.voiceId`. À implémenter seulement si
l'assignation reste possible on-device ; sinon l'autorité centrale suffit.
> Kazeia-central garde `locked_profile_id` par voix **en interne** (sa politique) et le
> matérialise par l'assignation `Profile.voiceId` + la localisation du `.cvps`. Aucun
> sidecar `.owner`, aucune ontologie d'exclusivité à dupliquer dans l'app.
---
## 5. Récap — ce qui est demandé au dev app patiente
| # | Adaptation | Criticité | Forme |
| --- | --- | --- | --- |
| 1 | `/voices` scanne WAV (« à convertir ») **et** `.cvps` (« prête »), col. `cvps_exists` | inventaire voulu | curseur `voicesCursor()` |
| 2 | `voices_reload` (rescan + `RELOAD_VOICES`, constante `ACTION_RELOAD_VOICES`) | important | méthode `call()` |
| 4 | exclusivité = via `Profile.voiceId` existant + autorité d'assignation centrale | **aucun code app** (garde-fou picker optionnel, sans artefact) | central / §4 |
Côté Kazeia-central (déjà fait / à faire, **pas** côté app) : enrôlement, archive
chiffrée du WAV, suppression du WAV device, **politique de déploiement verrou-conscient**,
**autorité d'assignation** (`Profile.voiceId` du propriétaire, jamais ailleurs pour une
voix exclusive), et la **distribution flotte** (voix globales sur le parc, exclusives chez
leur patient) — en cours.
---
*Source de vérité : `KazeiaTelemetryProvider.voicesCursor()`, `CosyVoiceTtsEngine.kt`,
`Profile.kt`, `KazeiaService.setVoiceId()` (kazeia-android). Vérifié le 2026-06-19.*