xxjrq/github-project-intro

Orquestación de Video de Repositorio Único de GitHub

Este Skill es el punto de entrada único para la orquestación de videos de un solo repositorio de GitHub. Cada repositorio posee de forma independiente sus hechos, planificación, guion, grabación de pantalla, timeline, audio, datos de portada y paquete de publicación; solo se reutilizan componentes públicos. Los trabajos anteriores y ejemplos solo sirven como referencia, no como hechos, esquemas o estándares visuales estrictos.

1. Orden de Lectura y Responsabilidades

Primero, leer los documentos especificados en AGENTS.md del repositorio, luego leer y ejecutar por etapas de forma completa:

1. work-library-api-registration: Registro en la estación de trabajo o copia de campos de tarea.
2. ~/.codex/skills/selfmedia-github-research/SKILL.md: Fuentes oficiales y declaraciones de alto riesgo.
3. ~/.codex/skills/douyin-tech-content-planner/SKILL.md: Audiencia, beneficio único, gancho y orden de evidencia.
4. ~/.codex/skills/record-web-demo/SKILL.md: Lista de evidencia, Plan de Acción y grabación de pantalla real.
5. ~/.codex/skills/selfmedia-script-storyboard/SKILL.md: Determinar primero el guion final para locución y el storyboard legible, sin estimar la duración final del audio.
6. Reglas de audio de este Skill: Generar y medir el audio en serie, obtener primero la duración real y los tiempos de los subtítulos.
7. ~/.codex/skills/selfmedia-script-storyboard/SKILL.md: Usar los tiempos de las acciones de la grabación de pantalla y la duración del audio medida para completar el Timeline v1.2.
8. ~/.codex/skills/selfmedia-cover-design/SKILL.md: Portadas en dos tamaños: 3:4 y 4:3.
9. ~/.codex/skills/selfmedia-remotion-render/SKILL.md: Renderizado con plantillas públicas.
10. Puertas de seguridad del flujo de este Skill: Verificar el orden de las etapas, los productos requeridos y el estado de la estación de trabajo; tras pasar la verificación del contrato de máquina de cinco archivos, generar directamente el paquete de publicación formal de forma atómica.

El Agente de contenido solo puede modificar sus propias unidades de contenido. apps/studio/src/root.tsx, las plantillas públicas, las portadas públicas, los esquemas, las comprobaciones previas (Preflight) y los validadores de publicación solo pueden ser modificados por el Agente de integración principal. Varios Agentes no pueden modificar archivos compartidos simultáneamente.

2. Registro y Unidades de Contenido Formal

1. Después de que el usuario envíe un tema formal, primero se debe completar el registro en la estación de trabajo: para contenido nuevo, llamar a POST /api/production-requests; para un catálogo existente, llamar a POST /api/works y luego a POST /api/production-requests/adopt. Ambos métodos deben devolver un work_id y un ID de solicitud de producción válidos; sin estos dos IDs, no se permite investigar, grabar pantalla ni renderizar.
2. Una vez registrado exitosamente, se debe crear o tomar el control de una unidad de contenido independiente en projects/github/videos/<content-id>/, y sincronizar projects/index.yaml y projects/task-index.yaml. content.yaml, task.yaml y 制作单.md deben tener el mismo work_id; la primera etapa de la interfaz de flujo de la estación de trabajo mostrará fijamente "Registro en Estación de Trabajo".
3. La estación de trabajo solo guarda los requisitos de la tarea; al copiar una plantilla, se deben limpiar la URL del repositorio anterior, Stars, versión, licencia, guion, timeline, grabación de pantalla, fuentes, datos de portada y paquete de publicación.
4. renderer.composition_id está fijo como GitHubProjectDemoTemplate. El ID de la plantilla es devuelto por la estación de trabajo/API, no se debe codificar manualmente el ID de una plantilla de un trabajo histórico.
5. Cuando el usuario envía una tarea formal, se permite que la estación de trabajo ejecute de forma continua las ocho etapas hasta release_ready. Solo cuando el usuario solicite explícitamente una prueba y especifique un punto de parada, se debe configurar stopAfterStageId; planning solo entrega la hoja de producción, render solo deja el renderizado temporal, sin generar un catálogo formal. Cuando la estación de trabajo ejecuta de forma continua, reutiliza la misma sesión de Codex, manteniendo los controles de etapa pero sin restablecer el contexto para cada etapa.
6. Las unidades de contenido formal deben existir:
   • project.json
   • content.yaml
   • task.yaml
   • research/facts.json
   • 制作单.md
