endlessconflict/sourceframe

Was macht sourceframe?

Eine Methode, um ein Video so zu erstellen, wie man ein System baut: Anforderungen zuerst, ein Hauptbuch über das, was wahr ist, ein Layout-Vertrag, kleine verifizierte Schritte, Messung vor Meinung. Das Produkt ist ein kurzes, stummgeschaltetes Video (15 bis 90 s), das einen Mechanismus erklärt, indem es ein einzelnes Fokuselement durch diesen Mechanismus verfolgt. Der Name ist die Regel: Jeder Frame führt auf eine Quelle zurück.

Dieser Skill wurde aus einem echten Build destilliert (einem 77 s Erklärvideo, wie coreboot C-Code ausführt, bevor DRAM existiert, mit einem 4.096-Zellen-Cache-Gitter, einem 3D-Flash-Chip und DRAM-Training) und an einem zweiten, unabhängigen Thema erneut validiert (examples/merkle-proof, ein Merkle-Inklusionsbeweis, dessen jeder Hash vom Build berechnet wird). Pfade unten beziehen sich auf den Ordner dieses Skills.

Wann verwenden, wann nicht

Verwenden Sie ihn für: Wie-es-funktioniert-Videos, Protokoll- oder Algorithmus-Walkthroughs, Systemarchitektur-Touren, „Was passiert, wenn“-Sequenzen, Post-Mortem-Wiederholungen. Er glänzt, wenn das Thema einen Mechanismus mit sich änderndem Zustand hat (Bits kippen, ein Zeiger bewegt sich, ein Hash breitet sich aus).

Nicht verwenden für: Talking-Head- oder Footage-Schnitte, Produktwerbung, reine Bewegtbild-Markeninhalte, alles, bei dem der Inhalt Meinung und nicht Mechanismus ist. Verwenden Sie dafür einen einfachen Motion-Skill. Wenn der Benutzer nur eine statische Karussell-Grafik möchte, verwenden Sie einen Karussell-Skill.

Die sieben Prinzipien

1. Hauptbuch vor Pixeln. Schreiben Sie FACTS.md (Behauptung, Beleg, Status) vor der ersten Szene. Status V aus einer Quelle dieser Sitzung gelesen, C vom Build berechnet, S schematisch und auf dem Bildschirm beschriftet, H Erinnerung (erneut prüfen), N benötigt Quelle (blockiert Versand). Erfinden Sie niemals eine Zahl, ein Symbol, einen Pfad, eine Version. Bevorzugen Sie C: Lassen Sie den Build berechnen, was das Video zeigt.
2. Ein Fokuselement. Eine Sache pro Frame ist der Anker des Auges: Sie erhält die einzige „Fokus“-Farbe, ist immer der aktuelle Schritt und konkurriert nie mit einem zweiten. Alles andere ist konstruktionsbedingt ruhiger.
3. Farbe ist Bedeutung. Palettenrollen (data, focus, ok, bad, ink) sind semantisch und für das gesamte Video festgelegt. Wählen Sie niemals einen Farbton aus optischen Gründen.
4. Determinismus. Ein Frame ist eine reine Funktion seiner Frame-Nummer. Keine Echtzeit, kein Math.random, keine CSS-Übergänge, kein useFrame. Seeded hash(n) für alles Pseudo-Zufällige. Dies ermöglicht paralleles Rendern, Standbilder und spätere Audio-Synchronisation.
5. Das Bild ist das Instrument. Animation existiert, um eine Zustandsänderung zu zeigen. Jede Bewegung beantwortet die Frage „Was zeigt dies?“. Verboten: das gleiche Einblenden bei jedem Block, Bounce- oder Elastik-Easing, sich wiederholende Dekoration, Glühen um seiner selbst willen.
6. Messen zuerst, Aussehen zweitens. Zahlen sind billig und genau; Meinungen sind teuer. Typüberprüfung, Hauptbuch-Lint, Container untersuchen, Pixel messen, wo möglich, dann eine Kontaktkopie pro Runde ansehen.
7. Abbruchregeln. Maximal drei Überarbeitungsrunden pro Szenensatz, maximal drei Korrekturen pro Runde. Sagen Sie, was übrig ist und warum Sie aufgehört haben. Ehrlichkeit vor Perfektion: Kennzeichnen Sie, was nicht verifiziert wurde.

