Planuze
Opções

Do modelo ao backend.O código é seu.

Descreva o que precisa, revise a proposta e aprove o código antes que ele chegue ao seu projeto.

  • Versão estável
  • Download oficial
  • Atualizações pelo app

O agente modela e gera o código. Você aprova cada diff.

  1. Você pede: Preciso de faturas com itens, ligadas ao cliente.
  2. Ele propõe o modelo: Duas coleções, uma relação e uma rota de listagem.
  3. Ele aplica pelo editor: Aplicado. As coleções já estão na árvore do módulo.
  4. Você aprova o diff: 8 arquivos para escrever. Nenhum existente será sobrescrito.
  5. O que aparece no seu projeto: schema, migration, model, validator. Arquivo comum no seu disco: abre no seu editor, entra no seu commit, roda sem o Planuze instalado.

Agente de IA

O agente modela e gera o código. Você aprova cada diff.

Descreva o que precisa, acompanhe a proposta e decida o que chega ao projeto.

Exemplo ilustrativo: conversa e aprovação de diff
  1. 1

    Preciso de faturas com itens, ligadas ao cliente.

  2. 2

    Duas coleções, uma relação e uma rota de listagem.

  3. 3

    Aplicado. As coleções já estão na árvore do módulo.

  4. 4

    8 arquivos para escrever. Nenhum existente será sobrescrito.

  1. 1

    Você pede

    Descreva o que precisa em uma frase.

  2. 2

    Ele propõe o modelo

    Organiza a solução antes de fazer mudanças.

    • describe_project
  3. 3

    Ele aplica pelo editor

    Transforma a proposta em arquivos do projeto.

    • create_collection
    • add_column
    • create_relation
    • set_route
  4. 4

    Você aprova o diff

    Você confere tudo antes de salvar.

    • generate

Você escolhe o provedor de IA — inclusive um local.

O que você constrói

O editor fala de domínio, não de backend

Coleções, colunas, relações e rotas servem qualquer sistema com dados. Os quatro abaixo são modelagens; o pack escolhido gera o backend delas.

  • Vendas e relacionamento

    Clientes, o que está em negociação e o histórico de cada conversa.

    4Coleções que você declara

    • customer
    • deal
    • activity
    • note
  • Estoque e catálogo

    Produtos com variação, onde cada um está e toda movimentação.

    4Coleções que você declara

    • product
    • variant
    • warehouse
    • stock_movement
  • Agendamento

    Quem atende, o que oferece e o que já foi marcado.

    4Coleções que você declara

    • professional
    • service
    • appointment
    • availability
  • Portal interno

    Pessoas, áreas e os pedidos que passam por aprovação.

    4Coleções que você declara

    • employee
    • department
    • request
    • approval

Nenhum desses exemplos vem pronto: o pack transforma o que você declarou em código.

Quatro peças, e o vocabulário vem do pack

  • Modelagem declarativa

    Coleções, colunas e rotas viram JSON versionado dentro do projeto.

  • Geração com aprovação de diff

    Nenhuma escrita no seu disco sem um diff que você aprova.

  • Um agente que opera o editor

    Ele chama as operações do editor em vez de improvisar arquitetura.

  • Packs assinados

    A stack, o vocabulário e o gerador saem do pack instalado.

Do modelo ao disco

Você declara a coleção. O backend aparece como arquivo.

O que você modela no editor vira arquivos comuns, prontos para revisar e versionar.

O que você declara

O editor de coleção do Planuze, com uma coleção de exemplo aberta.

  1. numberstring
  2. totaldecimal
  3. paidboolean
  4. customer_idstring

O arquivo que o editor salva

planuze/api/invoice/schema.json

{ "schemaVersion": 1, "id": "invoice", "name": "invoice", "columns": [ { "id": "c1", "name": "number", "type": "string", "unique": true }, { "id": "c2", "name": "total", "type": "decimal", "precision": 12, "scale": 2 }, { "id": "c3", "name": "paid", "type": "boolean", "default": false }, { "id": "c4", "name": "customer_id", "type": "string", "indexed": true } ], "relations": [ { "id": "r1", "name": "customer", "kind": "many-to-one", "target": { "kind": "collection", "id": "customer" }, "fkColumn": { "kind": "column", "collectionId": "invoice", "columnId": "c4" }, "targetColumn": { "kind": "column", "collectionId": "customer", "columnId": "c1" } } ], "routes": [ { "id": "rt1", "type": "index", "enabled": true }, { "id": "rt2", "type": "store", "auth": true, "enabled": true } ]}

