🤖 The End of Manual Labor (Autonomous Mode)
I’ve officially implemented Option 99 (Autonomous Mode). The engine now runs in a continuous loop,
watching for script files or backend signals. If a new idea hits the queue, the engine captures it,
renders it, and delivers the final video without me touching a single button. This is the foundation for
scaling production on mobile.

🎨 The “Absolute Cinema” Look (v1.6)
I wasn’t happy with “raw” renders. To give the videos a signature look, I added a post-processing layer
directly in the FFmpeg chain:

• Color Grading: Dynamic contrast and saturation boosts.
• Vignette Effect: That classic “cinema” dark-border focus that draws the eye to the center.
  The output now feels like a finished product, not just a test render.

🔊 Studio-Grade Audio (EBU R128)
Consistency is key. I implemented Audio Mastering (Loudnorm) to hit the industry standard of -14 LUFS
(the same used by YouTube and Spotify). No more videos that are too quiet or clipping—everything sounds
professional and balanced.

🧹 Clean House, Clean Mind
I did a deep cleanup of the GitHub repository. I used git rm –cached to strip away internal roadmaps
and simulation logs an tests of the pipeline. The public repo now holds only the pure Engine Core, keeping my portfolio sharp and focused on the code that actually matters.
P.S. Ieave the screen turn-off and paused the recording

Today was a major breakthrough for VOICE-TASK-MASTER (VTM). I transformed the entire interface into a retro-cyberpunk terminal and fully integrated the core voice engine.

Key Achievements:

• Neural UI Uplink: Implemented a high-contrast Neon Green aesthetic with CRT flicker and scanline effects.
• Voice Intelligence: Integrated the Web Speech API for real-time task management (Add, Remove, Clear).
• Redundant Grid Persistence: Added a secondary backup layer to chrome.storage to ensure zero-data-loss for mission-critical tasks.
• Audio Feedback: Synthesized AI status reports for daily briefings.

Technical Challenges:

Managing browser permissions for the microphone in a Chrome Extension popup was tricky, but I implemented a fallback to open the config in a new tab if access is denied.

Proof of Work:

I uploaded a preview of the UI (IMG_20260315_120436.jpg) and prepared the deployment package (extension_v1.0.1.tar.gz).

Next step: recording the final demo video and shipping the v1.0 version.

🚀 It’s Alive: Script to Video in One Click

the Factory just crossed the line from a “cool experiment” to a functional tool. The core engine is finally humming.

What’s new (and why it took a minute):

• No more CORS headaches: I moved all media generation (Gemini & Hugging Face) to the NestJS backend. It’s cleaner, safer, and supports automatic token rotation. If an API key hits a limit, the system just swaps to the next one without breaking the flow.
• Better Visuals (FLUX.1): Swapped generic images for FLUX.1-schnell. The pipeline now generates storyboards that actually match the script’s vibe instead of just “looking okay.”
• Clean Narration: Integrated Gemini’s native TTS. It’s producing crystal-clear audio that’s perfectly synced with the auto-generated captions (SRT).
• Built to last: The pipeline can now handle 7+ minute videos. I added smart batching and exponential backoff retries—so if an image service hiccups, the system fights to stay alive instead of just crashing.

Pivoting Study Lab into AstroLab: learning with real NASA data between lectures 🚀📚

Study Lab Core started as a general “learning playground” — notes, experiments, and some loose project scaffolding. When my Computer Engineering course started, my schedule got a lot more chaotic: 10 km commute, bus rides, homework, Blueprint hardware work, and then trying to study on top of that. Generic study tools didn’t feel motivating enough to survive that reality.
During the past weeks (mostly late at night and on weekends) I used Perplexity to explore a new direction: what if the study tool was space‑themed, powered by real NASA APIs, and could generate quizzes and flashcards from actual scientific data? That’s how AstroLab was born. The idea is simple but powerful: every day NASA publishes the Astronomy Picture of the Day (APOD) with a technical explanation — that’s an automatic, high‑quality prompt for learning.
The latest pivot commit wires this idea into the code: AstroLab now treats NASA + Gemini as the core “study ecosystem”. It pulls APOD, feeds the description into Gemini, and turns that into quizzes and flashcards grounded in real data (black holes, gravitational lensing, nebulae, whatever the APOD is that day).
This devlog also covers the repo restructuring I did earlier: splitting learning exercises from shippable projects, organizing devlogs, and preparing the codebase to be more than just a personal scratchpad. The goal is to make AstroLab feel like “study with the universe as your teacher” — even if I’m reviewing it from a crowded bus on the way to campus. 🌠🚌

Turning OmniLab into a real HUD assistant: voice, vision and a more proactive AI persona 🎧🖐️

OmniLab has been my experimental lab for interfaces: 3D HUD, hand‑tracking, voice input, and AI all living in the same space. At the same time, life got busier: I started Computer Engineering, the campus is ~10 km away, and I’ve been splitting my time between classes, Blueprint hardware projects, and these software labs. That’s why commits came in bursts instead of daily drips — most of the work happened in small, tired, late‑night sessions.
Earlier this year I refactored the architecture to favor local‑first vision (removing a cloud version that was too high‑latency) and added the Web Speech API to the HUD, so I could trigger Gemini analyses via voice while the system tracked my hands in real time. That was the turning point: OmniLab stopped being “just a cool 3D scene” and started behaving like a genuine interface between my body, my voice and an AI brain.
Recently I pushed a big “SHIP‑ready” upgrade: Gemini integration is now first‑class, tests and CI/CD are in place, and the HUD feels more stable as a product, not just a demo. On top of that, I refined the AI persona: instead of only answering direct questions, OmniLab now makes proactive observations about what it sees and hears — it can comment on the scene, suggest next actions, and feel more like a lab partner than a tool.

Most of this evolution happened while juggling buses, deadlines and other projects, with Perplexity helping me reason about trade‑offs (what to keep in 3D, what to simplify, where AI actually adds value). This devlog is my way of catching the Flavortown timeline up with the reality: OmniLab grew quietly, but it grew a lot. ✨

From idea to browser extension: hacking a voice‑first task manager 👾🎙️

Voice Task Master has been in the background since January — I started it as a simple idea for a voice‑powered todo tool, but only had the basic extension structure in place for a while. This week I finally sat down and turned it into a real Chrome MV3 extension with an opinionated UI and a shippable build.
The biggest jump happened in the latest sessions: I implemented a full cyber / hacker‑style UI for the popup, with dark monospace styling, CRT‑like visual details and a layout focused on fast capture (keyboard + voice). On top of that, I wired in voice synthesis so the extension can actually talk back when reading tasks or daily standups, instead of being just a silent checklist.

To make distribution easier, I also created a ready‑to‑install tarball for the extension and added a proper icon128.png, so it looks like a real product in the browser toolbar instead of a blank placeholder. This way, anyone can load it via chrome://extensions → “Load unpacked” or import the tarball directly when needed.
A lot of this happened in short bursts between college, buses and other Blueprint projects — I used Perplexity to quickly test small UI ideas, clarify WebExtension details and make sure the architecture stayed simple and local‑first. Now the plan is to iterate on features like a “Voice Standup” mode and calendar integration, but the core experience (talk → get tasks saved → hear them back) is already alive inside the browser. 🚀

From simple scraper to AI‑assisted matchmaker (while commuting between classes) 🚏💼

Opportunity Aggregator started in January as a very simple experiment: a Python bot, a SQLite file, and a basic TabNews parser. Then college kicked in, Blueprint deadlines appeared, and I found myself coding on short windows between bus rides and homework instead of doing long, focused sprints. That’s why the commit history shows an initial burst in January and then a big jump only now.

During that gap I spent more time thinking than committing: what makes this different from a fancy RSS reader? The interesting piece is the match score — using AI to tell you how well each opportunity fits your profile, instead of just dumping links. I used Perplexity a lot in this phase to explore architecture ideas: how many sources, how to model user profiles, how aggressive the AI usage should be, and how to keep things cheap and robust.
The latest commit is where all that background thinking finally lands in code: I implemented a Super MVP with a proper SQLite persistence layer and a multi‑tier AI fallback strategy (Gemini as the primary brain, with dynamic model discovery as a fallback) to score opportunities. The scraper stack now has a cleaner structure and is ready for more sources.

It’s still early, but now the project feels like an actual assistant instead of a script. Next steps: Telegram commands for /match and /today, plus a daily digest flow so it can ping me with the top 3 fits while I’m literally on the bus to college. 🚌✨

Balancing college, buses and FFmpeg: finally shipping an end-to-end video pipeline 🎓🚌