Die zehn Phasen

Jede Phase hat ein Ergebnis und ein Tor. Überspringen Sie kein Tor, um Zeit zu sparen: Die teuren Fehler liegen alle stromaufwärts.

#	Phase	Ergebnis	Tor
0	Aufnahme	Einzeiliger Fit-Check, Plattform, Dauer, stummgeschaltet oder mit Ton	Nur fragen, was die Arbeit blockiert (eine Frage), sonst entscheiden und festlegen
1	Briefing	BRIEF.md Abschnitte 1 bis 3	Zusammenfassung passt in einen Satz; Fokuselement in einer Phrase benennbar
2	Belege	FACTS.md für jede geplante Behauptung ausgefüllt; Berechnungsskripte für C-Zeilen	tools/ledger_lint.py ist erfolgreich; keine N-Zeile
3	Regie	Kill-Liste, Ideensatz, Schlüsselmoment, theme.ts-Tokens	Wettbewerbertest bestanden (siehe references/02-direction.md)
4	Storyboard	Tabelle: Szene, Sekunden, was sich bewegt, Bildunterschrift, Hauptbuchzeile; timeline.json	Bildunterschrift-Budget eingehalten; Gesamtlänge begründet
5	Grundlagen	Eingerüstetes Projekt, Schriften, Thema, Hülle, Kamera, Vorschau öffnet sich	Ein Standbild rendert; WebGL funktioniert (siehe Fallstricke: Pfadlänge)
6	Bau	Szenen, zuerst die schwierigste und zentralste	Pro Szene: Standbilder, eine Kontaktkopie, maximal 3 Korrekturen
7	Assets	3D- und Icon-Assets, prozedural, sofern keine lizenzierte Quelle benötigt wird	Jedes verwendete Logo oder Zeichen unverändert und mit Quellenangabe
8	Verifizierung	Vollständiger Render, Kodierung, Überprüfung, Frame-Blatt, Hauptbuch-Lint	Alle automatischen Prüfungen grün; Blatt überprüft; Fehler aufgelistet
9	Auslieferung	mp4, Cover-Frame, Bildunterschrift, Alternativtext, Quellenangaben, „Nicht verifiziert“-Liste	Der Benutzer kann es posten, ohne fragen zu müssen, was wahr ist

Phase 0: Aufnahme

Geben Sie in einer Zeile an, was Sie erstellen werden: Reading this as: <medium> for <reader>, <focal element>, <duration>. Stellen Sie eine Frage nur, wenn die Antwort ändert, was Sie bauen (Plattform und Seitenverhältnis; ob Ton folgt; welche Quellen maßgeblich sind). Standard-Canvas 1080 x 1350 (4:5) bei 30 fps für soziale Feeds; siehe references/08-adapting.md für 16:9, 1:1, 9:16.

Phase 1: Briefing

Kopieren Sie templates/starter/BRIEF.md. Füllen Sie die Absicht aus (Medium, Leser, Zusammenfassung, Fokuselement, Stimmung). Die Zusammenfassung muss ein Satz sein, den ein Zuschauer wiederholen könnte. Wenn Sie das Fokuselement nicht in einer Phrase benennen können, haben Sie noch kein Video: Entscheiden Sie und sagen Sie es, oder stellen Sie eine Frage.

Phase 2: Belege (der Teil, den die meisten Videos überspringen)

