ayase0307/ai-comic-drama

Producción de AI漫劇 (Versión solo Agente)

Reglas de inicio (hacer siempre, sin excepción)

1. Primero ejecuta python scripts/h3d.py next --root <proyecto>, haz la "única instrucción" que imprima, y lee la referencia que especifique. No organices tu propio flujo ni te saltes pasos.
2. La decisión final del usuario siempre se registra con h3d decide <id> <valor> --quote "<palabras textuales del usuario>" en decisions.json (estilo, relación de aspecto, política de diálogos, motor de diseño, política de aceptación, método de edición...). No lo escribas solo en notas, y no decidas por el usuario.
3. No modifiques manualmente review/project-state.json. El estado solo puede ser escrito por build_stage_review.py; la modificación manual será considerada un bloqueo por h3d next. Si la etapa 6 de QA técnico es PARCIAL y el usuario lo aprueba después de verlo, usa --approve-stage 6 --override --reason "<motivo del usuario>".
4. Las conclusiones por segmento de la etapa 6 siempre se registran con h3d verdict en review/verdicts.json (pass/warn/fail + una frase de motivo + imagen de evidencia), clasificadas según acceptance_policy. 3a. El backend de generación de imágenes lo elige el usuario, no se presupone por defecto: antes de generar la imagen de diseño (etapa 2) o el storyboard (etapa 4), ejecuta primero h3d imagegen --detect --root <proyecto> para listar las herramientas detectadas como disponibles (las no disponibles con motivo), y pide al usuario que elija—incluso si solo se detecta una disponible, debes preguntar; después de la respuesta, ejecuta h3d imagegen --set <backend> [--stage 2|4] --quote "<palabras textuales del usuario>". Si h3d next encuentra que no se ha elegido o que lo elegido no está disponible, te indicará que preguntes (references/tooling.md §2.4.1). 4a. Las decisiones que debe tomar el usuario se generan en una bandeja de entrada con h3d inbox (solo las excepciones); las etapas autorizadas por el usuario se ejecutan con h3d approve --auto según h3d next. La etapa 0, la imagen de diseño de personajes, y el tono de voz de cada personaje siempre requieren decisión humana (ver references/tooling.md §2.6).
5. No ejecutes dos runners de video al mismo tiempo; si el ledger tiene trabajos en estado waiting/running, solo recoge resultados (h3d collect), no envíes nuevos trabajos.
6. Si te encuentras con PARTIAL o duration_drift, detente, actúa según references/tooling.md §4 e informa al usuario. No lo evites por tu cuenta.
7. El formato de entrega por defecto es largometraje de cómic drama: la prioridad es contar la historia con claridad; cada evento clave de la obra original debe incluir causa → desarrollo → consecuencia (incluyendo motivación, cambios de tiempo y lugar). No comprimas eventos para cumplir con la duración de un episodio. Por defecto, no se divide en episodios; toda la obra es un solo video continuo. El formato de serie corta vertical de alto impacto (1-2 minutos, con gancho fuerte) solo se usa si el usuario lo solicita explícitamente (h3d decide series_format short). Los eventos que se hayan comprimido, omitido o explicado insuficientemente serán restaurados por el agente según la obra original (event_coverage.py). No los elimines por tu cuenta ni preguntes al usuario.
8. No preguntes al usuario sobre la reescritura del guion: sigue siempre references/adapt/dialogue-first-adaptation.md (conserva todo el diálogo original; solo los diálogos que son paráfrasis se pueden reescribir y marcar como invented; la narración debe ser la voz interior del protagonista VO ≤30%; la duración del episodio no tiene límite; los cortes deben estar en puntos naturales de la historia y registrar el ancla de la obra original + motivo; antes de la entrega, deben pasar todas las comprobaciones de adapt_gate.py).
9. Antes de empezar, verifica la versión de la skill: si h3d --version no coincide con la versión registrada en review/project-state.json, primero sincroniza la skill antes de trabajar. El mismo prompt puede tener diferentes umbrales en diferentes versiones (15→18 caracteres por oración, 60%→90% de proporción de diálogo, 2.0→1.2 segundos de duración mínima de plano, nuevas comprobaciones de densidad D2 y apertura D4). Aplicar reglas antiguas a un borrador nuevo resultará en trabajo en vano. La copia de la skill en el directorio de instalación no es necesariamente un repositorio git; si el repositorio de origen está en la máquina local, haz pull primero y luego sobrescríbelo todo, pero antes de sobrescribir haz una copia de seguridad.
10. Las correcciones deben hacerse por lotes, no volver a aprobar frase por frase: corrige todos los segmentos con el mismo tipo de problema (mismo patrón de oración, mismo problema en un lote) de una sola vez, luego haz rebuild → h3d bind → h3d compile → vuelve a aprobar etapa 4/5 (un lote significa verificar cada plano contra shot_intent para confirmar que es la misma causa raíz, no corregir por tipo de advertencia; los segmentos corregidos en la etapa 5 deben seguir la aprobación por segmento con --segments, no uses --auto). Volver a aprobar cada vez que corriges una frase consumirá todo el tiempo de revisión, y la etapa 5 bloqueará si las huellas digitales de layer2 y segments no están sincronizadas. El rebuild borrará los campos sketch_*; antes de reconstruir, haz una instantánea con shot_id y después de reconstruir, restáuralos. Si cambia el número o el código de un segmento, sincroniza la tabla de storyboard de REMIX (PUT /projects/{id}/storyboard): la interfaz/sala de revisión lee el campo "N planos previstos" y las agrupaciones de capítulos de ese documento, no de segments-*.json; si no se actualiza, siempre mostrará la planificación antigua (por ejemplo, 133 planos vs. 18 segmentos reales). Antes de cambiarlo, usa GET /jobs?project=<id> para verificar plano por plano que el código antiguo no tiene trabajos pendientes—si no los hay, sobrescríbelo completamente. Cuando el usuario dice "sortear" o "organiza la revisión/edición/ciclo tú mismo" = ejecuta todo el ciclo de forma autónoma (enviar trabajo → recoger resultado → muestrear fotogramas para revisión → corregir → volver a muestrear), deteniéndote solo en los puntos de control humano (aprobación de la etapa 6, cuando el usuario necesita escribir el motivo de la sobrescritura); los informes deben ser por "ronda + cuatro imágenes de evidencia + qué se corrigió", no informes cada vez que muestreas un segmento.
11. El paquete de referencia anula el prompt: todo lo que aparece en el plano madre del paquete REMIX aparecerá en cada plano (edificios brillantes, mochilas, cielo nocturno en el plano madre cuentan). Para cambiarlo, cambia el paquete o regenera el plano madre; no uses frases negativas en el prompt para forzarlo—mencionar un objeto = el objeto aparece. Los detalles están en references/remix-draft-loop.md.
12. La versión aprobada y la versión final se guardan por separado; cambiar de versión requiere nueva verificación: videos/<segmento>.mp4 siempre contiene la versión que "ha pasado QA y ha sido firmada"; el material final de pika768, la superresolución, los candidatos para resorteo van en videos/final-768/ y otros subdirectorios. Para promocionar un final a versión aprobada = volver a ejecutar h3d qa/motion/--continuity → reconstruir la instantánea de la etapa 6 → el usuario la vuelve a firmar; no sobrescribas el archivo directamente para cambiar la versión, eso hará que la instantánea firmada y la evidencia no coincidan.

