Relatório de Auditoria Técnica (Pipeline)

Data: 2026-01-09 Versão do Pipeline: 1.0

1. Visão Geral

Auditoria focada nos fluxos críticos de negócio (Vendas e Precificação) identificados na fase de Análise.

2. Achados Críticos

🚨 Duplicação de Lógica de Negócio (DRY Violation)

A lógica que define quanto a plataforma cobra do lojista ("Hub Fee" / "Connect Fee") está duplicada em dois lugares críticos:

1. src/routes/orders.ts (Linha 66: getFeeForPlan)
2. src/routes/public-api.ts (Linha 790: getFeeForPlan)

Risco: Se a taxa mudar, é muito provável que um dos arquivos não seja atualizado, causando inconsistência financeira (cobrar errado ou exibir valor errado).

🔓 Risco de Segurança (Hardcoded Bypass)

O arquivo src/routes/public-api.ts contém um bypass de autenticação hardcoded:

if (apiKey === 'osk_SuperAdminStoreKey2025ForSaaS') { ... }

Embora útil para dev, este código não tem verificação de ambiente (c.env.ENVIRONMENT === 'development'), tornando-se uma backdoor potencial em produção.

⚠️ Configuração Inconsistente (Hardcoded Fallbacks)

Existe um objeto de configuração fallback gigante (linhas 770-787 de public-api.ts) que define taxas, markups e custos de envio. Em src/routes/orders.ts (linha 23), existe outra definição hardcoded de markups. Risco: Inconsistência de preços e taxas entre o que o usuário vê na loja e o que é cobrado no checkout.

3. Recomendações (Para o Arquiteto)

1. Centralizar Lógica Financeira: Criar src/services/marketplace.ts ou fees.ts para conter:

   • getFeeForPlan(plan)
   • getMarkupForPlan(plan)
   • Constantes de configuração padrão.

2. Hardening de Segurança:

   • Envolver o bypass de SuperAdmin em verificação estrita de ambiente ou movê-lo para variável de ambiente SUPER_ADMIN_KEY.

3. Unificar Lógica de Pedidos:

   • Refatorar POST /orders (Public API) e POST /marketplace/orders (Orders API) para usar um service comum de criação de pedido (createOrderCore), evitando divergência na lógica de validação e criação.

Aprovado por: Auditor Virtual 2️⃣

4. Auditoria de Saúde e Tipagem (2026-01-15)

Foco: Linting, Limpeza de Código e Segurança de Secrets.

✅ Correções Realizadas

1. Segurança de APIs: Identificadas e removidas chaves hardcoded (SERPAPI_KEY, INTERNAL_API_KEY) no backend. Refatoração do HubGateway para usar injeção de dependência.

   • Status: Resolvido (Requer validação de .env em produção).

2. Limpeza de Backend:

   • Remoção de ~200 warnings de lint (imports não usados, console.log inseguros).
   • Substituição de console.log por console.info para melhor observabilidade em logs estruturados.

3. Fixes de Frontend:

   • Correção de dependências de useEffect em Marketplace.tsx.
   • Melhora na tipagem de dados de produtos.

⚠️ Pontos de Atenção (L3)

• Tipagem 'Any': Ainda existem usos de any no backend para evitar refatoração massiva de lógica legada. Recomendado planejar sprint de "Strict Type Adoption".
• Prompt Injection: Alertas do ArmorIQ sobre prompts não escapados nos Agents. Risco mitigado pelo contexto controlado, mas requer revisão de segurança dedicada.

Status Final: Projeto Estável (Build & Test OK). Aprovado por: Pipeline Antigravity 🚀