Over the last two months AI Video Factory was my “background process”. I had just started my Computer Engineering degree, and the campus is about 10 km from home, so most days were: bus → classes → bus → quick late-night coding sessions. On top of that I was also juggling Blueprint hardware projects, so I decided to work on this in focused bursts instead of constant tiny commits.

Most of the progress happened off-Git: I kept iterating on the FFmpeg pipeline, breaking it, fixing it, and using Perplexity as a kind of “technical rubber duck” to reason about filter graphs, error messages and timing issues. I didn’t want to push half-broken experiments all the time, so I waited until things felt structurally solid before committing.
In this latest round of changes I finally wired the full end-to-end pipeline: script → images → audio → video. I refactored image and audio generation into clearer modules and fixed a couple of nasty production issues: zoompan freezing on long chains, bad subtitle timing, and 503s during long renders. The solution involved rendering clips individually, using ffprobe for real audio duration, and switching to character‑weighted subtitle timing so the pacing feels natural.

I also hardened the Docker environment: proper SQLite permissions, config via env vars, and better logging through a global exception filter in the NestJS backend. Now, when something explodes, it explodes with logs instead of silently failing. 😅

This devlog is basically the “catch‑up chapter” for everything that happened between classes, buses and late‑night debugging. The next step is polishing the UI and shipping a public demo link.

what I did in two months (in the case of this project)

I haven’t posted a devlog for HOMES-Engine in about two months. Not because I wasn’t working on it — actually the opposite. I was heads-down testing, breaking things, fixing things, and Honestly sometimes just staring at FFmpeg error messages trying to figure out what went wrong. This is that story.

Where it started — Jan 4, day zero

The first commit was a proof of concept: a basic Python script that called FFmpeg and generated a video. That’s it. It barely worked. The font was wrong, the imports were broken, the output format was inconsistent. But it rendered something, which felt like enough to keep going.

In the same day I went from v0.1 to v1.3, v1.4, and v1.6 in rapid succession. Each version was fixing something the previous one broke: Edge-TTS for neural narration, multi-line text rendering (I kept getting those quadradinhos — encoding artifacts from special characters that took forever to track down), synchronized VTT subtitles, dynamic B-Roll stitching, music ducking. I was running all of this on Termux, on Android, ARM64. FFmpeg on ARM has its own quirks that aren’t documented anywhere useful.

The SAR bug that took too long

One thing that slowed me down more than anything else was a SAR mismatch error in ffmpeg_engine.py. When concatenating video clips, FFmpeg was crashing because different clips had different Sample Aspect Ratios. The fix was two FFmpeg flags: setsar=1 and format=yuv420p. Simple fix — once you know what it is. Finding it took hours of testing different inputs, reading logs, and using Gemini CLI to help me parse what the error stack actually meant.

I used Gemini CLI a lot during this phase. Not to write the code for me, but to help me reason through FFmpeg filter chains. FFmpeg’s filter syntax is its own language and when you’re building complex pipelines.

commit THE IMPORTANT
— feat(agent): status widget data export + automated Wakatime heartbeats and cry: ignore local status and logs

Title: HOMES Agent gets smarter: status export

Today I pushed two meaningful updates to the HOMES agent. First, I implemented status widget data export — the agent can now serialize its own state (telemetry, running modules) into a structured format that external dashboards can consume. This is the foundation for the HUD I’m building for OmniLab to talk to HOMES remotely.

Working on Android/Mobile is cool and interesting. I like understanding how the system’s API works (which is in Java. Currently, they use the Kotlin set for this). It’s difficult and a bit annoying; some simple errors and things break the system, but that’s just how it is.

I also cleaned up .gitignore to stop tracking local status dumps and log files that were polluting the repo. Small change, but it keeps the history clean.

For cli-problem-solver, I intentionally kept commits quiet for a while. I was figuring out what this tool should really do: just call an LLM, or also keep local memory, search previous solutions, and feel like a true “context co-processor” for my terminal.
During this time I prototyped different flows locally (no commits), tried a few CLI designs, and thought a lot about how to balance AI calls with a fast local experience. Perplexity helped me explore options and refine the idea before I locked anything into the repo.
Once I felt I had a decent mental model (commands, history, basic architecture), I started committing the structure in bigger, more meaningful chunks instead of tiny incremental updates.

Basically I updated the docs, improve the code and corrected the AI system in the application. I made her follow the specified language in the input.
I also deployed the functions (I forgot to make this…🫠)

I tried to edit the archives in GitHub web, but I get problems and errors. I learned to no use this for important and precision developments.
I think it is.

And for this devlog, because it is short and does not have many updates I make this so simple.

OmniLab Devlog #1

I’ve officially kicked off OmniLab on my first laptop! Coming from a background of mobile development and browser-based IDEs, my first instinct was to keep everything “off-device”. I spent a good chunk of these 5 hours attempting to run the processing stack on a remote VM (Firebase Studio) and tunneling the HUD via a web page. However, the latency was unbearable for real-time tracking. I quickly realized that for a “Jarvis-like” experience, the vision loop must be 100% local.

Technical Hurdles & Git Mess

The first challenge was MediaPipe. I started with legacy code, but it wouldn’t play nice. I had to dive into the latest MediaPipe Tasks API docs to rewrite the landmark detection core. It’s much more efficient now, but the documentation shift caught me off guard.

Since I was jumping between cloud editing and local testing without properly cloning the repo first, I ended up with a mess of Git conflicts. I used the Gemini CLI as a mentor to help me untangle the branches, resolve the “already exists” errors, and get the local and remote repositories back in sync. It was a great lesson in maintaining a clean workflow on a new machine.

Current Progress

I’ve successfully implemented the “pinch” gesture logic (calculating the hypotenuse between thumb and index) and set up a local FastAPI server to bridge vision data to a Three.js HUD. The HUD now runs locally on Debian 13 (XFCE), which eliminated all the lag from my previous VM tests.

Timelapses

• https://lapse.hackclub.com/timelapse/HZ9Th77AiSlD
• https://lapse.hackclub.com/timelapse/3jj1M0-cRWnF
• https://lapse.hackclub.com/timelapse/pW1dj8FJctPJ
• https://lapse.hackclub.com/timelapse/M0r9Eb8IoYF_

Título: Modularização Extrema, Rich CLI e a Grande Faxina no Flavortown
Data: 2026-02-25
Commits:

• 5ba3f12 — 🚀 REESTRUTURAÇÃO COMPLETA: O FLAVORTOWN AGORA É MODULAR! — 5ba3f12

Resumo: Adeus ao script único e bagunçado! Transformei o Flavortown em uma aplicação Python robusta, modular e visualmente incrível usando a biblioteca Rich para dominar o terminal.

O que foi feito:

• Arquitetura Modular (src/): Fiz o “de-coupling” total da lógica. O que antes era um emaranhado de funções no main.py agora está distribuído em módulos especializados:
  • src/ui: Toda a lógica de renderização e interação com o usuário.
  • src/quiz: O motor que controla o fluxo das perguntas e validações.
  • src/scoring: Sistema de cálculo e persistência de pontos.
  • src/problems: Gerenciamento dinâmico do banco de dados de desafios.
  • src/config: Centralização de constantes e caminhos do sistema.
• Centralização de Dados (data/): Criei uma “camada de persistência” real. Agora, questions.json e scores.json vivem em uma pasta dedicada, permitindo que eu adicione centenas de novos problemas sem precisar alterar uma única linha de código da lógica do quiz.
• Upgrade Visual com Rich: Implementei a biblioteca Rich para transformar a experiência de texto puro em algo profissional. Agora o Flavortown exibe as perguntas em painéis estilizados (Rich Panels), usa cores para indicar acertos ou erros e tabelas limpas para mostrar o desempenho. O terminal ganhou vida!
• Telemetria e Sync: Ajustei os utilitários de rastreamento para garantir que cada minuto codado no Termux seja computado corretamente pelo Wakatime/Hackatime. Corrigi bugs de pathing que faziam o tracker se perder durante a mudança para a estrutura src/.
• Refatoração e Limpeza: Removi arquivos temporários, templates HTML obsoletos do protótipo inicial e simplifiquei o ponto de entrada (main.py), que agora funciona apenas como o “orquestrador” do app.
  Ahh e a UX ficou até que interessante, o Rich Text CLI ajuda. 🙂👾

Devlog Atrasado

Período: 30 de Janeiro a 18 de Fevereiro de 2026

Tô escrevendo esse report retroativo agora pra botar a casa em ordem, registrar o que foi feito e poder shipar novamente o projeto, mas dessa vez com a certeza de que ele tá rodando liso. O foco desse ciclo foi basicamente transformar o gerador de roteiros em algo que realmente dá pra confiar.

