Inventário de Aplicações → Repositórios

Data: 2026-08-31 · revisado em 2026-09-02 pela fase 0 do runbook da RFC-0009 Fonte: AWS ECS sa-east-1 (conta 025910518967), 19 clusters — mapeamento feito pela imagem ECR de cada task definition ativa, cruzada com os workflows de build de cada repositório da org quanthubbr.

O que a revisão de 2026-09-02 mudou. A fase 0 da RFC-0009 existe porque a tabela STACKS vai carimbar label a partir daqui: item classificado errado vira label errado, e corrigir label já escrito é trabalho que não precisava existir. Foram corrigidos o repositório do Backoffice (A5), a seção "Plataforma nova" (A0), o balde "interno" (A1/A2) e a linha do Aviator binary — cada um com a evidência ao lado. O que não foi resolvido está marcado como pendência, nunca preenchido por suposição.

---

Stack padrão (roda em quase todo cliente)

O serviço de Risk Ops sobe três containers na mesma task, todos construídos pelo mesmo repositório.

Risk Ops e BI SERÃO DESCONTINUADOS (dono da plataforma, 2026-09-10). Quem os substitui é o PropManager Admin, que passa a integrar a stack prophub. Os dois seguem no catálogo e mantidos — há cliente usando. Detalhe e alcance na emenda da seção Plataforma e ferramentas internas.

Corrigido em 2026-09-02 (A5): a imagem directus é buildada pelo quanthubbr/paas-pipeline, não pelo fork quanthubbr/directus. Evidência: paas-pipeline/.github/workflows/ci.yml declara ECR_REPOSITORY: directus, builda e empurra a imagem, e o repositório tem directus/ na raiz mais os workflows que operam a frota (deploy-clusters.yml, client-drift-check.yml, rollback-client-db.yml, promote-to-staging.yml). O quanthubbr/directus é o fork do Directus upstream — descrição e workflows são os do projeto original (changeset-check, cla, blackbox), e o último push foi em 2025-10-03. Ele não é o que roda em cliente nenhum.

Consequência para o catálogo: o source-repo do bloco backoffice é o paas-pipeline.

---

Conectores de corretora

Todos os conectores são construídos pelo repositório único quanthubbr/risk-engine-csharp, que publica sete imagens ECR distintas a partir da mesma base de código. Seis delas estão na tabela abaixo; a sétima (risk-engine-dashboard) saiu daqui em 2026-09-02 por não ser conector — ver A2, logo abaixo.

A2 (2026-09-02): o RE Dashboard saiu desta tabela. O serviço é re-dashboard-re-dashboardsvc — sem prefixo de cliente, ao contrário de todos os outros aqui. É singleton, logo aplicação interna e não conector por cliente. Foi para "Plataforma e ferramentas internas", abaixo.

Pendência — Rithmic (A5): as duas imagens Rithmic não aparecem nos workflows do clone local de risk-engine-csharp, e o repositório que as constrói continua não confirmado. Em standby por decisão do dono da plataforma (2026-09-02): o Rithmic ainda está em desenvolvimento. Isso mantém a fase 3 da RFC-0009 (gateways) bloqueada de propósito, não por falta de investigação.

Atenção: o repositório quanthubbr/risk-engine (imagem risk-engine) é uma coisa diferente — é o motor de regras de risco e não tem serviço em ECS. Não confundir com risk-engine-csharp.

---

Plataforma e ferramentas internas

Aplicação interna aqui quer dizer: instância única, sem prefixo de cliente, operada pela própria equipe. É o balde que vira a stack interno da RFC-0009.

Atenção: o repositório se chama devops-dashboard mas a imagem ECR se chama aws-dashboard. Os nomes divergem — vale lembrar na hora de buscar.

RE Dashboard é o monitoramento interno do Risk Engine (A2). Fica no ECS em standby por decisão do dono da plataforma; quando migrar, migra como aplicação normal da plataforma — categoria do devops-dashboard, não bloco de tenant. A config dele é fan-in (Mt5RestApi__Hosts__<tenant>, uma entrada por tenant), e o resolvedor derives do scaffolder só faz fan-out: não é coberto pela RFC-0008.

Billing é tooling, confirmado pelo dono da plataforma em 2026-09-02 (A5): não tem serviço nem imagem, e sai do balde de deploy. Fica listado aqui como repositório, não como aplicação.

Pipeline PaaS saiu desta seção (A5, 2026-09-02). Ele não é ferramenta interna: paas-pipeline é onde o Directus mora — o repositório que builda a imagem directus do bloco backoffice e que opera o deploy da frota de clientes. Está no "Stack padrão", na linha do Backoffice, com a evidência.

Movidos daqui para "opcionais por cliente" (A1)

