TheCreepero/event-pack-create

Event Pack: criar um pacote ou adicionar eventos

Planeja um pacote ou novos eventos, até cada texto, efeito e imagem, em um único arquivo de plano que event-pack-implement executa. Leia docs/source-format.md e docs/style-guide.md antes da Fase 4.

Regras

• Cada fato é verificado em sua página. Um fato entra na ficha de fatos apenas a partir de um KEEP ou FIX da Fase 3a, com sua fonte e sua citação; um detalhe que nenhuma página verificada afirma não entra em um texto, por mais plausível que seja.
• A licença é uma decisão da ferramenta. Uma imagem entra no plano apenas depois que build.ps1 -FetchPicture ... -DryRun imprimir ACCEPTED para ela.
• O editor aprova cada texto. Nenhum plano fica READY com um evento para o qual o editor não tenha retornado KEEP em sua rodada mais recente.
• O pacote finalizado não é tocado aqui. Esta skill escreve o plano, o dossiê em research/<key>/ e arquivos em scratch/; source/ e packs/ são alterados quando o plano é implementado. A única exceção é -NewPack para um pacote totalmente novo (Fase 0); a miniatura do próprio pacote é feita na implementação (Fase 3, passo 5).
• Os dossiês são mantidos. Cada dossiê permanece em research/<key>/, nunca excluído ou aparado, mesmo quando o plano é descartado: os candidatos não escolhidos e os fatos não utilizados são onde começa a próxima expansão do pacote. As únicas adições são as linhas Used: e Checked: da Fase 5.4. Ele é commitado com o plano quando o plano é enviado, ou a pedido do proprietário.
• Pergunte ao proprietário apenas as questões da Fase 0 e da Fase 2.

Fase 0: escopo

1. Pergunte ao proprietário, em uma mensagem: o país (e sua tag, se não for óbvia), o período (padrão: 1936 até o início de sua guerra, mais seus primeiros meses), o número de eventos (padrão: 10 a 15), tipos a enfatizar ou evitar, e qualquer coisa que o pacote não deva abordar. Registre as respostas na seção "Decisões" do plano.
2. Um novo pacote: confirme a tag com a skill hoi4-vanilla-lookup (Get-HoiCountry), depois execute powershell -File .\build.ps1 -NewPack -Pack <key> -Tag <TAG> -DisplayName "<País>"; ela renderiza uma primeira miniatura sobre a tela de carregamento padrão da família com o New-HoiThumbnail.ps1 do Modding Manager (ou copia assets/thumbnail_master.png e imprime o comando quando não for possível executar), que a Fase 3 substitui. Escreva source/<key>/workshop-intro.bbcode: duas ou três frases simples sobre o pacote e as linhas de informação que -NewPack esboçou.
3. Copie docs/plans/TEMPLATE-pack.md para docs/plans/<YYYY-MM-DD>-<key>-<o-que>.md e preencha o cabeçalho, "Contexto" e "Decisões". Para um pacote existente: anote o último id de evento; os novos ids continuam a partir dele.

Fase 1: pesquisa

1. Se research/<key>/ existir, leia seus dossiês. Os candidatos sem uma marca Used: que se encaixam no período e nos tipos são candidatos para este plano também; anote suas chaves. Um candidato com uma linha Checked: foi verificado em suas páginas; julgue-o pelo local que sua linha Checked: mais recente nomeia, não pelos fatos escritos abaixo dela. Uma ficha de fatos ali contém todos os fatos verificados. A "Verificação de fatos" de um plano contém apenas as correções e exclusões, portanto, os fatos do dossiê que ela não nomeia foram mantidos. Se escolhido, ainda passa pela Fase 3a.
2. Candidatos desejados: cerca de uma vez e meia o número de eventos desejados, menos os candidatos anteriores utilizáveis. Divida-os em lotes de no máximo 12, cada um cobrindo sua própria fatia do período (para 30: 1936, 1937-1938, 1939-1940), e despache um ep-historical-researcher por lote, todos em paralelo, cada um com: o país, a tag, sua fatia de período, seu número de candidatos, os tipos da Fase 0, os títulos dos eventos existentes do pacote, cada candidato dos dossiês anteriores como chave, data e uma linha, e seu próprio caminho research/<key>/<YYYY-MM-DD>-dossier.md (com -2 e seguintes para os outros lotes, ou quando esse dia já tiver um). Aguarde cada resumo.