O que realmente rolou nos bastidores

1. O problema da IA com dupla personalidade
O app tava com uma falha chata: se o usuário mandasse o input em inglês, mas as instruções da persona no backend estivessem em português, a IA se perdia e respondia no idioma errado ou misturava tudo.
A solução: Sentei e traduzi todas as descrições e regras de prompt das personas pro inglês no backend. Agora o “contrato” com a IA tá muito mais claro e ela obedece o idioma que o usuário pedir sem alucinar.

2. O maldito Case-Sensitive
O frontend tava mandando a persona escolhida como Default (com maiúscula) e o backend (CONFIG) só entendia default (minúscula). Isso fazia o sistema falhar silenciosamente ou cair num fallback genérico.
A solução: Forcei um .toLowerCase() nas chaves da persona. Básico, mas resolveu de vez a dor de cabeça.

3. Lição aprendida: não editar código pelo GitHub Web
Eu tava fazendo umas alterações rápidas direto pela interface web do GitHub e adivinha? Quebrei a sintaxe das cloud functions algumas vezes (crases erradas, aspas faltando). Além disso, as URLs de deploy mudaram e o app parou de conseguir falar com o backend.
A solução: Tive que fazer uns hotfixes urgentes pra arrumar os erros de sintaxe e atualizar os endpoints corretos de produção nas requisições.

Título: Crise no Lapse & O Panic Save Module

Data: 2026-02-01

Commits

• 93ec85c — Initial commit — (Base do projeto)
• Nota: Os ajustes de hardware do Panic Module estão em fase de roteamento no EasyEDA.

Resumo

Seis horas de Deep Work em hardware viraram um “filme de terror mudo” quando o upload do Lapse falhou. A frustração com o erro de IndexedDB (Rate Limit 429) motivou uma mudança radical: o projeto agora tem um botão físico de pânico para salvar o estado do sistema.

O que foi feito

• Investigação Técnica: Analisei os logs de rede no DevTools após o upload travar em 60%. Identifiquei um InvalidStateError causado por um Rate Limit (429) que corrompeu o banco de dados local durante o merge do WebM.
• Hardware-Level Backups: O Encoder (Hype Dial) agora tem uma função secundária via Python/Serial para controlar a frequência de backups locais.
• Panic Button: Adicionei um gatilho físico no design para forçar um git push e salvar o estado do projeto antes de qualquer instabilidade de conexão.
• Identidade Visual: Finalizei o banner no Canva para o projeto “The Nerve”, focando na estética “Absolute Cinema / Cyberdeck”.

Resultados / Status

O sistema agora é resiliente a falhas digitais. O que era para ser apenas um controlador de vídeo agora é uma ferramenta de sobrevivência hacker. O esquema elétrico foi atualizado para incluir o Panic Module.

Evidências e Timelapses

• Investigação Slack: Thread de Logs
• Desenvolvimento: Lapse 5nQGY4
• Fragmentos do Erro: Lapse 22PkPR | Lapse i0X9Le
• Design Canva: Lapse _twz4gb

O foco principal deste ciclo foi refatorar a arquitetura do HOMES Neural Deck para Autonomia de Engenharia. Eu decidi abstrair o Frontend (usando Framer para garantir o visual Cyberpunk que idealizei) para dedicar 100% da minha energia ao Backend (Firebase Cloud Functions) e à integração da API Gemini. Essa decisão garante que a lógica central, onde reside o valor real do projeto, é 100% código autoral.

[Hash: 3d16779] - Consolidação da lógica de orquestração do Gemini.
[Hash: d5e8f21] - Nova Estrutura de Pasta (web_page): Criação de um diretório dedicado para documentação visual e técnica. Incluí o Timelapses.md para documentar o processo de design fora do editor de código.
[Hash: a1b2c3d] - Gestão de Estado Reativa: Início da modelagem de dados para o Framer. Substituí a manipulação direta de IDs do DOM por um fluxo de dados JSON, preparando o “contrato” de comunicação com o Firebase Cloud Functions.

🧠 O que aprendi (Insights de Engenheiro)
Repositório como Prova Social: Entendi que a organização de pastas não é apenas estética. Ao criar a web_page/, estou criando um audit trail (rastro de auditoria). O Timelapses.md prova que o design evoluiu através de decisões humanas. Pra mim ter o processo do estilo e design da página.

O “Contrato” Cliente-Servidor: Ao integrar o Framer com o Firebase, tive um estalo sobre arquitetura: o Frontend e o Backend são como dois sócios. Eles não precisam saber como o outro trabalha por dentro, mas precisam de um “contrato” (payload JSON) bem definido. Isso libera minha criatividade no design sem quebrar a lógica robustaNque construí no backend.

Links das timelapses

https://lapse.hackclub.com/timelapse/L-DqtB-feWSw
https://lapse.hackclub.com/timelapse/BYUOzevQb1i3
https://lapse.hackclub.com/timelapse/ARkVL4dmqWPn

Título: O Nascimento do “The Nerve” – Hardware & Design
Data: 2026-01-29
Commits:

• 93ec85c — Initial commit

Resumo: O projeto ganhou vida! Saí do zero e finalizei a fase de design inicial do controle físico que vai comandar meu pipeline de renderização de vídeo por IA.

O que foi feito:

• Design Visual: Usei o Canva para criar o banner e definir a identidade visual “Cyberdeck / Absolute Cinema”. Queria algo que tivesse uma pegada tátil e futurista.
• Simulação (Wokwi): Antes de queimar qualquer coisa, validei a lógica do display OLED (SSD1306) via I2C no Wokwi com MicroPython. Tudo fluiu bem, garantindo que a comunicação está estável.
• Esquema Elétrico (EasyEDA): Desenhei o circuito usando um RP2040-PLUS. Adicionei um encoder rotativo (o “Hype Dial”) para ajustar parâmetros dos vídeos e um botão de trigger para disparar o pipeline.
• Otimização: Removi capacitores extras que seriam redundantes, já que a placa da Waveshare já cuida bem da filtragem de energia.

Resultados / Status:
O “gêmeo digital” do hardware está validado. O esquema passou no Netlist sem erros. Agora o projeto deixou de ser apenas software e tem um “corpo” planejado.

Próximos passos:

• Partir para o PCB Layout no EasyEDA.
• Criar um contorno de placa personalizado (não retangular) para manter a estética Cyberdeck.
• Começar a integração com o n8n/FFmpeg via USB.

Timelapses do progresso:

• EasyEDA: https://lapse.hackclub.com/timelapse/DWZLKkUoJHg_ e https://lapse.hackclub.com/timelapse/Bqq1dqeWwFCD
• Wokwi: https://lapse.hackclub.com/timelapse/MadKnTIJt5I7
• Canva: https://lapse.hackclub.com/timelapse/_twz4gbRkyeV e https://lapse.hackclub.com/timelapse/ltAJlJhr7JNe

Título: Estruturação Inicial e Simulação Wokwi
Data: 2026-01-28
Commits:

• eda9319 — feat: iniciando o repo e aproveitei e falei sobre um projeto que mexi hoje
• 507906f — refactor(structure): Organize monorepo for learning and projects

Resumo: Inicialização do repositório Study-Lab-Core e organização da estrutura de monorepo para separar exercícios de aprendizado de projetos reais.

O que foi feito:

• Criação do repositório core para centralizar estudos e projetos de hardware/firmware.
• Reorganização total da estrutura de pastas:
  • Logs de projetos movidos para a raiz.
  • Criado diretório /logs para notas gerais e registros de aprendizado.
  • Consolidado projeto ‘servomotor’ em /projects.
  • Criado diretório /learning para módulos de estudo focados.
• Atualização do diagram.json para refletir o setup atual no Wokwi.
• Adição de scratchpad.md para notas rápidas de desenvolvimento.

Resultados: Estrutura de diretórios limpa, escalável e pronta para novos módulos. Simulação no Wokwi funcional e integrada ao fluxo de commits.

• Timelapse da simulação no Wokwi: https://lapse.hackclub.com/timelapse/X8cyRSMCyUkt

Título: Setup Inicial, Faxina no Git e Integração com TabNews
Data: 2026-01-25

Commits:

• b966db7 — feat: implementa parser para buscar notícias do TabNews
• 89f8288 — chore: stop tracking venv and internal config files
• d41b700 — Criei o arq bot.py e estou me preparando para o primeiro Devlog :)
• af2779b — Iniciando o projeto com os primeiros arquivos
• a98014e — Initial commit