1. Identifizieren Sie die Primärquellen (Spezifikation, RFC, Quellbaum, Datenblatt, Manpage, gemessene Ausgabe). Lesen Sie die genauen Zeilen, die Sie zitieren werden. Notieren Sie Datei:Zeile oder URL plus Abschnitt.
2. Fragen Sie bei jeder Zahl: Kann der Build sie berechnen? Wenn ja, schreiben Sie ein Skript, das sie berechnet, auf einem zweiten Weg kreuzprüft, bei Nichtübereinstimmung abbricht und ein generiertes Modul schreibt, das die Szenen importieren (examples/merkle-proof/scripts/compute.mjs ist das Modell: RFC-Rekursion versus iterativer Build müssen übereinstimmen, sonst wird nichts geschrieben).
3. Alles, was nicht quellbar ist, wird entweder ein beschriftetes Schema (S, und das Wort „Schema“ erscheint auf dem Bildschirm) oder wird gestrichen. Sichtbares [NEEDS SOURCE] ist in Entwürfen erlaubt, niemals im Render.
4. Beispielhafte Daten sind legal, wenn sie ehrlich sind: Erfundene Beispielobjekte werden als einfacher Beispieltext angezeigt und als S protokolliert.
5. Führen Sie python tools/ledger_lint.py als Auslöser aus: Jede Ziffer in einer Szenenzeichenfolge muss im Hauptbuch erscheinen.

Vollständiges Format und Beispiele: references/01-brief-and-ledger.md.

Phase 3: Regie

Schreiben Sie den Ideensatz: „In diesem Video wird [etwas, das zum Thema gehört] zu [dem Gerät].“ Führen Sie den Wettbewerbertest durch: Wenn ein generisches Video zum Thema denselben Satz verwenden könnte, handelt es sich um eine Kategorieidee, nicht um eine Idee. Wählen Sie einen Schlüsselmoment (die einzige auffällige Bewegung) und die Kill-Liste (die drei offensichtlichsten Visualisierungen, jetzt verboten: typischerweise ein Stapel von Rechtecken mit Pfeilen, ein Screenshot, ein zentriertes Objekt auf einem Farbverlauf). Stellen Sie die Regler ein: Varianz, Bewegungsintensität, Dichte, jeweils 1 bis 10, abgeleitet vom Thema (ein Sicherheitserklärvideo für Ingenieure ist ruhig und dicht; ein Launch-Teaser ist keines von beidem). Details und die Choreografie-Regeln in references/02-direction.md.

Phase 4: Storyboard und Timing

Eine Tabelle: Szene, Sekunden, was sich bewegt, Bildunterschrift, Hauptbuchzeile. Budgets, die sich in der Praxis bewährt haben:

• Bildunterschrift maximal 2 Zeilen und 14 Wörter, mindestens 48 px auf einer 1080-Leinwand (ein Telefon zeigt die Leinwand etwa 0,36-fach, also sind 48 px etwa 17 pt); Beschriftungen mindestens 26 px;
• Eine Bildunterschrift bleibt mindestens Wörter / 2,6 + 0,8 Sekunden, wird nie mitten im Satz ersetzt;
• Eine Idee pro Szene; eine Szene länger als 12 s benötigt interne Takte (Schritte) mit eigener Bildunterschrift;
• Das gesamte Stück ist eine Idee, einmal erzählt: Streichen Sie jede Szene, deren Entfernung keine Hauptbuchzeile verlieren würde.

Schreiben Sie die Szenenreihenfolge und -längen nur in timeline.json. Remotion, die Verifizierungsskripte und die CueLab-Audio-Pipeline lesen alle dieselbe Datei.

Phase 5: Grundlagen

node scripts/scaffold.mjs <target-dir> --install

Dann: Bearbeiten Sie src/theme.ts (Palette, Canvas), legen Sie Schriftarten in public/fonts ab, setzen Sie BRAND in src/ui/Chrome.tsx, bearbeiten Sie timeline.json. Halten Sie den Projektpfad kurz (siehe Fallstricke: ANGLE benötigt einen kurzen Pfad unter Windows). Rendern Sie ein Standbild einer 3D-Szene, bevor Sie mehr schreiben: Wenn WebGL jetzt fehlschlägt, wird es später fehlschlagen.

Phase 6: Bau, Szene für Szene

Reihenfolge: die Schlüsselszene zuerst (das schwierige 3D oder Gitter), dann die Szenen, die davon abhängen, dann verbindende Szenen. Pro Szene:

