Fábrica de software open source

Jumentix

A marca Jumentix vem do jegue brasileiro: firme, prático e resistente. A plataforma carrega a arquitetura Node.js enterprise do primeiro monólito modular a um ecossistema ilimitado de serviços.

O animal é a promessa: menos cerimônia, mais software que aguenta carga.

Comece a construir Explore a plataforma

99% quality threshold
DDD + Hexagonal
Bun monorepo
Open source

Jumentix carrega a carga

Uma mascote prática para uma arquitetura prática

O jegue faz parte da linguagem do produto: avanço confiável, pé firme e pouca cerimônia quando o terreno muda. O Jumentix aplica isso a design visual de domínios, runtimes orientados a contratos, adaptadores reutilizáveis, automação de desenvolvimento e governança de deploy.

12+adaptadores HTTP e functions

10+destinos de persistência

3estilos de interface de API

99%padrão de cobertura

Arquitetura que você pode ver

Projete contextos delimitados como um sistema vivo

O Domain Designer transforma domínios, entidades, campos, validações e relacionamentos em um modelo navegável. Os mesmos contratos orientam geração de código e documentação de API.

Veja o produto Docs de arquitetura

Domain Designer do Jumentix exibindo contextos delimitados e relações entre entidades — O Domain Designer como ele é hoje.

Código faz parte do produto

Comece localmente. Mantenha todas as opções de produção abertas.

Os mesmos contratos de aplicação funcionam em monólito modular, servidor em tempo real, functions e serviços distribuídos.

npx @jumentix/cli-init init my-product
cd my-product
bun install
bun run dev

Tooling movido a Bun

O caminho rápido é o caminho padrão

Todo projeto gerado pelo CLI Jumentix roda em Bun: uma ferramenta pinada é runtime, gerenciador de pacotes, executor de scripts e test runner, então seu notebook e seu CI rodam a mesma coisa.

Por que Bun importa aqui

Bun elimina o setup que um projeto novo costuma exigir: workspaces instalam rápido, TypeScript roda sem etapa de build em desenvolvimento e um único conjunto de scripts cobre todos os apps do projeto.

Projetos gerados pinam `bun@1.4.2` em `packageManager`, então toda máquina roda a mesma versão.
`bun run dev`, `test`, `lint` e `build` rodam em todos os apps do workspace.
Serviços backend sobem direto do código TypeScript em desenvolvimento.
`jumentix add`, `upgrade` e `doctor` fazem o projeto crescer e seguir atualizado depois do primeiro dia.

Referência do CLI Bun docs

npx @jumentix/cli-init init my-product --mode=hybrid
cd my-product
bun install
bun run dev

1ferramenta de runtime/pacote/teste/bundle

1.4.2+versão Bun pinada

4comandos do CLI: init, add, upgrade, doctor

14xinstall a frio mais rápido vs npm, medido neste monorepo

Falha alto, não em silêncio

`bun run --filter` sai com 1 quando nenhum workspace casa. O equivalente `--if-present` do pnpm saía 0 e já produziu falso-verde aqui antes.

--filter exit 1

Sem build step em desenvolvimento

Serviços backend sobem direto do TypeScript fonte — nada pra recompilar antes de rodar ou testar uma mudança.

no tsc step

Instala sem flag nenhuma

Este monorepo instala limpo no Bun. A mesma árvore precisa de `--legacy-peer-deps` só pra resolver no npm.

zero install flags

Entende `workspace:*` nativamente

npm recusa esta árvore de cara — erro de protocolo não suportado — até cada faixa `workspace:*` ser reescrita na mão.

workspace:*

Um lockfile que dá pra revisar de verdade

`bun.lock` é commitado em texto legível, então uma mudança de dependência aparece como diff de verdade no code review.

bun.lock (text)

Test runner nativo, já medido

`bun test`: 1,72s para 531 testes. Jest: cerca de 28s para as mesmas suites.

bun test 1.72s/531

Bundler incluso

Builds de pacote geram bundles ESM reais sem webpack, rollup ou esbuild como dependência separada — bundling custa milissegundos de um dígito.

bun build

Uma ferramenta, não quatro

Runtime, gerenciador de pacotes, bundler e test runner pinados juntos — a alternativa é quatro ferramentas que podem perder sincronia entre si em silêncio.

1 pinned tool

Um pin de versão acaba com "funciona na minha máquina"

`.bun-version`, `packageManager` e `engines.bun` são checados juntos — uma versão errada falha no install, não no deploy.

.bun-version

Qualidade como superfície do produto

Requisitos, testes e evidências não ficam escondidos

O Jumentix trata qualidade como parte da promessa visível do produto. Requisitos são checados, testes são mapeados, regras de arquitetura são executáveis e caminhos de publicação carregam evidências em vez de depender de cerimônia.

98%cobertura mínima de statements, branches, funções e linhas

reqsrequisitos ligados a checagens executáveis

0tolerância a drift oculto de docs

realtestes browser para APIs browser

Registro de requisitos

O trabalho de entrega conecta comportamento, docs, testes e evidência de release para que “pronto” seja auditável.

