# Resumo de passagem — poster-desk-lab/1.0.2 [Baixe o ZIP completo do exercício](https://yenpo.app/examples/poster-desk-handoff-1.0.2.zip) · SHA-256: `c39d19b210c05f4667cd74db4934459a079408d14c5e7678c24cd087e1df5185` Esta é uma cópia para leitura do resumo incluído no ZIP. Os caminhos de código e scripts abaixo se referem à pasta extraída `poster-desk-lab`; use o ZIP para executar os comandos e copiar o modelo de aceitação. Objetivo: receber títulos de pôsteres para revisão local posterior. Estas são promessas fictícias de produto a verificar, não afirmações retiradas de uma saída de IA. Node.js 22+; sem instalação, rede ou credenciais. Extraia em um diretório novo, entre em `poster-desk-lab` e execute cada comando separadamente. Mantenha este resumo junto do pacote exato; verifique seu manifesto antes de ler as referências de linha. ## Fatos sobre as capacidades | ID | Promessa e observação real | Classificação e limite | Código nesta revisão | | --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | P1 | “Um cartão enviado pode ser revisado depois.” Um processo Node separado lista o ID e o título exatos salvos no mesmo diretório de estado preservado. | **implementado** — armazenamento local em arquivo, entre processos sequenciais. Não demonstra durabilidade após falhas, banco remoto nem retenção na implantação. | `src/store.mjs` linhas 46–76; `src/cli.mjs` linhas 12–17 | | P2 | “Um recibo é enviado.” O resultado aceito inclui uma prévia de exemplo com `adapter: fixture`, `delivery: not-attempted`. | **simulado** — só a prévia existe; o envio não foi tentado. A promessa mais ampla de “enviado” é refutada para este pacote. | `src/cli.mjs` linhas 1–2, 15–17 selecionam `src/receipt.mjs` linhas 3–7 e `fixtures/receipt.json` | | P3 | “Reenviar o mesmo cartão não o duplica.” Repetir sequencialmente o mesmo ID e título retorna `created: false`; a lista continua com um cartão. Reutilizar o ID com texto diferente é rejeitado. | **implementado** — repetições sequenciais idênticas neste diretório preservado. Sem garantia para concorrência, escrita interrompida ou repetição de notificações externas. | `src/store.mjs` linhas 46–60 | | P4 | “Os cartões enviados sobrevivem à substituição da implantação.” Não foi fornecido ambiente implantado nem ciclo de vida do diretório de estado. Preservar um diretório conserva o cartão; um novo fica vazio. | **desconhecido** — esses dois resultados locais não revelam qual armazenamento uma implantação preserva. Não extrapole P1 para P4. | `src/store.mjs` linhas 7–9, 22–38; configuração de implantação ausente neste snapshot | Aqui, “implementado” se refere apenas ao escopo demonstrado. “Simulado” identifica um caminho conhecido de simulação, não um serviço real ainda sem testes. “Desconhecido” marca uma afirmação para a qual faltam as evidências necessárias do ambiente, não uma funcionalidade cuja ausência foi comprovada. ## Receba e reproduza ```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 ``` Esperado: o primeiro envio tem `accepted: true`, `created: true` e um recibo de fixture com `delivery: not-attempted`. A primeira listagem é `{"cards":[{"id":"cloud-poster","title":"Cloud shapes"}]}`. A repetição idêntica tem `created: false` e mantém essa lista inalterada. O comando com título diferente **termina com status 2**, imprime `{"error":"card-id-conflict"}` em stderr e nada em stdout. A listagem seguinte ainda contém o título original. O novo `replacement-state` lista `{"cards":[]}`; o `receiver-state` preservado ainda contém o cartão. Reinicializar `receiver-state` **termina com status 2** com `{"error":"EEXIST"}` e não o substitui. São duas rejeições esperadas, não status de execução bem-sucedida; não una os comandos com `&&`. A listagem após a reinicialização rejeitada deve mostrar novamente o cartão original. Cinco testes passam; um deles realmente copia e preenche o registro externo de aceitação e depois verifica o pacote original. Cada linha da CLI é um processo separado. Isso verifica a reinicialização de processos com arquivos preservados. O diretório de substituição vazio é uma configuração local de comparação, **não um experimento real de implantação**. ## Aceitação e a pergunta em aberto O comando de cópia acima coloca o modelo imutável `RECEIVER.md` em `../poster-desk-receiver.md`, fora do pacote extraído, e recusa sobrescrever uma cópia existente. Preencha **essa cópia externa** com suas próprias saídas e leitura do código. Mantenha o modelo entregue intacto; seu registro de aceitação fica separado do manifesto do pacote original. Depois de preencher a cópia, execute: ```sh node scripts/verify-package.mjs ``` O pacote original deve continuar passando. Aceite esta passagem de trabalho somente se P1/P3 corresponderem ao escopo declarado, P2 continuar classificado como simulado e P4 permanecer em aberto. Uma incógnita não é motivo para marcar como falhas as observações locais conhecidas do pacote; é motivo para não prometer retenção na implantação. Para resolver P4 em um ambiente real, obtenha a configuração exata de implantação e armazenamento e teste de forma independente um registro conhecido durante o procedimento de substituição desse ambiente, usando dados autorizados e não sensíveis. Não há tal configuração ou teste aqui. Separadamente, escritas simultâneas, perda de energia, restauração de backup e notificações reais não foram avaliadas. O código grava o cartão antes de preparar o recibo; assim, uma falha no recibo pode deixar um cartão salvo. Um erro, por si só, não provaria que nada foi armazenado.