# Fiche de transmission — poster-desk-lab/1.0.2 [Télécharger le ZIP pédagogique complet](https://yenpo.app/examples/poster-desk-handoff-1.0.2.zip) · SHA-256 : `c39d19b210c05f4667cd74db4934459a079408d14c5e7678c24cd087e1df5185` Ceci est une copie de lecture de la fiche incluse dans le ZIP. Les chemins de sources et de scripts ci-dessous se rapportent au dossier extrait `poster-desk-lab` ; utilisez le ZIP pour exécuter les commandes et copier le modèle d’acceptation. Objectif : recevoir des titres d’affiches pour une revue locale ultérieure. Ce sont des promesses produit fictives à vérifier, pas des affirmations tirées d’une sortie IA. Node.js 22+ ; aucune installation, aucun réseau ni identifiant. Décompressez dans un nouveau répertoire, entrez dans `poster-desk-lab` et exécutez chaque commande séparément. Conservez cette fiche avec le paquet exact ; vérifiez son manifeste avant de lire les références de lignes. ## Faits sur les capacités | ID | Promesse et observation réelle | Classification et limite | Source dans cette révision | | --- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | P1 | « Une carte soumise peut être relue plus tard. » Un processus Node distinct liste exactement l’ID et le titre enregistrés depuis le même répertoire d’état conservé. | **implémenté** — stockage local par fichiers, entre processus séquentiels. Ni résistance aux pannes, ni base distante, ni conservation lors d’un déploiement. | `src/store.mjs` lignes 46–76 ; `src/cli.mjs` lignes 12–17 | | P2 | « Un reçu est envoyé. » Le résultat accepté inclut un aperçu d’exemple avec `adapter: fixture`, `delivery: not-attempted`. | **simulé** — seul l’aperçu existe ; aucun envoi n’a été tenté. La promesse plus large « envoyé » est réfutée pour ce paquet. | `src/cli.mjs` lignes 1–2, 15–17 sélectionnent `src/receipt.mjs` lignes 3–7 et `fixtures/receipt.json` | | P3 | « Réessayer la même carte ne la duplique pas. » Répéter séquentiellement le même ID et titre renvoie `created: false` ; la liste garde une seule carte. Réutiliser l’ID avec un autre texte est rejeté. | **implémenté** — répétitions séquentielles exactes dans ce répertoire conservé. Aucune garantie pour la concurrence, les écritures interrompues ou les notifications externes répétées. | `src/store.mjs` lignes 46–60 | | P4 | « Les cartes soumises survivent au remplacement du déploiement. » Aucun environnement déployé ni cycle de vie du répertoire d’état n’est fourni. Garder le répertoire préserve la carte ; un nouveau est vide. | **inconnu** — ces deux résultats locaux ne disent pas quel stockage un déploiement conserve. N’étendez pas P1 à P4. | `src/store.mjs` lignes 7–9, 22–38 ; configuration de déploiement absente de cet instantané | « Implémenté » désigne ici uniquement le périmètre démontré. « Simulé » identifie un chemin factice connu, pas un service réel non testé. « Inconnu » signale une affirmation dont les preuves d’environnement manquent, pas une fonctionnalité dont l’absence est établie. ## Recevoir et reproduire ```sh node --version node scripts/verify-package.mjs node scripts/copy-receiver.mjs node src/cli.mjs init receiver-state node src/cli.mjs submit receiver-state cloud-poster "Cloud shapes" node src/cli.mjs list receiver-state node src/cli.mjs submit receiver-state cloud-poster "Cloud shapes" node src/cli.mjs list receiver-state node src/cli.mjs submit receiver-state cloud-poster "Different title" node src/cli.mjs list receiver-state node src/cli.mjs init replacement-state node src/cli.mjs list replacement-state node src/cli.mjs list receiver-state node src/cli.mjs init receiver-state node src/cli.mjs list receiver-state node --test tests/contract.test.mjs tests/receiver-copy.test.mjs ``` Attendu : la première soumission contient `accepted: true`, `created: true` et un reçu de fixture avec `delivery: not-attempted`. La première liste est `{"cards":[{"id":"cloud-poster","title":"Cloud shapes"}]}`. La répétition exacte donne `created: false` et laisse cette liste inchangée. La commande avec un autre titre **sort avec le code 2**, affiche `{"error":"card-id-conflict"}` sur stderr et rien sur stdout. La liste suivante contient encore le titre initial. Le nouveau `replacement-state` liste `{"cards":[]}` ; le `receiver-state` conservé contient toujours la carte. Réinitialiser `receiver-state` **sort avec le code 2** et `{"error":"EEXIST"}` sans le remplacer. Ce sont deux rejets attendus, pas des statuts de réussite ; ne reliez pas les commandes avec `&&`. La liste après la réinitialisation rejetée doit encore montrer la carte initiale. Cinq tests passent ; l’un copie et remplit réellement le relevé d’acceptation externe, puis vérifie le paquet original. Chaque ligne CLI est un processus distinct. Cela vérifie le redémarrage d’un processus avec les fichiers conservés. Le répertoire de remplacement vide est un montage local contrasté, **pas une véritable expérience de déploiement**. ## Acceptation et question ouverte La commande de copie place le modèle immuable `RECEIVER.md` dans `../poster-desk-receiver.md`, hors du paquet extrait, et refuse d’écraser une copie existante. Complétez **cette copie externe** à partir de vos sorties et de votre lecture des sources. Gardez le modèle livré intact ; votre relevé d’acceptation est séparé du manifeste du paquet original. Après avoir rempli la copie, exécutez : ```sh node scripts/verify-package.mjs ``` Le paquet original doit toujours réussir. N’acceptez la transmission que si P1/P3 correspondent au périmètre annoncé, si P2 reste simulé et si P4 demeure ouvert. Une inconnue ne justifie pas de déclarer en échec les observations locales connues ; elle justifie de ne pas promettre la conservation lors d’un déploiement. Pour résoudre P4 dans un environnement réel, obtenez la configuration exacte du déploiement et du stockage, puis testez indépendamment un enregistrement connu pendant sa procédure de remplacement, avec des données autorisées et non sensibles. Aucune configuration ni aucun test de ce type n’est présent ici. Les écritures simultanées, coupures de courant, restaurations de sauvegardes et notifications réelles n’ont pas non plus été évaluées. Le code écrit la carte avant de préparer son reçu : un échec du reçu peut laisser une carte enregistrée ; une erreur seule ne prouve pas que rien n’a été stocké.