Seu sintoma (funciona para a imagem 1, a imagem 2 recebe apenas uma pasta e nenhuma geração) é o clássico problema de Loop Over Items aninhado. Quase nunca é o nó Gemini.
Por que acontece
O Loop Over Items (SplitInBatches) do n8n mantém seu contador de lote dentro do nó. Seu loop interno sobre os 6 prompts termina todos os 6 para a imagem 1 e permanece no estado "concluído". Na segunda iteração externa, seu loop de imagens lhe entrega a imagem 2, mas o loop interno ainda acredita que já foi concluído, então ele aciona sua saída done imediatamente e pula os nós Gemini e upload. Tudo antes do loop interno ainda é executado, o que é exatamente por que a imagem 2 recebe sua etapa Create Concept Folder e nada mais.
A correção de um nó
Abra seu nó interno Loop Over Prompts, vá para Options e ative Reset. Isso força o loop interno a ser reinicializado toda vez que uma nova imagem chega do loop externo, em vez de permanecer "concluído". Esta é a correção para a grande maioria dos relatórios "nested loop runs once".
Duas coisas que vale a pena verificar rapidamente enquanto você estiver lá:
- Confirme que Build Prompts realmente emite 6 itens por imagem. Se uma execução mostrar um "items total" menor do que esperado, o loop tem menos coisas para iterar do que você pensa.
- A ramificação done do seu loop interno deve retornar ao loop de imagens externo, que na sua captura de tela faz, então a fiação em si está correta. Reset é o que está faltando.
Vale considerar: elimine completamente o loop interno
Loops aninhados SplitInBatches são o padrão mais frágil do n8n, e suas chamadas Gemini são executadas estritamente uma por vez, então 2 imagens com 6 prompts cada é 12 gerações sequenciais. Como você está no nano-banana (Gemini 3.1 Flash Image), você pode distribuir os 6 prompts como 6 itens e executá-los em paralelo com uma API de imagem assíncrona. Uso KIE.AI, que expõe nano-banana como um job submit-then-poll:
- Build 6 Prompts (um nó Code) emite 6 itens.
- Submit Task é um único nó HTTP sem loop ao redor. Como um nó HTTP é executado uma vez por item de entrada, todos os 6 jobs são acionados quase simultaneamente e cada um retorna um
taskId.
- Uma etapa curta Wait then Poll coleta cada resultado. Os itens se encaminham sozinhos: um concluído faz download e salva imediatamente, um pendente aguarda e consulta novamente, então jobs rápidos não esperam pelos lentos.
Não há nenhum Loop Over Items interno em qualquer lugar, então não há estado de reset para acertar, e todos os 6 são renderizados de uma vez, em vez de um por vez.
Coloquei um workflow de referência sanitizado abaixo (clique no </> no composer e ele importa diretamente). O loop de imagem externa permanece; o loop de prompt interno desapareceu. Substitua os nós Google Drive por onde suas imagens estão, coloque sua credencial de portador KIE.AI nos dois nós HTTP e edite as seis strings de cenário em Build 6 Prompts. Também há uma nota sticky mostrando a mudança de uma linha para executar image-to-image (variações da imagem de origem) em vez de text-to-image.
Qualquer um dos caminhos o corrige: Reset se você quiser manter seu design atual, ou o fan-out assíncrono se você quiser mais rápido e mais difícil de quebrar conforme adiciona mais imagens de entrada.
Espero ter ajudado,
Michael