requirements:check

Testes confiáveis

Unit, integração, route sweep Cypress, specs de browser e smoke de Storybook cobrem a superfície real de cada camada.

test-map:check

Arquitetura executável

Scripts de limite rejeitam imports e atalhos que vazariam frameworks, bancos ou infraestrutura para o domínio.

arch:check-*

Disciplina de publicação

Sync de conteúdo, checagens de rota, dry-runs de pacote e governança de release rodam antes de artefatos públicos avançarem.

website:test:prepublish

bun run requirements:check
bun run test-map:check
bun run docs:check-audience
bun run website:test:prepublish

Plataforma pronta para AI

A UI entrega arquitetura com governança acoplada

O Jumentix é preparado para AI porque o produto não obriga agentes a inferir arquitetura a partir de código espalhado. A UI captura contextos delimitados, entidades, interfaces, perfis de deploy e requisitos; o repositório expõe docs legíveis por agentes e checagens executáveis que tornam trabalho gerado auditável.

UImodelo de domínio como input de primeira classe

llmscontexto do site legível por agentes

reqsrequisitos ligados a checks

gatesevidência de arquitetura e publish

1. Modele o serviço

A UI captura o domínio

Category, Task, relacionamentos, validações e superfícies de API viram dados explícitos da plataforma.

2. Fundamente o agente

Docs e pacotes nomeiam o caminho

O agente lê índice de docs, contratos de pacote e blueprint da UI antes de escolher arquivos para alterar.

3. Gere dentro dos limites

Ports e adapters moldam o código

Casos de uso, controllers, SDKs, exemplos Cana e perfis de runtime preservam seus limites de ownership.

4. Verifique evidências

Checks de governança capturam drift

Requisitos, test maps, scripts de arquitetura, checagens de rota e gates prepublish validam a mudança.

5. Publique com confiança

A PR carrega prova

Revisores veem o que mudou, por que cabe na arquitetura e quais checks provam que está pronto.

Instruções de baixo contexto

Agentes podem partir do índice de docs, páginas de pacote, metadados de rotas e snippets de código em vez de adivinhar qual arquivo possui um comportamento.

/llms-full.txt

UI como input de arquitetura

A UI de Service Management transforma conceitos de produto em contextos, interfaces e escolhas de deploy que geradores e revisores conseguem inspecionar.

service-management-ui

Geração governada

Mudanças geradas ou escritas por agentes ainda passam por requisitos, test maps, rotas, limites de pacote e governança de release antes de publicar.

requirements:check

Grafo de pacotes fundamentado

Pacotes reutilizáveis dão ao trabalho de AI nomes estáveis para persistência, mediação, clientes, Cana, bootstrap de runtime e limites arquiteturais.

packages/*

Trabalho de AI vira entrega governada

A UI entrega para a AI um ponto de partida restrito: vocabulário do serviço, limites, interfaces, perfil de runtime e obrigações de qualidade são explícitos antes de qualquer prompt. Isso transforma o agente de um gerador por chute em um contribuidor dentro das regras da plataforma.

Prompts referenciam contextos delimitados, entidades, requisitos e pacotes nomeados em vez de desejos amplos de implementação.
Código gerado tem destino conhecido: modelo da UI, contratos, SDKs, casos de uso, adaptadores, testes e docs.
Revisores podem rejeitar drift com checagens executáveis em vez de depender apenas de review arquitetural manual.

Ação de AI	Fonte da UI	Guarda-corpo de governança	Saída útil
Desenhar com segurança	Contexto delimitado, entidades, relacionamentos e requisitos.	Validação do modelo de serviço e registro de requisitos.	Uma spec de serviço que produto, arquitetura e engenharia revisam juntas.
Gerar com segurança	Interfaces, eventos, perfil de deploy e escolhas de pacote.	OpenAPI, AsyncAPI, checagens de rota e limites de workspace.	Contratos, SDKs, handlers e exemplos alinhados ao mesmo modelo.
Publicar com evidência	Expectativas de qualidade, caminho de release e índice de docs.	Test map, checagens de arquitetura, sync de docs e gates prepublish.	Uma PR que revisores auditam com prova concreta em vez de confiança narrativa.

{
  "boundedContext": "Tasks",
  "entities": [
    { "name": "Category", "fields": ["id", "name", "color"] },
    { "name": "Task", "fields": ["id", "title", "categoryId", "completed"] }
  ],
  "interfaces": ["REST", "WebSocket"],
  "deploymentProfiles": ["dev", "staging", "production"],
  "requirements": ["REQ-TASK-CATEGORY", "REQ-TASK-LIVE-UPDATES"],
  "governanceChecks": [
    "requirements:check",
    "test-map:check",
    "arch:check-workspace-boundaries"
  ]
}

Escolha uma jornada

O Jumentix é para equipes que querem velocidade de framework sem abrir mão da propriedade do domínio, portabilidade ou evidências operacionais.

Construa o produto. Preserve a arquitetura.

Explore o código, execute a fábrica localmente e transforme seu próximo serviço Node.js em uma capacidade repetível de plataforma.

Leia a documentação GitHub