1. Schreiben Sie die Szene gegen den Layout-Vertrag (references/03-layout-contract.md) mit Shell, Tokens und den Animations-Helpern;
2. bash tools/shots.sh <Scene> out/<scene> <frames...>: Wählen Sie Frames am Anfang, in der Mitte der Bewegung und am Ende jedes Taktes, eine Kontaktkopie;
3. Lesen Sie das Blatt einmal und beantworten Sie: Erstes/zweites/drittes gesehenes Objekt? Fokuselement wie beabsichtigt? Irgendetwas generisch? Was soll gestrichen werden? Beheben Sie höchstens drei Dinge; nehmen Sie nur geänderte Frames neu auf;
4. Wenn die Szene stabil ist, fahren Sie fort. Polieren Sie Szene 2 nicht, während Szene 6 noch ungebaut ist.

Bewegungsmuster, die die Arbeit tragen (maskierte Linien-Enthüllungen, gestaffelte Zeilen, Hash-Scramble, Bitflips, projizierte Beschriftungen auf 3D, instanziierte Gitter) finden Sie in references/04-remotion-patterns.md; 3D-Rezepte in references/05-three-assets.md.

Phase 7: Assets

Bevorzugen Sie prozedurale Assets: Sie sind deterministisch, winzig, thematisierbar und ohne Lizenzrisiko. Folienboxen, extrudierte Logos, instanziierte Zellgitter und Punktfelder decken die meisten Erklärvideos ab. Verwenden Sie KI-generierte Meshes nur, wenn ein organisches oder markenrechtlich geschütztes Objekt wesentlich ist und die Lizenz und die Kosten des Dienstes für den Benutzer akzeptabel sind; verheimlichen Sie niemals, dass ein Asset generiert wurde. Echte Logos und Zeichen: Verwenden Sie die eigene Datei des Projekts unverändert (das Umfärben eines einfarbigen Zeichens ist in der Regel in Ordnung; ein Neuzeichnen nicht), prüfen Sie die Lizenz, nennen Sie die Quelle auf dem Bildschirm oder in der Bildunterschrift.

Phase 8: Verifizierung

Automatisch, in dieser Reihenfolge (günstig zu teuer):

npx tsc --noEmit                 # Typen
python tools/ledger_lint.py      # Zahlen vs. Hauptbuch
bash tools/shots.sh Main out/m <frames>   # Kontaktkopie, einmal ansehen
npm run render && npm run encode          # Rohrender, dann limited-range yuv420p h264
                                          # encode.sh endet mit dem Ausführen von tools/probe.py

tools/probe.py prüft Codec, yuv420p (nicht yuvj420p), Größe, fps, Dauer gegen timeline.json, limited range, keine schwarzen Frames, Fast-Start-Atom. Dann sehen Sie sich ein Blatt des endgültigen MP4 an (Frames alle 4 s, extrahiert mit ffmpeg) und einen Frame in voller Größe auf Textschärfe. Wenn ein Design-Kritiker verfügbar ist (z. B. der creator-critic-Skill), führen Sie ihn auf einem Ordner mit Standbildern aus: Behandeln Sie Blocker als Blocker und Majors als Fragen. Vollständige Checkliste: references/06-verification.md.

Phase 9: Auslieferung

Liefern aus: out/video.mp4, einen Cover-Frame (ein Ruheframe, in dem sowohl der Titel als auch das Fokuselement lesbar sind), Bildunterschriftenentwurf (einfach, keine Übertreibungen, Quelle genannt), Alternativtext (ein Satz darüber, was das Video zeigt), Quellenangaben (Assets, Logos, Lizenzen) und eine „Nicht verifiziert“-Liste (alles im Hauptbuchstatus H oder S, alles, was der Build nicht beweisen kann, alles, was Sie nicht mit eigenen Augen überprüfen konnten). Posten Sie selbst nichts.

Entscheidung zwischen Optionen (Entscheidungstabellen)

