mvpfy-document

Consolidar o MVP.md

Use assets/MVP.template.md como fonte estrutural. O documento final deve ser um único arquivo Markdown, compreensível sem o histórico da conversa, com metadados, resumo do MVP, análise de requisitos, problema, público, personas, escopo, SaaS, mercado, preço, custos, tecnologia, marketing, métricas, plano de execução e pendências.

Execute scripts/render-company.mjs --project <diretório> para criar ou atualizar o arquivo. O script localiza seções pelos IDs HTML mvpfy:section:<id>, preserva conteúdo existente e usa “Pendente” quando faltarem dados. A seção requirements-analysis é regenerada a partir de .mvpfy/answers.jsonl, .mvpfy/state.json e .mvpfy/existing-project.json. Ela mantém o texto original de cada entrada e organiza módulos, recursos, telas, ferramentas, pessoas, dados, fluxos e requisitos operacionais.

A seção requirements-specification permanece no template como estrutura de consolidação. Preencha suas subseções com a análise da entrada recebida; ela não depende de arquivos auxiliares no projeto consumidor.

Ao consolidar, percorra as subseções aplicáveis ao MVP da pessoa. Registre nelas os detalhes já presentes na descrição inicial, nas respostas, nos itens candidatos e no contexto encontrado. Não reduza uma descrição ampla a uma lista curta de funcionalidades. Quando um tópico não for necessário para o MVP atual, use Não se aplica ao MVP atual; quando faltar informação para um tópico relevante, use Pendente e formule a lacuna de forma específica.

Execute o mesmo script com --check antes de uma gravação. Valide depois com scripts/validate-company.mjs --project <diretório>. O estado só pode ser ready quando os campos mínimos do MVP SaaS estiverem preenchidos; caso contrário, use preliminary e liste as lacunas.

Gate editorial e de publicação

Antes de gerar um ebook, confirme que docs/user/reading-order.txt contém somente páginas destinadas à pessoa usuária. A referência técnica e a especificação continuam disponíveis online, mas não entram no guia do usuário. Compare a estrutura com um projeto de referência do Hub e mantenha a identidade visual sem copiar sua prosa.

Leia o conjunto de páginas como uma publicação inteira. Reescreva trechos que pareçam catálogo, lista de recursos ou anotação de agente. Cada seção pública precisa explicar a situação, a ação, o efeito e o limite da orientação. Listas e tabelas devem organizar informação paralela, nunca substituir a explicação.

Depois da leitura editorial, gere PDF e EPUB, leia o resultado e rode os validadores do submódulo e do Hub. Um build correto comprova o arquivo gerado, mas não comprova a qualidade do texto.

Use o mesmo SemVer do framework no PDF, no EPUB e no manifesto. VERSION é a fonte canônica e ebooks/VERSION é apenas um espelho conferido pelo build. Se os valores divergirem, corrija a versão antes de gerar ou publicar os formatos.

Leia document-rules.md para a ordem canônica.