v1.2.32

Read in English →

Oi,

Toda mudança em produção deve ser uma confirmação, e um override num merge deve esperar por uma pessoa. É disso que esta versão trata. Em Settings ▸ Databases, o interruptor que permite mudanças e o login do dono agora são confirmações (#8914). Uma gravação de dados única mostra as contagens dela antes de você aprovar (#9087). Quando você atualiza, os itens antigos do Needs you passam para as confirmações deles (#9077). Um override num merge é recusado quando há uma sessão do Claude Code acima dele (#8953), e um épico roda em Waves como uma sprint (#6166).

Mais duas coisas destes dois dias. Uma atualização interrompida não pode mais trancar você para fora dos seus próprios registros (#8870). E quando o orçamento compartilhado do GitHub se esgota, o Fleet e a Merge Queue dizem isso numa linha (#8921).

Teste três coisas primeiro: aperte S para abrir Settings e vá até a aba Databases para ver o interruptor de mudanças e o login do dono (#8914); aperte w para abrir Waves e peça ao ACE para iniciar um épico (#6166); e depois feche e abra de novo cada cockpit aberto e o FlowForge Desktop. Antes de começar, leia Ainda não no fim: três limites continuam em aberto (#9141, #8732, #8731, #9048). 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

Toda mudança em produção é uma confirmação, e um override espera por uma pessoa. 74 pull requests mesclados desde a 1.2.31. Esta versão termina o que a 1.2.31 começou. Settings ▸ Databases agora oferece o interruptor de mudanças e o login do dono como confirmações. Uma gravação de dados única mostra as contagens dela antes de você aprovar. Quando você atualiza, os itens antigos do Needs you passam para as confirmações deles. Um override num merge é recusado quando há uma sessão do Claude Code acima dele, e um FAIL de um especialista segura o merge. Um épico roda em Waves como uma sprint. Um orçamento do GitHub esgotado diz isso numa linha. As sprints de um projeto Jira chegam à FlowForge (ainda não lidas num site real). Uma atualização interrompida não pode mais trancar você para fora dos seus registros. O que ainda não está pronto está listado no fim.

Uma confirmação para toda mudança em produção

• 🔴 Settings ▸ Databases oferece o interruptor de mudanças e o login do dono como confirmações, e "Last check" diz a verdade. "Allow changes for production" pede uma janela (1 hora, 1 dia, ou até você desligar), um motivo e o ticket. Você a aprova em Needs you; num Mac, o FlowForge Desktop pede o Touch ID ou, sem ele, a senha de login do Mac, e no Linux a aprovação não é assinada, como na 1.2.31. Então o processo da própria FlowForge liga o interruptor, e nenhum comando de terminal o liga. "Save the owner sign-in" abre um campo seguro para a senha do dono. "Switch changes off" é só seu. "Last check" lia a instrução mais recente que qualquer pessoa rodou: uma única instrução recusada numa tabela da qual o login somente leitura é mantido de fora fazia o banco de dados inteiro aparecer como "can't read". Uma instrução recusada numa conexão que funciona agora conta como uma checagem que funcionou, e "Check again" roda uma leitura real (#8914).
• 🔴 Uma gravação de dados única (um backfill, um linker, uma correção de dados) é uma confirmação que mostra as contagens da simulação antes de você aprovar. fft-dba a prepara, você aprova uma vez, e o processo da própria FlowForge a executa e a lê de volta. Não há script para colar nem chave de dono para guardar. flowforge db dry-run lê as contagens e diz onde as leu, produção ou uma cópia de ensaio. Uma simulação vale por 24 horas, e uma gravação sem uma simulação recente e comprovada é recusada (#9087).
• 🔴 Quando você atualiza, os itens antigos do Needs you passam para as confirmações deles. Passos que já foram feitos se fecham com a evidência. Passos pendentes passam para a confirmação que os executa. Um passo que ainda não tem confirmação nomeia o ticket que vai construir uma. flowforge install --global roda isso em toda atualização, e flowforge founder-step migrate mostra uma prévia. Numa cópia da lista do próprio fundador, 52 itens viraram 23, e os 42 passos antigos de comando para colar viraram nenhum (#9077).
• Um passo pendente se fecha sozinho quando o mundo prova que ele está feito. Uma confirmação em pacote fecha os passos que ela executa, e flowforge founder-step attach dá a um passo pendente a evidência que o fecha. A um passo novo se pergunta como saber que ele está feito. flowforge db verify agora sai com 8 quando a leitura de volta não é verdadeira; antes, saía com 0 fosse o que fosse que lia (#8905).
• Uma confirmação de dono falha diante de qualquer mudança inesperada nos poderes de um papel. Os poderes de cada papel são lidos antes e depois, então uma mudança construída em tempo de execução dentro de um bloco DO é pega (#8911).
• A porta da plataforma lê e liga a recuperação em um ponto no tempo (PITR) de um projeto Supabase. flowforge platform pitr read diz se ela está ligada, a retenção, e o ponto de restauração mais antigo e o mais recente. Ligá-la é uma confirmação: você a aprova, e o agente da plataforma a executa sob uma concessão de uso único de no máximo uma hora (#8730).

Um override espera por uma pessoa

• 🔴 Um override num merge precisa de uma pessoa comprovada pela tabela de processos da máquina. Um comando com uma sessão do Claude Code acima dele é recusado, diga o que disser o ambiente dele, e o mesmo vale para uma árvore de processos que não pode ser lida. A confirmação Bypass do cockpit é um token de uso único, preso ao cockpit que o emitiu. Uma rota continua aberta: um arquivo de inicialização plantado pode relançar a chamada num painel de terminal desanexado, e esse painel passa por uma pessoa (#8953, #9127).
• Desligar o portão de proveniência da revisão conta como override e também precisa de uma pessoa (#8954). O loop hands-free não honra nenhum override: cada um é descartado, registrado e narrado (#8939).
• O merge do ACE roda como uma chamada à parte, e só a sua confirmação o autoriza. O ACE não pode passar um override nem levantar um freeze por uma ordem sua falada. flowforge doctor tem uma linha merge-permission (#8874).
• O motivo que um agente acrescenta ao seu freeze de merge é achatado numa linha simples, limitada a 200 caracteres, e todo freeze é registrado (#8957).
• Os guardas leem uma flag antes do subcomando como a linha de comando lê, então flowforge review --repo x/y verdict 1 não passa mais batido numa sessão de worker (#8970). O guarda que impede um agente de lhe entregar um segredo ou um comando para colar pega mais formatos (#9012).
• O veredito de um especialista segura o merge. Um GOLDEN de código não libera mais uma ponta que um especialista reprovou (#8969). A liberação de um especialista só conta quando a FlowForge a despachou e a registrou com flowforge review specialist <pr> --agent <name> (#9028).
• Um worker estaciona o PR dele para revisão só depois que a própria pré-checagem passa nas regras do revisor. A pré-checagem não acha nenhum CRITICAL nem MAJOR na ponta, e é postada no PR (#8472). Um estacionamento ou uma pré-checagem só conta com o próprio comentário no PR, e um worker não pode escrever nenhum dos dois registros à mão (#8949).
• flowforge doctor tem uma linha permission-hygiene. Ela nomeia toda regra de permissão que deixa um agente rodar código de escolha dele sem perguntar. Nunca imprime uma regra, e a FlowForge nunca edita as suas regras (#8940).

Os épicos rodam em Waves

• 🔴 Um épico (◉) começa e entra na fila como uma sprint. flowforge waves start --epic N o inicia (--dry-run mostra o plano e não inicia nada), e flowforge waves queue add --epic N o põe na fila. O ACE pode iniciá-lo, enfileirá-lo, pausá-lo e pará-lo. Ele roda ao lado de outras execuções e só é recusado onde os tickets se sobrepõem (#6166).
• Ele avança uma wave depois da outra conforme os tickets dele são mesclados, e nunca inicia um filho cujo bloqueador fora do épico ainda esteja aberto. Todo ato e toda retenção nomeia o épico (#6167). A tela própria dele diz ◉ Epic #N · <title>, conta os filhos mesclados antes de ele começar e nunca mostra carregando como vazio (#6164). Board, Waves e Gantt leem um único escopo tipado (#6169).
• Correções em Waves. Uma execução pausada aparece como pausada na faixa do cockpit, e a linha conta as execuções pausadas (#8936). Slots livres não ficam mais parados enquanto waves esperam pelos pisos umas das outras: quatro waves e três slots livres agora iniciam três (#8943). "Add to the queue" roda de novo uma sprint terminada que novos tickets reabriram, e nunca nomeia uma letra oculta (#8929). "Start now" numa sprint reaberta inicia uma nova execução (#8980).
• O guia da Wave Screen foi reescrito, em inglês e em português (#6168).

O orçamento do GitHub, dito com clareza

• Quando o orçamento compartilhado do GitHub se esgota, o Fleet e a Merge Queue dizem isso numa linha: pausado, por quê, quando volta e quem o gastou. Por exemplo: ⚠ GitHub budget spent — background reads paused to protect merges · resumes 05:12 (#8921).

Planos que chegam inteiros

• Um plano precisa entregar o pacote inteiro, ou plans lint e plans fire o recusam. O pacote tem quatro partes: como é imposto, a parte do ACE, a migração dos dados existentes e uma prova no estado real. Cada parte nomeia o trabalho que a entrega, ou diz "Not applicable" com um motivo. A recusa vem uma vez por problema, com a correção dele (#8913, #8988, #8994).
• Regra #39: prove no estado real. Um ticket de funcionalidade ou de bug é recusado sem uma seção Real-state Proof, e o revisor carimba a evidência no GOLDEN (#8908).

Versões para o seu próprio projeto

• Os verbos de release leem o formato do projeto em que rodam. Um projeto web ouve falar da própria versão e nunca da versão da FlowForge. flowforge release cut --dry-run imprime as checagens só da FlowForge como "stands down", e release promote fora do repositório da FlowForge precisa de --bucket e --alias (#8902).
• flowforge release tag põe tag numa versão de cliente entregue. A tag é anotada. --commit <sha> --evidence <text> preenche um commit mais antigo, um merge simples de pull request conta como corte, --no-push para antes do push, e --github-release cria o release no GitHub onde nenhum pipeline o faz. Toda recusa é impressa (#8901).

Jira: as sprints chegam

• As sprints de um projeto Jira agora chegam à FlowForge. A FlowForge encontra os quadros do projeto uma vez por sessão e lista as sprints abertas de todo quadro que as tem. Uma sprint com datas aparece como sprint; uma sem datas aparece como milestone, e nenhuma data é inventada. O campo Sprint de uma issue vira o milestone dela. Num projeto com vários quadros de equipe, o nome de cada sprint leva o nome do quadro dela. Uma leitura que falha é um erro, nunca uma lista vazia. Isso foi conferido contra as respostas documentadas do Jira Cloud: nenhum site Jira real foi lido ainda, e as visões de quadro e da War Room no Jira vêm a seguir (#7210).

Backups: a leitura chega, a tarefa não está armada

• Uma leitura que diz quando uma noite de backup falha. flowforge platform backup status lista as cópias noturnas e horárias de uma stack de backup registrada e nunca lê um backup em si. Ele informa "missed" (nenhuma noite concluída em 26 horas), "small" (menos da metade da mediana de até sete noites anteriores) ou "unknown". As linhas db-backup e db-pitr do flowforge doctor dizem o mesmo, e uma frase do Needs you diz, por exemplo, "Your live database has not been backed up for 30 hours." Um projeto sem stack de backup não mostra nada (#8732).
• O banco de dados de produção da própria FlowForge tem a tarefa de backup noturno construída, não armada. A tarefa e o papel somente leitura dela estão escritos. O armazenamento e o usuário de confirmação do armazenamento estão escritos e não aplicados, e as duas confirmações que armam a tarefa ainda não estão construídas, então nenhuma noite rodou (veja Ainda não) (#8732, #9021, #9022).

Correções

• 🔴 Uma atualização interrompida não pode mais trancar você para fora dos seus próprios registros. Cada atualização do seu armazenamento de auditoria local agora é gravada junto com a própria checagem, então uma falha, um encerramento forçado ou um disco ocupado entre as duas não pode mais deixar o armazenamento recusando toda abertura, o que parava o ledger, os direitos, as concessões, Settings ▸ Databases e as aprovações do Touch ID. Um armazenamento que já ficou preso assim se repara na próxima abertura, mas só quando o que ele guarda bate exatamente com a atualização; qualquer outra divergência continua recusada como adulteração (#8870).
• Um PR revisado não espera mais por um worker que só está em loop no próprio goal. Quando um worker estacionou o PR dele e a branch está limpa no commit revisado, o merge segue mesmo com a sessão do worker ainda rodando. Ninguém precisa mais limpar o goal do worker à mão. Um worker com mudanças não salvas, um commit ainda não enviado ou uma branch fora do commit revisado ainda segura o merge até que ele envie ou descarte esse trabalho (#8844, #8875, #8918).
• O goal de um worker é cumprido pelo PR que a revisão liberou e virou para ready (#8967). O ACE pode responder a uma pergunta de um worker que não é sua para decidir com flowforge worker answer, e limpar um goal estacionado com flowforge worker goal-clear. Todo ato é registrado (#8875).
• As chamadas ao servidor git do loop diário passam para a interface comum de servidores git, a base do GitLab: o merge, o down-merge, o backstop de branch e as leituras de PR da War Room. O GitHub responde como antes. A sonda de contrato numa instância do GitLab ainda é devida (#7208, #6661).
• O rodapé do site tira um ícone do LinkedIn que apontava para a página de outra empresa (#8015).

Estudos, registros e alicerces

Nada disto muda o que você roda. Cada item aparece aqui só como o que é.

• O banco de dados de produção da própria FlowForge: o armazenamento de backup e o usuário de confirmação que o arma, escritos na conta da AWS que já usamos e não aplicados (#9021, #9022); o desenho do backup e a emenda da ADR dele (#8732, #9020); o runbook da recuperação em um ponto no tempo (#8731); a metade do banco de dados do simulado de restauração, provada num ensaio (#8733); a janela de retenção levada para esta linha (#7618); a confirmação de uma migração pendente, com o brief e o ensaio dela (#8909); a ordem das migrações de produção da 1.2.31 (#8818); e três correções de segurança nos scripts que aplicam as migrações de dono: variáveis herdadas de roteamento do banco de dados são recusadas e cada passo roda a partir de uma cópia com hash (#8876), a senha passa por um arquivo privado e nunca pela linha de comando (#8782), e Ctrl-C interrompe um passo (#8932).
• Briefs de design à espera de uma decisão: o deploy de uma edge function como uma confirmação (#9088), e duas listas com dois nomes (#8906).
• A carta de versão do console, percorrida do jeito do cliente: 17 passos, 16 lacunas registradas (#8881). A página do roadmap da 1.3.0 nomeia a sprint #257 (#8104).
• Checagens mantidas verdes: os guardas do site e das migrações (#8995, #8974, #8966, #6169, #9167). O promote da 1.2.31 está registrado (#8833).
• Estas notas de versão e a carta (#8917, #9181).

Agentes — 53: três mudaram

Nenhum agente foi adicionado ou removido. Três definições mudaram:

• Mudou fft-code-reviewer — carimba REAL-STATE-EVIDENCE no GOLDEN: uma mudança que encontra um estado real precisa de uma execução somente leitura nesse estado, uma fixture não basta, e um FAIL bloqueia o GOLDEN (#8908).
• Mudou fft-dba — nunca liga o interruptor de mudanças por conta própria: ele diz a você a confirmação em Settings ▸ Databases (#8914). Ele prepara uma gravação de dados única como um movimento com a simulação dele, flowforge db dry-run, e a confirmação mostra as contagens a você (#9087).
• Mudou fft-devops-agent — lê flowforge platform backup status pela porta da plataforma (#8732).

Ainda não

• O S do cockpit num quadro de épico ainda não inicia o épico. Inicie ou ponha na fila pelo ACE, ou com flowforge waves start --epic N (#9141).
• O backup noturno da própria FlowForge está construído, não armado. O armazenamento dele está escrito e não foi aplicado, e as duas confirmações que o armam, uma que monta o armazenamento de backup e outra que liga o login de backup, ainda não estão construídas. A recuperação em um ponto no tempo ainda não está ligada (#8732, #9021, #9022, #8731).
• Um simulado real de restauração ainda não rodou. Só a metade do banco de dados está provada, num ensaio (#9048).

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 e o FlowForge Desktop.