O Cursor transforma uma planilha de vendas em um app. Quem fica responsável pelo link?

Na segunda-feira de manhã, a liderança de vendas quer uma página com as contas que precisam de atenção. Os números ficam em uma planilha, as regras de atribuição ficam em outra aba e cada pessoa tem uma cópia um pouco diferente. Alguém do desenvolvimento consegue montar um painel útil em uma tarde. A primeira pergunta difícil aparece quando a liderança pede o link.

A Anysphere, criadora do ambiente de programação Cursor, lançou o Live Apps em 5 de novembro de 2026. Você pede um aplicativo web a um agente do Cursor na nuvem. O Cursor pode configurar hospedagem, autenticação e um banco Postgres, caso o aplicativo precise. Depois de uma revisão de segurança e de uma ação explícita de publicação, o aplicativo recebe uma URL ativa. O recurso está disponível em planos pagos com agentes na nuvem habilitados. O código pode vir de um repositório novo ou existente no Cursor Origin ou no GitHub. Anúncio do lançamento do Cursor

Assim, um aplicativo interno vira uma opção prática para tarefas que antes dependiam de cópias de planilhas e mensagens semanais. Também fica fácil passar de um protótipo para algo de que um colega vai depender. Um painel de vendas e um portal de integração de novos funcionários ajudam a entender quando o protótipo está pronto para esse passo e quem pode ver, alterar ou desativar o que ele disponibiliza.

O botão de publicação encerra uma tarefa e inicia outra

O Cursor pede que você diga explicitamente que quer criar um aplicativo e use um agente na nuvem. Uma sessão local de programação ainda pode ajudar com o código, mas o fluxo do Apps descrito pelo Cursor passa pelo agente na nuvem. Começar do zero permite criar um repositório no Cursor Origin. Se a equipe já tem um aplicativo em um repositório compatível, pode usar esse código. O Cursor provisiona os recursos, enquanto quem publica escolhe a URL e decide quando compartilhá-la. Configuração e implantação de aplicativos

Caminho do código-fonte à URL ativa, com o público e a origem dos dados mostrados separadamente. Ilustração original do Telli.sh.

O Cursor descreve dois tipos de revisão antes da publicação. Verificações determinísticas detectam condições conhecidas, como uma credencial gravada em um arquivo. Uma revisão de segurança por IA examina o código-fonte em busca de problemas graves. Segundo o Cursor, administradores podem adicionar regras próprias, consultar os aplicativos e segredos da equipe e retirar aplicativos do ar. Também podem autorizar algumas publicações bloqueadas pela revisão por IA. O Cursor mantém os bloqueios para código malicioso, segredos embutidos e credenciais expostas. Cabe à pessoa responsável decidir de quais credenciais o aplicativo precisa desde o início. Anúncio do lançamento do Cursor · Segurança e administração de aplicativos

Imagine um aplicativo cuja página inicial mostra totais de vendas e cujo endpoint de detalhes devolve todas as contas. A página pode parecer devidamente limitada quando uma gerente de vendas entra. Ainda assim, um colega pode conseguir abrir uma URL de detalhes por tentativa ou pedir ao backend dados de um território que ele não vê na tabela. A revisão de implantação pode encontrar falhas de implementação. A política de acesso da equipe define a regra de territórios, e o teste de lançamento precisa exercitá-la com os perfis relevantes.

Com uma URL ativa, essas escolhas passam a ter consequências. Depois que os colegas salvam o link, um relatório quebrado pode atrasar uma reunião matinal. Se o aplicativo vira o único lugar onde uma decisão ou aprovação é registrada, o banco dele passa a fazer parte de um processo de trabalho. Até um aplicativo pequeno precisa de alguém que saiba explicar o que aconteceu quando os números parecem errados.

Comece com um painel que só possa ler

Suponha que a equipe de operações de vendas queira acompanhar o funil de dois territórios. Uma primeira versão sensata mostra a quantidade de oportunidades por etapa, a data da última atualização e um link para consultar os detalhes no CRM. Primeiro, ela funciona com contas fictícias. Quando a visualização estiver correta, a credencial pode ler um relatório restrito ou uma visão do banco que contenha só os campos necessários ao painel. O CRM continua responsável pelas atribuições e anotações. Assim, a primeira versão deixa alterações nos registros comerciais fora de escopo e você mantém uma fonte independente para conferir os totais.

