O Asana não sabe que há um contêiner parado na alfândega.

Sim. O mesmo componente de Tarefas é renderizado em três portais: operador (visibilidade total), cliente (o comprador — vê as tarefas criadas para ele, como "Aprovar amostra" ou "Confirmar embarque fracionado"), e fornecedor (o Fabricante — vê as tarefas criadas para ele, como "Enviar relatório SGS" ou "Confirmar cronograma de inspeção"). Cada portal utiliza o mesmo modelo de dados com um prefixo API diferente (operador: /api/tasks · cliente: /api/portal/client/tasks · fornecedor: /api/portal/supplier/tasks) e uma whitelist restrita de tipos de entidade. O operador cria uma tarefa, atribui-a a um contato do fornecedor, e ela aparece na lista de tarefas do portal do fornecedor — mesmo enum de status, mesma prioridade, mesmo fluxo de atividades. O fornecedor a marca como concluída; o operador vê a conclusão em tempo real.

Aprovações são tarefas. Especificamente, uma tarefa com o status pending_approval — um dos seis status nativos. Quando um operador ou contraparte submete um entregável que precisa de validação (uma redline de contrato, uma avaliação de amostra, um estouro de orçamento, uma versão de documento), o trabalho passa para pending_approval e aparece na lista de tarefas do aprovador junto com tudo o mais que ele precisa tratar. Aprovação, rejeição e ”requer alterações” são transições de status na tarefa. O registro de auditoria — quem aprovou o quê, quando e por quê — fica no fluxo de atividades da tarefa. Optamos deliberadamente por não construir um motor de aprovações separado; incorporá-lo às Tarefas significa uma única caixa de entrada, um único fluxo de trabalho, um único lugar para consultar.

Sim — essa é a parte de ”sistema nervoso” da arquitetura. Eventos em outras seções (mudança de status de pedido, QC de produção concluído, atraso em embarque, fatura vencida, amostra avaliada, reclamação registrada, documento carregado, mensagem sinalizada com um item de ação) são todos emitidos pelo motor de Tarefas. A plataforma decide se o evento requer atenção humana com base em regras configuráveis por categoria e, quando isso ocorre, uma tarefa é criada com o link da entidade herdado, a categoria predefinida e um responsável sugerido com base no histórico de partes responsáveis. As Tarefas são a forma como a plataforma comunica aos humanos o trabalho que precisa ser feito — e como acompanha se esse trabalho foi realizado.

A principal superfície de ação do Atlas É a criação de tarefas. Quando o Atlas detecta algo que requer julgamento humano — uma margem caindo abaixo de um limite, uma contraparte ficando em silêncio em um thread, um documento prestes a expirar, um padrão recorrente entre Pedidos — ele cria uma tarefa com os dados relevantes já anexados. Uma mensagem de chat faz uma pergunta e some. Uma tarefa carrega o contexto, o responsável, a data de vencimento e o registro de auditoria sobre se o operador agiu. Isso torna o sinal do Atlas mensurável: a tarefa foi encerrada no prazo? Foi encerrada? O fato de o Atlas criar tarefas (em vez de apenas postar mensagens) é a forma como mantemos a IA responsável pelo trabalho que ela sinaliza.