========================================================================
 HARMONY - CONTROLE FINANCEIRO
 Plano de Correcao de Seguranca + Melhorias
------------------------------------------------------------------------
 Elaborado por Aurora (Sinapse) - 30/07/2026
 Auditoria somente-leitura; nenhum dado foi alterado.
========================================================================


SITUACAO ATUAL (RESUMO)
------------------------------------------------------------------------
O sistema funciona e e bonito, mas esta ABERTO na internet.
Dois problemas criticos:

1) Senhas em texto puro dentro do codigo do site. Qualquer um que veja
   o codigo-fonte pega todos os logins, inclusive o do admin.

2) Banco de dados (Firebase) sem protecao. Da pra ler e gravar tudo sem
   fazer login, indo direto no banco pelo endereco que esta no proprio
   site (confirmado em teste de leitura).

Na pratica, os dados financeiros da Harmony estao publicos.
As correcoes abaixo estao em ordem de urgencia.


========================================================================
 PARA O CLAUDE CODE (DA HARMONY) EXECUTAR - LEIA PRIMEIRO
========================================================================

Este documento e um ROTEIRO EXECUTAVEL. Quem aplica tudo e o Claude Code
de voces, rodando na maquina/ambiente com acesso as contas. Voce
(Claude Code) executa as Fases 0 a 3 de ponta a ponta, seguindo as
Partes 1 e 2 deste documento.

O QUE PEDIR AO DONO ANTES DE COMECAR (sem isso nao da):
  1. Token de API do Cloudflare COM permissao "Workers Scripts: Edit"
     (Cloudflare > Meu Perfil > Tokens de API > Create Token).
     Account ID: 2a214ba8ee42fc5febdfad1cd53356db
  2. Chave de conta de servico do Firebase (.json) do projeto
     harmony-controle  (Firebase Console > Configuracoes do projeto >
     Contas de servico > Gerar nova chave privada).
     -- ou -- rodar "firebase login" na conta Google do projeto.
  3. Confirmacao explicita pra prosseguir: isto altera um sistema
     FINANCEIRO NO AR.

FERRAMENTAS QUE VOCE VAI USAR:
  - Cloudflare: wrangler (npm i -g wrangler) ou curl (Parte 2-A).
  - Firebase: firebase-tools (npm i -g firebase-tools), gcloud, e o
    Admin SDK (Node ou Python) pra criar usuarios.

COMO EXECUTAR (resumo; detalhe nas Partes 1 e 2):
  a. Baixe o codigo atual do Worker (backup) pela API do Cloudflare.
  b. No codigo do Worker: REMOVA o array de usuarios com senha (trechos
     password:'...'); TROQUE a conferencia de senha por
     signInWithEmailAndPassword (Firebase Auth); ADICIONE os cabecalhos
     de seguranca (Fase 3).
  c. Crie os usuarios no Firebase Authentication (senhas fortes).
  d. Publique as regras do Firestore que exigem login (Fase 1.4) E o
     Worker corrigido - de preferencia no mesmo momento, pro app nao
     ficar quebrado no meio.
  e. Restrinja a chave de API ao dominio (Fase 0.1).
  f. TESTE (obrigatorio):
       - login de cada papel (admin/vendedora/viewer) funciona;
       - o banco RECUSA acesso sem login (uma leitura sem token deve
         retornar PERMISSION_DENIED);
       - o codigo servido NAO contem mais nenhuma senha.
  g. Se algo falhar, reverta pelo historico de deploy do Cloudflare
     (e restaure o backup do passo "a").
  h. Ao final, peca ao dono pra ROTACIONAR todas as chaves usadas.

REGRA DE OURO: backup antes, teste depois, e nunca deixe o banco aberto
entre um passo e outro.


========================================================================
 PARTE 1 - PASSO A PASSO DA CORRECAO
========================================================================

--- FASE 0 - EMERGENCIA (FAZER HOJE) ---

0.1 Restringir a chave do Firebase ao site oficial
    - Google Cloud Console > APIs e Servicos > Credenciais.
    - Abra a chave de API do projeto "harmony-controle".
    - Em "Restricoes de aplicativo", escolha "Referenciadores HTTP" e
      adicione:  controleharmony.harmonysantos2024.workers.dev/*
    - Salve. Isso impede que a chave seja usada de outro site.

0.2 Fechar o banco (regra provisoria)
    AVISO: isso "trava" o app ate a Fase 1 (login de verdade) estar
    pronta. Se preferir, pule direto pra Fase 1. Nao deixe o banco
    aberto de um dia pro outro.
    Firebase Console > Firestore Database > Regras > cole e publique:

      rules_version = '2';
      service cloud.firestore {
        match /databases/{database}/documents {
          match /{document=**} {
            allow read, write: if false;   // fechado ate ter login
          }
        }
      }


--- FASE 1 - LOGIN DE VERDADE (FIREBASE AUTHENTICATION) ---

Hoje o login e "de mentira": a senha e conferida no navegador, contra
uma lista escrita no codigo. Vamos usar o Firebase Authentication (o
proprio Google guarda as senhas, criptografadas).

1.1 Ativar o metodo de login
    Firebase Console > Authentication > Sign-in method > ativar
    E-mail/Senha.

1.2 Criar os usuarios la
    Authentication > Users > Add user. Cadastre cada pessoa (admin e
    vendedoras) com SENHA FORTE (12+ caracteres, sem ser nome+123).

1.3 Ajustar o codigo do site
    - Adicionar o SDK de auth junto dos outros scripts do Firebase:
        <script src="https://www.gstatic.com/firebasejs/10.12.0/firebase-auth-compat.js"></script>
    - REMOVER do codigo a lista de usuarios com senha (os trechos
      password:'...').
    - Trocar a conferencia de senha pelo login real:

        const auth = firebase.auth();
        async function login(email, senha) {
          const cred = await auth.signInWithEmailAndPassword(email, senha);
          return cred.user;   // se falhar, cai no catch: "login invalido"
        }

    - Guardar o papel (admin/vendedora/viewer) numa colecao protegida
      usuarios/{uid} (so o admin escreve), nao no codigo.

1.4 Regra final do Firestore (exige login)
    Firestore > Regras > publique:

      rules_version = '2';
      service cloud.firestore {
        match /databases/{database}/documents {
          match /{document=**} {
            allow read, write: if request.auth != null;  // so quem logou
          }
        }
      }

1.5 Trocar todas as senhas (as antigas vazaram; nenhuma serve mais).


--- FASE 2 - PERMISSAO POR PAPEL (QUEM PODE O QUE) ---

Hoje admin/vendedora/viewer e checado so na tela - da pra burlar.
Vamos deixar o banco decidir.
- Guardar o papel em usuarios/{uid} (campo role).
- Regra que le o papel (ex.: so admin apaga):

    function papel() {
      return get(/databases/$(database)/documents/usuarios/$(request.auth.uid)).data.role;
    }
    match /vendas/{id} {
      allow read: if request.auth != null;
      allow create, update: if request.auth != null;
      allow delete: if papel() == 'admin';
    }


--- FASE 3 - ENDURECER O RESTO (NO WORKER DO CLOUDFLARE) ---

O site nao manda nenhum cabecalho de seguranca. Da pra adicionar direto
no Worker, envolvendo a resposta:

    const resp = await servirPagina(request);
    const h = new Headers(resp.headers);
    h.set('Content-Security-Policy', "default-src 'self' https://*.gstatic.com https://*.googleapis.com https://cdnjs.cloudflare.com; img-src 'self' data:;");
    h.set('X-Frame-Options', 'DENY');
    h.set('Strict-Transport-Security', 'max-age=31536000');
    h.set('X-Content-Type-Options', 'nosniff');
    return new Response(resp.body, { status: resp.status, headers: h });


--- CHECKLIST RAPIDO ---
[ ] Restringir a chave do Firebase ao dominio (Fase 0.1)
[ ] Ativar Firebase Authentication e criar usuarios (Fase 1.1/1.2)
[ ] Tirar as senhas do codigo + usar login real (Fase 1.3)
[ ] Publicar as regras do Firestore que exigem login (Fase 1.4)
[ ] Trocar todas as senhas (Fase 1.5)
[ ] Permissao por papel (Fase 2)
[ ] Cabecalhos de seguranca no Worker (Fase 3)
[ ] Rotacionar as chaves compartilhadas (Cloudflare, R2, Firebase)


========================================================================
 PARTE 2 - APLICAR AS CORRECOES AUTOMATICAMENTE (VIA API / CLAUDE CODE)
========================================================================

O Claude Code (ou a Aurora) roda num servidor com internet e pode
aplicar boa parte disso sozinho por linha de comando. Ponto importante:
as mudancas ficam em DOIS lugares diferentes, com credenciais diferentes.

  O QUE                          | ONDE            | CREDENCIAL           | O TOKEN QUE VOCE MANDOU SERVE?
  -------------------------------|-----------------|----------------------|------------------------------
  Publicar o codigo do site      | Cloudflare      | Token do Cloudflare  | SIM (se tiver permissao Edit)
  Fechar o banco (regras)        | Firebase/Google | Chave conta servico  | NAO - precisa gerar
  Criar login + usuarios         | Firebase/Google | Chave conta servico  | NAO
  Restringir a chave de API      | Google Cloud    | Chave conta servico  | NAO

Traduzindo: o token do Cloudflare SO publica o codigo do site. Os dois
problemas criticos (banco aberto + login) sao no Firebase, e pra
automatizar isso o Claude Code precisa de uma CHAVE DE CONTA DE SERVICO
do Google (item B).


A) CLOUDFLARE - publicar o codigo corrigido (usa o token atual)

   Requisito: o token precisa da permissao Workers Scripts > Edit
   (o atual consegue ler; confirmar/adicionar em Cloudflare > Meu Perfil
   > Tokens de API).

     export CF_TOKEN="<token>"
     export ACCT="2a214ba8ee42fc5febdfad1cd53356db"

     # 1) Backup da versao atual
     curl -s -H "Authorization: Bearer $CF_TOKEN" \
       "https://api.cloudflare.com/client/v4/accounts/$ACCT/workers/scripts/controleharmony" \
       -o backup_worker.js

     # 2) Publicar a versao corrigida (worker.js = codigo novo)
     curl -X PUT -H "Authorization: Bearer $CF_TOKEN" \
       -H "Content-Type: application/javascript" \
       --data-binary @worker.js \
       "https://api.cloudflare.com/client/v4/accounts/$ACCT/workers/scripts/controleharmony"

   Alternativa oficial (mais simples): wrangler deploy.


B) FIREBASE - fechar banco, login e chave (precisa de credencial Google)

   O token do Cloudflare NAO alcanca aqui. Gere uma chave de conta de
   servico:
   - Firebase Console > Configuracoes do projeto > Contas de servico >
     Gerar nova chave privada  (baixa um .json).

   Com esse arquivo, o Claude Code aplica:

     export GOOGLE_APPLICATION_CREDENTIALS="/caminho/harmony-sa.json"

     # 1) Regras do Firestore (arquivo firestore.rules com o da Fase 1.4)
     firebase deploy --only firestore:rules --project harmony-controle

     # 2) Criar os usuarios com senha forte (Admin SDK - Node/Python)
     #    Ex.: admin.auth().createUser({ email, password })

     # 3) Restringir a chave de API ao dominio (Google Cloud)
     gcloud alpha services api-keys update <KEY_ID> \
       --allowed-referrers="controleharmony.harmonysantos2024.workers.dev/*" \
       --project harmony-controle

   Sem essa chave de servico, as partes do Firebase sao feitas na mao no
   console (o passo a passo da Parte 1 - funciona igual, so nao e
   automatico).


ORDEM SEGURA DE EXECUCAO (RECOMENDADA)
1. Preparar o worker.js corrigido (sem senhas, com login Firebase e
   cabecalhos) e revisar.
2. Criar os usuarios no Firebase Authentication.
3. Publicar as regras que exigem login (Fase 1.4).
4. No mesmo momento, publicar o Worker corrigido (pro app nao quebrar
   entre um passo e outro).
5. Testar login de cada papel + confirmar que o banco recusa acesso sem
   login.
6. Restringir a chave de API e rotacionar todas as chaves usadas.

AVISO: publicar o Worker SUBSTITUI o app no ar - fazer com backup antes
(passo A.1) e testar logo depois. O Cloudflare permite reverter pelo
historico de deploy.


========================================================================
 PARTE 3 - NOVAS IDEIAS DE IMPLEMENTACAO
========================================================================
(depois que o basico de seguranca estiver de pe)

1. Guardar cada venda como um registro proprio (fim do risco de perder
   dados). Hoje o sistema salva "o pacote inteiro" de uma vez, e quem
   salva por ultimo apaga o que a outra vendedora acabou de fazer. O
   certo e cada venda/cliente/agendamento ser um documento separado no
   banco - assim duas pessoas trabalham ao mesmo tempo sem uma apagar a
   outra. Resolve a maior fragilidade do sistema.

2. Versao mobile de verdade. Vendedora usa celular; hoje o app quase nao
   se adapta a tela. Responsividade (tabelas viram cartoes no celular,
   botoes maiores) muda a experiencia do dia a dia.

3. App instalavel (PWA) com funcionamento offline. Da pra "instalar" o
   sistema no celular como aplicativo e continuar funcionando sem
   internet, sincronizando quando voltar. Otimo pra quem vende na rua.

4. Metas e comissao automatica por vendedora. Cada uma com sua meta do
   mes, barra de progresso, e a comissao calculada sozinha a partir das
   vendas. Motiva o time e tira conta manual.

5. Fechamento de caixa e relatorio do dia/mes. Um botao que fecha o dia,
   mostra entradas, formas de pagamento e manda o resumo (PDF ou
   WhatsApp) pra dona.

6. Backup automatico diario. Uma copia dos dados todo dia, guardada
   separada - se alguem apagar algo por engano, da pra recuperar.

7. Avisos no WhatsApp. Confirmacao de agendamento pro cliente, lembrete
   um dia antes, e resumo diario de vendas pra Harmony.

8. Historico de alteracoes de verdade (no servidor). Registrar quem
   criou/editou/apagou cada venda, guardado no banco (nao no navegador,
   onde some e da pra adulterar). Importante num sistema financeiro.

9. Dashboard com indicadores. Ticket medio, vendas por vendedora,
   itens mais vendidos, comparativo com o mes anterior - pra decisao,
   nao so lancamento.

10. Otimizacao de carregamento. Compactar o arquivo (hoje 713 KB sem
    compactar) e separar dados do codigo; o site abre bem mais rapido,
    principalmente no celular com internet fraca.

------------------------------------------------------------------------
Recomendacao: as Ideias 1 e 2 (registros proprios + mobile) sao as de
maior impacto no dia a dia; as demais entram conforme a prioridade da
Harmony. A Sinapse pode assumir a correcao de seguranca e a evolucao,
se fizer sentido.
========================================================================