TheCreepero/creación-de-paquetes-de-eventos

Paquete de eventos: crear un paquete o añadir eventos

Planifica un paquete o nuevos eventos, hasta cada texto, efecto e imagen, en un solo archivo de plan que event-pack-implement ejecutará. Lee docs/source-format.md y docs/style-guide.md antes de la Fase 4.

Reglas

• Cada hecho se verifica en su página. Un hecho entra en la ficha de datos solo desde un KEEP o FIX de la Fase 3a, con su fuente y su cita; un detalle que ninguna página revisada indique no entra en un texto, por verosímil que sea.
• La licencia es decisión de la herramienta. Una imagen entra en el plan solo después de que build.ps1 -FetchPicture ... -DryRun haya impreso ACCEPTED para ella.
• El editor aprueba cada texto. Ningún plan pasa a LISTO con un evento que el editor no haya devuelto como KEEP en su última ronda.
• El paquete enviado no se toca aquí. Este skill escribe el plan, el dossier en research/<key>/ y los archivos en scratch/; source/ y packs/ cambian cuando se implementa el plan. La única excepción es -NewPack para un paquete completamente nuevo (Fase 0); la miniatura del propio paquete se crea en la implementación (Fase 3, paso 5).
• Los dossiers se conservan. Cada dossier permanece en research/<key>/, sin eliminar ni recortar, incluso si se descarta el plan: los candidatos no elegidos y los hechos no utilizados son el punto de partida para la siguiente expansión del paquete. Las únicas adiciones son las líneas Used: y Checked: de la Fase 5.4. Se confirma junto con el plan cuando el plan se envía, o por orden del propietario.
• Pregunta al propietario solo las preguntas de la Fase 0 y la Fase 2.

Fase 0: alcance

1. Pregunta al propietario, en un solo mensaje: el país (y su etiqueta si no es obvia), el período (por defecto: 1936 hasta el inicio de su guerra, más sus primeros meses), el número de eventos (por defecto 10 a 15), los tipos a enfatizar o evitar, y cualquier cosa que el paquete no deba tocar. Registra las respuestas en las "Decisiones" del plan.
2. Para un paquete nuevo: confirma la etiqueta con el skill hoi4-vanilla-lookup (Get-HoiCountry), luego ejecuta powershell -File .\build.ps1 -NewPack -Pack <key> -Tag <TAG> -DisplayName "<Country>"; esto renderiza una primera miniatura sobre la pantalla de carga predeterminada de la familia con el New-HoiThumbnail.ps1 del Modding Manager (o copia assets/thumbnail_master.png e imprime el comando cuando no se puede ejecutar), la cual la Fase 3 reemplazará. Escribe source/<key>/workshop-intro.bbcode: dos o tres frases sencillas sobre el paquete, y las líneas de información que -NewPack redactó.
3. Copia docs/plans/TEMPLATE-pack.md a docs/plans/<YYYY-MM-DD>-<key>-<what>.md y completa el encabezado, "Contexto" y "Decisiones". Para un paquete existente: anota el último id de evento; los nuevos ids continúan a partir de él.

Fase 1: investigación

1. Si research/<key>/ existe, lee sus dossiers. Sus candidatos sin una marca Used: que encajen en el período y los tipos también son candidatos para este plan; anota sus claves. Un candidato con una línea Checked: ha sido verificado en sus páginas; evalúalo por el lugar que nombra su línea Checked: más reciente, no por los hechos escritos debajo. Una ficha de datos allí contiene todos los hechos verificados. Un plan en su "Verificación de hechos" solo contiene las correcciones y eliminaciones, por lo que los hechos del dossier que no nombra se consideran mantenidos. Si se elige, aún pasa por la Fase 3a.
2. Candidatos deseados: aproximadamente una vez y media la cantidad de eventos deseados, menos los candidatos anteriores utilizables. Divídelos en lotes de máximo 12, cada uno cubriendo su propio segmento del período (para 30: 1936, 1937-1938, 1939-1940), y envía un ep-historical-researcher por lote, todos en paralelo, cada uno con: el país, la etiqueta, su segmento de período, su número de candidatos, los tipos de la Fase 0, los títulos de los eventos existentes del paquete, cada candidato de los dossiers anteriores como clave, fecha y una línea, y su propia ruta research/<key>/<YYYY-MM-DD>-dossier.md (con -2 y siguientes para los otros lotes, o cuando ese día ya tenga uno). Espera cada resumen.

Fase 2: elegir

Lee los nuevos dossiers. Descarta los candidatos cuyos hechos clave sean UNVERIFIED, que no puedan llenar 40 palabras con hechos citados, o que dupliquen un candidato de otro lote. Muestra al propietario el resto, con los candidatos anteriores utilizables marcados como tales, como una lista breve (clave, fecha, tipo, compuerta: ventana de fecha o estado del juego, una línea) con tu recomendación de cuáles conservar y por qué, y toma su decisión.

Fase 3: imágenes

1. Envía ep-picture-researcher con los eventos elegidos: clave, fecha, lugar y las ideas de imagen del dossier.
2. Para cada evento, ejecuta powershell -File .\build.ps1 -FetchPicture -Pack <key> -File "<File:...>" -Key <picture key> -DryRun en su primera propuesta; si es REJECTED, prueba la siguiente. Un evento sin un archivo aceptado recibe una imagen del juego original (vanilla:GFX_report_event_<name>, encontrada con Find-HoiUsage del skill hoi4-vanilla-lookup) y una nota en el plan.
3. Elige el recorte y el tono por imagen: warm para fotografías en blanco y negro (coincide con las imágenes propias del juego), none para arte en color; un recorte diferente a 50 solo cuando la nota de recorte del investigador lo solicite.
4. Completa la tabla "Imágenes" del plan con lo que imprimieron las ejecuciones en seco.
5. Miniatura, para un paquete nuevo o uno sin un packs.<key>.background en assets/thumbnail.json: el fondo es una de las imágenes de eventos del propio paquete, no una pantalla de carga del juego original. El New-HoiThumbnail.ps1 del Modding Manager dibuja el resto en el diseño fijo del paquete de eventos (el borde del juego, "EVENT PACK" y el país en la placa inferior, la bandera de la etiqueta del paquete en la esquina superior derecha), por lo que la imagen y su recorte son las únicas opciones. Elige una imagen que haya impreso ACCEPTED, preferiblemente PD o CC0; CC BY también sirve, ya que la descripción generada del Workshop acredita cada imagen que utiliza un evento. Observa la imagen y dónde se sitúa su tema: la placa cubre aproximadamente el tercio inferior del cuadrado y la bandera su esquina superior derecha, por lo que prefiere una imagen cuyo tema pueda situarse en la parte media superior. Una imagen apaisada llena toda la altura del cuadrado, por lo que el recorte ("center", "left", "right") solo la mueve lateralmente; una imagen vertical llena su ancho, y "top" o "bottom" mantiene el tema dentro; las fracciones de centrado [x, y] lo colocan en medio. Escribe Thumbnail: <picture key>, crop <crop> y completa el paso 4 de "Pasos de implementación" con la clave de la imagen, el recorte como JSON y la ruta absoluta del Modding Manager como <Manager root> (la carpeta dos niveles por encima de este repositorio). Sus comandos toman -Path ., por lo que el ensayo de la Fase 5 renderiza y escribe solo su copia. Una ejecución en seco no descarga nada, por lo que la miniatura se crea en la implementación, después del paso 3, a partir de la copia que -FetchPicture guarda en sources-cache/<key>/ (la representación de Commons, de hasta 1600 px de ancho), nunca del DDS de 210x176. Un paquete que ya tiene su propia miniatura: escribe Thumbnail: unchanged y haz que el paso 4 diga Miniatura sin cambios: nada que ejecutar., para que los números de paso se mantengan.

Fase 3a: verificar

