feat(backend): adiciona tracking e readiness

[Jovinull]

Card

• PAV-35

Objetivo e escopo

• Tornar o estado operacional do backend observável sem alterar o contrato de GET /health.
• Adicionar rastreamento opcional de exceções inesperadas via Sentry.

O que foi feito

• Mantém GET /health como liveness do processo.
• Adiciona GET /ready, que verifica Postgres e Valkey e retorna 503 quando alguma dependência não está disponível.
• Inicializa o Sentry somente quando SENTRY_DSN está definido.
• Registra exceções inesperadas localmente com requestId, método e caminho, e envia esse contexto ao Sentry quando habilitado.
• Documenta SENTRY_DSN nos arquivos de exemplo e no README.

Módulos afetados

• backend/src/app.ts
• backend/src/errorTracking.ts
• backend/src/middleware/errorHandler.ts
• backend/src/server.ts
• backend/.env.example
• .env.example
• README.md

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/unit/app.test.ts tests/unit/errorTracking.test.ts tests/unit/middleware/errorHandler.test.ts tests/unit/services/server.test.ts - 4 arquivos e 43 testes aprovados.
• Os testes cobrem /health, /ready com dependências disponíveis, /ready com falha de dependência, ausência de SENTRY_DSN e captura de exceções com contexto.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.

Configuração e observações

• SENTRY_DSN é opcional. Sem a variável, o Sentry permanece desativado e os logs estruturados locais continuam ativos.
• O teste de readiness usa mocks das dependências; não foi necessário interromper Postgres ou Valkey locais.
• Não há alteração de schema nem migration nesta PR.

[hltav]

A descrição apresenta um resumo da implementação, mas ainda está fora do padrão de PR definido pelo projeto e não fornece contexto suficiente para uma revisão segura.

Por favor, complemente a PR conforme o template/documentação, incluindo:

• referência e critérios atendidos da PAV-35;
• objetivo e escopo da alteração;
• módulos/arquivos relevantes afetados;
• comportamento esperado de /health e /ready;
• configuração necessária para Sentry e variáveis de ambiente;
• testes executados e respectivos resultados;
  cenários de falha validados, especialmente indisponibilidade de Postgres/Valkey e ausência de SENTRY_DSN.

Após a adequação da descrição, seguimos com a revisão técnica.

[hltav]

A implementação contempla boa parte do escopo da PAV-35, porém o comportamento operacional dos healthchecks ainda não garante integralmente o critério de monitoramento de disponibilidade previsto no card.

Existem cenários de indisponibilidade das dependências que não estão representados pela implementação e pela cobertura atual, o que pode comprometer a utilização do readiness como sinal confiável de disponibilidade.

Revise o fluxo de readiness e sua estratégia de validação considerando cenários reais de degradação antes de solicitar nova revisão.

[Jovinull]

Atualiza??o ap?s o review da PAV-35:

• O endpoint /ready agora aplica timeout de 2 segundos em cada verifica??o de Postgres e Valkey.
• Depend?ncias que rejeitam ou ficam sem resposta resultam em HTTP 503, evitando que o readiness fique pendurado.
• Adicionado teste cobrindo uma depend?ncia que n?o responde.

Valida??o executada:

• Suite completa do backend: 576 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

[Jovinull]

Card

• PAV-35

Objetivo e escopo

• Tornar o estado operacional do backend observável sem alterar o contrato de GET /health.
• Adicionar rastreamento opcional de exceções inesperadas via Sentry.

O que foi feito

• Mantém GET /health como liveness do processo.
• Adiciona GET /ready, que verifica Postgres e Valkey e retorna 503 quando alguma dependência não está disponível.
• Inicializa o Sentry somente quando SENTRY_DSN está definido.
• Registra exceções inesperadas localmente com requestId, método e caminho, e envia esse contexto ao Sentry quando habilitado.
• Documenta SENTRY_DSN nos arquivos de exemplo e no README.

Módulos afetados

• backend/src/app.ts
• backend/src/errorTracking.ts
• backend/src/middleware/errorHandler.ts
• backend/src/server.ts
• backend/.env.example
• .env.example
• README.md

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/unit/app.test.ts tests/unit/errorTracking.test.ts tests/unit/middleware/errorHandler.test.ts tests/unit/services/server.test.ts - 4 arquivos e 43 testes aprovados.
• Os testes cobrem /health, /ready com dependências disponíveis, /ready com falha de dependência, ausência de SENTRY_DSN e captura de exceções com contexto.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.