Descripción general

Completa la adaptación de novelas, guiones, storyboards de dirección, prompts, o utiliza herramientas de imagen/video realmente disponibles para generar medios, según el alcance de entrega especificado por el usuario. La planificación de texto se puede entregar de forma independiente; la generación de medios requiere las herramientas correspondientes o un backend conectado (FreeVideo es un adaptador opcional, no significa que cada agente tenga integrada la generación de video). Sin llamar realmente a una herramienta de generación, no se debe afirmar que se ha producido una imagen o video. Las novelas no se pueden usar directamente como guiones; primero deben pasar por la etapa 1 de adaptación. Si asumes un proyecto existente (no comenzado desde cero por ti), primero audítalo antes de avanzar: lee primero references/audit-inherited-project.md; no continúes escribiendo basándote en el storyboard del agente anterior—un upstream defectuoso hará que cada plano tenga que rehacerse; antes de juzgar "activo duplicado" o "error de contenido", verifica siempre contra la biblia y el número de línea de la obra original, no solo mires la imagen o el nombre del archivo.

Esta página es la página de inicio de operaciones: qué hacer en cada etapa, qué no hacer, qué comando ejecutar. Los principios, plantillas, decisiones prácticas y la lista completa de herramientas están en references/skill-guide.md (texto completo de SKILL.md, capítulos sin cambios), a la que h3d next te dirigirá para que leas la correspondiente.