Resumo:
Iniciei o Opportunity Aggregator para centralizar chances acadêmicas e tech. O foco foi estruturar o ambiente, criar a base do bot no Telegram e implementar um parser para coletar dados reais via RSS. Este início foi um mergulho prático em bibliotecas novas e conceitos de versionamento.

O que foi feito:

• Estruturação: Configuração de .gitignore e requirements.txt para um ambiente organizado.
• Bot Base: Criação do bot.py com comandos /start e /ping usando ‘python-telegram-bot’.
• Parser RSS: Uso da lib ‘feedparser’ para extrair os 5 posts mais recentes do TabNews.
• Segurança: Uso do ‘python-dotenv’ para gerenciar o token do bot de forma segura.

Dificuldades e Aprendizado Ativo:
Enfrentei desafios logo de cara. Um erro comum foi subir a pasta ‘venv’ para o GitHub. Isso me forçou a aprender comandos avançados de Git, (não q vou lembrar muito, mas usei 🫡😁) como ‘git rm –cached’, para limpar o repositório sem perder os arquivos locais. Foi uma lição prática sobre o que não deve ser versionado.

Estou lidando com libs complexas como ‘python-telegram-bot’. Em vez de só copiar código, estou lendo a documentação para entender o “porquê” das coisas, como a lógica de funções assíncronas (async/await). A IA tem sido uma “Mentora”; ela explica a engrenagem por trás dos snippets, mas eu mesmo aplico e edito o código para garantir o aprendizado.

Resultados:
Bot operacional e parser extraindo dados reais com sucesso. Próximo passo: integrar o parser no comando /vagas do bot e iniciar os estudos com Supabase.

RESUMO
O objetivo central desta fase foi a estabilização definitiva da ponte entre o Frontend (GitHub Pages) e o Backend (Cloud Functions/Cloud Run). Enfrentamos desafios complexos de infraestrutura, especialmente no que diz respeito ao roteamento de rede e políticas de segurança cross-origin.

DETALHAMENTO DE COMMITS:

c6ae119 - Padronização de Runtime (Node 24)

Atualização estratégica da stack para Node 24 dentro do ambiente IDX. Esta mudança não é apenas estética; ela padroniza o motor de execução para as Cloud Functions, garantindo suporte às versões mais recentes de dependências e otimizando o consumo de recursos.

59bb7d8 - Estabilização e Autenticação IDX

Fase de correção de bugs na comunicação app-to-cloud. Resolvemos gargalos de autenticação específicos do ambiente IDX que causavam quedas de conexão. Implementamos um tratamento de cabeçalhos mais robusto, assegurando que o servidor identifique corretamente as requisições autorizadas, eliminando interrupções no fluxo de dados.

2e34eee / be3d67f - Migração para Endpoints de Produção

Realizamos o chaveamento das URLs de desenvolvimento (localhost/preview) para as URLs definitivas do Cloud Run. Este processo foi crítico para que o frontend hospedado no GitHub Pages passasse a interagir com o backend de alta disponibilidade, deixando de depender de simuladores ou mocks locais.

433ae50 - Refinamento de Roteamento (/gerarRoteiro)

Correção de pathing para evitar erros 404. Forçamos a inclusão explícita da rota /gerarRoteiro em todas as requisições de produção. Isso garante que o balanceador de carga do Google Cloud direcione o tráfego exatamente para a função de processamento de IA, evitando que requisições “morram” na raiz do serviço.

3d16779 - Resolução Definitiva de Bloqueios CORS

Ajuste fino na política de segurança de navegadores. Removemos o uso de credenciais (cookies/auth headers desnecessários) no método fetch do cliente.

RESUMO DA EVOLUÇÃO
Lançamento da v1.0.0 com foco em polimento de interface e documentação. Implementação de novas personas, toasts para avisos e sistema de TTS com realce sincronizado. O repositório foi reorganizado para suportar o backend inicial via Firebase Functions, isolando a lógica de geração de roteiros em um ambiente seguro. Preparação concluída para deploy serverless e upgrade na integração com Gemini API.

COMMITS

d7799 (01/jan) – chore(release): v1.0.0 Launch

Lançamento da versão estável. README reescrito com foco em branding e guia de uso. Polimento geral na UI com adição de badges e melhorias cosméticas. Marco oficial para avaliação técnica e divulgação.

da6d6 (19/jan) – feat: Novas features + organização

Reestruturação do projeto para uma arquitetura mais limpa.

• Personas (CONFIG.PERSONAS): Inserção de variações de tom e estilo (Científico, Dramático, etc).
• Toasts: Substituição de alerts comuns por notificações elegantes.
• Error Handling: Melhoria no tratamento de exceções.
• TTS Sync: Realce de texto sincronizado com a fala (highlight + scroll automático).
• UX: Botão de processamento com estado de loading.

4732f (19/jan) – docs: PROGRESS.md adicionado

Criação de um log de progresso para tracking de tarefas. Inclui progresso de prompts por persona, status do sincronismo de áudio e mapeamento de pendências técnicas (Firestore e Web Audio API).

72648 (19/jan) – Limpeza de diretórios

70cd4 (22/jan) – Segurança e Firebase Functions

• Segurança: .gitignore configurado para proteger .env e node_modules.
• Backend: Criação da pasta functions/ com index.js. Implementação da Cloud Function ‘gerarRoteiro’.
• Lógica: Integração com Gemini, tratamento de CORS, validação de inputs (topic/persona) e resposta em JSON.
• Infra: Controle de logs e custos via console do Firebase.

Neste ciclo, o projeto transicionou de uma ferramenta puramente client-side para uma arquitetura full-stack. O foco foi segurança de dados, UX defensiva e fundamentos de infraestrutura.

Principais Entregas
Lançamento v1.0.0: Marco de estabilidade com documentação técnica completa e branding “Neural Deck”.

Segurança de API: Implementação de Firebase Functions para encapsular a lógica do Gemini. Agora, a API Key não fica mais exposta no frontend — um padrão essencial de segurança em Engenharia de Software.

Interface e UX: Substituição de alerts genéricos por um sistema de Toast Notifications e implementação de seletor de Personas.

Sincronização TTS: Desenvolvimento de lógica para realce (highlight) de texto sincronizado com a síntese de voz (Text-to-Speech).

Histórico de Engenharia (Commits)
d779957 — chore(release): Launch v1.0.0. Lançamento oficial da versão estável. Reescrita do guia de uso e polimento de UI.

da6d636 — feat: Novas features e organização. Implementação do seletor de personas, sistema de Toasts em CSS puro e refatoração do tratamento de erros para leitura de corpo de resposta HTTP.

4732f7a — docs: PROGRESS.md. Implementação de rastreabilidade de tarefas. Adição de estados para futura integração com Web Audio API.

7264825 — refactor: Limpeza estrutural. Reorganização de diretórios e variáveis de estado para o visualizador de áudio.

70cd401 — feat: Backend & Firebase Deploy. Configuração de ambiente de deploy. Criação da Cloud Function gerarRoteiro utilizando o SDK @google/generative-ai (modelo Gemini Flash). Configuração de CORS e validação defensiva de inputs no servidor.

Título: Criação e Estruturação do Flavortown CLI Problem Solver
Commits:

• 3891434 — Reformulei o README com o link do design e tirei o projeto
• 1e3538c — chore: stop tracking .wakatime-project
• d1b0ec3 — chore: add .wakatime-project to .gitignore
• 9c2dabcf — chore: remove HTML design template and minor updates to main.py
• c647f39 — Initialize README with project details and instructions
• b0bb2a5 — refactor: reverte main.py para usar lista fixa (remove json)
• bc2d779 — feat: integra JSON de questoes e adiciona loop infinito

Resumo: Desenvolvimento inicial de um quiz CLI focado em lógica e programação, construído inteiramente em ambiente mobile (Termux/Acode).

O que foi feito:

• Implementação da lógica principal em Python (main.py) com sistema de quiz aleatório.
• Refatoração do banco de questões de JSON para lista interna para garantir portabilidade no MVP.
• Criação de sistema de validação de input com tratamento simples de strings (.lower() e .strip()).
• Design visual da identidade e landing page do projeto via Figma.
• Documentação completa do processo de desenvolvimento mobile e instruções de teste.
• Limpeza de arquivos de ambiente (.wakatime) e templates HTML obsoletos.

Resultados: CLI funcional operando via terminal, permitindo resolver problemas de lógica com feedback imediato. Design de interface concluído e documentado.

Próximos passos: Implementar sistema de pontuação acumulada, expandir o banco de perguntas e adicionar categorias de dificuldade.

