Context
Reunimos as fontes autorizadas relevantes para o projeto.
Organizarea muncii Desenvolvimento e demonstrações
Taskin explora a transformação de discussões e do contexto do projeto em compromissos, prioridades e passos de trabalho. O objetivo é manter a ligação entre uma tarefa e a conversa de onde surgiu.
Taskin
Reunimos as fontes autorizadas relevantes para o projeto.
Identificamos as decisões e as tarefas a fazer para verificação pela equipa.
Organizamos as responsabilidades e o acompanhamento dos passos confirmados.
A reconstrução das decisões e das prioridades sem perder o contexto.
Propostas de tarefas a partir de discussões, revistas antes da utilização.
Uma direção para a coordenação entre pessoas e agentes AI.
As funções e as conexões estão em desenvolvimento. Não assumimos que qualquer decisão extraída automaticamente seja correta ou aprovada.
Taskin em detalhe
Taskin é um board de trabalho que tem uma particularidade: não espera que você lhe introduza as tarefas. Lê o que já aconteceu — chamadas, emails, calendário, mensagens, commits, sessões de trabalho — e propõe o que deve ser feito, juntamente com a prova de onde surgiu a proposta.
A distinção que constrói é entre o que foi observado e o que foi decidido. Uma tarefa proposta automaticamente não se torna um compromisso até que uma pessoa confirme o responsável, o prazo e a formulação. Essa regra não é uma promessa de interface, mas uma restrição imposta na base de dados: um agente não pode fechar uma tarefa, e qualquer escrita que feche uma tem de declarar quem a pediu. Uma escrita sem nome é recusada.
Usamo-lo em nós próprios. Quase tudo o que é interessante nele surgiu porque nos faltava algo concreto na operação da nossa própria empresa, e os comentários no código citam contagens reais de produção e incidentes com data — incluindo um em que uma rotina diária ficou em silêncio durante onze dias seguidos sem que ninguém o soubesse.
50 rotas por 49 páginas: equipas, ciclos, projetos, tarefas, inbox, folha de rota, plano do dia, clientes com dossier e histórico, despesas recorrentes, faturação, registo de horas e sessões de trabalho, desempenhos, chat interno, administração e membros. A base tem 90 tabelas, construídas a partir de 81 migrações.
Rotinas programadas no servidor, não temporizadores no processo — porque um temporizador perde-se a cada redeploy. Cada execução passa por um invólucro que escreve no registo e trata até uma resposta HTTP 200 como falha se trouxer uma lista de erros, com alerta no Telegram. O invólucro existe porque, antes, um comando que falhava silenciosamente deixou o briefing diário morto durante onze dias.
14 ferramentas via HTTP — leitura (listagem, pesquisa, a minha fila, a fila dos agentes, resumo do board, pessoas, agentes, projetos) e escrita (criação, atualização, atribuição, movimento, comentário). Cada token de acesso está ligado a um perfil real, por isso a atividade no board regista quem a pediu. Um agente AI e um colega trabalham na mesma lista, com as mesmas regras.
Telegram, como bot próprio com escuta permanente, incluindo transcrição de mensagens de voz. Quatro caixas de correio eletrónico (três Gmail e uma Microsoft 365), lidas exclusivamente em modo de leitura. Google Calendar. Chamadas telefónicas, através de tronco SIP, incluindo chamadas de lembrete iniciadas pelo board. Obsidian. LinkedIn. Os modelos passam por um gateway próprio compatível com OpenAI, e o motor de execução dos agentes usa um ciclo de ferramentas sobre OpenRouter.
"Um agente não fecha uma tarefa" é uma função na base de dados, não uma frase numa descrição de ferramenta. Chegou lá porque a primeira versão não funcionava: identificava o ator de uma forma que ficava vazia para um serviço automático, por isso a regra não se aplicava em lado nenhum. Agora o ator é resolvido a partir de três fontes sucessivas e, se não se puder determinar, o pedido é recusado.
Dados e funcionamento
Da exploração à implementação
Não ligamos tudo. Uma fonte — normalmente o email ou o Telegram — e um projeto real, para se verem em dados reais o que o sistema propõe e quanto do que propõe é útil.
O período em que o sistema propõe e a equipa apenas confirma ou rejeita é o que diz se vale a pena continuar. Uma proposta rejeitada é tão informativa como uma aceita.
Quem pode encerrar o quê, o que significa um prazo e o que acontece com uma tarefa sem responsável. Aqui também se decide se os agentes podem escrever no board e em que condições.
A entrega é por rsync para uma máquina, não para um contentor: a interface como diretórios estáticos servidos por nginx, o coletor e o servidor MCP como serviços systemd. A verificação de saúde compara o pacote servido com o construído e faz rollback se não coincidirem.
Funciona em produção e é o board com o qual conduzimos a nossa empresa. Os números: 566 commits, o último em 4 de setembro de 2026; 81 migrações que constroem 90 tabelas; 171 políticas de acesso ao nível da linha; 563 casos de teste automáticos em 38 ficheiros; 21 rotinas agendadas no servidor mais 9 loops no processo; 14 ferramentas MCP; 35 endpoints no coletor. O que não é: um serviço com autosserviço. Não existe um botão com o qual uma equipa externa o possa iniciar por si própria — instala-se.
Não, e a restrição está na base de dados, não na interface. Uma função de tipo guard impede um agente de encerrar uma tarefa, e qualquer escrita que encerre uma tem de declarar o ator; se o ator não puder ser determinado, o pedido é recusado. Vale a pena dizer também porque a regra é assim: a primeira versão identificava o ator por meio de uma função que devolvia vazio para um serviço automático, por isso não se aplicava em lado nenhum. Uma auditoria própria detetou-o, e a migração que o corrigiu explica no comentário exatamente o que não funcionava.
Na prática, com código e com rotina agendada: Telegram (bot próprio, escuta permanente, transcrição de mensagens de voz), quatro caixas de correio — três Gmail e uma Microsoft 365 — apenas leitura, Google Calendar, chamadas telefónicas por tronco SIP, Obsidian, LinkedIn, além de sessões de trabalho e atividade git lidas do computador da pessoa. Os modelos passam por um gateway próprio compatível com OpenAI; o motor de execução dos agentes corre em OpenRouter. O que NÃO está ligado, apesar de a nossa página de integrações o mostrar: Slack, GitHub, Jira, Notion, Figma, Zapier, Dropbox, Google Drive, Microsoft Teams, GitLab, Outlook. Procurei no código e não existe uma única linha para nenhum deles. Essa página é uma grelha de marketing e tem de ser corrigida.
Não, apesar do nome de um ecrã na aplicação. Esse ecrã é, na verdade, o emparelhamento de um dispositivo por código QR, no estilo com que toda a gente está habituada no WhatsApp Web — daí vem o nome. Não existe qualquer chamada a um API WhatsApp. Além disso: esse fluxo não é usado, e as suas tabelas estão vazias, algo que a própria migração que reviu as permissões constata.
A parte útil não é termos políticas de acesso, mas termos encontrado as falhas e reparado uma a uma, com cada migração a explicar o que não funcionava. Uma auditoria própria de agosto descobriu que as três barreiras para agentes estavam inertes. Outra barreira revelou-se fail-open — a verificação era completamente saltada, não rejeitada — e foi invertida para falhar fechado. O terceiro problema era subtil e geral: no Postgres, uma função nova é executável por omissão por toda a gente, por isso a concessão explícita de direitos não restringia nada; foi verificado em produção que uma chave anónima entrava no corpo da função, e depois foi revogado o direito por omissão. Ao nível do repositório, uma barreira rejeita pushes diretos para a branch principal e bloqueia ficheiros de segredos, porque um repositório privado numa conta pessoal não pode ter proteção de branch por parte do GitHub.
Três coisas que preferimos dizer. Os tipos gerados para a base de dados estão antigos desde janeiro e contêm tabelas de um projeto totalmente não relacionado, o que forçou 101 conversões de tipo forçadas em 26 ficheiros — funciona, mas perde a verificação em compilação exatamente onde seria útil. O verificador de estilo reporta 161 erros herdados e não bloqueia a entrega. E 36 testes são saltados na integração contínua porque precisam de uma chave de modelo que não existe lá. Nenhum deles trava o produto; os três são dívida real.
Por rsync, não por contentor: a interface vai para um diretório estático servido por nginx, o coletor e o servidor MCP correm como serviços systemd. A integração contínua corre os testes e constrói; a entrega só arranca se esses tiverem passado na branch principal, através de um executor próprio que tem permissão para correr exatamente dois scripts e mais nada. Cada ação externa no pipeline fica fixada pela sua impressão digital completa, não por uma etiqueta, depois do comprometimento de uma ação popular em março de 2026. A verificação de saúde lê que pacote a página servida referencia e faz rollback se não for o recente — regra escrita após um incidente real em 3 de setembro de 2026. As migrações da base de dados continuam manuais, deliberadamente.
Exemplo ilustrativo
Um cenário de utilização, sem dados de cliente nem resultados comerciais atribuídos.
Uma chamada termina com uma promessa. Ninguém a escreve em lado nenhum, e daí a uma semana ninguém se lembra nem do que foi prometido, nem a quem.
A chamada entra no board através de uma rotina programada, como registo com ligação de volta à origem. Um loop liga-a ao dossier do cliente certo e propõe uma tarefa com responsável e prazo. A proposta continua a ser proposta: o gate na base de dados não permite que um agente a feche, e a escrita que a fecharia tem de declarar quem a pediu.
A tarefa aparece com o contexto de que resultou anexado, de modo que um colega que não esteve na chamada possa entender o que precisa de ser feito sem reconstruir a conversa. Uma pessoa confirma o responsável, o prazo e a formulação — ou rejeita a proposta, o que é igualmente informativo.
Ce este necesar:Sursa trebuie conectată efectiv, cu acces autorizat, și trebuie să existe un acord al echipei asupra a ce înseamnă o sarcină atribuită. Sistemul nu presupune consimțământul nimănui.
Possibilidades de colaboração
A ligação das fontes autorizadas, a organização da informação e a revisão das ações pela equipa, com acesso separado por funções.
Definimos um piloto em torno de um processo real: utilizadores, dados, integrações, custos e critérios de aceitação. A expansão segue após a avaliação do resultado.
Estabelecemos os requisitos de acessibilidade, alojamento, proteção de dados e interoperabilidade. Qualquer ligação a serviços AGE ou STISC requer a validação da elegibilidade, do acesso e das aprovações.
Estes são cenários de adaptação, não declarações sobre contratos ou parcerias existentes. As funções propostas confirmam-se no âmbito de trabalho do projeto.
Fale sobre um pilotoUm assistente ligado à informação do seu negócio, nos canais por onde os clientes lhe escrevem.
PlatformăO Cronberry junta fontes autorizadas, conversas e relações num espaço de investigação e coordenação.
Desenvolvimento e demonstraçõesO Megaforms explora a recolha de respostas por formulários conversacionais, incluindo respostas por voz e transcrição.
Desenvolvimento e demonstraçõesConte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.