Cuándo usar

• "Convierte esta novela/historia en un AI漫劇, 動態漫, 短劇" "Adapta la novela a un guion de AI漫劇"
• "Escribe el storyboard/lista de planos/prompts de video" "Diseña las fichas de personaje/biblia de personajes" "Convierte el material del producto en un video de venta corto"

Página de inicio de operaciones por etapa

Etapa	Qué hacer	Qué no hacer	Qué comando ejecutar	Leer primero
0 Definición	Preguntar todas las preguntas de definición de una sola vez (tema, soporte, estilo, relación de aspecto), cada una con valores recomendados; la política de diálogo se fija como "dar prioridad al diálogo original" sin preguntar; el formato de entrega por defecto es largometraje de AI漫劇 (no preguntar por episodios/duración; solo si el usuario solicita explícitamente cortometraje, entonces h3d decide series_format short); el estilo por defecto recomendado es el nº 14 "Estilo antiguo realista y espeso con sensación cinematográfica" (con imagen de muestra, se puede cambiar)	No decidas por el usuario; no te saltes la inferencia del volumen; no presupongas dividir en episodios cortos	init_project.py, h3d decide style/aspect_ratio	references/pipeline.md, references/styles.md
1 Adaptación	Conserva la clasificación por niveles, la integridad de la narración de eventos (cada evento: causa → desarrollo → consecuencia; las omisiones las completa el agente), reescritura prioritaria de diálogos y división por presupuesto de diálogo, estructura de párrafos, deuda causal; antes de la entrega, deben pasar todas las comprobaciones de adapt_gate.py	Usar la novela directamente como guion; comprimir eventos por duración; eliminar por cuenta propia la narración de eventos	event_coverage.py, dialogue_budget.py, adapt_gate.py, h3d next	references/adapt/dialogue-first-adaptation.md, references/adapt/novel-to-manju.md, references/adapt/structure-and-pacing.md §0
2 Diseño de personajes	El usuario elige la herramienta de generación de imágenes después de la detección (incluso si solo hay una disponible, hay que preguntar); generar primero la imagen del personaje principal, después de la autoverificación, regenerar; una vez que la herramienta está decidida, todo el proyecto queda bloqueado; cada efecto especial en el guion debe tener su propia tarjeta de efecto B- y una imagen de referencia ya revisada (sin imagen, no se puede pasar a la etapa 5, E56)	Presuponer la herramienta de generación de imágenes por defecto; cambiar de herramienta de generación sin comparar lado a lado; aprobar automáticamente (siempre se necesita que una persona vea la cara y la ropa)	h3d imagegen --detect/--set (escribe design_engine), página de revisión	references/consistency.md, references/styles.md
3 Guion	Reescritura por escenas, presupuesto de diálogo (velocidad de habla del personaje 4.0/4.5/VO 5.5 caracteres/segundo, proporción de diálogo 75-90%), diferencias de adaptación, revisión ciega antes de la entrega (un subagente nuevo recibe solo el paquete de material del guion: build_blind_review.py --stage 3, reglas en references/blind-review.md)	Enviar material que supere el presupuesto	estimate_duration.py --h3, sync_script.py	references/adapt/screenplay-format.md
4 Storyboard	Para cada plano, primero escribe shot_intent (qué debe entender el espectador) y luego los valores técnicos, cada elección debe tener un motivo en choice_why; el movimiento de cámara se elige según el ritmo de la batida, consultando references/camera-moves-guide.md para seleccionar move_preset (el motivo de la selección se escribe en la tabla de storyboard, el compilador lo expande, move_lint advierte); cada segmento debe tener una cuenta de personajes, para los planos de diálogo escribir la línea de visión, para las costuras entre segmentos escribir el estado final y cambiar la posición de la cámara (continuity-ledger.md); Ref2VA por defecto: un plano, una imagen con cara reconocible (recorte de una sola persona, no aplica cuando se usa un paquete de personajes remix), no poner personas en planos generales, escribir distancia focal y distancia al objeto como un par	Pasar a la compilación sin el PNG de composición correspondiente; corregir por tipo de advertencia; modificar el contenido aprobado para pasar la verificación (cambiar multitudes por asientos vacíos, añadir empty background); cambiar de persona en las imágenes del storyboard u omitir objetos clave	Cuando falte la composición: h3d imagegen --detect/--set --stage 4 (el usuario elige storyboard de Codex/lápiz de Qwen de nueve cuadrantes/dibujo a mano, escribe storyboard_engine) → h3d next da las instrucciones para esa herramienta (Codex necesita --model <modelo especificado por el usuario>), validate_storyboard.py	references/storyboard/shot-intent.md, references/storyboard/cinematic-director.md, references/storyboard/continuity-ledger.md; si hay peleas/golpes/efectos especiales, carga también h3-combat-impact (ver sección siguiente)
5 Prompts	Escribe manualmente plano por plano Layer 2 five_part_en (Camera/Motion/Performance/Light/Sound, Motion y Performance deben ser detallados; cada frase debe corresponder a un resultado visible o audible; no reescribas la apariencia que ya tiene la imagen de referencia; escribe la posición, la línea de visión, la pose inicial y final, los objetos clave), lee el storyboard, la composición y el estado del plano anterior antes de escribir; el compilador solo se encarga de formar la estructura de seis partes; antes de enviar, ejecuta prompt_sketch_audit.py para verificar frase por frase la correspondencia prompt ↔ composición (para segmentos fl2v, primero frame_pair_qa.py superpone las imágenes)	Escribir código para generar las cinco subsecciones; sobrescribir segments después de la compilación; usar metapalabras (authored/approved) o apilar frases prohibidas para salir del paso; pasar por alto las advertencias sin hacer ack	h3d bind (primero generar la imagen de referencia y vincularla), h3d author, h3d compile --check, h3d catalog --check	references/prompt-authoring.md, references/h3/prompt-formats.md, references/tooling.md; para segmentos de pelea/golpe especial, escribir también según h3-combat-impact
6 Video	Enviar trabajo → recoger resultado → QA → QA dinámico (congelación/flujo óptico, propuesta automática de lista de cambios de velocidad) → QA de continuidad en la costura (punto de corte real + collage de costura + candidato estático en un lado, solo advertencia) → --continuity-pairs responde par por par a la lista de seis preguntas de continuidad (location/prop/screen side/costume/light/effect) → conclusión por segmento → bandeja de entrada	Ejecutar dos runners al mismo tiempo; tocar el trabajo de otro; enviar material con deriva a QA; usar la duración planificada para muestrear fotogramas y juzgar la costura (primero mira el punto de corte real encontrado por --continuity)	h3d probe, h3d run --plan, h3d qa, h3d motion, h3d qa --continuity, h3d verdict, h3d inbox	references/tooling.md §2.5–2.8 (QA de costura en §2.8.1), references/remix-draft-loop.md (ciclo de sorteo REMIX → revisión → corrección), references/speed-ramp.md, references/skill-guide.md "Etapa 6 Generación"
7 Subtítulos y edición	Postproducción de cambios de velocidad en segmentos de acción ya aprobados (el metraje original no se mueve, el diálogo a velocidad original), sonoridad, tono de voz de cada personaje decidido de una vez, proyecto de edición único para todo el proyecto, revisión ciega antes de la entrega (build_blind_review.py --stage 7 collage de fotogramas, reglas en references/blind-review.md)	Todos los diálogos, narraciones y voces en off son generados de forma nativa por H3 (no hay TTS externo); decidir el tono de voz por el usuario; sobrescribir el metraje original; modificar la velocidad en la zona de diálogo	h3d ramp, h3d concat plan/build, h3d assemble; lente de edición (solo sugerencias) scripts/craft/edit_review.py	references/tooling.md §2.7, references/skill-guide.md "Etapa 7", references/edit/manju-editing-playbook.md (puntos de corte/transiciones/efectos/subtítulos/tarjetas de aparición/ducking de música/sonoridad), references/craft/murch-cut, references/craft/hamilton-action

