Como o csmkt roda, como subir no seu computador e como o deploy acontece

O produto em uma tela

Marketplace peer-to-peer de skins de CS2, com preço em reais e pagamento por Pix. A plataforma não guarda itens: ela segura o dinheiro, verifica a entrega e só então paga o vendedor.

Arquitetura

Seis repositórios separados por camada. O core é um monolito modular: a mesma imagem roda em três papéis (APP_ROLE).

Infra no Dokploy

Projeto csmkt no Dokploy. Um compose de infraestrutura e uma aplicação por processo, cada uma buildada a partir do próprio repositório.

Aplicações (buildadas dos repositórios)

Compose infra (imagens públicas com versão fixa)

Como o deploy funciona

Cada aplicação está ligada ao seu repositório, branch main, com deploy automático. Um push na main dispara o build no Dokploy.

1. Push ou merge na main

   O GitHub App do Dokploy recebe o evento do repositório.

2. Build de cada serviço ligado ao repositório

   Um push em csmkt-api rebuilda api-migrate, api, worker e scheduler; em csmkt-ai, os três da IA; em csmkt-platform, sandbox e flagd. O build usa o Dockerfile do próprio repositório, sem alteração.

3. Dependência interna resolvida no build

   Api, web e admin instalam o @csmkt/contracts do registry interno. O hash do pacote precisa bater com o do pnpm-lock.yaml, então o registry guarda exatamente o tarball publicado pelo dono do projeto.

4. Migrations

   api-migrate e ai-migrate rodam uma vez e terminam. Elas não bloqueiam a subida da API, por isso toda migration precisa ser compatível com a versão anterior (expand/contract), como o projeto já exige.

5. Troca do container

   A versão nova sobe antes de a antiga sair (start-first), e a saúde é conferida pelo HEALTHCHECK de cada imagem. Se a atualização falhar, o serviço volta para a versão anterior.

Rodar tudo no seu computador

O ambiente local é o compose do csmkt-platform, com o mesmo sandbox do staging. Os repositórios são privados: o acesso é por convite.

Pré-requisitos

1. Clonar os seis repositórios lado a lado

Os Makefiles usam caminhos relativos como ../csmkt-contracts, então as seis pastas ficam dentro de uma mesma pasta.

mkdir -p csmkt && cd csmkt
for r in platform contracts api ai web admin; do
  git clone git@github.com:Gacktto/csmkt-$r.git
done

2. Subir a stack (primeira vez)

cd csmkt-platform
git config core.hooksPath .githooks
cp .env.example .env
./scripts/gen-local-secrets.sh             # gera senhas e chaves locais no .env
make up-infra                              # banco, cache, S3, e-mail, Keycloak, flags, sandbox, registry
./scripts/registry-login.sh                # cria o publicador do registry local
make -C ../csmkt-contracts install publish # publica o @csmkt/contracts no registry local
make up                                    # builda e sobe api, worker, scheduler, ai, web e admin
make ps                                    # todos healthy

3. Endereços locais

Todas as portas escutam só em 127.0.0.1 e podem ser trocadas no .env (variáveis HOST_PORT_*).

4. Dados de demonstração e testes

make seed-demo                       # vendedores com anúncios e compradores com saldo, pelos fluxos reais
make demo-order VARIANT=correct      # compra, troca, verificação, proteção e liberação
make demo-payout                     # saque: TOTP, KYC, chave Pix, cool-down
make ci                              # lint, testes, cobertura e scanners do repositório
make ci-all                          # ci de todos os repositórios + E2E (com a stack no ar)

Para ver a liberação na hora, o PROTECTION_HOLD_HOURS aceita fração no ambiente local (por exemplo 0.01). Em produção ele precisa ser de pelo menos 168 horas.

Como funciona por dentro

O fluxo de uma compra, do Pix até a liberação ao vendedor.

1. Depósito

   O comprador gera uma cobrança Pix. O PSP avisa por webhook assinado; a API confere a assinatura sobre o corpo bruto, guarda o evento e reconsulta o PSP antes de creditar o saldo.

2. Compra

   Numa única transação: o anúncio é travado no preço visto pelo comprador, as regras de risco rodam, a taxa é calculada e congelada na ordem e o valor passa de available para held.

3. Troca na Steam

   O vendedor confirma e envia a oferta pela própria conta. A verificação compara os inventários: o item saiu do vendedor e um item com a mesma impressão digital chegou ao comprador. Caso ambíguo vai para disputa; nunca libera sozinho.

4. Proteção

   A ordem fica em proteção durante a janela da Steam. Se a troca for revertida, o comprador é reembolsado e o vendedor é restringido.

5. Liberação

   Fim da proteção sem reversão: o vendedor recebe o valor menos a comissão (regra semeada: 5% do vendedor) e o split é feito no PSP.

Estados da ordem

Ledger de partidas dobradas

Saque

KYC pela subconta do PSP (um CPF por conta), chave Pix só do mesmo CPF, 2FA com reconfirmação, espera de 48 horas depois de mudanças sensíveis, limites diários por nível e revisão manual do primeiro saque.

IA

A IA é um processo separado e só adiciona: se cair ou demorar, compra e venda seguem normalmente. Ela nunca libera dinheiro nem decide disputa; o score de risco só pode mandar algo para revisão.

Sandbox x real

O staging roda inteiro contra simulações. "Fase concluída" no roadmap significa implementada e testada contra o sandbox.