Links do Projeto:
Design (Figma): https://www.figma.com/site/p8z5loosi9Lo5yZ4ayrYFp/CLI-Problem-Solver?node-id=0-1&t=Ds3KhPCdMtdeXuaJ-1
Timelapses (Hack Club):

• https://lapse.hackclub.com/timelapse/bn-VSIccCVrP
• https://lapse.hackclub.com/timelapse/X0uTiDgtooy5
• https://lapse.hackclub.com/timelapse/ngZbvjmv_t4y

Título: Melhorias de áudio, documentação e timeouts
Data: 2026-01-10

Commits (hashes):
3bb12a6 ee1f5e3 d3c80a4

Resumo:
Trabalhei em três frentes diretas após os commits 3dbbaf16 / be0f105a: áudio inteligente (ducking), atualização de documentação/testes e aumento de timeouts do servidor para reduzir erros 503 em renderizações longas.

O que foi feito:

• 3bb12a6 — Implementado Smart Ducking no pipeline de vídeo: agora a mixagem reduz automaticamente o volume da música de fundo quando a narração está ativa, com curvas de ganho suaves para evitar cortes abruptos. Adicionei testes unitários cobrindo a lógica de mixagem e validação de níveis RMS para garantir que ducking não degrade a fala. NÃO TESTADO!
• ee1f5e3 — Atualizei docs e refinei testes: status do projeto ajustado, casos de teste do VideoService/AIService ampliados e pequenas correções nos scripts de teste (mais mensagens claras nos asserts).
• d3c80a4 — Aumentei timeout do servidor para 15 minutos e confirmei timeouts longos no proxy do Vite; objetivo: reduzir timeouts 503 durante jobs de processamento de vídeo grandes.

Resultados:

• Experimentos locais mostram áudio mais claro em saídas com BGM + narração e transições sem artefatos.
• Testes automatizados fortalecidos (cobertura crítica mantida) — menos regressões ao ajustar mixagem/FFmpeg.
• Redução observada de falhas por timeout em runs manuais longos (a validar em CI).

Próximos passos:

• Rodar E2E com pipeline completo em CI (docker-compose) para confirmar estabilidade do timeout ampliado.
• Medir impacto do ducking em diferentes BGM (multi-gênero) e ajustar parâmetros padrão.
• Expor métricas de nível de áudio (RMS/peak) no VideoGateway para monitoramento em tempo real.

Data: 2026-01-09

Commits cobertos (hashes):
3dbbaf16 be0f105a

Resumo:
Após as melhorias de estabilidade e limpeza, foquei em tornar o projeto testável e executável em container. Adicionei testes unitários, preparei imagens Docker e corrigi problemas de execução no ambiente containerizado para garantir que o pipeline possa rodar localmente e em CI com consistência.

Detalhes por commit:

• 3dbbaf16 — feat: complete unit tests and docker configuration

  • Adição e correção de testes para VideoService, ProjectsService e AiService; cobertura acima de 60%.
  • Criação de docker-compose.yml e Dockerfile para o servidor; adição de .dockerignore.
  • Estrutura de containerização pensada para isolar banco (SQLite no container), serviços e facilitar builds locais/CI.
  • Objetivo: permitir execução reproducível do backend e integração com frontend via proxy.

• be0f105a — fix: Depuração completa e estabilização do ambiente Docker

  • Ajustes de permissões do arquivo de banco de dados para evitar erros de escrita em container.
  • Movi configuração do BD para variáveis de ambiente (melhor segurança e flexibilidade).
  • Resolvido conflito de dependência do Express que quebrava o container.
  • Limpeza de cache Docker para recuperar espaço e evitar builds corrompidos.

Impacto:

• Ambiente Docker agora inicializa de forma confiável e o backend executa com a mesma configuração esperada na CI.
• Testes unitários cobrem componentes cruciais do pipeline — reduz risco de regressões ao mexer em FFmpeg/IA.
• Menos atrito para colaboradores: com docker-compose é mais fácil replicar o ambiente localmente.

O que testar / próximos passos:

• Executar pipeline completo dentro do container (geração de script → TTS → imagens → assemble) para validar timeouts e recursos.
• Adicionar testes E2E que rodem em CI usando o docker-compose.
• Monitorar o uso de disco em runners/containers e automatizar limpeza de caches em pipelines.

DEVLOG - 08 JANEIRO 2026

RESUMO:
Nascimento do HOMES AI Agent e integração com a API do Termux para feedback de voz e tátil. O sistema agora não é apenas código, mas um assistente capaz de interagir fisicamente com o usuário através do Android.

ATIVIDADES:

1. Implementação do Agente Principal (homes_agent.py):
   • Substituição do antigo jarvis.py por uma estrutura mais robusta.
   • Integração com Termux TTS (Text-to-Speech) para notificações por voz.
   • Feedback tátil usando vibração do dispositivo em casos de sucesso ou erro.
2. Refatoração e Limpeza:
   • Limpeza de arquivos legados (generator.py e scripts antigos).
   • Otimização da estrutura de diretórios para o Hub Central.

COMMITS DO DIA (AUDIT TRAIL):

• 018f03a - feat: implement HOMES AI Agent with Termux API integration
• aae75c4 - feat: add jarvis.py for Termux voice feedback and cleanup legacy files

MÉTRICAS:

• Linguagem: Python / Bash
• Sistema: Termux (ARM64)
• Status: 🟢 Funcional

HOMES AI: “Sistema pronto para operação, Senhor.”

HAVIA ESQUECIDO DE ESCREVER NO SITE AQUI😅

Devlog - 07/01/2026: Hardware Assembly & Setup

Resumo:
Dia dedicado à estruturação física e infraestrutura do ecossistema. Montagem da estação
de trabalho mobile e do protótipo eletrônico que servirá de interface para as
funcionalidades de automação do HOMES.

🛠️ Workstation & Hardware

• Estação de Trabalho: Configurada para desenvolvimento 100% mobile (Termux/ARM64).
• Montagem do Circuito: Integração física dos componentes ao ESP32 para monitoramento
  e automação.
  • Sensores: DHT11 (Clima), MQ-2 (Gás), Ultrassônico (Presença).
  • Atuadores: Servos (Porta/Janela), Relé (Fan), LEDs de Status.

📌 Commits do Dia (Audit Trail)

• 8a41e67 - docs(devlog): add hardware assembly proof of work
• 50f32b4 - docs(devlog): add assembly video proof of work

📸 Proof of Work

• Fotos da Bancada: Registro do circuito montado e componentes conectados.
• Time Tracking: Sessões registradas no Toggl Track (comprovando dedicação entre 11:48
  e 12:22).
  AQUI SE VÊ O QUE JÁ HAVIA ENVIADO:
  https://github.com/EngThi/HOMES/blob/main/devlog/2026-01-07-hardware.md

Título: Robustez do Pipeline e Sincronia Audiovisual
Commits: 75f531a, 17c3a84

Resumo:
Foco em estabilidade do engine FFmpeg e precisão na sincronização áudio/legenda. Eliminamos travamentos de memória em vídeos longos e bugs de timing, além de limpar artefatos de tracking no repositório.

O que foi feito:

• Render por Clipe (75f531a): Fragmentação da cadeia monolítica do zoompan em etapas individuais. Imagens são processadas como clipes MP4 isolados e unidas via concat demuxer, evitando congelamentos de frame e estouro de memória.
• Sincronia via ffprobe (75f531a): Implementação de sondagem nativa de áudio no backend. Agora o sistema obtém a duração real do arquivo, corrigindo desvios causados por estimativas do frontend.
• Legendas Inteligentes (75f531a): Novo algoritmo de peso por caracteres (character-weighted). O tempo de cada legenda agora é proporcional ao tamanho do texto, resultando em leitura fluida e natural.
• Padding & Erros (75f531a): Adição de +5s de segurança no clipe final para evitar cortes abruptos. Criado filtro global de exceções para debug em server.log.
• Frontend Sync (75f531a): Detecção real de duração via Audio API (fim do placeholder de 60s) e inclusão automática de subtitles.srt no ZIP de saída.
• Limpeza (17c3a84): Normalização do .gitignore e remoção de arquivos temporários do tracking do Git.

Resultados:

• Fim dos travamentos de renderização em sequências longas.
• Legendas perfeitamente sincronizadas com a narração.
• Repositório limpo, focado apenas em código produtivo.

Testes:

• Montagem com mix de formatos (PNG/JPG) e áudios reais; verificação de saída MP4/SRT e integridade do ZIP.

Próximos Passos:

• Validar pipeline com cargas de 50+ imagens.
• Expor métricas via WebSocket para triagem em tempo real.

Título: HOMES-Engine 3.1 — Gemini TTS, Hybrid VTT & Integration Hardening

Commits:

• c1fb79a — feat(core): implement Gemini 2.5 Flash TTS engine with multi-speaker
  support
• 93cb143 — feat(video): integrate Gemini TTS with heuristic VTT generator
• 1e053f4 — feat(integration): align queue poller with AI-VIDEO-FACTORY API specs
• d5764e3 — chore(security): update gitignore for local simulation and fix poller
  paths

Resumo:
Sessão intensiva de upgrade da Engine para v3.1. Implementação nativa de Voz Neural
(Gemini), sistema de legendas sem timestamps e alinhamento total de segurança/API com o
backend de orquestração.

O que foi feito:

• Gemini TTS Nativo: Substituí o motor de voz antigo pela API v1beta do Gemini,
  habilitando vozes ultra-realistas (“Kore”, “Fenrir”).
• Legendas Híbridas (Math-based): Desenvolvi um algoritmo heurístico para gerar
  arquivos .vtt sincronizados, permitindo legendas visuais mesmo usando APIs de áudio
  puro (WAV).
• Poller de Integração: Implementei o worker que conecta ao AI-VIDEO-FACTORY,
  ajustando endpoints e payload para o spec oficial.
• Segurança: Blindagem do .gitignore para simulações locais e limpeza de artefatos.

Por que foi feito:
Elevar a qualidade cinematográfica dos vídeos (voz melhor) sem perder a acessibilidade
(legendas), enquanto preparo a infraestrutura para rodar de forma autônoma e segura em
produção.

Resultados / Status:

• Vídeos gerados agora possuem qualidade de estúdio (Demo no anexo).
• Worker pronto para testes E2E com o Backend NestJS.
• Ambiente local limpo e seguro.

O commit d977f4e marca a transição de protótipo para MVP full-stack. Implementei três pilares arquiteturais críticos para robustez e
UX:

1. Persistência de Dados (TypeORM + SQLite)
   Substituí a volatilidade do navegador por um banco de dados real.

• Backend: Implementação do ProjectsModule com operações CRUD completas (/api/projects).
• DB: homes.db (SQLite) gerenciado via TypeORM com sincronização automática de schema.
• Impacto: Usuários agora podem salvar, listar e retomar projetos anteriores. O estado persiste entre sessões e recargas de página.

1. Feedback em Tempo Real (WebSockets)
   Resolvi a “caixa preta” de processos longos usando socket.io.

• Arquitetura: VideoGateway no NestJS emite eventos de progresso (scriptProgress, videoProgress) para o frontend.
• UX: O usuário visualiza o pipeline exato: “Gerando Imagens (3/10)” -> “Renderizando (45%)” -> “Concluído”.
• Tech: Handshake otimizado com configurações CORS específicas para permitir comunicação Vite (5173) <-> NestJS (3000).

1. Centralização de IA (Backend-First)
   Movi 100% da lógica de IA para o servidor, eliminando exposição de chaves no cliente.

• Módulo: Novo AiModule encapsula geminiService.ts e serviços de TTS/Imagem.
• Fluxo: Frontend consome endpoints REST limpos (POST /api/ai/script), enquanto o backend gerencia quotas, retries e rotação de
  chaves de API com segurança.

Stack & Métricas:

• Novas Deps: @nestjs/typeorm, sqlite3, @nestjs/websockets, socket.io.
• Arquivos: +8 módulos principais (ai.module.ts, video.gateway.ts, project.entity.ts).
• Desafios Vencidos: Configuração fina de CORS para WSS e sincronização de entidades TypeORM em runtime.

Commits (hashes):
a673d30 até f83c967
Desde o ponto marcado por acc5ab9 concluí uma série de mudanças que transformaram a base em um pipeline mais resiliente e com melhor experiência de desenvolvimento. A ênfase foi em três frentes: (1) DX / Dev Mode para testes rápidos com pacotes ZIP, (2) orquestração e fallback de geração de imagens com processamento em batch, e (3) robustez do FFmpeg e infraestrutura backend.

O Dev Mode foi melhorado: upload de ZIPs agora extrai no cliente, auto-start do fluxo e carregamento automático de script, áudio e imagens locais para acelerar testes. No frontend ajustei o form (duração padrão, seleção de bg music) e introduzi processamento por lotes (batch) para geração de imagens — isso permite paralelizar requisições e aplicar fallback simples quando uma imagem falha, mantendo a ordem final. Acrescentei timeouts e fetchWithTimeout nas chamadas a provedores de imagem para evitar travamentos longos.

Na camada de imagem, o ImageGeneratorPro e a estratégia de rotação entre provedores foram reforçados para reduzir falhas por quota (Gemini → HF → StableDiffusion → Pollinations → Replicate). Também limpei guias e arquivos antigos, reorganizei .gitignore e adicionei ferramentas para reproducibilidade (Nix idx, rescue scripts).

No backend houve evolução significativa: adicionei um módulo Projects (TypeORM + SQLite) para persistir projetos; ampliei VideoService com geração SRT dinâmica, mixagem opcional de música de fundo, probe de duração de áudio, e um grafo de filtros FFmpeg mais robusto. As correções de FFmpeg continuam (stream normalization, mapeamento explícito, reset de PTS e aumento para 30fps), além de melhorias de erro/cleanup (remoção de SRT temporário, verificações de saída). Tempo de timeout do servidor e proxy estendido para suportar jobs longos.

Resultados: pipeline gera vídeos mais estáveis (30fps, sem drops), Dev Mode permite iteração rápida com assets locais, e a orquestração de imagens tolera quedas de provedores.

Título: HOMES-Engine — Iteração Studio & Estabilizações (sessão pós-v2.1)
Data: 2026-01-06
Commits:

• 2587dfe — feat(visuals): implement color conversion engine and update learning lab
• a8feb18 — feat(tts): set Google Gemini 2.5 TTS as primary engine
• 2d483ab — docs: add system architecture overview and update readme v3.0
• f868a70 — fix(ffmpeg): standardise SAR and pixel format for concat stability
• ae25fe9 — feat(v3.0): add Smart Assets (Image Gen) and experimental TTS via Pollinations.ai
• bfecd9f — refactor(arch): extract ffmpeg engine and improve audit tools

Resumo: Sprint focada em estabilidade do pipeline multimídia, promoção do Gemini TTS como engine principal e melhorias visuais programáticas para THEMES.

O que foi feito:

• Visuals: criado core/color_utils.py e refatorados temas para usar constantes RGB, permitindo paletas geradas dinamicamente.
• TTS: integrado Gemini 2.5 Flash TTS como prioridade; tts_engine atualizado com fallback limpo.
• FFmpeg: padronizado SAR e formato de pixel (setsar=1, format=yuv420p) para evitar erros de concat em ARM64.
• Arquitetura: extraído ffmpeg logic para core/ffmpeg_engine.py; melhor auditabilidade e verificação de segredos.
• Assets/IA: adicionado ImageGenerator experimental (Pollinations/FLUX) e scripts de verificação de configuração.

Resultados / status:

• Pipeline completo funciona em ARM (concat estável, ducking e VTT testados rapidamente).
• TTS principal configurado — testes de qualidade/latência pendentes.
• Documentação e guia de arquitetura atualizados (Readme v3.0).

Próximos passos:

• Parametrizar prompts do Gemini (controle de tom, gancho e extensão).
• Automatizar geração de paletas THEMES via color_utils.
• Criar testes end-to-end simulados (CI) para concat/ducking sem assets pesados.

Sugestões de anexos:

• Terminal.log com prova do render (setsar fix).
• Vídeo curto 10s mostrando tema + legenda + áudio Gemini.

DEVLOG DIA 1 - HOMES HUB INIT

Data: 5-6 Jan 2026 | Autor: EngThi | Repo: github.com/EngThi/HOMES

RESUMO

Hub central criado para ecossistema HOMES (4 repos).
Tempo: 10h45min | Commits: 10 | Status: 100% funcional

TIMELINE

5 Jan 23:56 - Commit b89aff2: README + scripts + estrutura
6 Jan 00:30 - Commit 42bcd55: architecture. md + strategy.md
6 Jan 00:32 - Commit a985689: LICENSE + .gitignore + .env.example
6 Jan 00:45 - Commit 2f64edb: setup-guide + integration-flow
6 Jan 10:16 - Commit 1c5f80d: 6 docs tecnicos completos
6 Jan 10:32 - Commit a41a397: Analise HOMES-Engine
6 Jan 10:36 - Commit 7b81434: GEMINI.md criado
6 Jan 10:41 - Commit 361e7c9: ROADMAP.md + . gitignore update
6 Jan 10:45 - Commit 2b05d3c: Devlog finalizado