Se ejecuta después de la elección del propietario, al mismo tiempo que la Fase 3 si se desea; la cita de un investigador es una pista, no una verificación.

1. Envía ep-audit-researcher en los eventos elegidos, como máximo cinco por agente, todos en paralelo. Pega cada sección del dossier del evento completa; no envíes imágenes.
2. Solo los hechos KEEP y FIX continúan, cada uno con la fuente y la cita que el verificador devolvió. Un evento que se queda con menos de 40 palabras de detalle verificado vuelve a la Fase 2 para un reemplazo, y el reemplazo también pasa por la Fase 3a.
3. Completa la "Verificación de hechos" del plan: agentes y eventos por agente; por evento verificado, incluidos los reemplazados, los recuentos de KEEP, FIX y DROP, cada hecho corregido con su corrección y cada hecho descartado; los eventos reemplazados.

Fase 4: redacción

1. Escribe la sección de cada evento elegido en el bloque markdown fact-sheets del plan solo a partir de sus resultados de la Fase 3a: cada línea de hecho es - <facto>. Fuente: <URL> (<título de la página>). Cita: «<línea de la página>». Nunca copies un hecho de un dossier directamente.
2. Escribe los eventos en el bloque json events: para un paquete existente, comienza desde el source/<key>/events.json actual y añade a él. Sigue docs/source-format.md para cada campo y docs/style-guide.md para cada texto. Efectos pequeños y que coincidan con su opción; una idea temporizada solo cuando el evento la merezca. Tres reglas a las que el editor te exige:
   • Ninguna afirmación hecha uniendo dos hechos, a menos que una cita establezca la afirmación unida.
   • Títulos y roles tal como eran en la fecha del evento, no como llegaron a ser después.
   • El texto se mantiene verdadero en cada día de la ventana fire: nada que llame reciente o próximo puede haber terminado ya, o no haber sucedido aún, en otro día de la ventana.
   • Un evento sobre una guerra, o sobre prepararse para una, se cierra con la compuerta en el estado del juego en fire.trigger (consulta AGENTS.md), no en una fecha; su texto no nombra ninguna fecha histórica para el inicio de la guerra o los preparativos. Un evento en tiempo de paz se bloquea una vez que el país está en guerra. Antes de que un disparador entre en el plan, busca su ámbito con Find-HoiDoc, y busca cada etiqueta, estado y bandera que nombre al inicio de la ventana (Get-HoiState, Get-HoiCountryHistory, Find-HoiUsage): un disparador que es script válido aún puede no ser verdadero nunca en una partida normal (un país que no existe al inicio, un estado que posee otro país). Una búsqueda que el plan promete para más adelante se realiza antes de que el plan esté LISTO.
3. Verifica los disparadores antes de que el editor los vea. Envía el agente trigger-checker (el Agents/trigger-checker.md del Modding Manager, instalado a nivel de usuario; Antigravity pasa ese archivo a invoke_subagent) con la ruta del plan, las claves de los eventos y la etiqueta del paquete. Resuelve cada fire.trigger con los archivos del juego en el fire.after del evento y responde, por evento, si el disparador puede ser verdadero en la ventana, cuánto tiempo se mantiene contra la verificación semanal, si el texto es falso en un caso que el disparador permita, y si la ventana se ajusta a las fechas del texto. Aplica cada FIX tal como se da, vuelve a ejecutar los eventos modificados y registra el veredicto de cada evento en la "Verificación de disparadores" del plan: OK, el FIX con el disparador que reemplazó al anterior, o ABIERTO con la sonda y su resultado o la decisión del propietario. Un plan con un evento ABIERTO que no tenga ni un resultado de sonda ni una decisión del propietario no está LISTO. Las condiciones sugeridas por el editor son pistas para este paso, no disparadores.
4. Envía ep-editor con la ruta del plan (su bloque markdown fact-sheets es la ficha de datos) y las claves de los eventos. Aplica cada REESCRITURA tal como se da; descarta o reemplaza un RECHAZO (vuelve a la Fase 2 para un reemplazo). Registra cada ronda en "Registro del editor". Vuelve a enviar los eventos modificados al editor hasta que cada evento sea KEEP; como máximo tres rondas, luego pregunta al propietario.
5. Evalúa la introducción del paquete en el Workshop, source/<key>/workshop-intro.bbcode: envía workshop-editor en modo mod (el docs/workshop-text-style.md del Modding Manager (..\..\docs\workshop-text-style.md), sección "Auditar una página") con la carpeta del mod (la raíz del repositorio) y ese archivo, después de que Test-WorkshopText.ps1 -Mod "Event Packs" -Pack <key> pase. La introducción dice solo lo que muestran el events.json y pictures.json del paquete (el número de eventos, qué eventos llevan una imagen de época, cuáles son los efectos) y usa la redacción de las introducciones de otros paquetes para el mismo hecho. Aplica cada REESCRITURA, ejecuta -Generate, Sync-WorkshopRegions.ps1 y la verificación mecánica de nuevo, luego vuelve a enviar la introducción hasta que sea KEEP; como máximo tres rondas, luego pregunta al propietario. Registra las rondas en "Registro del editor".

