Promotion et règle des 4 yeux

La commande tk-ota-push promote permet de promouvoir un patch déjà validé et signé d'un canal interne (par exemple staging ou beta) vers un canal supérieur (par exemple stable) sans aucune recompilation. Ce mécanisme s'articule avec le workflow d'approbation à 4 yeux (--staged / Maker-Checker).

1. Le principe des 4 yeux (`--staged` / Maker-Checker)

Lors de la publication d'un patch sensible, la séparation des tâches entre le développeur qui soumet le correctif (Maker) et le responsable sécurité ou release manager qui l'autorise (Checker) s'opère en deux temps :

Flux de promotion entre canaux

Soumission initiale : Le développeur soumet le patch sur un canal interne (staging) avec mise en quarantaine (STAGED).
Double validation (4-yeux) : Un second collaborateur autorisé (Release Manager ou RSSI) approuve le patch.
Signature cryptographique : Le correctif reçoit une signature numérique de production.
Promotion vers la production : Le patch devient actif et distribuable sur le canal stable.

Comportement exact côté serveur (`Serveur TkushPatch`)

Soumission avec --staged : la CLI envoie auto_approve=false. Le patch est stocké avec le statut STAGED et hashSignature = null. Tant qu'il est STAGED, aucun téléphone mobile ne peut le télécharger.
Politique enforceFourEyes du Tenant : même si le développeur omet --staged (auto_approve=true), si la politique de gouvernance du Tenant impose les 4 yeux (politique des 4-yeux == true), le serveur refuse l'auto-approbation et force le statut STAGED.
Validation par un second acteur : lors de l'appel à POST /api/admin/v1/patches/{patchId}/approve, si approvedBy est identique à createdBy et que enforceFourEyes est actif (ou que le Tenant compte plus d'un membre), le serveur rejette l'opération avec HTTP 409 Conflict :
```
Violation du Principe des 4 Yeux (Four-Eyes Principle) : L'approbateur (<email>) doit être différent du créateur du patch.
```

2. Commande `tk-ota-push promote`

Une fois qu'un patch a été qualifié sur staging et possède le statut APPROVED_AND_SIGNED, utilisez promote pour le publier sur stable :

tk-ota-push promote --patch-id <uuid> [--to-channel stable] [options]

Options de `promote`

Option / Flag	Obligatoire	Défaut	Description
`--patch-id`	Oui	—	Identifiant UUID du patch source à promouvoir
`--to-channel`	Non	`stable`	Canal de destination (ex: `stable`, `beta`)
`--tenant-id`	Non	`shorebird.yaml` / session / `default`	Identifiant du Tenant
`--server`	Non	`shorebird.yaml` / env / `http://localhost:8080`	URL du serveur OTA
`--project`	Non	`.`	Chemin du projet Flutter (pour lire `shorebird.yaml`)
`--json`	Non	`false`	Affiche la réponse brute en JSON

3. Garanties cryptographiques lors de la promotion

Lorsque tk-ota-push promote appelle POST /api/admin/v1/patches/{patchId}/promote?target_channel=<canal>, le serveur exécute les vérifications suivantes (Serveur TkushPatch) :

Vérification du statut : le patch source doit impérativement être à l'état APPROVED_AND_SIGNED. S'il est encore STAGED ou ROLLED_BACK, le serveur renvoie HTTP 409 Conflict :
```
Seul un patch dans l'état APPROVED_AND_SIGNED peut être promu vers un autre canal (état actuel: STAGED)
```
Vérification du canal cible : le canal de destination doit être différent du canal source, sinon HTTP 409 Conflict :
```
Le canal cible (staging) est identique au canal source du patch.
```
Immutabilité binaire (Zéro recompilation) : le nouveau patch créé sur le canal cible réutilise exactement le même fichier différentiel (diffArtifactPath), le même targetSha256Hash et le même fichier de symboles (symbolsArtifactPath).
Numérotation séquentielle indépendante : le serveur calcule automatiquement le prochain patchNumber disponible sur le canal de destination (findMaxPatchNumberForReleaseAndChannel + 1).
Re-Signature cryptographique par canal : le serveur signe targetSha256Hash avec la clé de signature associée au couple (tenantId, appId, targetChannel) et trace l'origine dans approvedBy sous la forme PROMOTED_FROM_<SOURCE_CHANNEL>:<actor>.

Exemple de workflow complet (`staging` vers `stable`)

# Étape 1 : Publication en staging avec mise en quarantaine 4-yeux
tk-ota-push patch 1.0.0+3 -p android --channel staging --staged -m "Correctif virement SEPA"

# (Après approbation du patch dans la Console Web par un second administrateur)

# Étape 2 : Promotion vers le canal de production stable
tk-ota-push promote \
  --patch-id 8b73f831-29cf-4cb6-8801-44ebda29910a \
  --to-channel stable

Sortie dans le terminal :

Promotion du patch 8b73f831-29cf-4cb6-8801-44ebda29910a vers le canal 'stable'...

✅ Patch promu avec succès !
  ┌──────────────────────────────────────────────────────────────────────────
  │ 🚀 REÇU DE PUBLICATION PATCH OTA #2
  ├──────────────────────────────────────────────────────────────────────────
  │ ID Patch (UUID)     : c19a4502-88ef-41a0-9123-77bcde112233
  │ Application & Version: sara-money-demo • v1.0.0+3
  │ Cible & Canal       : android (aarch64) • Canal 'stable'
  │ Statut & Rollout    : APPROVED_AND_SIGNED (Déploiement : 100%)
  ...

1. Le principe des 4 yeux (--staged / Maker-Checker)​

Comportement exact côté serveur (Serveur TkushPatch)​

2. Commande tk-ota-push promote​

Options de promote​

3. Garanties cryptographiques lors de la promotion​

Exemple de workflow complet (staging vers stable)​