Configuração e observações

• SENTRY_DSN é opcional. Sem a variável, o Sentry permanece desativado e os logs estruturados locais continuam ativos.
• O teste de readiness usa mocks das dependências; não foi necessário interromper Postgres ou Valkey locais.
• Não há alteração de schema nem migration nesta PR.

[hltav]

A descrição apresenta um resumo da implementação, mas ainda está fora do padrão de PR definido pelo projeto e não fornece contexto suficiente para uma revisão segura.

Por favor, complemente a PR conforme o template/documentação, incluindo:

• referência e critérios atendidos da PAV-35;
• objetivo e escopo da alteração;
• módulos/arquivos relevantes afetados;
• comportamento esperado de /health e /ready;
• configuração necessária para Sentry e variáveis de ambiente;
• testes executados e respectivos resultados;
  cenários de falha validados, especialmente indisponibilidade de Postgres/Valkey e ausência de SENTRY_DSN.

Após a adequação da descrição, seguimos com a revisão técnica.

[hltav]

A implementação contempla boa parte do escopo da PAV-35, porém o comportamento operacional dos healthchecks ainda não garante integralmente o critério de monitoramento de disponibilidade previsto no card.

Existem cenários de indisponibilidade das dependências que não estão representados pela implementação e pela cobertura atual, o que pode comprometer a utilização do readiness como sinal confiável de disponibilidade.

Revise o fluxo de readiness e sua estratégia de validação considerando cenários reais de degradação antes de solicitar nova revisão.

[Jovinull]

Atualiza??o ap?s o review da PAV-35:

• O endpoint /ready agora aplica timeout de 2 segundos em cada verifica??o de Postgres e Valkey.
• Depend?ncias que rejeitam ou ficam sem resposta resultam em HTTP 503, evitando que o readiness fique pendurado.
• Adicionado teste cobrindo uma depend?ncia que n?o responde.

Valida??o executada:

• Suite completa do backend: 576 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

[Jovinull]

Card

• PAV-35

Objetivo e escopo

• Tornar o estado operacional do backend observável sem alterar o contrato de GET /health.
• Adicionar rastreamento opcional de exceções inesperadas via Sentry.

O que foi feito

• Mantém GET /health como liveness do processo.
• Adiciona GET /ready, que verifica Postgres e Valkey e retorna 503 quando alguma dependência não está disponível.
• Inicializa o Sentry somente quando SENTRY_DSN está definido.
• Registra exceções inesperadas localmente com requestId, método e caminho, e envia esse contexto ao Sentry quando habilitado.
• Documenta SENTRY_DSN nos arquivos de exemplo e no README.

Módulos afetados

• backend/src/app.ts
• backend/src/errorTracking.ts
• backend/src/middleware/errorHandler.ts
• backend/src/server.ts
• backend/.env.example
• .env.example
• README.md

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/unit/app.test.ts tests/unit/errorTracking.test.ts tests/unit/middleware/errorHandler.test.ts tests/unit/services/server.test.ts - 4 arquivos e 43 testes aprovados.
• Os testes cobrem /health, /ready com dependências disponíveis, /ready com falha de dependência, ausência de SENTRY_DSN e captura de exceções com contexto.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.

Configuração e observações

• SENTRY_DSN é opcional. Sem a variável, o Sentry permanece desativado e os logs estruturados locais continuam ativos.
• O teste de readiness usa mocks das dependências; não foi necessário interromper Postgres ou Valkey locais.
• Não há alteração de schema nem migration nesta PR.

[hltav]

A descrição apresenta um resumo da implementação, mas ainda está fora do padrão de PR definido pelo projeto e não fornece contexto suficiente para uma revisão segura.

Por favor, complemente a PR conforme o template/documentação, incluindo:

• referência e critérios atendidos da PAV-35;
• objetivo e escopo da alteração;
• módulos/arquivos relevantes afetados;
• comportamento esperado de /health e /ready;
• configuração necessária para Sentry e variáveis de ambiente;
• testes executados e respectivos resultados;
  cenários de falha validados, especialmente indisponibilidade de Postgres/Valkey e ausência de SENTRY_DSN.

Após a adequação da descrição, seguimos com a revisão técnica.