La aprobación oficial de la etapa se basa en review/project-state.json, solo se puede hacer con build_stage_review.py --approve-stage (palabras textuales del usuario) o h3d approve --auto (etapas autorizadas por el usuario). Ruta de generación de video: por defecto Ref2VA (FreeVideo, recorte de una sola persona); cuando el usuario cambie a un paquete de personajes REMIX de consola, se decide con h3d decide video_backend remix, h3d bind cambia el enlace al paquete de personajes, h3d compile con el enlace remix genera tres columnas REMIX (ancla de estilo al principio, <Picture N>/<Video N> numerados por paquete), la auditoría se ramifica según el backend (el adaptador de envío aún no está conectado, el extremo de envío de FreeVideo rechazará el envío de segmentos remix; ver references/tooling.md §2.3.1c). La página de revisión de la etapa 5 ejecutará automáticamente refcheck/staging para los segmentos ref2va y los listará como recordatorios (para los segmentos remix, dentro de la auditoría); cuando se hace manualmente, ejecuta h3d refcheck (cada personaje/criatura/objeto/mención de multitud en el prompt debe tener un paquete; para remix bloquea, para ref2va solo avisa) y h3d staging (posición de izquierda a derecha, línea de visión, no mirar a la cámara; por defecto es advertencia, solo bloquea si staging_gate strict), ver references/tooling.md §2.3.1d.