Fase 5: compuerta

1. Ensaya el plan sin tocar el repositorio: robocopy . scratch\rehearsal /MIR /XD .git scratch artifacts sources-cache, luego en scratch\rehearsal ejecuta los pasos 1 a 8 del plan exactamente como están escritos (escriben solo la copia). Cada paso debe dar lo que dice que espera; corrige el plan, no la copia, y vuelve a ensayar. El paso 4 edita el assets\thumbnail.json de la copia; abre la vista previa que nombra con la herramienta Read, y elige otra imagen o recorte cuando la placa del título o la bandera cubran el tema. El paso 8 dibuja cada evento como la ventana del juego (scratch\rehearsal\artifacts\workshop-images\<key>/): abre las imágenes con la herramienta Read, y acorta un título u opción para el que el render imprima un [WARN]: se desborda de su caja hacia el texto de abajo [GUW-027].
2. Completa "Eventos", lista en "Mantenido en juicio" cualquier [WARN] que el -Check -Pack <key> o -RenderEvents -Pack <key> del ensayo haya impreso y que se mantenga, y establece Estado: LISTO.
3. Elimina la copia: Remove-Item -Recurse -Force scratch\rehearsal.
4. Marca los dossiers, en cada sección de la clave del candidato (dossier y apéndice por igual):
   • Cada evento del plan LISTO recibe una línea Used: <nombre del archivo del plan> justo debajo de su encabezado ## <key>.
   • Cada candidato que la Fase 3a verificó, incluidos los reemplazados, recibe luego una línea debajo de esa (debajo de su encabezado si no tiene Used:, debajo de cualquier línea Checked: anterior): Checked: <nombre del archivo del plan>, <K> mantenidos, <F> corregidos, <D> descartados. Los hechos a continuación son las notas del investigador, no los verificados: consulte <lugar>. Los recuentos son los suyos propios de "Verificación de hechos". <lugar> es source/<key>/fact-sheets.md para un evento del plan, y la "Verificación de hechos" del plan para uno reemplazado.
   • No cambies nada más en un dossier. Un candidato nunca verificado permanece sin marcar, tal como lo escribió el investigador.

Fase 6: transferencia

Informa al propietario: la ruta del plan, las rutas de los dossiers con cuántos candidatos conservan para más adelante, los eventos con sus títulos, las licencias de las imágenes (cuántas PD, CC0, CC BY), la imagen y el recorte de la miniatura, los totales de verificación de hechos, los totales del editor, y que event-pack-implement lo ejecuta. Luego detente.

Antigravity: pasa la ruta de cada instrucción del agente a invoke_subagent; donde no se pueda enviar un subagente, lee las instrucciones y realiza el trabajo tú mismo, manteniendo el trabajo del editor en una pasada separada que lea solo el borrador, la ficha de datos y la guía de estilo.