СТАТТЯ

FLORA: spreadsheet batch через MCP (20 паралельних рядків) проти оркестрації Bubble-каталогу в BIAIG

Віталій Дорошенко Опубліковано

Де зупинити FLORA MCP (chunks по 20, polling, run_id→SKU), а де тримати source of truth і batch-identity у Bubble — чеклист без плутанини batch-id і без double-bill після timeout.

Контекст

У digest з’явилася нова точка на карті «зовнішній batch-host перед Bubble»: FLORA batch з spreadsheet через MCP — приблизно 20 паралельних рядків на виклик. Той самий архітектурний слот, що Ideogram Batch (до ~500 рядків на upload) і Batch Banana (до 1 000 рядків CSV/TSV на Max), але інший масштаб і вхід через MCP/agent, а не лише hosted UI. Схожий розбір: Ideogram Batch (500 rows) проти.

Публічна документація FLORA описує MCP-рецепт як оркестрацію агентом: експорт таблиці, один prompt template на рядок, submit через flora_create_generations (1–20 generations на виклик, паралельно всередині виклику). Більший job — chunks по 20 у заявленому діапазоні ~20–500 assets. Polling — flora_list_generations (до 20 run_id за виклик), cooldown max(15 s, 2 s × кількість run).

BIAIG у публічному вигляді (biaig.com) не дає верифікованої специфікації оркестрації. Нижче — поділ шарів, який я узгодив з Bubble Manual і editorial brief (internal catalog app на Bubble). Схожий розбір: ShaheerTools free bulk guide (17.10):.

Де зупинити FLORA (MCP)

На стороні FLORA + agent/middleware лишаю лише те, що в docs названо generation layer:

  1. Паралельність і chunking — не більше 20 рядків на flora_create_generations; решту job розбиваю явно. Це не один upload на 500/1 000 рядків, як у Ideogram/Batch Banana.
  2. Polling і partial retry — список run_id, інтервали з docs. Агресивний polling я вже бачив, як б’ється об rate limits (429/cooldown).
  3. run_id → рядок (наприклад SKU) — документація прямо каже: це єдиний стабільний зв’язок між run і source row. Map має жити поза сесією агента — файл, БД, Bubble-запис job, не «в голові» chat.
  4. Quote-before-run там, де рецепт це передбачає — не стрибаю в create без розуміння billing.

Bubble live ledger на кожен MCP-виклик — погана ідея. Занадто багато round-trips і зайва coupling. Bubble має отримувати стан job і результати, а не кожен проміжний create.

Де тримати source of truth (Bubble / BIAIG)

Каталог, SKU/variant, статуси «queued / generating / failed / ready», URL зображень після completion — тут, якщо BIAIG — ваш Bubble-backed catalog: Поруч із цим: OpenArt Bulk Create (500 CSV.

  • Data API — CRUD по записах каталогу та batch job.
  • Workflow API — тригери з зовнішнього middleware після chunk/poll.
  • Schedule API Workflow on a list — нативна ітерація з interval для rate limits, коли orchestration частково в Bubble, а не в agent loop.

Один canonical batch job id створюю у Bubble до першого flora_create_generations — наприклад поле batch_job_id + статус. FLORA MCP не дає idempotency key на create; це не замінник вашого job id.

Критично: без idempotency на create

FLORA явно попереджає: flora_create_generations без idempotency key. Timeout або втрачена сесія + повторний fire рядків без перевірки project history → double-bill. Я б не покладався на «авось не дублюється».

Обов’язково (не optional):

  • Перед повторним submit рядка — перевірити, чи run уже існує в history.
  • Персистити кожен (stable_row_key, chunk_index, run_id, create_timestamp).
  • Retry лише failed рядки (partial success у рецепті), не весь chunk «вслепую».

Optional skill / skill_run_id на generation calls — лише attribution у звітах, не deduplication. Не плутайте з batch job identity у Bubble.

Не дублюйте «batch-id» (чеклист)

Ідентифікатор Хто володіє Призначення
Bubble batch_job_id Bubble/BIAIG Один job на spreadsheet import; idempotency на вашому боці
FLORA run_id (1..N) FLORA Один generation run; map до SKU/row key
Chunk index (0, 1, 2…) Ваш middleware Які 20 рядків уже відправлені
skill_run_id FLORA reporting Attribution, не dedupe

Помилка: називати «batch id» один MCP chunk або один skill_run_id і думати, що це покриває весь spreadsheet job.

MCP batch = багато викликів create + poll, не один об’єкт batch як у FLORA API/SDK CSV recipe.

Коли не MCP «fire chunks of 20»

FLORA API/SDK CSV recipe (Technique-per-row) документує idempotency keys, bounded concurrency (наприклад старт з CONCURRENCY = 4), resumable reruns — ближче до production, ніж agent loop з chunks по 20.

Орієнтир для рішення (без вигаданих SLA):

  • ~20–500 assets, agent-driven, MCP уже в стеку — MCP recipe + жорсткий map + history checks.
  • Потрібні idempotency і resumability «з коробки» на стороні FLORA — дивіться API/SDK CSV, не лише MCP.
  • 500–1 000+ рядків, мінімум custom orchestration — порівняйте hosted batch Ideogram/Batch Banana (інші ліміти, plan gates, credit model); chunk math для FLORA MCP при 20/call означає більше явних кроків, ніж один upload.

Запис результатів у каталог

Після completion: image URL → поле variant/SKU у Bubble (Data API update або Workflow API з middleware). Row key на старті job має збігатися з ключем у map run_id → row. Якщо SKU зміниться mid-batch — політика conflict (freeze export vs live catalog) має бути одна, зафіксована до старту.

Короткий workflow

  1. Export/stable row list + SKU column (як у FLORA guides).
  2. Bubble: створити batch_job_id, статус draft → running.
  3. Middleware/agent: chunks по 20 → create → persist run_ids → poll з cooldown rules.
  4. On complete/fail: оновити Bubble records; failed — targeted retry з history check.
  5. Закрити job у Bubble; FLORA layer більше не «джерело правди» для каталогу.

Джерела (публічні)

FLORA MCP batch recipe, runs/polling, generation tools; FLORA API batch-from-CSV; Ideogram Batch; Batch Banana Batch; Bubble Schedule API Workflow on a list та API terminology. BIAIG — лише editorial контекст internal app, не верифікований public orchestration API.

Відкриті питання: canonical row list під час run (file vs staged Bubble table); exact wiring BIAIG↔FLORA без internal docs — лишаються на вашому product spec.

Схожі статті

← Усі статті