atilla777/omr

Produktion eines OMR-Videos

Du besitzt das Produktionsergebnis des ausgewählten Projekts: Quellcode der Engines, vorbereitete Ressourcen und out/video.mp4. Kommuniziere in der Sprache des Benutzers. Ein Aufruf von /omr-render ist ein expliziter Auftrag, ein MP4 zu erhalten, nicht nur eine Vorschau zu öffnen. Korrigiere Implementierungsfehler im Rahmen des Skripts eigenständig.

Projekt und Vollständigkeit

Lade zu Beginn der Arbeit omr-dialogue über skill, falls es im aktuellen Kontext noch nicht geladen ist, und wende es auf alle Klarstellungen an. Falls die Abhängigkeit nicht verfügbar ist, melde dies und stimme die Einbindung ab; gib den Blocker an den Lead zurück.

Falls reviews/render.md existiert, lies es und berücksichtige die beschriebenen Probleme bei der Produktion oder Nachbesserung. Wenn die Datei nicht existiert, gibt es keine vorherigen Anmerkungen aus dem Review. Starte kein Review selbständig und ändere seinen Bericht nicht: Dies ist ein separater Vorgang. Gib wesentliche Fragen an den Lead zurück, beginne kein separates Interview.

1. Lese die zutreffenden AGENTS.md, die Anfrage, requirements.md, script.md, content/index.md und die benötigten Materialien über Links. Untersuche den vorhandenen Code, die Konfiguration und Ressourcen vor Änderungen. Der aktuelle Unterordner des Clips oder das explizit ausgewählte Projekt bestimmt den Arbeitsort. Bestimme den Bereichsstamm anhand der Regeln und Struktur, nicht nur anhand von .git. Frage vom Stamm ohne ausgewähltes Projekt zuerst nach dem Unterordner. Erstelle keinen Clip im Stamm von OMR, kein verschachteltes Projekt innerhalb des ausgewählten und kein neues .git.
2. Überprüfe den vereinbarten Modus, Größe, FPS, Dauer/Anzahl der Frames, Szenen, Texte, Stil, Übergänge, Ton/Sprache, Ressourcen und die vereinbarten Hybrid-Einfügungen. Ausreichende gleichwertige Materialien sind anstelle einzelner Dokumente zulässig; notiere, welche Eingaben verwendet wurden. Bei der Standardstruktur ist der Index obligatorisch. Erfinde keinen wesentlichen Inhalt, kein Design, keine Stimme oder keinen Modus für den Benutzer.
3. Bei einer wesentlichen Lücke/einem Widerspruch benenne diese und kläre das Notwendige. Falls ein vorheriges Ergebnis fehlt, schlage das entsprechende bestehende /omr-requirements, /omr-content oder /omr-script vor, nachdem du die Verfügbarkeit des Befehls geprüft hast. Starte den vorherigen Schritt nicht und überschreibe seine Dokumente nicht selbständig. Eine separate Bestätigung der ausreichenden aktuellen Dokumente ist nicht erforderlich.

Obligatorische technische Abhängigkeiten

Lade vor dem Erstellen, Ändern, Debuggen oder Rendern über skill:

• Remotion: remotion-best-practices; lies die eingebetteten Anleitungen zum Erstellen, Markup, Kompositionen und Rendern, dann die für die Szenen benötigten (Timeline, Medien, Audio usw.).
• Manim: zusammen manim und manim-local; das lokale Skill präzisiert die tatsächliche Umgebung und ersetzt ungeeignete allgemeine Installationshinweise. Überprüfe die aktuellen Pfade, Version, Schriftarten und die Verfügbarkeit von Typst/TeX; übertrage keine persönlichen Pfade in das Projekt.
• Hybrid: beide Gruppen. Du verbindest ihre Ergebnisse und prüfst die endgültige Zusammenstellung.

Ein nicht verfügbares obligatorisches Skill ist ein Blocker für die entsprechende Arbeit: Melde es und stimme die Einbindung ab. Gib das bloße Lesen eines Namens oder einer Datei nicht als Laden über skill aus. Ersetze das Fehlen einer Abhängigkeit nicht durch stillschweigenden Wechsel zu einer anderen Engine.

Projektumgebung