7. Cuando la salida de la investigación de Pipeline esté en un área de trabajo temporal, se deben escribir las fuentes oficiales, los campos dinámicos utilizados actualmente y las conclusiones de las declaraciones de alto riesgo de vuelta a la unidad de contenido formal; no se debe usar el directorio temporal en lugar del proyecto formal.

Los videos de proyectos individuales de GitHub solo mantienen un documento maestro manual 制作单.md, utilizando cinco bloques de marcado fijos: decision, voiceover, storyboard, assets, release. Las nuevas tareas no deben crear research/decision.md, research/content-plan.md, script/voiceover.md, script/script.json, 创作提示词.md o qa/; los hechos, timeline, plan de acción, lista de grabación de pantalla, audio, SRT y accesorios de renderizado continúan utilizando archivos de máquina independientes.

3. Puertas de Seguridad de Fuentes, Riesgos y Planificación

1. Usar la página del repositorio de GitHub para confirmar la identidad del proyecto y guardar la URL oficial. Solo acceder a README, documentación oficial o página de lanzamiento para las declaraciones de alto riesgo que realmente aparecen en este video, sin realizar una verificación enciclopédica completa de todas las funciones.
2. Las declaraciones de alto riesgo incluyen: números dinámicos y clasificaciones; precios, costos, porcentajes de ahorro y comparaciones de rendimiento; conclusiones de seguridad, privacidad y legales; licencia, versión, estado de mantenimiento e identidad oficial; promesas absolutas; y resultados específicos sin respaldo visual real o fuente oficial.
3. Los campos como Stars, versión, licencia, etc., solo se verifican si se utilizan visualmente o en el texto; si se usan, se actualizan justo antes del renderizado formal. facts.json guarda los valores exactos, fuentes y conclusiones de riesgo; si no hay declaraciones de alto riesgo adicionales, solo se registra una lista vacía.
4. Los puntos débiles comunes, preguntas retóricas, emociones, analogías, humor ligero y resúmenes coloquiales de demostraciones reales no requieren verificación frase por frase. Los ganchos dados o aprobados por el usuario están bloqueados por defecto; solo se pueden vetar si hay un error fáctico claro, un riesgo de cumplimiento legal o una desinformación grave; para otros riesgos, solo se realizan modificaciones mínimas a nivel de palabra.
5. Un video solo promete un beneficio central. Primero determinar la audiencia, el gancho en lenguaje natural, el cumplimiento de los primeros 12 segundos y una sola llamada a la acción (CTA), luego escribir el guion. El archivo de hechos no debe inyectar jerga técnica del README en la locución; solo las barreras duras que realmente afectan si se puede usar el producto deben explicarse naturalmente con la función correspondiente. Está prohibido crear páginas de advertencia de riesgo, páginas pendientes de verificación, muros de descargo de responsabilidad o páginas de límites de aplicabilidad por separado.
6. Los productos finales públicos no deben mostrar URLs completas, códigos QR, botones de descarga, instrucciones para acciones fuera del sitio o montos monetarios específicos de herramientas comunes.
7. Si no se puede confirmar la identidad del proyecto, o si el texto público aún contiene declaraciones de alto riesgo sin resolver, se debe detener; si no hay declaraciones de alto riesgo, no se debe bloquear la grabación de pantalla ni el renderizado.