[hltav]

A implementação contempla boa parte do escopo da PAV-35, porém o comportamento operacional dos healthchecks ainda não garante integralmente o critério de monitoramento de disponibilidade previsto no card.

Existem cenários de indisponibilidade das dependências que não estão representados pela implementação e pela cobertura atual, o que pode comprometer a utilização do readiness como sinal confiável de disponibilidade.

Revise o fluxo de readiness e sua estratégia de validação considerando cenários reais de degradação antes de solicitar nova revisão.

[Jovinull]

Atualiza??o ap?s o review da PAV-35:

• O endpoint /ready agora aplica timeout de 2 segundos em cada verifica??o de Postgres e Valkey.
• Depend?ncias que rejeitam ou ficam sem resposta resultam em HTTP 503, evitando que o readiness fique pendurado.
• Adicionado teste cobrindo uma depend?ncia que n?o responde.

Valida??o executada:

• Suite completa do backend: 576 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

[Jovinull]

Card

• PAV-35

Objetivo e escopo

• Tornar o estado operacional do backend observável sem alterar o contrato de GET /health.
• Adicionar rastreamento opcional de exceções inesperadas via Sentry.

O que foi feito

• Mantém GET /health como liveness do processo.
• Adiciona GET /ready, que verifica Postgres e Valkey e retorna 503 quando alguma dependência não está disponível.
• Inicializa o Sentry somente quando SENTRY_DSN está definido.
• Registra exceções inesperadas localmente com requestId, método e caminho, e envia esse contexto ao Sentry quando habilitado.
• Documenta SENTRY_DSN nos arquivos de exemplo e no README.

Módulos afetados

• backend/src/app.ts
• backend/src/errorTracking.ts
• backend/src/middleware/errorHandler.ts
• backend/src/server.ts
• backend/.env.example
• .env.example
• README.md

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/unit/app.test.ts tests/unit/errorTracking.test.ts tests/unit/middleware/errorHandler.test.ts tests/unit/services/server.test.ts - 4 arquivos e 43 testes aprovados.
• Os testes cobrem /health, /ready com dependências disponíveis, /ready com falha de dependência, ausência de SENTRY_DSN e captura de exceções com contexto.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.

Configuração e observações

• SENTRY_DSN é opcional. Sem a variável, o Sentry permanece desativado e os logs estruturados locais continuam ativos.
• O teste de readiness usa mocks das dependências; não foi necessário interromper Postgres ou Valkey locais.
• Não há alteração de schema nem migration nesta PR.

[hltav]

A descrição apresenta um resumo da implementação, mas ainda está fora do padrão de PR definido pelo projeto e não fornece contexto suficiente para uma revisão segura.

Por favor, complemente a PR conforme o template/documentação, incluindo:

• referência e critérios atendidos da PAV-35;
• objetivo e escopo da alteração;
• módulos/arquivos relevantes afetados;
• comportamento esperado de /health e /ready;
• configuração necessária para Sentry e variáveis de ambiente;
• testes executados e respectivos resultados;
  cenários de falha validados, especialmente indisponibilidade de Postgres/Valkey e ausência de SENTRY_DSN.

Após a adequação da descrição, seguimos com a revisão técnica.

[hltav]

A implementação contempla boa parte do escopo da PAV-35, porém o comportamento operacional dos healthchecks ainda não garante integralmente o critério de monitoramento de disponibilidade previsto no card.

Existem cenários de indisponibilidade das dependências que não estão representados pela implementação e pela cobertura atual, o que pode comprometer a utilização do readiness como sinal confiável de disponibilidade.

Revise o fluxo de readiness e sua estratégia de validação considerando cenários reais de degradação antes de solicitar nova revisão.

[Jovinull]

Atualiza??o ap?s o review da PAV-35:

• O endpoint /ready agora aplica timeout de 2 segundos em cada verifica??o de Postgres e Valkey.
• Depend?ncias que rejeitam ou ficam sem resposta resultam em HTTP 503, evitando que o readiness fique pendurado.
• Adicionado teste cobrindo uma depend?ncia que n?o responde.

Valida??o executada:

• Suite completa do backend: 576 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

[Jovinull]

Card

• PAV-35

Objetivo e escopo

• Tornar o estado operacional do backend observável sem alterar o contrato de GET /health.
• Adicionar rastreamento opcional de exceções inesperadas via Sentry.