Os dois itens abaixo estavam neste balde e não são internos: o nome do serviço traz prefixo de cliente, logo são por-tenant. Na RFC-0009 pertencem à stack prophub como blocos opcionais.

Medido em 2026-09-02, e muda o que se sabia dos dois:

Nenhum dos dois roda hoje. desiredCount: 0 no OMS nos 2 clusters que o têm (euro, 5p) — e, fora desta tabela, o mesmo vale para o BI: 0 em todos os 7. O inventário os contava como "2 clusters" e "7 clusters" porque contava existência de serviço, não execução. O BI não está descontinuado, e o motivo importa: os 7 tenants foram clientes que degustaram a ferramenta (dono da plataforma, 2026-09-03). O zero é fim de avaliação, não desativação — é um bloco que se liga por cliente quando vendido. Ler esses zeros como "serviço morto" levaria a tirá-lo do catálogo, e o próximo cliente que comprar BI recomeçaria do zero.

EMENDA (2026-09-10, dono da plataforma) — o BI E o Risk Ops SERÃO DESCONTINUADOS. Quem os substitui é o PropManager Admin, e ele passa a fazer parte da stack prophub. O parágrafo acima fica REVOGADO quanto ao status: as medições seguem válidas (0/7 no BI), mas a conclusão "é um bloco que se liga por cliente quando vendido" não — não há cliente novo para ligar.

Três coisas que esta emenda NÃO diz, e que importam mais que ela:

1. Não é remoção do catálogo. Há cliente usando: o Risk Ops roda 1/1 em 8 dos 10 tenants que o declaram (medido 2026-09-03). Os blocos continuam no catálogo, continuam compondo e continuam mantidos. Descontinuado aqui significa não entra em cliente novo e tem substituto definido — não pode sair. A razão do parágrafo acima (tirar do catálogo faria o próximo cliente recomeçar do zero) continua valendo com força maior para quem JÁ usa.
2. "Risk Ops" é o serviço inteiro, ou seja os três containers do risk-ops-tool: os blocos risk-ops e risk-analysis-api, mais o profit-split-engine (medido em 2026-09-03 em demo e dev, deliberadamente nunca modelado). O risk-analysis-api não tem consumidor fora do risk-ops, então vai junto por construção.
3. A varredura de consumidores externos do risk-api nunca terminou — parou em 5 de 18 clusters quando a credencial SSO expirou. Descontinuar não fecha essa pendência: ela é o que diz se alguém de FORA chama a API, e a resposta muda o plano de desligamento, não o de catálogo.

