# COMO SE PUBLICA NA LM — DOCUMENTO ÚNICO E DEFINITIVO **Decidido pelo dono a 09/08/2026. Substitui TUDO o que foi escrito antes sobre publicação.** Se algum ficheiro antigo contradisser este, **este ganha**. Notas anuladas: "Buffer avariado" (falso — o Buffer publica bem, provado a 01/08 e 06/08; o que falhou a 08/08 foi o conector MCP, não o Buffer) · publicação pelo ASUS (**o ASUS deixou de ser usado para publicar**) · funnel manual no desktop (**substituído pela ponte Lenovo**). --- ## 1 · UMA ROTA POR CANAL — regra fixa, não se improvisa | Canal | Ferramenta | Identificador | Porquê esta e não outra | |---|---|---|---| | **Instagram** (reel + 2 stories) | **Buffer** | canal `6a402eab5ab6d2f1067c7536` | Fila de 10 slots que se renova — aguenta os 12 itens/semana do IG | | **TikTok** (vídeo) | **Metricool** | brand `6695614` | 20 posts/mês no plano free; 4/semana dá ~17/mês — cabe | | **Facebook** (reel) | **Composio** | página `1326814130505190` | Não tem quota nenhuma. **NUNCA gastar slots de Buffer ou Metricool com o Facebook** | **Fallback:** Composio (IG e FB) ou publicação manual (TikTok). **TikTok via Composio NÃO EXISTE** — exigia app de developer própria e auditoria. Abandonado, não se volta a tentar. ## 2 · A PONTE — Lenovo (bellatrix-node) Substituiu o funnel manual. **Está sempre ligada e sobrevive a reboots.** - Serviço systemd de utilizador `publish-bridge` — **http-server (npm)**, porta 8791, restart automático, linger ativo - Funnel permanente: **`https://bellatrix-node.tail321fa0.ts.net/`** - Pasta servida: `/home/lenovod/publish-bridge/media/` - Capacidade: 786 GB livres, 14 GB RAM (a biblioteca inteira são ~1,3 GB) **Pôr um ficheiro na ponte** (a partir do desktop): ``` scp "output/BIBLIOTECA//reel.mp4" "lenovod@bellatrix-node.tail321fa0.ts.net:~/publish-bridge/media/_reel.mp4" ``` O URL público fica imediatamente `https://bellatrix-node.tail321fa0.ts.net/_reel.mp4`. **Diagnóstico:** `systemctl --user status publish-bridge` e `tailscale funnel status`. ## 3 · O PACOTE POR CAMISOLA — modelo Herrera, provado 3× 1. **POST: reel** → Instagram (Buffer) **e** Facebook (Composio), com `LEGENDA_PUBLICAR.txt` 2. **STORY 1: grelha de 4 fotos** (`POST_CARROSSEL/02_capa_4fotos.jpg`) → Instagram **via Composio** 3. **STORY 2: o mesmo reel** → Instagram **via BUFFER** — **sempre DEPOIS da grelha** 4. **TikTok:** o reel com legenda curta própria → Metricool > ### ⚠️ REGRA DAS STORIES (aprendida a 10/08, à segunda tentativa falhada) > **Story de IMAGEM → Composio.** **Story de VÍDEO → Buffer.** > O container `STORIES` de vídeo do Composio falhou duas vezes seguidas com `ERROR` genérico no mesmo MP4 que o Buffer publicou à primeira. Não insistir no Composio para vídeo; não perder tempo a re-encodar. ## 4 · CALENDÁRIO `SISTEMA\CALENDARIO_PUBLICACAO.json` — **106 camisolas em fila, com rotação por clube**. - Cadência: **4 camisolas/semana** — segunda, quarta, sexta, domingo - Período: **10/08/2026 → 10/02/2027** (~6 meses de stock) - ⚠️ As últimas ~2 semanas são quase só Real Madrid (17 no inventário — inevitável no fim da rotação) - **Carregar o Buffer 2× por semana**: a fila de 10 slots não leva os 12 itens de IG da semana toda de uma vez ## 5 · REGISTO — obrigatório, sem exceção Cada publicação gera uma entrada em `SISTEMA\PUBLICACOES.json`: **canal + formato + permalink** (ou `media_id` nas stories). **Antes de publicar qualquer camisola, verificar se a pasta já lá consta.** Na dúvida sobre um permalink, a camisola conta como **PUBLICADA**. Foi a falta disto que causou o incidente de duplicação de 02/08. ## 6 · ARMADILHAS — todas custaram tempo real, nenhuma é teórica 1. **A ponte TEM de suportar Range requests (206).** O `python -m http.server` **NÃO SUPORTA** — foi isso que partiu os fetches do Meta a 09/08. O `http-server` do npm resolve. **Nunca voltar ao http.server do Python.** 2. A **1.ª chamada do Meta a um funnel novo falha** com *"Video could not be read from its URL"* (o certificado só é emitido no primeiro pedido externo). **Repetir uma vez e passa.** 3. Se o `_PUBLISH` do Instagram der **timeout**, **NÃO repetir o publish** — verificar primeiro com `INSTAGRAM_GET_POST_STATUS`; costuma já estar `PUBLISHED`. 4. **Containers do Instagram expiram em ~24h e são de uso único.** Se falhar, criar um novo — nunca reutilizar o `creation_id`. 5. O funnel **por caminho** (`--set-path`) exige admin do Windows e devolve 401. Na ponte Lenovo isto já não se aplica, mas fica registado. ## 7 · O QUE ESTE DOCUMENTO TORNA OBSOLETO - **`pipeline\publicar.py`** foi escrito a 09/08 de manhã para o mundo antigo: arranca `python -m http.server` local (armadilha nº1), publica IG por Composio em vez de Buffer, e não conhece o Metricool nem a ponte Lenovo. **Não usar como está** — ou se reescreve para esta estratégia, ou se publica pelas ferramentas diretamente. - **Sessão S6 (Voldemort/ASUS publicador)** — **CANCELADA**. O ASUS deixou de ser usado para publicar. - **Sessão S5 (calendário)** — **FEITA**. O `CALENDARIO_PUBLICACAO.json` já existe com as 106 camisolas. --- ## ATUALIZAÇÃO AUTORITATIVA — 13/08/2026 Esta atualização, decidida expressamente pelo dono, substitui os horários e a ligação antiga entre Reel e Stories: - Todos os posts de feed saem às **19:00**, `Europe/Lisbon`. - Os Reels e flashes de vídeo mantêm as datas já aprovadas no Lenovo. - Nos dias sem Reel/flash, sai um post estático **Before/After** às 19:00. - Há duas Stories de imagem **todos os dias**, às **10:00** e **12:00**. - Story de imagem e post estático Before/After passam pelo `lmpub` e pelo Composio; o `PUBLICACOES.json` continua a ser escrito apenas após sucesso. - O lote inicial é `LM_BA_V7_139_20260813`: 139 pares, 139 posts 4:5 e 139 Stories 9:16 aprovados pelo dono para o Lenovo. - A cópia autoritativa do calendário continua em `/home/lmpub/lm/estado/CALENDARIO_PUBLICACAO.json` no `bellatrix-node`. - A medição anterior das 21:00 fica encerrada. Reels, posts Before/After e Stories são medidos separadamente.