Develop

.github/workflows/multilingual.yaml

@@ -34,3 +34,6 @@ jobs:
 
       - name: Test native multilingual behavior
         run: bundle exec ruby scripts/test_multilingual.rb
+
+      - name: Build published and draft content
+        run: hugo --buildDrafts --buildFuture --minify --destination "${{ runner.temp }}/hugo-content-check"

content/docs/2026/julho/refactor-blog/index.en.md

@@ -151,3 +151,9 @@ First I requested an analysis through claude.ai, then wrote the following instru
 
 - For `.AGENTS.md`, with a leading dot, I used the standard `AGENTS.md` convention at the root, the name agent tools recognize, plus an `.agents/` folder for persistent setup.
 - The PR targeted **develop**, the repository's default branch, in four thematic commits.
+
+---
+
+### How did it turn out?
+
+I was still using Notion, but wanted to extract all the text and keep it in my own repository. That started the migration to a different layout: the [Hextra template](https://themes.gohugo.io/themes/hextra/). I used AI to migrate the posts first. Since Notion can export Markdown files, moving everything at once was simpler. Then I configured the new template, added the features I wanted, and adapted its cleaner, simpler layout. This continues in “Refactoring the blog — part 2”, which is still a draft.

content/docs/2026/julho/refactor-blog/index.md

@@ -151,3 +151,11 @@ Primeiro foi solicitado para realizar uma análise utilizando o claude.ai, segui
 
 - `.AGENTS.md` (com ponto): usei a convenção padrão `AGENTS.md` na raiz (é o nome que as ferramentas de agente reconhecem) + a pasta `.agents/` para o setup persistente.
 - O PR foi aberto contra **`develop`** (branch padrão do repo), em 4 commits temáticos.
+
+---
+
+### Como tudo ficou?
+
+Como ainda eu estava dentro da plataforma do Notion, e eu gostaria de extrair todos os textos dele e ficar em um repositório meu
+resolvi então a saga para migração de posts do blog para outro Layout que encontrei que é este [template Hextra aqui](https://themes.gohugo.io/themes/hextra/). Resolvi com uso de IA fazer a migração dos posts primeiro então como o Notion tem a opção de extrair arquivo.md é mais simples fazer tudo de uma única vez. Após isso, foi configurar este novo template e adicionar funcionalidades que eu gostaria, e também
+aplicar no layout que é, mais limpo e simples, coisas que eu gostaria. Esta saga continua no post “Refatorando o Blog parte 2”, ainda em rascunho.

content/docs/2026/novembro/criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados.en.md

@@ -0,0 +1,59 @@
+---
+title: "Building a portfolio website and organizing the work I have done"
+date: 2026-11-06
+slug: criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados
+tags: [portfolio, engenharia-de-software, testes, documentacao]
+draft: false
+---
+
+## Building a portfolio website and organizing the work I have done
+
+Recently I started organizing my portfolio in a way that would help me present my work more clearly. I wanted more than a list of technologies or repository links. I also wanted to explain what I did, how I organized the stages, and what evidence is available to check each contribution.
+
+The project is on GitHub: <https://github.com/kellen-xavier/ladydebug-workstation>. The published version is available at <https://kellen-xavier.github.io/ladydebug-workstation/>.
+
+## What I wanted to organize
+
+Throughout my career, I have worked in support, frontend development, mobile and backend applications, testing, and documentation. Some of that work took place in private repositories, so it is not always possible to show the code or reproduce a run through a public link alone.
+
+That is why I am organizing the accounts to distinguish what was implemented, what appears in the available records, and the limits of each piece of evidence. An implementation described in a report does not, by itself, mean that every scenario was executed or that a pipeline was published. I want readers to be able to see that distinction.
+
+## A website with several pages
+
+The site is a static application built with React and TypeScript. Instead of creating one long page with every subject mixed together, I divided the navigation into pages for my career, contributions, workflow, setup, tools, and games. The homepage works as a map to reach those sections. This map is still in development, as I would like a layout inspired by Stardew Valley.
+
+For the visual design, I used a retro workstation reference, with cream, beige, brown, and pink tones and a pixel art illustration. I wanted the identity to connect with my Ladydebug blog while keeping the focus on reading and the work presented.
+
+In the **In practice** section, each contribution can be opened to read its account and references. Public projects also link to their repositories. This keeps the content in one place while giving each subject its own context.
+
+## Content separated from components
+
+An important decision was to move long texts out of the components. The introduction, about section, career history, and project accounts live in Markdown files inside `src/content/`. Components handle the page structure, and content can be edited without changing the layout. Keeping those responsibilities separate made more sense than hardcoding text into components.
+
+For the accounts, I use Markdown with headings, paragraphs, lists, links, and references. The `react-markdown` library turns that content into page elements. Local images can also be referenced in Markdown; the build process packages the files and generates paths that work on [GitHub Pages — see the repository here](https://github.com/remarkjs/react-markdown).
+
+Information with a predictable structure stays in TypeScript. Workflow stages and project data, for example, need an order, identifiers, descriptions, and links. Keeping that data typed helps reveal inconsistencies during development.
+
+This division also makes maintenance easier: editorial content stays in Markdown, data feeding cards and stages stays typed, and components are responsible for presentation.
+
+## The workflow is part of the portfolio too
+
+I included a page to record how I usually work. The flow involves understanding the context, building and testing, reviewing evidence, and following up on what needs to improve. The idea is to show some of the decisions and practices behind the deliveries, as well as the final result. I reached this approach through analysis, gathering information, applying tests, and validating the results.
+
+I also organized examples of tools and setup, along with a list of game studies. These sections reflect the subjects I follow and help show how I organize my environment and keep learning. They also include my experience with the Arch Linux-based system [Omarchy](https://omarchy.org/).
+
+## Testing and publishing
+
+The project has unit tests and browser tests with [Playwright](https://playwright.dev/). In the browser tests, I am prioritizing behaviors someone can perform: navigating between pages, opening an account, following an anchor, downloading a file, copying a command, and filtering the games list. I also check layout behavior at different widths, such as horizontal scrolling and touch target sizes.
+
+I organized the E2E tests into separate files by flow, including navigation, home, career, accounts, workflow, tools, and responsiveness. That makes it easier to locate a scenario and understand which part of the site it covers. The tests validate features and interface states without comparing the wording of editorial texts.
+
+The site is generated as [static files and published through GitHub Pages](https://github.com/kellen-xavier/ladydebug-workstation/blob/main/.github/workflows/pages.yml). The pipeline runs lint, type checks, tests, and browser tests against the production build before publishing the main branch version.
+
+## What I am still learning
+
+Building this portfolio is also helping me think about presenting technical experience clearly. I need to choose which details help explain a contribution, which links are useful, and where to state limitations instead of making claims that go beyond the available records.
+
+I still want to review the accounts and keep improving navigation and readability on smaller screens. The structure already lets me update each part more independently: I can adjust Markdown text, reorganize a project in the typed data, or improve a component without rewriting the whole site.
+
+The goal is to keep this space as a living record of my work and studies, with ways to check what is public and enough context to understand the rest.

content/docs/2026/novembro/criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados.md

@@ -0,0 +1,59 @@
+---
+title: "Criando um site portfolio - E como estou organizando os trabalhos realizados"
+date: 2026-11-06
+slug: criando-um-site-portfolio-e-como-estou-organizando-os-trabalhos-realizados
+tags: [portfolio, engenharia-de-software, testes, documentacao]
+draft: false
+---
+
+## Criando um site portfolio - E como estou organizando os trabalhos realizados
+
+Recentemente comecei a organizar meu portfólio de um jeito que me ajudasse a mostrar melhor os trabalhos que venho realizando. Não queria deixar somente uma lista de tecnologias ou links para repositórios. Também queria explicar o que foi feito, como organizei as etapas e quais evidências existem para conferir cada contribuição.
+
+O projeto está no GitHub: <https://github.com/kellen-xavier/ladydebug-workstation>. A versão publicada pode ser acessada em <https://kellen-xavier.github.io/ladydebug-workstation/>.
+
+## O que eu queria organizar
+
+Ao longo da minha trajetória, trabalhei com suporte, desenvolvimento frontend, aplicações mobile e backend, testes e documentação. Parte desse trabalho aconteceu em repositórios privados, então nem sempre é possível mostrar o código ou reproduzir uma execução apenas com um link público.
+
+Por isso, estou organizando os relatos para separar o que foi implementado, o que aparece nos registros disponíveis e quais são os limites de cada evidência. Uma implementação descrita em um relatório não significa, por si só, que todos os cenários foram executados ou que um pipeline foi publicado. Quero deixar essa diferença visível para quem estiver lendo.
+
+## Um portfólio com várias páginas
+
+O site é uma aplicação estática feita com React e TypeScript. Em vez de montar uma única página longa com todos os assuntos misturados, separei a navegação em páginas para trajetória, contribuições, workflow, setup, ferramentas e games. A página inicial funciona como um mapa para chegar a essas partes. (Este mapa ainda está em desenvolvimento pois eu gostaria de algo no layout de Stardew Vallew)
+
+Na parte visual, usei uma referência de workstation retrô, com tons de creme, bege, marrom e rosa e uma ilustração em pixel art. Queria que a identidade tivesse relação com o meu blog Ladydebug sem tirar o foco da leitura e dos trabalhos apresentados.
+
+Na seção **Na prática**, cada contribuição pode ser aberta para consultar o relato e as referências. Os projetos públicos também levam aos respectivos repositórios. Assim, o conteúdo fica em um mesmo lugar, mas cada assunto tem seu próprio contexto.
+
+## Conteúdo separado dos componentes
+
+Uma decisão importante foi retirar os textos longos dos componentes. Apresentação, sobre, trajetória e relatos ficam em arquivos Markdown dentro de `src/content/`. Os componentes cuidam da estrutura da página e o conteúdo pode ser editado sem alterar o layout. Foi melhor deixar tudo isso separado, não tem o menos cabimento deixar harded code os textos nos componentes.
+
+Para os relatos, uso Markdown com títulos, parágrafos, listas, links e referências. A biblioteca `react-markdown` transforma esse conteúdo em elementos da página. Imagens locais também podem ser escritas no Markdown; o processo de build empacota os arquivos e gera caminhos que funcionam no [GitHub Pages veja o repositório aqui](https://github.com/remarkjs/react-markdown).
+
+Já as informações que têm estrutura previsível ficam em TypeScript. Por exemplo, etapas do workflow e dados dos projetos precisam de ordem, identificadores, descrições e links. Manter esses dados tipados ajuda a perceber inconsistências durante o desenvolvimento.
+
+Essa divisão também facilita a manutenção: conteúdo editorial fica no Markdown, dados que alimentam cartões e etapas ficam tipados e os componentes ficam responsáveis por apresentar tudo.
+
+## O workflow também faz parte do portfólio
+
+Incluí uma página para registrar como costumo trabalhar. O fluxo passa por entender o contexto, construir e testar, revisar as evidências e acompanhar o que precisa evoluir. A ideia é mostrar um pouco das decisões e práticas por trás das entregas, não apenas o resultado final. Exemplo como cheguei nessa lógica, foi analisando, fazendo o levantamento, aplicando testes, validando.
+
+Também organizei exemplos de ferramentas e setup, além de uma lista de estudos sobre jogos. Esses blocos fazem parte dos assuntos que acompanho e ajudam a mostrar como organizo o ambiente e continuo aprendendo. E também minha tragetórica com o sistema baseado no Arch Linux o [Omarchy](https://omarchy.org/)
+
+## Testes e Publicação
+
+O projeto tem testes unitários e testes de navegador com [Playwright](https://playwright.dev/). Nos testes de navegador, estou priorizando comportamentos que alguém consegue executar: navegar entre páginas, abrir um relato, seguir uma âncora, baixar um arquivo, copiar um comando e filtrar a lista de jogos. Também verifico aspectos de layout em larguras diferentes, como rolagem horizontal e tamanho dos alvos de toque.
+
+Organizei os testes E2E em arquivos separados por fluxo, como navegação, home, carreira, relatos, workflow, ferramentas e responsividade. Isso deixa mais fácil localizar um cenário e entender qual parte do site ele cobre. Os testes validam funcionalidades e estados da interface, sem comparar a redação dos textos editoriais.
+
+O site é gerado como [arquivos estáticos e publicado pelo GitHub Pages](https://github.com/kellen-xavier/ladydebug-workstation/blob/main/.github/workflows/pages.yml). A pipeline executa lint, verificação de tipos, testes e testes de navegador sobre o build de produção antes de publicar a versão da branch principal.
+
+## O que ainda estou aprendendo
+
+Montar esse portfólio também está me ajudando a pensar sobre como apresentar experiências técnicas com clareza. Preciso escolher quais detalhes ajudam a entender uma contribuição, quais links são realmente úteis e onde é necessário indicar limites em vez de fazer uma afirmação maior do que os registros permitem.
+
+Ainda quero revisar os relatos e continuar melhorando a navegação e a leitura em telas menores. A estrutura já me permite atualizar cada parte com mais autonomia: posso ajustar um texto no Markdown, reorganizar um projeto nos dados tipados ou evoluir um componente sem precisar reescrever o site inteiro.
+
+O objetivo é manter esse espaço como um registro vivo do meu trabalho e dos estudos, com caminhos para conferir o que está público e contexto suficiente para entender o restante.

content/docs/2026/novembro/refatorando-o-blog-parte-2.md

@@ -0,0 +1,9 @@
+---
+title: "Refatorando o Blog parte 2"
+date: 2026-11-06
+slug: refatorando-o-blog-parte-2
+tags: []
+draft: true
+---
+
+## Refatorando o Blog parte 2