NotreCouple 1.2 — cadrage et plan de livraison
Décision propriétaire du 5 octobre 2026 : la prochaine livraison de fonctionnalités et correctifs après la 1.1.1 est la 1.2. Le périmètre anciennement nommé V1.3 est repris dans cette version. Aucune étape 1.1.2 n'est prévue dans ce cycle.
Plane pilote le travail : module notrecouple-release-12, lot de cadrage release-12-plan. GitHub porte les PR d'implémentation. Ce document cadre une cible produit ; le bump technique sera calculé depuis le dernier main et VERSION lors de la finalisation, conformément à AGENTS.md.
Objectif
Enrichir le livre commun sans pression de cadence, permettre une personnalisation facultative et proposer une quête partagée qui respecte le rythme des deux personnes. Les correctifs découverts pendant ce cycle sont rattachés au lot concerné avec reproduction et critère de sortie.
Point de départ
La promotion de la 1.1.1 est fusionnée via PR #953, commit 99824215f46207f8a9ad893252f7fce86c453c43. Le moteur d'accomplissements (#646), le livre (#652) et son affichage immédiat (#951) font déjà partie de cette version. Les migrations 0018/0019 et ACHIEVEMENTS_UI.md décrivent ce socle.
Les états historiques NC-15/16 dans Plane doivent être rapprochés des preuves. Leur état ne signifie pas que le code reste à écrire. Conserver les gains, la confidentialité, la célébration indépendante par membre et le cache des illustrations ; compléter les recettes manquantes avant de clôturer les lots.
Lots du cycle 1.2
| Ordre | Lot | Résultat attendu | Sortie |
|---|---|---|---|
| 0 | NC-15 / NC-16, qualification du socle | Matrice livré / vérifié / restant ; recette deux sessions du livre et des gains | Preuves rattachées aux PR et à la version servie ; états rapprochés sans inventer une recette |
| 1 | NC-18, récompenses et personnalisation | Assets des 12 gains ; couverture, cadre et marque-page facultatifs et persistants | Droits vérifiés serveur, choix partagé cohérent sous concurrence, alternatives accessibles |
| 2 | NC-19, quête hebdomadaire facultative | Choix partagé, progrès depuis acceptation, récompense unique, clôture douce | Frontières ISO UTC, choix concurrents, retry, expiration, absence/reprise et isolation validés |
| 3 | NC-17, validation intégrée 1.2 | Recette commune de tous les lots retenus et corrections nécessaires | PostgreSQL, deux sessions, mobile, Safari/iOS réel, clavier, reduced-motion et effacement |
| Exploration A | NC-50, garder / proposer | Vérifier l'historique/favoris existants ; prototype si besoin non couvert | Décision motivée développer/abandonner avant implémentation |
| Exploration B | NC-52, pas maintenant | Vérifier le skip/masquage existant après NC-50 ; prototype si utile | Choix privé, temporaire et réversible compris, suggestions non raréfiées |
NC-50 et NC-52 sont inclus au cycle de cadrage 1.2. Leur présence ne promet pas une fonctionnalité développée : une conclusion d'abandon motivée satisfait leur lot de découverte. Si le prototype est retenu, compléter son contrat et son estimation dans le même lot avant la PR d'implémentation.
Contrats produit
- Les gains restent communs et permanents ; aucune perte pour absence, aucun classement, XP individuel, monnaie ou contenu essentiel verrouillé.
- La personnalisation ne consomme pas un gain. Le serveur vérifie les récompenses acquises et résout le couple depuis la session.
- Une quête est facultative, commune, bornée à la semaine ISO UTC. Seules les découvertes postérieures au choix comptent. Une quête inachevée se ferme sans reproche ni retrait des gains.
- Garder pour soi reste privé ; proposer à deux est un partage explicite et retirable sans justification. Un vote ne devient pas automatiquement un favori commun.
- Pas maintenant ne révèle aucun refus au partenaire et reste réversible ; aucune justification obligatoire ni blacklist permanente.
- Aucun texte de réponse intime dans les projections, logs, métriques, feedback ou assets.
- Aucun e-mail d'accomplissement dans ce périmètre.
Le contrat détaillé des accomplissements 1.2 conserve les clés et règles du catalogue initial.
Exécution et dépendances
Le cadrage de réalisation NC-18 → NC-19 → NC-17 précise les interactions, la concurrence des choix et les critères de sortie. Mise à jour d'état Plane du 09/10/2026 : NC-18 et NC-19 sont en Review ; NC-17 reste au Backlog. Les étapes d'implémentation ci-dessous représentent l'ordre de travail initial décidé le 05/10, pas des travaux nécessairement encore à commencer. La recette Notre Socle NC-66 est un périmètre parallèle et ne remplace pas NC-17.
- Qualifier la baseline 1.1.1 avec NC-15/16 et rapprocher les incidents de recette NC-41/44/45 de leurs preuves. Une anomalie réellement persistante reçoit un correctif reproduit ; ne pas recopier comme nouvelle feature un correctif déjà livré.
- Cadrer les interactions NC-18 et les prototypes NC-50, puis NC-52. Revoir quelques essais humains pour décider de leur utilité avant d'élargir le développement.
- Implémenter NC-18, puis NC-19 sur le socle existant, en PR distinctes par lot. Migrations additives et rollback préservant gains et préférences.
- Implémenter uniquement les explorations retenues, avec permissions, confidentialité et comportement à deux sessions explicités.
- Exécuter NC-17 : dix scénarios du contrat, quêtes et personnalisation, régression Jouer/Nous, identités concurrentes, réseau retardé, focus/scroll, clavier et reduced-motion.
- Finaliser la release depuis le dernier main ; publication de l'image validée puis promotion des huit consommateurs dans une PR distincte ; merge après décision propriétaire et preuves de déploiement.
Dépendances utiles : NC-20/21/23 pour conservation/purge, NC-25/27 pour restauration et anti-résurrection, NC-4/5/6 pour les moyens E2E nécessaires. Utiliser ces lots existants ; leur totalité n'est pas automatiquement un prérequis de développement, mais une preuve manquante qui affecte un critère de sortie doit bloquer ce critère.
PLAT-216 porte la publication hors GitHub Actions. La dérogation 1.1.1 ne s'étend pas à 1.2. Qualifier la voie de publication autorisée avant la finalisation.
Estimation et points de décision
NC-50 dispose d'une estimation indicative de prototype de 1 à 2 jours ; l'implémentation reste à chiffrer. Estimer NC-18/19 après inventaire des assets et du schéma existants. Pas de date de MEP engagée avant qualification de la baseline, arbitrage des prototypes et capacité de publication disponible.
Les sorties sont des preuves et décisions : baseline qualifiée ; personnalisation validée ; quête validée ; prototypes retenus/abandonnés ; recette intégrée réussie ; image publiée et promotion prête ; runtime et parcours vérifiés.
Gate de release
- SHA exact et version technique cohérents ; tests Dagger/K3s adaptés au diff, PostgreSQL réel pour stores/migrations/concurrence.
- Recette A/B et cross-couple, droits de récompense, effacement et anti-résurrection ; aucun contenu privé dans les traces.
- Desktop/mobile, Safari/iOS réel et clavier ; les environnements non exécutés restent explicitement non vérifiés.
- Image immuable publiée et contrôlée ; huit pins cohérents ; migrations additives compatibles avec rollback.
- Après promotion : SHA mergé, révision Flux, image/digest, pods/endpoints et smoke métier. Un HTTP 200 ou une CI verte seuls ne clôturent pas la livraison.
- Restaurer l'image précédente conserve les migrations compatibles et les acquis ; aucun reset ni suppression de données.
Traçabilité
Le module historique notrecouple-achievements-v13 a été remplacé par notrecouple-release-12 lors du cadrage initial. Depuis PLAT-217, le Gateway expose plane.update_module : un renommage de module existant est désormais possible sans recréer son UUID ni ses relations. Ce progrès technique ne justifie pas de ressusciter le module annulé. Les lots gardent leurs clés et références NC. Le module historique est annulé comme remplacé, pas marqué terminé. Le contrat à son ancienne URL reste une page de renvoi pour préserver les liens.