Plataforma

Visão geral dos principais blocos da plataforma (projetos, módulos, entidades, UI, dashboards, regras e permissões).

Madrix é uma plataforma para desenhar, gerar e operar apps corporativos com IA.

Use esta página como mapa mental. Ela te ajuda a navegar pelos blocos e fluxos.

Atalhos:

• Gere e itere no chat: Modo Chat AI

• Ajustes avançados (backend + scaffold): Modo Editor

• Settings do projeto: Configurações do Projeto

• Settings do runtime (segurança, auth, etc): Configurações do Runtime

• Conectar com seu stack: Integrações

Fluxo end-to-end (o “caminho feliz”)

1. Login na plataforma.

2. Abrir a Home.

3. Entrar em Projetos e criar/selecionar um projeto.

4. Gerar e evoluir via Chat AI (com checkpoints de aprovação).

5. Testar no Preview com Executar.

6. Fazer deploy com Publicar (quando quiser Cloud).

Se você quer o passo a passo com prompt pronto: Comece aqui.

Mapa da interface (onde fica o quê)

Login

Entrada da plataforma. Depois do login, você cai na Home.

Home

Ponto de partida. Normalmente você faz:

• Selecionar um projeto recente.

• Criar um novo projeto.

• Abrir configurações globais (usuário/organização).

Projetos

Um Projeto é o “container” do seu app. Ele guarda:

• Estrutura (módulos, entidades/componentes, campos, scripts).

• UI gerada (telas, rotas, menus).

• Configurações e ambientes.

Editor de Projetos (barra superior)

É a área onde você alterna entre gerar e editar.

Itens comuns:

• Nome do projeto

• Troca de modo: Chat AI ↔ Editor

• Executar: abre/atualiza o Preview do app

• Publicar: faz deploy para ambiente Cloud (quando configurado)

• Home: volta para a Home

• Notificações

• Configurações do usuário/organização

Configurações do Usuário / Organização

Onde ficam preferências e contexto de organização (ex: permissões, acesso, etc).

Idioma selecionado

Controla textos da interface. Também conversa com traduções como pt-BR, en, etc.

Conceitos essenciais (definições curtas)

• Projeto: o app inteiro (código, dados, configurações e deploy).

• Módulo: um domínio funcional (ex: Vendas, Tarefas, Financeiro).

• Entidade / Componente: seu “objeto” principal (vira tabela no banco).

• Campo: atributo da entidade (tipo, obrigatório, único, picklist, etc).

• Relacionamento: conexão entre entidades (1-N, N-N).

• Script: regra de negócio no backend (ex: validação e automação).

• UI: telas, rotas, menus e formulários gerados.

• Dashboard / Relatório: visão gerencial e análises.

• Permissões (RBAC): quem pode ver/fazer o quê.

Como a IA gera sistemas no Madrix (modelo mental)

O fluxo tende a ser este:

1. Você descreve objetivo, entidades e regras no prompt.

2. A plataforma gera uma especificação para você aprovar.

3. Após aprovação, agentes geram backend + UI + recursos do projeto.

4. Você testa no Preview e pede mudanças incrementais.

Dica prática: trate a especificação como “contrato”. Ela reduz retrabalho.

Fluxos comuns (quando usar cada modo)

Chat AI (mudanças grandes e iterativas)

Use quando você quer:

• Criar um app do zero.

• Adicionar módulos e entidades inteiros.

• Refatorar regras ou fluxos.

• Pedir mudanças em “linguagem de negócio”.

Abrir: Modo Chat AI

Editor (ajuste “cirúrgico” e controle fino)

Use quando você quer:

• Ajustar campos, relacionamentos, menus e scripts por evento.

• Entender o scaffold do frontend gerado.

• Resolver detalhes que o chat não fechou bem.

Abrir: Modo Editor

AWUs (Agentic Work Units)

AWU é a unidade de consumo para trabalho agêntico. Na prática, ele cresce com:

• Escopo do pedido (quantidade de módulos/entidades/telas).

• Número de iterações (mudanças que reescrevem muito).

• Complexidade de regras, integrações e permissões.

Boas práticas para consumir menos:

• Comece com um prompt menor e evolua em passos.

• Aprove a especificação antes de gerar.

• Faça mudanças por “lotes” pequenos e testáveis.

Mudança ampla e vaga (“refaça tudo”) costuma gastar mais e quebrar mais coisas.

Limits (limites, boas práticas e anti-padrões)

Use como guardrail para ter mais previsibilidade.

Boas práticas:

• Escreva prompts com objetivo + entidades + regras.

• Prefira nomes consistentes. Evite sinônimos para a mesma coisa.

• Peça mudanças em formato de checklist. Isso reduz ambiguidade.

• Teste no Preview logo após cada lote de mudanças.

Anti-padrões:

• Pedir “um ERP completo” em um único prompt.

• Misturar muitos domínios no mesmo primeiro passo.

• Trocar nomes e estruturas “em massa” sem validar impacto.

• Fazer deploy sem validar o Preview e as permissões básicas.

Próximos passos

• Quer aprender fazendo: Tutoriais Práticos

• Quer ver casos reais: Demonstrações

• Travou em algo: Solução de problemas