Esse estado passou a ser exprimível com replicas: 0 na forma api (PR #236). scaling.min continua em minimum: 1: HPA com minReplicas: 0 exige o feature gate HPAScaleToZero.

O bloqueio do OMS não é o "IP fixo". Ele aponta para 172.31.6.238 no QuestDB (porta 9000 HTTP e 8812 pg wire) e no Postgres. Um Service do Kubernetes resolveria o endereço sem esforço — o problema real era que o QuestDB não estava no cluster: roda no host trading-hub-01, em Docker Compose. É migração de banco de série temporal, não troca de string.

Metade desse bloqueio caiu em 2026-09-04 (RFC-0010 §8.1, PR #249): o QuestDBInstance existe como XRD, com Composition emitindo StatefulSet + Service + ConfigMap, e aparece no catálogo ao lado de Postgres e Redis. A outra metade continua de pé, e é a que importa para o oms: nenhuma instância foi provisionada, e não deve ser até o time do OMS responder se algum fluxo de operação cruza valores de client (RFC-0010 §9.1) — é essa resposta que decide entre uma instância por tenant e uma compartilhada por namespace, e partir errado esvazia a visão de admin em silêncio. Faltam também retenção por tabela oms_* (§9.2) e backup (§9.4), que são entradas obrigatórias antes da primeira provisão. O bloco oms em si (§8.3) e a migração (§8.4) seguem sem aval.

EMENDA (2026-09-10, dono da plataforma): o OMS SAIU DA FILA — "não vai ser mais usada por ora". A consequência prática é que a pergunta do §9.1 deixa de ser ação pendente: ela existia para escolher o escopo antes da primeira provisão, e não há primeira provisão no horizonte. O mesmo vale para retenção (§9.2) e backup (§9.4). Nada disso fica resolvido — fica estacionado, e volta junto com o OMS se ele voltar. O QuestDBInstance permanece no catálogo (ADR-0021) e agora sem consumidor, o que é estado deliberado e não dívida: a decisão de 2026-09-03 foi oferecê-lo "como o Postgres e Redis", independente do OMS.

O do Risk Ops também não é o que parecia. São 2 containers (risk-ops-tool:5000 + risk-analysis-api:5001) falando por URL_RISK_API=http://localhost:5001/..., e um Pod do Kubernetes faz exatamente isso — o localhost continuaria funcionando sem tocar em env var nenhuma. O que falta é que spec.placement.image é um {repository, tag}, e é esse o campo que a promoção patcha: duas imagens numa Colocação mexem no caminho de promoção de toda a plataforma. Some a isso que as duas imagens rodam :latest, que os charts recusam por princípio. É o bloco mais VIVO dos quatro (8 de 10 tenants).

---

Tron

O aviator-binary é serviço com porta, não artefato de build — pergunta aberta desde 2026-08-31, respondida em 2026-09-02 lendo a configuração da própria imagem no OCIR (prophub/tron-aviator-binary:11889aa, 11 camadas, 21,5 MiB):

Campo	Valor
ExposedPorts	80/tcp
Entrypoint / Cmd	/docker-entrypoint.sh · nginx -g daemon off;
Última camada	COPY /app/apps/binary/dist /usr/share/nginx/html
Config	COPY apps/binary/nginx.conf /etc/nginx/templates/default.conf.template
Env	BACKEND_HOST=127.0.0.1:8791, NGINX_ENVSUBST_FILTER=BACKEND_HOST

É um nginx servindo SPA estática e fazendo proxy para um backend. Duas consequências:

1. A coluna "Imagem ECR = Repositório" mente nesta linha. Não existe repositório quanthubbr/tron-aviator-binary (HTTP 404), e nenhum repo da org builda essa imagem: tron-aviator builda tron-aviator e tron-aviator-backend builda tron-aviator-backend — conferido nos ci.yml dos dois. O COPY /app/apps/binary/ e o build-arg APP=binary denunciam um monorepo com layout apps/<nome>, e o tron-aviator não é um (é Vite single-app, com src/ e Dockerfile na raiz). Origem não identificada — mesma família de nuntius-bookkeeper, profit-split-engine, risk-analysis-api e aws-dashboard, cujos nomes de imagem também não resolvem em repositório da org.
2. NÃO é sidecar — medido na task definition tron-aviator-binary:33 em 2026-09-02, depois de a suspeita ter sido levantada pelo default BACKEND_HOST=127.0.0.1:8791 da imagem. A task tem um container só, porta 80, target group próprio no ALB (tron-aviator-binary-tg), desiredCount: 1 e 1 rodando. E a task definition não declara nenhuma env var — ou seja, o BACKEND_HOST fica no default da imagem sem que exista nada em 127.0.0.1:8791: é resíduo, não configuração. Não há o bloqueio do risk-ops aqui; o que falta para tratá-lo como bloco é só saber quem o builda.

---

Fora do ECS — host trading-hub-01 (EC2, Docker Compose)

QuestDB e Caddy também rodam nesse host, mas são software de terceiros, sem repositório próprio.

---

Sites públicos

---

Plataforma nova (Kubernetes / OCI, RFC-0005)

A estrutura são DOIS repositórios — corrigido em 2026-09-02 (A0). Esta seção listava sete, e a fase 1 da RFC-0009 é sobre exatamente estes:

Os outros cinco plat-eng-* que esta seção listava não são estrutura, e é justamente por isso que a fase 0 existe: cada um deles viraria uma linha errada na tabela STACKS.

Aplicações da plataforma nova (a stack interno)

O que roda no cluster OKE hoje, fora de tenant. É este conjunto que a fase 1 da RFC-0009 rotula com prophub.tech/stack=interno — lido do cluster em 2026-09-02 e relido em 2026-09-11, quando apareceram duas Colocações novas:

O RE Dashboard pertence a este conjunto por natureza (A2), mas continua no ECS — não tem Colocação, e por isso não entra no backfill de label da fase 1.

As duas novas, registradas por register() em 2026-09-08 (oci-dashboard) e 2026-09-09 (sec-seal). Ambas com o conjunto completo de labels, auto-deploy: true, deploy-branch: main e — o que importa — segredo pelo caminho certo (contract.env.fromSecret + secretKeys), não em placement.env.vars. Ambas já nasceram com o build-and-deploy.yml da RFC-0011.

Duas observações que só o cluster conta:

• O sec-seal é forma api (porta 8080, health /api/status), tem Postgres e Redis próprios, e já promoveu pelo caminho novo — tag de 7 caracteres e reason: promoção via CI … de build-and-deploy.
• O oci-dashboard é forma web (porta 3000, /api/health) e nunca promoveu: a tag no ar é o SHA de 40 caracteres gravado no registro, com changed-at igual ao creationTimestamp. Não é defeito — é que não houve push em main desde o onboarding. Consequência para quem conta: o runbook da RFC-0011 fala de "os quatro deployables", e já são seis.
• Os secretKeys do oci-dashboard incluem AUTH_ADMIN_PASSWORD_HASH, que é exatamente a chave do incidente do devops-dashboard de 2026-08-25 (bcrypt de 60 chars vs base64/SHA-256 de 44; bcryptjs devolve false sem lançar, e fica tudo verde com o admin sem entrar). Vale conferir o FORMATO do valor no Vault antes que alguém descubra pelo caminho difícil.

---

Lista canônica de tenants (A4)

A lista nominal não existia em lugar nenhum — o inventário contava clusters por aplicação (15 Backoffice, 15 Front, 13 Risk Engine, 10 Risk Ops, 7 BI) e o resumo da RFC-0008 falava em 16 tenants, mas ninguém nunca escreveu quais. É contra esta tabela que a tela de conformidade da RFC-0009 compara; sem ela a tela não tem o que mostrar. Levantada em 2026-09-02, nas duas plataformas.

No cluster OKE — a fonte da verdade são os TenantNamespace

Lido em 2026-09-02. Esta parte é canônica por construção: o objeto no cluster É a lista, não uma cópia dela.

Tenant com datastore e zero aplicação é a forma que custa dinheiro em silêncio. oci-bv-data é reclaimPolicy: Retain: o block volume da OCI continua alocado mesmo depois de o PV sumir, e nada no ArgoCD ou no Crossplane sinaliza. Foi assim que 350 GiB ficaram alocados sem dono até 2026-08-31. Mostrar isto sem ninguém ir procurar é exatamente o que motivou a RFC-0009 — é a checagem 5 do runbook da fase 1.

No ECS — a lista nominal, enfim

Levantada em 2026-09-02 com aws ecs list-clusters + list-services na conta 025910518967 / sa-east-1, e o domínio lido do DIRECTUS_URL da task definition de cada -bsvc. Nada aqui foi inferido de nome de serviço — foi essa inferência que produziu as 15 task defs <tenant>-rd todas apontando para o Directus do blueberry.

São 18 clusters: 15 de tenant, 3 que não são (tron-ecs, re-dashboard-ecs, quanthub).

Os 11 clientes

Os 3 ambientes internos que têm forma de tenant

Domínio interno (quanth.uk / prophub.tech) é o que os separa dos clientes:

Cuidado com a colisão de nome: o demo do ECS não é o tenant demo do cluster OKE. São ambientes diferentes, em plataformas diferentes, com domínios diferentes (demo-b.prophub.tech × prophub.tech).

O que os números fecham — e o que não

As contagens do topo deste inventário batem exatamente, o que confirma o método: 13 Risk Engine, 10 Risk Ops, 7 BI, 4 PropManager Admin (dev, demo, euro, blueberry).

Duas divergências, ambas registradas em vez de ajustadas:

1. Backoffice: contei 14 serviços -bsvc, o inventário dizia 15. São 15 clusters de tenant, mas o 5p não tem Backoffice — só OMS. A leitura provável é que a contagem antiga tenha sido de clusters, não de serviços; não corrigi o número original sem confirmar. E o inventário falava em 19 clusters: hoje são 18, então um sumiu desde 2026-08-31.
2. "Dois tenants sem Risk Engine" era um, mais o cluster que sumiu. Hoje só o elliotplay tem Backoffice sem Risk Engine (e sem Risk Ops e sem BI: é o tenant mais enxuto da frota).

PUBLIC_URL continua não derivável — e agora são três, não dois

Medido nos 14: 11 apontam para o host do Backoffice, e 3 para o do portal — neoprop (dashboard.npfunded.com), orbit (dashboard.orbitfunded.com) e dev (frontend-dev.quanth.uk). A RFC-0008 media 2 em 11; o terceiro apareceu ao cobrir a frota inteira. Derivar PUBLIC_URL sobrescreveria a configuração de três ambientes em produção, com o sintoma sendo link de e-mail apontando para o lugar errado — que ninguém vê num deploy verde.

---

Actions e tooling compartilhado

---

Observabilidade e QA

---

Resumo

Cinco aplicações formavam o stack padrão de todo cliente novo: Backoffice, Front do trader, Risk Engine, Risk Ops e BI. Backoffice e Front estão nos 15 clusters de cliente; Risk Engine em 13.

Para cliente NOVO isso mudou em 2026-09-10: Risk Ops e BI saem da composição padrão e o PropManager Admin entra na stack prophub no lugar dos dois. As contagens acima descrevem a frota como ela está, não como o próximo cliente será montado — os dois blocos seguem no catálogo porque há cliente usando (emenda na seção de ferramentas internas).

Dois repositórios concentram desproporcionalmente a operação: risk-engine-csharp (sete imagens, todos os conectores de corretora) e risk-ops-tool (três containers na mesma task). Mudança em qualquer um deles tem alcance amplo.

O que a fase 0 deixou em aberto

Nenhum destes foi preenchido por suposição — cada um espera um fato que ainda não existe: