Open-source software factory

Jumentix

The Jumentix mark comes from the Brazilian jegue: steady, practical, resilient. The platform carries enterprise Node.js architecture from the first modular monolith to an unlimited service landscape.

The animal is the promise: less ceremony, more load-bearing software.

Start building Explore the platform

99% quality threshold
DDD + Hexagonal
Bun monorepo
Open source

Jumentix carries the load

A practical mascot for practical architecture

The jegue is part of the product language: dependable movement, strong footing, and no drama when the terrain changes. Jumentix applies that to visual domain design, contract-first runtimes, reusable adapters, developer automation, and deployment governance.

12+HTTP and function adapters

10+persistence targets

3API interface styles

99%coverage standard

Architecture you can see

Design bounded contexts as a living system

The Domain Designer turns domains, entities, fields, validation, and relationships into a navigable model. The same contracts guide code generation and API documentation.

See the product Architecture docs

Jumentix Domain Designer displaying bounded contexts and entity relationships — The real Jumentix Domain Designer interface.

Code is part of the product

Start locally. Keep every production option open.

The same application contracts work across a modular monolith, realtime server, functions, and distributed services.

bun install
bun run cli
bun run dev:express

Bun-powered tooling

The fast path is the default path

Jumentix standardizes on Bun as the pinned monorepo runtime, package manager, script runner, test runner and browser-spec bundler. That keeps local work, CI gates, package checks and website publishing on one toolchain.

Why Bun matters here

The repository uses Bun where it actually reduces friction: fast installs with workspaces, direct TypeScript execution, repeatable package scripts, focused branch gates, and browser-test bundling before Cypress runs against real IndexedDB and DOM APIs.

One pinned version, `bun@1.3.13`, protects every workspace from “works on my machine” drift.
`bun run --filter` lets package checks stay scoped while full gates remain available for release work.
Bun bundles Cana browser specs before Cypress, avoiding Cypress webpack fragility while preserving real-browser evidence.
The same CLI drives local dev, docs sync, package dry-runs, security checks and production website publishing.

See Jumentix scripts Bun docs

bun install
bun run website:dev
bun run ci:affected

1runtime/package/test/bundle tool

1.3.13+pinned Bun version

3workspace roots: apps, packages, tooling

30xofficial Bun install-speed ceiling vs npm

Quality as product surface

Requirements, tests and evidence are not hidden plumbing

Jumentix treats quality as part of the user-facing promise. Requirements are checked, tests are mapped, architecture rules are executable, and publish paths carry evidence instead of relying on ceremony.

99/90statement/branch quality standard

reqsrequirements tied to executable checks

0tolerance for hidden docs drift

realbrowser tests for browser APIs

Requirement registry

Delivery work is expected to connect behavior, docs, tests and release evidence so “done” is auditable.

requirements:check

Reliable tests

Unit, integration, Cypress route sweeps, browser specs and Storybook smoke checks cover the surface each layer actually owns.

test-map:check

Executable architecture

Boundary scripts reject imports and shortcuts that would leak frameworks, databases or infrastructure into domain code.

arch:check-*

Publish discipline

Content sync, route checks, package dry-runs and release governance run before public artifacts move.

website:test:prepublish

bun run requirements:check
bun run docs:consumers:package-scripts
bun run website:test:prepublish

AI-ready platform

The UI gives agents architecture with governance attached

Jumentix is prepared for AI because the product does not ask agents to infer architecture from scattered code. The UI captures bounded contexts, entities, interfaces, deployment profiles and requirements; the repository exposes agent-readable docs and executable checks that keep generated work accountable.

UIdomain model as first-class input

llmsagent-readable website context

reqsrequirements tied to checks

gatesarchitecture and publish evidence

1. Model service

UI captures the domain

Category, Task, relationships, validations and API surfaces become explicit platform data.

2. Ground the agent

Docs and packages name the path

The agent reads the docs index, package contracts and UI blueprint before choosing files to change.

3. Generate inside boundaries

Ports and adapters shape the code

Use-cases, controllers, SDK clients, Cana examples and runtime profiles keep their ownership boundaries.

4. Verify evidence

Governance checks catch drift

Requirements, test maps, architecture scripts, route checks and prepublish gates validate the change.

5. Publish with confidence

PR carries proof

Reviewers see what changed, why it fits the architecture and which checks prove it is ready.

Low-context instructions

Agents can start from docs index, package pages, route metadata and code snippets instead of guessing which file owns a behavior.

/llms-full.txt

UI as architecture input

The Service Management UI turns product concepts into bounded contexts, interfaces and deployment choices that generators and reviewers can inspect.

service-management-ui

Governed generation

Generated or agent-authored changes still pass requirements, test maps, route checks, package boundaries and release governance before publication.

requirements:check

Grounded package graph

Reusable packages give AI work stable names for persistence, mediation, clients, Cana, runtime bootstrap and architecture boundaries.

packages/*

AI work becomes governed delivery

The UI gives AI a constrained starting point: the service vocabulary, boundaries, interfaces, runtime profile and quality obligations are explicit before a prompt is written. That turns the agent from a code guesser into a contributor working inside the platform rules.

Prompts reference named bounded contexts, entities, requirements and packages instead of broad implementation wishes.
Generated code has a known landing zone: UI model, contracts, SDKs, use-cases, adapters, tests and docs.
Reviewers can reject drift with executable checks instead of relying only on manual architecture review.

AI action	UI source	Governance guardrail	Useful output
Design safely	Bounded context, entities, relationships and requirements.	Service model validation and requirement registry.	A service spec that product, architecture and engineering can review together.
Generate safely	Interfaces, events, deployment profile and package choices.	OpenAPI, AsyncAPI, route checks and workspace boundaries.	Contracts, SDKs, handlers and examples aligned to the same model.
Ship with evidence	Quality expectations, release path and docs index.	Test map, architecture checks, docs sync and prepublish gates.	A PR reviewers can audit with concrete proof instead of narrative confidence.

{
  "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"
  ]
}

Choose a delivery path

Jumentix is for teams that want framework speed without surrendering domain ownership, portability, or operational evidence.

Build the product. Keep the architecture.

Explore the source, run the factory locally, and turn your next Node.js service into a repeatable platform capability.

Read the docs GitHub