♻️ refactor: padronizar estrutura de diretórios de imagens

Reorganiza todas as imagens para seguir o padrão consistente
`static/img/chapter-N/` para todos os capítulos.

Mudanças estruturais:
- Criar `static/img/chapter-1/` e mover imagens do Capítulo 1
- Renomear `static/img/javascript/` para `static/img/chapter-2/`
- Criar `static/img/chapter-4/` (vazio, aguardando imagens)
- Criar `static/img/chapter-5/` e mover imagens do Capítulo 5
- Remover diretório vazio `static/img/javascript/`

Atualizações de referências:
- Atualizar 4 arquivos do Capítulo 1: `/img/ch1-*` → `/img/chapter-1/ch1-*`
- Atualizar 4 arquivos do Capítulo 2: `/img/javascript/*` → `/img/chapter-2/*`
- Atualizar 2 arquivos do Capítulo 5: `/img/Fig5*`, `/img/chip.png`, `/img/ex5*`

Estrutura final:
```
static/img/
├── chapter-1/  (5 imagens)
├── chapter-2/  (5 imagens)
├── chapter-3/  (13 imagens)
├── chapter-4/  (vazio)
└── chapter-5/  (5 imagens)
```

Atualizar MISSING_IMAGES.md para refletir nova estrutura padronizada.

Author: claude

MISSING_IMAGES.md

@@ -166,42 +166,26 @@ This report identifies all pages in the SICP JavaScript translation that referen
 
 ---
 
-## Image Organization Inconsistency
+## Image Organization
 
-The current image organization varies across chapters, which should be standardized:
+The image directory structure has been standardized to a consistent `chapter-N/` pattern:
 
-### Current Structure
+### Current Structure ✅
 ```
 static/img/
-├── ch1-*.svg                    # Chapter 1 - root level
-├── javascript/
-│   └── ch2-*.svg               # Chapter 2 - subdirectory
-├── chapter-3/
-│   └── ch3-*.svg               # Chapter 3 - subdirectory
-└── (no chapter-4 directory)    # Chapter 4 - missing
-```
-
-### Recommended Consistent Structure
-```
-static/img/
-├── chapter-1/
+├── chapter-1/          # 5 images (complete)
 │   └── ch1-*.svg
-├── chapter-2/
+├── chapter-2/          # 5 images (complete)
 │   └── ch2-*.svg
-├── chapter-3/
-│   └── ch3-*.svg
-├── chapter-4/
-│   └── ch4-*.svg
-└── chapter-5/
-    └── ch5-*.svg
+├── chapter-3/          # 13 images (partial - 16+ missing)
+│   └── ch3-*.svg, Fig3.*.svg
+├── chapter-4/          # 0 images (directory created, awaiting images)
+│   └── (empty - all images missing)
+└── chapter-5/          # 5 images (partial - more needed)
+    └── ch5-*.svg, Fig5.*.svg, *.png
 ```
 
-**Actions for consistency:**
-1. Create `static/img/chapter-1/` and move Chapter 1 images there
-2. Rename `static/img/javascript/` to `static/img/chapter-2/`
-3. Create `static/img/chapter-4/` directory
-4. Ensure Chapter 5 images are in `static/img/chapter-5/`
-5. Update all markdown references to use new paths
+All markdown references have been updated to use the new paths.
 
 ---
 

docs/chapter-1/1.1.3.mdx