Fase 2: escolher

Leia os novos dossiês. Descarte candidatos cujos fatos-chave sejam UNVERIFIED, que não possam preencher 40 palavras com fatos citados, ou que dupliquem um candidato de outro lote. Mostre ao proprietário os restantes, com os candidatos anteriores utilizáveis marcados como tal, como uma lista curta (chave, data, tipo, condição: janela de data ou estado do jogo, uma linha) com sua recomendação de quais manter e porquê, e aceite a escolha deles.

Fase 3: imagens

1. Despache ep-picture-researcher com os eventos escolhidos: chave, data, local e as ideias de imagem do dossiê.
2. Para cada evento, execute powershell -File .\build.ps1 -FetchPicture -Pack <key> -File "<File:...>" -Key <chave da imagem> -DryRun em sua primeira proposta; em caso de REJECTED, tente a próxima. Um evento sem arquivo aceito recebe uma imagem vanilla (vanilla:GFX_report_event_<nome>, encontrada com Find-HoiUsage da skill hoi4-vanilla-lookup) e uma nota no plano.
3. Escolha o corte e o tom por imagem: warm para fotografias em preto e branco (combina com as próprias imagens do jogo), none para arte colorida; um corte diferente de 50 apenas quando a nota de corte do pesquisador o solicitar.
4. Preencha a tabela "Imagens" do plano com o que as execuções a seco imprimiram.
5. Miniatura, para um novo pacote ou um sem packs.<key>.background em assets/thumbnail.json: o fundo é uma das próprias imagens de evento do pacote, não uma tela de carregamento vanilla. O New-HoiThumbnail.ps1 do Modding Manager desenha o resto no layout fixo do Event Pack (a borda do jogo, "EVENT PACK" e o país na placa de título na parte inferior, a bandeira da tag do pacote no canto superior direito), portanto, a imagem e seu corte são as únicas escolhas. Escolha uma imagem que imprimiu ACCEPTED, de preferência PD ou CC0; CC BY também serve, pois a descrição gerada do Workshop credita cada imagem que um evento usa. Observe a imagem e nomeie onde seu assunto está: a placa cobre cerca de um terço inferior do quadrado e a bandeira cobre seu canto superior direito, portanto, prefira uma imagem cujo assunto possa ficar no meio superior. Uma imagem paisagem preenche toda a altura do quadrado, então o corte ("center", "left", "right") apenas a move lateralmente; uma imagem retrato preenche sua largura, e "top" ou "bottom" mantém o assunto visível; frações de centralização [x, y] o colocam no meio. Escreva Thumbnail: <chave da imagem>, crop <corte> e preencha o passo 4 de "Passos de implementação" com a chave da imagem, o corte como JSON e o caminho absoluto do Modding Manager como <raiz do Manager> (a pasta dois níveis acima deste repositório). Seus comandos usam -Path ., portanto, o ensaio da Fase 5 renderiza e escreve apenas sua cópia. Uma execução a seco não baixa nada, então a miniatura é feita na implementação, após o passo 3, a partir da cópia que -FetchPicture salva em sources-cache/<key>/ (a renderização do Commons, até 1600 px de largura), nunca do DDS 210x176. Um pacote que já possui sua própria miniatura: escreva Thumbnail: unchanged e faça o passo 4 ler Miniatura inalterada: nada a executar., para que os números dos passos permaneçam.

Fase 3a: verificar