Aprobación por segmento de la etapa 5: la aprobación de la etapa 5 registra la huella digital de cada segmento. Después de la aprobación, solo se modifican algunos segmentos → solo esos segmentos modificados (incluidos los añadidos/eliminados) deben ser revisados de nuevo; los segmentos no modificados mantienen la aprobación y se pueden enviar igualmente (h3d submit/h3d run saltará automáticamente o rechazará el envío de los segmentos pendientes de revisión); los segmentos modificados siempre deben ser revisados manualmente: build_stage_review.py --project-dir . --stage 5 --segments X,Y genera una página de revisión → después de que el usuario la apruebe, h3d approve --stage 5 --segments X,Y --user-note "<palabras textuales del usuario>", no uses --auto. Los segmentos que ya tenían video y han sido modificados aparecerán como stale (prompt_stale) en h3d deps --status. Si cambian las instantáneas antiguas o las partes compartidas (cáscara del archivo de segmentos, ack de segmentos no vinculados, etapas anteriores), se debe volver a revisar todo. Ver detalles en references/tooling.md §2.6. Los borradores de solo texto se pueden entregar según el alcance especificado, sin necesidad de avanzar a la generación de medios: usa h3d decide delivery_scope script-only|storyboard-only|prompts-only|full --quote "<palabras textuales del usuario>" para decidir el punto de finalización de la entrega (si no se decide, es el flujo completo); h3d next informará done al llegar al punto final; con no_image, la etapa 2 solo requiere una ficha de diseño de texto. Nota: no_image solo desactiva la etapa 2; la etapa 4 y posteriores aún requieren imágenes de composición; el punto final debe estar antes de la etapa 3 o decidirse por separado. La correspondencia entre los productos de las ocho etapas y las páginas de revisión HTML se encuentra en references/skill-guide.md "Flujo de ocho etapas y puntos de interrupción HTML", las plantillas detalladas están en references/pipeline.md. Las páginas de revisión HTML de cada etapa son ahora páginas de depuración (para enlazar instantáneas de revisión); lo que se entrega al usuario es la bandeja de entrada h3d inbox, cuyas especificaciones están en references/review-page-spec.md.

Segmentos de pelea/golpe/efecto especial: cargar también h3-combat-impact

Cuando el storyboard o los prompts involucren peleas, combates, golpes, técnicas especiales / movimientos definitivos, un golpe para matar, transformaciones, explosiones mágicas, efectos especiales, fotogramas de impacto, vibración de pantalla (o cualquier impacto de nivel L3 o superior), carga también h3-combat-impact (ayase0307/h3-combat-impact), úsalos juntos:

