marcozhou26/one-slide

OneSlide

Processa exatamente um slide por vez, organizando lógica, informações e layout no padrão de relatórios de consultoria. O usuário interage apenas com esta entrada; internamente, o design e a proveniência do conteúdo são tratados primeiro, e o Builder integrado é invocado apenas quando necessário para gerar o PPTX.

Execute estas leituras primeiro

Leia completamente:

• references/input-contract.md
• references/suite-contract.md
• producer/references/single-slide-contract.md
• producer/references/provenance-contract.md
• producer/references/output-contract.md

Ao entrar na fase de desenho, leia builder/ENGINE.md e a referência do módulo único retornado pela rota. Não leia todos os módulos do Builder antecipadamente.

Primeira interação

Explique naturalmente que esta rodada produzirá apenas um slide. Em seguida, com base na conversa atual, anexos e decisões já tomadas, preencha:

• O que este slide deve comunicar;
• Quem vai ver e o que deve entender ou decidir ao final;
• Um problema principal, uma relação principal e uma conclusão central;
• Quais conteúdos são fornecidos pelo usuário e devem ser preservados;
• Quais lacunas serão preenchidas de forma direcionada e marcadas.

Faça uma pergunta bloqueante apenas se houver duas direções igualmente razoáveis que alterem a conclusão central ou o gráfico principal. Não peça ao usuário para preencher campos internos, números de módulo, coordenadas, quantidade de cartões ou preferências de decoração.

Dois tipos de saída

Derive da fala do usuário:

• PROMPT_ONLY: o usuário quer um prompt, brief, pacote de transferência ou instrução de geração.
• PPT_DRAFT: o usuário quer criar, desenhar, gerar ou entregar um PowerPoint.

Se o formato não for especificado, assuma PROMPT_ONLY e explique brevemente. Se o usuário posteriormente mudar para PPT_DRAFT, reutilize as fontes e direções já definidas sem pedir que o material seja reexposto.

Três modos de conteúdo

• SOURCE_ONLY: as informações existentes são suficientes para este slide; nenhum fato novo é adicionado.
• SYNTHETIC_AUGMENTATION: apenas preenche as lacunas necessárias do slide, sem alterar os fatos do usuário ou a lógica principal.
• EVIDENCE_BLOCKED: o objetivo exige fatos reais, mas faltam evidências e não é possível preenchê-las honestamente.

Estilo, redação, layout e escolha de gráficos não são lacunas factuais; podem ser derivados da relação principal.

Fluxo de trabalho

1. Definir o escopo do slide único

Preserve a solicitação original do usuário e crie registros de origem e hash para os anexos utilizados. Cada execução pode ter apenas:

1 tarefa de audiência
1 problema principal
1 relação principal
1 conclusão central
1 gráfico principal
0-3 temas de evidência de suporte
0-1 ação ou condição

Se houver gráficos principais concorrentes ou mais de três temas de evidência, retorne SINGLE_SLIDE_SCOPE_OVERLOAD e recomende o foco mais forte para o slide único; não remova conteúdo essencial nem gere um segundo slide.

2. Estabelecer a linha de base de fontes

Atribua um source_id estável para cada tipo de fonte: fornecida pelo usuário, dedução estável, cálculo, verificação externa e preenchimento pelo modelo. Mantenha inalterados os números, definições, força da conclusão, itens obrigatórios e exclusões do usuário.

Os anexos do usuário são "evidências fornecidas pelo usuário", não equivalem automaticamente a fatos verificados independentemente. Em caso de conflito de autoridade, pare os cálculos afetados; não tome partido implicitamente.

3. Preenchimento direcionado

Se o conteúdo for insuficiente, preencha apenas o mínimo necessário para o gráfico principal e os temas de evidência declarados:

• Dados sintéticos devem definir objeto, granularidade, período, unidade, denominador e regra de cálculo;
• Totais, proporções, funis, pontes, valores duplicados e conclusões dos títulos devem ser consistentes;
• Conteúdo qualitativo sintético deve ser tratado como "hipótese", "exemplo" ou "a confirmar";
• Não invente fontes, falas do cliente, benchmarks do setor, conclusões legais ou resultados reais de empresas.

Se uma organização real não tiver dados reais, não escreva métricas fictícias em nome dessa organização. Você pode transformar em exemplo anônimo ou retornar EVIDENCE_BLOCKED.

4. Gerar o pacote de conteúdo

Execute conforme producer/ENGINE.md e produza um diretório de execução versionado. Cada fato visível, título, dado de gráfico, insight e ação deve ter source_ids.

Números ou conjuntos de dados sintéticos devem exibir no slide:

Dados de exemplo sintéticos, não dados reais de clientes

Conteúdo qualitativo sintético deve exibir "a confirmar" em local adjacente ou usar uma legenda do slide que mapeie item por item. Se o usuário confirmar um cenário, ele continua sendo uma hipótese de cenário, não um fato real.

Execute:

python3 producer/scripts/validate_package.py <run-directory> --stage handoff --write-report

Após a validação estrutural, leia completamente o Brief, Prompt, documento de transferência e lista de verificação de conteúdo. O script não pode comprovar a lógica de consultoria ou a qualidade visual do PPT.

5. Entregar conforme o modo de saída

Saída PROMPT_ONLY:

• handoff/builder-prompt.md
• handoff/builder-handoff.json
• review/content-review.md

PPT_DRAFT: após a aprovação do pacote de conteúdo, leia builder/ENGINE.md e passe handoff/builder-handoff.json para o Builder integrado. O Builder é responsável pela seleção de módulos, geometria precisa, objetos do PowerPoint, renderização e QA do PPTX; não reescreva o objetivo do slide ou os fatos de origem.

Após a entrega do Builder, execute novamente:

python3 producer/scripts/validate_package.py <run-directory> --stage final --write-report

Se o Builder não estiver disponível, faltarem dependências de execução ou retornar MODULE_COVERAGE_GAP, mantenha o pacote de prompt utilizável e retorne PPT_RENDERING_BLOCKED. Não troque secretamente por um renderizador genérico e alegue ter gerado um PPT de nível consultoria.

O Producer só deve gravar requested_module e um module_payload completo e validável pelo validador do módulo quando um módulo já em produção cobrir todo o conteúdo obrigatório. Não force o acerto apenas com o nome do módulo sem payload executável; para slides mistos, use orquestração direta com controle de acesso via layout.

6. Verificar o PPTX

PPT_DRAFT deve atender:

• Exatamente uma página, 16:9;
• Texto, formas, tabelas e gráficos são objetos nativos editáveis do PowerPoint;
• Aprovado em auditoria semântica, verificação de renderização de página inteira e verificação de legibilidade;
• O layout JSON passa nas verificações de: tag curta em linha única, órfãos, tokens em inglês, unidade numérica, título e subtítulo mutuamente exclusivos em duas linhas, zona segura do título, equilíbrio vertical, alinhamento de bordas entre blocos, utilização da tela e limites de área;
• Organogramas: verificação adicional de alinhamento horizontal entre nós do mesmo nível, alinhamento vertical de linhas de subordinação direta, direção de linhas funcionais e sem rotas que se cruzem; não entregue se houver ORG_PEER_ROW_MISALIGNMENT, ORG_DIRECT_REPORT_DOGLEG ou ORG_FUNCTIONAL_ROUTE_AMBIGUOUS;
• Se o ambiente atual tiver Microsoft PowerPoint, abra e verifique fisicamente;
• O diretório de entrega externa deve conter apenas o PPTX versionado; fontes, prompts, prévias e QA permanecem no diretório interno.

Limites rígidos

• Não gere relatórios de várias páginas, páginas ocultas de estouro ou uma segunda página candidata.
• Não adicione cartões decorativos, sugestões, métricas ou benchmarks para preencher a página.
• Não remova conteúdo essencial, reduza a fonte a tamanhos ilegíveis ou mude a ideia central para caber em uma página.
• Não disfarce conteúdo preenchido pelo modelo como fornecido pelo usuário ou verificado externamente.
• Não exponha caminhos locais, histórico de prompts, soluções descartadas, QA interno ou instruções de produção.
• Não confunda geração de arquivo, aprovação em script de validação ou integridade do ZIP com valor de produto ou aceitação pelo usuário.

Autoverificação do pacote de lançamento

python3 scripts/validate_suite.py .
python3 -m unittest discover -s tests -v
python3 scripts/check_environment.py

Status

Relate separadamente:

BASIC_OUTPUT_PASS | fail
TECHNICAL_CHAIN_PASS | not_tested | fail
INPUT_CONTRACT_PASS | not_tested | fail
SOURCE_BASELINE_PASS | fail
SINGLE_SLIDE_SCOPE_PASS | fail
PROVENANCE_COVERAGE_PASS | fail
SYNTHETIC_DISCLOSURE_PASS | not_applicable | fail
DATA_RECONCILIATION_PASS | not_applicable | not_tested | fail
HANDOFF_PACKAGE_PASS | fail
BUILDER_HANDOFF_READY | not_applicable | fail
RENDERED_READABILITY_PASS | not_applicable | not_tested | fail
POWERPOINT_OPEN_CHECK | not_applicable | not_tested | fail
REQUIREMENT_COVERAGE_PASS | not_tested | fail
PRODUCT_VALUE_PASS | not_tested | fail
USER_REQUIREMENT_PASS | not_tested
PUBLIC_LICENSE_READY | pass

Somente quando o resultado visível ao usuário real atender aos requisitos de slide único, fonte e editabilidade desta Skill, poderá ser marcado PRODUCT_VALUE_PASS. Somente depois que o usuário tiver visto o resultado específico, poderá ser marcado USER_REQUIREMENT_PASS.