4. Evidencia Real y Tiempos de Material

Primero se debe ejecutar record-web-demo:

1. Usar un viewport lógico de 800×600 para capturar README, imágenes/GIF, capturas de pantalla candidatas y selectores.
2. Primero, planificar la toma de identidad del repositorio de GitHub: el nombre real del repositorio en un cuadro de esquinas redondeadas finas, las Stars o la versión en un círculo elíptico fino; esta toma debe ir antes que cualquier README o Demo externo.
3. Luego, seleccionar de 1 a 3 evidencias del README o Demo oficial que puedan probar el beneficio central; las listas de archivos, registros de instalación, logotipos y licencias no pueden actuar por defecto como evidencia de resultado.
4. La identidad de GitHub y los Demos externos usan Planes de Acción y archivos de grabación de pantalla independientes; cada uno debe pasar su propia verificación antes de grabar. Si se necesita una fuente de codificación de 1600×1200, usar el posprocesamiento --pixel-scale 2, sin expandir el diseño de la página web.
5. La lista de grabación de pantalla debe registrar startMs, endMs, página, operación, objeto de evidencia y resultado de la ejecución para cada acción real.
6. El script de grabación de pantalla debe completarse con éxito; las acciones en la lista deben tener startMs, endMs reales y un estado de finalización; las acciones fallidas no deben entrar en el Timeline.
7. trimStartMs y trimEndMs del Timeline solo pueden provenir de la lista de grabación de pantalla; está prohibido usar los tiempos de la escena final como puntos de entrada del material.

5. Guion y Timeline

La duración se determina por la información, la locución medida y el tiempo de lectura visual, no se fija en 25 segundos. La referencia narrativa por defecto:

0～3 seg    Página del repositorio de GitHub, nombre del proyecto, Stars y valor central
3～6 seg    Primera evidencia real del resultado del README o Demo oficial
Primeros 12 seg    Aparece la evidencia real más fuerte
Mitad       Continuar demostrando 1～2 evidencias
Parte final    Escenarios de aplicación, umbrales o limitaciones
Final       Un resumen y una CTA natural

Primero, escribir la locución final y el storyboard legible en los bloques voiceover y storyboard de 制作单.md. Después de completar la fase de audio, usar la duración del audio medida, los tiempos de los subtítulos y la lista de grabación de pantalla para generar el único archivo de director de máquina timeline.json. Timeline:

• Usar packages/timeline-schema/timeline.schema.json, versión 1.2;
• El role de la escena solo permite hook, proof, process, result, identity, cta;
• direction.proofByMs <= 12000;
• direction.demoLayoutPreset está fijo como fixed-demo-v1; el marco de demostración fijo es x=86, y=420, width=908, height=681;
• Máximo un visualPeak: true;
• focus usa coordenadas normalizadas derivadas de fotogramas de origen verificados;
• Las escenas de demostración no deben configurar identityTop, evidenceTop, captionTop; el énfasis solo está permitido dentro del marco de demostración;
• Si la grabación de pantalla ya tiene anotaciones, no se deben repetir en Remotion;
• Las escenas, los subtítulos y el audio cubren el tiempo completo, sin superposiciones, desbordamientos ni espacios en blanco no válidos.

El título, la portada, la primera pantalla, la locución, los subtítulos y el texto de publicación deben contener GitHub y el nombre del proyecto, y mantener la coherencia de la identidad del proyecto, los números y otros hechos de alto riesgo. Los títulos de las tres plataformas no deben exceder los 30 caracteres Unicode cada uno. Las líneas de Temas/Etiquetas de las tres plataformas deben contener #github优质项目 #github开源, con un total de 5～7 etiquetas sin repetición, y complementar con la etiqueta del proyecto y al menos dos etiquetas de valor/escenario que coincidan con el contenido de este video; se puede agregar un máximo de 2 etiquetas de tendencia en tiempo real, pero solo si hay evidencia de la plataforma en esta ocasión.