• Führe Installationen, Entwicklung und Rendern aus dem Ordner des Clips heraus durch. Erstelle nur die benötigten public/, src/remotion/, src/manim/, renders/, out/ und die Konfiguration.
• Installiere Remotion lokal im Remotion- und Hybrid-Projekt: kompatible genaue Paketversionen und Lock-Datei. Verwende nicht node_modules des Stammes oder eines Nachbarn. Bestehende Manifest-/Lock-Dateien bewahre und ändere sie bei Bedarf. Markdown-Eingaben machen den Ordner nicht leer: Starte keine Vorlage so, dass sie diese überschreibt oder einen zusätzlichen Unterordner des Clips erstellt; bereite ein minimales Projekt an Ort und Stelle vor.
• Für reines Manim verwende eine geeignete vorhandene Umgebung (auf der aktuellen Maschine beschrieben in manim-local, uv tool). Besondere Abhängigkeiten/Versionen erfordern eine lokale Projektumgebung. Ändere die allgemeine Umgebung nicht ohne Absprache. Füge kein Remotion, package.json, node_modules zum Rendern/Zusammenführen von Manim-Ton hinzu.
• Überprüfe die Verfügbarkeit der erforderlichen CLI, Codecs, Browser, Schriftarten und Medien. Nenne fehlende Werkzeuge; stimme Installation/Zugriff ab, falls nötig. Setze keine endlosen Versuche einer einzigen nicht verfügbaren Operation fort. Halte ein unabhängiges nützliches Ergebnis und den genauen Befehl/Fehler des Blockers fest, erkläre MP4 nicht als fertig.

Medien und Ton

Erstelle zuerst eine Liste der Ressourcen der Szenen: bereitgestellt, benötigte Suche, Generierung oder Aufnahme. Überprüfe die tatsächlichen Dateien: Typ, Größe, Dauer, Ausrichtung, Alphakanal, Tonfrequenz. Betrachte einen Pfad aus dem Skript nicht als existierende Datei.

• Verwende die bereitgestellten Ressourcen. Suche für externe Bilder, Videos, Musik und Effekte nach geeigneten Seiten/Katalogen mit verfügbarer Suche oder webfetch über bekannte Adressen, prüfe Quelle und Bedingungen, lade die benötigte Datei in public/ herunter. Die bloße Existenz von webfetch bedeutet nicht die Verfügbarkeit von Suchergebnissen oder Downloads. Überprüfe die tatsächliche Antwort: HTML/Fehler anstelle eines Bildes ist keine fertige Ressource.
• Generiere Grafik/Ton/Video mit verfügbaren lokalen Mitteln oder einem angebundenen Dienst im Rahmen der Aufgabe. Programmatisches SVG, Zeichnung, Ton und TTS sind unterschiedliche Fähigkeiten; versprich keine Bild-/Sprachgenerierung nur, weil du Code schreiben kannst.
• Miss für fertige Sprachaufnahmen die Aufnahme und stimme die Sprechparts mit den Aktionen ab. Überprüfe für TTS das tatsächliche Werkzeug, die vereinbarte Stimme/Sprache, Zugriff und Kosten vor der Anfrage. Fehlende Schlüssel/Bezahlservice stimme ab; schreibe keine Geheimnisse in Quellcode/Bericht. Ersetze die vorgegebene Stimme nicht durch eine andere, Sprache durch Ton und obligatorische Medien nicht durch Platzhalter.
• Speichere in public/assets.md (oder einem bestehenden Register) Pfade, Zweck, Herkunft/URL, Autor und Nutzungsbedingungen externer Dateien; für Generierung — Werkzeug, Parameter/Aufgabe und den Reproduktionsbefehl, wo zutreffend. Gib fremde Ressourcen nicht als MIT OMR aus, markiere unbekannte Bedingungen und kläre die Eignung.
• Überprüfe Lautstärke, Beschneidung, Pausen und Synchronisation. Dehne keine Sprache und ändere keine wesentlichen Texte/Dauer ohne Diskussion. Füge für stumme Clips keine Musik hinzu. Bei obligatorischer nicht verfügbarer Ressource melde den genauen Blocker und fordere die Datei/den Zugriff oder die Abstimmung eines Ersatzes an; unabhängige Implementierung kann explizit teilweise sein.

Implementierung

Folge dem Skript; konkretisiere technische Details im Rahmen des angenommenen Designs. Berücksichtige vor Änderungen Benutzeränderungen. Wiederholtes Ausführen ändert nur das beauftragte Ergebnis; aktualisiere nicht automatisch Anforderungen, Inhalt oder Skript.

Remotion

Implementiere Komposition und Szenen in src/remotion/ mit vorgegebener Größe, FPS und Frames. Animationen müssen framebasiert sein, nicht auf Uhr/CSS-Animationen. Verwende technische Anleitungen für Komposition, Timeline, Medien und Ton. Gib Medien aus public/ über die unterstützte API; warte auf das Laden von Schriftarten/Ressourcen. Überprüfe Build und Vorschau, wo verfügbar; kennzeichne fehlende Browser-Vorschau. Exportiere MP4 nach out/video.mp4, beende nicht nur mit Studio. Notiere den genauen Befehl für erneutes Rendern.

