Envio e revisão

A página My submissions lista as suas submissões uma página por vez (25, 50 ou 100), da mudança mais recente para a mais antiga ou por nome, com um link para cada status que você tem e a contagem de cada um; as arquivadas só aparecem em Archived. Busque por parte do nome do item ou escolha um tipo; os dois aparecem como chips, e os links de status mantêm a ordenação e o tamanho da página.

Withdraw aparece na sua própria submissão até ela ser lançada: como rascunho, aguardando revisão, devolvida para mudanças ou aprovada. Fica no cabeçalho da página dela, na linha dela em My submissions e na página de revisão dela. Uma versão lançada não pode ser retirada da revisão; em vez disso, use Deprecate ou Yank nela. Ao retirar, o app pergunta o que fazer com ela:

• Archive (o padrão): ela sai da revisão e da lista de My submissions. Só você a vê, no filtro Archived. Restore a traz de volta como rascunho, com os arquivos, as iterações e a conversa; o próximo envio é a próxima iteração dela.
• Delete for good: ela é removida com os arquivos e o histórico, e isso não pode ser desfeito. Essa opção só é oferecida enquanto nenhum revisor tiver comentado ou decidido sobre ela; depois disso, a conversa também é um registro para os revisores, então ela só pode ser arquivada. Uma submissão arquivada pode ser excluída do mesmo jeito, na página dela ou no filtro Archived.

Nos dois casos, o nome fica livre: uma submissão arquivada, como um rascunho, não o reserva. O que depende dela fica marcado como bloqueado enquanto ela estiver arquivada, e como não enviado depois que ela for excluída. O log de auditoria guarda um registro de cada exclusão.

Um rascunho pode ser salvo com problemas, mas o envio espera até não haver nenhum. No editor, um ícone vermelho depois do nome de um arquivo indica que ele tem erros, e um âmbar, só avisos: clique nele para vê-los, e clique em um deles para ir até a linha. O resumo ao lado do nome do item conta todos. Submit for review fica desativado enquanto houver erros ou mudanças não salvas (marcadas com ● Unsaved changes ao lado do nome). A caixa de diálogo de envio então verifica:

• o manifesto e os arquivos são válidos para o tipo e estão dentro dos limites de tamanho;
• o nome está livre: nenhum item publicado, e nenhuma submissão aberta de outra pessoa, o usa;
• cada dependência é permitida para o tipo e está lançada com uma versão compatível, ou está em revisão: nesse caso, a versão dela é verificada quando esta submissão for lançada. Uma dependência que é só um rascunho ainda não conta;
• para uma proposta de mudança: o tipo é o do item, ela muda alguma coisa e nenhum conflito de rebase ficou em aberto.

Um rascunho sem nenhum desses problemas está pronto. A página My submissions marca cada rascunho como Ready, ou mostra quantos problemas faltam corrigir, e o envio em lote só leva os prontos. Os avisos aparecem, mas não impedem o envio.

Em My submissions, cada rascunho, e cada submissão devolvida para mudanças, tem uma caixa de seleção quando está pronto. Marque os que quiser, ou Select all ready, e depois Submit selected: o app os lista e pede confirmação antes, depois envia cada um separadamente e diz o que aconteceu com cada um. Um rascunho que deixou de estar pronto nesse meio-tempo, porque outra pessoa enviou o mesmo nome, diz por quê, e os outros seguem. Select all ready pega todos os rascunhos prontos, inclusive os de outras páginas ou escondidos por uma busca.

Em um terminal, com rmk:

rmk submit --all --dry-run          # what's ready, and what's in the way of the rest
rmk submit @team/reviewer @team/style
rmk submit --all                    # every ready one, after asking

• O nome de um item indica o seu rascunho aberto dele; se houver mais de um, indique-o pelo id que aparece no endereço. --all indica todos os seus rascunhos e todas as suas submissões devolvidas para mudanças, as 100 mais recentes por vez.
• Ele verifica primeiro, mostra Ready to submit e Not ready com cada problema, e pede confirmação. Sem um terminal, ele precisa de --yes.
• Ele sai com 0 quando tudo o que você indicou foi enviado, e com 1 quando algo não foi.

Na sua ferramenta de IA, o servidor MCP do registro faz o mesmo: check_drafts mostra o que está pronto, e submit_drafts, que a sua ferramenta pede para você confirmar, faz o envio.

Os seus rascunhos dos quais um rascunho selecionado depende são incluídos e vão primeiro: assim que estiverem em revisão, o que os usa pode ser enviado. Marcar um rascunho em My submissions marca esses também; o rmk submit os lista em Included, e --no-deps os deixa de fora. O que acontece depois está em Dependências em revisão.

Os revisores também podem aprovar em lote: Aprovar em lote.

Uma submissão pode depender de itens que ainda não foram lançados, desde que estejam em revisão: uma skill e o agente que a usa passam pela revisão juntos, em vez de uma rodada para cada um.

• Waits on (aguarda): em My submissions e na fila de revisão, um ícone de link com um número marca o que uma submissão aguarda: âmbar enquanto as dependências estão pendentes, vermelho quando uma delas está bloqueada; clique nele para ver cada uma. A página de revisão diz isso por extenso, como Waits on @team/github (in review). No editor, cada dependência tem um selo âmbar ao lado do nome até ser lançada, e um vermelho se estiver bloqueada.
• A aprovação não espera: cada item recebe a própria revisão, e os revisores veem a marcação.
• O release espera: Publish fica desativado até que todas as dependências sejam lançadas, e a faixa de versões é verificada contra a versão que cada uma recebeu. Lance as dependências primeiro.
• Bloqueado: quando uma dependência é rejeitada ou arquivada, o que depende dela fica marcado como bloqueado, também mais abaixo em uma cadeia. Remova-a das dependências ou dependa de outro item. Uma nova submissão com o mesmo nome desfaz o bloqueio.
• Rejeitar uma dependência: a caixa de diálogo de rejeição lista o que depende dela e oferece Request changes on them too, ativado por padrão, com uma mensagem própria. Cada uma é uma decisão separada, registrada com a rejeição como causa. Uma submissão do próprio moderador é pulada e indicada pelo nome. Ao retirar uma submissão sua, o app diz quantas dependem dela.

Os revisores encontram as submissões em Reviews, em quatro abas: Needs review e Waiting on the author (envio mais antigo primeiro), To release (aprovação mais antiga primeiro) e Decided (mais recentes primeiro). Toda aba é paginada, 25, 50 ou 100 por vez, com o total. Ordene pela data da aba ou pelo nome do item nos cabeçalhos das colunas, e encontre submissões por parte do nome do item ou do autor, ou por tipo; os filtros aparecem como chips.

Para cada submissão, os revisores leem:

• O que ela pode fazer: sinalizações de risco calculadas a partir dos arquivos, como um hook e o comando que ele roda, um servidor MCP, regras de permissão, arquivos executáveis, scripts de shell e endereços web. O autor não pode defini-las nem escondê-las. As sinalizações descrevem; o revisor decide.
• As mudanças desde a última iteração, ou todos os arquivos na primeira, do jeito que a página do item mostra os de uma versão: os arquivos em uma árvore ao lado do que você escolher, cada arquivo alterado marcado como adicionado, alterado ou removido, o Markdown renderizado com o código-fonte a uma aba de distância. O link de uma sinalização de risco abre o arquivo dela na linha certa. Os arquivos em .ronne/, como o layout de um canvas, não são lançados, então não aparecem.
• As verificações e a conversa com o autor.

• Approve: basta uma aprovação de um moderador ou do root que não seja o autor. Ela vale para a iteração que você está vendo: se o autor enviar uma nova enquanto isso, a aprovação não é concluída, e você vê a nova iteração primeiro.
• Request changes: a submissão volta para o autor, com o que corrigir. Uma submissão aprovada também pode ser devolvida, até ser lançada.
• Reject: a submissão é fechada, com o motivo. Quando outras submissões dependem dela, a caixa de diálogo as lista e oferece pedir mudanças nelas também (veja Dependências em revisão).
• Override: o root pode aprovar a própria submissão. Isso fica marcado como override na conversa e no log de auditoria, com ou sem motivo.

A aprovação, incluindo o override, aceita uma mensagem opcional. Pedir mudanças e rejeitar exigem uma, para que o autor saiba o que corrigir ou por que a submissão foi fechada: ele a vê no topo da página da submissão e abaixo do nome dela em My submissions. Toda decisão é registrada na conversa e no log de auditoria.

Onde ficam: em Reviews, cada linha de Needs review termina com Request changes e Reject, e cada linha de To release com Request changes. Todas as decisões ficam no cabeçalho da página de revisão de uma submissão, que se abre pelo nome dela. Para aprovar várias de uma vez, use Approve selected.

A sua própria submissão: as decisões aparecem, mas desativadas: outro moderador ou o root decide. O root também tem Approve (override) nas próprias submissões. Uma proposta que precisa de rebase pode ser devolvida ou rejeitada, mas não aprovada até passar pelo rebase.

Em Reviews, em Needs review, cada submissão que você pode aprovar agora tem uma caixa de seleção. Marque as que quiser, ou Select all, e depois Approve selected. Select all abrange a página que você está vendo: mostre 100 por página, ou filtre antes, para aprovar mais submissões de uma só vez.

• Algumas não podem ser selecionadas, e a caixa de seleção delas diz por quê: a submissão do próprio moderador (outro revisor a aprova), ou uma proposta de mudança desatualizada, em que o autor precisa fazer rebase primeiro.
• Na confirmação, a lista tem rolagem própria: filtre-a por nome, tipo ou autor, e desmarque as que quiser deixar de fora.
• A confirmação lista primeiro as que têm sinalizações de risco, com cada sinalização nomeada, para que nada arriscado passe despercebido. As do próprio root são marcadas: elas são aprovadas como overrides.
• Uma única mensagem opcional vai em todas as aprovações, como se fosse digitada em cada página. Deixe-a vazia para não mandar nenhuma.
• Cada uma é aprovada separadamente e registrada como uma aprovação normal na conversa dela e no log de auditoria. Uma que tenha sido decidida por outra pessoa, retirada ou que tenha ficado desatualizada nesse meio-tempo é reportada, e as outras são aprovadas mesmo assim.

Pedir mudanças e rejeitar continuam sendo uma submissão por vez, já que cada uma precisa da própria mensagem: cada linha tem essas ações. O release continua sendo feito a partir de cada submissão aprovada.