6. Arquitectura Pública de Remotion

Los nuevos repositorios solo usan Composition públicas:

• GitHubProjectDemoTemplate
• GitHubProjectCoverPortrait
• GitHubProjectCoverLandscape

GitHubProjectCoverFeed es solo para compatibilidad histórica, no entra en la lista de Composition, tareas de renderizado o paquetes de publicación de nuevos proyectos.

El proyecto pasa el Timeline, nombre del proyecto, Stars, gancho, resultado, preajustes y material a través de una entrada estructurada. Prohibido:

• Crear un sistema visual TSX dedicado al repositorio;
• Registrar Composition de video o portada dedicadas al repositorio en Root;
• Codificar OpenMontage o cualquier proyecto histórico como hechos predeterminados de la plantilla pública;
• Modificar hechos, adivinar tiempos de material o reordenar escenas durante la fase de renderizado.

GitHubProjectDemoTemplate es un ID de plantilla, no un ID de proyecto. Studio usa fijo http://localhost:3000/, seleccionando los datos del proyecto a través de propiedades de entrada. Los cambios en TSX, CSS, JSON y material normales dependen de la recarga en caliente; solo se permite reiniciar y registrar la razón si hay cambios en dependencias, configuración, punto de entrada, el servicio no responde o hay errores de compilación irrecuperables. El renderizado formal por CLI no depende del puerto de Studio.

Antes del renderizado formal, ejecutar una Preflight unificada: archivos formales completos, campos dinámicos y declaraciones de alto riesgo utilizados en contenido público válidos, Plan de Acción y grabación de pantalla aprobados, tiempos de material legales, esquema de Timeline válido, longitud de título válida, modo de audio coherente, datos de portada completos. Si alguna falla, detener inmediatamente.

7. Modo de Audio

Solo obedece al voice.mode coherente de la estación de trabajo, content.yaml y task.yaml:

• generate-and-mix: Generar Edge-TTS en serie y mezclarlo en el video de publicación; el audio final debe ser AAC 48kHz estéreo, con un volumen promedio de aproximadamente -20～-28dB.
• generate-reference: Generar audio de referencia pero no mezclarlo; el video de publicación debe estar realmente sin pista de audio.
• self-recorded: No generar TTS; el video de publicación debe estar realmente sin pista de audio, el SRT se conserva para que el usuario lo ajuste después de grabar su propia voz.

Si el modo falta o los tres lugares son inconsistentes, la Preflight falla. La fase de audio debe ir antes de la fase de Timeline; después de cambiar el texto, regenerar y medir el audio, no reutilizar duraciones antiguas. El Timeline y el SRT deben usar la duración medida de esta vez; si el audio o el SRT exceden la duración del Timeline, no se permite la entrada al renderizado.

8. Portada y Renderizado Formal

La portada debe ejecutar selfmedia-cover-design; no se puede improvisar una después de que el video esté terminado. El video genera fijamente dos portadas con diseños independientes: 3:4 y 4:3; no recortar fotogramas de video a la fuerza, no generar portadas de 9:16 para el feed de video.

El orden de información fijo de la serie GitHub: identidad de la columna GitHub, nombre del proyecto, Stars doradas debajo del nombre del proyecto, un resultado específico de 6 a 12 caracteres. Los datos de la portada deben provenir de este proyecto y generar dos archivos en 3:4 y 4:3 respectivamente.

Después de que todos los proyectos pasen la Preflight, agrupar (Bundle) solo una vez, luego renderizar videos y portadas en lote según la planificación aprobada. No se permite obtener una vista previa repetida, extraer fotogramas escena por escena y volver a renderizar para la misma versión, ni crear un directorio de imágenes de QA.