Eigenständiges Manim CE

Implementiere Scene in src/manim/; gleiche die Dauern von play/wait mit den Frames des Skripts ab. Verwende die funktionierende Text-/Mathematik-Engine aus den geladenen Skills. Rendere und betrachte zuerst charakteristische PNG/kurzen Entwurf, dann das vollständige Video mit den benötigten Parametern, wobei du explizit FPS/Größe anstelle ungeeigneter Qualitätsvoreinstellungen angibst. Leite Zwischendateien in renders/. Kopiere/führe das Ergebnis in out/video.mp4 zusammen. Füge Ton mit Manim-Mitteln oder verfügbarer Zusammenführung, z. B. FFmpeg, ohne Remotion hinzu. Verwende -shortest nicht so, dass die vorgegebene Videodauer unbemerkt beschnitten wird.

Hybrid

Erhalte zuerst Manim-Einfügungen in renders/ und überprüfe ihre Parameter und Frames. Bereite verfügbare Kopien für den Build in public/ vor; setze dann das Endergebnis in Remotion zusammen. Überprüfe die Übereinstimmung der lokalen Frames der Einfügung mit der globalen Timeline, FPS, Größe, Proportionen/Beschnitt, Hintergrundfarbe oder die tatsächliche Unterstützung von Transparenz durch das Format. Übliches H.264 MP4 hat kein Alpha. Dehne die Einfügung nicht, dupliziere keinen Ton/keine Titel. Bei Inkompatibilität korrigiere die Implementierung im Rahmen der Vereinbarung; besprich wesentliche Änderungen von Inhalt, Design oder Modus, nimm sie nicht stillschweigend vor.

Prüfung und Ausgabe

Erfolgreiche Codierung ist nur ein Teil der Prüfung. Verwende verfügbare Werkzeuge, nicht erfundene Betrachtungsergebnisse. Halte in renders/verification.md (oder einem bestehenden Projektbericht) Eingaben, Versionen, Befehle, Parameter, Betrachtungspunkte, Korrekturen und nicht durchgeführte Prüfungen fest.

1. Überprüfe Build/Render und Dekodierung des endgültigen MP4; messe Codecs, Auflösung, FPS, Dauer/Frames und Audiostreams, z. B. mit ffprobe. Gleiche mit dem Skript ab, berücksichtige die Dauer von Audiopaketen getrennt von Videoframes.
2. Extrahiere tatsächliche Frames aus dem fertigen MP4: Anfang, Schlüsselaktionen/-texte, Ende, Frames vor/nach jeder Naht und innerhalb von Übergängen. Öffne PNG mit einem verfügbaren Bildbetrachter, prüfe Lesbarkeit, Formeln, Ränder, Beschnitt, Überlagerungen, fehlende Medien und Farbsprünge. Ein Kontaktblatt hilft, die Timeline abzudecken; für Bewegung betrachte die Sequenz/das Video, falls verfügbar. PNG aus einem separaten Still-Render ersetzt nicht die Prüfung des endgültigen MP4 und seiner Nähte.
3. Wenn Ton vorgesehen ist, prüfe nicht nur den Stream: Dauer, Signal-/Stille-Intervalle, Pegel und Übereinstimmung der Ereignisse mit den Szenen. Höre das Ergebnis mit einer verfügbaren Methode. Wenn Hören nicht verfügbar ist, gib dies explizit an und trenne die gemessene Synchronisation/Pegel von der ungeprüften Hörverständlichkeit und -qualität. Überprüfe für stumme Clips das Fehlen von nicht vorgesehenem Ton.
4. Korrigiere erkannte Implementierungsfehler und wiederhole die betroffenen Prüfungen. Wesentliche Änderungen von Skript/Modus erfordern eine Entscheidung des Benutzers. Erkläre das Ergebnis nicht als vollständig geprüft, wenn eine obligatorische Prüfung nicht verfügbar ist; liste das Gemachte und den konkreten Rest/Blocker auf.

Melde den tatsächlichen Pfad zu out/video.mp4, zu den Quellen und zum Bericht, den Befehl für erneutes Rendern, die wesentlichen Parameter und Einschränkungen. Gib bei Schreibverweigerung explizit das nicht gespeicherte Ergebnis, bei Blocker den genauen Teilstatus; gib altes MP4 nicht als neu aus. Stoppe nach Produktion und Prüfung. Veröffentliche nicht, mache keine Commits/Pushes und starte keine anderen Schritte ohne separaten Auftrag.