O que aparece no seu projeto

  1. schema

    Schema do banco, na linguagem do ORM do pack.

  2. migration

    Migration versionada, do estado atual para o novo.

  3. model

    Model tipado, com as relações resolvidas.

  4. validator

    Validador de entrada, derivado das regras de cada coluna.

  5. controller

    Controller com as operações da rota configurada.

  6. route

    Registro da rota na API, pronto para receber requisição.

Arquivo comum no seu disco: abre no seu editor, entra no seu commit, roda sem o Planuze instalado.

Do download até esses arquivos

  1. Entre com um código no e-mail, GitHub ou Google. Plano e provedor de IA podem ficar para depois.
  2. Instale um pack e crie o projeto: você escolhe a pasta no seu disco.
  3. Declare a coleção e peça a geração: você lê o diff, aprova, e os arquivos aparecem na pasta.
Escolher download

Sem trava

O código gerado é seu, e continua seu se você sair

Código-fonte comum, com as dependências que você já conhece. Não há camada nossa entre o seu backend e a sua produção.

  1. No seu disco, desde o primeiro arquivo

    A geração escreve no diretório que você escolheu. Sem upload, sem workspace na nuvem.

  2. Versionável como qualquer código

    Arquivos declarativos e código gerado entram no mesmo commit. Diff, blame e revert funcionam.

  3. Você faz deploy do seu jeito

    Container, VM, serverless, o pipeline que já existe. Nada de infraestrutura nossa para subir.

  4. Sair não quebra nada

    Desinstale e o projeto continua compilando e rodando. Você perde a ferramenta, não o produto.

O que não existe no caminho

  • Nenhum runtime proprietário em produção
  • Nenhuma chamada obrigatória a servidor nosso para o backend funcionar
  • Nenhum formato fechado — os arquivos declarativos são JSON legível
  • Nenhum lock-in de banco: o pack escolhe o ORM, e você escolhe o pack

Packs

A stack vem do pack que você escolher

Escolha como o backend será gerado sem prender o projeto a uma única stack.

  1. declarations

    Tudo começa com o pack

    Ele reúne os tipos, relações, rotas e validadores que você usa para modelar o projeto.

  2. signatureAlgorithm

    Instalação verificada

    A assinatura e cada arquivo são conferidos antes de o pack ser instalado.

  3. stack

    Troque de stack com outro pack

    Linguagem, banco e ORM mudam com o pack, enquanto os arquivos do seu projeto continuam no mesmo lugar.

  4. distribution

    Publique packs para sua equipe

    Empacote e assine pelo CLI sem tirar a chave privada da sua máquina.

Explore no app os packs disponíveis e as opções incluídas na sua licença.

Organizações

Uma organização não é uma conta compartilhada

Cada pessoa tem a própria conta e o próprio assento. Toda ação de administração fica registrada com autor e data.

Papéis claros para cada pessoa
Dono, administrador e membro têm permissões próprias. Ninguém entra automaticamente pelo domínio de e-mail.
Assentos que acompanham o time
Use os assentos incluídos no plano e ajuste a quantidade quando o time mudar.
Packs privados para a organização
Compartilhe packs só com as pessoas autorizadas; o acesso termina quando elas deixam a organização.
Histórico das ações administrativas
Convites, remoções e transferências ficam registrados com autor e data, com exportação em CSV ou JSON.

Gerencie pessoas, assentos e auditoria no painel da organização dentro do Planuze.

Onde o seu dado fica, e o que o app manda para fora

