Public product documentation and blog content. No account is required for these public resources.
Blog Thesis 2.1: compute adaptativo virou parte da resposta 2026-09-10 A versão 2.1 separa tarefas simples de problemas que realmente exigem prova, auditoria e verificação, sem transformar cada prompt em um ritual de múltiplos agentes.
O problema não era falta de tokens Em testes difíceis, o gargalo aparecia antes da matemática: o roteador podia classificar uma prova extensa como tarefa de instrução ou aplicar esforço baixo justamente quando o prompt pedia auditoria recursiva. Thesis 2.1 muda a unidade de decisão. O sistema estima família, dificuldade, risco de erro e contrato de saída antes de escolher o nível de compute. A meta não é usar mais raciocínio sempre; é impedir que uma tarefa de alto risco receba o mesmo orçamento de uma resposta cotidiana.
Uma política de dificuldade, não um botão decorativo Low continua existindo para respostas determinadas por contexto curto. Medium entra quando há várias restrições ou encadeamento lógico. High passa a ser obrigatório em provas, operator theory, matemática avançada, problemas abertos e solicitações explícitas de xhigh ou ultra. O usuário ainda pode pedir um esforço, mas o runtime não reduz uma tarefa classificada como difícil só porque uma heurística textual escolheu a rota errada.
Preflight barato antes do solver caro Em instâncias difíceis, o Melos 2 pode atuar primeiro como crítico rápido. Ele não resolve a questão; extrai obrigações de formato, invariantes, pontos de circularidade e falhas que merecem inspeção. Esse mapa é entregue ao GPT-OSS 120B, que continua sendo o solver principal. A separação reduz um tipo comum de desperdício: usar o modelo maior para descobrir, tarde demais, que deixou passar uma condição explícita do prompt.
Verificação só quando compra informação O 2.1 não transforma toda resposta em dois passes de 120B. Checks determinísticos vêm primeiro. Quando a tarefa é arriscada e ainda existe incerteza material, um segundo modelo pode auditar a conclusão. O ganho desejado é reduzir erros independentes e violações de contrato, não produzir uma resposta diferente por vaidade. Se o verificador não encontra defeito concreto, a resposta primária permanece.
O que 2.1 não promete Mais compute não transforma um foundation model em oráculo. Thesis 2.1 não promete prova de problemas abertos, zero erro ou superioridade universal. A mudança é operacional: problemas difíceis recebem mais capacidade, saídas passam por contratos verificáveis e afirmações extraordinárias enfrentam guards explícitos. A versão deve ser julgada por regressões e benchmarks, não pelo número 2.1.
Math-first: por que Thesis 2.1 mudou a ordem do roteamento 2026-09-10 Quando uma prova tem muitas regras de formato, o formato não pode roubar a tarefa da matemática. O 2.1 dá prioridade ao conteúdo e valida a apresentação depois.
A falha de precedência Um prompt matemático sério costuma conter dezenas de comandos: prove, audite, use três fases, preserve uma notação, pare sob uma condição, não consulte a web. Um classificador ingênuo vê muitos verbos imperativos e conclui “instruction following”. Isso é tecnicamente coerente e operacionalmente errado. A tarefa central continua sendo matemática. Thesis 2.1 identifica primeiro o domínio decisivo; o contrato de forma vira uma camada posterior.
Conteúdo primeiro, contrato depois O router agora trata prova, álgebra linear, combinatória, teoria dos números, probabilidade, cálculo, corpos finitos e operator theory como famílias de reasoning com prioridade própria. Depois da geração, um guard verifica marcadores obrigatórios, JSON-only, contagem de palavras, fases e regras de loop. Assim, cumprir o formato não exige trocar o solver matemático por um caminho de texto genérico.
Famílias diferentes, verificações diferentes Combinatória pede controle contra dupla contagem. Teoria dos números pede resíduos reversos e hipóteses de coprimalidade. Operator theory pede domínio, closability, diferença entre simétrico e autoadjunto, classes de Schatten, espectro essencial e topologia de convergência. O 2.1 mantém lenses específicos para impedir que uma auditoria matemática vire apenas “releia a resposta e veja se parece correta”.
Corpos finitos continuam com pipeline especializado Problemas de F₂, decomposição por fatores irredutíveis, semissimplicidade, centralizadores e classes de conjugação já possuíam um caminho especializado. Thesis 2.1 não joga esse trabalho fora. O novo kernel reconhece esses casos e delega ao pipeline matemático existente com esforço alto, preservando solvers determinísticos e verificações que já provaram valor.
O ganho real é menos desvio silencioso Esse desenho não aumenta a inteligência do foundation model por decreto. Ele reduz uma classe concreta de erro sistêmico: mandar o modelo certo para o problema errado. Em benchmarks de reasoning, um roteamento imperfeito pode apagar qualquer benefício de um modelo maior. Math-first transforma esse risco em uma decisão explícita e observável.
Thesis 2.1: 120B resolve, 20B audita 2026-09-10 A verificação cruzada usa modelos com perfis diferentes e orçamentos separados para procurar defeitos, sem duplicar o custo do solver principal em toda mensagem.
Independência útil, não consenso teatral Pedir ao mesmo modelo para “revisar a própria resposta” pode detectar erros, mas também reproduz os mesmos atalhos. No 2.1, GPT-OSS 120B continua responsável pela solução e GPT-OSS 20B pode atuar como auditor independente. O verificador recebe a tarefa e a resposta como material não confiável, tenta resolver o passo decisivo por conta própria e procura contraexemplos, hipóteses escondidas e violações de contrato.
Quotas por modelo viram recurso de arquitetura O governor acompanha orçamento por modelo. Isso permite gastar compute do 20B para verificação sem fingir que cada token do auditor pertence ao teto do 120B. A consequência prática é simples: o sistema pode obter uma segunda perspectiva quando ela vale a pena sem reduzir desnecessariamente a resposta principal.
O auditor não ganha direito de reescrever tudo Um verificador probabilístico também erra. Por isso a arquitetura não aceita qualquer discordância como correção. O council distingue defeito menor de defeito material e exige confiança alta antes de substituir a conclusão. Se não houver falha concreta, mantém-se o resultado do solver. Essa assimetria evita que a verificação introduza regressões por preferência estilística.
Determinístico antes do LLM Contagem exata de palavras, JSON válido, presença de fases, marcadores de loop e testes de código não precisam de julgamento semântico. Esses checks vêm antes. O auditor é reservado para propriedades que exigem interpretação: uma implicação circular, uma hipótese esquecida, um argumento espectral mal definido ou uma conclusão mais forte que as premissas.
Verificação é evidência, não certificado de verdade Quando dois modelos concordam, a confiança operacional pode aumentar, mas a resposta não se torna matematicamente provada por votação. Thesis 2.1 registra verificação como uma classe de evidência e continua distinguindo resultado derivado, teste executado, fonte recuperada e julgamento de modelo. Essa separação é parte do produto porque evita que telemetria pareça mais forte do que realmente é.
Riemann como teste de produto: o Open Problem Guard do Thesis 2.1 2026-09-10 Problemas abertos são excelentes testes de honestidade: o sistema precisa explorar ideias sem converter uma ponte conjectural em “prova” só porque a escrita ficou convincente.
Por que RH expõe falhas de reasoning A Hipótese de Riemann concentra quase todos os riscos que um agente avançado precisa administrar: objetos analíticos delicados, construções espectrais formais, limites de operadores, equivalências não provadas e enorme incentivo para confundir uma ideia elegante com um teorema. Um sistema que responde bem a perguntas triviais ainda pode falhar de forma espetacular aqui. Por isso RH entrou no 2.1 como caso de regressão e não como promessa de descoberta.
A regra: não assuma a ponte que precisa provar Se um operador é definido a partir dos zeros e depois sua autoadjunção é usada para concluir que os zeros estão na reta crítica, o argumento pode conter a própria conjectura na construção. Se Kε é compacto para ε>0, isso não dá automaticamente convergência espectral bijetiva quando ε→0. Se uma perturbação é compacta, o teorema de Weyl não permite apagar livremente um espectro essencial preexistente. O Open Problem Guard força o solver a identificar esse tipo de ponte antes de declarar êxito.
Falhar corretamente também é capacidade Em problemas abertos, a melhor resposta muitas vezes é um mapa rigoroso do ponto em que o argumento quebra. Thesis 2.1 trata isso como resultado legítimo. Se o domínio autoadjunto não foi construído, a topologia de convergência não foi especificada ou o determinante usado exige trace class que não foi provada, o sistema deve expor a obstrução. Preencher a lacuna com linguagem plausível é uma regressão.
Loops do prompt agora viram contrato verificável Um teste recente exigia iniciar outra iteração sempre que a confiança ficasse abaixo de 9/10. A resposta avaliou a própria construção em 3/10 e mesmo assim encerrou. O 2.1 transforma esse padrão em check: se existe nota abaixo do limiar, o output precisa conter o marcador de falha e uma iteração subsequente quando o prompt assim exige. É um detalhe de instruction following, mas em reasoning longo esse detalhe decide se o processo continua ou abandona a busca cedo demais.
Exploração continua permitida O guard não foi criado para transformar o modelo em um compilador que só repete resultados conhecidos. Ele pode propor operadores, conexões com física matemática, novos critérios condicionais e caminhos especulativos. A exigência é rotular corretamente o status lógico de cada ponte e separar conjectura, heurística e consequência demonstrada. Isso preserva criatividade sem vender imaginação como resolução.
Melos 2: reasoning rápido sem fingir que tudo é fácil 2026-09-10 O modelo rápido mantém single-pass na maior parte do uso, mas agora sobe o esforço de forma agressiva em matemática e lógica difícil, em vez de economizar justamente onde o erro custa mais.
Velocidade continua sendo o contrato Melos 2 continua baseado no GPT-OSS 20B e não herda a arquitetura completa de múltiplos estágios do Thesis 2.1. O caminho padrão permanece curto: classificar, escolher esforço, gerar e validar o contrato. Isso preserva a característica que torna o Melos útil em chat cotidiano, coding rápido e tarefas que não justificam uma auditoria externa.
High agora significa high Antes, heurísticas de velocidade podiam manter problemas matemáticos difíceis em low ou medium. A política nova leva em conta tamanho, densidade de restrições, linguagem de prova e sinais de problema aberto. Quando o risco sobe, Melos pode usar high reasoning e um orçamento de saída maior, ainda dentro de um único passe.
Math e logic recebem disciplinas próprias Para matemática, o contrato exige codificar restrições, checar o passo decisivo e substituir o resultado de volta quando possível. Para lógica espacial e theory of mind, o modelo mantém estados separados para evitar vazamento de conhecimento. Para code trace, registra mutações e ordem de avaliação. São instruções pequenas, específicas e baratas, não uma persona universal gigantesca.
Guard de contrato sem segunda geração automática Melos verifica JSON-only, inteiro-only e outras estruturas objetivas. Uma segunda chamada só é aberta quando existe uma violação observável que realmente precisa de reparo. Essa política reduz latência de cauda e evita o paradoxo de um “modelo rápido” que passa metade do tempo avaliando a si mesmo.
Quando usar Melos e quando usar Thesis 2.1 Melos é a escolha natural quando tempo de resposta importa e a tarefa cabe em uma trajetória forte. Thesis 2.1 entra quando o custo de uma falha justifica preflight, reasoning mais profundo, verificação cruzada ou guards de problemas abertos. Os dois modelos compartilham princípios de honestidade e contrato, mas não fingem ter a mesma curva de latência.
Da resposta à decisão: um protocolo de evidências 2026-09-07 Aprenda a transformar uma resposta plausível em uma conclusão auditável, com hipóteses, fontes, limites e um critério explícito de aceitação.
Defina o que mudaria sua decisão Antes de pedir uma comparação, escreva a decisão concreta e os critérios que podem alterá-la. Para escolher uma ferramenta de trabalho, por exemplo, disponibilidade na sua região, exportação dos dados e compatibilidade com seu fluxo podem valer mais que a quantidade de recursos. Defina quais requisitos são obrigatórios, quais são preferências e qual informação ainda falta. Uma resposta útil deve mostrar o que sabe, o que pressupõe e o que precisa confirmar. Sem esse registro, uma tabela extensa pode apenas esconder uma escolha arbitrária.
Vincule cada afirmação decisiva à fonte Registre a afirmação, o endereço da fonte, a data de consulta, a versão do produto e o trecho que sustenta a conclusão. Uma fonte primária descreve diretamente o objeto: documentação do fabricante, publicação da pesquisa, registro oficial ou dados originais. Uma fonte secundária pode contextualizar ou apontar problemas, mas não deve receber autoridade que não possui. Abrir um link não prova que ele sustenta a afirmação. Confira também o escopo: uma funcionalidade disponível em um plano não implica que exista em todos. Quando duas fontes discordarem, mantenha o conflito visível até localizar a diferença de data, versão ou condições.
Faça uma verificação independente Escolha a afirmação com maior efeito sobre a decisão e tente refutá-la. Em uma conta, recalcule com outro método e confira as unidades. Se três pessoas trabalham quatro horas por dia durante cinco dias, o resultado é 3 × 4 × 5 = 60 horas-pessoa; não são 60 dias nem 60 horas de duração do calendário. Em uma recomendação técnica, execute um exemplo pequeno com resultado conhecido. Pedir a um segundo modelo que concorde não equivale a um teste: os dois podem reproduzir o mesmo erro. Registre o procedimento e o resultado observado, inclusive quando a verificação falha.
Encerre com condições, não com certeza artificial Uma conclusão responsável pode ser condicional: “Esta opção atende aos requisitos confirmados; falta verificar a exportação antes da adoção”. Liste as pendências que realmente podem mudar a escolha, a pessoa responsável pela checagem e o momento de rever a decisão. Evite porcentagens de confiança sem método definido. O resultado final deve permitir que outra pessoa repita a verificação sem reconstruir toda a conversa. Critério de aceitação: requisitos obrigatórios atendidos, afirmações decisivas sustentadas, contas reproduzidas e nenhuma pendência crítica escondida. Essa disciplina reduz o retrabalho porque separa uma decisão pronta de uma investigação ainda em andamento.
Código por agentes: revisão, execução e recuperação 2026-09-07 Um fluxo prático para transformar pedidos em mudanças pequenas, verificáveis e reversíveis, sem confundir uma interface convincente com execução comprovada.
Reproduza antes de corrigir Descreva o comportamento esperado e o observado com uma entrada concreta. “Login falha” é menos útil que “depois de confirmar o e-mail, o retorno abre a página inicial, mas a sessão não é restaurada”. Registre navegador, versão, rota e mensagem de erro sem copiar senhas ou tokens. Siga a ação do formulário ao servidor e de volta ao estado visual. Quando a falha estiver localizada, preserve um caso pequeno que a reproduza. Isso impede uma correção cosmética que apenas muda a mensagem enquanto o problema permanece.
Revise o conjunto completo de mudanças Leia os arquivos alterados e seus consumidores. Uma assinatura de função nova pode exigir mudanças no cliente, no servidor, nos tipos e no teste. Confira caminhos, importações, tratamento de falhas e compatibilidade com dados existentes. O agente deve preparar as alterações antes de gravá-las e mostrar o que será criado, atualizado ou removido. Uma alteração em permissões ou migração merece uma revisão específica; a existência de um botão “Aplicar” não prova que essa revisão aconteceu. Se o projeto mudou durante a geração, compare a revisão de origem e recalcule o diff antes de aplicar.
Separe os níveis de verificação Um parser confirma que a sintaxe é aceita. Um build verifica parte da integração entre módulos. Um teste unitário cobre uma regra isolada. Um teste de ponta a ponta percorre uma tarefa real. Nenhum deles, sozinho, garante todo o produto. Para um login, verifique campos inválidos, credenciais recusadas, conexão indisponível, retorno de sessão e recuperação de acesso. Para arquivos, confira se o documento abre e contém o que foi solicitado. Relate comando, resultado e limite do teste. Quando a execução não estiver disponível, marque “não executado”; não substitua evidência por uma frase confiante.
Planeje a recuperação Antes de aplicar, mantenha uma cópia recuperável dos arquivos afetados. Valide todos os destinos antes da primeira gravação e rejeite caminhos fora da pasta autorizada, links simbólicos e colisões entre arquivos. Se uma gravação falhar, restaure o conjunto anterior em vez de deixar metade da alteração aplicada. Depois de publicar, repita o fluxo principal na versão servida: o artefato local e o publicado podem divergir. Critério de aceitação: o defeito reproduzido desaparece, os fluxos adjacentes continuam funcionando, o usuário consegue revisar o diff e existe um caminho claro de retorno.
Da fala ao rascunho: ditado que você consegue revisar 2026-09-06 Organize ideias falando, acompanhe o texto durante a captura e revise o que importa antes de enviar.
Comece pela intenção Antes de ligar o microfone, escolha a entrega: uma mensagem, uma lista de tarefas ou o esboço de um documento. Diga primeiro o objetivo e depois os detalhes. Em uma reunião, por exemplo, separe decisão, responsável e prazo em frases distintas. Essa ordem reduz a necessidade de reorganizar um parágrafo longo depois. Você não precisa falar como um texto pronto; o rascunho existe justamente para preservar ideias antes da edição.
Texto parcial não é texto definitivo Nos navegadores compatíveis, o ditado mostra resultados parciais enquanto você fala. Algumas palavras podem mudar quando o reconhecimento recebe mais contexto. Isso é esperado, especialmente com nomes próprios, números e frases interrompidas. Em outros dispositivos, a captura pode usar a transcrição ao vivo do serviço ou transcrever ao parar. A velocidade depende do aparelho, do navegador e da conexão; não existe promessa de latência zero.
Revise os pontos de maior impacto Ao terminar, confira valores, datas, nomes e negações. “Não aprovar” e “aprovar” mudam completamente uma instrução. Use fones ou um ambiente silencioso quando possível e evite que várias pessoas falem ao mesmo tempo. O microfone preenche o rascunho; ele não envia a mensagem automaticamente. Para editar durante a captura, pare o ditado primeiro. Você mantém controle sobre o texto final e decide o momento do envio.
Como ler um benchmark de IA sem confundir meta com resultado 2026-09-06 Uma pontuação só fica útil quando você conhece a prova, a versão, as condições e as falhas incluídas na conta.
Compare a mesma prova Imagine dois sistemas avaliados em datas diferentes. Um resolveu problemas antigos; o outro recebeu uma edição mais difícil. Ordenar apenas os números mistura populações diferentes. Antes de comparar, procure a edição do conjunto de avaliação, as categorias e a forma de calcular a média. Um bom resultado em raciocínio não determina sozinho a qualidade em código, linguagem ou instruções. Também importa saber se ferramentas e pesquisa externa estavam permitidas.
Conte também as falhas Uma avaliação de produto precisa registrar respostas incorretas, interrupções e indisponibilidade. Excluir tentativas que falharam na rede pode inflar a impressão de confiabilidade. Relate separadamente acerto entre respostas concluídas e sucesso considerando todas as tentativas. Uma amostra pequena serve para encontrar regressões e orientar investigação; ela não sustenta uma posição global. Repetições e casos variados ajudam a enxergar a incerteza que um número isolado esconde.
Traga a avaliação para o seu trabalho Monte uma coleção de tarefas representativas, removendo dados pessoais desnecessários. Defina o resultado esperado antes de experimentar: um cálculo conferível, um arquivo que abre ou uma alteração que passa no teste relevante. Reserve casos que não serão usados no ajuste. Compare qualidade, tempo até uma entrega utilizável e frequência de falhas. Uma meta ambiciosa orienta desenvolvimento; o resultado publicado precisa continuar ligado às evidências que realmente existem.
Um espaço de trabalho legível em mais de um idioma 2026-09-06 Idioma, contraste e preferência de leitura precisam funcionar juntos nas tarefas que você repete todos os dias.
Escolha uma preferência explícita A detecção automática acompanha o idioma do navegador. Se você compartilha um aparelho ou trabalha em outra língua, selecione uma preferência manual. A interface oferece português, inglês, espanhol e francês. Navegar do blog para a documentação e voltar à conversa deve preservar a escolha. Os controles traduzidos ajudam a encontrar ações; seus próprios textos, nomes de arquivos e trechos de código devem manter o conteúdo original.
Modo claro exige mais que um fundo branco Uma tela legível precisa distinguir superfície, texto, borda e seleção. Caixas de entrada, menus, mensagens de erro e painéis secundários merecem o mesmo cuidado que a página inicial. Prefira uma luminosidade confortável no aparelho e aumente o texto se necessário. Cor sozinha não deve comunicar um estado: rótulos e ícones também ajudam. Fotografias, ilustrações e arquivos anexados não precisam ter suas cores invertidas para acompanhar o tema.
Verifique o fluxo que você usa Depois de mudar idioma ou tema, abra uma conversa, um menu e um artigo. Confira se o foco do teclado continua visível e se os botões longos cabem na tela. No celular, faça essa conferência com o teclado aberto. Se encontrar um trecho sem tradução, registre a página, o idioma e a frase exata, sem incluir informações privadas da conversa. Isso torna o problema reproduzível e permite corrigir a origem em vez de apenas uma captura de tela.
Melos 2: velocidade só conta quando a resposta continua verificável 2026-09-04 Uma rota mais rápida para trabalho cotidiano, com foco em respostas diretas, pesquisa quando necessária e formato final consistente.
Menos cerimônia, mais entrega Perguntas simples devem continuar simples. O ganho de velocidade desaparece quando a interface acrescenta um relatório inteiro a uma decisão de duas linhas.
Pesquisar quando a resposta depende do agora Preço, disponibilidade, versão, notícia e documentação que muda precisam de fonte atual. Conhecimento estável não precisa abrir a web por hábito.
O formato final também é qualidade JSON, listas curtas, tabelas e respostas “somente o valor” devem sair no formato pedido. Uma resposta correta que quebra o contrato ainda gera trabalho extra.
Quando usar Thesis 2.1 Arquitetura complexa, investigação longa, código de alto risco e tarefas que exigem muitas verificações ainda justificam uma rota mais pesada. A escolha deve seguir a carga de trabalho, não o prestígio do nome.
Exemplo prático e critério de aceitação Para resumir uma reunião, peça primeiro cinco decisões com responsável e prazo. Compare o resultado com as notas originais: nomes preservados, prazos ausentes sinalizados e nenhuma decisão inventada. Se uma ambiguidade mudar a entrega, forneça a informação faltante antes de trocar de modelo. Meça o tempo até o resumo aprovado, incluindo as correções que você precisou fazer.
Como verificar uma resposta de IA sem refazer tudo do zero 2026-09-04 Uma revisão eficiente procura o ponto decisivo, não repete todo o raciocínio por esporte.
Ache a afirmação que governa o resto Quase toda resposta complexa tem uma ou duas premissas sem as quais a conclusão muda. Marque essas premissas primeiro.
Use um método diferente para conferir Somar a mesma coluna duas vezes do mesmo jeito repete o mesmo erro. Prefira uma checagem independente: outra fórmula, outro agrupamento, um teste de limite ou uma fonte primária.
Separe erro de informação de erro de formato Um número certo dentro de um JSON inválido é um problema de entrega; um JSON perfeito com número errado é um problema de conteúdo. Corrigir os dois exige diagnósticos diferentes.
Pare quando a evidência fecha Verificação infinita também é desperdício. Quando o ponto decisivo foi confirmado por evidência apropriada e não há contradição material aberta, seguir revisando tende a adicionar custo sem reduzir risco.
Exemplo prático e critério de aceitação Escolha a afirmação que mais influencia a conclusão e procure uma evidência independente. Em um orçamento, recalcule um subtotal e confira a unidade; em uma comparação, abra a fonte do critério decisivo. Se o primeiro teste falhar, amplie a revisão para os itens da mesma classe. Registre o que foi conferido e mantenha o restante como não verificado.
Pesquisa na web: quando a data da fonte muda a resposta 2026-09-04 Recência não é enfeite de citação. Em muitos temas, ela faz parte do conteúdo.
Classifique a volatilidade História, definições e princípios físicos tendem a envelhecer devagar. Preços, placares, APIs, políticas, horários e cargos podem mudar em horas ou dias.
Prefira a fonte que pode responder Uma página de marketing não é a melhor fonte para um limite técnico; uma postagem social não substitui documentação oficial para comportamento de API. Autoridade depende da pergunta.
Use datas absolutas “Ontem” e “recentemente” envelhecem mal. Em relatórios ou decisões, registre a data da fonte e a data em que o fato foi verificado.
Quando não pesquisar Abrir a web para toda pergunta aumenta latência e ruído. Se o fato é estável e o usuário não pediu fontes atuais, pesquisa automática pode piorar uma resposta que já era simples.
Exemplo prático e critério de aceitação Ao comparar recursos de um produto, registre versão, data consultada e região. Uma página recente pode repetir informações antigas; procure a data do fato, não apenas a publicação. Havendo conflito, prefira a documentação do responsável pelo produto e explicite o ponto ainda incerto. Guarde o link junto da afirmação para que outra pessoa consiga refazer a checagem.
Planilhas com IA: sete checagens antes de confiar no total 2026-09-04 O erro mais perigoso em uma planilha costuma parecer plausível.
1–2 · Unidade e universo Confirme a unidade de cada coluna e quais linhas pertencem ao universo da pergunta. Misturar reais com milhares de reais ou pedidos com clientes muda tudo sem produzir erro de sintaxe.
3–4 · Duplicatas e nulos Antes de somar, conte chaves únicas e nulos. Um join um-para-muitos pode multiplicar receita; um nulo tratado como zero pode esconder ausência de dado.
5 · Recalcule uma amostra Escolha poucas linhas e calcule manualmente. Se a regra não fecha em uma amostra pequena, não confie na automação sobre cem mil linhas.
6–7 · Total alternativo e reconciliação Crie um segundo caminho de cálculo e reconcilie com uma fonte externa quando existir. Diferença pequena e explicada pode ser arredondamento; diferença sem explicação é sinal para parar.
Exemplo prático e critério de aceitação Crie uma cópia da planilha e teste um cenário pequeno cujo resultado você conhece. Inclua uma célula vazia, um valor negativo e um número armazenado como texto. Confira se filtros escondem linhas usadas na soma e se percentuais são frações ou valores inteiros. Só depois compare o total completo. Um valor plausível pode continuar errado por causa de unidade, duplicação ou intervalo incompleto.
Código gerado: um checklist curto que pega bugs caros 2026-09-04 Compilar é o começo da revisão, não o fim.
Contrato público primeiro Confira nomes de rota, parâmetros, formato de retorno e estados esperados antes de olhar implementação interna. Uma função elegante que rompe o contrato ainda é regressão.
Falhas que precisam ser simuladas Teste sessão expirada, timeout, resposta vazia, duplicidade de clique, arquivo ausente e retry. Esses casos revelam mais que o screenshot do caminho feliz.
Persistência e concorrência Pergunte quem é dono do estado e o que acontece quando duas ações chegam juntas. Muitos bugs de produção são duas operações corretas executadas na ordem errada.
Teste o que você pretende afirmar “Funcionando” deve significar algo observável: build passou, rota abriu, estado persistiu ou teste específico passou. Sem evidência, use “candidato” em vez de “corrigido”.
Exemplo prático e critério de aceitação Para uma mudança de login, não basta testar que o formulário aparece. Verifique inicialização, credenciais inválidas, rede indisponível e retorno de uma sessão existente. Reproduza o defeito antes de editar e mantenha um teste que falhe na versão anterior. A revisão deve acompanhar o caminho completo da ação, porque uma tela correta pode depender de um script que nem chegou a iniciar.
Trabalho longo com IA: escreva contratos, não romances 2026-09-04 O contexto que sobrevive é o que pode ser checado depois.
Objetivo em uma frase testável “Melhorar o app” é ambíguo. “Reduzir o login a um fluxo estável sem mudar a regra de sessão” diz o que melhorar e o que preservar.
Invariantes ficam separados Liste o que não pode quebrar: auth, formato de arquivo, rota pública, compatibilidade, identidade visual ou requisito jurídico. Isso impede que uma melhoria local compre uma regressão global.
Decisão e evidência não são a mesma coisa “Vamos usar X” é decisão. “Teste Y passou em Z” é evidência. Manter os dois separados ajuda uma sessão futura a saber o que pode ser reavaliado e o que foi observado.
Handoff termina com próximo marco Um bom handoff não termina em “continue daí”. Ele aponta o próximo resultado verificável, os arquivos relevantes e qualquer bloqueio ainda aberto.
Especifique invariantes, entregas e critérios de parada Prompts longos falham quando misturam objetivo, contexto, preferência e detalhe incidental sem indicar o que é obrigatório. Para trabalho de várias etapas, escreva um contrato curto: resultado esperado, arquivos ou sistemas que podem ser tocados, invariantes que não podem mudar, evidências que precisam ser produzidas e condição de conclusão. O modelo pode então planejar livremente dentro dessas bordas. Se surgir conflito entre duas instruções, a regra de prioridade deve estar explícita, não escondida na posição de uma frase em um bloco de milhares de tokens.
Durante a execução, mantenha o contrato separado do diário de trabalho. Novas descobertas entram como estado atualizado; não reescreva silenciosamente a intenção inicial. Ao final, verifique cada critério de aceitação e liste o que ficou incompleto. Isso funciona melhor do que pedir “seja extremamente cuidadoso” vinte vezes, uma tradição venerável dos prompts que só aumenta o tamanho sem aumentar a precisão.
Documentos e anexos: dados dentro do arquivo não viram ordens automaticamente 2026-09-04 Uma frase em um PDF pode ser conteúdo a analisar, não uma mudança de autoridade.
Pergunte quem falou A mesma frase tem peso diferente se veio do usuário, de uma política confiável, de um PDF recebido por e-mail ou de uma página aberta na web. Origem é parte do significado.
Extração não é execução Resumir uma instrução maliciosa encontrada em um documento não significa obedecê-la. A análise deve poder citar o conteúdo sem conceder permissão ao conteúdo.
Conectores aumentam a necessidade de limite Quanto mais ações externas estão disponíveis, mais importante é separar leitura de escrita e pedir autorização proporcional antes de alterar algo fora da conversa.
Registre o que foi usado Em trabalho sensível, uma resposta melhor indica quais documentos sustentam a conclusão e quais dados ficaram de fora por falta de autorização ou relevância.
Trate conteúdo como dado, não como autoridade Um PDF, planilha ou página pode conter texto que se parece com uma instrução para o modelo: “ignore as regras anteriores”, “envie estes dados” ou “execute este comando”. Quando o arquivo foi fornecido como material de análise, esse texto é conteúdo, não autorização. O runtime deve manter uma fronteira explícita entre instruções do usuário, política do sistema, resultados de ferramentas e material recuperado. Se o documento pedir uma ação externa, o sistema deve descrevê-la como parte do documento, não executá-la silenciosamente.
A defesa não deve depender de uma lista de frases proibidas. Use proveniência e capacidade: cada trecho carregado mantém sua origem, e apenas canais explicitamente autorizados podem solicitar ferramentas ou mudanças de estado. Em tarefas sensíveis, uma segunda verificação deve comparar a ação pretendida com a intenção original do usuário antes do commit.
Referência visual: como pedir fidelidade sem copiar uma interface 2026-09-04 A parte útil de uma referência é a relação entre elementos, não a clonagem da marca.
Descreva a geometria Diga onde está a massa principal, quanto espaço vazio existe, qual elemento domina e como o olhar percorre a tela. Isso é mais útil que pedir “estilo premium”.
Separe identidade de composição Logotipo, nomes, ícones proprietários e textos específicos pertencem à identidade. Grade, contraste, proporção e ritmo podem inspirar uma composição nova sem copiar a marca.
Peça estados, não só screenshot Uma tela real precisa sobreviver a loading, erro, vazio, hover, foco, mobile e conteúdo longo. Uma referência estática não resolve esses estados automaticamente.
Compare por critérios observáveis Depois de implementar, compare escala, ocupação de espaço, alinhamentos, contraste e comportamento. “Parece parecido” é um diagnóstico fraco; diferenças mensuráveis viram tarefas corrigíveis.
Extraia princípios, não pixels Uma referência visual é mais útil quando é decomposta em decisões: densidade, hierarquia tipográfica, largura de leitura, ritmo vertical, contraste, comportamento de menus, estados de foco e quantidade de informação por superfície. Copiar posições e componentes literalmente produz uma réplica frágil; entender o sistema permite manter a identidade do produto. Para cada referência, anote o que cria a sensação desejada e traduza isso para tokens e regras próprias. No Giorgio, por exemplo, Anthropic Serif pode assumir a voz editorial enquanto PPLX Sans mantém controles e navegação precisos.
A validação deve ser feita lado a lado em tamanhos de viewport equivalentes. Compare primeiro silhueta e proporções, depois tipografia, espaçamento e microinterações. Se a página só “parece igual” depois de muitos overrides locais, a abstração está errada: corrija o token ou o componente-base em vez de adicionar mais uma exceção.
Automação: quatro sinais de que ainda não é hora de automatizar 2026-09-04 Automatizar um processo instável apenas faz o erro acontecer mais rápido.
1 · A entrada não é previsível Se ninguém concorda sobre quais dados entram, a automação vai codificar uma interpretação escondida. Primeiro estabilize o contrato de entrada.
2 · O sucesso não pode ser medido “Fazer melhor” não é gate. Defina tempo, erro tolerável, cobertura, aprovação humana ou outro resultado observável antes de delegar o processo.
3 · Exceções dominam o fluxo Se metade dos casos exige negociação ou contexto não registrado, uma automação rígida cria fila de correções. Automatize primeiro o trecho estável e mantenha exceções explícitas.
4 · Não existe caminho de desfazer Ações irreversíveis pedem revisão, confirmação ou staging. Se um erro apaga, envia ou publica algo sem retorno, desenhe o mecanismo de recuperação antes da automação.
Automação precisa de um contrato operacional Automatizar cedo demais transforma incerteza em uma máquina que repete incerteza mais rápido. Antes de delegar uma rotina, verifique se a entrada é observável, se o resultado desejado pode ser testado e se existe uma forma segura de interromper ou reverter a ação. Processos que mudam toda semana, dependem de julgamento tácito ou possuem consequências caras ainda pedem execução assistida. Use o modelo para preparar, comparar e sugerir; mantenha a confirmação humana no ponto em que a ação passa a ter efeito externo.
O sinal de maturidade não é “a IA consegue fazer”, mas “conseguimos detectar quando ela não deveria fazer”. Métricas de erro, limites de autorização, logs de decisão e um caminho de fallback simples devem existir antes de aumentar autonomia. Só então vale remover confirmações manuais que deixaram de adicionar segurança real.
Conectores: o melhor contexto é o mínimo necessário para a tarefa 2026-09-04 Mais acesso não significa automaticamente uma resposta melhor.
Comece pela pergunta “Qual reunião mudou de horário?” pede eventos recentes, não todos os contatos e documentos. A pergunta define o menor conjunto de dados capaz de respondê-la.
Leitura e escrita são permissões diferentes Pesquisar uma agenda não implica autorização para cancelar um evento. Sempre trate observação e mutação como capacidades separadas.
Mostre de onde veio a decisão Quando a resposta depende de dados conectados, indique a mensagem, evento ou arquivo relevante. Isso permite auditoria sem despejar conteúdo desnecessário.
Revogue sem quebrar o produto Um conector desconectado deve degradar de forma clara: explicar o que ficou indisponível e preservar o restante do trabalho. Permissão não deve virar dependência invisível.
Desenhe o conector pelo menor privilégio útil A pergunta correta não é “quais dados o conector consegue acessar?”, mas “qual é o menor conjunto de dados e ações necessário para concluir esta tarefa?”. Um conector de calendário que só precisa consultar disponibilidade não deveria receber, por conveniência, permissão para apagar eventos. O mesmo vale para Drive, e-mail, CRM e bancos de dados. Separe leitura, escrita e ações destrutivas; peça elevação de permissão apenas quando a intenção do usuário exigir. Isso reduz o raio de impacto de erros e também torna auditoria e explicação muito mais simples.
No runtime, registre qual conector foi usado, quais campos foram lidos e qual ação externa foi solicitada. Dados irrelevantes não devem ser copiados para prompts, memória ou logs apenas porque estavam disponíveis. O ganho é duplo: menos exposição e menos ruído contextual para o modelo.
Handoff entre pessoas e IA: preserve decisões, não ruído 2026-09-04 Um bom handoff permite continuar o trabalho sem reler a conversa inteira.
Estado atual antes da história Comece pelo que existe agora: versão, arquivos, decisão ativa, bloqueio e último resultado verificado. História entra apenas quando explica uma restrição.
Decisões com motivo curto Registre “escolhemos X porque Y”, não uma transcrição do debate inteiro. Se Y mudar, fica claro qual decisão precisa ser reaberta.
Evidência precisa ser reproduzível Inclua comando, arquivo, URL, teste ou dado que permita conferir o resultado. “Funcionou comigo” é memória; “teste X passou com saída Y” é evidência.
Próximo passo precisa caber em uma sessão Evite “terminar tudo”. Defina o próximo marco verificável. Isso reduz contexto, melhora estimativa e deixa claro quando o trabalho realmente avançou.
O que precisa sobreviver à troca de pessoa ou modelo Um bom handoff não é uma transcrição da sessão. Ele preserva o estado do trabalho: decisão tomada, motivo, evidência usada, restrições, pendências e o próximo ponto de verificação. Se outra pessoa ou outro modelo precisar reler vinte páginas para descobrir o que já foi decidido, o registro falhou. Prefira um resumo operacional curto ligado às fontes originais. Separe fatos de hipóteses e marque o que ainda depende de confirmação. Isso reduz retrabalho sem transformar o histórico inteiro em contexto permanente.
Também registre o que foi descartado quando isso evita repetir uma investigação cara. Não é necessário guardar cada tentativa, apenas as alternativas relevantes e o motivo de rejeição. Para projetos longos, um handoff útil deve ser atualizado quando uma decisão muda, em vez de ganhar uma nova camada contraditória. O objetivo é continuidade, não volume.
Thesis 2.1: o contexto virou um ledger de evidências, não um histórico infinito 2026-09-03 O runtime separa missão, restrições, evidência recente, contratos e estado de execução para reduzir context rot e preservar o que realmente governa a tarefa.
Missão e restrições ficam fixas O primeiro nível do ledger guarda o objetivo do usuário e regras que não podem ser “resumidas para fora”: formato de entrega, comportamento que deve ser preservado, limites de segurança, rotas públicas, compatibilidade e critérios de aceitação.
Evidência tem precedência sobre memória Logs, respostas HTTP, resultados de testes, conteúdo de arquivos e screenshots são classificados como evidência. Uma hipótese do modelo pode orientar a próxima verificação, mas não substitui um resultado observado.
Compaction não é amnésia Quando o contexto cresce, o runtime preserva decisões, invariantes, falhas abertas e o melhor artefato atual, enquanto remove repetição e raciocínio já consumido. O objetivo é manter continuidade sem carregar um diário inteiro a cada chamada.
Context reset é diferente de resumo Tarefas de muitas horas ou dias podem mudar de sessão. O handoff não tenta imitar toda a mente anterior; ele entrega estado verificável, próximos marcos, arquivos relevantes e riscos abertos para que uma sessão nova continue sem herdar entropia desnecessária.
Prefixos estáveis reduzem custo Políticas de runtime e contratos duráveis ficam em uma zona estável do prompt. Evidência nova entra depois. Além de melhorar legibilidade para o modelo, isso evita reconstruir instruções gigantes a cada etapa e favorece mecanismos de cache quando o provedor os suporta.
O ledger também registra dívida de evidência Uma resposta pode estar semanticamente convincente e ainda ter dívida alta: teste não executado, rota não aberta, screenshot não comparado, contrato de auth não confirmado. Essa dívida controla se o Thesis 2.1 deve encerrar, reparar ou gastar mais compute.
O resultado esperado A meta não é “lembrar tudo”. É manter acessível aquilo que ainda pode mudar a decisão. Em tarefas de código isso significa contratos e regressões; em design, referências e proporções; em pesquisa, fontes e recência; em long-run, checkpoint e estado de verificação.
Thesis 2.1: gastar compute onde a incerteza está, não em toda mensagem 2026-09-03 A arquitetura de test-time compute deixa de ser “Max = mais texto” e passa a decidir quando planejar, validar, reparar, comparar candidatos ou simplesmente parar.
Trajetória única por padrão Low e Medium priorizam uma geração direta. High adiciona verificação quando a tarefa possui risco material. Extra e Max liberam mais etapas, mas ainda obedecem a um orçamento de geração e avaliação.
Determinístico antes de probabilístico Parser, typecheck, build, testes, contratos de rota e validações estruturais são mais baratos e reproduzíveis que pedir a outro modelo para “achar bugs”. O juiz semântico entra quando o defeito exige interpretação, segurança, arquitetura ou qualidade de produto.
Dívida de evidência controla o próximo passo Cada falha observada aumenta dívida. Cada gate realmente limpo reduz dívida. O runtime não usa “sensação de qualidade” como sinal de parada; ele observa se ainda existem requisitos não cobertos, defeitos determinísticos ou verificações críticas indisponíveis.
Repair antes de resample Se um candidato está quase correto, a próxima chamada recebe o candidato e findings objetivos. Recomeçar do zero só faz sentido quando a arquitetura ou a composição inteira é o defeito. Isso reduz regressão e custo.
Divergência só quando há motivo Uma segunda solução independente é cara. Thesis 2.1 só abre um branch divergente quando há ambiguidade real, tarefa subjetiva difícil ou desacordo relevante entre avaliadores. Depois, um verificador listwise compara candidatos sob os mesmos critérios.
Quota também é um sinal de controle Se a janela de uso está perto do limite, o harness reduz branching e avaliações opcionais antes de sacrificar a geração principal. Em vez de falhar no meio de um ritual de auto-crítica, preserva compute para entregar algo completo.
Por que isso diferencia o Thesis 2.1 O diferencial não é declarar “raciocínio máximo”. É transformar custo em uma política: mais compute quando ele compra informação, menos compute quando o problema já está determinado por checks baratos.
Thesis 2.1 por horas ou dias: trabalho durável precisa sobreviver ao próprio processo 2026-09-03 Long-run não significa manter uma função aberta eternamente. Significa estado externo, checkpoints idempotentes, leases, retomada e handoff entre sessões independentes.
Sessões discretas, missão contínua Cada sessão recebe missão, checkpoint, melhor artefato atual, próximos marcos e falhas abertas. Ela não precisa carregar todas as mensagens anteriores para entender o que ainda falta.
Checkpoint antes do próximo salto A sequência correta é produzir, validar, persistir e só então agendar a continuação. Disparar a próxima etapa antes de salvar estado cria uma janela em que uma queda perde progresso ou duplica trabalho.
Leases impedem dois agentes de assumir o mesmo turno Uma atualização condicional do job funciona como lease. Se dois workers acordarem juntos, apenas um adquire a versão atual do estado. O outro deve sair sem produzir uma segunda resposta concorrente.
Falha transitória não é falha terminal Rate limit de provedor, timeout ou indisponibilidade temporária entram como estado pausado/retryable. Auth inválida, restrição da conta ou orçamento encerrado têm semântica diferente. Misturar essas classes é como transformar “tente depois” em “o projeto morreu”.
Initializer, builder e evaluator não fazem a mesma coisa O primeiro turno estabelece mapa de milestones e critérios. Turnos de builder executam o próximo pedaço verificável. Periodicamente, um evaluator-integration pass procura deriva, dívida de teste e incompatibilidades entre partes antes de continuar construindo.
Handoff factual, não diário de raciocínio O checkpoint carrega decisões e evidência necessária, não uma tentativa de serializar pensamento privado. Isso o torna menor, mais estável e mais útil para uma sessão nova.
Critério de término “Tempo acabou” não é conclusão. O job termina quando a entrega está completa e o melhor gate de verificação disponível passou, ou quando existe uma condição explícita de pausa/falha que pode ser mostrada ao usuário sem fingir sucesso.
Thesis 2.1 sobre GPT-OSS 120B: o MoE está no modelo; a inteligência extra está no harness 2026-09-03 117 bilhões de parâmetros totais não significam 117 bilhões ativos por token. O design do Thesis 2.1 parte dessa diferença e usa orquestração externa seletiva, não uma fantasia de “escolher experts” no JavaScript.
Sparsidade interna, seletividade externa O MoE economiza compute dentro da inferência. O harness economiza compute fora dela: decide quando buscar na web, abrir verificador de código, rodar análise visual, fazer preflight, reparar ou gerar um segundo candidato.
O contexto de 128k continua sendo escasso Um monorepo, histórico de chat, documentação, logs e screenshots podem ultrapassar 128k rapidamente. Por isso o runtime usa compilação de contexto e artifacts de handoff em vez de empilhar tudo até o attention map virar um depósito.
Esforço de raciocínio é uma alavanca real GPT-OSS foi pós-treinado para níveis de esforço. Thesis 2.1 usa isso junto com gates externos: Low/Medium não carregam o custo de Max, enquanto Extra/Max podem comprar mais planejamento e verificação quando o perfil da tarefa justifica.
Especialização sem trocar o foundation model Código, UI, PBR, arquitetura e pesquisa recebem políticas, ferramentas e critérios diferentes, mas o gerador primário continua sendo o mesmo foundation model. Isso evita uma identidade em que “Thesis 2.1” vira apenas um nome sobre modelos diferentes a cada rota.
Verificação é um sistema separado O gerador não deve dar a nota para o próprio trabalho e encerrar. Thesis 2.1 usa checks determinísticos e, quando necessário, avaliadores independentes. Se um verificador estiver indisponível, isso vira estado de qualidade degradada em vez de um “passou” inventado.
Mais agentes não significa automaticamente mais inteligência Times paralelos podem expandir busca, mas também multiplicam custo, conflito e integração. Thesis 2.1 prefere uma trajetória, repair e branching condicionado a desacordo. Paralelismo vira ferramenta excepcional, não decoração arquitetural.
O que o harness pode e não pode fazer Harness engineering pode melhorar enormemente desempenho efetivo, consistência e custo. Ele não transforma magicamente 5,1B parâmetros ativos em outro foundation model. O ganho vem de contexto melhor, ferramentas melhores, compute melhor alocado e critérios de saída mais fortes.
Thesis 2.1 v3: mais rigor onde o trabalho realmente quebra 2 de setembro de 2026 Visual, 3D, PBR, arquitetura e refinamento agora têm gates próprios em vez de compartilhar um único botão de “pensar mais”.
Compute progressivo Low e Medium permanecem diretos; High só escala quando os sinais do domínio justificam; Extra e Max podem acionar frontier validation e targeted repair.
menos custo em tarefas simples mais rigor em fronteiras difíceis Repair seletivo Uma nova tentativa não vence por recência. Ela precisa preservar comportamento verificado e elevar a evidência; caso contrário, o checkpoint anterior continua sendo a melhor versão.
Classificação por domínio antes do compute O runtime distingue código, UI, 3D, PBR, arquitetura, pesquisa e risco operacional antes de montar o harness. A especialização acontece nas políticas e verificadores, não trocando silenciosamente de foundation model.
Anti-AI-slop como rubric observável Em UI, “parece IA” é decomposto em padrões verificáveis: grids de cards com peso igual, excesso de pills, glass gratuito, hierarquia rasa, tipografia sem papéis, controles decorativos e spacing que não comunica estrutura.
Código: reachability antes de elegância Uma solução que não inicia perde antes de qualquer debate arquitetural. O gate de código prioriza boot, sintaxe, contratos, segunda execução, cleanup, auth e persistência antes de aceitar refactors “bonitos”.
3D e PBR: coerência física e orçamento GPU Materiais, luz, câmera, color pipeline e performance são avaliados juntos. Um highlight “bonito” não compensa roughness incoerente, textura no espaço de cor errado ou cena que explode draw calls.
Arquitetura: ownership antes de abstração A revisão procura quem é dono do estado, onde existe durabilidade, quais chamadas são idempotentes, como retries e cancelamento funcionam e quais fronteiras de auth/autorização não podem ser atravessadas por conveniência.
Research: recência vira requisito Quando uma afirmação pode ter mudado, o harness marca necessidade de busca atual. Memória do modelo serve para enquadrar a pergunta; fonte primária recente serve para sustentar o fato.
Release gate: não basta uma resposta plausível O candidato final precisa reduzir dívida de evidência dentro do orçamento. Se o verificador necessário estiver indisponível ou existir falha material aberta, o estado deve dizer qualidade degradada em vez de fabricar certeza.
Thesis 2.1: coding visual com gerador, avaliador e checkpoint 2026-09-02 A nova disciplina do Thesis 2.1 separa criação, crítica e verificação para evitar que uma interface apenas “pareça pronta”.
O problema do one-shot Interfaces ambiciosas degradam quando um único passe tenta decidir arquitetura, estética, interação e QA ao mesmo tempo. O Thesis 2.1 passa a tratar essas responsabilidades como papéis distintos, mesmo quando executadas pelo mesmo runtime.
Gerador primeiro, avaliador depois O gerador recebe o briefing, o estado real do código e as referências visuais. O avaliador recebe a saída e um rubric explícito: coerência do conjunto, originalidade, acabamento e funcionalidade. A crítica não pode ser “ficou bonito”; precisa localizar diferenças observáveis.
Mundo visual, não decoração Para páginas cinematográficas, o prompt agora exige um modelo de mundo: fonte de luz, atmosfera, planos de profundidade, textura, silhueta principal, oclusão de primeiro plano e crop responsivo. Gradiente, blur e partículas entram apenas quando explicam esse mundo.
Screenshot como evidência Quando há navegador ou referência de imagem, o loop termina apenas depois de comparar screenshot, hierarquia, ocupação de espaço, ritmo tipográfico e estados. O melhor checkpoint é preservado para que uma iteração posterior não piore o que já estava resolvido.
Código real continua sendo o limite Nenhuma ambição visual autoriza quebrar contrato de rota, estado, acessibilidade ou performance. O avaliador visual trabalha junto da validação de sintaxe, runtime, responsividade e interação.
Por dentro de Poder de veto do avaliador O salto de qualidade acontece quando o avaliador pode rejeitar uma tela tecnicamente válida por composição ruim, hierarquia fraca, excesso de elementos ou interação incompleta. Thesis 2.1 preserva o melhor checkpoint aprovado e só promove uma nova versão quando ela melhora o conjunto, não apenas uma métrica isolada.
latência e custo compatíveis com a complexidade identidade pública do modelo preservada em fallback esforço extra só quando compra evidência Falha específica: Poder de veto do avaliador O risco é deixar generator e evaluator compartilharem o mesmo viés. Se ambos premiam volume de código, a revisão vira cerimônia e uma regressão visual pode parecer progresso.
Evidência que fecha Poder de veto do avaliador A prova forte combina execução, screenshot comparável, estados de interação e um checklist de critérios objetivos: foco, leitura, densidade, crop, contraste, responsividade e ausência de controles mortos.
Código de longa duração: checkpoints, handoffs e progresso que não se perde 2026-09-02 Projetos grandes não falham só por falta de inteligência; falham quando o agente perde o mapa do trabalho ao longo das iterações.
Decompor sem fragmentar O plano divide o trabalho em unidades verificáveis, mas mantém contratos entre elas. Cada unidade termina com estado do código, evidência obtida, riscos abertos e a próxima decisão, não apenas com uma lista de arquivos alterados.
Handoff é um artefato Quando contexto precisa ser compactado ou trocado, o handoff carrega objetivos, invariantes, decisões já tomadas, comandos de validação e falhas conhecidas. Isso reduz a tendência de reabrir decisões que já tinham sido resolvidas.
Checkpoint válido, não só recente O último estado não é automaticamente o melhor. O Thesis 2.1 mantém referência ao último checkpoint que passou pelos gates importantes e pode recuar para ele quando uma tentativa introduz regressão estrutural.
Paralelismo só com fronteiras claras Subagentes podem acelerar pesquisa, testes e revisão, mas não devem editar a mesma propriedade de estado sem coordenação. Trabalhos paralelos precisam de fronteiras de arquivos, contratos e critérios de merge.
Onde Checkpoint é estado validado, não timestamp realmente ganha qualidade Em tarefas longas, o checkpoint correto não é o arquivo mais recente, mas o último estado que passou pelos critérios relevantes. Isso permite explorar uma mudança agressiva sem transformar cada tentativa em dano cumulativo.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Checkpoint é estado validado, não timestamp Handoffs vagos fazem o próximo agente repetir investigação ou, pior, continuar uma hipótese já refutada. Um handoff útil registra estado, evidência, testes executados, riscos abertos e a próxima decisão concreta.
Evidência que fecha Checkpoint é estado validado, não timestamp O fluxo está saudável quando uma sessão pode ser interrompida e retomada sem reconstruir mentalmente o projeto inteiro, e quando a recuperação volta ao melhor candidato conhecido em vez de empilhar patches.
Refinar código sem transformar cada bug em uma reescrita 2 de setembro de 2026 O Thesis 2.1 v3 passa a tratar regressão, lifecycle e contratos adjacentes como parte do repair, não como dano colateral aceitável.
Evidência em camadas Syntax, typecheck, build, runtime, integration, E2E e visual review são classes distintas. O relatório deve dizer qual delas foi realmente executada.
Lifecycle primeiro Observers, timers, listeners, sockets e recursos GPU são revisados em reentrada porque grande parte dos bugs de interface só aparece na segunda navegação.
Baseline explícita antes do patch Antes de tocar no arquivo, o repair identifica qual comportamento já funciona e quais rotas, seletores, contratos e estados não pertencem ao bug. Sem baseline, qualquer “correção” pode apagar funcionalidade e ainda parecer limpa no diff.
Defeito local, impacto sistêmico Um erro em auth pode aparecer como UI congelada; um listener duplicado pode parecer bug de rede; CSS duplicado pode mascarar um problema de layout. O refinement busca defeitos diretamente acoplados antes de aumentar o escopo.
Segundo uso é parte do teste Muitos bugs só aparecem ao voltar para a rota, enviar uma segunda mensagem, reabrir o modal ou repetir a geração. Por isso reentrada, cleanup e idempotência fazem parte da verificação mínima.
O patch precisa ser monotônico Uma reparação só substitui o candidato anterior quando reduz falhas materiais sem abrir regressões maiores. “Mudou bastante” não é critério de melhoria; evidence debt menor é.
Quando reescrever é a decisão correta Rewrite deixa de ser tabu quando a arquitetura é o defeito: ownership impossível de corrigir localmente, contratos contraditórios, dependência circular ou camadas duplicadas que impedem qualquer patch confiável. A diferença é justificar a reescrita por invariantes quebrados, não por preferência estética.
PBR não é “material brilhante”: é um pipeline inteiro 2 de setembro de 2026 Metallic-roughness, microfacet BRDF, IBL, color management e budget de GPU precisam conversar entre si.
Material plausível Metais, dielétricos, roughness, normal maps e clearcoat têm semânticas físicas diferentes. A revisão procura coerência antes de procurar “efeito”.
Cor e ambiente Linear-light shading, saída sRGB, HDR/IBL, prefiltragem e tone mapping são parte do resultado. Se uma etapa está errada, compensar na próxima produz um look frágil.
BRDF e conservação de energia O specular precisa responder à geometria microscópica da superfície. GGX-class distribution, masking-shadowing e Fresnel não são nomes para enfeitar documentação; determinam como roughness, ângulo e índice de refração produzem highlights plausíveis.
Texturas têm semântica de canal Base color costuma entrar como sRGB; roughness, metallic, AO e normal são dados e não devem receber a mesma conversão. Um pipeline que trata todos os mapas como “imagem” pode parecer aceitável sob uma luz e quebrar sob outra.
Normal map depende de tangent space correto Tangent, bitangent, orientação UV e handedness precisam concordar. Costuras, iluminação invertida ou detalhe que muda ao rotacionar a câmera são sinais de um problema de base, não de “intensidade da normal”.
IBL precisa respeitar roughness Ambiente HDR não é só um background. Specular IBL precisa de prefilter por roughness e diffuse irradiance coerente; do contrário toda superfície reflete o mesmo nível de detalhe e o material perde escala visual.
Performance faz parte do material final DPR ilimitado, dezenas de materiais quase idênticos, textura 4K em todo objeto e shader variants descontroladas podem destruir a cena mais “realista”. Thesis 2.1 inclui draw calls, memória de textura, LOD, instancing e disposal no mesmo gate de qualidade.
Validação troca “parece real” por sinais A revisão pergunta se metais têm diffuse indevido, se dielétricos preservam F0 plausível, se exposição estoura highlights, se sombras têm bias incorreto e se roughness responde sob múltiplos ambientes. O objetivo é reduzir compensações frágeis.
Design de IA sem “vibes”: um loop de avaliação que consegue reprovar a própria tela 2026-09-02 Bom design agentico precisa de critérios que permitam dizer não à primeira versão e explicar por quê.
Quatro eixos de avaliação Coerência mede se a página funciona como um todo. Originalidade mede se existe uma ideia própria. Acabamento olha espaçamento, tipografia, detalhes e arte. Funcionalidade verifica se o que parece clicável realmente é clicável.
Referência não é decoração Uma screenshot de referência deve alterar composição, escala, densidade, hierarquia e comportamento. Copiar apenas cor e raio de borda produz semelhança superficial e perde o sistema que tornou a referência convincente.
A crítica precisa apontar uma correção “Mais polido” é inútil como instrução. “O hero perde 38% da altura sem informação, o CTA fica abaixo da dobra e a arte tem metade da escala da referência” vira uma tarefa executável.
O melhor estado vira checkpoint Depois de cada iteração, o sistema registra a melhor versão válida. Se uma tentativa posterior adiciona impacto visual mas quebra legibilidade ou interação, ela não substitui o checkpoint anterior.
A parte difícil de Rubrica visual que consegue dizer não Uma avaliação visual útil transforma “parece bom” em critérios observáveis: distribuição de massa, ritmo de espaços, escala tipográfica, continuidade de alinhamentos, contraste semântico, profundidade, acabamento e coerência entre breakpoints.
referência vira requisito de composição e comportamento visual é revisado depois de implementado estética nunca substitui estado funcional Falha específica: Rubrica visual que consegue dizer não O erro clássico é usar uma referência apenas como paleta. Isso preserva cores e destrói proporção, ocupação espacial, comportamento e hierarquia, justamente as partes que fazem a referência funcionar.
Evidência que fecha Rubrica visual que consegue dizer não O loop fecha quando cada crítica produz uma correção verificável e a nova captura é comparada com o checkpoint anterior. Se a nova versão piora leitura ou interação, ela não vira o novo baseline.
Giorgio Office: um contexto, oito superfícies de trabalho 2 de setembro de 2026 Ordo, Scriptum, Lumen, Nodus, Tabula, Forma, Convena e Acta dividem estado e agente sem virar um super-app indistinto.
Domínios claros Cada app possui ownership de estado e um conjunto de operações previsíveis. Isso é mais importante para integração do que imitar visualmente um pacote de escritório existente.
Setup nativo A versão 7.85 adiciona instaladores PE32+ em Go para Desktop, Code e Ordo, com UI própria, atalhos e desinstalação.
Ordo mantém a gramática de planilha Grid, endereços de célula, barra de fórmula, múltiplas folhas, referências e funções continuam visíveis. A camada agentica entra para transformar e explicar o workbook, não para esconder a planilha atrás de um chat.
Scriptum trabalha com estrutura de documento Títulos, parágrafos, tabelas e estilos são objetos manipuláveis. O agente pode reestruturar uma seção ou montar uma versão nova preservando o restante do documento, em vez de devolver texto solto sem formato.
Lumen separa narrativa de slide Conteúdo, ordem, speaker notes e tema não são a mesma camada. Isso permite ao Giorgio revisar a narrativa sem destruir layout e depois aplicar mudanças visuais de maneira controlada.
Nodus, Convena e Acta trabalham com continuidade Mensagens, decisões e tarefas podem carregar referências entre si. Uma conversa em Convena pode virar item de Acta; uma mensagem em Nodus pode alimentar um documento sem copiar manualmente todo o contexto.
Sync tem ownership e conflito explícitos Sincronizar não pode significar sobrescrever silenciosamente. Cada documento precisa de identidade, versão, dono, timestamp e estratégia para conflito. O agente só é confiável quando esse estado é observável e recuperável.
Giorgio Office e Ordo: documentos deixam de ser arquivos passivos 2026-09-02 A suíte Office do Giorgio combina interfaces familiares de produtividade com um agente capaz de operar entre planilha, texto, slides e agenda.
Ordo é a planilha Ordo trabalha com células, fórmulas, tabelas, filtros, importação CSV, exportação e cenários. A diferença está na camada agentica: o usuário pode pedir uma transformação em linguagem natural e ainda inspecionar as células alteradas.
Scriptum, Lumen e Nodus Scriptum cuida de documentos longos, estilos, comentários e revisão. Lumen transforma conteúdo em apresentações com layouts, notas e gráficos. Nodus reúne e-mail, calendário, tarefas e follow-ups. Todos compartilham o mesmo sistema de arquivos e contexto.
Sincronização como estado visível Sincronizar não deve ser um spinner misterioso. Cada arquivo mostra origem, última sincronização, conflitos, versão local e versão remota. O agente só automatiza depois que esse estado está claro.
Formatos importam A suíte foi pensada para trabalhar com CSV, XLSX, DOCX, PDF, PPTX e formatos web. Quando a exportação exata não estiver disponível, a interface deve dizer isso antes da edição e oferecer o formato preservável mais próximo.
O contrato escondido em Documentos que compartilham estado Ordo ganha valor quando a planilha deixa de terminar na célula. Uma seleção pode alimentar Scriptum, virar gráfico em Lumen, gerar follow-up no Nodus e continuar associada ao mesmo projeto e ao mesmo contexto do Giorgio.
controle visível produz efeito real estado persiste ou sincroniza quando prometido saída pode ser reutilizada fora da tela atual Falha específica: Documentos que compartilham estado O maior risco é sincronização sem modelo de propriedade: dois clientes editam a mesma versão, um sobrescreve o outro e o usuário vê “sincronizado” mesmo tendo perdido trabalho.
Evidência que fecha Documentos que compartilham estado O critério prático é simples: conteúdo local precisa sobreviver ao refresh; sync autenticado precisa recuperar o último estado; exportação precisa produzir um arquivo real; e o agente deve declarar qual documento está usando como contexto.
Thesis 1.6: raciocínio adaptativo para trabalho de precisão 2026-09-01 Como o runtime de precisão do Giorgio escala esforço, preflight e disciplina de código conforme a complexidade da tarefa.
O que muda em relação a uma rota rápida Thesis 1.6 é a rota de precisão do Giorgio para tarefas que exigem arquitetura, revisão ampla ou mudanças que atravessam vários arquivos. O objetivo não é produzir uma resposta maior, mas dedicar mais trabalho à localização do problema, ao plano e à verificação antes da entrega.
Nos níveis Extra e Max, o runtime adiciona uma etapa de preflight mais rígida antes da resposta final. Isso é especialmente útil quando uma alteração aparentemente simples pode causar regressões fora do arquivo tocado.
Quando usar Refactors de vários arquivos e mudanças de arquitetura. Falhas em que a causa raiz não está óbvia no primeiro log. Revisões em que regressão e compatibilidade importam mais que velocidade. O que ele não substitui Mais raciocínio não elimina a necessidade de evidência. Testes, terminal, preview, diffs e arquivos continuam sendo as fontes que confirmam se a mudança funciona no ambiente real.
O mecanismo central de Esforço proporcional à ambiguidade Thesis 1.6 continua útil como rota de precisão quando o problema é bem delimitado mas exige rastrear contratos, regressões e evidência antes de escrever. A adaptação deve responder à incerteza real, não ao tamanho superficial do prompt.
latência e custo compatíveis com a complexidade identidade pública do modelo preservada em fallback esforço extra só quando compra evidência Falha específica: Esforço proporcional à ambiguidade O risco é confundir “mais thinking” com “mais qualidade” e gastar orçamento em um problema que precisava apenas de inspeção correta do arquivo ou de uma chamada de ferramenta.
Evidência que fecha Esforço proporcional à ambiguidade A boa escolha reduz retrabalho: tarefas pequenas permanecem rápidas; mudanças com múltiplas fronteiras ganham preflight, validação e revisão independentes.
Critério de roteamento como gate Em “Thesis 1.6: raciocínio adaptativo para trabalho de precisão”, o ponto técnico que fecha a análise é tratar modelo, esforço e custo como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Melos: a rota de baixa latência para trabalho cotidiano 2026-09-01 Onde uma rota mais leve é melhor que gastar o maior orçamento de raciocínio em toda solicitação.
Velocidade também é parte da qualidade Melos é a rota rápida do Giorgio para trabalho diário, respostas criativas e alterações de código mais leves. Em tarefas pequenas, reduzir latência melhora o ciclo de pedir, revisar e corrigir sem sacrificar o controle do usuário.
Bom encaixe Perguntas diretas e tarefas com poucos passos. Ajustes pequenos de interface ou conteúdo. Primeira passada em trabalho que será revisado depois. Quando trocar de rota Se a tarefa cresce, começa a atravessar vários módulos ou exige diagnóstico de causa raiz, vale migrar para Thesis ou Thesis 1.6 em vez de insistir na rota rápida. A seleção de modelo é uma decisão de carga de trabalho, não uma competição de nomes.
A engenharia por trás de Latência baixa sem fingir profundidade Melos funciona melhor quando a tarefa tem baixa ambiguidade, poucas dependências e retorno fácil de verificar. O objetivo é chegar cedo a uma resposta útil sem acionar uma orquestração pesada que custaria mais do que o problema.
latência e custo compatíveis com a complexidade identidade pública do modelo preservada em fallback esforço extra só quando compra evidência Falha específica: Latência baixa sem fingir profundidade O perigo é promover Melos automaticamente em mudanças com autenticação, persistência ou contratos cruzados só porque o prompt parece curto.
Evidência que fecha Latência baixa sem fingir profundidade Um roteador saudável mede risco e dependências antes de velocidade. Se o trabalho ultrapassa o limite da rota rápida, a transição para Thesis deve ser explícita e preservar o contexto já observado.
Critério de roteamento como gate Em “Melos: a rota de baixa latência para trabalho cotidiano”, o ponto técnico que fecha a análise é tratar modelo, esforço e custo como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Escolher modelo pela carga de trabalho, não pelo hábito 2026-09-01 Uma regra prática para decidir entre velocidade, profundidade e custo de iteração dentro do Giorgio.
Comece pela tarefa Antes de escolher um modelo, pergunte quantos arquivos, dependências e etapas de verificação a tarefa envolve. Um pedido curto com resultado facilmente observável pede um perfil diferente de um refactor que precisa preservar contratos e evitar regressões.
Heurística simples Poucos passos e resultado óbvio: prefira a rota rápida. Múltiplos arquivos ou diagnóstico: aumente profundidade. Mudança crítica ou difícil de reverter: use revisão mais rigorosa. O melhor modelo é contextual Não existe ganho real em usar o maior orçamento para tudo. O ganho vem de combinar o nível de esforço com o risco e a complexidade do trabalho.
O ponto que decide Roteamento por risco, não por apego ao nome Escolher o modelo pela carga de trabalho significa olhar incerteza, necessidade de ferramentas, tamanho do grafo de dependências, reversibilidade e custo de uma resposta errada. O nome do modelo é consequência dessa leitura.
latência e custo compatíveis com a complexidade identidade pública do modelo preservada em fallback esforço extra só quando compra evidência Falha específica: Roteamento por risco, não por apego ao nome O anti-padrão é manter o mesmo modelo para tudo e compensar depois com prompts cada vez maiores, criando mais contexto e menos sinal.
Evidência que fecha Roteamento por risco, não por apego ao nome O critério de sucesso é uma política previsível: tarefa simples vai para rota rápida; tarefa longa ou arriscada ganha planejamento, ferramentas, revisão e orçamento compatíveis.
Critério de roteamento como gate Em “Escolher modelo pela carga de trabalho, não pelo hábito”, o ponto técnico que fecha a análise é tratar modelo, esforço e custo como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Revisão independente com Thesis e Melos antes de aceitar uma mudança 2026-08-31 Por que duas rotas com perfis diferentes podem encontrar falhas que uma única geração deixa passar.
Gerar e revisar são papéis diferentes No fluxo de código do Giorgio, o candidato pode ser submetido a uma revisão independente usando Thesis e Melos como avaliadores separados. A ideia é reduzir o viés de uma única trajetória de raciocínio antes de aceitar uma alteração.
O que a revisão procura Contrato quebrado entre arquivos ou módulos. Teste ou verificação ausente para um caminho crítico. Diagnóstico que não explica a evidência observada. Rejeitar também é resultado Se a revisão independente não encontra evidência suficiente para aceitar o candidato, o melhor comportamento é rejeitar e voltar ao diagnóstico. Um sistema confiável precisa saber parar, não apenas continuar produzindo patches.
Como Discordância é um recurso de qualidade deixa de ser só interface Revisão independente só acrescenta valor quando o segundo modelo recebe liberdade para discordar e critérios diferentes do gerador. Thesis pode atacar arquitetura e contratos enquanto Melos procura inconsistências simples, ausência de estados e comportamento que não fecha.
causa raiz vem antes do fallback mudança não quebra subsistemas fora do escopo logs e códigos permitem reproduzir a falha Falha específica: Discordância é um recurso de qualidade Se o revisor recebe a conclusão do gerador como verdade, a segunda passagem vira validação social automatizada.
Evidência que fecha Discordância é um recurso de qualidade Uma revisão boa produz findings acionáveis, classifica severidade e só força repair quando há defeito material. Discordância sem evidência não deve bloquear uma entrega válida.
Falha que esse desenho evita como gate Em “Revisão independente com Thesis e Melos antes de aceitar uma mudança”, o ponto técnico que fecha a análise é tratar ownership, recuperação e observabilidade como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Esforço de raciocínio é um orçamento, não um botão de qualidade 2026-08-31 Como Low, Medium, High, Extra e Max mudam a quantidade de trabalho interno sem substituir boas evidências.
Mais esforço tem custo Aumentar o esforço permite que a sessão dedique mais tempo a planejamento, comparação de hipóteses e verificação. Isso é útil em tarefas difíceis, mas pode ser desperdício quando o resultado é simples de observar e corrigir.
Quando subir Há muitas dependências e o erro pode estar longe do sintoma. A tarefa exige várias etapas de planejamento e revisão. Uma regressão teria custo alto ou seria difícil de detectar. Quando não subir Para alterações pequenas, use o menor nível que ainda produz qualidade suficiente. O objetivo é eficiência proporcional, não maximizar esforço por reflexo.
Por dentro de Orçamento deve comprar redução de incerteza Esforço de raciocínio é útil quando cada etapa adicional compra alguma coisa: mais inspeção, comparação de hipóteses, chamada de ferramenta, teste, revisão ou síntese de evidência. Pensar mais sem novos sinais apenas alonga a resposta.
latência e custo compatíveis com a complexidade identidade pública do modelo preservada em fallback esforço extra só quando compra evidência Falha específica: Orçamento deve comprar redução de incerteza O risco de um botão Max mal desenhado é transformar custo em ritual e dar ao usuário a impressão de que respostas curtas são deliberadamente piores.
Evidência que fecha Orçamento deve comprar redução de incerteza O sistema ideal mostra esforço como estratégia: Low para tarefas triviais, níveis maiores para risco e complexidade, e possibilidade de encerrar cedo quando a evidência já fechou a questão.
Critério de roteamento como gate Em “Esforço de raciocínio é um orçamento, não um botão de qualidade”, o ponto técnico que fecha a análise é tratar modelo, esforço e custo como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Contrato de contexto: separar o observado do inferido no Code 2026-08-30 Um fluxo de engenharia fica mais auditável quando arquivo observado, hipótese, mudança proposta e verificação têm estados diferentes.
Por que rotular evidência Durante uma investigação de código, fatos observados em arquivos não devem receber o mesmo peso que uma hipótese de causa raiz. O Giorgio mantém estados como observado em arquivos, inferido, mudança proposta, verificado por execução e não executado.
O benefício na revisão Evita apresentar hipótese como fato. Mostra claramente o que foi ou não executado. Facilita retomar a sessão sem reconstruir toda a investigação. Contrato não é excesso de burocracia O objetivo é tornar as decisões legíveis. Em tarefas simples, o contrato pode ser curto; em tarefas críticas, ele funciona como trilha para entender por que uma mudança foi aceita.
A parte difícil de Estado observado não é hipótese O contrato de contexto impede que uma suposição ganhe o mesmo peso de um arquivo lido ou de um teste executado. Marcar observado, inferido, proposto, verificado e não executado reduz um dos erros mais caros em agentes de código: continuar a partir de fatos inventados.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Estado observado não é hipótese O risco aparece quando resumos comprimem demais e apagam a proveniência. Uma frase curta como “auth está quebrado” não diz se isso veio do runtime, de um print ou de uma hipótese.
Evidência que fecha Estado observado não é hipótese A evidência boa mantém ligação entre claim, fonte e check. Ao retomar a sessão, o agente sabe o que pode reutilizar e o que precisa confirmar novamente.
Contrato de saída como gate Em “Contrato de contexto: separar o observado do inferido no Code”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Diagnóstico útil começa classificando a falha 2026-08-30 Timeout, indisponibilidade de modelo, teste quebrado e drift de contexto pedem respostas diferentes.
Nem todo erro pede retry O runtime do Giorgio distingue falhas transitórias, falhas de implementação e perda de validade do contexto. Um timeout ou rate limit pode justificar retry; um teste quebrado pede reparo; drift de contexto pode exigir invalidar etapas construídas sobre uma base que mudou.
Classificações que mudam a ação MODEL_UNAVAILABLE, TIMEOUT e RATE_LIMIT: tratar como indisponibilidade transitória. TEST_FAILURE, SYNTAX_ERROR, TYPE_ERROR e RUNTIME_ERROR: reparar a implementação. BASE_DRIFT ou CONTEXT_DRIFT: revalidar o que dependia da base anterior. Uma mensagem de erro precisa orientar Mostrar apenas “não foi possível concluir” esconde a informação mais útil. O diagnóstico deveria dizer o tipo provável de falha, a evidência disponível e a próxima ação segura.
O contrato escondido em Falhas diferentes exigem recuperações diferentes Timeout, rate limit, erro de sintaxe, falha de teste, drift de base e violação de contrato podem produzir a mesma frase “não foi possível concluir”, mas pedem respostas totalmente diferentes. Classificar cedo evita retries inúteis.
causa raiz vem antes do fallback mudança não quebra subsistemas fora do escopo logs e códigos permitem reproduzir a falha Falha específica: Falhas diferentes exigem recuperações diferentes O anti-padrão é tratar qualquer 5xx como motivo para repetir o mesmo request. Isso consome quota, mascara causa raiz e pode multiplicar efeitos colaterais.
Evidência que fecha Falhas diferentes exigem recuperações diferentes Um diagnóstico acionável informa classe, superfície afetada, se é retryable, qual evidência existe e qual próximo passo muda o estado do problema.
Falha que esse desenho evita como gate Em “Diagnóstico útil começa classificando a falha”, o ponto técnico que fecha a análise é tratar ownership, recuperação e observabilidade como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Quando um modelo fica indisponível, a interface precisa explicar 2026-08-30 Estados explícitos de disponibilidade evitam que falhas de provedor pareçam erro do usuário ou do prompt.
Falha sem contexto é falha de UX Se o envio falha porque a rota escolhida está temporariamente indisponível, a pessoa precisa saber que o problema não está no conteúdo enviado. Esconder esse estado gera tentativas repetidas e diagnóstico errado.
Informação mínima útil Qual modelo ou rota está afetado. Se o problema é temporário ou exige outra ação. Qual alternativa está disponível sem perder o trabalho atual. Fallback não deve ser invisível Trocar de rota pode ser útil, mas a interface deve manter a pessoa informada. Confiabilidade inclui saber qual sistema realmente executou a tarefa.
Onde Fallback precisa mudar de caminho de verdade realmente ganha qualidade Quando um modelo fica indisponível, o fallback deve usar outro provedor, outra rota ou outra estratégia. Tentar o mesmo endpoint com outro rótulo produz uma ilusão de resiliência e geralmente repete a falha original.
causa raiz vem antes do fallback mudança não quebra subsistemas fora do escopo logs e códigos permitem reproduzir a falha Falha específica: Fallback precisa mudar de caminho de verdade O risco é vazar mensagem crua do provedor, como crédito esgotado, e apresentá-la ao usuário como se fosse limite da própria conta Giorgio.
Evidência que fecha Fallback precisa mudar de caminho de verdade O comportamento correto diferencia limite do usuário, limite do provedor, indisponibilidade transitória e falha permanente; registra a troca e preserva a identidade pública do modelo selecionado.
Falha que esse desenho evita como gate Em “Quando um modelo fica indisponível, a interface precisa explicar”, o ponto técnico que fecha a análise é tratar ownership, recuperação e observabilidade como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Busca na web só quando a resposta depende do agora 2026-08-29 Uma política de freshness reduz respostas desatualizadas sem transformar toda pergunta em pesquisa externa.
Nem toda pergunta precisa de internet Perguntas históricas, conceitos estáveis e explicações baseadas em um arquivo fornecido não ganham qualidade automaticamente com uma busca. A pesquisa faz sentido quando preço, disponibilidade, notícia, documentação atual ou estado de um serviço pode ter mudado.
Gatilhos de freshness “Hoje”, “agora”, “último”, “atual” ou datas recentes. Serviços, modelos ou ferramentas com disponibilidade variável. Perguntas em que uma informação errada por desatualização mudaria a decisão. Pesquisar também exige síntese O resultado da busca não deveria ser uma pilha de links. A tarefa do sistema é separar fonte primária, contexto secundário e incerteza antes de responder.
Frescor é parte da resposta A web agrega valor quando o fato pode ter mudado: preços, disponibilidade, documentação viva, notícias, resultados, versões e políticas. Para conhecimento estável, buscar por reflexo adiciona latência e fontes desnecessárias. A decisão correta depende da volatilidade da informação.
O que precisa estar atualizado Em “Busca na web só quando a resposta depende do agora”, a ideia só vira valor quando aparece no fluxo real. Uma política de freshness reduz respostas desatualizadas sem transformar toda pergunta em pesquisa externa. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso O mecanismo central de Frescor precisa ser decidido antes da resposta A busca em tempo real não deve depender de o usuário escrever “pesquise”. Preço, versão, notícia, placar, disponibilidade, lei vigente e qualquer fato mutável precisam acionar recuperação atual antes da síntese.
fonte tem frescor compatível com a pergunta fallback mantém o mesmo tipo de intenção ausência de fonte atual é declarada Falha específica: Frescor precisa ser decidido antes da resposta O risco inverso é pesquisar tudo: latência sobe, fontes de baixa qualidade entram no contexto e perguntas históricas simples passam a depender de rede sem necessidade.
Evidência que fecha Frescor precisa ser decidido antes da resposta Uma boa política classifica mutabilidade, tenta fonte oficial ou especializada primeiro e deixa claro quando o resultado é atual, histórico ou não pôde ser verificado.
Arquivos antes de suposições 2026-08-29 Quando o usuário fornece um documento, o fluxo deve tratar o conteúdo real como evidência prioritária em vez de adivinhar pelo nome do arquivo.
O nome do arquivo não é o conteúdo Um sistema que vê apenas o título de um TXT, PDF ou documento tende a preencher lacunas com suposições. Em tarefas de análise, relatório ou estudo, isso é pior do que admitir que o conteúdo ainda não foi lido.
Fluxo correto Ler ou buscar no arquivo antes de responder. Usar o trecho relevante como evidência, não como decoração. Dizer quando o arquivo não contém suporte para uma conclusão. Menos alucinação começa na entrada Qualidade não depende só do modelo. Se a camada de entrada perde o conteúdo do arquivo, nenhum raciocínio posterior recupera a evidência que nunca chegou ao contexto.
O arquivo é a fonte primária Quando a tarefa depende de um documento, log, planilha ou código anexado, o conteúdo real deve vencer qualquer suposição baseada no nome do arquivo. Ler primeiro também evita respostas que parecem específicas, mas foram construídas apenas a partir do título ou de um trecho incompleto.
Evidência antes de inferência Em “Arquivos antes de suposições”, a ideia só vira valor quando aparece no fluxo real. Quando o usuário fornece um documento, o fluxo deve tratar o conteúdo real como evidência prioritária em vez de adivinhar pelo nome do arquivo. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso A engenharia por trás de O arquivo citado vira fonte primária Se a tarefa depende de um arquivo, o agente precisa ler esse arquivo antes de responder. Inferir conteúdo a partir do nome, de uma versão antiga ou de um trecho visto em outra conversa é exatamente o tipo de atalho que produz correções no documento errado.
o arquivo correto é lido antes da conclusão proveniência continua ligada à afirmação leitura cresce apenas quando a tarefa exige Falha específica: O arquivo citado vira fonte primária O problema fica pior em bases grandes, onde arquivos com nomes semelhantes coexistem e o contexto parcial pode parecer suficiente.
Evidência que fecha O arquivo citado vira fonte primária O fluxo confiável localiza o arquivo correto, lê apenas a faixa necessária, expande quando a resposta depende de seção maior e cita a evidência usada na conclusão.
Conectores: permissão explícita antes de conveniência 2026-08-28 Integrações ficam mais seguras quando a pessoa entende qual sistema está conectado, o que pode ser lido e o que pode ser alterado.
Conectar não significa liberar tudo Um conector deve deixar claro quais capacidades foram autorizadas. Buscar conteúdo, listar itens e executar uma ação de escrita têm níveis de consequência diferentes e não deveriam aparecer como se fossem a mesma coisa.
O que a interface precisa mostrar Serviço conectado e conta ou escopo relevante. Permissões de leitura e escrita separadas. Quando uma ação exige confirmação ou autorização adicional. Confiança vem de previsibilidade A melhor integração não é a que faz mais coisas escondida; é a que torna óbvio o que está prestes a acontecer e por quê.
A fronteira de permissão Em “Conectores: permissão explícita antes de conveniência”, a ideia só vira valor quando aparece no fluxo real. Integrações ficam mais seguras quando a pessoa entende qual sistema está conectado, o que pode ser lido e o que pode ser alterado. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso O ponto que decide Conector não equivale a autorização irrestrita Um conector útil combina descoberta, escopo e intenção. Ter acesso técnico ao serviço não significa que qualquer ferramenta possa ler, escrever ou compartilhar qualquer recurso sem uma ação compatível com o pedido.
menor privilégio por operação leitura e escrita ficam separadas conteúdo recuperado permanece dado não confiável Falha específica: Conector não equivale a autorização irrestrita O risco é misturar leitura e escrita, especialmente em ações com efeitos externos como e-mail, calendário, deploy ou alteração de dados.
Evidência que fecha Conector não equivale a autorização irrestrita O limite saudável preserva identidade, autorização e menor privilégio, registra exatamente qual operação foi executada e evita transformar contexto recuperado em instrução de sistema.
Chat temporário: quando o trabalho não precisa virar memória 2026-08-28 Separar contexto transitório de memória persistente reduz ruído e dá ao usuário mais controle sobre o que permanece.
Nem tudo merece persistir Uma conversa usada para testar uma ideia, revisar um texto pontual ou resolver um problema momentâneo pode não ter valor em sessões futuras. Tornar essa escolha explícita evita que a memória vire depósito de contexto irrelevante.
Use chat temporário quando O contexto é específico de uma tarefa única. Você está explorando opções que não devem influenciar sessões futuras. O valor do histórico termina quando a tarefa é concluída. Memória deve ser intencional Persistência útil nasce de seleção. Preferências, instruções duráveis e contexto de projeto podem merecer memória; rascunhos transitórios, não necessariamente.
Privacidade precisa ser previsível O usuário precisa saber quando uma conversa entra no histórico, quando memória pode ser usada e quando um fluxo é deliberadamente temporário. A regra útil é simples: retenção e reutilização de contexto devem ser explícitas, compreensíveis e reversíveis sempre que possível.
O ciclo de vida do dado Em “Chat temporário: quando o trabalho não precisa virar memória”, a ideia só vira valor quando aparece no fluxo real. Separar contexto transitório de memória persistente reduz ruído e dá ao usuário mais controle sobre o que permanece. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso Como Temporário precisa ter semântica de ciclo de vida deixa de ser só interface Chat temporário não é apenas um ícone diferente. Ele precisa evitar promoção automática para memória, deixar claro o que ainda pode existir por motivos técnicos e não misturar o conteúdo descartável com projetos persistentes.
ciclo de vida é previsível para o usuário memória e retenção não são confundidas mudanças de persistência são explícitas Falha específica: Temporário precisa ter semântica de ciclo de vida O risco é prometer desaparecimento absoluto enquanto anexos, logs ou artefatos continuam armazenados por outro subsistema.
Evidência que fecha Temporário precisa ter semântica de ciclo de vida A interface confiável separa conversa, memória, arquivos e telemetria; explica o que não será reutilizado e permite que o usuário escolha quando um dado temporário deve virar contexto durável.
Giorgio Design: do briefing ao QA de frontend 2026-08-27 A superfície de Design combina referência visual, preview executável, acessibilidade, responsividade e revisão antes da exportação.
Design não termina na imagem No Giorgio, a superfície de Design foi pensada para sair do briefing e chegar a uma experiência executável. Thesis e Melos continuam como motores técnicos, enquanto o protocolo de Design acrescenta direção visual, acessibilidade, responsividade e QA de frontend.
Etapas que importam Entender objetivo, público e restrições do briefing. Usar referência visual sem copiar estrutura cegamente. Renderizar, revisar responsividade e verificar acessibilidade antes de exportar. Preview é parte do processo Uma interface pode parecer correta no código e falhar quando renderizada. Por isso a etapa visual precisa ser tratada como verificação, não como decoração de fim de fluxo.
Design termina na verificação, não no mockup Uma direção visual só vira produto quando sobrevive a conteúdo real, estados vazios, teclado, telas estreitas, contraste e interação. O fluxo de Design deve aproximar briefing, implementação e QA para que a estética não esconda regressões funcionais.
Da intenção ao preview Em “Giorgio Design: do briefing ao QA de frontend”, a ideia só vira valor quando aparece no fluxo real. A superfície de Design combina referência visual, preview executável, acessibilidade, responsividade e revisão antes da exportação. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso Por dentro de QA visual começa no briefing Um briefing bom define objetivo, público, restrições, referência e estados obrigatórios. Isso permite avaliar o resultado depois por critérios concretos, em vez de decidir no final se a tela “tem cara boa”.
referência vira requisito de composição e comportamento visual é revisado depois de implementado estética nunca substitui estado funcional Falha específica: QA visual começa no briefing O risco é tratar preview como acabamento. Sem navegação, estados vazios, erro, teclado, mobile e exportação, um mockup polido continua sendo um produto incompleto.
Evidência que fecha QA visual começa no briefing O ciclo fecha quando o mesmo conjunto de requisitos acompanha direção visual, implementação, screenshot review e entrega do artefato final.
Recuperar autenticação sem perder o trabalho em andamento 2026-08-27 Sessões longas precisam distinguir expiração de credencial, falha de rede e erro de modelo antes de mandar o usuário de volta ao login.
Redirecionar para login não é diagnóstico Quando uma chamada recebe 401, o problema pode ser uma corrida de autorização ou um token que precisa ser renovado. Derrubar toda a sessão e voltar ao login transforma um erro recuperável em perda de contexto.
Ordem de recuperação Tentar renovar a autenticação quando a sessão ainda é válida. Preservar o prompt, arquivos e estado da tarefa durante o retry. Só pedir login novamente quando a recuperação realmente falhar. Confiabilidade é continuidade Para quem está trabalhando em uma tarefa longa, manter contexto e estado durante uma falha transitória vale mais do que esconder o erro com uma animação de carregamento.
A parte difícil de Renovar sessão não pode apagar estado local Uma corrida de refresh token pode acontecer no pior momento: depois que o usuário anexou arquivos ou enquanto uma resposta longa está sendo gerada. Recuperação de auth precisa distinguir credencial expirada de sessão terminal e preservar o trabalho ainda não enviado.
causa raiz vem antes do fallback mudança não quebra subsistemas fora do escopo logs e códigos permitem reproduzir a falha Falha específica: Renovar sessão não pode apagar estado local O perigo é “resolver” 401 redirecionando imediatamente para login e destruindo composer, anexos e estado do workspace.
Evidência que fecha Renovar sessão não pode apagar estado local O comportamento correto tenta recuperar sessão uma vez, bloqueia duplicação de refresh, repete somente a operação segura e restaura o contexto local se o login realmente for necessário.
Falha que esse desenho evita como gate Em “Recuperar autenticação sem perder o trabalho em andamento”, o ponto técnico que fecha a análise é tratar ownership, recuperação e observabilidade como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Preview e execução antes da entrega no Giorgio Code 2026-08-26 Código gerado só vira entrega quando existe uma forma observável de verificar o comportamento que mudou.
O código não é a evidência final Uma alteração pode compilar e ainda falhar visualmente, quebrar um fluxo ou produzir resultado incorreto. Terminal, preview e revisão de arquivos existem para transformar “parece certo” em evidência verificável.
Três verificações diferentes Terminal: testes, build e erros de execução. Preview: comportamento visual e interação. Revisão: diff, arquivos alterados e impacto fora do caso feliz. Entrega significa estado conhecido Quando algo não foi executado, isso deve ser dito. Quando foi verificado, a resposta deve indicar qual evidência sustentou a conclusão. Esse detalhe reduz falsa confiança sem atrasar o fluxo.
O contrato escondido em Preview é evidência de produto Para frontend, abrir o arquivo ou servidor e observar a tela acrescenta uma classe de evidência que parser nenhum oferece: overflow, crop, contraste, densidade, estado vazio, foco e interação real.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Preview é evidência de produto O risco é usar screenshot como prova de tudo. Uma imagem bonita não demonstra auth, persistência, API, acessibilidade ou comportamento em outros breakpoints.
Evidência que fecha Preview é evidência de produto A entrega forte combina preview visual com checks de runtime e contratos, e registra separadamente o que foi observado, executado e apenas inspecionado estaticamente.
Contrato de saída como gate Em “Preview e execução antes da entrega no Giorgio Code”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Sessões persistentes: por que o trabalho não deveria recomeçar do zero 2026-09-01 Como histórico, arquivos e decisões permanecem juntos para tarefas que levam mais de uma resposta.
Uma sessão é uma unidade de trabalho No Giorgio Code, uma sessão não é só um histórico de mensagens. Ela reúne a tarefa, os arquivos abertos, as decisões tomadas e os resultados que precisam ser revisados.
Isso reduz o custo de explicar novamente o contexto e torna retomadas mais previsíveis depois de uma pausa.
Quando separar Crie outra sessão quando o objetivo principal mudar. Mantenha a mesma sessão quando a nova solicitação for revisão, correção ou continuação direta. Use nomes claros para encontrar o trabalho depois. O ganho real Persistência não serve para acumular conversa infinita. Serve para preservar apenas o que torna a próxima decisão melhor.
Onde Sessão persistente é memória operacional realmente ganha qualidade Uma boa sessão preserva decisões, arquivos, estado do workspace e evidência suficiente para continuar sem reconstruir o problema do zero. Isso é diferente de simplesmente armazenar um transcript infinito.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Sessão persistente é memória operacional O risco é carregar contexto demais e transformar continuidade em ruído. Histórico irrelevante pode competir com o estado atual e reforçar decisões obsoletas.
Evidência que fecha Sessão persistente é memória operacional O sistema precisa resumir, indexar e recuperar por relevância, mantendo checkpoints e artefatos como fontes mais fortes do que conversa antiga.
Contrato de saída como gate Em “Sessões persistentes: por que o trabalho não deveria recomeçar do zero”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Previews que fazem parte da revisão 2026-08-31 Por que visualizar HTML, imagens e artefatos ao lado da tarefa é melhor do que tratar preview como decoração.
Resultado visível Um preview útil responde a uma pergunta simples: o resultado entregue realmente parece e se comporta como deveria?
No fluxo de Code e Artefatos, abrir o resultado no mesmo contexto reduz o salto entre geração e validação.
O que revisar Hierarquia, espaçamento e responsividade. Estados vazios, erros e ações principais. Se o arquivo final corresponde ao pedido, não apenas ao código gerado. Preview não substitui teste Ele torna falhas visuais e de fluxo mais fáceis de enxergar. Testes, terminal e revisão continuam sendo evidências complementares.
O mecanismo central de Preview precisa aceitar inspeção, não só aplauso Um preview revisável permite comparar versões, abrir DOM ou arquivo, checar comportamento e voltar ao ponto exato que produziu a regressão. O objetivo é transformar o visual em uma superfície de engenharia.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Preview precisa aceitar inspeção, não só aplauso O erro é usar preview como uma miniatura decorativa ou regenerá-lo sem preservar a versão anterior, eliminando a possibilidade de comparação.
Evidência que fecha Preview precisa aceitar inspeção, não só aplauso Quando a revisão aponta uma diferença, o agente deve localizar a causa no código, corrigir e reconstruir o preview, não apenas descrever o defeito.
Contrato de saída como gate Em “Previews que fazem parte da revisão”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Um blog público dentro do mesmo HTML 2026-08-30 Como separar conteúdo público e workspace privado sem duplicar o produto inteiro.
Duas experiências, uma entrada O mesmo arquivo pode hospedar rotas públicas e privadas desde que o roteamento identifique a intenção antes de iniciar a tela de autenticação.
Blog e documentação precisam abrir sem sessão; chat, projetos e ações de conta continuam protegidos.
O detalhe que evita flashes A rota pública deve ser reconhecida no head antes que a interface privada apareça. Depois, o runtime público assume a tela com um único renderer.
Regra de manutenção Uma única tabela de rotas públicas. Um único CSS autoritativo para Blog e Docs. Fallback por hash apenas quando o arquivo é aberto localmente. Uma superfície pública precisa funcionar sem contexto oculto Blog e documentação devem abrir por URL direta, permanecer legíveis sem sessão e expor estrutura suficiente para navegadores, buscadores e agentes. A experiência autenticada pode continuar privada; o conteúdo público não deveria depender dela para existir.
A engenharia por trás de Rota pública não pode depender do login privado Colocar Blog e app no mesmo HTML economiza distribuição, mas cria uma fronteira delicada: o router privado não pode capturar /blog e devolver /new, nem o bootstrap de auth pode esconder conteúdo público.
rota funciona em file:// e hospedagem primeiro render não depende de auth quando é público mobile e desktop preservam a mesma intenção Falha específica: Rota pública não pode depender do login privado O risco cresce em file://, onde hash routing e links normais se comportam de forma diferente do deploy web.
Evidência que fecha Rota pública não pode depender do login privado O contrato robusto reconhece rotas públicas antes do guard privado, intercepta navegação public-only em capture phase e oferece URLs legíveis para crawlers quando hospedado.
Documentação que descreve o produto que existe 2026-08-29 O que muda quando a documentação para de prometer superfícies que ainda não fazem parte do Giorgio.
A documentação também é interface Uma página bonita perde valor rapidamente se ensina um botão, integração ou fluxo que o usuário não consegue encontrar.
Por isso, a nova documentação parte do inventário real do HTML: chat, busca, arquivos, projetos, artefatos, Design, Cowork, memória, conectores, plugins e as superfícies reais do Code.
O que fica de fora Recursos planejados ou conceitos externos não entram como se fossem funcionalidade pronta. Quando algo não existe, o docs não tenta preencher o espaço com marketing.
Critério Existe no produto atual. É possível explicar sem inventar backend ou permissão. A instrução ajuda alguém a concluir uma tarefa real. Documentação é contrato de comportamento Uma página de documentação útil descreve o que existe agora, os limites conhecidos e o caminho verificável para concluir uma tarefa. Quando a documentação promete uma função que a interface não entrega, ela deixa de orientar e passa a criar erro.
O ponto que decide Documentação precisa envelhecer junto com o runtime Docs são perigosas quando descrevem uma capacidade que ainda não existe ou usam o nome de um modelo que o backend não retorna. A documentação deve nascer de contratos reais, não de roadmap imaginado.
controle visível produz efeito real estado persiste ou sincroniza quando prometido saída pode ser reutilizada fora da tela atual Falha específica: Documentação precisa envelhecer junto com o runtime O risco é copiar uma estrutura genérica entre dezenas de páginas e produzir volume sem utilidade operacional.
Evidência que fecha Documentação precisa envelhecer junto com o runtime Cada documento deve informar o que a função faz, entrada, saída, limites, estados de erro, relações com outras superfícies e uma forma de verificar o comportamento descrito.
Miniaturas de arquivo com menos ruído 2026-08-28 Por que reconhecer o tipo do arquivo é mais importante do que desenhar um pequeno diorama em cada card.
Informação antes de ornamento Uma miniatura precisa ajudar a responder “que arquivo é esse?” em menos de um segundo. Ícone, nome, extensão e estado resolvem a maior parte desse problema.
Onde o visual ainda ajuda Imagens podem mostrar uma miniatura real. Artefatos renderizados podem mostrar um recorte do resultado. Arquivos de código ganham mais com linguagem e status do que com decoração. Densidade controlada Cards menores deixam a conversa respirar e tornam listas longas mais escaneáveis sem esconder o que foi anexado.
Menos ruído, mais sinal Uma capacidade de produto deve reduzir o esforço necessário para entender o estado atual. Rótulos, miniaturas e ações funcionam melhor quando ajudam a decidir o próximo passo, não quando competem entre si por atenção.
O comportamento que importa Em “Miniaturas de arquivo com menos ruído”, a ideia só vira valor quando aparece no fluxo real. Por que reconhecer o tipo do arquivo é mais importante do que desenhar um pequeno diorama em cada card. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso Como Miniatura é estado do composer deixa de ser só interface Uma miniatura boa confirma qual arquivo foi anexado sem transformar o composer em galeria. Imagens precisam de preview; documentos precisam de tipo, nome e ação de remover; tudo precisa sobreviver ao layout compacto.
controle visível produz efeito real estado persiste ou sincroniza quando prometido saída pode ser reutilizada fora da tela atual Falha específica: Miniatura é estado do composer O risco é gerar URL temporária sem revogar, duplicar o mesmo arquivo ou deixar anexos visualmente fora da caixa de mensagem.
Evidência que fecha Miniatura é estado do composer O comportamento correto limita tamanho e quantidade, mostra feedback imediato, permite remoção e entrega os mesmos objetos ao pipeline que o botão de anexar usaria.
Conectores com contexto e permissão explícitos 2026-08-27 O papel de um conector fica mais claro quando a interface explica o que ele disponibiliza e quando ele será usado.
Conectar não deveria ser mágico O usuário precisa saber qual serviço está sendo conectado, qual acesso foi solicitado e como desconectar depois.
Uma sequência previsível Escolher o conector. Revisar a finalidade e permissões. Concluir a autorização e confirmar o estado conectado. Desconectar quando a integração não for mais necessária. Contexto ainda importa Mesmo com um conector ativo, o pedido precisa indicar qual informação é relevante. Conexão não é sinônimo de contexto infinito.
Conectar não significa liberar tudo Um conector bom reduz trabalho sem apagar fronteiras. A sessão deve acessar apenas o serviço, a conta e o escopo necessários para a tarefa, e a interface precisa deixar claro quando uma ação apenas lê dados ou quando pode modificá-los.
A fronteira de permissão Em “Conectores com contexto e permissão explícitos”, a ideia só vira valor quando aparece no fluxo real. O papel de um conector fica mais claro quando a interface explica o que ele disponibiliza e quando ele será usado. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso Por dentro de Contexto recuperado continua sendo dado Conectores tornam o Giorgio mais útil quando trazem a menor quantidade de informação necessária para a tarefa e mantêm claro de onde ela veio. O conteúdo recuperado não deve ganhar autoridade de instrução só porque veio de uma conta conectada.
menor privilégio por operação leitura e escrita ficam separadas conteúdo recuperado permanece dado não confiável Falha específica: Contexto recuperado continua sendo dado O risco é um documento ou mensagem conter instruções maliciosas que tentem redefinir a ação do agente.
Evidência que fecha Contexto recuperado continua sendo dado O pipeline deve separar dados recuperados de autoridade, aplicar escopo por usuário e exigir uma operação explícita antes de qualquer escrita externa.
Chat temporário para trabalho que não precisa permanecer 2026-08-26 Quando uma conversa descartável é uma escolha melhor do que adicionar mais histórico à conta.
Nem toda conversa precisa virar histórico Perguntas rápidas, testes e tarefas isoladas podem ser mais fáceis de administrar em um chat temporário. O objetivo é reduzir bagunça, não esconder comportamento.
Quando usar Experimentos curtos. Perguntas que não precisam aparecer na lista de conversas. Tarefas sem relação com projetos ou memórias existentes. Quando não usar Se você pretende voltar ao trabalho, comparar versões ou manter instruções de projeto, uma conversa normal oferece continuidade melhor.
Privacidade precisa ser previsível O usuário precisa saber quando uma conversa entra no histórico, quando memória pode ser usada e quando um fluxo é deliberadamente temporário. A regra útil é simples: retenção e reutilização de contexto devem ser explícitas, compreensíveis e reversíveis sempre que possível.
O ciclo de vida do dado Em “Chat temporário para trabalho que não precisa permanecer”, a ideia só vira valor quando aparece no fluxo real. Quando uma conversa descartável é uma escolha melhor do que adicionar mais histórico à conta. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso A parte difícil de Descartável precisa parecer descartável em todo o fluxo Se a conversa é temporária, sidebar, memória, projetos e sugestões futuras não devem agir como se ela fosse mais uma sessão permanente. A semântica precisa atravessar armazenamento e interface.
ciclo de vida é previsível para o usuário memória e retenção não são confundidas mudanças de persistência são explícitas Falha específica: Descartável precisa parecer descartável em todo o fluxo O erro comum é apenas ocultar a conversa depois, mantendo os mesmos efeitos colaterais de memória durante a sessão.
Evidência que fecha Descartável precisa parecer descartável em todo o fluxo Uma implementação coerente bloqueia promoção automática, diferencia artefatos escolhidos para salvar e informa a transição se o usuário decidir tornar algo persistente.
Projetos como contexto persistente, não como pasta bonita 2026-08-25 O valor de um projeto aparece quando instruções, fontes e conversas trabalham juntas.
O projeto define um território Projetos reúnem materiais e instruções que pertencem ao mesmo objetivo. Isso ajuda o Giorgio a distinguir contexto durável de detalhes que só importavam numa mensagem.
Três camadas Instruções: como o trabalho deve ser conduzido. Fontes: materiais que sustentam as respostas. Conversas: decisões e iterações específicas. Menos repetição Quando o contexto persistente está bem organizado, cada novo chat dentro do projeto pode começar mais perto do problema real.
Contexto persistente precisa ter função Um projeto é útil quando reduz repetição: instruções, arquivos, decisões e conversas relevantes permanecem próximos da tarefa. Persistência sem organização só transfere o problema de “lembrar tudo” para “encontrar qualquer coisa”.
Persistência sem ruído Em “Projetos como contexto persistente, não como pasta bonita”, a ideia só vira valor quando aparece no fluxo real. O valor de um projeto aparece quando instruções, fontes e conversas trabalham juntas. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso O contrato escondido em Projeto é fronteira de contexto, não pasta Um projeto útil combina instruções, fontes, arquivos, conversas e decisões com uma identidade própria. Isso permite recuperar o contexto certo sem espalhar detalhes específicos para todas as conversas do usuário.
contexto específico não vaza entre projetos fontes e instruções mantêm origem retomada não exige reconstruir o histórico inteiro Falha específica: Projeto é fronteira de contexto, não pasta O risco é tratar tudo como memória global e contaminar respostas em projetos diferentes.
Evidência que fecha Projeto é fronteira de contexto, não pasta A recuperação deve preferir contexto do projeto ativo, usar preferências globais apenas quando realmente globais e registrar a origem de cada memória promovida.
Refletir: transformar atividade em leitura útil 2026-08-24 Gráficos só ajudam quando respondem perguntas sobre ritmo, horários e foco — não quando existem para preencher espaço.
Dados com uma pergunta por trás O painel Refletir fica mais útil quando cada visual responde algo concreto: em quais dias houve mais atividade, quais horários concentram uso e quais assuntos dominaram o período.
Menos pontos, mais tendência Linhas mostram evolução diária sem poluir cada valor. Barras ajudam a comparar dias da semana. Heatmaps funcionam melhor para horários recorrentes. O painel precisa carregar Um visual impecável sem acesso aos dados reais é só decoração. Por isso a renderização precisa acontecer dentro do mesmo runtime que conhece usuário, histórico e estado do aplicativo.
Métrica sem interpretação é só contagem Refletir funciona melhor quando transforma atividade bruta em perguntas úteis: onde o tempo foi gasto, quais tipos de tarefa se repetem, quando o fluxo desacelera e o que mudou ao longo do período. O gráfico é meio; a decisão continua sendo o fim.
Onde Atividade só é útil quando responde uma pergunta realmente ganha qualidade Gráficos de uso devem explicar ritmo, foco e mudança, não preencher espaço. Refletir funciona melhor quando transforma eventos em padrões legíveis e permite ao usuário ligar um insight ao período e às tarefas que o produziram.
métrica responde pergunta concreta inferência é separada do dado observado tempo e escopo da leitura ficam visíveis Falha específica: Atividade só é útil quando responde uma pergunta O risco é inferir produtividade, humor ou intenção a partir de contagens superficiais.
Evidência que fecha Atividade só é útil quando responde uma pergunta O produto precisa separar fato observado de interpretação, oferecer contexto temporal e evitar métricas que pareçam precisas sem base suficiente.
Login mobile que sobrevive ao teclado 2026-08-23 Viewport dinâmica, safe areas e inputs legíveis fazem mais diferença do que simplesmente diminuir o desktop.
Mobile é outra condição de uso No celular, metade da interface pode desaparecer quando o teclado abre. Um login responsivo de verdade acompanha a altura visual disponível em vez de confiar apenas em 100vh.
O que precisa caber Identidade da marca sem ocupar a tela inteira. Campos com pelo menos 16px para evitar zoom inesperado. Botão principal acessível mesmo com o teclado aberto. VisualViewport Quando disponível, a API visualViewport permite reagir à área realmente visível e reposicionar conteúdo sem depender de adivinhações por breakpoint.
Uma superfície pública precisa funcionar sem contexto oculto Blog e documentação devem abrir por URL direta, permanecer legíveis sem sessão e expor estrutura suficiente para navegadores, buscadores e agentes. A experiência autenticada pode continuar privada; o conteúdo público não deveria depender dela para existir.
O mecanismo central de O teclado é parte da geometria da tela Login mobile quebra quando a UI assume 100vh estável e o teclado reduz o viewport visual. O formulário precisa continuar acessível, com foco visível e botões fora de áreas cortadas.
rota funciona em file:// e hospedagem primeiro render não depende de auth quando é público mobile e desktop preservam a mesma intenção Falha específica: O teclado é parte da geometria da tela O risco é corrigir apenas um aparelho usando altura fixa ou translate manual, criando outro bug em orientação diferente.
Evidência que fecha O teclado é parte da geometria da tela A validação deve usar 100dvh/visualViewport quando apropriado, safe areas, scroll interno previsível e testes com teclado aberto, rotação e zoom de acessibilidade.
Do brief ao preview no Giorgio Design 2026-08-22 Como separar intenção, configuração visual e resultado renderizado sem transformar a ferramenta em um formulário infinito.
Comece pelo que precisa existir O brief concentra objetivo, público e restrições. A partir dele, tema, densidade e tamanho de dispositivo viram ajustes do mesmo resultado, não pedidos desconectados.
Três controles que mudam a leitura Dispositivo: desktop, tablet ou mobile. Tema: relação entre fundo, superfícies e contraste. Densidade: quanto conteúdo cabe antes de a interface cansar. Exportar depois de olhar O preview é onde inconsistências aparecem. Exportar HTML antes de olhar o resultado só acelera a entrega do erro.
Design termina na verificação, não no mockup Uma direção visual só vira produto quando sobrevive a conteúdo real, estados vazios, teclado, telas estreitas, contraste e interação. O fluxo de Design deve aproximar briefing, implementação e QA para que a estética não esconda regressões funcionais.
Da intenção ao preview Em “Do brief ao preview no Giorgio Design”, a ideia só vira valor quando aparece no fluxo real. Como separar intenção, configuração visual e resultado renderizado sem transformar a ferramenta em um formulário infinito. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso A engenharia por trás de Direção visual antes do CSS Antes de codar, Giorgio Design precisa escolher uma direção: sistema tipográfico, escala, composição, assinatura visual, materiais e regra de movimento. Isso evita que cada componente invente sua própria estética.
referência vira requisito de composição e comportamento visual é revisado depois de implementado estética nunca substitui estado funcional Falha específica: Direção visual antes do CSS O risco é iniciar pelo card, botão e gradiente padrão e descobrir tarde demais que a página não tem uma ideia central.
Evidência que fecha Direção visual antes do CSS O preview deve ser avaliado contra o brief e não contra o gosto do gerador, com correções que preservam funcionalidade e identidade.
Cowork: fontes, tarefa e saída no mesmo fluxo 2026-08-21 Um workspace colaborativo fica mais claro quando separa o que entra, o que precisa ser feito e o que foi produzido.
Entrada explícita Fontes e contexto ficam visíveis antes da execução. Isso ajuda a conferir se a tarefa está realmente apoiada no material correto.
Uma tarefa, várias saídas Texto ou resumo. Arquivo ou artefato. Próximas ações e itens de revisão. A fronteira útil Cowork não precisa esconder o processo nem despejar toda a implementação. Ele precisa mostrar fontes, tarefa, estado e resultado de forma que outra pessoa consiga continuar.
O trabalho precisa permanecer rastreável Cowork ganha valor quando fonte, pedido, transformação e entrega permanecem conectados. Isso reduz o custo de conferir de onde veio uma afirmação e facilita continuar o trabalho depois sem reconstruir o raciocínio a partir do zero.
O ponto que decide Cowork precisa transformar delegação em trabalho observável Uma tarefa delegada ganha confiança quando o usuário enxerga fontes, plano, progresso, decisões que exigem intervenção e o artefato final. O agente não deve desaparecer por minutos e voltar com uma caixa-preta.
trabalho delegado continua observável paralelismo respeita dependências handoff registra estado e decisão pendente Falha específica: Cowork precisa transformar delegação em trabalho observável O risco é paralelizar etapas que dependem umas das outras ou permitir que subagentes escrevam no mesmo estado sem coordenação.
Evidência que fecha Cowork precisa transformar delegação em trabalho observável Um bom orquestrador separa unidades independentes, faz handoffs estruturados e mantém um líder responsável por integrar e verificar o resultado.
Busca na web quando a resposta depende do agora 2026-08-20 Informação atual exige uma fonte atual; o desafio é pesquisar quando necessário sem transformar todo pedido em navegação.
Frescura é parte da pergunta Tabela, preço, notícia, versão de produto e disponibilidade podem mudar. Nesses casos, responder só com memória do modelo é assumir que o mundo parou.
Sinais de que vale pesquisar O usuário pede “agora”, “hoje”, “último” ou “atual”. O dado muda com frequência. Uma fonte pública verificável melhora a resposta. Pesquisar também tem limite Pedidos criativos, resumos de arquivos já fornecidos e conhecimento estável não precisam sofrer uma excursão pela internet só porque o botão existe.
Frescor é parte da resposta A web agrega valor quando o fato pode ter mudado: preços, disponibilidade, documentação viva, notícias, resultados, versões e políticas. Para conhecimento estável, buscar por reflexo adiciona latência e fontes desnecessárias. A decisão correta depende da volatilidade da informação.
O que precisa estar atualizado Em “Busca na web quando a resposta depende do agora”, a ideia só vira valor quando aparece no fluxo real. Informação atual exige uma fonte atual; o desafio é pesquisar quando necessário sem transformar todo pedido em navegação. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso Como Busca atual precisa de fallback heterogêneo deixa de ser só interface Uma busca robusta não depende de um único provedor. Se CSE retorna 403 ou outro serviço está sem quota, o sistema precisa poder recorrer a outra fonte de web aberta ou a um vertical apropriado sem inventar resultado.
fonte tem frescor compatível com a pergunta fallback mantém o mesmo tipo de intenção ausência de fonte atual é declarada Falha específica: Busca atual precisa de fallback heterogêneo O risco é cair de busca geral para fonte acadêmica e apresentar paper antigo como resposta a uma pergunta sobre “agora”.
Evidência que fecha Busca atual precisa de fallback heterogêneo O roteador deve preservar tipo de intenção, registrar frescor das fontes e falhar de forma explícita quando nenhuma fonte adequada responde.
Modelo, esforço e modo sem transformar o composer em painel de avião 2026-08-19 Controles avançados só ajudam quando a pessoa entende o efeito sem interromper o pedido que está escrevendo.
O composer continua sendo o centro Escolher modelo, esforço ou capacidade não deveria competir visualmente com escrever o pedido. Os controles ficam úteis quando são compactos, previsíveis e mostram estado atual.
Três perguntas Qual modelo está ativo? Quanto raciocínio a tarefa merece? Há uma capacidade específica, como busca ou código, necessária agora? Defaults importam A maioria dos pedidos deve funcionar sem configuração manual. Controles avançados são escape hatch, não pré-requisito para conversar.
Por dentro de Composer não é cockpit Modelo, esforço e modo precisam caber na decisão que o usuário realmente faz. Expor cada detalhe do runtime transforma o composer em painel de avião e aumenta erro de configuração.
latência e custo compatíveis com a complexidade identidade pública do modelo preservada em fallback esforço extra só quando compra evidência Falha específica: Composer não é cockpit O risco é esconder demais e impedir que usuários avançados controlem profundidade, ferramentas ou custo quando isso importa.
Evidência que fecha Composer não é cockpit A solução é progressive disclosure: default simples e adaptativo, com controles avançados próximos do modelo e explicações curtas sobre impacto real.
Critério de roteamento como gate Em “Modelo, esforço e modo sem transformar o composer em painel de avião”, o ponto técnico que fecha a análise é tratar modelo, esforço e custo como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Revisar antes de entregar 2026-08-18 O painel de revisão existe para transformar alterações em evidência: o que mudou, onde mudou e se algo ficou quebrado.
Mudança sem revisão é só confiança Uma resposta pode soar segura e ainda ter removido uma função, alterado um seletor errado ou deixado diagnóstico pendente. A revisão organiza o que precisa ser conferido antes de encerrar a sessão.
Evidências úteis Lista de arquivos alterados. Resumo do que foi feito. Diagnósticos, testes e mensagens relevantes do terminal. Encerrar com estado claro Uma boa entrega diz o que está pronto, o que foi validado e o que ainda merece atenção. Esse resumo é tão importante quanto o diff.
A parte difícil de Revisor deve procurar regressão fora do diff Uma mudança pequena pode quebrar rota, auth, i18n, tema ou persistência longe do arquivo editado. Revisão antes de entregar precisa rastrear contratos atingidos, não apenas reler as linhas novas.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Revisor deve procurar regressão fora do diff O risco é transformar review em lint textual e ignorar comportamento.
Evidência que fecha Revisor deve procurar regressão fora do diff O gate fecha com checks estáticos, execução quando disponível, inspeção de estados negativos e comparação com o último checkpoint que já funcionava.
Contrato de saída como gate Em “Revisar antes de entregar”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Terminal como evidência, não como teatro 2026-08-17 Comandos e logs têm valor quando respondem ao que precisa ser verificado, não quando apenas fazem a sessão parecer técnica.
Rodar com propósito Antes de executar, a pergunta deveria ser clara: estamos verificando sintaxe, build, teste, arquivo gerado ou comportamento?
Saída que interessa Código de saída e mensagem final. Erros com arquivo e linha quando disponíveis. Um resumo legível na conversa. Menos log, mais conclusão Despejar centenas de linhas não prova nada por si só. O terminal funciona melhor quando a sessão destaca o trecho que sustenta a decisão.
O contrato escondido em Terminal não prova o que não executou Comando, build e teste são evidência somente quando foram realmente executados e o resultado foi observado. Mostrar comandos bonitos ou um transcript fabricado é pior do que declarar que a verificação não estava disponível.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Terminal não prova o que não executou O risco é tratar “npm run build” como sinônimo de runtime correto ou usar exit code zero de um check parcial como garantia de produto.
Evidência que fecha Terminal não prova o que não executou O relatório deve nomear a classe da evidência: parser, lint, teste, build, startup, E2E, visual ou não executado.
Contrato de saída como gate Em “Terminal como evidência, não como teatro”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Code Web e app instalado: a mesma tarefa, limites diferentes 2026-08-16 O navegador é ótimo para acesso imediato; o app instalado ganha quando a tarefa depende mais do ambiente local.
Web primeiro quando faz sentido Abrir uma sessão, revisar arquivos e continuar um trabalho sem instalar nada é uma vantagem real. Para tarefas compatíveis com o sandbox do navegador, o Code Web reduz atrito.
Quando o instalado ajuda Acesso mais direto ao ambiente local. Fluxos de terminal e arquivos que dependem do sistema. Sessões de trabalho longas em uma superfície dedicada. A documentação precisa dizer a diferença Prometer paridade absoluta onde o navegador impõe limites só cria surpresa. A melhor orientação é mostrar a superfície adequada para cada tipo de tarefa.
Onde Mesmo projeto, capacidades diferentes realmente ganha qualidade Code Web e app instalado podem compartilhar modelo e workspace, mas não possuem as mesmas permissões de filesystem, processos, navegador local ou integração com sistema operacional.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Mesmo projeto, capacidades diferentes O risco é gerar instrução que só funciona no desktop e apresentá-la no Web como se o runtime pudesse executá-la.
Evidência que fecha Mesmo projeto, capacidades diferentes O agente precisa conhecer o execution target, escolher ferramentas compatíveis e oferecer handoff explícito quando a tarefa exige capacidade local.
Contrato de saída como gate Em “Code Web e app instalado: a mesma tarefa, limites diferentes”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Idioma certo antes do primeiro render 2026-08-15 Detectar depois que a página aparece causa flashes e mistura de idiomas; conteúdo público precisa decidir o idioma cedo.
Preferência explícita vem primeiro Se a pessoa escolheu um idioma nas configurações, essa escolha deve vencer o idioma do navegador. Sem escolha manual, navigator.languages oferece um bom ponto de partida.
Sem depender de login Blog e documentação abrem sem conta, então suas traduções também precisam existir localmente. O primeiro render não pode depender de uma sessão autenticada para traduzir texto.
Resultado esperado PT, EN, ES ou FR completos desde a primeira pintura. Troca manual persistida para a próxima visita. Sem pedaços antigos no idioma anterior. Uma superfície pública precisa funcionar sem contexto oculto Blog e documentação devem abrir por URL direta, permanecer legíveis sem sessão e expor estrutura suficiente para navegadores, buscadores e agentes. A experiência autenticada pode continuar privada; o conteúdo público não deveria depender dela para existir.
O mecanismo central de Idioma precisa existir antes da primeira pintura Se a detecção de idioma ocorre depois do render, o usuário vê flicker e componentes podem persistir texto na língua errada. O idioma é parte do estado inicial da aplicação.
rota funciona em file:// e hospedagem primeiro render não depende de auth quando é público mobile e desktop preservam a mesma intenção Falha específica: Idioma precisa existir antes da primeira pintura O risco cresce com strings geradas por patches tardios que não entram no mesmo catálogo de tradução.
Evidência que fecha Idioma precisa existir antes da primeira pintura O produto deve resolver locale antes de montar a superfície, usar uma função única de tradução e auditar qualquer objeto multilíngue para PT, EN, ES e FR.
Painel Supremo: poder administrativo precisa de hierarquia 2026-08-14 Controles de conta, avisos e restrições ficam mais seguros quando a interface separa ações rápidas de operações sensíveis.
Admin não é uma lista de botões Quando tudo tem o mesmo peso visual, uma ação destrutiva parece tão casual quanto atualizar a página. Um painel administrativo precisa deixar intenção, alvo e consequência legíveis antes do clique.
Separação útil Estado e diagnóstico. Avisos e comunicação. Restrições, duração e recursos. A autorização não mora no CSS Esconder uma aba para usuários comuns melhora a experiência, mas a autoridade final continua no backend. A interface pode orientar; a função segura decide.
Poder administrativo exige mais contexto Ações de alto impacto precisam mostrar alvo, consequência e estado atual antes da confirmação. Quanto maior o alcance de uma operação, menos aceitável é depender de um rótulo ambíguo ou de um botão visualmente idêntico a uma ação comum.
A engenharia por trás de Poder administrativo exige causalidade visível Painel Supremo lida com ações que podem banir, restaurar, alterar feature flags ou mexer em contas. Hierarquia visual precisa refletir risco e separar leitura, simulação e mutação.
ação destrutiva exige alvo e efeito claros preview não altera estado auditoria distingue leitura de mutação Falha específica: Poder administrativo exige causalidade visível O perigo é colocar ações destrutivas no mesmo peso de filtros ou previews, aumentando clique acidental e dificultando auditoria.
Evidência que fecha Poder administrativo exige causalidade visível Cada mutação deve mostrar alvo, efeito, duração, justificativa quando aplicável e retorno do backend; previews não podem alterar estado real.
Como limpar um HTML standalone sem arrancar a lógica junto 2026-08-13 Em um arquivo monolítico, ordem de CSS e scripts pode ser comportamento; limpeza segura começa por entender dependências.
“O último ganha” também é lógica Muitos patches acumulados deixam regras repetidas, mas apagar tudo que parece duplicado pode mudar a cascata que uma tela dependia para funcionar. Primeiro é preciso identificar qual camada realmente é autoritativa.
Uma limpeza segura Inventariar funções, IDs, estilos e rotas antes. Mover responsabilidade sem alterar ordem de execução. Validar JavaScript e comparar contagens depois. Comentários que ajudam alguém novo Um mapa do fonte e marcadores de responsabilidade valem mais do que comentários de versão espalhados. A equipe precisa saber onde mudar auth, chat, Code, Refletir e admin sem adivinhar.
O ponto que decide Em HTML monolítico, posição de patch é contrato Um único arquivo pode conter strings que parecem tags de fechamento. Fazer replace no primeiro </body> encontrado pode inserir CSS e JS dentro de template strings e destruir partes que não tinham relação com a mudança.
causa raiz vem antes do fallback mudança não quebra subsistemas fora do escopo logs e códigos permitem reproduzir a falha Falha específica: Em HTML monolítico, posição de patch é contrato O risco é particularmente cruel porque o parser pode continuar carregando parte da página e fazer o bug parecer visual.
Evidência que fecha Em HTML monolítico, posição de patch é contrato A manutenção segura usa marcadores únicos, `rfind` para o fechamento real, valida todos os scripts executáveis e compara subsistemas não relacionados quando a alteração deveria ser isolada.
Falha que esse desenho evita como gate Em “Como limpar um HTML standalone sem arrancar a lógica junto”, o ponto técnico que fecha a análise é tratar ownership, recuperação e observabilidade como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Artefatos como entrega, não como anexo perdido 2026-08-12 Um artefato útil mantém nome, tipo, preview e ação próximos do contexto que o gerou.
A conversa explica o porquê O arquivo sozinho diz pouco sobre escolhas e restrições. Quando o artefato continua ligado à mensagem que o produziu, revisão e edição ganham contexto.
O card precisa responder O que é? Posso abrir ou baixar? Há uma prévia útil? De onde veio? Entrega melhor Essa estrutura deixa o artefato funcionar como resultado verificável em vez de mais um item numa lista de downloads.
Entrega precisa sobreviver à conversa Um artefato útil pode ser aberto, revisado, compartilhado e retomado sem depender de encontrar a mensagem exata que o gerou. Separar a entrega da conversa transforma uma resposta em algo que continua utilizável depois.
Como Artefato é fronteira de entrega deixa de ser só interface Um artefato útil tem nome, tipo, versão e relação clara com a tarefa que o produziu. Ele deve sobreviver à conversa e poder ser reaberto sem depender de lembrar qual mensagem continha o link.
arquivo é real e reabrível origem e validação ficam associadas handoff não depende do transcript Falha específica: Artefato é fronteira de entrega O risco é criar um arquivo correto e deixá-lo perdido como efeito colateral do chat.
Evidência que fecha Artefato é fronteira de entrega O handoff forte inclui preview quando faz sentido, download real, origem, estado de validação e possibilidade de continuar trabalhando a partir do mesmo objeto.
Memória visível e controlável 2026-08-11 Lembrar preferências só é útil quando a pessoa consegue entender o que foi guardado e remover o que não serve mais.
Memória não deveria ser surpresa Preferências duráveis podem reduzir repetição, mas só fazem sentido se o usuário souber que elas existem. A interface de Memórias serve para inspecionar e ajustar esse contexto.
O que vale lembrar Preferências de formato que se repetem. Contexto estável de projetos quando apropriado. Restrições que mudam respostas futuras de forma consistente. Controle inclui esquecer Uma memória antiga ou errada precisa poder ser removida. Persistência sem remoção não é personalização; é acúmulo.
Memória útil também precisa de limites Memória melhora continuidade quando o usuário consegue entender o que foi lembrado e corrigir o que não deveria continuar influenciando respostas. Persistência invisível pode economizar cliques, mas cobra o preço em previsibilidade.
O que merece permanecer Em “Memória visível e controlável”, a ideia só vira valor quando aparece no fluxo real. Lembrar preferências só é útil quando a pessoa consegue entender o que foi guardado e remover o que não serve mais. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso Por dentro de Memória precisa de provenance e controle Guardar tudo cria um modelo de usuário barulhento e potencialmente invasivo. Memória útil promove apenas informações duráveis e relevantes, com categoria, origem e possibilidade de remover ou corrigir.
promoção exige informação durável origem e confiança permanecem rastreáveis usuário pode remover ou corrigir Falha específica: Memória precisa de provenance e controle O risco é transformar inferência em fato pessoal ou reutilizar contexto de um projeto em outro.
Evidência que fecha Memória precisa de provenance e controle O sistema deve separar memória global de contexto de projeto, registrar confiança e usar a memória silenciosamente apenas quando ela realmente muda a resposta.
Plugins como capacidades reconhecíveis 2026-08-10 Catálogo, instalação e estado ficam mais úteis quando a interface explica o que cada plugin acrescenta ao trabalho.
Descoberta antes de instalação Um catálogo de plugins precisa ser navegável por categoria e intenção. A pessoa deveria entender em uma frase por que aquilo existe antes de decidir instalar.
Estados claros Disponível. Instalado. Configurado ou aguardando configuração, quando aplicável. Capacidade não é ruído Plugins devem ampliar o que o Giorgio consegue fazer sem transformar cada prompt em uma tela de configuração. Descoberta pode ser rica; uso precisa continuar simples.
Capacidades precisam ser legíveis Plugins funcionam melhor quando o usuário entende rapidamente o que cada integração pode ler, produzir ou alterar. Uma lista enorme de nomes sem contexto parece poderosa, mas transfere para o usuário o trabalho de descobrir a ferramenta certa.
Capacidade sem opacidade Em “Plugins como capacidades reconhecíveis”, a ideia só vira valor quando aparece no fluxo real. Catálogo, instalação e estado ficam mais úteis quando a interface explica o que cada plugin acrescenta ao trabalho. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso A parte difícil de Plugin deve parecer capacidade, não catálogo Uma lista enorme de plugins não ajuda se o usuário não entende quando cada um entra no fluxo. O produto precisa mapear capacidade, permissão, entrada e saída, e acionar ferramentas quando a tarefa pede.
capacidade tem ferramenta real por trás permissão é resolvida antes da ação resultado da ferramenta é observável Falha específica: Plugin deve parecer capacidade, não catálogo O risco é exibir dezenas de integrações “instaladas” sem ação real por trás ou deixar o modelo afirmar que usou uma ferramenta que nunca foi chamada.
Evidência que fecha Plugin deve parecer capacidade, não catálogo O contrato bom exige ferramenta invocável, resultado observável e fallback claro quando a integração não está disponível.
Anexos como evidência prioritária 2026-08-09 Quando um arquivo é fornecido, a melhor resposta começa lendo o material em vez de adivinhar pelo nome.
O arquivo muda a prioridade Se o pedido depende do conteúdo anexado, esse conteúdo deve ser a base. Conhecimento geral entra apenas para explicar, comparar ou ampliar quando o usuário pede.
Fluxo saudável Identificar o tipo do arquivo. Extrair ou ler o conteúdo disponível. Responder distinguindo o que veio do arquivo do que foi inferido. Miniatura não é leitura Mostrar um card bonito não significa que o conteúdo foi compreendido. O pipeline de anexos precisa alimentar de verdade a solicitação enviada ao modelo.
O arquivo é a fonte primária Quando a tarefa depende de um documento, log, planilha ou código anexado, o conteúdo real deve vencer qualquer suposição baseada no nome do arquivo. Ler primeiro também evita respostas que parecem específicas, mas foram construídas apenas a partir do título ou de um trecho incompleto.
Evidência antes de inferência Em “Anexos como evidência prioritária”, a ideia só vira valor quando aparece no fluxo real. Quando um arquivo é fornecido, a melhor resposta começa lendo o material em vez de adivinhar pelo nome. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso O contrato escondido em Anexo deve vencer contexto genérico Se o usuário envia um arquivo e pergunta sobre ele, esse conteúdo precisa ser a base da resposta. Conhecimento geral pode expandir ou comparar, mas não substituir silenciosamente o material enviado.
o arquivo correto é lido antes da conclusão proveniência continua ligada à afirmação leitura cresce apenas quando a tarefa exige Falha específica: Anexo deve vencer contexto genérico O risco é usar um snippet parcial e responder sobre seções que nunca foram lidas.
Evidência que fecha Anexo deve vencer contexto genérico O agente deve localizar a parte relevante, expandir leitura quando necessário e distinguir claramente o que vem do arquivo do que vem de pesquisa externa ou inferência.
Imagem como contexto, não só como decoração no prompt 2026-08-08 Uma entrada visual útil precisa chegar ao modelo junto com a pergunta e manter relação clara com a mensagem.
Ver antes de responder O usuário pode apontar para detalhe de uma captura, comparar imagens ou pedir leitura de um gráfico. Nesses casos, a imagem faz parte da evidência principal da pergunta.
A interface precisa manter a ligação Preview do anexo perto da mensagem. Estado claro de carregamento ou falha. Possibilidade de remover antes de enviar. Resposta ancorada Quando a pergunta depende da imagem, a resposta deve refletir o que realmente está visível e sinalizar limites quando algo não pode ser lido com segurança.
Imagem precisa entrar como evidência Quando uma captura, diagrama ou foto é relevante para a tarefa, a análise precisa partir do que está visível nela e não apenas do texto ao redor. O ganho real aparece quando a imagem muda o diagnóstico, a explicação ou a decisão.
O que a imagem realmente prova Em “Imagem como contexto, não só como decoração no prompt”, a ideia só vira valor quando aparece no fluxo real. Uma entrada visual útil precisa chegar ao modelo junto com a pergunta e manter relação clara com a mensagem. O teste final é simples: a pessoa entende o estado atual, sabe qual é o próximo passo e consegue confirmar se o resultado corresponde ao que pediu.
teste o caminho feliz e pelo menos um estado de falha mantenha feedback visível durante espera, fallback ou revisão encerre com evidência observável, não apenas com uma afirmação de sucesso Onde Imagem carrega layout, estado e evidência realmente ganha qualidade Uma screenshot não é só “uma imagem”: ela revela hierarquia, recorte, densidade, labels, estado de erro, relação entre painéis e muitas vezes a causa de uma regressão visual.
observação visual vira requisito verificável inferência não ultrapassa o que a imagem mostra crop e escala são avaliados por breakpoint Falha específica: Imagem carrega layout, estado e evidência O risco é descrever pixels sem conectar a observação ao comportamento pedido, ou inferir informação invisível na captura.
Evidência que fecha Imagem carrega layout, estado e evidência O uso correto transforma observações visuais em requisitos verificáveis e, em tarefas de UI, alimenta o loop de implementação e comparação.
Configurações sem virar depósito de recurso 2026-08-07 Agrupar conta, privacidade, capacidades, memórias e personalização por intenção reduz a sensação de painel infinito.
Uma configuração deve responder “por quê” A pessoa entra em Configurações para resolver algo: mudar aparência, administrar dados, controlar memória, revisar capacidades ou ajustar a conta. A arquitetura deve seguir essas intenções.
Progressive disclosure Opções avançadas podem existir sem ocupar a primeira tela. Mostrar primeiro o que é comum e aprofundar quando necessário mantém o painel legível.
Consistência Mesma linguagem de cards e divisórias. Descrições curtas para efeitos menos óbvios. Ações destrutivas separadas visualmente. Configuração boa aparece na hora certa Controles frequentes precisam ser fáceis de achar; opções raras podem ficar atrás de níveis mais profundos. Essa hierarquia evita transformar a tela de configurações em um inventário técnico onde tudo parece igualmente importante.
O mecanismo central de Configuração avançada precisa aparecer no momento certo Configurações acumulam opções de produto, modelo, privacidade e aparência. Sem hierarquia, o usuário precisa entender a arquitetura interna só para mudar uma preferência simples.
default simples primeiro opções avançadas aparecem sob demanda cada toggle persiste e altera comportamento Falha específica: Configuração avançada precisa aparecer no momento certo O risco é esconder opções importantes em submenus profundos ou deixar preferências que não alteram comportamento real.
Evidência que fecha Configuração avançada precisa aparecer no momento certo Progressive disclosure mantém defaults claros, agrupa por intenção e garante que cada controle tenha efeito persistente e reversível.
Code no celular sem fingir que 390px são 1440px 2026-08-06 Uma coluna por vez é mais útil do que esmagar sidebar, editor, terminal e conversa lado a lado.
A prioridade muda No desktop, múltiplos painéis podem coexistir. No celular, a mesma informação precisa virar navegação entre superfícies: sessão, arquivos, editor, terminal e preview.
Controles essenciais Botão de menu e retorno sempre alcançáveis. Composer fixado sem cobrir o conteúdo. Drawers em tela cheia para arquivos e editor. Responsivo não é miniatura Reduzir tudo proporcionalmente deixa texto, hitboxes e controles inúteis. O layout mobile precisa reorganizar responsabilidades, não apenas encolher pixels.
A engenharia por trás de Mobile exige outra composição, não miniaturização Um workspace de código com sidebar, árvore, editor, terminal e preview não cabe em 390px apenas reduzindo tudo. A interface precisa decidir qual superfície ocupa o foco e como o usuário troca entre elas.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Mobile exige outra composição, não miniaturização O risco é manter painéis simultâneos, targets pequenos e viewport fixo enquanto teclado e safe area mudam a geometria.
Evidência que fecha Mobile exige outra composição, não miniaturização O desenho robusto usa navegação por superfícies, preserva estado ao trocar de painel e testa edição, terminal e preview com teclado aberto.
Contrato de saída como gate Em “Code no celular sem fingir que 390px são 1440px”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Diagnósticos que alguém consegue usar 2026-08-05 Erro bom informa contexto, localização e próximo passo em vez de apenas dizer que “não foi possível”.
O erro é parte do produto Falhas de rede, modelo, arquivo e execução acontecem. O que diferencia uma experiência utilizável é se a mensagem ajuda a pessoa a decidir o que fazer depois.
Um diagnóstico útil contém Qual etapa falhou. Se há arquivo, comando ou recurso associado. Se tentar novamente faz sentido ou se outra ação é necessária. Mensagem genérica é último recurso “Tente novamente” serve quando realmente não há informação melhor. Se o runtime sabe o que falhou, esconder isso só torna suporte e depuração mais difíceis.
O ponto que decide Erro útil contém próxima ação Um diagnóstico acionável informa o que falhou, onde, em qual classe, se é recuperável e qual evidência sustenta essa classificação. “Não foi possível concluir” serve como último fallback, não como interface principal.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Erro útil contém próxima ação O risco é despejar stack trace ou mensagem do provedor sem tradução para o estado do produto.
Evidência que fecha Erro útil contém próxima ação O sistema deve mapear códigos técnicos para ações seguras e preservar detalhes suficientes para debug quando o usuário abre a camada avançada.
Contrato de saída como gate Em “Diagnósticos que alguém consegue usar”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Especialidades de Code sem lotar a interface 2026-08-04 Especialidade deve orientar o contexto e as prioridades da tarefa sem virar uma segunda linguagem de configuração.
Um atalho de intenção Quando a tarefa é claramente frontend, backend, revisão ou documentação, uma especialidade pode ajustar defaults e dar pistas ao agente sem exigir um prompt maior.
O chip precisa ser leve Mostrar a escolha atual. Permitir trocar ou remover rapidamente. Não competir com modelo, esforço e envio. O prompt ainda manda Especialidade é contexto auxiliar. O pedido explícito da pessoa continua definindo o resultado esperado e as restrições reais.
Como Especialidade deve entrar como contexto sob demanda deixa de ser só interface Frontend, backend, dados, 3D, documentos e mobile exigem critérios diferentes. A interface não precisa mostrar quinze toggles; o runtime pode detectar domínio e anexar a skill apropriada ao prompt de engenharia.
contratos entre arquivos e runtimes continuam alinhados cada estado de erro tem recuperação previsível verificação distingue parser, runtime e visual Falha específica: Especialidade deve entrar como contexto sob demanda O risco é ativar todas as skills ao mesmo tempo e aumentar contexto, conflito de regras e latência.
Evidência que fecha Especialidade deve entrar como contexto sob demanda Uma boa seleção usa sinais do pedido e da base, mantém poucas skills ativas e deixa a evidência do projeto superar heurística quando há conflito.
Contrato de saída como gate Em “Especialidades de Code sem lotar a interface”, o ponto técnico que fecha a análise é tratar código executável, regressão e evidência como parte do mesmo contrato. A implementação deixa de ser convincente quando uma dessas dimensões existe só no texto, mas não aparece no comportamento verificável do produto.
definir o estado esperado antes da ação observar o efeito real e registrar a evidência se o gate falhar, reparar a causa antes de ampliar o escopo Começamos o desenvolvimento do Melos 2 2026-09-02 A próxima geração da rota rápida do Giorgio começa com uma meta clara: menos latência e custo sem transformar velocidade em superficialidade.
Por que um Melos 2 Thesis 2.1 está sendo construído para tarefas em que contexto, verificação, ferramentas e execução prolongada justificam mais compute. Isso deixa um espaço importante para um modelo complementar: rápido o suficiente para permanecer no fluxo, mas disciplinado o bastante para não transformar toda tarefa curta em um chute.
Objetivos de arquitetura roteamento de ferramentas nativo e barato, com descoberta sob demanda em vez de carregar dezenas de schemas contexto compacto orientado à tarefa, preservando instrução, evidência recente e estado útil verificação seletiva: checks determinísticos primeiro; juiz de modelo só quando houver incerteza residual handoff limpo para Thesis 2.1 quando a tarefa deixa de ser rápida e passa a exigir profundidade O que não está sendo anunciado Melos 2 ainda está em desenvolvimento. Este artigo descreve direção e critérios, não um modelo já finalizado nem benchmarks que ainda não existem. O trabalho começa agora com avaliação de latência, qualidade curta, uso de ferramentas, coding leve e custo por tarefa concluída.
Como vamos medir progresso tempo até a primeira resposta útil, não apenas tokens por segundo taxa de tarefas resolvidas sem escalada desnecessária qualidade de tool use e recuperação quando uma ferramenta falha custo total por resultado aceito, incluindo reparos e verificações Relação com Thesis 2.1 A intenção não é criar dois modelos disputando o mesmo lugar. Melos 2 deve resolver com eficiência o que já está dentro de sua fronteira confiável; Thesis 2.1 assume quando o trabalho exige pesquisa iterativa, arquitetura, verificação independente, execução longa ou refinamento visual e técnico mais caro.
Fast path precisa saber quando sair do caminho Melos 2 não precisa vencer Thesis 2.1 em profundidade. Precisa reconhecer cedo quando uma tarefa deixou de ser barata: migração, auth, arquitetura, research mutável ou código com alto risco devem promover para uma rota mais profunda antes de gerar confiança falsa.
Métrica central: trabalho útil por segundo Latência só vale se a resposta evita retrabalho. O objetivo do Melos 2 é maximizar trabalho útil por segundo: contexto menor, tool routing barato, output objetivo e verificação curta quando existe risco real.
Docs Visão geral O Giorgio reúne conversa, pesquisa, arquivos, projetos, artefatos e workspaces especializados em uma interface única.
Como pensar no produto O chat é a entrada mais simples. A partir dele, arquivos, busca e artefatos entram quando a tarefa exige mais contexto ou uma entrega concreta.
Superfícies principais Como as superfícies se encaixam A visão geral funciona melhor quando você entende o produto como quatro superfícies ligadas: Chat para conversa, Projetos para contexto persistente, Docs para referência e Code para execução técnica.
Como isso entra no fluxo Use Visão geral como uma referência de operação, não como uma tela isolada. A própria proposta da página é: O Giorgio reúne conversa, pesquisa, arquivos, projetos, artefatos e workspaces especializados em uma interface única. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Visão geral o estado deixou de corresponder ao que a interface prometia.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Cenário real Comece por “Como pensar no produto”, confirme o estado visível e avance para “Superfícies principais” apenas quando a etapa anterior estiver estável. Em Visão geral, pular contexto costuma gerar mais retrabalho do que velocidade.
Onde costuma quebrar Imagine uma tarefa real em que Visão geral deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Visão geral realmente exigir mais contexto, controle ou verificação.
Critério de conclusão Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Visão geral o estado deixou de corresponder ao que a interface prometia.
Use Visão geral como uma referência de operação, não como uma tela isolada. A própria proposta da página é: O Giorgio reúne conversa, pesquisa, arquivos, projetos, artefatos e workspaces especializados em uma interface única. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Mapa operacional: Visão geral Nesta página, a referência completa cobre mapa das superfícies públicas, privadas e do fluxo principal. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Visão geral A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Acesso e login A tela de acesso separa conteúdo público de ações que dependem da sua conta.
Antes de entrar Blog, Giorgio Docs e Giorgio Code Docs podem ser abertos diretamente pela tela de login. Essas páginas não precisam de sessão autenticada.
Depois de entrar Sessão, recuperação e continuidade Login não é só uma porta de entrada. A sessão precisa sobreviver a refresh, expiração de token e troca de rota sem perder a conversa em andamento.
Antes de começar Imagine uma tarefa real em que Acesso e login deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Sequência recomendada Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Acesso e login o estado deixou de corresponder ao que a interface prometia.
Use Acesso e login como uma referência de operação, não como uma tela isolada. A própria proposta da página é: A tela de acesso separa conteúdo público de ações que dependem da sua conta. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Decisões que mudam o resultado Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Acesso e login, onde o contexto pode atravessar mais de uma etapa.
Comece por “Antes de entrar”, confirme o estado visível e avance para “Depois de entrar” apenas quando a etapa anterior estiver estável. Em Acesso e login, pular contexto costuma gerar mais retrabalho do que velocidade.
Como validar Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Acesso e login realmente exigir mais contexto, controle ou verificação.
Referência de produção: Acesso e login Nesta página, a referência completa cobre sessão, refresh, callbacks, recuperação e preservação do trabalho local. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Acesso e login A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Navegação A sidebar organiza trabalho recente e as principais superfícies sem duplicar funções.
Comece pelo destino Recolher sem perder acesso No desktop, a sidebar pode ser recolhida e reaberta pelo controle de painel. No mobile, ela funciona como drawer para não competir com o conteúdo.
Rotas que preservam contexto A navegação foi pensada para manter a tarefa viva enquanto você alterna entre conversa, projeto, artefato e documentação.
Leitura operacional Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Navegação, onde o contexto pode atravessar mais de uma etapa.
Comece por “Comece pelo destino”, confirme o estado visível e avance para “Recolher sem perder acesso” apenas quando a etapa anterior estiver estável. Em Navegação, pular contexto costuma gerar mais retrabalho do que velocidade.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Do primeiro clique à entrega Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Navegação realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Navegação deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Limites e exceções Use Navegação como uma referência de operação, não como uma tela isolada. A própria proposta da página é: A sidebar organiza trabalho recente e as principais superfícies sem duplicar funções. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Checklist de uso Comece por “Comece pelo destino”, confirme o estado visível e avance para “Recolher sem perder acesso” apenas quando a etapa anterior estiver estável. Em Navegação, pular contexto costuma gerar mais retrabalho do que velocidade.
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Navegação, onde o contexto pode atravessar mais de uma etapa.
Contrato desta superfície: Navegação Nesta página, a referência completa cobre rotas, deep links, histórico, páginas públicas e retorno ao app. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Navegação A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Chat O chat é a superfície padrão para perguntar, criar, revisar e transformar contexto em trabalho.
Composer A caixa de texto aceita o pedido principal e oferece anexos, microfone, seleção de modelo e capacidades de forma compacta.
Durante a geração Composer, streaming e continuidade O Chat deve aceitar um pedido simples sem configuração extra, mas também permitir anexos, mensagens enviadas durante geração e continuação de contexto.
O que merece atenção Use Chat como uma referência de operação, não como uma tela isolada. A própria proposta da página é: O chat é a superfície padrão para perguntar, criar, revisar e transformar contexto em trabalho. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Chat o estado deixou de corresponder ao que a interface prometia.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Um fluxo que funciona Comece por “Composer”, confirme o estado visível e avance para “Durante a geração” apenas quando a etapa anterior estiver estável. Em Chat, pular contexto costuma gerar mais retrabalho do que velocidade.
Quando mudar de estratégia Imagine uma tarefa real em que Chat deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Chat realmente exigir mais contexto, controle ou verificação.
Sinais de que terminou Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Chat o estado deixou de corresponder ao que a interface prometia.
Use Chat como uma referência de operação, não como uma tela isolada. A própria proposta da página é: O chat é a superfície padrão para perguntar, criar, revisar e transformar contexto em trabalho. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Leitura de engenharia: Chat Nesta página, a referência completa cobre composer, geração, anexos, modelos, estados de erro e continuidade. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Chat A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Chat temporário Use uma conversa temporária quando o trabalho não precisa entrar no histórico normal.
Indicado para Escolha uma conversa normal quando O trabalho depende de continuidade, comparação de versões ou contexto que você pretende reutilizar.
Quando não deixar rastro Chat temporário é útil para tarefas pontuais que não precisam alimentar histórico ou memória persistente.
Mapa da experiência Imagine uma tarefa real em que Chat temporário deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Aplicação prática Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Chat temporário o estado deixou de corresponder ao que a interface prometia.
Use Chat temporário como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Use uma conversa temporária quando o trabalho não precisa entrar no histórico normal. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Erros fáceis de evitar Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Chat temporário, onde o contexto pode atravessar mais de uma etapa.
Comece por “Indicado para”, confirme o estado visível e avance para “Escolha uma conversa normal quando” apenas quando a etapa anterior estiver estável. Em Chat temporário, pular contexto costuma gerar mais retrabalho do que velocidade.
Revisão final Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Chat temporário realmente exigir mais contexto, controle ou verificação.
Checklist de integração: Chat temporário Nesta página, a referência completa cobre retenção, memória, artefatos escolhidos e descarte previsível. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Chat temporário A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Busca na web Ative busca quando a resposta depende de informação pública atual ou verificável.
Quando ajuda Quando não é necessária Resumo de arquivos já enviados, escrita criativa e conhecimento estável geralmente não precisam abrir a web.
Frescura da informação e evidência A busca deve entrar quando a resposta depende do agora: preço, versão, notícia, disponibilidade, placar, lei vigente ou qualquer dado que possa ter mudado.
Ponto de partida Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Busca na web, onde o contexto pode atravessar mais de uma etapa.
Comece por “Quando ajuda”, confirme o estado visível e avance para “Quando não é necessária” apenas quando a etapa anterior estiver estável. Em Busca na web, pular contexto costuma gerar mais retrabalho do que velocidade.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Trabalho em camadas Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Busca na web realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Busca na web deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Diagnóstico rápido Use Busca na web como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Ative busca quando a resposta depende de informação pública atual ou verificável. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Próximo passo Comece por “Quando ajuda”, confirme o estado visível e avance para “Quando não é necessária” apenas quando a etapa anterior estiver estável. Em Busca na web, pular contexto costuma gerar mais retrabalho do que velocidade.
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Busca na web, onde o contexto pode atravessar mais de uma etapa.
Matriz de comportamento: Busca na web Nesta página, a referência completa cobre detecção de frescor, provedores, fallback, fontes e citações. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Busca na web A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Arquivos e anexos Anexos entram como evidência para a tarefa e permanecem ligados à mensagem que os enviou.
Antes de enviar Depois Arquivos gerados podem aparecer como artefatos com preview, nome e ação de abertura ou download.
Arquivo como fonte primária Quando um arquivo é anexado, o conteúdo dele deve ter prioridade sobre suposições genéricas. A tarefa começa pela leitura do material real.
Como pensar esta área Use Arquivos e anexos como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Anexos entram como evidência para a tarefa e permanecem ligados à mensagem que os enviou. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Arquivos e anexos o estado deixou de corresponder ao que a interface prometia.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Exemplo de uso Comece por “Antes de enviar”, confirme o estado visível e avance para “Depois” apenas quando a etapa anterior estiver estável. Em Arquivos e anexos, pular contexto costuma gerar mais retrabalho do que velocidade.
Quando não usar Imagine uma tarefa real em que Arquivos e anexos deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Arquivos e anexos realmente exigir mais contexto, controle ou verificação.
Verificação independente Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Arquivos e anexos o estado deixou de corresponder ao que a interface prometia.
Use Arquivos e anexos como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Anexos entram como evidência para a tarefa e permanecem ligados à mensagem que os enviou. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Guia de verificação: Arquivos e anexos Nesta página, a referência completa cobre seleção, drag-and-drop, miniaturas, limites e envio ao pipeline. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Arquivos e anexos A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Entrada de imagens Imagens podem acompanhar a mensagem para análise visual, comparação ou referência de design.
Dê uma pergunta à imagem Dizer o que você quer observar melhora a resposta: um detalhe, proporção, texto visível, erro de UI ou diferença entre duas capturas.
Limites visuais Se algo não estiver legível ou estiver fora da imagem, a resposta deve tratar isso como limite em vez de inventar o conteúdo ausente.
Imagem como contexto, não decoração Imagens entram como evidência visual: interface, gráfico, fotografia, documento ou erro de tela. O objetivo é extrair contexto útil para a tarefa.
Objetivo e contexto Imagine uma tarefa real em que Entrada de imagens deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Ordem das ações Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Entrada de imagens o estado deixou de corresponder ao que a interface prometia.
Use Entrada de imagens como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Imagens podem acompanhar a mensagem para análise visual, comparação ou referência de design. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Casos de borda Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Entrada de imagens, onde o contexto pode atravessar mais de uma etapa.
Comece por “Dê uma pergunta à imagem”, confirme o estado visível e avance para “Limites visuais” apenas quando a etapa anterior estiver estável. Em Entrada de imagens, pular contexto costuma gerar mais retrabalho do que velocidade.
Entrega sem surpresa Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Entrada de imagens realmente exigir mais contexto, controle ou verificação.
Detalhes que evitam regressão: Entrada de imagens Nesta página, a referência completa cobre preview, leitura visual, contexto multimodal e limites de inferência. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Entrada de imagens A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Projetos Projetos agrupam contexto persistente, fontes e conversas relacionadas ao mesmo trabalho.
Quando criar um projeto Organização Use nomes que descrevam o objetivo e mantenha dentro do projeto apenas materiais relacionados. Isso facilita busca, retomada e revisão.
Contexto persistente de verdade Projetos são o lugar para manter instruções, arquivos e conversas que pertencem ao mesmo objetivo. Eles valem quando o trabalho atravessa mais de uma sessão.
Da intenção ao resultado Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Projetos, onde o contexto pode atravessar mais de uma etapa.
Comece por “Quando criar um projeto”, confirme o estado visível e avance para “Organização” apenas quando a etapa anterior estiver estável. Em Projetos, pular contexto costuma gerar mais retrabalho do que velocidade.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Durante a execução Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Projetos realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Projetos deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Se algo sair do esperado Use Projetos como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Projetos agrupam contexto persistente, fontes e conversas relacionadas ao mesmo trabalho. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Fechamento do trabalho Comece por “Quando criar um projeto”, confirme o estado visível e avance para “Organização” apenas quando a etapa anterior estiver estável. Em Projetos, pular contexto costuma gerar mais retrabalho do que velocidade.
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Projetos, onde o contexto pode atravessar mais de uma etapa.
Mapa operacional: Projetos Nesta página, a referência completa cobre instruções, fontes, memórias de projeto e retomada de contexto. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Projetos A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Instruções do projeto Instruções do projeto definem regras duráveis para as conversas daquele contexto.
Boas instruções Conflitos O pedido atual pode trazer uma necessidade específica. Quando houver conflito, explicite qual instrução deve prevalecer em vez de depender de ambiguidade.
Hierarquia de instruções Instruções do projeto definem regras duráveis do trabalho, enquanto o prompt atual define o pedido específico daquela rodada.
O papel desta página Use Instruções do projeto como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Instruções do projeto definem regras duráveis para as conversas daquele contexto. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Instruções do projeto o estado deixou de corresponder ao que a interface prometia.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Uso no dia a dia Comece por “Boas instruções”, confirme o estado visível e avance para “Conflitos” apenas quando a etapa anterior estiver estável. Em Instruções do projeto, pular contexto costuma gerar mais retrabalho do que velocidade.
Armadilhas comuns Imagine uma tarefa real em que Instruções do projeto deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Instruções do projeto realmente exigir mais contexto, controle ou verificação.
Conferência antes de seguir Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Instruções do projeto o estado deixou de corresponder ao que a interface prometia.
Use Instruções do projeto como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Instruções do projeto definem regras duráveis para as conversas daquele contexto. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Referência de produção: Instruções do projeto Nesta página, a referência completa cobre precedência, escopo, versionamento e efeito nas respostas. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Instruções do projeto A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Artefatos Artefatos são resultados gerados que merecem ser abertos, revisados ou baixados como objetos próprios.
O que um card mostra Relação com a conversa O artefato continua ligado ao pedido que o produziu, preservando o contexto de por que aquele arquivo existe.
Artefato como handoff Um artefato bom é algo que outra pessoa consegue abrir, revisar e usar sem reconstruir o raciocínio que o gerou.
Primeira decisão Imagine uma tarefa real em que Artefatos deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Como manter o contexto Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Artefatos o estado deixou de corresponder ao que a interface prometia.
Use Artefatos como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Artefatos são resultados gerados que merecem ser abertos, revisados ou baixados como objetos próprios. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Falhas recuperáveis Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Artefatos, onde o contexto pode atravessar mais de uma etapa.
Comece por “O que um card mostra”, confirme o estado visível e avance para “Relação com a conversa” apenas quando a etapa anterior estiver estável. Em Artefatos, pular contexto costuma gerar mais retrabalho do que velocidade.
Resultado esperado Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Artefatos realmente exigir mais contexto, controle ou verificação.
Contrato desta superfície: Artefatos Nesta página, a referência completa cobre criação, preview, validação, download e reabertura. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Artefatos A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Giorgio Design Design transforma um brief em uma proposta visual que pode ser revisada em diferentes tamanhos e exportada.
Brief primeiro Descreva objetivo, público, conteúdo obrigatório e restrições. Esses elementos orientam a geração melhor do que uma lista vaga de adjetivos.
Revisão visual Do briefing ao QA Design transforma um briefing em direção visual, preview e revisão. A qualidade vem de combinar intenção estética com acessibilidade, responsividade e QA de frontend.
Visão prática Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Giorgio Design, onde o contexto pode atravessar mais de uma etapa.
Comece por “Brief primeiro”, confirme o estado visível e avance para “Revisão visual” apenas quando a etapa anterior estiver estável. Em Giorgio Design, pular contexto costuma gerar mais retrabalho do que velocidade.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Fluxo mínimo Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Giorgio Design realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Giorgio Design deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Escalando com segurança Use Giorgio Design como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Design transforma um brief em uma proposta visual que pode ser revisada em diferentes tamanhos e exportada. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Como saber que funcionou Comece por “Brief primeiro”, confirme o estado visível e avance para “Revisão visual” apenas quando a etapa anterior estiver estável. Em Giorgio Design, pular contexto costuma gerar mais retrabalho do que velocidade.
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Giorgio Design, onde o contexto pode atravessar mais de uma etapa.
Leitura de engenharia: Giorgio Design Nesta página, a referência completa cobre briefing, direções, preview, avaliação visual, responsividade e exportação. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Giorgio Design A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Giorgio Cowork Cowork organiza fontes, tarefa e saídas para trabalhos que precisam de contexto e entrega.
Estrutura do workspace Use quando O trabalho se beneficia de uma visão explícita do que entrou, do que está sendo feito e do que saiu.
Delegar sem perder controle Cowork é para tarefas em que o Giorgio pode avançar por etapas, reunir contexto e devolver um resultado revisável.
Como isso entra no fluxo Use Giorgio Cowork como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Cowork organiza fontes, tarefa e saídas para trabalhos que precisam de contexto e entrega. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Giorgio Cowork o estado deixou de corresponder ao que a interface prometia.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Cenário real Comece por “Estrutura do workspace”, confirme o estado visível e avance para “Use quando” apenas quando a etapa anterior estiver estável. Em Giorgio Cowork, pular contexto costuma gerar mais retrabalho do que velocidade.
Onde costuma quebrar Imagine uma tarefa real em que Giorgio Cowork deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Giorgio Cowork realmente exigir mais contexto, controle ou verificação.
Critério de conclusão Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Giorgio Cowork o estado deixou de corresponder ao que a interface prometia.
Use Giorgio Cowork como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Cowork organiza fontes, tarefa e saídas para trabalhos que precisam de contexto e entrega. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Checklist de integração: Giorgio Cowork Nesta página, a referência completa cobre delegação, fontes, plano, progresso, subagentes, handoffs e entrega. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Giorgio Cowork A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Memórias Memórias guardam contexto durável que pode melhorar respostas futuras e pode ser revisto nas configurações.
Bom candidato a memória Revise e remova Se uma memória ficou desatualizada ou deixou de ser útil, remova-a. A personalização funciona melhor quando o contexto persistente continua pequeno e correto.
Memória com provenance Memória útil precisa ser controlável e ter origem compreensível. Nem todo detalhe de uma conversa merece virar contexto durável.
Antes de começar Imagine uma tarefa real em que Memórias deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Sequência recomendada Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Memórias o estado deixou de corresponder ao que a interface prometia.
Use Memórias como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Memórias guardam contexto durável que pode melhorar respostas futuras e pode ser revisto nas configurações. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Decisões que mudam o resultado Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Memórias, onde o contexto pode atravessar mais de uma etapa.
Comece por “Bom candidato a memória”, confirme o estado visível e avance para “Revise e remova” apenas quando a etapa anterior estiver estável. Em Memórias, pular contexto costuma gerar mais retrabalho do que velocidade.
Como validar Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Memórias realmente exigir mais contexto, controle ou verificação.
Matriz de comportamento: Memórias Nesta página, a referência completa cobre captura, promoção, relevância, origem, confiança e exclusão. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Memórias A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Conectores Conectores permitem ligar serviços externos ao Giorgio quando uma tarefa precisa desse contexto.
Conectar um serviço Desconectar Quando uma integração não for mais necessária, use o controle de desconexão correspondente. A disponibilidade e o fluxo exato dependem do conector mostrado no catálogo.
Permissão antes de conveniência Conectores dão acesso a serviços externos e por isso devem tornar escopo e autorização explícitos antes de agir.
Leitura operacional Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Conectores, onde o contexto pode atravessar mais de uma etapa.
Comece por “Conectar um serviço”, confirme o estado visível e avance para “Desconectar” apenas quando a etapa anterior estiver estável. Em Conectores, pular contexto costuma gerar mais retrabalho do que velocidade.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Do primeiro clique à entrega Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Conectores realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Conectores deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Limites e exceções Use Conectores como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Conectores permitem ligar serviços externos ao Giorgio quando uma tarefa precisa desse contexto. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Checklist de uso Comece por “Conectar um serviço”, confirme o estado visível e avance para “Desconectar” apenas quando a etapa anterior estiver estável. Em Conectores, pular contexto costuma gerar mais retrabalho do que velocidade.
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Conectores, onde o contexto pode atravessar mais de uma etapa.
Guia de verificação: Conectores Nesta página, a referência completa cobre OAuth, escopos, leitura, escrita e fronteiras de autorização. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Conectores A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Plugins O catálogo de plugins reúne capacidades adicionais e mostra o que está disponível ou instalado.
Descobrir Navegue pelas categorias e leia a descrição de cada item antes de instalar. O objetivo é entender que problema aquela extensão ajuda a resolver.
Estados Capacidades com limites claros Plugins ampliam o que o Giorgio pode fazer, mas cada capacidade continua sujeita ao contrato da ferramenta conectada.
O que merece atenção Use Plugins como uma referência de operação, não como uma tela isolada. A própria proposta da página é: O catálogo de plugins reúne capacidades adicionais e mostra o que está disponível ou instalado. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Plugins o estado deixou de corresponder ao que a interface prometia.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Um fluxo que funciona Comece por “Descobrir”, confirme o estado visível e avance para “Estados” apenas quando a etapa anterior estiver estável. Em Plugins, pular contexto costuma gerar mais retrabalho do que velocidade.
Quando mudar de estratégia Imagine uma tarefa real em que Plugins deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Plugins realmente exigir mais contexto, controle ou verificação.
Sinais de que terminou Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Plugins o estado deixou de corresponder ao que a interface prometia.
Use Plugins como uma referência de operação, não como uma tela isolada. A própria proposta da página é: O catálogo de plugins reúne capacidades adicionais e mostra o que está disponível ou instalado. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Detalhes que evitam regressão: Plugins Nesta página, a referência completa cobre descoberta, capacidade, permissão, execução real e resultado observável. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Plugins A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Privacidade As configurações de privacidade reúnem controles e informações sobre dados, sessões e uso da conta.
Revise antes de mudar Leia a descrição de cada controle para entender o efeito na conta. Ações de exclusão ou remoção de dados devem ser tratadas como operações sensíveis.
Conteúdo público e privado Blog e documentação são públicos. Conversas, projetos, memórias e outras superfícies pessoais continuam associados à sessão autenticada.
Fronteiras de dados Privacidade depende de saber onde o dado entra, onde é armazenado e quando é compartilhado com uma ferramenta ou serviço conectado.
Mapa da experiência Imagine uma tarefa real em que Privacidade deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Aplicação prática Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Privacidade o estado deixou de corresponder ao que a interface prometia.
Use Privacidade como uma referência de operação, não como uma tela isolada. A própria proposta da página é: As configurações de privacidade reúnem controles e informações sobre dados, sessões e uso da conta. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Erros fáceis de evitar Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Privacidade, onde o contexto pode atravessar mais de uma etapa.
Comece por “Revise antes de mudar”, confirme o estado visível e avance para “Conteúdo público e privado” apenas quando a etapa anterior estiver estável. Em Privacidade, pular contexto costuma gerar mais retrabalho do que velocidade.
Revisão final Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Privacidade realmente exigir mais contexto, controle ou verificação.
Mapa operacional: Privacidade Nesta página, a referência completa cobre retenção, dados conectados, telemetria, temporário e controle do usuário. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Privacidade A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Idioma A interface pode seguir o idioma detectado ou uma preferência manual salva no navegador.
Detecção automática Sem escolha manual, o Giorgio usa a preferência de idioma do navegador para selecionar português, inglês, espanhol ou francês quando reconhecidos.
Escolha manual Ao trocar o idioma nas páginas públicas, a preferência é salva e o conteúdo inteiro é renderizado novamente no idioma escolhido.
Detecção e escolha manual O idioma pode ser detectado automaticamente, mas a escolha manual precisa sempre vencer quando o usuário a define.
Ponto de partida Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Idioma, onde o contexto pode atravessar mais de uma etapa.
Comece por “Detecção automática”, confirme o estado visível e avance para “Escolha manual” apenas quando a etapa anterior estiver estável. Em Idioma, pular contexto costuma gerar mais retrabalho do que velocidade.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Trabalho em camadas Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Idioma realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Idioma deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Diagnóstico rápido Use Idioma como uma referência de operação, não como uma tela isolada. A própria proposta da página é: A interface pode seguir o idioma detectado ou uma preferência manual salva no navegador. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Próximo passo Comece por “Detecção automática”, confirme o estado visível e avance para “Escolha manual” apenas quando a etapa anterior estiver estável. Em Idioma, pular contexto costuma gerar mais retrabalho do que velocidade.
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Idioma, onde o contexto pode atravessar mais de uma etapa.
Referência de produção: Idioma Nesta página, a referência completa cobre detecção inicial, persistência, catálogo PT/EN/ES/FR e conteúdo dinâmico. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Idioma A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Uso no celular O layout mobile reorganiza navegação, composer e painéis para telas estreitas e para o teclado virtual.
Sidebar como drawer Em vez de ocupar largura fixa, a navegação principal abre sobre o conteúdo e fecha após a escolha.
Teclado virtual O app usa a viewport visual quando disponível para evitar que campos e ações principais fiquem escondidos atrás do teclado.
Prioridade para a tarefa atual No celular, espaço é o recurso mais escasso. Composer, leitura e ações essenciais precisam vir antes de painéis secundários.
Como pensar esta área Use Uso no celular como uma referência de operação, não como uma tela isolada. A própria proposta da página é: O layout mobile reorganiza navegação, composer e painéis para telas estreitas e para o teclado virtual. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Uso no celular o estado deixou de corresponder ao que a interface prometia.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Exemplo de uso Comece por “Sidebar como drawer”, confirme o estado visível e avance para “Teclado virtual” apenas quando a etapa anterior estiver estável. Em Uso no celular, pular contexto costuma gerar mais retrabalho do que velocidade.
Quando não usar Imagine uma tarefa real em que Uso no celular deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Uso no celular realmente exigir mais contexto, controle ou verificação.
Verificação independente Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Uso no celular o estado deixou de corresponder ao que a interface prometia.
Use Uso no celular como uma referência de operação, não como uma tela isolada. A própria proposta da página é: O layout mobile reorganiza navegação, composer e painéis para telas estreitas e para o teclado virtual. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Contrato desta superfície: Uso no celular Nesta página, a referência completa cobre viewport, teclado, safe-area, touch, overlays e composição compacta. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Uso no celular A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Refletir Refletir resume padrões do histórico salvo com gráficos de ritmo, dias, horários e assuntos.
O que aparece Fonte dos dados O painel usa o histórico salvo disponível para a conta. Conversas temporárias não fazem parte desse resumo.
Atividade que responde perguntas Refletir só é útil quando o gráfico responde perguntas sobre ritmo, horário, foco e volume em vez de existir como decoração.
Objetivo e contexto Imagine uma tarefa real em que Refletir deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Ordem das ações Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Refletir o estado deixou de corresponder ao que a interface prometia.
Use Refletir como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Refletir resume padrões do histórico salvo com gráficos de ritmo, dias, horários e assuntos. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Casos de borda Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Refletir, onde o contexto pode atravessar mais de uma etapa.
Comece por “O que aparece”, confirme o estado visível e avance para “Fonte dos dados” apenas quando a etapa anterior estiver estável. Em Refletir, pular contexto costuma gerar mais retrabalho do que velocidade.
Entrega sem surpresa Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Refletir realmente exigir mais contexto, controle ou verificação.
Leitura de engenharia: Refletir Nesta página, a referência completa cobre eventos, métricas, período, interpretação e limites de inferência. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Refletir A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Configurações Configurações reúne conta, privacidade, capacidades, memórias, personalização e outras preferências do app.
Use a busca Quando disponível, a busca do painel reduz o tempo para encontrar uma opção em listas maiores.
Ações sensíveis Alterações de conta, privacidade e exclusão merecem leitura da descrição e confirmação antes de serem executadas.
Preferências persistentes Configurações devem alterar comportamento real e persistir de forma previsível entre sessões.
Da intenção ao resultado Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Configurações, onde o contexto pode atravessar mais de uma etapa.
Comece por “Use a busca”, confirme o estado visível e avance para “Ações sensíveis” apenas quando a etapa anterior estiver estável. Em Configurações, pular contexto costuma gerar mais retrabalho do que velocidade.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Durante a execução Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Configurações realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Configurações deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Se algo sair do esperado Use Configurações como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Configurações reúne conta, privacidade, capacidades, memórias, personalização e outras preferências do app. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Fechamento do trabalho Comece por “Use a busca”, confirme o estado visível e avance para “Ações sensíveis” apenas quando a etapa anterior estiver estável. Em Configurações, pular contexto costuma gerar mais retrabalho do que velocidade.
Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Configurações, onde o contexto pode atravessar mais de uma etapa.
Checklist de integração: Configurações Nesta página, a referência completa cobre defaults, progressive disclosure, persistência e efeito real dos controles. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Configurações A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Planos Compare Free e Pro com benefícios reais, limites, preço e o tipo de uso para o qual cada plano foi desenhado.
Free: o que já vem incluído O Free é um plano funcional, não uma demonstração vazia. Ele cobre Chat, Projetos, memória, busca na web, conectores, artefatos, criação de arquivos, plugins e Giorgio Code para uso cotidiano.
Pro: onde o ganho aparece Pro é para quem transforma o Giorgio em ferramenta de trabalho recorrente e começa a sentir o atrito da janela do Free. O foco é dar mais folga operacional, prioridade e continuidade para sessões intensas.
Preço Na interface atual, o Pro aparece por R$ 23,99/mês em contexto brasileiro e US$ 4.99/mês em contexto internacional. O valor final pode variar por região, moeda, impostos e método de pagamento.
Quando vale ficar no Free Fique no Free se o uso é leve, intermitente ou se você raramente atinge a janela móvel. Para muita gente, ele já cobre o fluxo inteiro sem custo.
Quando vale subir para Pro Pro passa a fazer sentido quando o custo de interromper uma sessão, esperar a janela resetar ou dividir trabalho pesado já supera o valor mensal do plano.
O papel desta página Use Planos como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Compare Free e Pro com benefícios reais, limites, preço e o tipo de uso para o qual cada plano foi desenhado. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Planos o estado deixou de corresponder ao que a interface prometia.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Uso no dia a dia Comece por “Free: o que já vem incluído”, confirme o estado visível e avance para “Pro: onde o ganho aparece” apenas quando a etapa anterior estiver estável. Em Planos, pular contexto costuma gerar mais retrabalho do que velocidade.
Matriz de comportamento: Planos Nesta página, a referência completa cobre Free, Pro, limites, preços, Thesis 2.1, Office, Code e prioridade. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Planos A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Conta A página de conta reúne identificação, sessão, segurança e ações ligadas ao perfil autenticado.
Sessões e dispositivos Quando o app mostra sessões ativas, use essa área para reconhecer onde a conta está conectada e encerrar acessos que não devem permanecer ativos.
Dados de conta Alterações permanentes devem ser feitas com atenção aos avisos exibidos pelo próprio painel.
Conta, identidade e recuperação A área de conta reúne identidade, segurança de acesso e recuperação. Mudanças críticas precisam de feedback claro e estado confirmável.
Primeira decisão Imagine uma tarefa real em que Conta deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Como manter o contexto Se o comportamento divergir do esperado, separe falha visual, falha de dados e falha de execução. O objetivo é descobrir em qual etapa de Conta o estado deixou de corresponder ao que a interface prometia.
Use Conta como uma referência de operação, não como uma tela isolada. A própria proposta da página é: A página de conta reúne identificação, sessão, segurança e ações ligadas ao perfil autenticado. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Falhas recuperáveis Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Conta, onde o contexto pode atravessar mais de uma etapa.
Comece por “Sessões e dispositivos”, confirme o estado visível e avance para “Dados de conta” apenas quando a etapa anterior estiver estável. Em Conta, pular contexto costuma gerar mais retrabalho do que velocidade.
Resultado esperado Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Conta realmente exigir mais contexto, controle ou verificação.
Guia de verificação: Conta Nesta página, a referência completa cobre perfil, sessão, plano, exclusão, segurança e estado da conta. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Conta A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Solução de problemas Comece pela etapa que falhou e pelo estado visível antes de apagar dados, reinstalar ou mudar configurações.
Login não conclui Uma página fica vazia Ao reportar Inclua a rota, ação feita, mensagem exibida e captura quando possível. Isso é muito mais útil do que apenas “não funciona”.
Diagnóstico antes de tentativa aleatória Solução de problemas começa separando falha de rede, autenticação, limite, modelo, ferramenta e interface. Cada classe pede uma resposta diferente.
Visão prática Considere o fluxo concluído quando o resultado pode ser reaberto, revisado e entendido sem depender da memória de quem executou a tarefa. Isso é especialmente importante em Solução de problemas, onde o contexto pode atravessar mais de uma etapa.
Comece por “Login não conclui”, confirme o estado visível e avance para “Uma página fica vazia” apenas quando a etapa anterior estiver estável. Em Solução de problemas, pular contexto costuma gerar mais retrabalho do que velocidade.
No app principal, preserve continuidade entre conversa, projeto, arquivo e ação para que o usuário não precise reconstruir o contexto a cada tela.
Fluxo mínimo Nem todo caso precisa da configuração mais avançada. Prefira o caminho mínimo que resolve o objetivo e aumente complexidade somente quando Solução de problemas realmente exigir mais contexto, controle ou verificação.
Imagine uma tarefa real em que Solução de problemas deixa de ser uma opção de menu e passa a decidir a qualidade da entrega. Faça uma primeira passagem curta, observe o retorno do sistema e só então aumente escopo, quantidade de arquivos ou duração da sessão.
Escalando com segurança Use Solução de problemas como uma referência de operação, não como uma tela isolada. A própria proposta da página é: Comece pela etapa que falhou e pelo estado visível antes de apagar dados, reinstalar ou mudar configurações. O ganho aparece quando isso se conecta ao que vem antes e ao que precisa acontecer depois.
Detalhes que evitam regressão: Solução de problemas Nesta página, a referência completa cobre classificação de falha, evidência, recuperação e escalonamento. O objetivo não é decorar nomes de controles; é entender entradas, estado, efeitos colaterais, falhas recuperáveis e a evidência que confirma a conclusão.
Casos de borda de Solução de problemas A versão robusta desta função continua coerente quando a rede atrasa, a sessão muda, o conteúdo está vazio, o usuário repete a ação, o viewport encolhe ou uma dependência externa deixa de responder. Esses estados fazem parte da documentação porque também fazem parte do produto.
Giorgio Office A suíte de produtividade do Giorgio: planilhas, documentos, apresentações, comunicação, notas, formulários, reuniões e planejamento sob um contexto compartilhado.
Arquitetura da suíte Ordo, Scriptum, Lumen, Nodus, Tabula, Forma, Convena e Acta compartilham identidade, persistência e um contrato de handoff. Cada app mantém sua gramática de produtividade familiar, mas o contexto pode atravessar planilha, documento, slide, agenda e tarefa sem exigir exportações intermediárias.
Aplicativos e responsabilidades O desenho evita um “super app” indistinto. Cada superfície possui domínio claro: Ordo calcula e estrutura dados; Scriptum compõe documentos; Lumen constrói narrativa visual; Nodus coordena e-mail/calendário/tarefas; Tabula organiza conhecimento; Forma coleta respostas; Convena coordena conversas e reuniões; Acta acompanha execução.
Compatibilidade de arquivos A estratégia de arquivo separa formato de trabalho interno de formatos de intercâmbio. CSV entra e sai do Ordo; documentos e apresentações podem ser exportados para formatos estruturados; quando a conversão perfeita de um formato proprietário não existe no browser, a interface deve dizer isso em vez de fabricar compatibilidade.
Agente entre superfícies O assistente não é uma caixa de texto decorativa. O contrato correto é: ler o estado da superfície ativa, identificar recursos realmente disponíveis, produzir uma proposta ou alteração observável e manter o usuário no controle para ações externas.
Critério de conclusão Um fluxo Office está concluído quando o conteúdo persiste, pode ser reaberto, exportado quando prometido e não perde contexto ao alternar de app. “Pareceu funcionar” não substitui persistência, reentrada e feedback de erro.
Sincronização no Giorgio Office Como estado local, sessão autenticada e sincronização na nuvem coexistem sem transformar edição em uma corrida de sobrescritas.
Estado local primeiro A edição permanece responsiva porque o documento é salvo localmente antes de depender da rede. A nuvem é uma camada de continuidade, não o único lugar onde o estado existe.
Identidade e RLS Cada registro de documento pertence ao user_id autenticado. As políticas de Row Level Security impedem leitura e escrita cruzada entre contas, mesmo que um cliente tente alterar identificadores manualmente.
Conflito e relógio A versão atual usa updated_at como evidência de atualização, mas não deve fingir colaboração CRDT que não existe. Para edição multi-dispositivo simultânea, a evolução correta é adicionar versionamento/etag ou um protocolo de merge explícito.
Falhas recuperáveis Sem sessão, o Office continua local. Com rede lenta, o estado de sincronização informa o atraso. Uma falha de nuvem não pode apagar o estado local nem bloquear exportação.
Instaladores nativos para Desktop, Code e Ordo O que os setups em Go realmente fazem, como o executável é instalado e qual é o limite entre cabeçalho MZ/PE e assinatura digital Authenticode.
Formato do executável Os instaladores são compilados em Go para Windows amd64 com subsistema GUI. O arquivo resultante é PE32+ e começa com a assinatura histórica MZ exigida pelo formato PE. Isso não equivale a uma assinatura criptográfica Authenticode.
Instalação O setup grava o launcher em LocalAppData, cria atalhos no Menu Iniciar e opcionalmente na área de trabalho, registra uma entrada mínima de desinstalação e oferece abrir o produto ao concluir.
Sem WebView empacotado O launcher procura Edge ou Chrome instalados e usa o modo app do navegador. Isso mantém o binário pequeno e evita empacotar outro Chromium. Se nenhum estiver disponível, cai para o navegador padrão do sistema.
Assinatura digital Para remover avisos de reputação do Windows em distribuição ampla é necessário um certificado de assinatura de código e Authenticode. O cabeçalho MZ sozinho apenas identifica o formato executável; ele não comprova publisher nem reputação.
Thesis 2.1: visão geral O 2.1 combina GPT-OSS 120B, roteamento math-first, test-time compute adaptativo, preflight no Melos 2 e verificação cruzada sem trocar a identidade pública do modelo.
Math-first routing Provas e matemática avançada têm precedência sobre classificadores genéricos de formato. Restrições de apresentação continuam obrigatórias, mas são verificadas como contrato depois da solução.
Compute adaptativo por dificuldade Tarefas simples continuam curtas. Problemas com prova, operator theory, alta densidade de restrições ou sinais de problema aberto recebem esforço maior e orçamento compatível. O objetivo é comprar raciocínio onde ele altera a taxa de erro.
Melos 2 como crítico rápido Em casos difíceis, o 20B pode produzir um preflight adversarial com obrigações, invariantes e riscos antes da chamada principal de 120B. Esse passo é consultivo e não substitui o solver.
Cross-model verification Quando a tarefa justifica auditoria, o 20B verifica a conclusão de forma independente. O sistema não trata qualquer discordância como correção: defeitos precisam ser concretos e materiais antes de substituir a resposta do 120B.
Open Problem Guard Em Riemann, P vs NP, Collatz e outros problemas abertos, o runtime impede que pontes conjecturais sejam silenciosamente promovidas a prova. O sistema pode explorar hipóteses, mas deve expor a obstrução quando uma equivalência, limite ou construção não foi demonstrada.
Internet real no Thesis 2.1 Busca pública iterativa, fontes rastreáveis e uma fronteira clara entre evidência da web e instruções.
Pré-busca e busca dirigida pelo modelo Quando o pedido já exige informação atual, documentação ou fontes, o gateway faz uma busca inicial. Se o Thesis 2.1 ainda detectar uma lacuna material, ele pode pedir consultas adicionais e receber os resultados em uma nova passagem. Isso transforma pesquisa em loop de evidência, não em um único snippet anexado ao prompt.
Fontes antes de síntese Defesa contra prompt injection O conteúdo recuperado entra explicitamente como UNTRUSTED DATA. Instruções encontradas numa página não mudam política, permissões, ferramenta ou objetivo. O texto serve para sustentar fatos; não ganha autoridade operacional só porque veio de uma URL.
Quando a busca não deve rodar Conhecimento estável, transformação do texto fornecido e tarefas locais bem especificadas não precisam pagar latência de rede. A busca é ferramenta, não ritual.
Ações locais confirmadas Como Thesis 2.1 pode pedir instalação de dependências e escrita de arquivos no Giorgio Desktop sem ganhar um shell irrestrito.
Propor, não executar silenciosamente O modelo emite uma ação tipada. A interface valida o tipo, mostra exatamente o que será instalado ou escrito e pede confirmação. Só depois o Desktop Bridge chama terminal ou filesystem. No navegador comum a ação não executa.
Instalação de pacotes Escrita de arquivos A escrita fica confinada ao workspace ativo. Caminhos absolutos, .. e payloads excessivos são rejeitados pelo protocolo antes de chegar ao runtime local.
Evidência de execução O retorno do terminal, o status da operação e o filesystem são evidência. Uma frase gerada pelo modelo não é. Se a ação falhar, Giorgio deve mostrar a falha e manter a resposta separada do estado real da máquina.
Runtime de plugins Plugins agora declaram método, entregável, verificação e política de evidência em vez de serem apenas nomes num catálogo.
Manifesto operacional Cada família central descreve papel, métodos, entregáveis esperados, gates de verificação e quando buscar evidência atual. Isso dá ao plugin um contrato executável e facilita auditoria quando um resultado sai do foco.
Descoberta progressiva O objetivo não é jogar centenas de definições no prompt. Giorgio mapeia o plugin escolhido para a menor família operacional relevante e carrega o manifesto necessário para aquela tarefa. Menos schemas inúteis significa mais contexto para o trabalho.
Famílias que exigem fontes atuais Verificação específica por domínio Um plugin de dados precisa reconciliar grain, unidades e totais; um plugin legal precisa preservar jurisdição, data e autoridade; um plugin de design precisa testar responsive, foco e estados; um plugin de engenharia precisa distinguir parse, build, runtime e E2E. “Uma resposta boa” não é um único critério universal.