O que foi feito

• Mantém GET /health como liveness do processo.
• Adiciona GET /ready, que verifica Postgres e Valkey e retorna 503 quando alguma dependência não está disponível.
• Inicializa o Sentry somente quando SENTRY_DSN está definido.
• Registra exceções inesperadas localmente com requestId, método e caminho, e envia esse contexto ao Sentry quando habilitado.
• Documenta SENTRY_DSN nos arquivos de exemplo e no README.

Módulos afetados

• backend/src/app.ts
• backend/src/errorTracking.ts
• backend/src/middleware/errorHandler.ts
• backend/src/server.ts
• backend/.env.example
• .env.example
• README.md

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/unit/app.test.ts tests/unit/errorTracking.test.ts tests/unit/middleware/errorHandler.test.ts tests/unit/services/server.test.ts - 4 arquivos e 43 testes aprovados.
• Os testes cobrem /health, /ready com dependências disponíveis, /ready com falha de dependência, ausência de SENTRY_DSN e captura de exceções com contexto.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.

Configuração e observações

• SENTRY_DSN é opcional. Sem a variável, o Sentry permanece desativado e os logs estruturados locais continuam ativos.
• O teste de readiness usa mocks das dependências; não foi necessário interromper Postgres ou Valkey locais.
• Não há alteração de schema nem migration nesta PR.

[hltav]

A descrição apresenta um resumo da implementação, mas ainda está fora do padrão de PR definido pelo projeto e não fornece contexto suficiente para uma revisão segura.

Por favor, complemente a PR conforme o template/documentação, incluindo:

• referência e critérios atendidos da PAV-35;
• objetivo e escopo da alteração;
• módulos/arquivos relevantes afetados;
• comportamento esperado de /health e /ready;
• configuração necessária para Sentry e variáveis de ambiente;
• testes executados e respectivos resultados;
  cenários de falha validados, especialmente indisponibilidade de Postgres/Valkey e ausência de SENTRY_DSN.

Após a adequação da descrição, seguimos com a revisão técnica.

[hltav]

A implementação contempla boa parte do escopo da PAV-35, porém o comportamento operacional dos healthchecks ainda não garante integralmente o critério de monitoramento de disponibilidade previsto no card.

Existem cenários de indisponibilidade das dependências que não estão representados pela implementação e pela cobertura atual, o que pode comprometer a utilização do readiness como sinal confiável de disponibilidade.

Revise o fluxo de readiness e sua estratégia de validação considerando cenários reais de degradação antes de solicitar nova revisão.

[Jovinull]

Atualiza??o ap?s o review da PAV-35:

• O endpoint /ready agora aplica timeout de 2 segundos em cada verifica??o de Postgres e Valkey.
• Depend?ncias que rejeitam ou ficam sem resposta resultam em HTTP 503, evitando que o readiness fique pendurado.
• Adicionado teste cobrindo uma depend?ncia que n?o responde.

Valida??o executada:

• Suite completa do backend: 576 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

[Jovinull]

Card

• PAV-35

Objetivo e escopo

• Tornar o estado operacional do backend observável sem alterar o contrato de GET /health.
• Adicionar rastreamento opcional de exceções inesperadas via Sentry.

O que foi feito

• Mantém GET /health como liveness do processo.
• Adiciona GET /ready, que verifica Postgres e Valkey e retorna 503 quando alguma dependência não está disponível.
• Inicializa o Sentry somente quando SENTRY_DSN está definido.
• Registra exceções inesperadas localmente com requestId, método e caminho, e envia esse contexto ao Sentry quando habilitado.
• Documenta SENTRY_DSN nos arquivos de exemplo e no README.

Módulos afetados

• backend/src/app.ts
• backend/src/errorTracking.ts
• backend/src/middleware/errorHandler.ts
• backend/src/server.ts
• backend/.env.example
• .env.example
• README.md

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/unit/app.test.ts tests/unit/errorTracking.test.ts tests/unit/middleware/errorHandler.test.ts tests/unit/services/server.test.ts - 4 arquivos e 43 testes aprovados.
• Os testes cobrem /health, /ready com dependências disponíveis, /ready com falha de dependência, ausência de SENTRY_DSN e captura de exceções com contexto.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.

Configuração e observações

• SENTRY_DSN é opcional. Sem a variável, o Sentry permanece desativado e os logs estruturados locais continuam ativos.
• O teste de readiness usa mocks das dependências; não foi necessário interromper Postgres ou Valkey locais.
• Não há alteração de schema nem migration nesta PR.

[hltav]

A descrição apresenta um resumo da implementação, mas ainda está fora do padrão de PR definido pelo projeto e não fornece contexto suficiente para uma revisão segura.

Por favor, complemente a PR conforme o template/documentação, incluindo:

• referência e critérios atendidos da PAV-35;
• objetivo e escopo da alteração;
• módulos/arquivos relevantes afetados;
• comportamento esperado de /health e /ready;
• configuração necessária para Sentry e variáveis de ambiente;
• testes executados e respectivos resultados;
  cenários de falha validados, especialmente indisponibilidade de Postgres/Valkey e ausência de SENTRY_DSN.

Após a adequação da descrição, seguimos com a revisão técnica.

[hltav]

A implementação contempla boa parte do escopo da PAV-35, porém o comportamento operacional dos healthchecks ainda não garante integralmente o critério de monitoramento de disponibilidade previsto no card.

Existem cenários de indisponibilidade das dependências que não estão representados pela implementação e pela cobertura atual, o que pode comprometer a utilização do readiness como sinal confiável de disponibilidade.

Revise o fluxo de readiness e sua estratégia de validação considerando cenários reais de degradação antes de solicitar nova revisão.

[Jovinull]

Atualiza??o ap?s o review da PAV-35:

• O endpoint /ready agora aplica timeout de 2 segundos em cada verifica??o de Postgres e Valkey.
• Depend?ncias que rejeitam ou ficam sem resposta resultam em HTTP 503, evitando que o readiness fique pendurado.
• Adicionado teste cobrindo uma depend?ncia que n?o responde.

Valida??o executada:

• Suite completa do backend: 576 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

[Jovinull]

Card

• PAV-35

Objetivo e escopo

• Tornar o estado operacional do backend observável sem alterar o contrato de GET /health.
• Adicionar rastreamento opcional de exceções inesperadas via Sentry.

O que foi feito

• Mantém GET /health como liveness do processo.
• Adiciona GET /ready, que verifica Postgres e Valkey e retorna 503 quando alguma dependência não está disponível.
• Inicializa o Sentry somente quando SENTRY_DSN está definido.
• Registra exceções inesperadas localmente com requestId, método e caminho, e envia esse contexto ao Sentry quando habilitado.
• Documenta SENTRY_DSN nos arquivos de exemplo e no README.

Módulos afetados

• backend/src/app.ts
• backend/src/errorTracking.ts
• backend/src/middleware/errorHandler.ts
• backend/src/server.ts
• backend/.env.example
• .env.example
• README.md

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/unit/app.test.ts tests/unit/errorTracking.test.ts tests/unit/middleware/errorHandler.test.ts tests/unit/services/server.test.ts - 4 arquivos e 43 testes aprovados.
• Os testes cobrem /health, /ready com dependências disponíveis, /ready com falha de dependência, ausência de SENTRY_DSN e captura de exceções com contexto.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.

Configuração e observações

• SENTRY_DSN é opcional. Sem a variável, o Sentry permanece desativado e os logs estruturados locais continuam ativos.
• O teste de readiness usa mocks das dependências; não foi necessário interromper Postgres ou Valkey locais.
• Não há alteração de schema nem migration nesta PR.

[hltav]

A descrição apresenta um resumo da implementação, mas ainda está fora do padrão de PR definido pelo projeto e não fornece contexto suficiente para uma revisão segura.

Por favor, complemente a PR conforme o template/documentação, incluindo:

• referência e critérios atendidos da PAV-35;
• objetivo e escopo da alteração;
• módulos/arquivos relevantes afetados;
• comportamento esperado de /health e /ready;
• configuração necessária para Sentry e variáveis de ambiente;
• testes executados e respectivos resultados;
  cenários de falha validados, especialmente indisponibilidade de Postgres/Valkey e ausência de SENTRY_DSN.

Após a adequação da descrição, seguimos com a revisão técnica.

[hltav]

A implementação contempla boa parte do escopo da PAV-35, porém o comportamento operacional dos healthchecks ainda não garante integralmente o critério de monitoramento de disponibilidade previsto no card.

Existem cenários de indisponibilidade das dependências que não estão representados pela implementação e pela cobertura atual, o que pode comprometer a utilização do readiness como sinal confiável de disponibilidade.

Revise o fluxo de readiness e sua estratégia de validação considerando cenários reais de degradação antes de solicitar nova revisão.

[Jovinull]

Atualiza??o ap?s o review da PAV-35:

• O endpoint /ready agora aplica timeout de 2 segundos em cada verifica??o de Postgres e Valkey.
• Depend?ncias que rejeitam ou ficam sem resposta resultam em HTTP 503, evitando que o readiness fique pendurado.
• Adicionado teste cobrindo uma depend?ncia que n?o responde.

Valida??o executada:

• Suite completa do backend: 576 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.

[Jovinull]

Card

• PAV-35

Objetivo e escopo

• Tornar o estado operacional do backend observável sem alterar o contrato de GET /health.
• Adicionar rastreamento opcional de exceções inesperadas via Sentry.

O que foi feito

• Mantém GET /health como liveness do processo.
• Adiciona GET /ready, que verifica Postgres e Valkey e retorna 503 quando alguma dependência não está disponível.
• Inicializa o Sentry somente quando SENTRY_DSN está definido.
• Registra exceções inesperadas localmente com requestId, método e caminho, e envia esse contexto ao Sentry quando habilitado.
• Documenta SENTRY_DSN nos arquivos de exemplo e no README.

Módulos afetados

• backend/src/app.ts
• backend/src/errorTracking.ts
• backend/src/middleware/errorHandler.ts
• backend/src/server.ts
• backend/.env.example
• .env.example
• README.md

Validação

• CI do PR concluído com sucesso, incluindo coverage de frontend e backend, lint e build.
• npm exec --workspace=backend vitest run tests/unit/app.test.ts tests/unit/errorTracking.test.ts tests/unit/middleware/errorHandler.test.ts tests/unit/services/server.test.ts - 4 arquivos e 43 testes aprovados.
• Os testes cobrem /health, /ready com dependências disponíveis, /ready com falha de dependência, ausência de SENTRY_DSN e captura de exceções com contexto.
• npm run lint --workspace=frontend - concluído sem erros.
• npm run build --workspace=frontend - concluído com sucesso.

Configuração e observações

• SENTRY_DSN é opcional. Sem a variável, o Sentry permanece desativado e os logs estruturados locais continuam ativos.
• O teste de readiness usa mocks das dependências; não foi necessário interromper Postgres ou Valkey locais.
• Não há alteração de schema nem migration nesta PR.

[hltav]

A descrição apresenta um resumo da implementação, mas ainda está fora do padrão de PR definido pelo projeto e não fornece contexto suficiente para uma revisão segura.

Por favor, complemente a PR conforme o template/documentação, incluindo:

• referência e critérios atendidos da PAV-35;
• objetivo e escopo da alteração;
• módulos/arquivos relevantes afetados;
• comportamento esperado de /health e /ready;
• configuração necessária para Sentry e variáveis de ambiente;
• testes executados e respectivos resultados;
  cenários de falha validados, especialmente indisponibilidade de Postgres/Valkey e ausência de SENTRY_DSN.

Após a adequação da descrição, seguimos com a revisão técnica.

[hltav]

A implementação contempla boa parte do escopo da PAV-35, porém o comportamento operacional dos healthchecks ainda não garante integralmente o critério de monitoramento de disponibilidade previsto no card.

Existem cenários de indisponibilidade das dependências que não estão representados pela implementação e pela cobertura atual, o que pode comprometer a utilização do readiness como sinal confiável de disponibilidade.

Revise o fluxo de readiness e sua estratégia de validação considerando cenários reais de degradação antes de solicitar nova revisão.

[Jovinull]

Atualiza??o ap?s o review da PAV-35:

• O endpoint /ready agora aplica timeout de 2 segundos em cada verifica??o de Postgres e Valkey.
• Depend?ncias que rejeitam ou ficam sem resposta resultam em HTTP 503, evitando que o readiness fique pendurado.
• Adicionado teste cobrindo uma depend?ncia que n?o responde.

Valida??o executada:

• Suite completa do backend: 576 testes aprovados.
• Lint do frontend: conclu?do sem erros (apenas warning preexistente de depend?ncia de hook).
• Build do frontend: conclu?do com sucesso.