Frage	Wählen	Weil
2D oder 3D für ein Element	3D nur, wenn Tiefe oder physische Form der Punkt ist (ein Chip, ein Stapel, ein Feld mit einer Million Objekten); sonst 2D	3D kostet Renderzeit und Lesbarkeit; verwenden Sie es, wo es erklärt
Kamera	orthografisch, manual = true, fest pro Szene	Ortho hält Beschriftungen projizierbar und Messungen ehrlich
Beschriftungen auf 3D	HTML oder SVG projiziert mit project()	Text bleibt scharf und gestaltet
Viele wiederholte Zellen	InstancedMesh (Tausende) oder Points (eine Million)	Zeichenaufrufe
Schriftarten	Maximal zwei Familien, OFL oder lizenziert, gebündelt in public/fonts	Determinismus, kein Netzwerk beim Rendern
Text auf Fläche oder Füllung	Dunkler Text auf hellen Flächen, niemals weiß auf hell	Kontrast
Ton	Nach der Bildsperre entwerfen, basierend auf timeline.json	Siehe den cuelab-Skill

Fehlermodi, die diese Methode verhindern soll

Das schöne, aber falsche Video (kein Hauptbuch); das korrekte, aber unlesbare Video (kein Layout-Vertrag); das generische Video (kein Ideensatz, keine Kill-Liste); das Video, das im Studio gut aussieht und im Render kaputt geht (Nichtdeterminismus); das Video, das bei 100% gut aussieht und auf einem Telefon Matsch ist (Schriftgrößen-Mindestwerte, Miniaturansicht-Test); das Video, das nicht bewertet werden kann (keine einzige Zeitachse); das Video, dessen Behauptungen niemand überprüfen kann (keine Ehrlichkeit bei der Auslieferung). Konkrete Fehler, die beim Bau der ersten beiden Videos gefunden wurden, jeweils mit Symptom, Ursache und Korrektur, finden Sie in references/07-pitfalls.md; lesen Sie dies, bevor Sie etwas debuggen, das wie Magie aussieht.

Dateien in diesem Skill

Pfad	Was
references/01-brief-and-ledger.md	Briefing-Vorlage, Hauptbuchformat, wie Fakten berechnet und kreuzgeprüft werden
references/02-direction.md	Ideensatz, Kill-Liste, Regler, Choreografie-Regeln, Bewegungs-Tokens
references/03-layout-contract.md	Canvas, Sicherheitsbereiche, Schriftgrößen-Mindestwerte und die Telefon-Skalierungsarithmetik
references/04-remotion-patterns.md	Getestete Animationsmuster mit Code
references/05-three-assets.md	three.js in Remotion: Kamera, Folien-Shader, Kanten, Instancing, Punkte, Extrusion, Beschriftungsprojektion
references/06-verification.md	Die vollständige Verifikationsleiter, Kontaktkopie-Protokoll, Kodierung und Überprüfung
references/07-pitfalls.md	Jeder echte Fehler, auf den wir gestoßen sind, mit Korrekturen
references/08-adapting.md	Andere Seitenverhältnisse, Themen, Sprachen, No-3D-Variante, Übergabe an Ton
templates/starter/	Ein funktionierendes Remotion-Projekt: Thema, Helfer, UI-Chrome, three.js-Kit, Tools, BRIEF- und FACTS-Vorlagen
scripts/scaffold.mjs	Kopiert das Starter in ein neues Projekt und installiert
../../examples/merkle-proof/	Ein vollständiges 36 s Beispiel mit berechneten Fakten, Hauptbuch, Render und Überprüfung

Lizenzhinweis, den Sie weitergeben müssen

Remotion ist nicht MIT. Es ist kostenlos für Einzelpersonen und für Teams von bis zu drei Personen; Unternehmen darüber hinaus benötigen eine kostenpflichtige Lizenz (die Remotion CLI druckt den Hinweis, siehe remotion.pro/license). Informieren Sie den Benutzer einmal frühzeitig, wenn das Projekt kommerziell sein könnte. three.js, React und die gebündelten Schriftarten (SIL OFL) sind permissiv.