v1.2.26

Read in English →

Oi,

Você está entre as primeiras pessoas a rodar esta versão, então esta página foi escrita para você: o que mudou, o que testar primeiro, o que precisa de um passo seu e o que ainda não está corrigido. Teste três coisas primeiro: coloque duas sprints na fila com largura 2 (#7244, #7059), abra a tela Fleet e aperte ? (#7313, #7320), e aperte r num board do War Room que você conhece bem (#7293). Depois, feche e abra de novo cada cockpit aberto. Se algo quebrar ou parecer errado, responda à carta ou abra um ticket. Uma captura de tela, e a tela em que ela foi tirada, resolve a maioria dos relatos de uma vez.

Um abraço, Alex

Mais trabalho em andamento, e um cockpit que só avisa o que precisa de você. 323 pull requests mesclados em dez dias, e esta seção cobre todos eles. As ondas deixam de rodar uma de cada vez: você escolhe quantas rodam lado a lado, coloca o resto na fila, dá um horário de início a uma entrada, e a fila continua andando sem nenhum cockpit aberto. O ACE lê um único recap da frota inteira, e os atores por trás dele agora entregam sozinhos as conclusões de uma revisão e cutucam um worker que ficou quieto. A tela Fleet e a fila de Workers foram refeitas sobre uma leitura única e compartilhada de cada worker, com uma legenda para cada símbolo. O board do War Room volta a dizer a verdade e lê só o que você pede. Oito novos especialistas entram no elenco (44 → 52), e sai o primeiro pacote opcional. O Windows passa a ser suportado pelo WSL2, o login deixa você entrar, e duas semanas do relatório de campo de um cliente estão corrigidas, achado por achado. O que precisa de um passo seu, e o que ainda não está pronto, estão ditos com clareza no fim.

Ondas: várias ao mesmo tempo, e uma fila para o resto

• 🔴 Rode mais de uma onda ao mesmo tempo. Você define uma largura N, e a fila mantém N ondas vivas; a próxima começa no momento em que uma termina. Uma linha do doctor aponta qualquer ticket que duas execuções seguram ao mesmo tempo (#7244). As vagas são divididas de forma justa: execuções que estão sem vaga são atendidas primeiro, cada onda pode ter seu próprio máximo e peso, e um piso reservado é imposto no portão que admite um worker. Duas execuções que planejariam o mesmo ticket são recusadas (#7137).
• A fila de ondas. Sprints na fila esperam numa fila durável, por repositório, com barreiras, uma política de pausa e um disjuntor (#7042). Você a gerencia pela CLI (flowforge waves queue show|add|rm|mv|barrier|width|start|hold, waves resume|skip|abandon) ou pela ferramenta MCP waves_queue. Toda recusa acontece quando você monta a entrada, nunca depois (#7059). A fila também lê os registros da própria máquina: o orçamento compartilhado do GitHub, uma pausa de uso e os códigos de recusa do verbo de início (#7084).
• Uma fila também é uma agenda. Uma entrada pode ter um dia e um horário de início, e você pode mover uma para a frente ou para o fim (#7109). O board Waves edita a fila no lugar: largura, horário de início e "a terceira para a primeira" com uma tecla (#7123). Um plano pavimentado também pode esperar na fila. A data de começo dele é respondida quando você o adiciona, e ele dispara por plans fire quando chega a vez dele (#7071).
• 🔴 A fila continua andando sem cockpit aberto. O cockpit avança a fila no seu ritmo de 1 Hz (#7064). Quando nenhum cockpit está conduzindo, o daemon do FlowForge avança cada fila em andamento pelo mesmo verbo e pela mesma porta, create_worker. Um cockpit que abre retoma a execução pelo seu lease, então dois condutores nunca disparam a mesma execução. Uma fila cuja próxima entrada está agendada para amanhã não lê nada do GitHub até lá (#7260). Todo spawn de worker sobe o daemon se ele não estiver rodando, a menos que você defina FLOWFORGE_DAEMON_AUTOSPAWN=0 (#6952).
• 🔴 Um ticket começa quando as dependências dele chegam. Dentro de uma onda, um ticket esperava a camada anterior inteira terminar. Agora ele começa assim que todo ticket de que depende foi mesclado e há uma vaga livre. Um plano sem arestas registradas mantém a barreira antiga, byte a byte (#7335). Do relatório de campo de um cliente.
• O board Waves. Ele mostra lado a lado as execuções vivas e as entradas na fila, uma linha de condutor e de máquina, um banner de problemas e cinco larguras (#7102). Tem um anel de foco, drill-in, verbos que nomeiam o alvo e uma trava nas teclas destrutivas (#7121). Uma cor significa uma execução em todo lugar onde aparece (#7118). Cada execução ganha seu próprio registro: um id, o escopo, um condutor, um resultado tipado (#6957), e armazenamento próprio, então parar e pausar agem sobre uma execução só (#7125).
• Histórico de ondas. Toda execução que terminou fica guardada, com a sprint, o início, o fim e o resultado, até você limpar (#6964).
• Arme uma onda sem o board. flowforge waves start --sprint, a ferramenta MCP waves_start e a tecla S passam todas por um único verbo. Ele organiza em camadas os tickets da própria sprint e recusa com motivos nomeados (#7012). O modo sprint de loop autofire passa pelas mesmas recusas antes de pegar um lease (#7124).
• Uma onda é ≈1, nunca W0. As ondas contam a partir de 1 e aparecem como ≈N no widget, no chip da Fleet, no board, na tela Waves e nas palavras do ACE. W é só para workers (#7063).
• Correções menores nas ondas. Toda linha mostra o título do seu ticket, ou loading…, nunca um espaço vazio (#6894). A tela Waves volta para a tela que a abriu, e b / t abrem o Kanban e o Gantt da mesma sprint (#6715). Os modais de disparo e a faixa de ondas contam todos os workers da máquina, não só os deste projeto (#7062). Um épico é um contêiner, não trabalho: ele nunca entra numa onda nem é disparado como worker (#7107). O board de ondas e o depends-audit leem o mesmo elenco completo (#6510).

O ACE que age

• 🔴 Um único recap da frota inteira. O recap é um retrato da frota em que cada leitura ou é conhecida ou é explicitamente UNKNOWN (#6979). O daemon o serve em /v1/recap, e flowforge recap o lê (#7003). Ele aparece como uma escalada no trilho do ACE, composto na largura do trilho (#7010). Antes de o ACE encerrar um turno, um portão de Stop-hook garante que ele leu o recap mais recente (#7029, #7041, #7056). Em produção, todo leitor que tem uma fonte está conectado (#7055), e o ciclo foi fechado e medido de novo de ponta a ponta (#7087).
• 🔴 A tabela de atores — cinco remédios, cada um com o estágio que conquistou. Os atores rodam no host de atores do daemon: um por home e por conta (#6827), supervisionado para que um panic custe uma passada e nunca o daemon (#7023). Cada remédio tem seu próprio estágio de confiança, e só é promovido pelo seu histórico (#6951):
  • relay-verdict entrega as conclusões de uma revisão ao worker aquecido que é dono do pull request. Ele age hoje (#6968, #6953).
  • nudge-worker manda um "continue" por período de silêncio. Ele nomeia qualquer recusa ou NOT-GOLDEN e, depois de um limite de uso, espera o reset. Ele age hoje.
  • order-rebase manda fazer rebase quando um pull request entra em conflito (#6959, #7057). Ele roda em sombra: registra o que teria feito e não age sobre nada.
  • dispatch-review inicia uma revisão que está devida (#6984). Ele também roda em sombra.
  • reap-vanished recolhe um worker cuja janela sumiu enquanto nenhum cockpit roda (#7037). Ele só registra, e nunca mata nada.
  • Cada linha do board de trabalho travado diz o que de fato aconteceu, lido de um registro: ACTED, ESCALATED, WAIVED ou FAIL (#7004).
• As escaladas chegam primeiro ao ACE. Há um único registro com quatro classes. Uma bifurcação só passa por um portão que um plano desenhou. Um portão de merge vale só para o seu pull request e o seu head. Falhas e perguntas vão primeiro ao ACE, e só uma decisão de nível de fundador chama você (#6913). As escaladas que vão primeiro ao ACE seguem pelo despertar do ACE (#7035) e chegam também a um ACE sem interface (#7049). Abaixo da linha de escalada, o ator de travamento ainda avisa o ACE (#7060). Uma condição sobre a qual nenhum remédio vai agir deve ao ACE um aviso por head, que diz o motivo e o próximo passo (#7073). Falhas de automação não têm mais um caminho silencioso (#6949), e uma lane vermelha nomeia a verificação e os testes que falharam (#6996).
• O despertar. Uma caixa de saída durável e um drenador na lane de stream acordam o ACE quando algo precisa dele. O fallback de composer é protegido e nunca é de disparo único (#7030). Um envio enfileirado atrás de um turno vivo fica retido, e não conta como entregue (#7036). O relay de worker-done para o ACE se rearma depois de uma recusa (#7093).
• Um worker que precisa de você diz por quê. O pedido de permissão de um worker vira uma linha adiada de needs-you (#6998). claude agents --json é uma segunda fonte para essas linhas (#6990). Um /goal que nunca armou é escalado (#7005). Um goal que o harness abandonou aparece como GOAL LOST, nunca como uma pausa silenciosa (#7000), e a linha do /goal cabe abaixo do limite de colagem recolhida do Claude Code, então ela volta a armar (#7002).
• Os relays usam a própria caixa de entrada do Claude Code. Uma mensagem para um worker é uma mensagem enquadrada com um resultado tipado, e a colagem fica como fallback (#7006). Ela só disca os sockets do usuário atual (#7009). Um relay que cai na fila de um worker é entregue pela FlowForge, não por você (#6531).

A tela Fleet e a fila de Workers

• 🔴 Uma leitura de cada worker, compartilhada pelas duas telas. Uma projeção tipada de cada item de trabalho (#6907) e de cada onda (#7096) é montada uma vez e entregue às duas telas no mesmo tick. A fila de Workers a lê (#7106), e dez setters por campo se aposentam. O título, o marco, as etiquetas e o tipo do ticket são lidos num único lote (#7103), e a chave do ticket é lida do jeito que foi escrita (#7100).
• A tela Fleet. O elenco agora são as sessões: toda sessão viva é uma lane, e um worker parado vira uma lane pela primeira vez. Se o daemon cair, um banner avisa, e nenhuma lane some (#7305). A faixa de sinais vitais cabe numa linha e tem um banner de falha (#7310). Selecionar uma lane abre o detalhe dela e uma prévia, sem tomar uma tecla da tabela (#7301). O modal de detalhe mostra as condições de cada lane e cabe num terminal baixo (#7296).
• A fila de Workers. Cada linha diz o que o worker está fazendo. Mostra há quanto tempo ele está quieto, pelo registro de travamento ou pelo painel (#7098), quantas rodadas de revisão o pull request dele já teve (#7104), e a qual onda ele pertence (#6898). O título dele é legível em 120 colunas (#7111). As linhas se agrupam em cinco grupos, cada um com uma linha de cabeçalho (#7140, #7285), e as duas linhas trazem a mesma leitura de atenção (#7132). A base do branch é registrada quando um worker é disparado (#7101).
• Cada símbolo, explicado. Linhas de decodificação e legendas cobrem cada glifo, cada um desenhado com sua cor e seu rótulo (#7145, #6909). A ajuda tem um bloco Symbols para Workers e Fleet, gerado das próprias tabelas dos renderizadores (#7320). As teclas, as dicas e a ajuda foram refeitas nas duas telas: k percorre a fila em foco, a barra e o rodapé nomeiam só verbos vivos, e ? na Fleet mostra as teclas da própria Fleet (#7313).
• As colunas se alinham. Cada glifo é desenhado na sua própria célula, e um teste de propriedade mantém cada coluna numa única posição x nas renderizações da Fleet e da ajuda (#7322). Cada tela foi renderizada de novo a partir do código, nos dois temas, para aceite (#7318).
• Um teto de workers e um orçamento do GitHub por máquina. Toda porta que dispara um worker passa por um único portão de vagas da máquina inteira (#6915). Um controle em Settings grava o teto, e o cockpit tem uma linha da máquina (#6973). A vaga de um worker morto é liberada (#7034). Todo processo FlowForge da máquina divide um único orçamento do GitHub (#6902). A parte GraphQL dele é medida, registrada e reservada para os portões de merge, e a linha de status e a lane de autofire param de consultar o que não mudou (#7275).

O War Room

• 🔴 O board diz a verdade, e r corrige. Cartões não somem mais de um board de sprint quando chega outra leitura. O board de lanes conta e desenha uma única lista, diz quando está desatualizado, e r lê de novo. Um ticket com pull request aberto fica em Review, não em To-do, porque agora o pull request se liga ao ticket pelo branch. Um ticket mesclado mas ainda aberto aparece em Review com um selo, e START e DUE aparecem no seu próprio fuso (#7293). Do relatório de campo de um cliente.
• O War Room lê o que você pede. Recarregue quando quiser. Leia uma sprint, um marco, os tickets avulsos ou tudo o que foi atualizado desde uma data, cada um respondido pela própria consulta do provedor (#7196). Uma linha de leitura sob o título diz o que o board pediu. R abre o seletor de leitura, r recarrega em qualquer estado, e sua escolha é lembrada por projeto (#7284).
• Agendas e contêineres que fecham a conta. Atraso e adiantamento seguem uma única regra: trabalho sem data herda o fim da sprint, épicos nunca contam, o cabeçalho é igual às linhas, e o trabalho que terminou cedo finalmente aparece como adiantado (#6545). Uma sprint pode ser desligada da sua iniciativa (#6555). Uma iniciativa fechada reabre quando uma sprint viva é ligada a ela (#6551). Por mais antiga que seja a prateleira "Plans ready to fire", ela aparece como uma única linha com nome (#6696). container-sweep nomeia cada épico que considerou, inclusive um mantido aberto por um filho aberto (#6869).
• O relógio que você lê é o seu relógio. O War Room, as Release Letters e todo relógio do cockpit aparecem no seu próprio fuso (#6549).

Merges e revisões em que você pode confiar

• Um veredito se liga ao head e à base. Uma troca de base ganha uma revisão nova sem precisar de um commit que só muda bytes (#6475). A troca de base também rearma a revisão, o portão de merge ignora execuções de CI da base antiga, e worker park recusa um pull request fora da lane (#7302).
• Um merge nunca acontece debaixo de um worker que ainda está trabalhando. Ele espera enquanto o worker tem mudanças não commitadas, commits não enviados ou um turno em andamento, avisa o worker uma vez por head e tenta de novo na próxima passada (#7011).
• Conflitos são ordenados uma vez. Um merge recusado por conflito num head é tentado uma vez, ordenado uma vez e só rearmado por um push (#7295). Uma única rodada compartilhada de ordem de conflito por pull request, head e base (#7091).
• Uma decisão por rodada. A recusa de um portão sobre o código é publicada como um único aviso de recusa, nunca guardada como veredito (#6687). O registro da revisão diz quem julgou um head, e um GOLDEN recusado não é relatado como uma equipe morta (#6597). Um registro ilegível é dito na linha de merge, nunca mostrado como "nenhum pedido" (#6969). Um portão de fundador liberado depois de um NOT-GOLDEN pode religar o head (#6963).
• As revisões começam por uma única porta. As equipes de revisão sobem por uma porta só, com tetos medidos de turnos e de orçamento e um SIGINT antes de qualquer kill (#6992). A pausa durável de um worker em qualquer branch marca a revisão como devida (#6911). Os orçamentos de disparo separam o que foi julgado, o que morreu e o que foi recusado, toda lane respeita uma pausa de uso da máquina inteira, e o verbo de merge não gasta nada (#6965).
• O fechamento é exato. Um pull request no branch padrão fecha só os tickets que declara (#6480). Dois projetos deixam de dividir um mesmo registro e uma mesma trava de verificação por número de pull request (#6906). O passo pós-merge do fundador é um registro durável, mostrado como um comando absoluto (#6658).

O relatório de campo de um cliente, corrigido achado por achado

Um cliente rodou a FlowForge num projeto real por duas semanas e relatou o que quebrou, com a contagem de ocorrências. Cada achado abaixo foi trabalhado no seu próprio ticket.

• 🔴 Um worker morto é encontrado, o trabalho dele é salvo, e ele é disparado de novo. Um worker morto por falta de memória ou por um reboot, ou uma sessão do Claude que morreu dentro de um tmux vivo, nunca era detectado. Agora o cockpit o encontra. Ele salva o trabalho não commitado num branch rescue/<ticket>-<time>, num patch e num tarball, e depois dispara o worker de novo com um briefing que nomeia o resgate. Um worker que continua morrendo fica retido para uma pessoa (#7286).
• 🔴 Os workers começam na base da sprint. As worktrees ignoravam o branch guarda-chuva declarado pela sprint. Agora elas são cortadas dele, e create_worker pode nomear uma base (#7281).
• 🔴 Um NOT-GOLDEN só sobre o corpo do pull request pode ser reavaliado no mesmo head assim que o corpo muda. O worker não fica mais pausado para sempre (#7279).
• 🔴 flowforge merge fecha o ticket de que o pull request é dono. Um fechamento que falhou entra numa fila e é tentado de novo (#7287).
• Um GOLDEN novo faz merge pelo veredito. Antes ele esperava o fim de um recuo por erro do GitHub que pertencia a outra chamada (#7328).
• Uma revisão só é registrada como disparada depois que a rodada dela está aberta (#7336).
• Arquivos gerados não têm teto de linhas por arquivo. Um marcador no cabeçalho, linguist-generated ou um glob configurado os isenta (#7331).
• Todo briefing de worker traz as regras permanentes do seu projeto, de .flowforge/worker-brief.md, por exemplo um limite de memória para o seu executor de testes (#7327).
• Um worker disparado de novo não é um worker parado. O relay relê o tmux antes de recusar, e um novo disparo, por qualquer porta, revive a linha do worker (#7330).
• O seu próprio statusLine do Claude Code continua sendo seu. A FlowForge só ocupa esse espaço quando ele está vazio ou já é da FlowForge, e avisa uma vez (#7334).
• Um pull request de promoção ou de sincronização sempre leva um commit de merge, nunca um squash (#7329).
• blueprint amend grava um arquivo por emenda, então pull requests irmãos fazem merge sem conflito (#7332).
• Um worker cujo turno morreu num erro de API antes do primeiro pull request recebe uma cutucada para tentar de novo, e depois o ACE é avisado (#7333).
• Uma mensagem que você envia nunca é pintada fora do trilho do ACE. Retornos de carro e tabulações numa mensagem colada são normalizados antes da quebra de linha, e cada linha é presa ao trilho (#7338).
• Emitir de novo um plano emendado cria só as unidades novas, e não duplica todos os tickets (#7337). plans fire pode ser rodado de novo com segurança depois de uma interrupção (#7256).
• A verdade do board do War Room e a prontidão por ticket numa onda vieram do mesmo relatório; as duas estão acima (#7293, #7335).
• Da primeira semana do mesmo relatório: um pull request mesclado fecha só os tickets que declara (#6480). O board de ondas e o depends-audit leem um único elenco (#6510). Um ticket em que a sua lane já mexeu é disparado, com a evidência no briefing (#6487). create_worker só informa spawned depois de ver a sessão (#6481). flowforge review cleared <pr> pergunta sobre o head daquele pull request (#6478). Os guards de escrita do git e do GitHub julgam cada comando executado pelos seus próprios argumentos, não pela linha inteira (#6485). Uma recusa de ticket new --live nomeia primeiro a linha que falta (#6484). Um documento renderizado nunca perde o corpo em silêncio (#6482).

Entrar, e entrar de verdade

• 🔴 A tela de login ocupa a tela inteira. Ela era desenhada embaixo de uma parede de diagnósticos de inicialização. Agora ela é dona da tela alternativa, e todo diagnóstico continua no seu histórico de rolagem (#6506).
• 🔴 O campo de senha aceita digitação. A validação controla o envio, nunca a passagem de um campo para outro (#6509).
• 🔴 O login no desktop sempre termina, com um valor, um erro ou um tempo esgotado, nunca com um spinner girando para sempre (#6508).
• Um clique em login não é uma tomada de sessão. Entrar no seu próprio Mac não expulsa mais você (#6535).
• Entre no Claude Code sem terminal. Um menu faz o seu primeiro login ou troca de conta (#6548).

FlowForge Desktop, e Windows pelo WSL2

• 🔴 Windows, pelo WSL2. Uma instalação no WSL prepara sozinha o lado Windows: primeiro a verificação gráfica, depois os atalhos, depois um resumo do que ela pulou (#6524). flowforge desktop shortcut --windows coloca atalhos na Área de Trabalho e no Menu Iniciar pelo WSLg, e também os remove (#6523). O app tem um ícone do Windows em vários tamanhos (#6514), e há um guia de instalação (#6515). Isto é Windows pelo WSL2, não Windows nativo (#6520).
• O app desktop diz o que falta num Linux ou WSL limpo, em vez de abortar com um stack trace, e o flowforge doctor ganha uma linha desktop-gl (#6507). O ambiente do app chega ao cockpit que ele abre, e um documento que não abre diz por quê (#6511). Os empacotadores se recusam a embutir um flowforge com um embed vazio ou desatualizado (#6976).
• A prévia vira um leitor. Busque no documento com ⌘F, com cada ocorrência pintada e "3 de 12" (#7131). Dê zoom para um tamanho de leitura que fica lembrado (#6895), e ⌘+ ⌘− ⌘0 e Esc funcionam onde quer que o foco esteja (#6904). Volte para onde você estava, e leia "On this page" (#7128). A gaveta Documents mostra um título em cada linha e pode ser alargada (#7127). Uma divisão de tela sempre deixa espaço para ler o documento (#7114). Todo atalho está documentado (#7139).
• Ratifique na própria página. A faixa de portão ratifica o documento na tela, na revisão que você está lendo, com uma janela para desfazer (#7119). "Not yet" abre o ACE do próprio documento com o composer já preenchido, e o documento continua à vista (#7122, #7120). flowforge doc status responde se uma ratificação espera por estes bytes (#7113), e doc ratify --json é a interface para máquinas (#7112).
• A página cabe no painel. A página preenche o painel (#6897), o cromo é uma faixa única que se dobra (#6905), o botão THEME de um documento troca só aquele documento (#6892), e a prévia nomeia o projeto de cada documento (#6865).

Agentes, roteamento e a trilha de direitos

• Uma única fonte para o elenco. agents/manifest.yaml é a única fonte do elenco de agentes. Toda contagem, menu e skill de roteamento é gerado a partir dele (#6617, #6620, #6826). Uma porta de roteamento e um detector avaliam cada disparo (#6621), e agentes e skills ganham seu próprio portão de CI (#6619). A cadeia de design pode aninhar quatro agentes de profundidade (#6997).
• A trilha de direitos. Um agente só chega a um banco de dados vivo por flowforge db, sob uma permissão que você concede com flowforge grant, e cada permissão vai para um registro só de acréscimo (#6630). Clientes de banco de dados crus são roteados para essa porta por um parser de shell de verdade (#6628, #6697, #6694). O trabalho de release, de plataforma e de marketing recebe o mesmo tratamento (#6629, #6627, #6625), e toda definição de agente traz um bloco ## Authorisation (#6948). Toda negação do modo automático vai para um registro que o cockpit lê (#6607).
• Especialistas existentes, recortados. fft-devops-agent é refundado como o operador de plataforma (#6680). fft-content-strategist e fft-social-media são recortados, e a dupla de mídia paga opera todos os degraus de rastreamento (#6681). fft-medical para de trazer cinco fatos errados sobre faturamento de saúde (#6954).

O primeiro pacote opcional: recebimento-médico

• flowforge agents install recebimento-medico adiciona dois especialistas brasileiros em recebimento médico: fft-faturista (glosa, recurso, prazos, precificação; sempre com fonte citada) (#6967) e fft-tiss-xml (o padrão de troca TISS: validação XSD, versões, portais) (#6970). O pacote vem dentro de todo binário de release (#6972). Ele só é instalado quando você pede, sobrevive ao install --global, e o doctor o conta (#6978, #6981, #6982). As citações em PT-BR dele são conferidas contra as fontes (#6975). /agents lista os pacotes opcionais à parte, então a contagem principal nunca muda (#6962).

Menos pedidos de permissão, serviço mais estável

• Os workers de clientes rodam os verbos protegidos de plano e de ticket da própria FlowForge sem pedido de permissão (#7141).
• O macOS para de perguntar se a FlowForge pode acessar dados de outros apps. Os auxiliares do Claude Code agora começam na pasta da própria FlowForge, e não em / (#6893).
• Erros de licenciamento dizem o que são. Um erro de servidor aparece como erro de servidor, não como "verifique sua conexão" (#7078). A carência rotineira de licenciamento, de 29 por dia, não assusta mais você (#6528). O serviço por trás disso teve a sua tarefa mais pesada limitada e o seu heartbeat passou a ter tempo constante (#7086, #7099, #7094, #7291, #7290).
• Ctrl-O volta a ser a saída de emergência: o Claude Code na própria sessão do ACE, com um único controlador (#7259).
• Um reap não mata mais um cockpit saudável (#6657). A varredura de atualização só para um servidor de cockpit comprovadamente abandonado, e o nomeia (#6464).
• Os custos de tokens têm preço para os modelos em uso (#6543).

Planos, versões e o registro

• Os planos têm nome pelo que entregam. Uma única regra de nomes é imposta no lint, no fire e no land, e há uma renomeação segura (#6896). Os números de ADR passam por uma única porta verificada no servidor (#6903).
• flowforge backfill-dates --across deriva várias sprints como uma única agenda (#6483).
• As versões terminam. Um corte que fez o merge e depois morreu retoma no portão de CI da main (#6473). O corte registra a sua lane em cada camada que a carrega (#6477). release-ci --check respeita a política da lane (#7026).
• O doctor fala um vocabulário só. Toda linha usa seis marcas de veredito, com uma dica em cada uma que não é aprovação (#6679, #6960). Uma linha cc-release-watch acompanha as versões do Claude Code (#6986).
• Os relógios do cabeçalho voltaram. O relógio da sessão está no canto direito, e o relógio de contexto se centraliza no cabeçalho (#6486).

Colado

Colado é um termo do jiu-jitsu — uma posição está colada quando está justa, perfeitamente ajustada, sem espaço, com pressão total — e é o nome da família de portões da FlowForge que não deixam espaço entre a regra e o trabalho. Esta versão fecha estas brechas:

• Um merge não pode mais acontecer debaixo de um worker que ainda está editando o seu head (#7011).
• Dois condutores não podem mais disparar a mesma execução de onda: o lease decide, e o daemon o confere antes de cada disparo (#7260).
• Um épico não pode mais ser disparado como trabalho (#7107).
• Um pull request mesclado não pode mais fechar um ticket que não declarou (#6480, #7287).
• Um veredito não pode mais ser gasto num branch que ele nunca julgou (#6475, #7302).
• Um disparo não pode mais informar um worker que não existe (#6481).

Estudos e planos

Nada abaixo está construído ou entregue. Cada item aparece aqui só como o que é.

• Team Tier 1.0: o estudo, a paridade nativa da FlowForge com GitHub e Jira, o escopo do console e os planos emitidos. Nenhum recurso de Team sai nesta versão (#7115, #7130, #7138, #7245).
• ADR-0141, o modelo de sessão da FlowForge, sobre o qual as correções de login foram construídas (#6505). The pipeline delivers, not only detects, o registro de decisão por trás da tabela de atores (#6622).
• O estudo da prévia (#6744), o módulo de briefing (#6695), ForgePlays em telas web (#6950), o estudo de agentes da FlowForge (#6916), Idea to Investor e Brand Identity Creation (#6745), e o plano de lançamento (#7283).

Agentes — 44 → 52: a organização jurídica, o operador de release, a dupla de banco de dados, a liderança de marketing, DevRel e marketing de produto

• Adicionado fft-legal-architect — a liderança jurídica: pergunta antes de redigir, decide qual lei e quais contratos um negócio precisa, gradua cada questão e concilia Brasil↔EUA.
• Adicionado fft-legal-br — direito de software brasileiro: contratos, licenças, termos e privacidade sob a LGPD, o Marco Civil, o CDC e a Lei do Software; marcas no INPI e registro de software.
• Adicionado fft-legal-us — direito de software dos EUA: contratos, licenças, termos e privacidade sob CCPA/CPRA, COPPA, CAN-SPAM e FTC §5; USPTO, Copyright Office, DMCA, DTSA.
• Adicionado fft-release-engineer — o operador de release: conduz uma versão desde uma lane pronta até os clientes a terem — notas, pacote da carta, o corte até o seu consentimento, tag, staging, verificação por nome, ensaio, paridade de instalação. O consentimento e a promoção continuam sendo seus (#6682).
• Renomeado fft-database → fft-database-architect — a liderança do modelo de dados, agora só de design: o banco, o ERD, quem pode ler e escrever cada tabela, e o plano de migração com o caminho de volta. Ele não tem shell e nunca abre uma conexão (#6683).
• Adicionado fft-dba — o único agente que pode mexer num banco de dados vivo, e só por flowforge db: ensaia cada migração numa cópia descartável, lê a produção só para leitura, aplica uma mudança só sob a sua permissão e relata o que fez (#6683).
• Adicionado fft-marketing-architect — a liderança de marketing: decide o que a sua empresa diz, para quem, em que ordem e por quais lanes, e escreve um único briefing de lançamento contra o qual toda lane de marketing planeja. Ele redige; nunca publica nem gasta. A mídia paga mantém a sua própria liderança para toda decisão de campanha (#6688).
• Adicionado fft-devrel — relações com desenvolvedores, sob a liderança de marketing: quais histórias técnicas contar no Hacker News, no Reddit, no Product Hunt e no Discord, e com que prova; pesquisa de criadores com rascunhos pessoais para você enviar. Ele nunca pede votos, nunca esconde para quem trabalha e nunca posta como uma pessoa real. Ele redige; uma pessoa publica (#6690).
• Adicionado fft-product-marketer — marketing de produto: mantém a lista do que a sua empresa pode dizer, cada afirmação com a sua evidência, conferida de novo a cada versão, e monta a partir dela battlecards, o kit de um negócio, estudos de caso e o anúncio de cada versão. Ele nunca decide um preço nem nomeia um concorrente em nada que um comprador leia. Ele redige; nunca publica (#6691).
• A organização jurídica é a #6458. As equipes de sucesso do cliente, de mídia paga e de análise de dados já estavam no elenco antes desta versão, e não mudaram em número.

Um passo de configuração

• Feche e abra de novo cada cockpit aberto depois de atualizar, para que a nova Fleet, a fila de Workers, o board Waves e o login sejam os que estão rodando.
• No Linux ou no WSL, instale o runtime GLES se o app desktop se recusar a iniciar. É libgles2 no Debian/Ubuntu, libglvnd-gles no Fedora/RHEL e libglvnd no Arch. A linha desktop-gl do flowforge doctor nomeia o pacote antes do app (#6507).
• Opcional: coloque as regras permanentes do seu projeto para os workers em .flowforge/worker-brief.md (#7327), e instale o pacote de recebimento médico com flowforge agents install recebimento-medico se precisar dele (#6978).

Ainda não

• Dois dos cinco remédios só observam. order-rebase e dispatch-review rodam em sombra, e reap-vanished só registra. Eles só vão agir quando o histórico deles merecer, e até lá um pull request em conflito ou uma revisão devida ainda precisam do ACE ou de você (#6959, #6984, #7037).
• Uma linha única e longa colada no ACE (#6504) nunca foi reproduzida. Um defeito parecido foi encontrado e corrigido: uma mensagem colada com quebras de linha era pintada por cima do painel Workers (#7338). Se você ainda vir o transbordamento de linha única, uma captura de tela, e em qual app ela foi tirada, resolve a questão.
• A correção do GLES não foi confirmada num contêiner limpo. A sonda vem como um script que qualquer pessoa com um runtime de contêiner pode rodar em cerca de um minuto (#6507).
• Resta um furo na leitura paginada, preso por um teste. Uma página cheia do GitHub em que toda linha é um pull request ainda encerra a leitura (#6510).
• O Team Tier é só estudos e planos nesta versão (#7115).

Atualizar

• flowforge update numa instalação existente, ou curl -fsSL https://get.flowforgesoft.com/install.sh | sh para uma nova. Os dois gravam o mesmo binário de release em /usr/local/bin e em ~/.flowforge/bin, juntos. flowforge update --repair reinstala os arquivos instalados sem a rede. Depois, feche e abra de novo cada cockpit aberto.

---

Os números desta página são uma leitura pontual: flowforge release stats v1.2.26 --ref origin/release/1.3.0 no head nomeado em NUMBERS.md §1, intervalo v1.2.25 (36f3befbf, tag de 2026-09-21T17:14:15-04:00) → esse head. A v1.2.26 ainda não tem tag, então estas cifras são derivadas de novo na tag, antes do corte.