9. Activos Multimedia, Portada y Publicación Multiplataforma

9.1 Primero, Distinguir Cuatro Tipos de Productos de Imagen

Un proyecto no puede registrar solo un campo "imagen". Se deben gestionar por separado:

Producto	Uso	Método de generación preferido	¿Usar IA para generar imágenes?
Imagen dentro del artículo	Explicar arquitectura, flujo, pasos de instalación, funciones reales	Capturas de pantalla oficiales, fotogramas de grabación de pantalla, fotogramas fijos de Remotion o SVG; si es necesario, usar IA para fondos sin hechos	Por defecto no; las imágenes fácticas no pueden ser inventadas por IA
Portada del artículo	Miniatura de lista de artículos en CSDN, Zhihu, WeChat, etc.	Remotion/HTML/CSS superposición de diseño	Se puede usar IA para generar fondos sin texto, pero el título, nombre del proyecto, Stars y números deben superponerse después
Portada del video	Portada de entrada de video o contenido gráfico en Douyin/Bilibili	selfmedia-cover-design + Composition pública de Remotion, generar de forma independiente 3:4 y 4:3	Se puede usar IA para generar el sujeto visual, pero no recortar fotogramas de video a la fuerza para reemplazar la portada
Icono del Skill	Página de exploración de SkillHub, metadatos del paquete Skill	Reutilizar el icono del proyecto o usar selfmedia-imagegen para generar un icono sin texto, luego recortar/exportar a 512px	Se puede usar; no poner texto pequeño o inglés ilegible dentro del icono

Conclusión: La portada del artículo y la portada del video no son capturar el primer fotograma del video; las imágenes dentro del artículo tampoco necesitan generarse todas con IA. Las capturas de pantalla reales son responsables de la evidencia, Remotion es responsable del diseño estable, y la IA solo es responsable de fondos visuales o iconos sin riesgo de hechos.

9.2 Orden de Generación de Activos de Imagen

Cada proyecto prepara los activos en el siguiente orden, prohibido hacer primero la portada y luego complementar los hechos:

Fuentes oficiales y verificación de hechos
  → Capturas de pantalla reales / Grabación de pantalla / Evidencia del README
  → Estructura del artículo y storyboard del video
  → Determinar qué imágenes se necesitan
  → Generar u organizar activos de imagen
  → Remotion superpone uniformemente el nombre del proyecto, título, números y diseño de marca
  → Generar portada de artículo, portada de video 3:4, portada de video 4:3
  → Verificación de tamaño / zona segura / coherencia de hechos

Selección de fuentes de imagen:

1. Imágenes de producto real: GitHub, Demo oficial, documentación oficial, página de ejecución real, captura de pantalla directa o fotograma de la grabación de pantalla.
2. Diagramas explicativos: Priorizar la generación con Remotion, SVG, HTML/CSS, adecuado para diagramas de arquitectura, diagramas de flujo, tablas comparativas y pasos de instalación.
3. Fondo ambiental: Usar selfmedia-imagegen para generar, no colocar logotipos, Stars, números de versión, precios y promesas de funciones no verificados.
4. Título de portada de artículo: Debe superponerse en Remotion/HTML/CSS, no depender de la IA para generar texto chino dentro de los píxeles.

9.3 Reglas de Campos y Diseño de Portada

Los datos de la portada de cada proyecto deben guardarse por separado, incluyendo al menos:

cover:
  eyebrow: "GitHub 开源项目"
  project_name: "<Nombre del proyecto>"
  hook: "<Resultado específico de 6 a 12 caracteres>"
  star_text: "<Stars reales, con fecha de verificación>"
  focal_asset: "<Ruta de la captura de pantalla real o imagen de fondo sin riesgo de hechos>"
  palette: "<Paleta de colores seleccionada para este proyecto>"
  source_checked_at: "<AAAA-MM-DD>"
  outputs:
    portrait: "02-PortadaVertical-3por4.png"
    landscape: "03-PortadaHorizontal-4por3.png"