A documentação do Cursor Apps diz que é possível cadastrar segredos para um data warehouse ou outro recurso externo na configuração do aplicativo ou no painel Apps. Segundo o Cursor, o agente não vê os valores. As credenciais ainda importam quando o aplicativo publicado faz uma requisição. Mantenha a conexão no código do servidor, limite o escopo das consultas e procure, na página gerada e nas respostas de rede, campos que deveriam permanecer no servidor. Uma credencial somente de leitura só ajuda se a conta de fato tiver acesso restrito à leitura dos dados pretendidos. Segredos no Cursor Apps

Teste o painel de três pontos de vista. O usuário previsto deve ver o total correto e a hora da atualização. Um colega de outro território deve ver apenas as linhas permitidas pela política do aplicativo, mesmo se editar o link ou a requisição. Uma pessoa fora do público autorizado deve ter o acesso negado antes de receber qualquer dado do painel. A segunda verificação é especialmente útil porque a falha passa despercebida com facilidade quando só quem criou o aplicativo o testa.

Concilie os totais com uma cópia fixa dos dados do sistema de referência. Registre o período, o fuso horário, os critérios de inclusão e o total exato esperado para cada território. Um gráfico que parece omitir as oportunidades de segunda-feira talvez esteja usando outro intervalo de apuração. Inclua um resultado vazio, um serviço de origem que não responde e uma atualização desatualizada nos primeiros testes. A data da última atualização bem-sucedida e um erro explícito ajudam a distinguir uma interrupção de uma queda real no volume do funil.

Cada campo do portal de integração precisa justificar seu lugar no banco

Um portal que apenas leva a páginas de políticas já existentes pode dispensar um banco novo. Uma lista interativa passa a ter estado próprio. O Cursor pode provisionar Postgres quando um aplicativo precisa dele, o que facilita criar a segunda versão. Antes disso, anote quais valores realmente precisam ser mantidos. Um identificador da etapa, a data e hora de conclusão e o identificador estável do usuário autenticado podem bastar. Uma cópia das anotações de um gestor, um documento de identidade ou o endereço de um funcionário aumentam o risco sem melhorar a lista. Recursos do Cursor Apps

Separe os dados que ajudam funcionários a acompanhar o processo dos dados de que a coordenação precisa para administrá-lo. Um funcionário pode marcar as próprias leituras obrigatórias como concluídas. A coordenação pode precisar ver etapas em atraso de uma turma inteira. Use uma regra de permissão diferente para essa visão e faça uma auditoria específica da consulta. Uma única tela de login dá consistência às duas visões, embora as necessidades de acesso sejam diferentes.

Três verificações de acesso distintas para um único aplicativo interno. Ilustração original do Telli.sh.

Um piloto pequeno pode começar com um funcionário fictício e um perfil de coordenação de teste antes de armazenar dados reais de integração. Use uma tentativa que deve falhar como critério para liberar a versão. Um funcionário precisa ser incapaz de sobrescrever a conclusão de outra pessoa, mesmo depois de alterar um identificador na requisição do navegador. Em seguida, confirme que uma segunda tentativa na mesma etapa preserva o estado, sem duplicar o progresso. O objetivo do piloto é tornar o comportamento verificável sem pedir que um colega exponha informações reais.

Uma lista de transição ajuda a manter esse tipo de aplicativo. Registre como uma nova pessoa da coordenação recebe acesso, onde o conteúdo do guia é editado, quem pode retirar o acesso de um ex-funcionário e o que acontece com os registros de conclusão. Decida como recuperar os dados relevantes se uma alteração falhar. O Cursor pode provisionar o banco. A equipe ainda define o que recuperação e retenção significam para essa lista.

Um convite e uma chave de integração cumprem funções diferentes

A documentação atual do Cursor Apps distingue três opções de compartilhamento. Um aplicativo somente para convidados pode permitir acesso ao responsável e a pessoas ou grupos específicos que fizeram login. O compartilhamento com a equipe pode liberá-lo a toda a equipe do Cursor que estiver conectada. Um aplicativo público pode ficar aberto a qualquer pessoa com a URL. Nos planos Teams e Enterprise, essa opção fica desabilitada até que um administrador a ative. O anúncio destaca o compartilhamento público nos planos individuais. Por isso, uma URL que funciona diz pouco sobre quem realmente pode usá-la até você confirmar a visibilidade no painel Apps. Compartilhamento no Cursor Apps

