# Guía de entrega — poster-desk-lab/1.0.2 [Descarga el ZIP didáctico completo](https://yenpo.app/examples/poster-desk-handoff-1.0.2.zip) · SHA-256: `c39d19b210c05f4667cd74db4934459a079408d14c5e7678c24cd087e1df5185` Esta es una copia de lectura de la guía incluida en el ZIP. Las rutas de código y scripts siguientes se refieren a su carpeta extraída `poster-desk-lab`; usa el ZIP para ejecutar los comandos y copiar la plantilla de aceptación. Objetivo: recibir títulos de carteles para revisarlos localmente más adelante. Son promesas de producto ficticias que se deben comprobar, no afirmaciones extraídas de una respuesta de IA. Node.js 22+; sin instalación, red ni credenciales. Descomprime en un directorio nuevo, entra en `poster-desk-lab` y ejecuta cada comando por separado. Conserva esta guía junto al paquete exacto; verifica su manifiesto antes de consultar las referencias de líneas. ## Hechos sobre las capacidades | ID | Promesa y observación real | Clasificación y límite | Código de esta revisión | | --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | P1 | «Una tarjeta enviada puede revisarse más adelante». Un proceso Node separado lista el ID y el título exactos guardados en el mismo directorio de estado conservado. | **implementado**: almacenamiento local en archivos entre procesos secuenciales. No demuestra durabilidad ante fallos, una base de datos remota ni conservación entre despliegues. | `src/store.mjs`, líneas 46–76; `src/cli.mjs`, líneas 12–17 | | P2 | «Se envía un recibo». El resultado aceptado incluye una vista previa de ejemplo con `adapter: fixture`, `delivery: not-attempted`. | **simulado**: solo existe la vista previa; no se intentó entregar nada. La promesa más amplia de «enviado» queda refutada para este paquete. | `src/cli.mjs`, líneas 1–2 y 15–17, seleccionan `src/receipt.mjs`, líneas 3–7, y `fixtures/receipt.json` | | P3 | «Reintentar la misma tarjeta no la duplica». Repetir secuencialmente el mismo ID y título devuelve `created: false`; la lista sigue teniendo una tarjeta. Reutilizar el ID con otro texto se rechaza. | **implementado**: reintentos secuenciales idénticos en este directorio conservado. No garantiza reintentos concurrentes, de escrituras interrumpidas ni de notificaciones externas. | `src/store.mjs`, líneas 46–60 | | P4 | «Las tarjetas enviadas sobreviven al reemplazo del despliegue». No se proporciona un entorno desplegado ni el ciclo de vida del directorio de estado. Conservar un directorio preserva la tarjeta; uno nuevo está vacío. | **desconocido**: esos dos resultados locales no indican qué almacenamiento conserva un despliegue. No conviertas P1 en P4. | `src/store.mjs`, líneas 7–9 y 22–38; esta instantánea no incluye configuración de despliegue | Aquí, «implementado» nombra únicamente el alcance demostrado. «Simulado» identifica una ruta que se sabe que está simulada, no un servicio real sin probar. «Desconocido» señala una afirmación para la que falta la evidencia necesaria del entorno, no una función cuya ausencia se haya demostrado. ## Recibe y reproduce ```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 ``` Resultado esperado: el primer envío tiene `accepted: true`, `created: true` y un recibo de prueba con `delivery: not-attempted`. La primera lista es `{"cards":[{"id":"cloud-poster","title":"Cloud shapes"}]}`. El reintento idéntico tiene `created: false` y deja esa lista sin cambios. El comando con otro título **termina con estado 2**, imprime `{"error":"card-id-conflict"}` en stderr y nada en stdout. La siguiente lista conserva el título original. El nuevo `replacement-state` muestra `{"cards":[]}`; el `receiver-state` conservado sigue conteniendo la tarjeta. Reinicializar `receiver-state` **termina con estado 2** con `{"error":"EEXIST"}` y no lo reemplaza. Son dos rechazos esperados, no estados de ejecución satisfactoria; no unas los comandos con `&&`. La lista posterior a la reinicialización rechazada debe volver a mostrar la tarjeta original. Pasan cinco pruebas; una copia y completa realmente el registro externo de aceptación y después verifica el paquete original. Cada línea de CLI es un proceso separado. Eso comprueba el reinicio del proceso con archivos conservados. El directorio de reemplazo vacío es una configuración local de contraste, **no un experimento de despliegue real**. ## Aceptación y pregunta pendiente El comando de copia anterior coloca la plantilla inmutable `RECEIVER.md` en `../poster-desk-receiver.md`, fuera del paquete extraído, y rechaza sobrescribir una copia existente. Completa **esa copia externa** a partir de tus propias salidas y lectura del código. Mantén la plantilla entregada sin cambios; tu registro de aceptación está separado del manifiesto original del paquete. Después de completar la copia, ejecuta: ```sh node scripts/verify-package.mjs ``` El paquete original debe seguir pasando la verificación. Acepta esta entrega solo si P1/P3 coinciden dentro del alcance indicado, P2 sigue clasificado como simulado y P4 permanece abierto. Una incógnita no es motivo para marcar como fallidas las observaciones locales conocidas del paquete; es motivo para no prometer la conservación entre despliegues. Para resolver P4 en un entorno real, consigue la configuración exacta de despliegue y almacenamiento y prueba de forma independiente un registro conocido durante el procedimiento de reemplazo de ese entorno, con datos autorizados y no sensibles. Aquí no se incluye esa configuración ni esa prueba. Por separado, no se han evaluado las escrituras simultáneas, los cortes de energía, la restauración de copias de seguridad ni las notificaciones reales. El código escribe la tarjeta antes de preparar el recibo, así que un fallo del recibo puede dejar una tarjeta guardada; un error por sí solo no demostraría que no se almacenó nada.