METRICAS

Arquivos: 26 | Linhas doc: ~28k | Commits: 10 | Repos: 1/4

DECISOES

• Multi-repo (4 separados)
• HOMES = hub central
• ROADMAP: Engine -> Backend -> Frontend
• Devlogs em . txt

PROXIMOS

[ ] HOMES-Engine: api_client.py + queue_poller.py
[ ] ai-video-factory: Firebase + WebSocket
[ ] homes-prompt-manager: React + Voice

APRENDIZADO

• Doc economiza tempo depois
• Commits 30min ideais

• Tirar screenshots durante trabalho

STATUS: Hub completo. Proximo: Engine integration
Usei bastante o Gemini CLI para desenvolver, auditar e desenvolver as coisas, com base nas pesquisas e ideias da Perplexity que já tinha uma ideia com base em arquivos, ideias e um esqueleto simples que tinha.

Título: Inicialização do Voice Task Master
Data: 2026-01-05

Commits:

• 8de9eb0 — fefeat: add initial project files — https://github.com/EngThi/voice-task-master/commit/8de9eb08e08b9d61a2ac289c2d4ae289d92cf745

Resumo: Setup inicial do projeto estabelecendo a estrutura base para o MVP do gerenciador de tarefas por voz.

O que foi feito:

• Criação do index.html básico para interface inicial.
• Configuração do package.json com dependências e scripts de execução.
• Definição de .gitignore para limpeza do ambiente.
• Criação do HANDOFF.md e diretório de devlogs para documentação técnica.

Resultados: Ambiente de desenvolvimento configurado e estrutura de arquivos pronta para implementação das APIs de áudio.

Próximos passos:

• Implementar captura de voz utilizando a Web Speech API.
• Desenvolver a lógica de manipulação da lista de tarefas (CRUD básico).

Título: 🚀 Hardening the Core & Subtitles
Data: 2026-01-04

Commits:

• 00fdd58 — feat: stabilize dev environment and enhance video assembly with subtitles — https://github.com/EngThi/ai-video-factory/commit/00fdd58117d405c854c2dad535e3389bd94b3dc5
• f25bd5d — chore: stop tracking GEMINI.md (keep local only) — https://github.com/EngThi/ai-video-factory/commit/f25bd5d25f4ffb18cfd1c29be36168d9f6d1f183

Resumo:
Hoje trabalhei para estabilizar o pipeline e melhorar o suporte a vídeos com legendas automáticas. Também refinei o ambiente de desenvolvimento para evitar conflitos futuros.

O que foi feito:

• Legendagem Automática:
  • Gerador SRT dinâmico baseado no script gerado pela IA e timing do áudio.
  • “Queima” (hard-code) das legendas no vídeo usando FFmpeg, com estilo legível (fonte neon ciano + bordas pretas).
• Estabilização do Ambiente:
  • Agora o backend usa ffprobe para verificar com precisão a duração do áudio antes da renderização.
  • Otimized proxy e tempo de execução do dev server (Vite) para tarefas longas.
• Gerenciamento de Assets Locais:
  • Parou o versionamento de arquivos como GEMINI.md, mantendo-os locais apenas com exclusões no .gitignore.

Resultados:

• Vídeos agora podem ser gerados com legendas legíveis e sincronizadas.
• Ambiente Dev mais estável e otimizado para casos de uso local.
• Arquivos redundantes não comprometem mais o repositório principal.

Próximos Passos:

• Testar variados estilos de legendas para legibilidade em formatos diferentes.
• Finalizar suporte para mixagem de áudio de fundo no pipeline.
• Outras otimizações possíveis no fluxo de geração de legendas.

DevLog: HOMES-Engine v2.1 – AI Studio & Arquitetura Modular**
Data: 2026-01-05 | Horas Gastas: ~6h

🚀 Commits Principais

• 7d477d7 — feat(v2.1): Architecture Overhaul & Gemini AI Integration 🧠
• 7fecb45 — feat: Absolute Cinema v1.6 - Dynamic B-Roll & Sinc Subs
• 4402ddd — fix(core): Correct imports and asset management

📝 Resumo da Evolução

Reestruturei o motor para um modelo de Studio Modular. O foco saiu de scripts isolados para um pipeline integrado onde o Gemini atua como o “Cérebro” da criação, garantindo automação de roteiros e estética cinematográfica (Absolute Cinema) rodando 100% em ambiente mobile.

🛠️ O que foi implementado:

1. Arquitetura Core: Migração para estrutura modular (core/), isolando ai_writer, render e I/O. Isso permite escalabilidade e chamadas limpas da API do Gemini.
2. AI Writer (Gemini): Integração do núcleo de escrita. Agora, o motor gera roteiros estruturados a partir de tópicos simples, salvando o output em scripts/ para processamento imediato.
3. Visual Engine: Implementação de efeito Ken Burns (ZoomPan) e upscaling Lanczos. Adicionei suporte a THEMES configuráveis (JSON), permitindo mudar a estética do vídeo sem alterar o código.
4. B-Roll & Subs: Sistema de seleção dinâmica e randômica de clipes de apoio. Geração de legendas VTT sincronizadas com tratamento de escape de caracteres especiais.
5. Áudio Pro: Pipeline de mixagem com Audio Ducking (redução automática do volume da trilha durante a voz) e introdução musical de 2s para branding.
6. Otimização de Repo: Limpeza de arquivos pesados no Git, .gitignore reforçado e separação clara de assets/, renders/ e cache/.

📊 Status & Resultados

O v2.1 (AI Studio) já opera em Prova de Conceito (PoC): O fluxo Ideia → Gemini → Script → TTS → Render (720p) está funcional e automatizado. O repositório está leve, modular e estável.

🚀 Devlog: HOMES-Engine Genesis & Mobile Pipeline (v0.1)

O motor do HOMES-Engine começou a rodar! O foco inicial foi estabelecer uma pipeline funcional de “Ideia para Vídeo” rodando inteiramente em ambiente mobile (Termux), otimizando recursos para garantir que a renderização não “frite” o processador do celular.

🏗️ Mudanças Técnicas:

• Genesis da Pipeline (Termux + FFmpeg):

  • Implementação do video_maker.py, um core de renderização otimizado para Android. Utiliza o preset ultrafast do libx264 e crf 28 para equilibrar velocidade e qualidade em dispositivos móveis.
  • Criação do main.py focado em automação via Termux API. O sistema agora captura ideias via Voz (Speech-to-Text) ou Clipboard, injeta diretrizes de branding (“Absolute Cinema”) e gera prompts prontos para o Gemini.
  • 9550b44 - 🚀 INIT: Genesis of HOMES-Engine

• Refinamento de Core & Identidade Visual:

  • Fix de Importação: Corrigidos typos críticos no main.py que impediam a execução do script no ambiente Python do Termux.
  • Assets de Marca: Adição da fonte Montserrat-ExtraBold na pasta assets/. Ela agora é injetada via filtro drawtext do FFmpeg para garantir que as legendas tenham impacto visual cinematográfico.
  • 4402ddd - fix(core): correct import in main.py and add assets

💡 Por que isso importa?

Diferente de editores pesados, o HOMES-Engine é focado em headless production. A modularidade do main.py permite que o roteiro gerado seja salvo localmente e enviado automaticamente para o clipboard, agilizando o workflow de criação de vídeos faceless sem sair do terminal.

Status: PoC validada. Próximo passo: Automação da montagem de B-Rolls. 🚢🔥

Hoje realizei grandes avanços no projeto HOMES: Neural Deck, criando e refinando funcionalidades cruciais para sua versão inicial. Cada passo foi pensado para entregar uma experiência única e imersiva ao usuário. Aqui estão as atualizações construídas:

Commits e mudanças recentes:

1. Text-to-Speech e visualização de áudio
   Commit: Add native Text-to-Speech (TTS) with audio visualizer and final polish (v4.0)

• Adicionado: Um Text-to-Speech nativo no navegador, permitindo que os usuários ouçam os roteiros gerados.
• Estética aprimorada: Visualizador de áudio animado em CSS, sincronizado com a fala.
• Código organizado com atenção à experiência do usuário (UI & UX).

1. Integração com API Gemini e gestão de histórico
   Commit: Implement Gemini API integration and local history storage (v3.0)

