Planuze
Baixar
Abrir menuFechar menu

App desktop para macOS, Windows e Linux

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

Declare coleções, colunas e rotas — no editor ou pedindo ao agente de IA; o backend sai em arquivos de código no seu disco, na stack do pack que você instalar.

Baixar o PlanuzeVer o agente trabalhando
Também para
  • Instalação local: o projeto fica na pasta que você escolher
  • Conta gratuita e sem senha: código no e-mail, GitHub ou Google
  • Modelar e gerar não dependem de plano pago
O editor de coleção do Planuze, com uma coleção de exemplo aberta.
  1. numberstring
  2. totaldecimal
  3. paidboolean
  4. customer_idstring

Agente de IA

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

Ele chama as mesmas operações do editor. Nenhum código vai para o disco sem o seu aval.

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 em português

    Uma frase, como você diria a alguém do time.

  2. 2

    Ele propõe o modelo

    Lê o manifest do pack antes de propor.

    • describe_project
  3. 3

    Ele aplica pelo editor

    As mesmas chamadas que a interface faz.

    • create_collection
    • add_column
    • create_relation
    • set_route
  4. 4

    Você aprova o diff

    A geração chega como diff. Você lê e aprova.

    • generate

Roda no provedor de IA que você configurar — 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 dos quatro vem pronto: são modelagens de exemplo. O que vem pronto é o gerador do pack, que 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.

Nada escondido entre a tela e o disco: o editor grava este arquivo, e é este que o gerador lê.

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.
Baixar o Planuze

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 não é decisão nossa — é declaração do pack

Um pacote assinado que carrega uma stack inteira. O editor e o gerador saem do manifest dele; o núcleo não tem opinião sobre stack nenhuma.

  1. declarations

    O manifest é o vocabulário

    O pack declara quais tipos de coluna, relações, rotas e validadores existem. Sem essa lista o editor não monta nada.

  2. signatureAlgorithm

    Assinado, e conferido antes de instalar

    Manifest e lock de conteúdo assinados em Ed25519, com um SHA-256 por arquivo. Assinatura ausente ou chave não verificada: recusa.

  3. stack

    Outra stack é outro pack, e nada mais

    Linguagem, banco e ORM vêm do manifest do pack instalado, numa linha dele. No núcleo não existe nome de tipo de rota nem de coluna — trocar de stack é instalar outro pack.

  4. distribution

    Publicar o seu é o mesmo caminho, ao contrário

    Você gera o par de chaves, empacota e assina pelo CLI — a chave privada não sai da sua máquina. O registry reverifica antes do catálogo.

O catálogo de packs vive dentro do app e muda com o tempo. Preço e acesso de cada um são resolvidos pela sua licença, na hora de instalar.

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.

Três papéis, conferidos no servidor
Dono, administrador e membro. Cada ação passa pela matriz de permissão do servidor, e não existe adesão automática por domínio de e-mail.
Assentos inclusos, e excedente por assento
Contratar acima dos inclusos cobra a diferença na hora; reduzir vira crédito na fatura seguinte. O assento do dono sustenta a licença e não é liberável.
Packs que só a sua organização vê
Um pack da organização fica visível só para quem você autorizar. Quem sai perde o acesso: a filiação é consultada a cada listagem e a cada download.
Um registro de quem fez o quê
Convite, remoção de membro e transferência de propriedade ficam gravados com autor e data, na mesma transação. A trilha sai em CSV ou JSON.

Pessoas, assentos e auditoria ficam no painel da organização, dentro do próprio Planuze — sem portal web à parte.

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

Quatro fatos sobre onde as coisas ficam, e o inventário completo do que sai da máquina, com o motivo de cada saída.

  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, token de licença e refresh token ficam num cofre cifrado pelo safeStorage do Electron — Keychain, DPAPI, libsecret. Sem chaveiro disponível, a versão de produção falha em vez de gravar em texto claro. A janela do app não guarda segredo.

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

    Anthropic, OpenAI, Gemini, Ollama ou qualquer endpoint que fale a API da OpenAI. Com o Ollama a inferência roda na sua máquina, sem chave e sem rede. Com provedor remoto, o app fala direto com a API dele usando a sua chave, sem proxy nosso no meio.

  4. Não há analytics de uso

    Nenhum SDK de produto, nenhum evento de comportamento, nenhuma métrica de uso — retirados do app, e esta página também não tem. O que ficou é relatório de falha, com chaves, tokens e e-mails filtrados antes do envio.

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.

Com um provedor de IA local e sem abrir o marketplace, o que resta de rede é a sua conta, a checagem de atualização e o relatório de falha.

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: quem declara tipos de coluna, tipos de rota e o gerador é o pack instalado, não o núcleo. O catálogo de packs disponíveis fica dentro do app, e outra stack entra como pack novo — seu ou da comunidade.

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

    Não sem você ver. Toda escrita passa por um diff que você aprova arquivo por arquivo, e o gerador roda em subprocesso isolado, sem caminho para o seu disco fora dessa aprovação.

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

    O que você declarou são arquivos JSON no próprio projeto, independentes do pack. Trocar de pack troca o gerador e o vocabulário; o que está declarado continua no repositório.

  • Preciso de conexão para trabalhar?

    Para modelar e gerar, não. Conexão é necessária para verificar licença, instalar pack novo e, se o provedor de IA for remoto, para o agente — com provedor local o agente roda sem sair da máquina.

  • 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. O que muda de um plano para outro é o agente de IA, o histórico de sessão, os assentos da organização e os packs privados — a página de Preços lê o catálogo do produto e mostra o que está publicado.

  • Como funciona a licença?

    A licença é verificada pelo app e vale por perfil. Times têm organização com assentos, e packs privados da organização ficam visíveis só para quem está nela.

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

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

Recomendado para o seu sistema

Sempre a versão estável mais recente.

Outros canais de atualização

Os canais abaixo recebem versões antes do estável. Atualizam pelo mesmo mecanismo do app, mas podem trazer defeitos ainda não corrigidos — use em projetos que você pode dar ré.

BetaRecursos fechados, em validação. Boa escolha para acompanhar de perto.

CanaryBuild do dia, sem validação. Só se você quer ver o que vem primeiro.