Executada após a escolha do proprietário, ao mesmo tempo que a Fase 3, se desejar; a citação de um pesquisador é uma pista, ainda não uma verificação.

1. Despache ep-audit-researcher nos eventos escolhidos, no máximo cinco por agente, todos em paralelo. Cole a seção do dossiê de cada evento por completo; não envie imagens.
2. Apenas fatos KEEP e FIX prosseguem, cada um com a fonte e a citação que o verificador retornou. Um evento com menos de 40 palavras de detalhes verificados volta para a Fase 2 para substituição, e o substituto também passa pela Fase 3a.
3. Preencha a "Verificação de fatos" do plano: agentes e eventos por agente; por evento verificado, incluindo os substituídos, as contagens de KEEP, FIX e DROP, cada fato corrigido com sua correção e cada fato descartado; os eventos substituídos.

Fase 4: escrever

1. Escreva a seção de cada evento escolhido no bloco markdown fact-sheets do plano apenas a partir de seus resultados da Fase 3a: cada linha de fato é - <fato>. Fonte: <URL> (<título da página>). Citação: «<linha da página>». Nunca copie um fato do dossiê diretamente.
2. Escreva os eventos no bloco json events: para um pacote existente, comece a partir do source/<key>/events.json atual e adicione a ele. Siga docs/source-format.md para cada campo e docs/style-guide.md para cada texto. Efeitos pequenos e correspondentes à sua opção; uma ideia temporizada apenas onde o evento a merece. Três regras que o editor o obriga a seguir:
   • Nenhuma afirmação feita unindo dois fatos, a menos que uma citação afirme a afirmação unida.
   • Títulos e funções como eram na data do evento, não como se tornaram depois.
   • O texto permanece verdadeiro em todos os dias da janela fire: nada que ele chame de recente ou futuro pode já ter terminado, ou ainda não ter acontecido, em outro dia da janela.
   • Um evento sobre uma guerra, ou sobre preparação para uma, é condicionado ao estado do jogo em fire.trigger (veja AGENTS.md), não a uma data; seu texto não nomeia nenhuma data histórica para o início da guerra ou os preparativos. Um evento em tempos de paz é bloqueado quando o país está em guerra. Antes de um gatilho entrar no plano, consulte seu escopo com Find-HoiDoc e consulte cada tag, estado e bandeira que ele nomeia no início da janela (Get-HoiState, Get-HoiCountryHistory, Find-HoiUsage): um gatilho que é script válido ainda pode nunca ser verdadeiro em um jogo normal (um país que não existe no início, um estado que outro país possui). Uma consulta que o plano promete para depois é feita antes de o plano ficar READY.
3. Verifique os gatilhos antes que qualquer editor os veja. Despache o agente trigger-checker (o Agents/trigger-checker.md do Modding Manager, instalado em nível de usuário; o Antigravity passa esse arquivo para invoke_subagent) com o caminho do plano, as chaves dos eventos e a tag do pacote. Ele resolve cada fire.trigger contra os arquivos do jogo no fire.after do evento e responde, por evento, se o gatilho pode ser verdadeiro na janela, por quanto tempo ele se mantém contra a verificação semanal, se o texto é falso em um caso que o gatilho permite, e se a janela se encaixa nas datas do texto. Aplique cada FIX como dado, execute os eventos alterados novamente e registre o veredito de cada evento na "Verificação de gatilhos" do plano: OK, o FIX com o gatilho que substituiu o antigo, ou OPEN com a investigação e seu resultado ou a decisão do proprietário. Um plano com um evento OPEN que não tem nem resultado de investigação nem decisão do proprietário não está READY. As condições sugeridas pelo editor são pistas para esta etapa, não gatilhos.
4. Despache ep-editor com o caminho do plano (seu bloco markdown fact-sheets é a ficha de fatos) e as chaves dos eventos. Aplique cada REWRITE como dado; descarte ou substitua um REJECT (de volta à Fase 2 para substituição). Registre cada rodada em "Registro do editor". Envie os eventos alterados de volta ao editor até que cada evento seja KEEP; no máximo três rodadas, depois pergunte ao proprietário.
5. Julgue a introdução do Workshop do pacote, source/<key>/workshop-intro.bbcode: despache workshop-editor no modo mod (o docs/workshop-text-style.md do Modding Manager (..\..\docs\workshop-text-style.md), seção "Auditing a page") com a pasta do mod (a raiz do repositório) e esse arquivo, depois que Test-WorkshopText.ps1 -Mod "Event Packs" -Pack <key> passar. A introdução diz apenas o que o events.json e pictures.json do pacote mostram (o número de eventos, quais eventos carregam uma imagem de período, quais são os efeitos) e usa a redação das introduções dos outros pacotes para o mesmo fato. Aplique cada REWRITE, execute -Generate, Sync-WorkshopRegions.ps1 e a verificação mecânica novamente, depois envie a introdução de volta até que seja KEEP; no máximo três rodadas, depois pergunte ao proprietário. Registre as rodadas em "Registro do editor".