Orden de información fijo de la serie GitHub: identidad de la columna → nombre del proyecto → Stars doradas → un resultado específico. El título principal de la portada solo expresa un beneficio, no se debe meter "100 proyectos", una lista completa de funciones o comandos de instalación en la portada.

• 3:4: 1080×1440, borde superior aproximadamente 115px, borde inferior aproximadamente 216px, izquierdo y derecho 86px cada uno.
• 4:3: Reorganización independiente, no estirar ni recortar a la fuerza la portada 3:4.
• Pantalla de video 9:16: 1080×1920, el contenido central respeta la zona segura del proyecto de 170px superior, 288px inferior, 86px izquierdo y derecho; esta no es una dimensión de portada de video.
• Título, nombre del proyecto, Stars, versión y otros números precisos utilizan diseño determinista; no generar texto preciso dentro de las imágenes de IA.

9.4 División del Trabajo entre Imágenes de Artículo y Remotion

Antes de publicar el artículo, elegir según el tipo de artículo:

Contenido del artículo	Activos recomendados	Explicación
Introducción del proyecto	1 portada del proyecto + 1 captura de pantalla real de GitHub + 1 imagen de capacidad central	La imagen de capacidad central usa SVG/Remotion, no uses IA para fingir una captura de pantalla del producto
Tutorial de instalación	Capturas de pantalla de comandos, capturas de pantalla de terminal, diagrama de flujo	Los comandos y las rutas deben provenir del proyecto real
Desglose de arquitectura	Diagrama de arquitectura SVG/Remotion + captura de pantalla del README oficial	Visualización de la estructura, la fuente de los hechos sigue siendo el repositorio oficial
Comparación y revisión	Tabla de Remotion/HTML + enlaces oficiales de cada proyecto	Solo comparar campos verificados
Artículo de opinión pura	Portada + algunas imágenes de ambiente	Las imágenes de ambiente pueden ser generadas por IA, pero no pueden usarse para probar la función del producto

9.5 Capas de la Plataforma de Publicación

La publicación no consiste en enviar el mismo texto original a todas las plataformas; se divide por capas:

Capa	Plataforma	Tarea principal	Contenido a publicar
Fuente de código principal	GitHub	Hechos autorizados, versión, Issues, Stars	Código fuente, README, CHANGELOG, Licencia, Release
Espejo de código nacional	Gitee	Acceso nacional, punto de entrada de espejo, descarga de respaldo	Código fuente y README sincronizados con GitHub, especificando claramente a GitHub como fuente principal
Distribución de Skills	SkillHub	Búsqueda, instalación y gestión de versiones de Skills	Paquete de Skill válido, manifest, descripción en chino, icono, cambios de versión
Búsqueda de artículos	CSDN, Zhihu, Juejin, Toutiao, WeChat	Búsqueda, explicación y derivación de artículos largos	Artículo adaptado a la plataforma, portada, capturas de pantalla reales, enlace oficial
Distribución de video/gráficos	Bilibili, Douyin	Descubrimiento, demostración, seguimiento y derivación	Video, columna/gráfico, portada de entrada 3:4 o según lo requiera la plataforma
Difusión opcional	Shaoshupai, SegmentFault, OSChina, Blog Park	Lectores técnicos y comunidad de desarrolladores	Publicar solo cuando el contenido sea realmente adecuado, no repetir publicaciones para aumentar la cantidad

La combinación de publicación mínima recomendada para 100 proyectos es:

Fuente principal GitHub + Espejo Gitee
  → Si el proyecto tiene Skill, luego publicar en SkillHub
  → CSDN / Zhihu / WeChat elige la versión de artículo adecuada para la plataforma
  → Bilibili / Douyin publica el video de demostración o contenido gráfico