@@ -21,7 +21,7 @@ Observe como a ideia de recursão pode ser usada sucintamente para expressar o q
 requer que a regra de avaliação seja aplicada a quatro combinações diferentes. Podemos obter uma imagem desse processo representando a combinação na forma de uma árvore, conforme mostrado na figura [1.1](#fig-1.1). Cada combinação é representada por um nó com ramificações correspondentes ao operador e aos operandos da combinação que dele decorrem. Os nós terminais (ou seja, nós sem ramificações derivadas deles) representam operadores ou números. Vendo a avaliação em termos de árvore, podemos imaginar que os valores dos operandos percolam para cima, começando nos nós terminais e depois combinando em níveis cada vez mais altos. Em geral, veremos que a recursão é uma técnica muito poderosa para lidar com objetos hierárquicos semelhantes a árvores. Na verdade, a forma de "filtrar os valores para cima" da regra de avaliação é um exemplo de um tipo geral de processo conhecido como `acumulação de árvore`.
 
 <a name="fig-1.1"></a>
-![#fig-1.1](/img/ch1-expression-tree.svg)
+![#fig-1.1](/img/chapter-1/ch1-expression-tree.svg)
 
 Figura 1.1 Representação em árvore, mostrando o valor de cada subexpressão.
 

docs/chapter-1/1.1.8.mdx

@@ -7,7 +7,7 @@ A função `sqrt` é nosso primeiro exemplo de um processo definido por um conju
 Observe que o problema de calcular raízes quadradas se divide naturalmente em vários subproblemas: como saber se uma estimativa é boa o suficiente, como melhorar uma estimativa e assim por diante. Cada uma dessas tarefas é realizada por uma função separada. Todo o programa `sqrt` pode ser visto como um cluster de funções (mostrado na figura 1.2) que reflete a decomposição do problema em subproblemas.
 
 <a name="fig-1.2"></a>
-![figura-1.2-decomposição-funcional-do-sqrt](/img/ch1-sqrt-decomposition.svg)
+![figura-1.2-decomposição-funcional-do-sqrt](/img/chapter-1/ch1-sqrt-decomposition.svg)
 
 Figura 1.2 Decomposição funcional do programa `sqrt`.
 

docs/chapter-1/1.2.1.mdx

@@ -28,7 +28,7 @@ Assim, podemos calcular $n!$ calculando $(n-1)!$ e multiplicando o resultado por
 
 Podemos usar o modelo de substituição da seção 1.1.5 para observar esta função em ação calculando $6!$, como mostrado na figura abaixo.
 
-![Um processo recursivo linear para calcular 6!](/img/ch1-Z-G-7.svg)
+![Um processo recursivo linear para calcular 6!](/img/chapter-1/ch1-Z-G-7.svg)
 
 *Figura: Um processo recursivo linear para calcular 6!.*
 
@@ -63,7 +63,7 @@ function fact_iter(product, counter, max_count) {
 
 Como antes, podemos usar o modelo de substituição para visualizar o processo de calcular $6!$, como mostrado na figura abaixo.
 
-![Um processo iterativo linear para calcular 6!](/img/ch1-Z-G-10.svg)
+![Um processo iterativo linear para calcular 6!](/img/chapter-1/ch1-Z-G-10.svg)
 
 *Figura: Um processo iterativo linear para calcular 6!.*
 

docs/chapter-1/1.2.2.mdx

@@ -26,7 +26,7 @@ Podemos traduzir imediatamente esta definição em uma função recursiva para c
   showLineNumbers={false}
 />
 
-![O processo recursivo em árvore gerado ao calcular fib(5)](/img/ch1-fibonacci-tree.svg)
+![O processo recursivo em árvore gerado ao calcular fib(5)](/img/chapter-1/ch1-fibonacci-tree.svg)
 
 *Figura: O processo recursivo em árvore gerado ao calcular `fib(5)`.*
 

docs/chapter-2/2.1.2.mdx

@@ -8,7 +8,7 @@ import CodePlayground from '@site/src/components/CodePlayground';
 
 Antes de continuar com mais exemplos de dados compostos e abstração de dados, vamos considerar algumas das questões levantadas pelo exemplo de números racionais. Definimos as operações de números racionais em termos de um construtor `make_rat` e seletores `numer` e `denom`. Em geral, a ideia subjacente da abstração de dados é identificar para cada tipo de objeto de dados um conjunto básico de operações em termos das quais todas as manipulações de objetos de dados desse tipo serão expressas, e então usar apenas essas operações na manipulação dos dados.
 
-![Barreiras de abstração de dados no pacote de números racionais](/img/javascript/ch2-Z-G-6.svg)
+![Barreiras de abstração de dados no pacote de números racionais](/img/chapter-2/ch2-Z-G-6.svg)
 
 Podemos visualizar a estrutura do sistema de números racionais como mostrado na figura acima. As linhas horizontais representam *barreiras de abstração* que isolam diferentes "níveis" do sistema. Em cada nível, a barreira separa os programas (acima) que usam a abstração de dados dos programas (abaixo) que implementam a abstração de dados. Programas que usam números racionais os manipulam exclusivamente em termos das funções fornecidas "para uso público" pelo pacote de números racionais: `add_rat`, `sub_rat`, `mul_rat`, `div_rat` e `equal_rat`. Estas, por sua vez, são implementadas exclusivamente em termos do construtor e seletores `make_rat`, `numer` e `denom`, que eles mesmos são implementados em termos de pares. Os detalhes de como os pares são implementados são irrelevantes para o resto do pacote de números racionais, desde que os pares possam ser manipulados pelo uso de `pair`, `head` e `tail`. Na prática, as funções em cada nível são as interfaces que definem as barreiras de abstração e conectam os diferentes níveis.
 

docs/chapter-2/2.2.1.mdx

@@ -8,7 +8,7 @@ import CodePlayground from '@site/src/components/CodePlayground';
 
 Uma das estruturas de dados úteis que podemos construir com pares é uma *sequência*—uma coleção ordenada de objetos de dados. Existem, é claro, muitas maneiras de representar sequências em termos de pares. Uma representação particularmente direta é ilustrada abaixo, onde a sequência 1, 2, 3, 4 é representada como uma cadeia de pares:
 
-![Sequência 1, 2, 3, 4 como cadeia de pares](/img/javascript/ch2-Z-G-13.svg)
+![Sequência 1, 2, 3, 4 como cadeia de pares](/img/chapter-2/ch2-Z-G-13.svg)
 
 O head de cada par é o item correspondente na cadeia, e o tail do par é o próximo par na cadeia. O tail do par final sinaliza o fim da sequência apontando para um valor distinto de qualquer par, que representamos na diagrama de box-and-pointer como um símbolo diagonal e em programas como o valor de `null`. A sequência inteira é construída por operações `pair` aninhadas:
 

docs/chapter-2/2.2.md

@@ -2,11 +2,11 @@
 
 Como vimos, os pares fornecem uma "cola" primitiva que podemos usar para construir objetos de dados compostos. A figura abaixo mostra uma maneira padrão de visualizar um par—neste caso, o par formado por `pair(1, 2)`. Nesta representação, que é chamada de *notação box-and-pointer*, cada objeto composto é mostrado como um ponteiro para uma caixa. A caixa para um par tem duas partes, a parte esquerda contendo o head do par e a parte direita contendo o tail.
 
-![Representação box-and-pointer de pair(1, 2)](/img/javascript/ch2-Z-G-11.svg)
+![Representação box-and-pointer de pair(1, 2)](/img/chapter-2/ch2-Z-G-11.svg)
 
 Já vimos que `pair` pode ser usado para combinar não apenas números, mas pares também. (Você fez uso desse fato, ou deveria ter feito, ao fazer os exercícios 2.2 e 2.3.) Como consequência, os pares fornecem um bloco de construção universal a partir do qual podemos construir todos os tipos de estruturas de dados. A figura abaixo mostra duas maneiras de usar pares para combinar os números 1, 2, 3 e 4.
 
-![Duas maneiras de combinar 1, 2, 3 e 4 usando pares](/img/javascript/ch2-Z-G-12.svg)
+![Duas maneiras de combinar 1, 2, 3 e 4 usando pares](/img/chapter-2/ch2-Z-G-12.svg)
 
 A capacidade de criar pares cujos elementos são pares é a essência da importância da estrutura de lista como uma ferramenta representacional. Nos referimos a essa capacidade como a *propriedade de closure* de `pair`. Em geral, uma operação para combinar objetos de dados satisfaz a propriedade de closure se os resultados de combinar coisas com essa operação podem ser combinados usando a mesma operação. Closure é a chave para o poder em qualquer meio de combinação porque nos permite criar estruturas *hierárquicas*—estruturas compostas de partes, que são elas mesmas compostas de partes, e assim por diante.
 

docs/chapter-2/2.5.md

@@ -6,4 +6,4 @@ Já vimos vários pacotes diferentes de operações aritméticas: a aritmética
 
 A figura abaixo mostra a estrutura do sistema que vamos construir. Observe as barreiras de abstração. Da perspectiva de alguém usando "números", há uma única função `add` que opera em quaisquer números fornecidos. A função `add` faz parte de uma interface genérica que permite que os pacotes separados de aritmética ordinária, aritmética racional e aritmética complexa sejam acessados uniformemente por programas que usam números. Qualquer pacote aritmético individual (como o pacote complexo) pode ser acessado através de funções genéricas (como `add_complex`) que combinam pacotes projetados para diferentes representações (como retangular e polar). Além disso, a estrutura do sistema é aditiva, de modo que podemos projetar os pacotes aritméticos individuais separadamente e combiná-los para produzir um sistema aritmético genérico.
 
-![Sistema aritmético genérico](/img/javascript/ch2-Z-G-64.svg)
+![Sistema aritmético genérico](/img/chapter-2/ch2-Z-G-64.svg)

docs/chapter-5/5.1.md

@@ -16,12 +16,12 @@ Podemos ilustrar os registradores e operações necessários para esta máquina
 
 Uma operação que calcula um valor a partir de constantes e do conteúdo de registradores é representada em um diagrama de caminho de dados por um trapézio contendo um nome para a operação. Por exemplo, a caixa marcada `rem` na Figura 5.1 representa uma operação que calcula o resto do conteúdo dos registradores `a` e `b` aos quais está conectada. Setas (sem botões) apontam dos registradores de entrada e constantes para a caixa, e setas conectam o valor de saída da operação aos registradores. Um teste é representado por um círculo contendo um nome para o teste. Por exemplo, nossa máquina MDC tem uma operação que testa se o conteúdo do registrador `b` é zero. Um teste também tem setas de seus registradores de entrada e constantes, mas não tem setas de saída; seu valor é usado pelo controlador em vez dos caminhos de dados. No geral, o diagrama de caminho de dados mostra os registradores e operações que são necessários para a máquina e como eles devem ser conectados. Se visualizarmos as setas como fios e os botões $\otimes$ como interruptores, o diagrama de caminho de dados é muito parecido com o diagrama de fiação de uma máquina que poderia ser construída a partir de componentes elétricos.
 
-![Figura 5.1](/img/Fig5.1a.std.svg)
+![Figura 5.1](/img/chapter-5/Fig5.1a.std.svg)
 **Figura 5.1:** Caminhos de dados para uma máquina MDC.
 
 Para que os caminhos de dados realmente calculem MDCs, os botões devem ser pressionados na sequência correta. Descreveremos essa sequência em termos de um diagrama de controlador, conforme ilustrado na Figura 5.2. Os elementos do diagrama de controlador indicam como os componentes do caminho de dados devem ser operados. As caixas retangulares no diagrama de controlador identificam os botões do caminho de dados a serem pressionados, e as setas descrevem o sequenciamento de um passo para o próximo. O diamante no diagrama representa uma decisão. Uma das duas setas de sequenciamento será seguida, dependendo do valor do teste do caminho de dados identificado no diamante. Podemos interpretar o controlador em termos de uma analogia física: pense no diagrama como um labirinto no qual uma bola de gude está rolando. Quando a bola de gude rola para dentro de uma caixa, ela pressiona o botão do caminho de dados que é nomeado pela caixa. Quando a bola de gude rola para dentro de um nó de decisão (como o teste para `b` $= 0$), ela sai do nó pelo caminho determinado pelo resultado do teste indicado. Tomados em conjunto, os caminhos de dados e o controlador descrevem completamente uma máquina para calcular MDCs. Iniciamos o controlador (a bola de gude rolando) no lugar marcado `start`, depois de colocar números nos registradores `a` e `b`. Quando o controlador atinge `done`, encontraremos o valor do MDC no registrador `a`.
 
-![Figura 5.2](/img/Fig5.2.std.svg)
+![Figura 5.2](/img/chapter-5/Fig5.2.std.svg)
 **Figura 5.2:** Controlador para uma máquina MDC.
 
 ### Exercício 5.1
@@ -48,8 +48,8 @@ Em `factorial(n)`, a função `iter(product, counter)` é inicializada com os ar
 
 Para o caminho de dados, vemos três registradores: `product`, `counter` e `n`. Existem duas operações: `multiply` e `plus` com duas atribuições. Existe um teste: `greater than`.
 
-![Figura 5.1 - Exercício](/img/ex5-1-solution-1.png)
+![Figura 5.1 - Exercício](/img/chapter-5/ex5-1-solution-1.png)
 
 Para o controlador, começamos preenchendo os três registradores com o fatorial desejado `n` e o valor `1` (inicializando `product` e `counter`). A função `iter` executa e testa se `counter > n`. Se `counter <= n`, então `product` é atualizado para `product * counter`, seguido por counter sendo atualizado para `counter + 1` e o processo é repetido até `counter > n`. Uma vez que counter é > n, o produto é `factorial(n)` e pode ser retornado.
 
-![Figura 5.2 - Exercício](/img/ex5-1-solution-2.png)
+![Figura 5.2 - Exercício](/img/chapter-5/ex5-1-solution-2.png)