AVAPAX-Video

Produkcja powtarzalnych materiałów wideo — prezentacji produktów, wariantów językowych, formatów pod różne kanały — to praca, w której twórcza jest jedna decyzja, a reszta to wykonanie tej samej sekwencji setki razy.

Rozdzielić orkiestrację od wykonania i dać jednej kolejce zadań cztery różne wejścia. To samo zadanie musi dać się uruchomić z interfejsu graficznego, z wiersza poleceń, z żądania HTTP i z narzędzia agentowego przez MCP — bo każdy z tych sposobów jest właściwy w innej sytuacji.

Repozytorium jest podzielone według warstw: apps to procesy uruchomieniowe (serwer API, CLI, worker, scheduler, desktop, serwer MCP), packages to domena, aplikacja, kontrakty, baza i storage, a adapters to integracje zewnętrzne, na czele z FFmpegiem.

Taki podział wymusza kierunek zależności: domena nie wie nic o FFmpegu, a worker nie wie nic o interfejsie, z którego przyszło zlecenie. Zadanie jest kontraktem, nie wywołaniem funkcji.

Tryb deweloperski działa na SQLite i lokalnym workerze; tryb serwerowy uruchamia się przez Docker Compose z PostgreSQL i Redisem.

Workflow oparty na węzłach jest tu czymś więcej niż wygodą interfejsu: opisuje zależności między zadaniami, dzięki czemu scheduler wie, co można policzyć równolegle, a co musi poczekać. Przy renderze rozproszonym to właśnie ta informacja decyduje o czasie całego zlecenia.

Zamknięty jest etap pierwszy — fundament. Działa import assetu z sondowaniem, transkodowanie z presetami, diagnostyka środowiska (avapax doctor) oraz API z dokumentacją OpenAPI.

Dokumentacja jest nietypowo rozbudowana i celowo dwutorowa: obok instrukcji użytkownika i referencji API istnieje READMEAI.md — dokument operacyjny dla agentów AI, zawierający mapę systemu, wszystkie endpointy, typy zadań, przepisy i kody błędów.

Fundament stoi: kolejka, worker, adapter FFmpeg, kontrakty i macierz identyfikowalności wymagań. W repozytorium leżą materiały testowe i zbudowane binaria FFmpeg, więc uruchomienie nie wymaga instalowania zależności systemowych.

Warto odnotować, na jakim etapie projekt jest naprawdę: zamknięty jest fundament, nie produkt. Dokumentacja mówi o tym wprost i utrzymuje osobny plik statusu oraz macierz identyfikowalności wymagań — to rzadkość w projektach warsztatowych, ale przy platformie z czterema interfejsami wejściowymi bez tego traci się orientację po miesiącu.

Adapter FFmpeg jest odizolowany celowo. To najbardziej zmienny element całego systemu: składnia parametrów zmienia się między wersjami, a komunikaty błędów bywają nieczytelne. Zamknięcie go za kontraktem oznacza, że aktualizacja FFmpega dotyka jednego pliku, a nie całej aplikacji.