• Gemini 2.5 Flash API: Integrei a API para gerar roteiros otimizados, estruturados, e cinematográficos.
• Histórico Local: Agora os roteiros gerados são salvos automaticamente no localStorage, acessíveis pela interface do “Memory Bank”.
• Melhorias no layout: Interface dividida em duas colunas para facilitar a navegação do usuário.

Reflexões e aprendizado

• Revisei o ciclo de desenvolvimento com integração de APIs grandes como a Google Gemini, aprendendo melhor sobre autenticação e manipulação eficiente de dados retornados.
• A otimização do Text-to-Speech e seu visualizador CSS foi um exercício incrível de mesclar tecnologia de voz com design dinâmico.
• Adotei práticas mais rigorosas de organização de código, documentação e testes, assegurando um produto final funcional e polido.

🛠️ O que foi construído hoje
De acordo com os commits mais recentes no repositório:

1. Integração da API Gemini para geração de roteiros
   Commit: Implement Gemini API integration and local history storage (v3.0)

Conexão direta com a API Gemini, que agora gera roteiros otimizados com:
Hooks iniciais para capturar a audiência.
Dicas de B-rolls e efeitos sonoros.
Interface reorganizada em um design de duas colunas, permitindo que o usuário veja os prompts e o histórico ao mesmo tempo.
Criado o recurso Memory Banks: uma barra lateral que salva e organiza os roteiros, usando localStorage.
2. Adição da funcionalidade Text-to-Speech (TTS)
Commit: Add native Text-to-Speech (TTS) with audio visualizer and final polish (v4.0)

Voz para os roteiros: Agora o usuário pode ouvir os roteiros gerados no navegador.
Incluído um visualizador de áudio animado em CSS, que sincroniza com a reprodução do texto, dando vida ao conteúdo.
3. Preparação e Lançamento da Versão 1.0
Commit: Launch v1.0.0 - The ‘Neural Deck’ Update 🚀

Polimento final em toda a interface: toque de futurismo, acessibilidade e responsividade.
Atualizações no arquivo README.md, com instruções para utilização do projeto.
Publicação como Versão 1.0.0, marcando a conclusão do ciclo inicial de desenvolvimento do projeto.

O que eu shippei:

1. Dynamic Motion (Ken Burns): Vídeos estáticos são chatos. Implementei filtros complexos no FFmpeg (zoompan, crop, scale) para dar
   movimento (pan & zoom) automático a todas as imagens geradas pela IA. Agora parece um documentário real, não um slide de
   PowerPoint.
2. Robust Image Orchestrator: O pipeline estava quebrando quando a API do Gemini dava rate-limit. Criei um sistema de Fallback em
   Cascata: se o Gemini falhar, ele tenta HuggingFace, depois Stable Diffusion, Replicate e finalmente Pollinations. O vídeo sempre
   sai.
3. DX (Developer Experience): Testar pipeline de IA é caro e lento. Criei um “Dev Mode” que injeta assets locais (ZIP) direto no
   pipeline, pulando as chamadas de API. Isso acelerou meu ciclo de testes de 2 minutos para 10 segundos.

Stack: React + NestJS + FFmpeg + Gemini 2.5 Flash.

Novas atualizações shippadas:

1. Instant ZIP Pipeline: Implementei um sistema de “Auto-Start”. Agora, ao selecionar um arquivo ZIP com assets pré-gerados, o
   sistema detecta os arquivos, faz o upload e inicia a montagem do vídeo automaticamente. Menos cliques, mais velocidade. ⚡
2. Smart Validation Bypass: Removi a obrigatoriedade de inputs de IA (como o tópico do vídeo) quando o Modo Dev está ativo. O sistema
   entende que os assets locais são a “única fonte da verdade”, limpando a interface de campos desnecessários.
3. Local Asset Mapping: Melhorei a lógica de extração no backend para garantir que, independente de como o ZIP foi estruturado, o
   pipeline localize corretamente o script, áudio e o storyboard.
4. GitHub Push Protection: Tivemos um pequeno susto com um segredo detectado pelo GitHub, mas resolvi via git reset e reescrita de
   histórico para manter o repositório seguro e limpo. 🔒

O que foi feito hoje:
Integração com múltiplos provedores de imagem ( 4816e90):

Adicionado suporte para Gemini Imagen 3 , Hugging Face , Stable Diffusion , Craiyon e Replicate .
Criado o componente ImageGeneratorPropara geração avançada de imagens.
Adicionadas novas bibliotecas e atualizações de serviços auxiliares ( pollinationsService.tse imageService.ts).
Melhoria na interface do usuário ( 6d24499):

Substitui o controle deslizante de duração pela entrada de valores numéricos e predefinidos, simplificando o uso.

Hoje foi um dia crucial na configuração final do AI Video Factory , meu projeto para o Flavortown.
Concluí configurações importantes para garantir que toda a estrutura do pipeline seja funcional, desde a entrada de dados até a geração automatizada de vídeos.
TRABALHEI EM ALGUMAS COISAS MAS ESQUECI DE GRAVAR O PROGRESSO. É MAIS OU MENOS ISSO QUE FIZ.

Usei o Gemini CLI para me dar me guiar e ir desenvolvendo as coisas enquanto organizava.

O que foi realizado hoje:
Configuração inicial e documentação ( a673d30):

Ajustei a base do projeto, garantindo que tanto o backend quanto o frontend estejam funcionando em harmonia.
Atualizei o README.mdpara incluir:
Guia completo de instalação local com suporte ao Docker.
Passo a passo sobre o uso do pipeline de automação.
Documentação detalhada dos endpoints da API de IA (geração de roteiro, visual e narração).
Estrutura do projeto e refinamento para o Flavortown ( 7b536d71, 6eda3fba):

Organizei melhor a estrutura de pastas e otimizei a configuração do Dockerfile para evitar conflitos no ambiente de execução.
Corrigidos pequenos bugs encontrados durante os testes de build do Docker e execução local.
Correção de erros durante os testes ( 6a03c43f):

Ajustei variáveis ​​de ambiente no .env.examplepara facilitar integrações futuras.
Solucionei problemas com as dependências relacionadas ao FFmpeg e integração com a API Gemini .

Hoje avancei na estruturação do projeto AI Video Factory para o Flavortown!

Conquistas de hoje:

Estrutura inicial: Organizando pastas para Backend (NestJS) e Frontend (React + Vite).
Configuração: Adaptei variáveis ​​de ambiente e integrais ao FFmpeg ao pipeline.
Documentação: Completo README.mdcom o diagrama do pipeline e instruções para rodar o projeto.
Próximo passo: Finalizar a integração de scripts e narração para gerar o primeiro vídeo automaticamente!
Commits de Ontem (27 de Dezembro de 2025):
76329a9- Revise o arquivo README com detalhes do projeto e instruções de configuração.

O que foi feito:
Atualização completa do README.md:
Resumo do projeto
Recursos e pilha tecnológica usados
Passo a passo para instalação e configuração
Pipeline do projeto do início ao fim
Documentação dos endpoints da API
ff55797- Primeiro envio dos arquivos

O que foi feito:
Subida inicial do projeto:
Estruturação básica de pastas e arquivos.
Subiu o esqueleto do frontend e backend.
Incluiu arquivos como Dockerfile, .env.example, .gitignore.
Compromisso de Hoje (28 de Dezembro de 2025):
a673d30- Tarefa: configuração inicial do projeto e documentação para Flavortown
O que foi feito:
Ajustes finais para a configuração do projeto.
Melhorias na documentação, adaptando o projeto para o concurso Flavortown.
Preparação de ambiente local e explicação para desenvolvedores externos.

O que foi feito: Ontem foi o “Big Bang” do projeto AI Video Factory. Eu foquei em estabelecer toda a fundação técnica para transformar um tópico qualquer em um vídeo completo para o YouTube de forma automatizada.

Destaques técnicos dos commits:

Subi os arquivos base do que espero ser o projeto. Sendo a estrutura base de tudo o que vou desenvolver.

Documentação e Setup: Finalizei o dia revisando o README.md com todos os endpoints da API (ideação, script, narração, montagem) e as instruções de setup via Docker, garantindo que o projeto seja replicável e “shipável” — bem no espírito do Flavortown.

Commit ff55797 (First push of the files):
Subiu o “coração” do projeto.
Estrutura de pastas separando Frontend e Backend.
Configuração de ambiente (.env.example) e arquivos de container (Dockerfile).
Commit 76329a9 (Revise README with project details):
Detalhamento da Pipeline Architecture.
Exposição dos endpoints /api/ai/ e /api/assemble.
Guia de instalação completo para quem quiser testar a “fábrica”.