Slice 3 of the batch feature. Marketing team can now upload the
Rasika-style CSV, watch each row auto-map to the trainer/studio
they uploaded in slice 2, get a real MuAPI cost estimate, and
persist the batch as a draft.
Backend
-------
- POST /api/batches: creates a batch in status='draft' along with one
job per CSV row (status='queued', not yet picked up since the
worker arrives in slice 4).
- GET /api/batches: list view payload.
- GET /api/batches/[id]: detail with jobs joined to trainer/studio
rows. Used by the slice-5 progress UI.
- POST /api/batches/[id]/estimate-cost: forwards the batch's model +
payload to MuAPI's /api/v1/app/calculate_dynamic_cost, multiplies
by row count, returns {perJob, total, currency}.
CSV
---
- lib/csvParser.js: PapaParse-based parser that validates required
columns, normalises duration ("15 sec" -> 15) snapped to Seedance
2.0's [5,10,15], maps quality ("1080P" -> "high"), and composes a
prompt from description + start position + camera angle.
UI
--
- components/batch/NewBatchWizard.jsx: full-screen 3-step wizard.
- Step 1 — name, CSV upload, model/duration/quality/aspect/
concurrency settings.
- Step 2 — review every row in a table. Auto-maps Character ->
Trainer.csvLabel and Studio -> Studio.csvLabel, shows per-row
override dropdowns and bulk-assign helpers, hard-blocks Next
until every active row has both a trainer and studio.
- Step 3 — saves the batch and triggers the cost estimate. On
success, surfaces the batch id and points the user to the
upcoming worker slice.
- components/batch/BatchesTab.jsx: replaces the placeholder with a
real list view (status pill, progress counts, model, created-at)
and the "+ New batch" button that opens the wizard.
- components/batch/BatchShell.jsx: pass apiKey to BatchesTab.
Verification
------------
- POST /api/batches with one row -> 201, batch + job persisted in
Postgres (verified with psql).
- GET /api/batches lists the row.
- Cost estimate endpoint returns 401 without a key, calls MuAPI
correctly with one (live test pending real credits).
Slice 2 of the batch feature. Marketing team can now upload the six
trainer images and the studio image once and reuse them across every
future batch.
Backend
-------
- lib/muapiUpload.js: Node-side wrapper around POST
/api/v1/upload_file with FormData + x-api-key. Mirrors
packages/studio/src/muapi.js:131-178 but uses native fetch +
FormData (no XHR).
- lib/batchAuth.js: shared getApiKey() — header > cookie > env fallback.
- lib/localUploadStore.js: writes a local backup of every uploaded
asset to /data/uploads/{trainers,studios}/<id>.<ext> on the
uploads_data volume, so we can re-upload to MuAPI if their CDN
ever expires the URL.
- app/api/trainers/route.js + [id]/route.js: GET list, POST multipart
(uploads to MuAPI then persists), DELETE (refuses if any active job
references the row).
- app/api/studios/route.js + [id]/route.js: identical shape.
UI
--
- app/batch/page.js: leaf route mounting BatchShell.
- components/batch/BatchShell.jsx: 3-tab dark-theme shell
(Batches / Trainers / Studios) with the same MuAPI key gate as
StandaloneShell (reuses ApiKeyModal + the muapi_key cookie).
- components/batch/AssetLibrary.jsx + AddAssetModal.jsx: shared grid +
upload modal driving both tabs from one component.
- components/batch/TrainersTab.jsx, StudiosTab.jsx: thin wrappers.
- components/batch/BatchesTab.jsx: placeholder for slice 3.
Stub packages (upstream submodules unavailable)
-----------------------------------------------
The ai-agent and workflow-ui submodules referenced in .gitmodules
return 404 (Anil-matcha/workflow-ui and jaiprasad04/ai-agent are
deleted/private). next build couldn't resolve their imports.
- Removed the dead .gitmodules entries.
- Added local stubs at packages/ai-agent and packages/workflow-ui
that export no-op components rendering "feature unavailable" so
the build succeeds. The /agents/* and Workflows tab show that
notice; the studios our marketing team actually uses
(Image / Video / Lip Sync / Cinema) keep working since they
live in the studio package which we have.
Docker / dev workflow
---------------------
- Dockerfile: run prisma generate during the builder stage, copy
prisma/ and lib/ into the runner stage so migrations and shared
helpers are present at runtime.
- docker-compose.override.yml (new): dev-mode overrides — mounts
source, runs as root to dodge node_modules permission issues with
the prod nextjs user, runs prisma generate + migrate deploy +
next dev. Worker container is a placeholder until slice 4 lands.
- The full stack (postgres + web + worker) now boots with
`docker compose up -d` and serves /batch on http://localhost:3000.
First slice of the CSV-driven batch video-generation feature. Introduces
the four-table schema (trainers, studios, batches, jobs) that the worker
and new /batch UI will operate on, plus the infrastructure glue so the
schema can be applied locally and in the docker-compose stack.
- prisma/schema.prisma: Trainer, Studio, Batch, Job models with the
indexes the worker's claim query will need
([batchId, status] and [status, nextAttemptAt]).
- prisma/migrations/20260423011041_init_batch_schema: initial migration
generated and applied against the compose Postgres.
- lib/prisma.js: standard Next.js PrismaClient singleton, reused across
the web API routes and the worker process.
- docker-compose.yml: map Postgres to host port 5433 to avoid colliding
with a pre-existing local Postgres on 5432; wire MUAPI_API_KEY env
through web and worker; add uploads_data volume mounted at
/data/uploads for slice-2 trainer/studio image backups.
- .env.example: documented DATABASE_URL (5433 for host, 5432 for
in-compose) and MUAPI_API_KEY placeholders.
- .gitignore: ignore /data/uploads/ now so future runtime uploads
don't end up tracked.
Also downgraded prisma from 7.x to ^6 since 7 moved datasource config
out of schema.prisma into a separate prisma.config.ts (breaking change
we don't need to absorb yet).
No API routes, worker, or UI in this slice — those land in the next
branches (feat/trainers-studios-crud, feat/batch-create-csv, etc).