No todos los proyectos de GitHub se pueden publicar en SkillHub. Solo los proyectos que realmente tienen una estructura de paquete de Skill ejecutable, SKILL.md/manifest.yaml, palabras de activación e instrucciones de autoevaluación deben publicarse en la tienda; los repositorios de herramientas comunes solo publican contenido de GitHub, Gitee y artículos/videos.

9.6 Adaptación de Plataforma antes de la Publicación

Cada plataforma genera un campo release independiente, no se permite copiar un mismo Markdown a todas las plataformas:

release:
  github:
    repo_url: ""
    release_url: ""
    status: "pending"
  gitee:
    mirror_url: ""
    sync_checked_at: ""
    status: "pending"
  skillhub:
    skill_slug: ""
    package_path: ""
    icon_path: ""
    status: "not_applicable"
  articles:
    csdn: { title: "", url: "", status: "pending" }
    zhihu: { title: "", url: "", status: "not_applicable" }
    wechat: { title: "", url: "", status: "not_applicable" }
  media:
    bilibili: { url: "", status: "pending" }
    douyin: { url: "", status: "pending" }

Después de completar cada plataforma, se debe volver a leer el título, los párrafos clave del texto/README, el enlace del proyecto, las imágenes y el estado público; el registro de publicación registra la URL real, la hora, la versión, el entorno del navegador y la conclusión de aceptación. Publicar, enviar, eliminar y sobrescribir borradores antiguos siguen siendo acciones de confirmación manual.

10. Verificación de Liberación (Release Check)

Después de que el Agente complete las siguientes puertas de seguridad del flujo de máquina, escriba los cinco archivos en renders/release-package/. Después de que la verificación de la estación de trabajo pase, cambie el nombre atómicamente a 发布成品/ (Producto Terminado) y entre directamente en release_ready:

• La solicitud de producción de la estación de trabajo está asociada a un work_id válido, y el directorio del registro de la biblioteca coincide exactamente con source_dir; de lo contrario, detenerse, sin entrar en la verificación de fuentes y riesgos, grabación de pantalla o fase de renderizado;
• Pipeline validate --require-assets pasa;
• El esquema del Timeline, la duración del material, la puerta de seguridad de la evidencia de los primeros 12 segundos pasan;
• El comando de renderizado tiene éxito, la salida de video es 1080×1920, 30fps, H.264;
• La pista de audio cumple con voice.mode, el TTS y el SRT no exceden la duración del video al final; el volumen promedio final de generate-and-mix debe estar entre -28 y -20dB;
• Las dos portadas tienen el tamaño y el nombre correctos;
• Las tres plataformas tienen títulos y descripciones sustancialmente diferentes, los títulos no superan los 30 caracteres Unicode, las descripciones conservan párrafos reales;
• Las etiquetas de las tres plataformas contienen #github优质项目 #github开源, cada línea tiene 5～7 etiquetas sin repetición, y las etiquetas del proyecto y las etiquetas de valor/escenario coinciden con el contenido actual;
• projects/index.yaml, projects/task-index.yaml, task.yaml, content.yaml tienen estados coherentes.

No se permite reproducción incompleta, extracción de fotogramas, visualización imagen por imagen, OCR, tabla de contactos o gráfico de estrés 20:9, ni generar imágenes de QA o informes subjetivos. La imagen final la revisa el usuario.

Ya no se establece la etapa de confirmación manual rendered → visual_reviewed, ni se copian paquetes candidatos duplicados. Si falla algún contrato de máquina, no se debe generar 发布成品/ (Producto Terminado) ni informar release_ready. El paquete de publicación formal debe y solo puede tener cinco archivos: texto de publicación, video, portada 3:4, portada 4:3, SRT. El SRT se nombra fijamente 04-字幕.srt; la imagen final la revisa el usuario en el directorio formal.

No subir automáticamente, no operar cuentas de plataforma, no recopilar datos posteriores a la publicación.