Verifikation
Verwende die niedrigste Verifikationsstufe, die das angeforderte Ergebnis beweist:
| Stufe | Erforderlicher Nachweis |
|---|---|
| L0 | Statische Prüfungen wie das fokussierte Verifikationsskript, npx tsc --noEmit, Tests und Build. |
| L1 | Ein echter Agenten-Lauf gegen den Editor unter localhost:5199, gefolgt von strukturellen und gerenderten Beweisen. |
| L2 | Die verpackte Desktop-App, die das Benutzerszenario abschließt, einschließlich menschlicher Sichtprüfung, wo Automatisierung unzureichend ist. |
Änderungen des Laufzeitverhaltens erfordern L0 + L1. Release- und Desktop-spezifische Änderungen erfordern ebenfalls L2, wenn die verpackte App das zu testende Verhalten ist.
Bevorzuge zwei Signale:
read_projectfür die Struktur: Assets, Tracks, Items, Frame-Platzierung, Timeline-Dauer.- Ein visueller Erfassungspfad für gerenderte Beweise zu exakten Frames.
Verwende view_timeline_frames für den Beweis der zusammengesetzten Timeline. Dies verifiziert die bearbeitete OpenChatCut-Timeline: Trims, Ebenen, Untertitel, Effekte,
Marker, Platzhalter, Zuschnitte, Überblendungen und Layout.
Für die Inspektion von Rohmaterial-Frames wähle den günstigsten Pfad basierend darauf, wo die Bytes leben:
- Der Agent in diesem Build hat keinen lokalen Dateisystemzugriff; alle Quell-Bytes leben
im Medien-Store des Projekts (
/media/uploads/). Verwendeview_asset_framesmit der Projekt-Asset-ID – der Server nimmt automatisch einen schnellen ffmpeg-Kontaktbogen-Pfad, daher ist dies bereits der günstigste Pfad für Quell-Frames. view_timeline_framesrendert die zusammengesetzte Timeline (die Editor-Wahrheitsprüfung);view_asset_framessampelt rohe Quell-Frames. Wähle basierend darauf, was du überprüfst.- Es gibt kein separates
get_contact_sheet-Tool in diesem Build – der Kontaktbogen ist das, wasview_asset_frames/view_timeline_framesbereits zurückgeben.
Verwende lokale/Remote-Quell-Frame-Artefakte nur zum Verständnis der Quelle, zur Momentauswahl und für grobe Trim-Entscheidungen, nicht als bearbeitete Ausgabe oder Timeline-Beweis.
Für lokale oder gerade hochgeladene Medien kann der Beweis der zusammengesetzten Timeline
blockiert sein, bis das Asset dem Renderer Bytes zur Verfügung stellt. Die Quell-Frame-Inspektion
via view_asset_frames funktioniert weiterhin, solange die Bytes des Assets auf der
Festplatte sind (/media/uploads/).
Wenn beide visuellen Beweispfade blockiert sind, bitte den Benutzer, den OpenChatCut-Editor direkt zu inspizieren und den Blockierer explizit zu notieren.
Nützliche Prüfungen:
- Nach dem Import:
read_project({ "view": "assets", "assetId": "<prefix>" }) - Nach Verschieben/Trimmen:
read_project({ "view": "timeline" }) - Nach visueller Überlagerung oder MG auf einem Timeline-Medium:
view_timeline_frames({ "frames": [30, 45, 75] }), dann überprüfe die zurückgegebenen Frames. - Für benutzeranfrage zur Quellauswahl oder visuellen Momentauswahl: sample Standbilder mit
view_asset_framesund inspiziere sie. Verwende dies nur, um Quelldateien, Momente und grobe Trims auszuwählen. Baue die sichtbare Bearbeitung als OpenChatCut-Timeline-Elemente. Behandle die Rohquell-Inspektion nicht als Timeline-Verifikation oder als Erlaubnis, das bearbeitete Video woanders zu produzieren. - Für die Quell-Frame-Inspektion: rufe
view_asset_frames({"assetId":"...","sourceTimesMs":[...]})auf, nachdemread_project({"view":"assets"})die Asset-ID / den Typ bestätigt hat. Bevorzuge dies, anstatt den Benutzer zu bitten, die Datei erneut anzuhängen. - Für die lokale visuelle Verifikation: lade/registriere cloud-lesbare Medien, bevor du dich auf den visuellen Beweis des Konnektors verlässt.
- Für die Validierung ohne Quelle: bestätige, dass das Tool-Manifest die von dir verwendeten Parameter offengelegt hat, und protokolliere dann den sichtbaren Beweis im Trace-Log.
Wenn du über Sekunden sprichst, überprüfe die fps aus read_project oder verwende Adapter-Tools, die fps intern auflösen.
Wenn du über einen Timeline-Element-Ort berichtest, verwende nur die neueste read_project-Struktur für Track-Alias, Element-ID, Start, Dauer und Asset-ID. Berichte nicht über geplante/Standard-Tracks oder die Tool-Call-Absicht als verifizierte Platzierung.
Behandle eine JSON-Antwort der Befehlszeile allein nicht als ausreichend, wenn der Benutzer fragt, ob der Editor das Ergebnis widerspiegelt. Verwende bei Möglichkeit die Editor-URL oder den visuellen Beweis.
Überprüfung des echten Agent-Transkripts
Nach jedem L1-Agenten-Lauf überprüfe den vollständigen Chat-Verlauf, bevor du den Erfolg meldest:
- Lies die letzte Assistentenantwort und jede Tool-Zeile, die durch den Lauf erstellt wurde.
- Erweitere fehlgeschlagene oder warnende Zeilen und protokolliere den genauen Fehler.
- Überprüfe auf abgebrochene Runden, wiederholte Wiederholungen, veraltete Vorschläge, unvollständige Jobs und Tool-Ergebnisse, die die letzte Antwort fälschlicherweise als erfolgreich beschreibt.
- Vergleiche das letzte
read_project-Ergebnis mit der sichtbaren Timeline. - Für visuelle Bearbeitungen inspiziere zurückgegebene Timeline-Frames, anstatt der Zusammenfassung des Assistenten zu vertrauen.
Ein Lauf mit einer korrekt aussehenden Timeline, aber einem nicht gemeldeten Tool-Fehler, ist kein sauberer Durchlauf. Behebe die Ursache oder melde den verbleibenden Fehler explizit.
Wenn die Verifikation fehlschlägt, klassifiziere die Lücke, bevor du die Tools wechselst:
- Tool-Beschreibung oder Schema war unzureichend
- Skill-Anweisungen haben einen Schritt vermisst
read_projecthat nicht genügend Zustand offengelegt- Editor-Autorisierung wurde nicht abgeschlossen
- Medien-/Transkriptions-Pipeline ist fehlgeschlagen
- Cloud-Rendering/Editor-Beobachtung wurde blockiert