Fase 5: portão

1. Ensaie o plano sem tocar no repositório: robocopy . scratch\rehearsal /MIR /XD .git scratch artifacts sources-cache, então em scratch\rehearsal execute os passos 1 a 8 do plano exatamente como escritos (eles escrevem apenas a cópia). Cada passo deve dar o que diz esperar; corrija o plano, não a cópia, e ensaie novamente. O passo 4 edita o assets\thumbnail.json da cópia; abra a prévia que ele nomeia com a ferramenta de Leitura e escolha outra imagem ou corte quando a placa de título ou a bandeira cobrir o assunto. O passo 8 desenha cada evento como a janela do jogo (scratch\rehearsal\artifacts\workshop-images\<key>\): abra as imagens com a ferramenta de Leitura e encurte um título ou opção para o qual a renderização imprimir um [WARN]: ele transborda sua caixa para o texto abaixo [GUW-027].
2. Preencha "Eventos", liste em "Mantido após julgamento" qualquer [WARN] que o ensaio -Check -Pack <key> ou -RenderEvents -Pack <key> imprimiu e que permaneça, e defina Status: READY.
3. Exclua a cópia: Remove-Item -Recurse -Force scratch\rehearsal.
4. Marque os dossiês, em cada seção da chave do candidato (dossiê e adendo igualmente):
   • Cada evento do plano READY recebe uma linha Used: <nome do arquivo do plano> logo abaixo do seu cabeçalho ## <key>.
   • Cada candidato verificado na Fase 3a, incluindo os substituídos, recebe então uma linha abaixo disso (abaixo do seu cabeçalho se não tiver Used:, abaixo de qualquer linha Checked: anterior): Checked: <nome do arquivo do plano>, <K> mantidos, <F> corrigidos, <D> descartados. Os fatos abaixo são as notas do pesquisador, não os verificados: veja <onde>. As contagens são suas próprias da "Verificação de fatos". <onde> é source/<key>/fact-sheets.md para um evento do plano, e "Verificação de fatos" do plano para um substituído.
   • Não altere nada mais em um dossiê. Um candidato nunca verificado permanece sem marca, como o pesquisador o escreveu.

Fase 6: transferência

Relate ao proprietário: o caminho do plano, os caminhos dos dossiês com quantos candidatos eles guardam para depois, os eventos com seus títulos, as licenças das imagens (quantas PD, CC0, CC BY), a imagem e o corte da miniatura, os totais da verificação de fatos, os totais do editor, e que event-pack-implement o executa. Em seguida, pare.

Antigravity: passe o caminho do briefing de cada agente para invoke_subagent; onde nenhum subagente puder ser despachado, leia o briefing e faça seu trabalho você mesmo, mantendo o trabalho do editor em uma passagem separada que leia apenas o rascunho, a ficha de fatos e o guia de estilo.