A mesma documentação explica as chaves de API para requisições automatizadas. A chave segue em um cabeçalho HTTP, e o sistema identifica a requisição como automatizada, sem associá-la a uma pessoa. Isso é útil quando um script precisa chamar o aplicativo e muda a investigação de uma requisição inesperada. Se o aplicativo aceitar sessões de pessoas e uma chave de API, confirme que a automação pode executar apenas as ações necessárias. Registre onde a chave é usada e quem vai substituí-la. Mantenha o primeiro piloto restrito a pessoas se toda ação relevante começa quando um colega abre o link. Chaves de API do Cursor Apps

Há três limites a testar quando um aplicativo lê um data warehouse. O Cursor controla o público do link. O aplicativo decide quais ações e linhas ficam disponíveis para esse público. O sistema de origem decide o que a credencial de serviço pode ler. As outras camadas podem limitar o efeito de um erro em uma delas. Se um painel interno precisa apenas de contagens agregadas do funil, conceder uma credencial capaz de consultar todos os registros do CRM torna caro até um erro pequeno no aplicativo.

Os testes podem ser simples. Abra o link ativo em uma sessão nova do navegador como pessoa convidada, como colega conectado sem permissão e sem fazer login. Na sessão autorizada, solicite um registro que deve ser visível e outro de um território diferente. Se um script usa uma chave, verifique que uma requisição sem o cabeçalho falha e confirme que uma chave revogada é rejeitada. Cada verificação revela um tipo diferente de erro.

Uma primeira versão enxuta acelera a revisão

1. Escolha uma tarefa e um público definido. Para o painel, peça totais semanais do funil por etapa com registros fictícios, horário de atualização visível e um link para o CRM. Para o portal, peça uma lista pequena com contas de funcionários fictícios.
2. Inicie um agente na nuvem e peça explicitamente que ele crie um aplicativo. Use um repositório que a pessoa responsável pelo aplicativo possa acessar. Mantenha a primeira alteração de código pequena o bastante para que ela consiga explicar as rotas, o modelo de dados e o tratamento de erros.
3. Defina o que pode ser armazenado e quais requisições podem gravar dados. Conecte uma credencial de escopo limitado nas configurações só quando o fluxo com dados fictícios estiver funcionando. Peça ao agente para mostrar onde a credencial é usada e onde são aplicadas as regras de acesso.
4. Use a revisão de publicação e examine o relatório. Escolha a URL, publique explicitamente e compartilhe com o menor grupo adequado. Teste requisições autorizadas e negadas no link implantado antes de pedir que alguém passe a depender dele.
5. Registre quem responde pelo aplicativo, qual serviço de origem ele chama e quem pode retirá-lo do ar. Repita uma verificação curta depois de alterar a visibilidade, um conector ou credenciais. Mantenha um link ou procedimento alternativo caso o aplicativo fique temporariamente indisponível.

A primeira versão pode ser mais restrita do que o código que o agente consegue gerar. Um painel que mostra um número confiável toda manhã pode valer mais do que um espaço com seis visualizações cujos cálculos são contestados. Um portal com uma lista bem mantida pode acabar com mensagens repetidas mesmo que a visão da coordenação fique para depois. Uma versão menor também permite à pessoa responsável observar quais mudanças, pedidos de acesso e dúvidas de suporte aparecem de fato.

Vale avaliar o resultado durante uma semana normal. Observe com que frequência alguém abre o aplicativo espontaneamente, se consegue localizar a fonte quando questiona um valor e quanto tempo a pessoa responsável leva para corrigir um problema. Um aplicativo ativo que poupa alguns minutos por dia pode justificar sua existência. Se as pessoas ainda usam a planilha para confirmar os números, descubra em qual resultado do aplicativo ainda falta confiança.

As mudanças do Cursor facilitam iniciar esse tipo de piloto. No anúncio de 5 de novembro, construção, banco de dados, autenticação, hospedagem e link para compartilhar fazem parte de um único fluxo. Antes, o mesmo experimento poderia morrer enquanto alguém procurava uma pessoa para cuidar da hospedagem ou tentava configurar uma tela de login. Com essas partes disponíveis, o ponto crítico passa a ser explicar claramente o público, os dados e as condições da publicação. O resultado útil é um link que alguém consegue usar e que outra pessoa sabe manter. Anúncio do lançamento do Cursor

Fontes

• Lançamento do Cursor Live Apps, 5 de novembro de 2026
• Documentação do Cursor Apps sobre configuração, compartilhamento e controles administrativos

---

Para consultar depois as conversas e decisões que orientaram a criação de uma ferramenta interna, crie uma conta no Telli.sh.