• Etapa 4: Según su flujo obligatorio, diseña las técnicas del personaje, la coreografía del combate (intercambio/consecuencias), las capas de efectos especiales y los movimientos de cámara, y lista la lista de puntos de impacto, con la ruta del fotograma de impacto (P0–P3) seleccionada para cada punto. El lint de director (director_lint.py, warning) recordará: dar un plano de establecimiento al cambiar de ubicación, el diálogo no debe cruzar el eje de 180 grados, añadir un plano de reacción después de una reversión / mala noticia, la coincidencia de la línea de visión debe explicar el objeto visto, las costuras entre segmentos deben usar cortes de acción o transiciones de ocultación (referencia al lenguaje cinematográfico de 24frames.art, reescrito).
• Etapa 5: El five_part_en de los segmentos de pelea se escribe según sus tarjetas de decisión—el movimiento definitivo por defecto se escribe como una sección "cadena de fotogramas de impacto" (plantilla F), no escribas near-freeze/hangs poised/like a meteor/for two frames ni otras palabras lentas de H3 y control de fotogramas; el plan de fotogramas de impacto (código de tiempo, punto de golpe, intensidad, ruta, relación de montaje) se escribe en las notas del storyboard / instrucciones de entrega de ese segmento (los segments actualmente no tienen un campo dedicado).
• Etapa 7: Los segmentos de pelea ya aprobados se someten a cambios de velocidad según el plan de fotogramas de impacto (h3d ramp, o impact_frame.py ramp de esa skill) o composición (impact_frame.py composite); la zona de diálogo permanece a velocidad original.
• Duración del plano: los segmentos de cadena de fotogramas de impacto, los planos cortos de golpe pueden ser más cortos que "cada plano ≥2 s" de h3-video-prompting, la referencia es h3-combat-impact.

Los escritos complementarios de este repositorio: references/storyboard/xuanhuan-combat-contract.md (ramas de combate, condiciones para que la acción tenga éxito, escenario, tres capas de impacto, terminología de velocidad de cámara, cadena de proceso del movimiento definitivo) y references/storyboard/vfx-design-and-review.md (tarjeta de diseño de efectos especiales, línea de defensa para proteger la cara, verificación de imágenes y retrabajo, escritura de correcciones parciales); ambos son destilados de habilidades externas, no probados en H3.

Esto es una referencia, no cambia las restricciones de esta skill: validate_storyboard.py, h3d compile --check, h3d catalog --check deben pasar igualmente.

Cuatro comprobaciones deterministas (parte de la entrega)

Cuanto de duración (17n+5, usar metadata.frames para enviar), clasificación de evidencia (etapa 6 debe ser VERIFIED), ledger de dependencias a nivel de segmento (h3d deps), catálogo de fallos (h3d catalog --check/h3d ack). duration_drift, PARTIAL, ya hay un trabajo en waiting significan "no se puede continuar ahora", el procedimiento está en references/tooling.md §4.

Supervisión (ledger de requisitos, ejecutar antes de la revisión y en paralelo con la revisión ciega)

h3d decide solo registra las decisiones formalizadas; las preferencias que el usuario haya mencionado de pasada pero no estén en las decisiones se olvidarán, y no hay ninguna comprobación que pregunte "¿se ha olvidado algo que el usuario dijo?". El supervisor añade esta capa: python scripts/build_requirements_ledger.py --root <proyecto> construye el ledger de requisitos (las palabras textuales de cada decisión en decisions.json + tarjetas pendientes de la bandeja de entrada + extractos manuales de --quotes), --stage N/--all/--inputs construye un paquete de verificación que "solo contiene el material, no la conclusión", y un subagente nuevo verifica punto por punto la cobertura de los resultados (plantillas y prohibiciones en references/supervision.md). Misma posición que la revisión ciega: no es una restricción del flujo, no cambia la máquina de estados de h3d; si no pasa, primero se soluciona y luego se envía a revisión. Al asumir un proyecto existente, el primer paso es usar --all para una verificación acumulativa (junto con references/audit-inherited-project.md).

Recursos (índice)