Seu projeto permanece local. Quando o app usa a rede, você sabe para quê.

  1. O projeto fica na pasta que você escolheu

    Você aponta um diretório e o Planuze escreve nele: declarações, schema de cada coleção e código gerado. O histórico do agente fica na pasta de dados do app, também na sua máquina. Não existe workspace na nuvem.

  2. As chaves vão para o chaveiro do sistema

    Chaves de API e tokens ficam protegidos pelo chaveiro do sistema. Se ele não estiver disponível, o app não guarda esses dados em texto aberto.

  3. Você escolhe o provedor de IA, inclusive um local

    Use Anthropic, OpenAI, Gemini, Ollama ou outro provedor compatível. Com o Ollama, a conversa fica na sua máquina; com um provedor remoto, o app se conecta direto usando a sua chave, sem proxy nosso.

  4. Não há analytics de uso

    Nenhum evento de comportamento ou métrica de uso é coletado. Apenas relatórios de falha são enviados, com chaves, tokens e e-mails filtrados.

O que sai da máquina, e por quê
  • Login e renovação de sessão: seu e-mail e o código de acesso, ou o retorno do login social.
  • Verificação de licença, de poucas em poucas horas: o token da licença e o identificador do dispositivo — não o seu projeto.
  • A checagem de atualização (sistema operacional, arquitetura, canal e versão instalada) e o instalador, quando há versão nova.
  • O catálogo do marketplace, a documentação e o download de cada pack que você instala — o registro da instalação inclui o caminho do projeto.
  • A lista de packs instalados, quando você manda o app checar se há atualização deles.
  • A conversa com o provedor de IA remoto que você escolheu, com a sua chave: inclui o que o agente leu do projeto para responder e o caminho da pasta de trabalho. Com provedor local, nada disso sai.
  • O conteúdo de um arquivo, se você pedir para a IA resolver um conflito de edição durante a geração.
  • Sua chave de API, quando você testa a conexão ou pede a lista de modelos de um provedor de nuvem — essa ida passa pelo nosso servidor.
  • O checkout e a assinatura: o formulário de pagamento é da Stripe, roda dentro do app e fala direto com ela, inclusive a telemetria do SDK dela.
  • O relatório de falha, quando o app quebra.
  • O que você escrever no chat de suporte, os anexos que mandar e a foto de perfil que escolher.
  • As notificações da sua conta, a Ajuda e as notas de versão — e, se você usa organização ou publica packs, o que você faz nessas telas.

Um provedor local mantém as conversas com a IA na sua máquina.

O que costumam perguntar antes de baixar

  • O Planuze substitui o meu backend ou gera um?

    Gera. O que sai é um projeto que você abre no seu editor, roda com as ferramentas que já usa e leva para a sua produção — o Planuze fica de fora do que você publicou.

  • Serve para a minha stack?

    Depende do pack disponível. Cada pack define a stack e a forma de geração; você escolhe no app o que combina com o seu projeto.

  • A geração sobrescreve o código que eu escrevi à mão?

    Não. Antes de qualquer arquivo ser escrito, você revisa o diff e aprova as mudanças arquivo por arquivo.

  • O que acontece com o meu modelo se eu trocar de pack?

    Seu modelo continua versionado no projeto. Ao trocar de pack, você muda a stack e a forma de geração, sem perder o que já declarou.

  • Preciso de conexão para trabalhar?

    Você pode modelar e gerar offline. A conexão é usada para entrar, verificar a licença, instalar packs e acessar um provedor de IA remoto. Com um provedor local, o agente também funciona offline.

  • Preciso criar conta?

    Sim, e ela é gratuita: você entra com um código enviado ao seu e-mail, ou pelo GitHub ou Google, e não há senha para criar. Escolher plano e configurar o provedor de IA são passos que você pode pular e resolver depois.

  • Preciso pagar para modelar e gerar?

    Não. Modelar e gerar não dependem de plano pago. Os planos diferem nos recursos do agente de IA, histórico de sessão, assentos da organização e packs privados.

  • Como funciona a licença?

    A licença vale para o seu perfil. Nos times, a organização reúne os assentos e controla quem pode acessar os packs privados.

Modele uma coleção e veja o backend aparecer.

Instalação local e conta gratuita. O que for gerado fica no seu disco.

Escolha o download que combina com sua máquina.

Confira a arquitetura e o formato quando houver mais de uma opção.

Outros canais de atualização

Beta e Canary antecipam novidades, mas podem conter instabilidades. Use-os quando for possível voltar à versão estável.

BetaNovidades quase prontas, em validação final.

CanaryMudanças mais recentes, com maior chance de instabilidade.