diff --git a/projects/frontend/beginner/01-todo-list-app/README.md b/projects/frontend/beginner/01-todo-list-app/README.md
index fa0e83f..54cba98 100644
--- a/projects/frontend/beginner/01-todo-list-app/README.md
+++ b/projects/frontend/beginner/01-todo-list-app/README.md
@@ -1,34 +1,92 @@
 # To-do List App
 
-## Idea
-Build a simple to-do list application where users can add, complete, and delete tasks. Learn fundamentals of DOM manipulation, state management, and local storage.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build the classic to-do list: a single screen where a user types a task, presses Enter, sees it appear, checks it off when done, and removes it when it no longer matters. It looks trivial, but it is the smallest complete example of the core frontend loop — user input changes state, and state re-renders the UI. Everything is driven by an in-memory array of task objects that you persist to `localStorage` so the list survives a page reload. There is no server and no framework requirement; the interesting work is keeping your data model and what the user sees perfectly in sync.
+
+## Prerequisites
+
+- Basic HTML, CSS, and JavaScript (variables, arrays, functions)
+- How to read from and write to the DOM, or a component framework of your choice
+- Familiarity with array methods (`map`, `filter`, `find`)
+- A code editor and a browser with dev tools
 
 ## Learning Objectives
-- Understand DOM manipulation
-- Implement state management basics
-- Use local storage for persistence
-- Build interactive UI
-- Handle user events
-
-## Implementation Tips
-- Create task objects with id, title, completed status
-- Store tasks in local storage
-- Implement add task functionality
-- Add complete/uncomplete toggle
-- Implement delete task
-- Add visual feedback for completed tasks
-- Create clear all completed tasks button
-- Add task count display
-- Implement filter (all/active/completed)
-- Add keyboard shortcuts (Enter to add)
-- Create animations for task operations
-- Add task editing capability
-- Implement due dates (optional)
-- Create themed styling
-
-## Key Challenges
-- Local storage synchronization
-- State consistency
-- UI responsiveness
-- Local storage size limits
-- Task ordering and sorting
+
+By the end, you should be able to:
+
+- Model UI as a function of a single source-of-truth state
+- Add, toggle, edit, and delete items immutably rather than mutating in place
+- Persist and rehydrate state with the `localStorage` API
+- Render a filtered view (all / active / completed) without losing the underlying data
+- Wire up keyboard and click interactions with accessible, labelled controls
+
+## Functional Requirements
+
+1. The user can type a task and add it by pressing Enter or clicking an Add button.
+2. Empty or whitespace-only tasks must be rejected without adding a blank row.
+3. Each task can be toggled between active and completed, with a clear visual difference.
+4. The user can delete any individual task.
+5. A live counter shows how many tasks remain active.
+6. The user can filter the list by all, active, or completed.
+7. The full list must survive a page refresh via `localStorage`.
+
+## Suggested Milestones
+
+1. **Milestone 1 — Add & render:** Capture input, push a task object to state, render the list.
+2. **Milestone 2 — Toggle & delete:** Mark tasks done and remove them, updating the counter.
+3. **Milestone 3 — Filter & persist:** Add the filter view and save/load from `localStorage`.
+
+## Data & Interface Sketch
+
+```text
+Task
+  id:        string   (crypto.randomUUID())
+  title:     string
+  completed: boolean
+  createdAt: number   (Date.now())
+
+Layout
++------------------------------------------+
+| [ new task input............ ] [ Add ]   |
++------------------------------------------+
+| [x] Buy milk                      (del)  |
+| [ ] Call dentist                  (del)  |
++------------------------------------------+
+| 1 item left   [All] [Active] [Completed] |
++------------------------------------------+
+```
+
+## Stretch Goals
+
+- Inline edit: double-click a task title to rename it.
+- Add a "Clear completed" button that removes all done tasks at once.
+- Allow reordering tasks by drag-and-drop.
+- Add a light/dark theme toggle stored alongside the tasks.
+
+## Definition of Done
+
+- [ ] Adding, toggling, and deleting update both the UI and stored state.
+- [ ] Blank tasks cannot be added.
+- [ ] The remaining-items counter is always accurate after any action.
+- [ ] Filters change the visible list without discarding hidden tasks.
+- [ ] Reloading the page restores the exact previous list.
+
+## Common Pitfalls
+
+- Mutating the state array directly instead of producing a new one, causing stale renders.
+- Storing rendered HTML strings instead of a clean data model, making filters and edits painful.
+- Forgetting to `JSON.parse` / `JSON.stringify` around `localStorage`, which only stores strings.
+- Using array index as a key/id, which breaks after deletion and reordering.
+- Skipping labels on the checkbox and buttons, leaving the app unusable with a screen reader.
+
+## Resources
+
+- [MDN: Web Storage API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API) — how `localStorage` works and its limits.
+- [MDN: Introduction to the DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction) — reading and updating the page.
+- [web.dev: Learn Accessibility — Forms](https://web.dev/learn/accessibility/forms) — labelling inputs and controls.
+- [roadmap.sh: Frontend](https://roadmap.sh/frontend) — where these fundamentals sit in the bigger picture.
diff --git a/projects/frontend/beginner/01-todo-list-app/README.pt-BR.md b/projects/frontend/beginner/01-todo-list-app/README.pt-BR.md
new file mode 100644
index 0000000..6ebe23e
--- /dev/null
+++ b/projects/frontend/beginner/01-todo-list-app/README.pt-BR.md
@@ -0,0 +1,92 @@
+# Aplicativo de Lista de Tarefas
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa a clássica lista de tarefas: uma única tela onde o usuário digita uma tarefa, pressiona Enter, a vê aparecer, marca como concluída e a remove quando não importa mais. Parece trivial, mas é o menor exemplo completo do laço central do frontend — a entrada do usuário muda o estado, e o estado re-renderiza a UI. Tudo é conduzido por um array de objetos de tarefa em memória que você persiste no `localStorage` para que a lista sobreviva a um recarregamento. Não há servidor nem exigência de framework; o trabalho interessante é manter seu modelo de dados e o que o usuário vê perfeitamente sincronizados.
+
+## Pré-requisitos
+
+- HTML, CSS e JavaScript básicos (variáveis, arrays, funções)
+- Como ler e escrever no DOM, ou um framework de componentes à sua escolha
+- Familiaridade com métodos de array (`map`, `filter`, `find`)
+- Um editor de código e um navegador com ferramentas de desenvolvedor
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Modelar a UI como uma função de um único estado como fonte da verdade
+- Adicionar, alternar, editar e excluir itens de forma imutável em vez de mutar no lugar
+- Persistir e reidratar o estado com a API `localStorage`
+- Renderizar uma visão filtrada (todas / ativas / concluídas) sem perder os dados subjacentes
+- Conectar interações de teclado e clique com controles acessíveis e rotulados
+
+## Requisitos Funcionais
+
+1. O usuário pode digitar uma tarefa e adicioná-la pressionando Enter ou clicando em um botão Adicionar.
+2. Tarefas vazias ou só com espaços devem ser rejeitadas sem adicionar uma linha em branco.
+3. Cada tarefa pode ser alternada entre ativa e concluída, com uma diferença visual clara.
+4. O usuário pode excluir qualquer tarefa individual.
+5. Um contador ao vivo mostra quantas tarefas permanecem ativas.
+6. O usuário pode filtrar a lista por todas, ativas ou concluídas.
+7. A lista completa deve sobreviver a um recarregamento da página via `localStorage`.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Adicionar e renderizar:** Capture a entrada, adicione um objeto de tarefa ao estado, renderize a lista.
+2. **Marco 2 — Alternar e excluir:** Marque tarefas como feitas e remova-as, atualizando o contador.
+3. **Marco 3 — Filtrar e persistir:** Adicione a visão de filtro e salve/carregue do `localStorage`.
+
+## Esboço de Dados e Interface
+
+```text
+Tarefa
+  id:        string   (crypto.randomUUID())
+  title:     string
+  completed: boolean
+  createdAt: number   (Date.now())
+
+Layout
++------------------------------------------+
+| [ nova tarefa............... ] [Adicionar]|
++------------------------------------------+
+| [x] Comprar leite                 (del)  |
+| [ ] Ligar para o dentista         (del)  |
++------------------------------------------+
+| 1 item restante  [Todas][Ativas][Feitas] |
++------------------------------------------+
+```
+
+## Desafios Extras
+
+- Edição em linha: dê um duplo clique no título de uma tarefa para renomeá-la.
+- Adicione um botão "Limpar concluídas" que remove todas as tarefas feitas de uma vez.
+- Permita reordenar tarefas com arrastar e soltar.
+- Adicione um alternador de tema claro/escuro armazenado junto com as tarefas.
+
+## Definição de Pronto
+
+- [ ] Adicionar, alternar e excluir atualizam tanto a UI quanto o estado armazenado.
+- [ ] Tarefas em branco não podem ser adicionadas.
+- [ ] O contador de itens restantes está sempre correto após qualquer ação.
+- [ ] Os filtros mudam a lista visível sem descartar tarefas ocultas.
+- [ ] Recarregar a página restaura exatamente a lista anterior.
+
+## Armadilhas Comuns
+
+- Mutar o array de estado diretamente em vez de produzir um novo, causando renderizações desatualizadas.
+- Armazenar strings de HTML renderizado em vez de um modelo de dados limpo, tornando filtros e edições penosos.
+- Esquecer o `JSON.parse` / `JSON.stringify` em torno do `localStorage`, que só armazena strings.
+- Usar o índice do array como chave/id, o que quebra após exclusão e reordenação.
+- Pular rótulos nas caixas de seleção e botões, deixando o app inutilizável com um leitor de tela.
+
+## Recursos
+
+- [MDN: Web Storage API](https://developer.mozilla.org/pt-BR/docs/Web/API/Web_Storage_API) — como o `localStorage` funciona e seus limites.
+- [MDN: Introdução ao DOM](https://developer.mozilla.org/pt-BR/docs/Web/API/Document_Object_Model/Introduction) — ler e atualizar a página.
+- [web.dev: Learn Accessibility — Forms](https://web.dev/learn/accessibility/forms) — rotular entradas e controles.
+- [roadmap.sh: Frontend](https://roadmap.sh/frontend) — onde esses fundamentos se encaixam no quadro maior.
diff --git a/projects/frontend/beginner/02-calculator-ui/README.md b/projects/frontend/beginner/02-calculator-ui/README.md
index bcd9ea2..cd8d982 100644
--- a/projects/frontend/beginner/02-calculator-ui/README.md
+++ b/projects/frontend/beginner/02-calculator-ui/README.md
@@ -1,34 +1,93 @@
 # Calculator UI
 
-## Idea
-Create a functional calculator UI with basic arithmetic operations. Learn about event handling, string manipulation, and UI state management.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build a working calculator with a keypad, a display, and the four basic operations. The visual layout is the easy half; the real lesson is modelling calculator behaviour as a small state machine. A user taps `7`, `+`, `3`, `=` — each key means something different depending on what came before. You will track the current entry, the pending operator, and the accumulated value, and decide what every button does in every state. Get that model right and edge cases like chaining operations or pressing `=` twice stop being surprises.
+
+## Prerequisites
+
+- Basic HTML, CSS, and JavaScript
+- CSS Grid or Flexbox for laying out a button pad
+- Comfort with `switch`/conditional logic and number parsing
+- A code editor and a browser with dev tools
 
 ## Learning Objectives
-- Handle button click events
-- Manage calculator state
-- Implement operation logic
-- Format number display
-- Handle edge cases
-
-## Implementation Tips
-- Design calculator layout with buttons
-- Implement number input handling
-- Add arithmetic operations (+, -, *, /)
-- Implement equals functionality
-- Add clear/reset button
-- Display current calculation
-- Handle decimal numbers
-- Implement backspace functionality
-- Add operation chaining
-- Implement percentage calculation
-- Add keyboard support
-- Create responsive design
-- Add operation history (optional)
-- Implement memory functions (optional)
-
-## Key Challenges
-- Floating point precision
-- Operation chaining logic
-- State management during calculations
-- Keyboard vs mouse input
-- Error handling (division by zero)
+
+By the end, you should be able to:
+
+- Represent interactive behaviour as explicit state rather than reading the display back as data
+- Handle operator precedence for a simple left-to-right calculator and chained operations
+- Format numeric output and avoid raw floating-point artefacts
+- Support both mouse/touch and physical keyboard input for the same actions
+- Guard against invalid states like multiple decimals or division by zero
+
+## Functional Requirements
+
+1. The calculator performs addition, subtraction, multiplication, and division.
+2. The display shows the number being entered and the result after `=`.
+3. Pressing an operator after a result uses that result as the new left operand (chaining).
+4. A clear button resets all state; a backspace removes the last entered digit.
+5. Only one decimal point is allowed per number.
+6. Division by zero shows a clear error state rather than `Infinity` or `NaN`.
+7. Number and operator keys on the physical keyboard mirror the on-screen buttons.
+
+## Suggested Milestones
+
+1. **Milestone 1 — Entry & display:** Build the keypad and show digits, decimals, and backspace.
+2. **Milestone 2 — Single operation:** Store an operator and left operand, compute on `=`.
+3. **Milestone 3 — Chaining & guards:** Chain operations, handle clear, decimals, and divide-by-zero.
+
+## Data & Interface Sketch
+
+```text
+State
+  current:   string    (digits being typed, e.g. "12.5")
+  operator:  "+"|"-"|"*"|"/"|null
+  accumulator: number|null
+  justEvaluated: boolean
+
+Layout (4-column grid)
++-------------------------------+
+|            123.45             |  <- display
++-------------------------------+
+|  C  | +/- |  %  |   /         |
+|  7  |  8  |  9  |   *         |
+|  4  |  5  |  6  |   -         |
+|  1  |  2  |  3  |   +         |
+|    0      |  .  |   =         |
++-------------------------------+
+```
+
+## Stretch Goals
+
+- Add a running history/tape of previous calculations.
+- Add memory keys (M+, M-, MR, MC).
+- Support percentage relative to the current accumulator.
+- Add a keyboard-only mode with visible focus indicators on each key.
+
+## Definition of Done
+
+- [ ] All four operations produce correct results, including chained sequences.
+- [ ] The display never shows `NaN`, `Infinity`, or `undefined`.
+- [ ] Clear fully resets state; backspace edits the current entry only.
+- [ ] Keyboard and on-screen buttons behave identically.
+- [ ] Only one decimal point can be entered per number.
+
+## Common Pitfalls
+
+- Using the display text as your source of truth instead of a separate state model.
+- Concatenating strings for math and getting `"1" + "2" = "12"` instead of `3`.
+- Ignoring floating-point rounding, so `0.1 + 0.2` shows `0.30000000000000004`.
+- Forgetting the "just evaluated" flag, so the next digit appends to the result instead of starting fresh.
+- Leaving buttons as non-focusable `<div>`s, breaking keyboard access.
+
+## Resources
+
+- [MDN: Number.prototype.toFixed()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed) — controlling decimal display.
+- [MDN: CSS Grid Layout](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout) — laying out the keypad.
+- [0.30000000000000004.com](https://0.30000000000000004.com/) — why floating-point math misbehaves.
+- [MDN: KeyboardEvent.key](https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key) — mapping physical keys to actions.
diff --git a/projects/frontend/beginner/02-calculator-ui/README.pt-BR.md b/projects/frontend/beginner/02-calculator-ui/README.pt-BR.md
new file mode 100644
index 0000000..80214a7
--- /dev/null
+++ b/projects/frontend/beginner/02-calculator-ui/README.pt-BR.md
@@ -0,0 +1,93 @@
+# Calculadora (UI)
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa uma calculadora funcional com teclado, visor e as quatro operações básicas. O layout visual é a metade fácil; a lição real é modelar o comportamento da calculadora como uma pequena máquina de estados. Um usuário toca `7`, `+`, `3`, `=` — cada tecla significa algo diferente dependendo do que veio antes. Você vai rastrear a entrada atual, o operador pendente e o valor acumulado, e decidir o que cada botão faz em cada estado. Acerte esse modelo e casos limítrofes como encadear operações ou pressionar `=` duas vezes deixam de ser surpresas.
+
+## Pré-requisitos
+
+- HTML, CSS e JavaScript básicos
+- CSS Grid ou Flexbox para dispor um teclado de botões
+- Conforto com lógica de `switch`/condicionais e parsing de números
+- Um editor de código e um navegador com ferramentas de desenvolvedor
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Representar o comportamento interativo como estado explícito em vez de ler o visor de volta como dado
+- Tratar a ordem das operações de uma calculadora simples da esquerda para a direita e operações encadeadas
+- Formatar a saída numérica e evitar artefatos brutos de ponto flutuante
+- Suportar entrada por mouse/toque e por teclado físico para as mesmas ações
+- Proteger contra estados inválidos como múltiplos decimais ou divisão por zero
+
+## Requisitos Funcionais
+
+1. A calculadora realiza adição, subtração, multiplicação e divisão.
+2. O visor mostra o número sendo digitado e o resultado após `=`.
+3. Pressionar um operador após um resultado usa esse resultado como novo operando à esquerda (encadeamento).
+4. Um botão limpar reseta todo o estado; um backspace remove o último dígito digitado.
+5. Apenas um ponto decimal é permitido por número.
+6. Divisão por zero mostra um estado de erro claro em vez de `Infinity` ou `NaN`.
+7. Teclas de número e operador no teclado físico espelham os botões da tela.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Entrada e visor:** Construa o teclado e mostre dígitos, decimais e backspace.
+2. **Marco 2 — Operação única:** Armazene um operador e o operando à esquerda, calcule no `=`.
+3. **Marco 3 — Encadeamento e proteções:** Encadeie operações, trate limpar, decimais e divisão por zero.
+
+## Esboço de Dados e Interface
+
+```text
+Estado
+  current:   string    (dígitos sendo digitados, ex.: "12.5")
+  operator:  "+"|"-"|"*"|"/"|null
+  accumulator: number|null
+  justEvaluated: boolean
+
+Layout (grade de 4 colunas)
++-------------------------------+
+|            123.45             |  <- visor
++-------------------------------+
+|  C  | +/- |  %  |   /         |
+|  7  |  8  |  9  |   *         |
+|  4  |  5  |  6  |   -         |
+|  1  |  2  |  3  |   +         |
+|    0      |  .  |   =         |
++-------------------------------+
+```
+
+## Desafios Extras
+
+- Adicione um histórico/fita das cálculos anteriores.
+- Adicione teclas de memória (M+, M-, MR, MC).
+- Suporte porcentagem relativa ao acumulador atual.
+- Adicione um modo somente teclado com indicadores de foco visíveis em cada tecla.
+
+## Definição de Pronto
+
+- [ ] As quatro operações produzem resultados corretos, incluindo sequências encadeadas.
+- [ ] O visor nunca mostra `NaN`, `Infinity` ou `undefined`.
+- [ ] Limpar reseta totalmente o estado; backspace edita apenas a entrada atual.
+- [ ] Teclado e botões da tela se comportam de forma idêntica.
+- [ ] Apenas um ponto decimal pode ser inserido por número.
+
+## Armadilhas Comuns
+
+- Usar o texto do visor como fonte da verdade em vez de um modelo de estado separado.
+- Concatenar strings para a matemática e obter `"1" + "2" = "12"` em vez de `3`.
+- Ignorar o arredondamento de ponto flutuante, fazendo `0.1 + 0.2` mostrar `0.30000000000000004`.
+- Esquecer o sinalizador "acabou de avaliar", de modo que o próximo dígito se anexa ao resultado em vez de começar do zero.
+- Deixar botões como `<div>`s não focáveis, quebrando o acesso pelo teclado.
+
+## Recursos
+
+- [MDN: Number.prototype.toFixed()](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed) — controlar a exibição de decimais.
+- [MDN: CSS Grid Layout](https://developer.mozilla.org/pt-BR/docs/Web/CSS/CSS_grid_layout) — dispor o teclado.
+- [0.30000000000000004.com](https://0.30000000000000004.com/) — por que a matemática de ponto flutuante se comporta mal.
+- [MDN: KeyboardEvent.key](https://developer.mozilla.org/pt-BR/docs/Web/API/KeyboardEvent/key) — mapear teclas físicas para ações.
diff --git a/projects/frontend/beginner/03-static-portfolio/README.md b/projects/frontend/beginner/03-static-portfolio/README.md
index 2a32740..2189d45 100644
--- a/projects/frontend/beginner/03-static-portfolio/README.md
+++ b/projects/frontend/beginner/03-static-portfolio/README.md
@@ -1,34 +1,99 @@
 # Static Portfolio Website
 
-## Idea
-Build a personal portfolio website showcasing projects and skills. Learn about semantic HTML, CSS styling, and responsive design.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build a personal portfolio site that presents who you are, what you have built, and how to reach you — all as static, content-first pages with no backend. The point is not flashy animation; it is writing clean, semantic HTML and a responsive CSS layout that reads well from a 320px phone to a wide desktop. You will structure real sections (intro, projects, skills, contact), make the navigation usable by keyboard and screen reader, and let the content drive the design rather than the other way around. Done well, this becomes something you actually deploy and link on your résumé.
+
+## Prerequisites
+
+- HTML fundamentals and the difference between semantic and generic elements
+- CSS box model, Flexbox, and CSS Grid basics
+- An understanding of media queries and relative units (`rem`, `%`, `vw`)
+- A code editor and a browser with dev tools
 
 ## Learning Objectives
-- Create semantic HTML structure
-- Implement responsive CSS layout
-- Use CSS Grid and Flexbox
-- Implement navigation
-- Create professional styling
-
-## Implementation Tips
-- Create sections: header, about, projects, skills, contact
-- Design responsive navigation bar
-- Add project showcase with descriptions
-- Implement skills section with categories
-- Create contact form or links
-- Add smooth scrolling navigation
-- Implement mobile-responsive design
-- Add footer with social links
-- Create dark mode toggle (optional)
-- Add project filtering by category
-- Implement lazy loading for images
-- Add scroll-to-top button
-- Create animations on scroll
-- Add blog or testimonials section
-
-## Key Challenges
-- Responsive design across devices
-- CSS complexity management
-- Image optimization
-- Scroll performance
-- Browser compatibility
+
+By the end, you should be able to:
+
+- Structure a page with semantic landmarks (`header`, `nav`, `main`, `section`, `footer`)
+- Build a layout that reflows gracefully across screen sizes without horizontal scroll
+- Use Grid and Flexbox for the right jobs (page skeleton vs. component alignment)
+- Write accessible navigation with a logical heading order and visible focus states
+- Optimize images with responsive `srcset`/`sizes` and meaningful `alt` text
+
+## Functional Requirements
+
+1. The site has clearly separated sections: intro/hero, about, projects, skills, and contact.
+2. A navigation bar links to each section and works with keyboard and touch.
+3. The layout is fully responsive with no horizontal overflow at 320px width.
+4. Each project entry shows a title, short description, and a link to code or a live demo.
+5. All images have descriptive `alt` text; decorative images use empty `alt`.
+6. Headings follow a single, logical order (`h1` → `h2` → `h3`) with no skipped levels.
+7. Color contrast meets WCAG AA for body text and interactive elements.
+
+## Suggested Milestones
+
+1. **Milestone 1 — Structure & content:** Write the semantic HTML for all sections with real placeholder content.
+2. **Milestone 2 — Responsive layout:** Style with Grid/Flexbox and add media queries for mobile, tablet, and desktop.
+3. **Milestone 3 — Polish & a11y:** Add focus states, contrast fixes, responsive images, and smooth in-page navigation.
+
+## Data & Interface Sketch
+
+```text
+Page landmarks
+  header > nav (logo + section links)
+  main
+    section#hero    (name, role, one-line pitch, CTA)
+    section#about   (short bio)
+    section#projects (grid of project cards)
+    section#skills  (grouped skill tags)
+    section#contact (email + social links)
+  footer (copyright, back-to-top)
+
+Project card
+  title:    string
+  summary:  string
+  tags:     string[]
+  repoUrl / liveUrl: string
+
+Desktop grid           Mobile (stacked)
++----+----+----+        +-----------+
+| c1 | c2 | c3 |        |    c1     |
++----+----+----+   -->  +-----------+
+| c4 | c5 | c6 |        |    c2     |
++----+----+----+        +-----------+
+```
+
+## Stretch Goals
+
+- Add a light/dark theme toggle that respects `prefers-color-scheme`.
+- Filter projects by tag/category without a page reload.
+- Add subtle scroll-reveal animations gated behind `prefers-reduced-motion`.
+- Deploy to a free static host and wire up a custom domain.
+
+## Definition of Done
+
+- [ ] Every section is reachable from the nav by mouse, touch, and keyboard.
+- [ ] The layout has zero horizontal scroll from 320px up to desktop widths.
+- [ ] All content images have appropriate `alt` text.
+- [ ] Heading levels are ordered with no skips, and there is exactly one `h1`.
+- [ ] Text and interactive colors pass WCAG AA contrast.
+
+## Common Pitfalls
+
+- Wrapping everything in `<div>`s instead of semantic landmarks, hurting screen-reader navigation.
+- Fixed pixel widths that force horizontal scrolling on small screens.
+- Skipping heading levels (`h1` straight to `h4`) for visual size instead of using CSS.
+- Low-contrast "designer grey" text that fails accessibility checks.
+- Shipping huge unoptimized images that tank load time on mobile.
+
+## Resources
+
+- [MDN: HTML elements reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Element) — choosing the right semantic element.
+- [web.dev: Learn Responsive Design](https://web.dev/learn/design) — building layouts that adapt.
+- [web.dev: Learn Accessibility](https://web.dev/learn/accessibility) — landmarks, headings, and contrast.
+- [MDN: Responsive images](https://developer.mozilla.org/en-US/docs/Web/HTML/Responsive_images) — `srcset` and `sizes`.
diff --git a/projects/frontend/beginner/03-static-portfolio/README.pt-BR.md b/projects/frontend/beginner/03-static-portfolio/README.pt-BR.md
new file mode 100644
index 0000000..2800e94
--- /dev/null
+++ b/projects/frontend/beginner/03-static-portfolio/README.pt-BR.md
@@ -0,0 +1,99 @@
+# Site de Portfólio Estático
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa um site de portfólio pessoal que apresenta quem você é, o que você construiu e como entrar em contato — tudo como páginas estáticas focadas em conteúdo, sem backend. O objetivo não é animação chamativa; é escrever HTML semântico e limpo e um layout CSS responsivo que se leia bem de um celular de 320px a um desktop largo. Você vai estruturar seções reais (introdução, projetos, habilidades, contato), tornar a navegação utilizável por teclado e leitor de tela, e deixar o conteúdo guiar o design em vez do contrário. Bem feito, isso se torna algo que você de fato publica e coloca no currículo.
+
+## Pré-requisitos
+
+- Fundamentos de HTML e a diferença entre elementos semânticos e genéricos
+- Modelo de caixa do CSS, Flexbox e o básico de CSS Grid
+- Entendimento de media queries e unidades relativas (`rem`, `%`, `vw`)
+- Um editor de código e um navegador com ferramentas de desenvolvedor
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Estruturar uma página com marcos semânticos (`header`, `nav`, `main`, `section`, `footer`)
+- Construir um layout que se rearranja graciosamente em vários tamanhos de tela sem rolagem horizontal
+- Usar Grid e Flexbox para os trabalhos certos (esqueleto da página vs. alinhamento de componente)
+- Escrever navegação acessível com ordem lógica de títulos e estados de foco visíveis
+- Otimizar imagens com `srcset`/`sizes` responsivos e texto `alt` significativo
+
+## Requisitos Funcionais
+
+1. O site tem seções claramente separadas: introdução/hero, sobre, projetos, habilidades e contato.
+2. Uma barra de navegação leva a cada seção e funciona com teclado e toque.
+3. O layout é totalmente responsivo, sem estouro horizontal em 320px de largura.
+4. Cada entrada de projeto mostra um título, uma descrição curta e um link para o código ou uma demo ao vivo.
+5. Todas as imagens têm texto `alt` descritivo; imagens decorativas usam `alt` vazio.
+6. Os títulos seguem uma ordem única e lógica (`h1` → `h2` → `h3`) sem pular níveis.
+7. O contraste de cores atende ao WCAG AA para texto de corpo e elementos interativos.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Estrutura e conteúdo:** Escreva o HTML semântico de todas as seções com conteúdo de exemplo real.
+2. **Marco 2 — Layout responsivo:** Estilize com Grid/Flexbox e adicione media queries para celular, tablet e desktop.
+3. **Marco 3 — Polimento e acessibilidade:** Adicione estados de foco, correções de contraste, imagens responsivas e navegação suave na página.
+
+## Esboço de Dados e Interface
+
+```text
+Marcos da página
+  header > nav (logo + links de seção)
+  main
+    section#hero    (nome, cargo, frase de efeito, CTA)
+    section#about   (bio curta)
+    section#projects (grade de cartões de projeto)
+    section#skills  (tags de habilidades agrupadas)
+    section#contact (e-mail + links sociais)
+  footer (copyright, voltar ao topo)
+
+Cartão de projeto
+  title:    string
+  summary:  string
+  tags:     string[]
+  repoUrl / liveUrl: string
+
+Grade desktop          Celular (empilhado)
++----+----+----+        +-----------+
+| c1 | c2 | c3 |        |    c1     |
++----+----+----+   -->  +-----------+
+| c4 | c5 | c6 |        |    c2     |
++----+----+----+        +-----------+
+```
+
+## Desafios Extras
+
+- Adicione um alternador de tema claro/escuro que respeite `prefers-color-scheme`.
+- Filtre projetos por tag/categoria sem recarregar a página.
+- Adicione animações sutis de revelação ao rolar, condicionadas a `prefers-reduced-motion`.
+- Publique em um host estático gratuito e configure um domínio personalizado.
+
+## Definição de Pronto
+
+- [ ] Toda seção é alcançável pela navegação por mouse, toque e teclado.
+- [ ] O layout tem zero rolagem horizontal de 320px até larguras de desktop.
+- [ ] Todas as imagens de conteúdo têm texto `alt` apropriado.
+- [ ] Os níveis de título estão ordenados sem pulos, e há exatamente um `h1`.
+- [ ] As cores de texto e interativas passam no contraste WCAG AA.
+
+## Armadilhas Comuns
+
+- Envolver tudo em `<div>`s em vez de marcos semânticos, prejudicando a navegação por leitor de tela.
+- Larguras fixas em pixels que forçam rolagem horizontal em telas pequenas.
+- Pular níveis de título (`h1` direto para `h4`) por tamanho visual em vez de usar CSS.
+- Texto "cinza de designer" de baixo contraste que falha nas verificações de acessibilidade.
+- Publicar imagens enormes e não otimizadas que arruínam o tempo de carga no celular.
+
+## Recursos
+
+- [MDN: Referência de elementos HTML](https://developer.mozilla.org/pt-BR/docs/Web/HTML/Element) — escolher o elemento semântico certo.
+- [web.dev: Learn Responsive Design](https://web.dev/learn/design) — construir layouts que se adaptam.
+- [web.dev: Learn Accessibility](https://web.dev/learn/accessibility) — marcos, títulos e contraste.
+- [MDN: Imagens responsivas](https://developer.mozilla.org/pt-BR/docs/Web/HTML/Responsive_images) — `srcset` e `sizes`.
diff --git a/projects/frontend/beginner/04-weather-app/README.md b/projects/frontend/beginner/04-weather-app/README.md
index b224d9e..31d621d 100644
--- a/projects/frontend/beginner/04-weather-app/README.md
+++ b/projects/frontend/beginner/04-weather-app/README.md
@@ -1,34 +1,97 @@
-# Weather App (API consumption)
+# Weather App
 
-## Idea
-Create a weather application that fetches and displays weather data from an API. Learn about HTTP requests, API integration, and data display.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build a small app where a user types a city, and you fetch and display its current weather from a public API. This is the beginner's first real taste of the async web: a request goes out, time passes, and something — data, an error, or nothing — comes back. The interesting work is not the layout but handling the three states every network UI must show: loading, success, and failure. You will read JSON, map it onto a clean view, and make sure the user is never staring at a frozen screen wondering what happened.
+
+## Prerequisites
+
+- JavaScript basics including functions and objects
+- Promises and `async`/`await`, or `.then()` chains
+- How to read API documentation and inspect a JSON response
+- A free API key from a weather provider (e.g. OpenWeather or Open-Meteo, which needs none)
 
 ## Learning Objectives
-- Make API requests with fetch/axios
-- Parse JSON responses
-- Handle API errors
-- Display API data in UI
-- Implement loading states
-
-## Implementation Tips
-- Use free weather API
-- Create search by city functionality
-- Display current weather with icon
-- Show temperature, humidity, wind speed
-- Implement forecast view (daily/hourly)
-- Add weather alerts
-- Create favorite cities list
-- Implement geolocation for current weather
-- Add unit conversion (C/F)
-- Display weather maps
-- Create loading and error states
-- Add weather history
-- Implement caching to reduce API calls
-- Create dark/light theme based on weather
-
-## Key Challenges
-- API rate limiting handling
-- Error states and user feedback
-- Geolocation permission handling
-- Data caching strategy
-- Weather icon selection
+
+By the end, you should be able to:
+
+- Make HTTP requests with `fetch` and parse a JSON response
+- Model and render explicit loading, success, and error states
+- Handle failures gracefully: bad city, network error, non-200 responses
+- Keep an API key out of source control and understand its limits
+- Transform raw API data into a small, UI-friendly shape
+
+## Functional Requirements
+
+1. The user can search for a city by name and trigger a weather lookup.
+2. While the request is in flight, a loading indicator is shown.
+3. On success, the UI shows temperature, a condition description, and humidity.
+4. An unknown city or failed request shows a clear, human-readable error message.
+5. Rapid repeated submissions must not leave a stale result on screen.
+6. The search input is keyboard-accessible and submittable via Enter.
+7. Temperature units are labelled explicitly (°C or °F).
+
+## Suggested Milestones
+
+1. **Milestone 1 — Fetch & display:** Call the API for a hardcoded city and render the result.
+2. **Milestone 2 — Search & states:** Wire up the input, add loading and error handling.
+3. **Milestone 3 — Robustness:** Handle empty input, bad cities, and out-of-order responses.
+
+## Data & Interface Sketch
+
+```text
+View state (one of)
+  { status: "idle" }
+  { status: "loading" }
+  { status: "success", data: Weather }
+  { status: "error", message: string }
+
+Weather (mapped from API JSON)
+  city:        string
+  tempC:       number
+  condition:   string   ("Clouds", "Rain", ...)
+  humidity:    number   (percent)
+  icon:        string   (code -> your own icon)
+
+Layout
++--------------------------------------+
+| [ search city......... ] [ Search ]  |
++--------------------------------------+
+|  London           [ loading... ]     |
+|  18°C  Cloudy   Humidity 72%         |
++--------------------------------------+
+```
+
+## Stretch Goals
+
+- Add a multi-day forecast below the current conditions.
+- Toggle between Celsius and Fahrenheit without re-fetching.
+- Use the Geolocation API to load weather for the user's current location.
+- Cache the last successful result so a reload shows something instantly.
+
+## Definition of Done
+
+- [ ] A valid city shows real weather data with a labelled unit.
+- [ ] Loading, success, and error states each render distinctly.
+- [ ] A nonexistent city produces a friendly error, not a blank screen or crash.
+- [ ] The API key is not committed to the repository.
+- [ ] Submitting with Enter and clicking Search behave identically.
+
+## Common Pitfalls
+
+- Assuming `fetch` rejects on HTTP errors — it only rejects on network failure; check `response.ok`.
+- Forgetting to handle the loading state, so the UI looks broken during the request.
+- Race conditions where a slow earlier request overwrites a newer result.
+- Hardcoding and committing your API key, then hitting rate limits or leaking it.
+- Rendering the raw API JSON shape directly, coupling your UI to the provider.
+
+## Resources
+
+- [MDN: Using the Fetch API](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch) — requests, responses, and error checking.
+- [MDN: Response.ok](https://developer.mozilla.org/en-US/docs/Web/API/Response/ok) — why you must check status yourself.
+- [Open-Meteo API](https://open-meteo.com/en/docs) — a free weather API with no key required.
+- [web.dev: Loading states and skeletons](https://web.dev/articles/optimize-cls) — communicating progress to users.
diff --git a/projects/frontend/beginner/04-weather-app/README.pt-BR.md b/projects/frontend/beginner/04-weather-app/README.pt-BR.md
new file mode 100644
index 0000000..328d214
--- /dev/null
+++ b/projects/frontend/beginner/04-weather-app/README.pt-BR.md
@@ -0,0 +1,97 @@
+# Aplicativo de Clima
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa um pequeno app onde o usuário digita uma cidade, e você busca e exibe o clima atual dela a partir de uma API pública. Este é o primeiro gostinho real da web assíncrona para iniciantes: uma requisição sai, o tempo passa, e algo — dados, um erro ou nada — volta. O trabalho interessante não é o layout, mas tratar os três estados que toda UI de rede precisa mostrar: carregando, sucesso e falha. Você vai ler JSON, mapeá-lo em uma visão limpa e garantir que o usuário nunca fique olhando para uma tela congelada sem saber o que aconteceu.
+
+## Pré-requisitos
+
+- Básico de JavaScript incluindo funções e objetos
+- Promises e `async`/`await`, ou cadeias de `.then()`
+- Como ler a documentação de uma API e inspecionar uma resposta JSON
+- Uma chave de API gratuita de um provedor de clima (ex.: OpenWeather ou Open-Meteo, que não requer nenhuma)
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Fazer requisições HTTP com `fetch` e analisar uma resposta JSON
+- Modelar e renderizar estados explícitos de carregamento, sucesso e erro
+- Tratar falhas graciosamente: cidade inválida, erro de rede, respostas não-200
+- Manter uma chave de API fora do controle de versão e entender seus limites
+- Transformar dados brutos da API em um formato pequeno e amigável à UI
+
+## Requisitos Funcionais
+
+1. O usuário pode buscar uma cidade pelo nome e disparar uma consulta de clima.
+2. Enquanto a requisição está em andamento, um indicador de carregamento é exibido.
+3. No sucesso, a UI mostra temperatura, uma descrição da condição e umidade.
+4. Uma cidade desconhecida ou requisição falha mostra uma mensagem de erro clara e legível.
+5. Envios repetidos e rápidos não devem deixar um resultado desatualizado na tela.
+6. O campo de busca é acessível por teclado e enviável via Enter.
+7. As unidades de temperatura são rotuladas explicitamente (°C ou °F).
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Buscar e exibir:** Chame a API para uma cidade fixa e renderize o resultado.
+2. **Marco 2 — Busca e estados:** Conecte o campo de entrada, adicione carregamento e tratamento de erro.
+3. **Marco 3 — Robustez:** Trate entrada vazia, cidades inválidas e respostas fora de ordem.
+
+## Esboço de Dados e Interface
+
+```text
+Estado da view (um de)
+  { status: "idle" }
+  { status: "loading" }
+  { status: "success", data: Weather }
+  { status: "error", message: string }
+
+Weather (mapeado do JSON da API)
+  city:        string
+  tempC:       number
+  condition:   string   ("Clouds", "Rain", ...)
+  humidity:    number   (percentual)
+  icon:        string   (código -> seu próprio ícone)
+
+Layout
++--------------------------------------+
+| [ buscar cidade....... ] [ Buscar ]  |
++--------------------------------------+
+|  London           [ carregando... ]  |
+|  18°C  Nublado   Umidade 72%         |
++--------------------------------------+
+```
+
+## Desafios Extras
+
+- Adicione uma previsão de vários dias abaixo das condições atuais.
+- Alterne entre Celsius e Fahrenheit sem refazer a busca.
+- Use a API de Geolocalização para carregar o clima da localização atual do usuário.
+- Faça cache do último resultado bem-sucedido para que um recarregamento mostre algo instantaneamente.
+
+## Definição de Pronto
+
+- [ ] Uma cidade válida mostra dados reais de clima com uma unidade rotulada.
+- [ ] Os estados de carregamento, sucesso e erro renderizam distintamente.
+- [ ] Uma cidade inexistente produz um erro amigável, não uma tela em branco ou travamento.
+- [ ] A chave de API não é commitada no repositório.
+- [ ] Enviar com Enter e clicar em Buscar se comportam de forma idêntica.
+
+## Armadilhas Comuns
+
+- Assumir que o `fetch` rejeita em erros HTTP — ele só rejeita em falha de rede; verifique `response.ok`.
+- Esquecer de tratar o estado de carregamento, fazendo a UI parecer quebrada durante a requisição.
+- Condições de corrida onde uma requisição anterior lenta sobrescreve um resultado mais novo.
+- Fixar e commitar sua chave de API, e então atingir limites de taxa ou vazá-la.
+- Renderizar o formato bruto do JSON da API diretamente, acoplando sua UI ao provedor.
+
+## Recursos
+
+- [MDN: Usando a Fetch API](https://developer.mozilla.org/pt-BR/docs/Web/API/Fetch_API/Using_Fetch) — requisições, respostas e verificação de erro.
+- [MDN: Response.ok](https://developer.mozilla.org/en-US/docs/Web/API/Response/ok) — por que você deve verificar o status por conta própria.
+- [Open-Meteo API](https://open-meteo.com/en/docs) — uma API de clima gratuita sem chave requerida.
+- [web.dev: Loading states](https://web.dev/articles/optimize-cls) — comunicar progresso aos usuários.
diff --git a/projects/frontend/beginner/05-simple-blog-ui/README.md b/projects/frontend/beginner/05-simple-blog-ui/README.md
index 65e1f61..347feef 100644
--- a/projects/frontend/beginner/05-simple-blog-ui/README.md
+++ b/projects/frontend/beginner/05-simple-blog-ui/README.md
@@ -1,34 +1,100 @@
 # Simple Blog UI
 
-## Idea
-Create a blog interface displaying posts and content. Learn about content display, filtering, and navigation between pages.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build the reading side of a blog: a list of posts you can browse, search, and filter by category, plus a detail view for reading a single post in full. There is no writing or backend — posts come from a local JSON file or a small in-memory array — so the focus stays on presenting content clearly and moving between a list and a detail without a full page reload. This is where beginners first meet the idea of a "view": the same data rendered two ways, and simple client-side navigation that keeps the URL and the screen in agreement.
+
+## Prerequisites
+
+- HTML, CSS, and JavaScript fundamentals
+- Array methods (`filter`, `map`, `find`) for list transformations
+- Basic understanding of client-side routing or show/hide view switching
+- A component framework of your choice is optional but welcome
 
 ## Learning Objectives
-- Display lists of content
-- Implement post pagination
-- Create post detail view
-- Build search functionality
-- Implement category filtering
-
-## Implementation Tips
-- Design blog layout with post list
-- Create post card components
-- Implement post detail/full view
-- Add pagination or infinite scroll
-- Create search functionality
-- Implement category filtering
-- Add tags display
-- Create author information
-- Implement comment display (optional)
-- Add reading time estimate
-- Create related posts section
-- Add breadcrumb navigation
-- Implement table of contents for posts
-- Add sharing buttons
-
-## Key Challenges
-- Large post list performance
-- Search functionality implementation
-- Pagination logic
-- Category management
-- Content formatting
+
+By the end, you should be able to:
+
+- Render a list of items from a data source and a detail view for one item
+- Implement client-side search and category filtering over the same dataset
+- Navigate between list and detail views while keeping state consistent
+- Paginate or lazily reveal a long list without overwhelming the DOM
+- Present readable typography and an accessible reading order
+
+## Functional Requirements
+
+1. The home view lists posts with title, excerpt, category, and estimated reading time.
+2. Selecting a post opens a detail view showing its full content.
+3. A search box filters the list by matching title or excerpt text.
+4. Category filters narrow the list; clearing them restores the full set.
+5. A long list is paginated or uses "load more" rather than rendering everything at once.
+6. The user can return from a detail view to the list without losing their filter.
+7. Each post detail has a single `h1` and a logical heading structure.
+
+## Suggested Milestones
+
+1. **Milestone 1 — List & detail:** Load posts and render the list, then a full detail view on selection.
+2. **Milestone 2 — Search & filter:** Add text search and category filtering over the dataset.
+3. **Milestone 3 — Navigation & paging:** Preserve filters across views and paginate the list.
+
+## Data & Interface Sketch
+
+```text
+Post
+  id:          string
+  title:       string
+  excerpt:     string
+  body:        string
+  category:    string
+  publishedAt: string   (ISO-8601)
+  readMinutes: number
+
+Views
+  list   -> filtered/paged array of Post summaries
+  detail -> one Post by id
+
+Layout (list)                Layout (detail)
++-------------------------+   +----------------------+
+| [ search ] [Category v] |   | < Back               |
++-------------------------+   | Title (h1)           |
+| Post card               |   | meta: cat · 5 min    |
+| Post card               |   |                      |
+| Post card               |   | body paragraphs...   |
++-------------------------+   +----------------------+
+| < 1 2 3 >               |
++-------------------------+
+```
+
+## Stretch Goals
+
+- Sync the current view and filters to the URL (query params or hash) so links are shareable.
+- Add a tag cloud and cross-link related posts by shared tags.
+- Add a table of contents generated from the post's headings.
+- Show a "no results" empty state with a way to reset filters.
+
+## Definition of Done
+
+- [ ] The list and detail views render the same data correctly from one source.
+- [ ] Search and category filters combine and can be cleared.
+- [ ] Returning to the list preserves the active search and filter.
+- [ ] A long list does not render all posts to the DOM at once.
+- [ ] Each detail page has exactly one `h1` and ordered headings.
+
+## Common Pitfalls
+
+- Duplicating post data for the list and detail instead of deriving both from one source.
+- Losing the active filter when navigating back from a detail view.
+- Case-sensitive search that misses obvious matches.
+- Rendering hundreds of cards up front, making the page janky.
+- Forgetting an empty state, so a filtered-out list looks like a bug.
+
+## Resources
+
+- [MDN: Array.prototype.filter()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) — building search and category filtering.
+- [MDN: History API](https://developer.mozilla.org/en-US/docs/Web/API/History_API) — reflecting views in the URL.
+- [web.dev: Learn Accessibility — Content structure](https://web.dev/learn/accessibility/structure) — headings and reading order.
+- [MDN: Working with JSON](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/JSON) — loading and parsing local data.
diff --git a/projects/frontend/beginner/05-simple-blog-ui/README.pt-BR.md b/projects/frontend/beginner/05-simple-blog-ui/README.pt-BR.md
new file mode 100644
index 0000000..6510baf
--- /dev/null
+++ b/projects/frontend/beginner/05-simple-blog-ui/README.pt-BR.md
@@ -0,0 +1,100 @@
+# Interface de Blog Simples
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa o lado de leitura de um blog: uma lista de posts que você pode navegar, buscar e filtrar por categoria, mais uma visão de detalhe para ler um único post por completo. Não há escrita nem backend — os posts vêm de um arquivo JSON local ou de um pequeno array em memória — então o foco fica em apresentar o conteúdo com clareza e transitar entre uma lista e um detalhe sem recarregar a página inteira. É aqui que iniciantes encontram pela primeira vez a ideia de uma "view": os mesmos dados renderizados de duas formas, e uma navegação simples no cliente que mantém a URL e a tela em acordo.
+
+## Pré-requisitos
+
+- Fundamentos de HTML, CSS e JavaScript
+- Métodos de array (`filter`, `map`, `find`) para transformações de listas
+- Entendimento básico de roteamento no cliente ou alternância mostrar/ocultar de views
+- Um framework de componentes à sua escolha é opcional, mas bem-vindo
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Renderizar uma lista de itens de uma fonte de dados e uma visão de detalhe para um item
+- Implementar busca no cliente e filtragem por categoria sobre o mesmo conjunto de dados
+- Navegar entre as views de lista e detalhe mantendo o estado consistente
+- Paginar ou revelar preguiçosamente uma lista longa sem sobrecarregar o DOM
+- Apresentar tipografia legível e uma ordem de leitura acessível
+
+## Requisitos Funcionais
+
+1. A view inicial lista posts com título, resumo, categoria e tempo estimado de leitura.
+2. Selecionar um post abre uma view de detalhe mostrando seu conteúdo completo.
+3. Uma caixa de busca filtra a lista comparando o texto do título ou do resumo.
+4. Filtros de categoria restringem a lista; limpá-los restaura o conjunto completo.
+5. Uma lista longa é paginada ou usa "carregar mais" em vez de renderizar tudo de uma vez.
+6. O usuário pode retornar de uma view de detalhe para a lista sem perder seu filtro.
+7. Cada detalhe de post tem um único `h1` e uma estrutura lógica de títulos.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Lista e detalhe:** Carregue os posts e renderize a lista, depois uma view de detalhe completa na seleção.
+2. **Marco 2 — Busca e filtro:** Adicione busca por texto e filtragem por categoria sobre o conjunto de dados.
+3. **Marco 3 — Navegação e paginação:** Preserve filtros entre views e pagine a lista.
+
+## Esboço de Dados e Interface
+
+```text
+Post
+  id:          string
+  title:       string
+  excerpt:     string
+  body:        string
+  category:    string
+  publishedAt: string   (ISO-8601)
+  readMinutes: number
+
+Views
+  list   -> array filtrado/paginado de resumos de Post
+  detail -> um Post por id
+
+Layout (lista)               Layout (detalhe)
++-------------------------+   +----------------------+
+| [ busca ] [Categoria v] |   | < Voltar             |
++-------------------------+   | Título (h1)          |
+| Cartão de post          |   | meta: cat · 5 min    |
+| Cartão de post          |   |                      |
+| Cartão de post          |   | parágrafos...        |
++-------------------------+   +----------------------+
+| < 1 2 3 >               |
++-------------------------+
+```
+
+## Desafios Extras
+
+- Sincronize a view atual e os filtros com a URL (query params ou hash) para que os links sejam compartilháveis.
+- Adicione uma nuvem de tags e cruze links de posts relacionados por tags compartilhadas.
+- Adicione um sumário gerado a partir dos títulos do post.
+- Mostre um estado vazio de "nenhum resultado" com uma forma de resetar os filtros.
+
+## Definição de Pronto
+
+- [ ] As views de lista e detalhe renderizam os mesmos dados corretamente de uma fonte.
+- [ ] Busca e filtros de categoria se combinam e podem ser limpos.
+- [ ] Retornar à lista preserva a busca e o filtro ativos.
+- [ ] Uma lista longa não renderiza todos os posts no DOM de uma vez.
+- [ ] Cada página de detalhe tem exatamente um `h1` e títulos ordenados.
+
+## Armadilhas Comuns
+
+- Duplicar os dados do post para a lista e o detalhe em vez de derivar ambos de uma fonte.
+- Perder o filtro ativo ao voltar de uma view de detalhe.
+- Busca sensível a maiúsculas que perde correspondências óbvias.
+- Renderizar centenas de cartões de imediato, deixando a página travada.
+- Esquecer um estado vazio, fazendo uma lista totalmente filtrada parecer um bug.
+
+## Recursos
+
+- [MDN: Array.prototype.filter()](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Array/filter) — construir busca e filtragem por categoria.
+- [MDN: History API](https://developer.mozilla.org/pt-BR/docs/Web/API/History_API) — refletir views na URL.
+- [web.dev: Learn Accessibility — Content structure](https://web.dev/learn/accessibility/structure) — títulos e ordem de leitura.
+- [MDN: Trabalhando com JSON](https://developer.mozilla.org/pt-BR/docs/Learn/JavaScript/Objects/JSON) — carregar e analisar dados locais.
diff --git a/projects/frontend/beginner/06-login-register-forms/README.md b/projects/frontend/beginner/06-login-register-forms/README.md
index 93b095d..04448b2 100644
--- a/projects/frontend/beginner/06-login-register-forms/README.md
+++ b/projects/frontend/beginner/06-login-register-forms/README.md
@@ -1,34 +1,98 @@
-# Login/Register Forms
+# Login & Register Forms
 
-## Idea
-Build authentication forms for user login and registration. Learn about form validation, error handling, and secure input handling.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build the front end for authentication: a login form and a registration form with real, client-side validation. There is no backend — you simulate submission — so the lesson is entirely about form UX, which is where a huge amount of frontend craft lives. You will validate fields as the user types, show precise error messages next to the right inputs, disable submission until the form is valid, and do all of it accessibly so screen-reader users know exactly what went wrong. Getting validation timing and messaging right is the difference between a form people complete and one they abandon.
+
+## Prerequisites
+
+- HTML forms, inputs, and the `<label>` element
+- JavaScript event handling (`input`, `submit`, `blur`)
+- Regular expressions or built-in validation for pattern checks
+- A basic grasp of why client validation is UX, not security
 
 ## Learning Objectives
-- Implement form validation
-- Handle form submissions
-- Display validation errors
-- Manage form state
-- Implement password validation rules
-
-## Implementation Tips
-- Create login form with email and password
-- Create register form with validation
-- Implement real-time validation
-- Add password strength indicator
-- Show/hide password toggle
-- Implement form error messages
-- Add success confirmation
-- Create "forgot password" flow
-- Implement email validation
-- Add terms and conditions checkbox
-- Create social login buttons (UI)
-- Implement loading state during submission
-- Add CAPTCHA (optional)
-- Create remember me functionality
-
-## Key Challenges
-- Complex validation rules
-- Error message presentation
-- Password security display
-- Form state management
-- Preventing double submission
+
+By the end, you should be able to:
+
+- Validate fields on the right events (on blur / on submit, not aggressively on first keystroke)
+- Associate error messages with inputs using `aria-describedby` and `aria-invalid`
+- Manage form state: values, touched fields, errors, and submit-disabled logic
+- Build a password strength indicator and a show/hide password toggle
+- Prevent double submission and give clear success feedback
+
+## Functional Requirements
+
+1. The registration form validates email format, password rules, and password confirmation match.
+2. Errors appear next to the relevant field and are announced to assistive technology.
+3. The submit button is disabled (or blocks submission) while the form is invalid.
+4. A password strength indicator updates as the user types.
+5. A show/hide toggle reveals or masks the password field.
+6. The login form validates required fields and shows a single form-level error on "failure".
+7. Submitting shows a loading state, then a success confirmation, preventing double submits.
+
+## Suggested Milestones
+
+1. **Milestone 1 — Structure & labels:** Build both forms with properly labelled, accessible inputs.
+2. **Milestone 2 — Validation:** Add field validation, error messaging, and submit gating.
+3. **Milestone 3 — Feedback & polish:** Add strength meter, show/hide, loading, and success states.
+
+## Data & Interface Sketch
+
+```text
+Field state (per input)
+  value:   string
+  touched: boolean
+  error:   string | null
+
+Register form fields
+  email             -> valid email pattern
+  password          -> min length, mixed character rules
+  confirmPassword   -> must equal password
+  acceptTerms       -> must be checked
+
+Layout (register)
++----------------------------------+
+| Email    [ .................. ]  |
+|          error text (aria)       |
+| Password [ ............ ] [👁]    |
+|          [====----] Medium       |
+| Confirm  [ .................. ]  |
+| [x] I accept the terms           |
+| [        Create account       ]  |  <- disabled until valid
++----------------------------------+
+```
+
+## Stretch Goals
+
+- Add a "forgot password" request form with its own validation.
+- Persist a draft of the registration form to `sessionStorage`.
+- Add inline "available/taken" username checking against a mock list.
+- Support submit-on-Enter and full keyboard navigation with a logical tab order.
+
+## Definition of Done
+
+- [ ] Every input has a programmatically associated label.
+- [ ] Errors are tied to inputs via `aria-describedby` and set `aria-invalid`.
+- [ ] Submission is blocked while any field is invalid.
+- [ ] The password toggle changes the input type without losing the value.
+- [ ] A submit cannot fire twice, and success is clearly communicated.
+
+## Common Pitfalls
+
+- Validating on every keystroke from the first character, so users see errors before they finish typing.
+- Using `placeholder` as a substitute for `<label>`, which disappears and fails accessibility.
+- Showing a generic "invalid form" message instead of field-specific errors.
+- Treating client validation as security — the real check must happen on a server.
+- Forgetting to focus or announce errors, leaving screen-reader users stuck.
+
+## Resources
+
+- [MDN: Client-side form validation](https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation) — constraints and custom messages.
+- [web.dev: Sign-in form best practices](https://web.dev/articles/sign-in-form-best-practices) — real-world form UX guidance.
+- [MDN: aria-invalid](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-invalid) — signalling invalid fields to AT.
+- [WAI: Form instructions & errors](https://www.w3.org/WAI/tutorials/forms/) — accessible form patterns.
diff --git a/projects/frontend/beginner/06-login-register-forms/README.pt-BR.md b/projects/frontend/beginner/06-login-register-forms/README.pt-BR.md
new file mode 100644
index 0000000..a6af9bb
--- /dev/null
+++ b/projects/frontend/beginner/06-login-register-forms/README.pt-BR.md
@@ -0,0 +1,98 @@
+# Formulários de Login e Cadastro
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa o front-end da autenticação: um formulário de login e um de cadastro com validação real no cliente. Não há backend — você simula o envio — então a lição é inteiramente sobre a UX de formulários, onde reside boa parte do ofício de frontend. Você vai validar campos conforme o usuário digita, mostrar mensagens de erro precisas ao lado dos campos certos, desabilitar o envio até que o formulário seja válido, e fazer tudo isso de forma acessível para que usuários de leitor de tela saibam exatamente o que deu errado. Acertar o momento e a mensagem da validação é a diferença entre um formulário que as pessoas completam e um que abandonam.
+
+## Pré-requisitos
+
+- Formulários HTML, inputs e o elemento `<label>`
+- Tratamento de eventos em JavaScript (`input`, `submit`, `blur`)
+- Expressões regulares ou validação nativa para verificações de padrão
+- Uma noção básica de por que a validação no cliente é UX, não segurança
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Validar campos nos eventos certos (ao sair / ao enviar, não agressivamente à primeira tecla)
+- Associar mensagens de erro a inputs usando `aria-describedby` e `aria-invalid`
+- Gerenciar o estado do formulário: valores, campos tocados, erros e lógica de envio desabilitado
+- Construir um indicador de força de senha e um alternador mostrar/ocultar senha
+- Prevenir envio duplo e dar feedback de sucesso claro
+
+## Requisitos Funcionais
+
+1. O formulário de cadastro valida formato de e-mail, regras de senha e correspondência da confirmação de senha.
+2. Erros aparecem ao lado do campo relevante e são anunciados à tecnologia assistiva.
+3. O botão de envio é desabilitado (ou bloqueia o envio) enquanto o formulário é inválido.
+4. Um indicador de força de senha atualiza conforme o usuário digita.
+5. Um alternador mostrar/ocultar revela ou mascara o campo de senha.
+6. O formulário de login valida campos obrigatórios e mostra um único erro de nível de formulário em caso de "falha".
+7. Enviar mostra um estado de carregamento, depois uma confirmação de sucesso, prevenindo envios duplos.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Estrutura e rótulos:** Construa ambos os formulários com inputs devidamente rotulados e acessíveis.
+2. **Marco 2 — Validação:** Adicione validação de campo, mensagens de erro e bloqueio de envio.
+3. **Marco 3 — Feedback e polimento:** Adicione medidor de força, mostrar/ocultar, carregamento e estados de sucesso.
+
+## Esboço de Dados e Interface
+
+```text
+Estado do campo (por input)
+  value:   string
+  touched: boolean
+  error:   string | null
+
+Campos do cadastro
+  email             -> padrão de e-mail válido
+  password          -> tamanho mínimo, regras de caracteres mistos
+  confirmPassword   -> deve ser igual a password
+  acceptTerms       -> deve estar marcado
+
+Layout (cadastro)
++----------------------------------+
+| Email    [ .................. ]  |
+|          texto de erro (aria)    |
+| Senha    [ ............ ] [👁]    |
+|          [====----] Média        |
+| Confirme [ .................. ]  |
+| [x] Aceito os termos             |
+| [        Criar conta          ]  |  <- desabilitado até ser válido
++----------------------------------+
+```
+
+## Desafios Extras
+
+- Adicione um formulário de "esqueci minha senha" com sua própria validação.
+- Persista um rascunho do formulário de cadastro no `sessionStorage`.
+- Adicione verificação em linha de "disponível/em uso" de nome de usuário contra uma lista simulada.
+- Suporte envio ao Enter e navegação completa por teclado com uma ordem lógica de tabulação.
+
+## Definição de Pronto
+
+- [ ] Todo input tem um rótulo associado programaticamente.
+- [ ] Erros estão vinculados aos inputs via `aria-describedby` e definem `aria-invalid`.
+- [ ] O envio é bloqueado enquanto qualquer campo é inválido.
+- [ ] O alternador de senha muda o tipo do input sem perder o valor.
+- [ ] Um envio não pode disparar duas vezes, e o sucesso é claramente comunicado.
+
+## Armadilhas Comuns
+
+- Validar a cada tecla desde o primeiro caractere, fazendo os usuários verem erros antes de terminarem de digitar.
+- Usar `placeholder` como substituto de `<label>`, que desaparece e falha na acessibilidade.
+- Mostrar uma mensagem genérica de "formulário inválido" em vez de erros específicos por campo.
+- Tratar a validação no cliente como segurança — a verificação real deve ocorrer em um servidor.
+- Esquecer de focar ou anunciar erros, deixando usuários de leitor de tela travados.
+
+## Recursos
+
+- [MDN: Validação de formulário no cliente](https://developer.mozilla.org/pt-BR/docs/Learn/Forms/Form_validation) — restrições e mensagens personalizadas.
+- [web.dev: Sign-in form best practices](https://web.dev/articles/sign-in-form-best-practices) — orientação de UX de formulários do mundo real.
+- [MDN: aria-invalid](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-invalid) — sinalizar campos inválidos à tecnologia assistiva.
+- [WAI: Instruções e erros de formulário](https://www.w3.org/WAI/tutorials/forms/) — padrões de formulários acessíveis.
diff --git a/projects/frontend/beginner/07-image-gallery/README.md b/projects/frontend/beginner/07-image-gallery/README.md
index 6ab0978..0640a7d 100644
--- a/projects/frontend/beginner/07-image-gallery/README.md
+++ b/projects/frontend/beginner/07-image-gallery/README.md
@@ -1,34 +1,96 @@
 # Image Gallery
 
-## Idea
-Create an interactive image gallery with navigation and preview capabilities. Learn about DOM manipulation, event handling, and image optimization.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build a responsive image gallery: a grid of thumbnails that opens a larger image in a lightbox overlay when clicked, with previous/next navigation. The grid teaches responsive layout with CSS Grid; the lightbox teaches something harder and more valuable — building an accessible modal. A real lightbox must trap keyboard focus, close on Escape, restore focus when it closes, and be operable with arrow keys. Add lazy image loading and you have a project that touches layout, interaction, and performance in one compact package.
+
+## Prerequisites
+
+- HTML, CSS, and JavaScript fundamentals
+- CSS Grid for responsive layouts
+- DOM event handling including keyboard events
+- A folder of sample images or a placeholder image service
 
 ## Learning Objectives
-- Implement image carousel
-- Handle navigation between images
-- Implement lightbox/modal display
-- Optimize image loading
-- Handle keyboard navigation
-
-## Implementation Tips
-- Create gallery grid layout
-- Implement image preview modal
-- Add previous/next navigation
-- Implement thumbnail navigation
-- Add keyboard arrow navigation
-- Create lazy loading for images
-- Add image zoom functionality
-- Implement full-screen view
-- Add image information display
-- Create smooth transitions
-- Implement swipe gestures
-- Add image filtering by category
-- Create slideshow mode
-- Add download button
-
-## Key Challenges
-- Image loading performance
-- Responsive grid design
-- Gesture handling
-- Memory management for many images
-- Touch/mouse input coordination
+
+By the end, you should be able to:
+
+- Build a responsive grid that adapts columns to the viewport with `auto-fill`/`minmax`
+- Implement an accessible modal/lightbox with focus trapping and restoration
+- Navigate images with previous/next buttons and arrow keys
+- Lazy-load offscreen images to reduce initial load
+- Provide meaningful `alt` text and keyboard-operable controls
+
+## Functional Requirements
+
+1. Images display in a responsive grid that reflows by viewport width.
+2. Clicking a thumbnail opens a lightbox showing the full-size image.
+3. The lightbox supports previous/next navigation via buttons and arrow keys.
+4. Escape closes the lightbox and focus returns to the triggering thumbnail.
+5. While the lightbox is open, keyboard focus stays trapped within it.
+6. Offscreen images load lazily rather than all at once on page load.
+7. Every image has descriptive `alt` text, and controls are labelled.
+
+## Suggested Milestones
+
+1. **Milestone 1 — Responsive grid:** Render thumbnails in a grid that adapts to screen width.
+2. **Milestone 2 — Lightbox:** Open a full image overlay with previous/next controls.
+3. **Milestone 3 — A11y & performance:** Add focus trap, Escape, keyboard nav, and lazy loading.
+
+## Data & Interface Sketch
+
+```text
+Image
+  id:      string
+  src:     string   (full)
+  thumb:   string   (small)
+  alt:     string
+  width:   number
+  height:  number
+
+Lightbox state
+  isOpen:  boolean
+  index:   number    (current image)
+
+Grid (auto-fill columns)        Lightbox overlay
++-----+-----+-----+-----+       +------------------------+
+| img | img | img | img |       |  [X]                   |
++-----+-----+-----+-----+       |   <   [ image ]   >    |
+| img | img | img | img |  -->  |                        |
++-----+-----+-----+-----+       |   3 / 12   caption     |
+                                +------------------------+
+```
+
+## Stretch Goals
+
+- Add swipe gestures for touch devices to move between images.
+- Add a thumbnail strip inside the lightbox showing position in the set.
+- Add a slideshow mode that auto-advances, pausable and respecting reduced motion.
+- Use `IntersectionObserver` for lazy loading instead of the `loading` attribute.
+
+## Definition of Done
+
+- [ ] The grid reflows without overflow from mobile to desktop.
+- [ ] The lightbox opens, navigates, and closes by both mouse and keyboard.
+- [ ] Focus is trapped while open and restored to the trigger on close.
+- [ ] Images below the fold do not load until needed.
+- [ ] All images carry appropriate `alt` text.
+
+## Common Pitfalls
+
+- Building the lightbox as a plain overlay that lets focus and Tab escape behind it.
+- Not restoring focus on close, so keyboard users lose their place.
+- Forgetting to set explicit image dimensions, causing layout shift as images load.
+- Loading full-resolution images as thumbnails, wasting bandwidth.
+- Making the close and nav controls non-focusable `<div>`s.
+
+## Resources
+
+- [MDN: CSS Grid Layout](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout) — responsive grids with `minmax` and `auto-fill`.
+- [MDN: Lazy loading](https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading) — deferring offscreen images.
+- [WAI-ARIA: Dialog (Modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/) — focus trap and keyboard behavior.
+- [web.dev: prefers-reduced-motion](https://web.dev/articles/prefers-reduced-motion) — respecting motion preferences.
diff --git a/projects/frontend/beginner/07-image-gallery/README.pt-BR.md b/projects/frontend/beginner/07-image-gallery/README.pt-BR.md
new file mode 100644
index 0000000..959308b
--- /dev/null
+++ b/projects/frontend/beginner/07-image-gallery/README.pt-BR.md
@@ -0,0 +1,96 @@
+# Galeria de Imagens
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa uma galeria de imagens responsiva: uma grade de miniaturas que abre uma imagem maior em uma sobreposição lightbox ao ser clicada, com navegação anterior/próxima. A grade ensina layout responsivo com CSS Grid; o lightbox ensina algo mais difícil e mais valioso — construir um modal acessível. Um lightbox de verdade deve prender o foco do teclado, fechar no Escape, restaurar o foco ao fechar e ser operável com as setas. Adicione carregamento preguiçoso de imagens e você tem um projeto que toca layout, interação e desempenho em um pacote compacto.
+
+## Pré-requisitos
+
+- Fundamentos de HTML, CSS e JavaScript
+- CSS Grid para layouts responsivos
+- Tratamento de eventos do DOM, incluindo eventos de teclado
+- Uma pasta de imagens de exemplo ou um serviço de imagens de placeholder
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Construir uma grade responsiva que adapta as colunas à viewport com `auto-fill`/`minmax`
+- Implementar um modal/lightbox acessível com prisão e restauração de foco
+- Navegar por imagens com botões anterior/próxima e teclas de seta
+- Carregar preguiçosamente imagens fora da tela para reduzir a carga inicial
+- Fornecer texto `alt` significativo e controles operáveis por teclado
+
+## Requisitos Funcionais
+
+1. As imagens são exibidas em uma grade responsiva que se rearranja pela largura da viewport.
+2. Clicar em uma miniatura abre um lightbox mostrando a imagem em tamanho cheio.
+3. O lightbox suporta navegação anterior/próxima via botões e teclas de seta.
+4. Escape fecha o lightbox e o foco retorna à miniatura que o acionou.
+5. Enquanto o lightbox está aberto, o foco do teclado permanece preso dentro dele.
+6. Imagens fora da tela carregam preguiçosamente em vez de todas de uma vez no carregamento.
+7. Toda imagem tem texto `alt` descritivo, e os controles são rotulados.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Grade responsiva:** Renderize miniaturas em uma grade que se adapta à largura da tela.
+2. **Marco 2 — Lightbox:** Abra uma sobreposição de imagem cheia com controles anterior/próxima.
+3. **Marco 3 — Acessibilidade e desempenho:** Adicione prisão de foco, Escape, navegação por teclado e carregamento preguiçoso.
+
+## Esboço de Dados e Interface
+
+```text
+Image
+  id:      string
+  src:     string   (cheia)
+  thumb:   string   (pequena)
+  alt:     string
+  width:   number
+  height:  number
+
+Estado do lightbox
+  isOpen:  boolean
+  index:   number    (imagem atual)
+
+Grade (colunas auto-fill)       Sobreposição do lightbox
++-----+-----+-----+-----+       +------------------------+
+| img | img | img | img |       |  [X]                   |
++-----+-----+-----+-----+       |   <   [ imagem ]   >   |
+| img | img | img | img |  -->  |                        |
++-----+-----+-----+-----+       |   3 / 12   legenda     |
+                                +------------------------+
+```
+
+## Desafios Extras
+
+- Adicione gestos de deslizar para dispositivos de toque moverem entre imagens.
+- Adicione uma tira de miniaturas dentro do lightbox mostrando a posição no conjunto.
+- Adicione um modo de slideshow que avança automaticamente, pausável e respeitando movimento reduzido.
+- Use `IntersectionObserver` para carregamento preguiçoso em vez do atributo `loading`.
+
+## Definição de Pronto
+
+- [ ] A grade se rearranja sem estouro do celular ao desktop.
+- [ ] O lightbox abre, navega e fecha por mouse e por teclado.
+- [ ] O foco fica preso enquanto aberto e é restaurado ao acionador ao fechar.
+- [ ] Imagens abaixo da dobra não carregam até serem necessárias.
+- [ ] Todas as imagens carregam texto `alt` apropriado.
+
+## Armadilhas Comuns
+
+- Construir o lightbox como uma sobreposição simples que deixa o foco e o Tab escaparem para trás dele.
+- Não restaurar o foco ao fechar, fazendo usuários de teclado perderem o lugar.
+- Esquecer de definir dimensões explícitas de imagem, causando deslocamento de layout enquanto elas carregam.
+- Carregar imagens em resolução cheia como miniaturas, desperdiçando banda.
+- Fazer os controles de fechar e navegar serem `<div>`s não focáveis.
+
+## Recursos
+
+- [MDN: CSS Grid Layout](https://developer.mozilla.org/pt-BR/docs/Web/CSS/CSS_grid_layout) — grades responsivas com `minmax` e `auto-fill`.
+- [MDN: Lazy loading](https://developer.mozilla.org/pt-BR/docs/Web/Performance/Lazy_loading) — adiar imagens fora da tela.
+- [WAI-ARIA: Dialog (Modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/) — prisão de foco e comportamento de teclado.
+- [web.dev: prefers-reduced-motion](https://web.dev/articles/prefers-reduced-motion) — respeitar preferências de movimento.
diff --git a/projects/frontend/beginner/08-notes-ui/README.md b/projects/frontend/beginner/08-notes-ui/README.md
index 5b8da8f..d630182 100644
--- a/projects/frontend/beginner/08-notes-ui/README.md
+++ b/projects/frontend/beginner/08-notes-ui/README.md
@@ -1,34 +1,97 @@
-# Notes UI (local storage)
+# Notes UI (Local Storage)
 
-## Idea
-Build a note-taking application with local storage persistence. Learn about data management, rich text editing, and local storage operations.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build a note-taking app: a list of notes on one side, an editor on the other, and everything saved to `localStorage` so it survives a reload. It is the To-do list grown up — instead of one-line items you have titled, editable documents, and instead of a single action you have full create-read-update-delete. The core challenge is the master-detail pattern: a list and an editor that stay in sync, where selecting a note loads it, editing updates it live, and deleting cleans up without leaving a dangling selection. Add search and auto-save and it starts to feel like a real tool.
+
+## Prerequisites
+
+- HTML, CSS, and JavaScript fundamentals
+- The `localStorage` API and `JSON` serialization
+- Array/object manipulation for CRUD operations
+- Debouncing basics for auto-save (or a timer)
 
 ## Learning Objectives
-- Implement local storage operations
-- Build note creation interface
-- Implement rich text editing
-- Manage note list and detail views
-- Handle data synchronization
-
-## Implementation Tips
-- Create note list view
-- Implement note creation and editing
-- Add note deletion with confirmation
-- Create search functionality
-- Implement tags or categories
-- Add note color coding
-- Implement note timestamps
-- Create note formatting (bold, italic, lists)
-- Add note export functionality
-- Implement note pinning
-- Add note sorting options
-- Create folder/organization system
-- Add markdown support (optional)
-- Implement undo/redo functionality
-
-## Key Challenges
-- Local storage data management
-- Rich text editor implementation
-- Search algorithm efficiency
-- Data consistency
-- Large note handling
+
+By the end, you should be able to:
+
+- Implement full CRUD over a collection persisted in `localStorage`
+- Build a master-detail layout where a list and editor stay synchronized
+- Auto-save edits with debouncing instead of a manual save button
+- Search/filter notes by title or content in real time
+- Handle edge cases: no notes, deleting the selected note, empty titles
+
+## Functional Requirements
+
+1. The user can create a new note, which appears in the list and opens in the editor.
+2. Editing a note's title or body updates the list and persists automatically.
+3. The user can delete a note, with a confirmation, and the selection resets sensibly.
+4. A search box filters the note list by title or content.
+5. Notes persist across reloads via `localStorage`.
+6. Each note shows a last-updated timestamp that reflects real edits.
+7. An empty state is shown when there are no notes or no search matches.
+
+## Suggested Milestones
+
+1. **Milestone 1 — List & create:** Render the note list and support creating and selecting notes.
+2. **Milestone 2 — Edit & persist:** Edit title/body, auto-save to `localStorage`, update timestamps.
+3. **Milestone 3 — Delete & search:** Add delete with confirmation and live search over notes.
+
+## Data & Interface Sketch
+
+```text
+Note
+  id:        string   (crypto.randomUUID())
+  title:     string
+  body:      string
+  updatedAt: number   (Date.now())
+
+App state
+  notes:      Note[]
+  selectedId: string | null
+  query:      string
+
+Layout (master-detail)
++------------------+-----------------------------+
+| [ search....... ]| Title [ ................. ] |
+| + New note       |                             |
+|------------------|  body textarea              |
+| > Groceries   ·  |  ...                        |
+|   Meeting     ·  |                             |
+|   Ideas       ·  |  updated 2m ago    [Delete] |
++------------------+-----------------------------+
+```
+
+## Stretch Goals
+
+- Add pinning so important notes stay at the top of the list.
+- Add tags or folders and filter by them.
+- Support basic Markdown rendering in a preview pane.
+- Add export/import of all notes as a single JSON file.
+
+## Definition of Done
+
+- [ ] Create, edit, and delete all update the list, editor, and stored data.
+- [ ] Edits auto-save without a manual save action.
+- [ ] Deleting the selected note leaves a sensible selection or empty state.
+- [ ] Search filters the list in real time and shows an empty state when nothing matches.
+- [ ] All notes survive a page reload intact.
+
+## Common Pitfalls
+
+- Writing to `localStorage` on every keystroke without debouncing, causing jank.
+- Losing the current selection or crashing when the selected note is deleted.
+- Keeping the editor's value out of sync with the stored note after a switch.
+- Exceeding the `localStorage` quota with large notes and not handling the error.
+- Forgetting the empty state, so a fresh app looks broken.
+
+## Resources
+
+- [MDN: Web Storage API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API) — persisting and reading structured data.
+- [MDN: JSON.stringify()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) — serializing your note collection.
+- [CSS-Tricks: Debouncing and Throttling](https://css-tricks.com/debouncing-throttling-explained-examples/) — rate-limiting auto-save.
+- [web.dev: Learn Forms — textarea](https://web.dev/learn/forms/textareas) — accessible multi-line input.
diff --git a/projects/frontend/beginner/08-notes-ui/README.pt-BR.md b/projects/frontend/beginner/08-notes-ui/README.pt-BR.md
new file mode 100644
index 0000000..770cb79
--- /dev/null
+++ b/projects/frontend/beginner/08-notes-ui/README.pt-BR.md
@@ -0,0 +1,97 @@
+# Interface de Notas (Local Storage)
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa um app de anotações: uma lista de notas de um lado, um editor do outro, e tudo salvo no `localStorage` para sobreviver a um recarregamento. É a lista de tarefas amadurecida — em vez de itens de uma linha, você tem documentos titulados e editáveis, e em vez de uma única ação, você tem criar-ler-atualizar-excluir completo. O desafio central é o padrão mestre-detalhe: uma lista e um editor que ficam sincronizados, onde selecionar uma nota a carrega, editar a atualiza ao vivo e excluir limpa sem deixar uma seleção órfã. Adicione busca e salvamento automático e começa a parecer uma ferramenta de verdade.
+
+## Pré-requisitos
+
+- Fundamentos de HTML, CSS e JavaScript
+- A API `localStorage` e serialização `JSON`
+- Manipulação de arrays/objetos para operações CRUD
+- Básico de debouncing para salvamento automático (ou um temporizador)
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Implementar CRUD completo sobre uma coleção persistida no `localStorage`
+- Construir um layout mestre-detalhe onde uma lista e um editor ficam sincronizados
+- Salvar edições automaticamente com debouncing em vez de um botão de salvar manual
+- Buscar/filtrar notas por título ou conteúdo em tempo real
+- Tratar casos limítrofes: nenhuma nota, excluir a nota selecionada, títulos vazios
+
+## Requisitos Funcionais
+
+1. O usuário pode criar uma nova nota, que aparece na lista e abre no editor.
+2. Editar o título ou o corpo de uma nota atualiza a lista e persiste automaticamente.
+3. O usuário pode excluir uma nota, com uma confirmação, e a seleção é resetada de forma sensata.
+4. Uma caixa de busca filtra a lista de notas por título ou conteúdo.
+5. As notas persistem entre recarregamentos via `localStorage`.
+6. Cada nota mostra um carimbo de data/hora de última atualização que reflete edições reais.
+7. Um estado vazio é mostrado quando não há notas ou nenhuma correspondência de busca.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Lista e criação:** Renderize a lista de notas e suporte criar e selecionar notas.
+2. **Marco 2 — Editar e persistir:** Edite título/corpo, salve automaticamente no `localStorage`, atualize os carimbos de data/hora.
+3. **Marco 3 — Excluir e buscar:** Adicione exclusão com confirmação e busca ao vivo sobre as notas.
+
+## Esboço de Dados e Interface
+
+```text
+Note
+  id:        string   (crypto.randomUUID())
+  title:     string
+  body:      string
+  updatedAt: number   (Date.now())
+
+Estado do app
+  notes:      Note[]
+  selectedId: string | null
+  query:      string
+
+Layout (mestre-detalhe)
++------------------+-----------------------------+
+| [ busca........ ]| Título [ ................ ] |
+| + Nova nota      |                             |
+|------------------|  textarea do corpo          |
+| > Compras     ·  |  ...                        |
+|   Reunião     ·  |                             |
+|   Ideias      ·  |  atualizado há 2m  [Excluir]|
++------------------+-----------------------------+
+```
+
+## Desafios Extras
+
+- Adicione fixação para que notas importantes fiquem no topo da lista.
+- Adicione tags ou pastas e filtre por elas.
+- Suporte renderização básica de Markdown em um painel de pré-visualização.
+- Adicione exportar/importar todas as notas como um único arquivo JSON.
+
+## Definição de Pronto
+
+- [ ] Criar, editar e excluir atualizam a lista, o editor e os dados armazenados.
+- [ ] As edições são salvas automaticamente sem uma ação manual de salvar.
+- [ ] Excluir a nota selecionada deixa uma seleção sensata ou um estado vazio.
+- [ ] A busca filtra a lista em tempo real e mostra um estado vazio quando nada corresponde.
+- [ ] Todas as notas sobrevivem intactas a um recarregamento da página.
+
+## Armadilhas Comuns
+
+- Escrever no `localStorage` a cada tecla sem debouncing, causando travamentos.
+- Perder a seleção atual ou travar quando a nota selecionada é excluída.
+- Manter o valor do editor fora de sincronia com a nota armazenada após uma troca.
+- Exceder a cota do `localStorage` com notas grandes e não tratar o erro.
+- Esquecer o estado vazio, fazendo um app recém-aberto parecer quebrado.
+
+## Recursos
+
+- [MDN: Web Storage API](https://developer.mozilla.org/pt-BR/docs/Web/API/Web_Storage_API) — persistir e ler dados estruturados.
+- [MDN: JSON.stringify()](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) — serializar sua coleção de notas.
+- [CSS-Tricks: Debouncing and Throttling](https://css-tricks.com/debouncing-throttling-explained-examples/) — limitar a taxa do salvamento automático.
+- [web.dev: Learn Forms — textarea](https://web.dev/learn/forms/textareas) — entrada de múltiplas linhas acessível.
diff --git a/projects/frontend/beginner/09-quiz-app/README.md b/projects/frontend/beginner/09-quiz-app/README.md
index bea9139..28dd250 100644
--- a/projects/frontend/beginner/09-quiz-app/README.md
+++ b/projects/frontend/beginner/09-quiz-app/README.md
@@ -1,34 +1,99 @@
 # Quiz App
 
-## Idea
-Create an interactive quiz application with questions, scoring, and results display. Learn about conditional rendering, state management, and user progress tracking.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build a multiple-choice quiz that walks a user through a set of questions one at a time, records their answers, and shows a scored results screen at the end. The questions live in a local array, so the work is all about flow and state: which question are we on, what has been answered, and what does the screen show right now. It is a clean introduction to conditional rendering and a tiny state machine — start, in-progress, and finished — plus the accessible rendering of radio-group choices where keyboard users can move and select without a mouse.
+
+## Prerequisites
+
+- HTML, CSS, and JavaScript fundamentals
+- Array iteration and index tracking
+- Conditional rendering (show one view based on state)
+- Accessible radio groups and buttons
 
 ## Learning Objectives
-- Manage quiz state and progress
-- Implement scoring logic
-- Display conditional content
-- Handle user answers
-- Show results and statistics
-
-## Implementation Tips
-- Design question and answer display
-- Implement next/previous navigation
-- Create progress tracking
-- Calculate and display score
-- Show correct answers after completion
-- Implement timer per question (optional)
-- Create difficulty levels
-- Add question randomization
-- Implement review mode
-- Create result breakdown
-- Add score sharing
-- Implement leaderboard (local)
-- Create multiple quiz support
-- Add category selection
-
-## Key Challenges
-- Quiz state management
-- Score calculation
-- Progress tracking accuracy
-- Timer synchronization
-- Question randomization fairness
+
+By the end, you should be able to:
+
+- Model quiz progress as explicit state (current index, answers, phase)
+- Render one question at a time and move forward/back through the set
+- Compute a score from recorded answers, not from the DOM
+- Show a results screen with a per-question review
+- Build an accessible radio group with keyboard selection and clear focus
+
+## Functional Requirements
+
+1. Questions are shown one at a time with their answer options.
+2. The user selects one answer per question and can go to the next question.
+3. A progress indicator shows the current position (e.g. "Question 3 of 10").
+4. At the end, a results screen shows the score and which answers were right or wrong.
+5. Answer options form an accessible radio group navigable by keyboard.
+6. The user cannot advance past the last question without seeing results.
+7. A restart option resets all state and returns to the first question.
+
+## Suggested Milestones
+
+1. **Milestone 1 — Render & answer:** Show one question with selectable options and record the choice.
+2. **Milestone 2 — Navigation & progress:** Move between questions and display progress.
+3. **Milestone 3 — Scoring & review:** Compute the score and render a results/review screen.
+
+## Data & Interface Sketch
+
+```text
+Question
+  id:       string
+  prompt:   string
+  options:  string[]
+  answer:   number   (index of correct option)
+
+Quiz state
+  phase:    "start" | "playing" | "finished"
+  index:    number
+  answers:  (number | null)[]   (one slot per question)
+
+Layout (playing)
++------------------------------------------+
+| Question 3 of 10        [====------]     |
++------------------------------------------+
+| What does CSS stand for?                 |
+|  ( ) Cascading Style Sheets              |
+|  ( ) Computer Style System               |
+|  ( ) Creative Styling Syntax             |
++------------------------------------------+
+| [ Back ]                     [ Next ]    |
++------------------------------------------+
+```
+
+## Stretch Goals
+
+- Add an optional per-question countdown timer that auto-advances on expiry.
+- Randomize question and option order on each run.
+- Support multiple quizzes/categories chosen from a start screen.
+- Persist a local high score across sessions with `localStorage`.
+
+## Definition of Done
+
+- [ ] Exactly one question shows at a time with its options.
+- [ ] Progress accurately reflects the current question.
+- [ ] The final score matches the recorded answers.
+- [ ] Options are a keyboard-navigable radio group with visible focus.
+- [ ] Restart fully resets state back to the first question.
+
+## Common Pitfalls
+
+- Reading the selected answer from the DOM instead of tracking it in state.
+- Off-by-one errors in the progress counter or the last-question boundary.
+- Using clickable `<div>`s for options, breaking keyboard and screen-reader use.
+- Recomputing score incorrectly when a user changes an earlier answer.
+- Not resetting every piece of state on restart, leaking the previous run.
+
+## Resources
+
+- [MDN: <input type="radio">](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/radio) — grouping and default keyboard behavior.
+- [WAI-ARIA: Radio Group pattern](https://www.w3.org/WAI/ARIA/apg/patterns/radio/) — accessible custom radio groups.
+- [MDN: Conditional rendering with JavaScript](https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Building_blocks/conditionals) — switching views by state.
+- [web.dev: Learn Accessibility — Focus](https://web.dev/learn/accessibility/focus) — managing and showing focus.
diff --git a/projects/frontend/beginner/09-quiz-app/README.pt-BR.md b/projects/frontend/beginner/09-quiz-app/README.pt-BR.md
new file mode 100644
index 0000000..db8ba0d
--- /dev/null
+++ b/projects/frontend/beginner/09-quiz-app/README.pt-BR.md
@@ -0,0 +1,99 @@
+# Aplicativo de Quiz
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa um quiz de múltipla escolha que conduz o usuário por um conjunto de perguntas, uma de cada vez, registra suas respostas e mostra uma tela de resultados pontuada ao final. As perguntas vivem em um array local, então o trabalho é todo sobre fluxo e estado: em qual pergunta estamos, o que foi respondido e o que a tela mostra agora. É uma introdução limpa à renderização condicional e a uma pequena máquina de estados — início, em andamento e finalizado — além da renderização acessível de escolhas em grupo de rádio, onde usuários de teclado podem se mover e selecionar sem um mouse.
+
+## Pré-requisitos
+
+- Fundamentos de HTML, CSS e JavaScript
+- Iteração de arrays e rastreamento de índice
+- Renderização condicional (mostrar uma view com base no estado)
+- Grupos de rádio e botões acessíveis
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Modelar o progresso do quiz como estado explícito (índice atual, respostas, fase)
+- Renderizar uma pergunta por vez e avançar/voltar pelo conjunto
+- Calcular uma pontuação a partir das respostas registradas, não do DOM
+- Mostrar uma tela de resultados com uma revisão por pergunta
+- Construir um grupo de rádio acessível com seleção por teclado e foco claro
+
+## Requisitos Funcionais
+
+1. As perguntas são mostradas uma de cada vez com suas opções de resposta.
+2. O usuário seleciona uma resposta por pergunta e pode ir para a próxima pergunta.
+3. Um indicador de progresso mostra a posição atual (ex.: "Pergunta 3 de 10").
+4. Ao final, uma tela de resultados mostra a pontuação e quais respostas estavam certas ou erradas.
+5. As opções de resposta formam um grupo de rádio acessível navegável por teclado.
+6. O usuário não pode avançar além da última pergunta sem ver os resultados.
+7. Uma opção de reiniciar reseta todo o estado e retorna à primeira pergunta.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Renderizar e responder:** Mostre uma pergunta com opções selecionáveis e registre a escolha.
+2. **Marco 2 — Navegação e progresso:** Mova entre perguntas e exiba o progresso.
+3. **Marco 3 — Pontuação e revisão:** Calcule a pontuação e renderize uma tela de resultados/revisão.
+
+## Esboço de Dados e Interface
+
+```text
+Question
+  id:       string
+  prompt:   string
+  options:  string[]
+  answer:   number   (índice da opção correta)
+
+Estado do quiz
+  phase:    "start" | "playing" | "finished"
+  index:    number
+  answers:  (number | null)[]   (uma posição por pergunta)
+
+Layout (playing)
++------------------------------------------+
+| Pergunta 3 de 10        [====------]     |
++------------------------------------------+
+| O que significa CSS?                     |
+|  ( ) Cascading Style Sheets              |
+|  ( ) Computer Style System               |
+|  ( ) Creative Styling Syntax             |
++------------------------------------------+
+| [ Voltar ]                 [ Próxima ]   |
++------------------------------------------+
+```
+
+## Desafios Extras
+
+- Adicione um cronômetro opcional de contagem regressiva por pergunta que avança automaticamente ao expirar.
+- Randomize a ordem das perguntas e das opções a cada execução.
+- Suporte múltiplos quizzes/categorias escolhidos em uma tela inicial.
+- Persista uma pontuação máxima local entre sessões com `localStorage`.
+
+## Definição de Pronto
+
+- [ ] Exatamente uma pergunta é mostrada por vez com suas opções.
+- [ ] O progresso reflete com precisão a pergunta atual.
+- [ ] A pontuação final corresponde às respostas registradas.
+- [ ] As opções são um grupo de rádio navegável por teclado com foco visível.
+- [ ] Reiniciar reseta totalmente o estado de volta à primeira pergunta.
+
+## Armadilhas Comuns
+
+- Ler a resposta selecionada do DOM em vez de rastreá-la no estado.
+- Erros de "um a mais/menos" no contador de progresso ou no limite da última pergunta.
+- Usar `<div>`s clicáveis para opções, quebrando o uso por teclado e leitor de tela.
+- Recalcular a pontuação incorretamente quando um usuário muda uma resposta anterior.
+- Não resetar cada parte do estado ao reiniciar, vazando a execução anterior.
+
+## Recursos
+
+- [MDN: <input type="radio">](https://developer.mozilla.org/pt-BR/docs/Web/HTML/Element/input/radio) — agrupamento e comportamento de teclado padrão.
+- [WAI-ARIA: Radio Group pattern](https://www.w3.org/WAI/ARIA/apg/patterns/radio/) — grupos de rádio personalizados acessíveis.
+- [MDN: Condicionais em JavaScript](https://developer.mozilla.org/pt-BR/docs/Learn/JavaScript/Building_blocks/conditionals) — alternar views por estado.
+- [web.dev: Learn Accessibility — Focus](https://web.dev/learn/accessibility/focus) — gerenciar e mostrar o foco.
diff --git a/projects/frontend/beginner/10-timer-app/README.md b/projects/frontend/beginner/10-timer-app/README.md
index 08bcb28..6e82e2f 100644
--- a/projects/frontend/beginner/10-timer-app/README.md
+++ b/projects/frontend/beginner/10-timer-app/README.md
@@ -1,34 +1,94 @@
 # Timer App
 
-## Idea
-Build a timer application supporting countdown, stopwatch, and alarm functionality. Learn about time management, intervals, and UI updates.
+> 🌐 **English** · [Português](./README.pt-BR.md)
+
+**Domain:** Frontend · **Level:** Beginner · **Estimated time:** 3–6 hours
+
+## Overview
+
+Build a timer app with two modes: a stopwatch that counts up and a countdown that counts down to zero and alerts. It looks simple, but it teaches the single most misunderstood thing about time in the browser — you cannot trust `setInterval` to be accurate. Intervals drift, and they slow down or pause entirely in background tabs. The correct approach is to store a start timestamp and compute elapsed time from the real clock on each tick, using the interval only to trigger repaints. Get that right and your timer stays accurate even after the tab was hidden for a minute.
+
+## Prerequisites
+
+- HTML, CSS, and JavaScript fundamentals
+- `setInterval`, `clearInterval`, and `Date.now()`
+- Basic state modelling (running vs. paused vs. stopped)
+- Formatting numbers into `MM:SS` strings
 
 ## Learning Objectives
-- Implement timer/countdown logic
-- Handle time formatting
-- Manage intervals and requestAnimationFrame
-- Build stopwatch functionality
-- Implement pause/resume logic
-
-## Implementation Tips
-- Create timer input interface
-- Implement countdown display
-- Add start/pause/resume buttons
-- Add reset functionality
-- Create stopwatch mode
-- Implement lap timing
-- Add alarm sound on completion
-- Create time format display (MM:SS)
-- Implement background timer
-- Add notification support
-- Create multiple timers
-- Implement preset timers (Pomodoro)
-- Add progress visualization
-- Create custom time input
-
-## Key Challenges
-- Accurate time tracking
-- Interval timing precision
-- Background tab handling
-- Audio notification compatibility
-- UI update efficiency
+
+By the end, you should be able to:
+
+- Track elapsed time from a real timestamp rather than accumulating interval ticks
+- Implement start, pause, resume, and reset without drift
+- Build both stopwatch (count up) and countdown (count down) modes
+- Format time consistently and update the display smoothly
+- Fire an accessible alert/notification when a countdown reaches zero
+
+## Functional Requirements
+
+1. The stopwatch counts up from zero and can be paused, resumed, and reset.
+2. The countdown accepts a duration, counts down to zero, and signals completion.
+3. Elapsed/remaining time is computed from real timestamps, staying accurate after a background tab.
+4. Time is displayed in a clear `MM:SS` (or `HH:MM:SS`) format.
+5. Pause preserves the exact elapsed time; resume continues from it.
+6. Reset returns to the initial state with controls in the correct enabled/disabled states.
+7. Countdown completion is announced accessibly, not by color alone.
+
+## Suggested Milestones
+
+1. **Milestone 1 — Stopwatch:** Count up from a start timestamp with start/pause/reset.
+2. **Milestone 2 — Countdown:** Accept a duration and count down, signalling zero.
+3. **Milestone 3 — Accuracy & polish:** Verify no drift across tab backgrounding; add the completion alert.
+
+## Data & Interface Sketch
+
+```text
+Timer state
+  mode:       "stopwatch" | "countdown"
+  status:     "idle" | "running" | "paused"
+  startedAt:  number | null   (Date.now() at last start)
+  baseElapsed: number         (ms accumulated before current run)
+  durationMs: number          (countdown target)
+
+elapsed = baseElapsed + (running ? Date.now() - startedAt : 0)
+
+Layout
++------------------------------------------+
+|            00:00:00                      |  <- display
++------------------------------------------+
+|   [ Start ]  [ Pause ]  [ Reset ]        |
++------------------------------------------+
+|   Mode: (o) Stopwatch  ( ) Countdown     |
++------------------------------------------+
+```
+
+## Stretch Goals
+
+- Add lap timing to the stopwatch, recording split times in a list.
+- Add Pomodoro presets that cycle work and break countdowns.
+- Use the Notification API to alert when the tab is not focused.
+- Add a circular progress ring that fills as the countdown runs (respect reduced motion).
+
+## Definition of Done
+
+- [ ] Elapsed time is derived from timestamps and stays accurate after backgrounding.
+- [ ] Start, pause, resume, and reset all behave correctly with matching control states.
+- [ ] Both stopwatch and countdown modes work independently.
+- [ ] Countdown completion is announced without relying on color alone.
+- [ ] Time is always formatted consistently, with no negative or `NaN` values.
+
+## Common Pitfalls
+
+- Incrementing a counter each `setInterval` tick, which drifts and stalls in background tabs.
+- Forgetting to `clearInterval`, leaking timers and stacking updates.
+- Not preserving elapsed time across pause/resume, resetting the clock accidentally.
+- Signalling completion only with a color change, invisible to some users.
+- Displaying negative time when the countdown overshoots zero on a slow tick.
+
+## Resources
+
+- [MDN: setInterval()](https://developer.mozilla.org/en-US/docs/Web/API/setInterval) — its guarantees and its limits.
+- [MDN: Date.now()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/now) — the timestamp your accuracy depends on.
+- [MDN: Page Visibility API](https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API) — knowing when a tab is hidden.
+- [MDN: ARIA live regions](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions) — announcing completion accessibly.
diff --git a/projects/frontend/beginner/10-timer-app/README.pt-BR.md b/projects/frontend/beginner/10-timer-app/README.pt-BR.md
new file mode 100644
index 0000000..41a9625
--- /dev/null
+++ b/projects/frontend/beginner/10-timer-app/README.pt-BR.md
@@ -0,0 +1,94 @@
+# Aplicativo de Temporizador
+
+> 🌐 [English](./README.md) · **Português**
+
+**Domínio:** Frontend · **Nível:** Iniciante · **Tempo estimado:** 3–6 horas
+
+## Visão Geral
+
+Construa um app de temporizador com dois modos: um cronômetro que conta para cima e uma contagem regressiva que conta até zero e alerta. Parece simples, mas ensina a coisa mais mal compreendida sobre tempo no navegador — você não pode confiar que o `setInterval` seja preciso. Intervalos derivam, e eles desaceleram ou pausam totalmente em abas em segundo plano. A abordagem correta é armazenar um timestamp de início e calcular o tempo decorrido a partir do relógio real a cada tique, usando o intervalo apenas para disparar repinturas. Acerte isso e seu temporizador permanece preciso mesmo depois de a aba ter ficado oculta por um minuto.
+
+## Pré-requisitos
+
+- Fundamentos de HTML, CSS e JavaScript
+- `setInterval`, `clearInterval` e `Date.now()`
+- Modelagem básica de estado (rodando vs. pausado vs. parado)
+- Formatar números em strings `MM:SS`
+
+## Objetivos de Aprendizado
+
+Ao final, você deve ser capaz de:
+
+- Rastrear o tempo decorrido a partir de um timestamp real em vez de acumular tiques de intervalo
+- Implementar iniciar, pausar, retomar e resetar sem deriva
+- Construir os modos cronômetro (contar para cima) e contagem regressiva (contar para baixo)
+- Formatar o tempo de forma consistente e atualizar o visor suavemente
+- Disparar um alerta/notificação acessível quando uma contagem regressiva chega a zero
+
+## Requisitos Funcionais
+
+1. O cronômetro conta para cima a partir do zero e pode ser pausado, retomado e resetado.
+2. A contagem regressiva aceita uma duração, conta até zero e sinaliza a conclusão.
+3. O tempo decorrido/restante é calculado a partir de timestamps reais, permanecendo preciso após uma aba em segundo plano.
+4. O tempo é exibido em um formato claro `MM:SS` (ou `HH:MM:SS`).
+5. Pausar preserva o tempo decorrido exato; retomar continua a partir dele.
+6. Resetar retorna ao estado inicial com os controles nos estados corretos de habilitado/desabilitado.
+7. A conclusão da contagem regressiva é anunciada de forma acessível, não apenas pela cor.
+
+## Marcos Sugeridos
+
+1. **Marco 1 — Cronômetro:** Conte para cima a partir de um timestamp de início com iniciar/pausar/resetar.
+2. **Marco 2 — Contagem regressiva:** Aceite uma duração e conte para baixo, sinalizando o zero.
+3. **Marco 3 — Precisão e polimento:** Verifique a ausência de deriva ao colocar a aba em segundo plano; adicione o alerta de conclusão.
+
+## Esboço de Dados e Interface
+
+```text
+Estado do timer
+  mode:       "stopwatch" | "countdown"
+  status:     "idle" | "running" | "paused"
+  startedAt:  number | null   (Date.now() no último início)
+  baseElapsed: number         (ms acumulados antes da execução atual)
+  durationMs: number          (alvo da contagem regressiva)
+
+elapsed = baseElapsed + (running ? Date.now() - startedAt : 0)
+
+Layout
++------------------------------------------+
+|            00:00:00                      |  <- visor
++------------------------------------------+
+|  [ Iniciar ]  [ Pausar ]  [ Resetar ]    |
++------------------------------------------+
+|  Modo: (o) Cronômetro  ( ) Regressiva    |
++------------------------------------------+
+```
+
+## Desafios Extras
+
+- Adicione cronometragem de voltas ao cronômetro, registrando tempos parciais em uma lista.
+- Adicione presets Pomodoro que alternam contagens de trabalho e pausa.
+- Use a Notification API para alertar quando a aba não está focada.
+- Adicione um anel de progresso circular que preenche conforme a contagem regressiva corre (respeite movimento reduzido).
+
+## Definição de Pronto
+
+- [ ] O tempo decorrido é derivado de timestamps e permanece preciso após o segundo plano.
+- [ ] Iniciar, pausar, retomar e resetar se comportam corretamente com estados de controle correspondentes.
+- [ ] Ambos os modos cronômetro e contagem regressiva funcionam de forma independente.
+- [ ] A conclusão da contagem regressiva é anunciada sem depender apenas da cor.
+- [ ] O tempo é sempre formatado de forma consistente, sem valores negativos ou `NaN`.
+
+## Armadilhas Comuns
+
+- Incrementar um contador a cada tique de `setInterval`, que deriva e estagna em abas em segundo plano.
+- Esquecer o `clearInterval`, vazando temporizadores e empilhando atualizações.
+- Não preservar o tempo decorrido entre pausar/retomar, resetando o relógio acidentalmente.
+- Sinalizar a conclusão apenas com uma mudança de cor, invisível para alguns usuários.
+- Exibir tempo negativo quando a contagem regressiva ultrapassa o zero em um tique lento.
+
+## Recursos
+
+- [MDN: setInterval()](https://developer.mozilla.org/pt-BR/docs/Web/API/setInterval) — suas garantias e seus limites.
+- [MDN: Date.now()](https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Global_Objects/Date/now) — o timestamp do qual sua precisão depende.
+- [MDN: Page Visibility API](https://developer.mozilla.org/pt-BR/docs/Web/API/Page_Visibility_API) — saber quando uma aba está oculta.
+- [MDN: ARIA live regions](https://developer.mozilla.org/pt-BR/docs/Web/Accessibility/ARIA/ARIA_Live_Regions) — anunciar a conclusão de forma acessível.