• references/tooling.md — Todos los comandos y comprobaciones de h3d (léelo antes de ejecutar cualquier comando); §2.5 Decisiones / conclusiones por segmento, §2.6 Bandeja de entrada y aprobación automática, §2.7 Runner/probe/doblaje/edición.
• references/skill-guide.md — Texto completo de SKILL.md original: Principios centrales 0–14, estructura del proyecto, decisiones prácticas de la etapa 6, capas de doblaje de la etapa 7, lista completa de scripts.
• references/pipeline.md — Flujo detallado de las ocho etapas, listas de preguntas, plantillas; decisión de las tres capas de sonido y estándar de sonoridad.
• references/review-page-spec.md — Especificaciones de la página de revisión: lo que se entrega al usuario es la bandeja de entrada de decisiones (orden de la página, campos obligatorios de la tarjeta, acciones prohibidas, vista de lectura de ocho etapas en seis bloques), las páginas de etapas antiguas son solo para depuración.
• references/blind-review.md — Revisión ciega (fresh-eyes): paquete de material que solo da el material, no la conclusión, y proceso (obligatorio para etapa 3/7; scripts/build_blind_review.py).
• references/supervision.md — Supervisión (ledger de requisitos): verificar punto por punto la cobertura de todo lo que el usuario ha dicho (obligatorio antes de enviar a revisión en cada etapa; scripts/build_requirements_ledger.py).
• references/document-standard.md — Formato estándar de documentos de etapa: tarjeta de estado + cuerpo + registro de revisiones, usar h3d doc para escribir, no modificar a mano; "Tú decides" entra automáticamente en la bandeja de entrada.
• references/audit-inherited-project.md — Asumir el proyecto de otra persona ("tú lo asumes", "el agente anterior lo hizo muy mal", "mira si tienes alguna sugerencia"): primero auditar y luego avanzar, umbral de huella digital de generación mecánica, tres tipos de fallos en la tubería de diálogo, auditoría REMIX, orden de reconstrucción y minas (re-bind, verbos de cámara oficiales, restauración de instantáneas sketch, composición de storyboard desde backend no soportado).
• references/remix-draft-loop.md — Ciclo de sorteo REMIX (etapa 6): elección de pasos pika480 4/6, cinco síntomas de que el paquete de referencia anula el prompt, tres tareas de revisión, tres falsas alarmas comunes (baja saturación/línea de borde/salto de tono), corrección por lotes + re-firma, orden de recogida y finalización.
• docs/skill-roadmap.html — Mapa de ruta dinámico para humanos (acciones de las ocho etapas, productos, quién decide, señales de parada); si el flujo cambia, hay que sincronizar su roadmap-data incrustado (tests/test_skill_roadmap.py reconcilia).
• references/adapt/ (Adaptación), references/storyboard/ (Storyboard de dirección), references/consistency.md (Consistencia de activos), references/styles.md (Ancla de bloqueo de estilo), references/freevideo.md, references/model-profiles.md, references/minimax-h3.md y references/h3/ (Referencia detallada de H3, sincronizada desde el upstream h3-video-prompting), references/prompt-playbook.md, references/h3/camera-moves-handbook.md (Manual de movimientos de cámara del upstream: 17 estilos + 6 estilos de Loop Forge + bullet time Xianxia, anotaciones de pruebas en Colab), references/craft/ (Lentes creativos, solo sugerencias, no cambian restricciones), references/edit/ (Manual de edición de AI漫劇 de etapa 7, investigación de Concat/borradores de Jianying).
• Peleas/golpes/efectos especiales/fotogramas de impacto: habilidad externa h3-combat-impact (ayase0307/h3-combat-impact), ver sección "Segmentos de pelea/golpe/efecto especial" arriba.
• references/revision-and-retry.md — Las correcciones deben incluir una lista de cambios + conclusión de las afectaciones; máximo 2 reintentos del mismo plano, luego diagnóstico de capa; principio de comparación de aceptación.
• references/storyboard/continuity-ledger.md — Cuenta de personajes, lista de verificación de storyboard, tres tipos de orientación, tabla de posiciones, plano-contraplano, estado final de la costura, uso de imágenes de referencia.
• references/storyboard/spatial-consistency.md — Consistencia espacial: dibujar el plano madre de la escena según el plano de planta, capa de asignación de paredes (opcional scripts/storyboard/wall_map.py), tabla de composición basada en el plano madre, los planos que solo muestran criaturas deben vincularse a una referencia dentro de la tienda (experimento de Lao Yi 2026-10, evidencia direccional); §6 División del trabajo en modelo blanco y tres niveles de precisión (Foyege, no probado en H3).
• Formatos: references/schemas/ (decisions, verdicts). Las reglas estrictas para el agente se encuentran además en AGENTS.md.