# Übergabebeschreibung — poster-desk-lab/1.0.2 [Vollständige Lehr-ZIP herunterladen](https://yenpo.app/examples/poster-desk-handoff-1.0.2.zip) · SHA-256: `c39d19b210c05f4667cd74db4934459a079408d14c5e7678c24cd087e1df5185` Dies ist eine Lesefassung der Beschreibung in der ZIP. Quell- und Skriptpfade beziehen sich auf den entpackten Ordner `poster-desk-lab`; verwenden Sie die ZIP, um Befehle auszuführen und die Abnahmevorlage zu kopieren. Zweck: Postertitel zur späteren lokalen Prüfung annehmen. Dies sind erfundene Produktzusagen zur Überprüfung, keine Aussagen aus einer KI-Ausgabe. Node.js 22+; keine Installation, kein Netzwerk, keine Zugangsdaten. In ein neues Verzeichnis entpacken, nach `poster-desk-lab` wechseln und jeden Befehl einzeln ausführen. Bewahren Sie diese Beschreibung zusammen mit genau diesem Paket auf und prüfen Sie vor dem Lesen von Zeilenverweisen das Manifest. ## Fakten zu den Fähigkeiten | ID | Zusage und tatsächliche Beobachtung | Einordnung und Grenze | Quelle in dieser Revision | | --- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | P1 | „Eine eingereichte Karte lässt sich später prüfen.“ Ein separater Node-Prozess listet exakt die gespeicherte ID und den Titel aus demselben erhaltenen Zustandsverzeichnis auf. | **implementiert** — lokale Dateispeicherung über sequenzielle Prozesse hinweg. Keine Zusage zur Ausfallsicherheit, entfernten Datenbank oder Aufbewahrung bei Bereitstellungen. | `src/store.mjs` Zeilen 46–76; `src/cli.mjs` Zeilen 12–17 | | P2 | „Ein Beleg wird gesendet.“ Das akzeptierte Ergebnis enthält eine Beispielvorschau mit `adapter: fixture`, `delivery: not-attempted`. | **simuliert** — nur die Vorschau existiert; eine Zustellung wurde nicht versucht. Die weitergehende Zusage „gesendet“ ist für dieses Paket widerlegt. | `src/cli.mjs` Zeilen 1–2, 15–17 wählen `src/receipt.mjs` Zeilen 3–7 und `fixtures/receipt.json` | | P3 | „Wiederholen derselben Karte erzeugt kein Duplikat.“ Die sequenzielle Wiederholung identischer ID und identischen Titels liefert `created: false`; die Liste enthält weiter eine Karte. Gleiche ID mit anderem Text wird abgelehnt. | **implementiert** — exakte sequenzielle Wiederholungen in diesem erhaltenen Verzeichnis. Keine Garantie für Nebenläufigkeit, unterbrochene Schreibvorgänge oder erneute externe Benachrichtigungen. | `src/store.mjs` Zeilen 46–60 | | P4 | „Eingereichte Karten überstehen das Ersetzen einer Bereitstellung.“ Bereitgestellte Umgebung und Lebenszyklus des Zustandsverzeichnisses fehlen. Ein erhaltenes Verzeichnis behält die Karte, ein neues ist leer. | **unbekannt** — diese zwei lokalen Ergebnisse zeigen nicht, welchen Speicher eine Bereitstellung erhält. Leiten Sie P4 nicht aus P1 ab. | `src/store.mjs` Zeilen 7–9, 22–38; Bereitstellungskonfiguration fehlt in diesem Stand | „Implementiert“ bezeichnet hier nur den nachgewiesenen Umfang. „Simuliert“ kennzeichnet einen bekannten Ersatzpfad, keinen ungetesteten echten Dienst. „Unbekannt“ steht für fehlende erforderliche Umgebungsbelege, nicht für eine nachweislich fehlende Funktion. ## Übernehmen und reproduzieren ```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 ``` Erwartet: Die erste Einreichung liefert `accepted: true`, `created: true` und einen Fixture-Beleg mit `delivery: not-attempted`. Die erste Liste lautet `{"cards":[{"id":"cloud-poster","title":"Cloud shapes"}]}`. Die exakte Wiederholung liefert `created: false` und lässt diese Liste unverändert. Der Befehl mit abweichendem Titel **endet mit Status 2**, schreibt `{"error":"card-id-conflict"}` nach stderr und nichts nach stdout. Die folgende Liste enthält weiterhin den ursprünglichen Titel. Das neue `replacement-state` listet `{"cards":[]}`; das erhaltene `receiver-state` enthält die Karte weiterhin. Die erneute Initialisierung von `receiver-state` **endet mit Status 2** und `{"error":"EEXIST"}`, ohne es zu ersetzen. Das sind zwei erwartete Ablehnungen, keine erfolgreichen Exitstatus; verknüpfen Sie die Befehle nicht mit `&&`. Die Liste nach abgelehnter Initialisierung muss erneut die ursprüngliche Karte zeigen. Fünf Tests bestehen; einer kopiert und füllt tatsächlich das externe Abnahmeprotokoll und prüft danach das Originalpaket. Jede CLI-Zeile ist ein eigener Prozess. Das prüft einen Prozessneustart mit erhaltenen Dateien. Das leere Ersatzverzeichnis ist ein kontrastierender lokaler Aufbau, **kein tatsächliches Bereitstellungsexperiment**. ## Abnahme und offene Frage Der Kopierbefehl oben legt die unveränderliche Vorlage `RECEIVER.md` außerhalb des entpackten Pakets unter `../poster-desk-receiver.md` ab und verweigert das Überschreiben einer vorhandenen Kopie. Füllen Sie **diese externe Kopie** mit eigenen Ausgaben und Erkenntnissen aus dem Quellcode. Lassen Sie die gelieferte Vorlage unverändert; Ihr Abnahmeprotokoll ist vom Manifest des Originalpakets getrennt. Nach dem Ausfüllen führen Sie aus: ```sh node scripts/verify-package.mjs ``` Das Originalpaket muss weiter bestehen. Nehmen Sie die Übergabe nur an, wenn P1/P3 im genannten Rahmen stimmen, P2 als simuliert eingeordnet bleibt und P4 offen bleibt. Ungewissheit ist kein Grund, bekannte lokale Beobachtungen als fehlgeschlagen zu markieren; sie ist ein Grund, keine Aufbewahrung bei Bereitstellungen zu versprechen. Um P4 für eine echte Umgebung zu klären, beschaffen Sie die genaue Bereitstellungs- und Speicherkonfiguration und prüfen Sie unabhängig einen bekannten Datensatz über deren Ersetzungsverfahren hinweg, mit autorisierten nicht sensiblen Daten. Solche Konfigurationen und Tests fehlen hier. Auch gleichzeitige Schreibzugriffe, Stromausfall, Wiederherstellung aus Backups und echte Benachrichtigungen wurden nicht bewertet. Der Code speichert die Karte vor dem Vorbereiten des Belegs. Ein Belegfehler kann daher eine gespeicherte Karte zurücklassen; ein Fehler allein beweist nicht, dass nichts gespeichert wurde.