Gerenciadores Paralelos de Funcionalidades

O que Gerenciadores Paralelos de Funcionalidades faz?

Use a mesh Cotal ativa como uma hierarquia:

• A sessão atual é o coordenador. Ele cria isolamento, define políticas, monitora o progresso e retransmite decisões. Ele não duplica implementação ou revisão do painel.
• Cada funcionalidade recebe um gerenciador enraizado em seu próprio worktree Git e branch. O gerenciador é responsável pelo ciclo completo: plano -> implementação -> revisão -> teste -> commit.
• Cada gerenciador cria três ou mais pares somente leitura/revisão em um canal dedicado: engenheiro, segurança e crítico como mínimo.
• Perto do portão final, cada gerenciador adiciona um revisor frio independente, instruído sob a skill cold-review, que é a fonte única para como esse assento é instruído, isolado e avaliado. É um controle sobre o painel, não um quarto painelista.

Modelos: painéis entre fornecedores são uma regra de correção, não uma preferência

Nenhum dois assentos cujo acordo seja crítico pode compartilhar a mesma família de modelos. Uma descoberta confirmada por um assento da mesma família daquele que a fez é um eco, não uma confirmação. Um painel de três revisores do mesmo modelo aprovou um cabeçalho contendo um defeito que todos os três perderam, e o que o trouxe à tona foi uma leitura com enquadramento diferente, não um quarto verificador.

Declare dessa forma, não como uma contagem de cabeças. Disponibilidade é uma propriedade do momento, não do fornecedor: o mesmo modelo entrou e entregou em uma hora e falhou ao entrar na seguinte, no mesmo host com as mesmas ferramentas. Uma regra formulada como "N fornecedores distintos" é insatisfatível em uma frota degradada e silenciosamente, e uma regra que pode ser quebrada pelo relógio é silenciosamente ignorada em vez de obedecida. cold-review carrega a ordem de degradação e o piso.

Fixee o modelo explicitamente no spawn E na persona, porque capacidade não registrada é efetivamente não avaliada: um revisor cujo esforço ou modelo ninguém registrou produz um veredito que ninguém pode ponderar depois.

Os gerenciadores podem executar um modelo mais forte que seus revisores. Os revisores não devem executar o mesmo modelo que o coordenador, para que o painel não possa herdar os pontos cegos do coordenador.

Verifique os identificadores exatos do modelo no catálogo do conector antes de criar, e trate um nível de esforço de raciocínio declarado como não verificado até que um assento realmente tenha iniciado com ele: um catálogo pode declarar níveis que o provedor recusa, e um nível recusado mata o assento na inicialização.

Regras rígidas

• Nunca mude o branch do coordenador. Crie worktrees a partir de uma base commitada nomeada.
• Um gerenciador por funcionalidade, um revisor por canal do painel e um revisor frio independente por funcionalidade. Selecione o contato e destino desse assento sob cold-review. Um destino de arquivo é uma alternativa apenas por norma e não pode satisfazer um portão que exija identidade de postagem atestada pelo broker. Nenhuma instância irmã ou fan-out de testador, a menos que o usuário solicite.
• Apenas gerenciadores editam seu worktree de funcionalidade. Revisores apenas leem, executam verificações não mutáveis e postam descobertas com referências de arquivo/linha.
• Cada funcionalidade usa um canal de painel, review.<feature-slug>, mais um canal de registro frio dedicado, review.<feature-slug>.cold-record. Mantenha confirmações e conversas de status fora do canal do painel; use-o para planos, descobertas, disposições fundamentadas, solicitações de revisão de código e resultados finais.
• O revisor frio independente não está nesse canal. Seu isolamento, instrução e relatórios são de propriedade de cold-review; imponha-os lá em vez de reafirmá-los por canal.
• Decisões de produto/design viajam por DM: gerenciador -> coordenador -> usuário -> coordenador -> gerenciador. Um gerenciador não deve adivinhar através de uma escolha consequencial não resolvida.
• Nunca faça merge, push, abra um PR ou remova worktrees, a menos que o usuário solicite.
• Nunca perturbe o broker mesh ativo. Testes usam espaços descartáveis e portas altas aleatórias; mate processos de teste por PID exato, nunca pkill amplo.

1. Estabeleça a matriz de funcionalidades

Para cada funcionalidade solicitada, escolha e registre:

Campo	Exemplo
Funcionalidade	exportação de canais
Slug	channels-export
Branch	feat/channels-export
Worktree	caminho irmão como Cotal-feature-channels-export
Persona do gerenciador	mgr-channels-export
PR	número exato, ou none até que um exista
Canal	review.channels-export
Contrato	comportamento concreto, limites, testes e não-objetivos conhecidos

Resolva colisões de branch/caminho antes de criar qualquer coisa. Inspecione git status, git worktree list --porcelain e branches existentes. Não limpe ou reverta estado sujo não relacionado.

Crie os worktrees sequencialmente porque eles mutam metadados Git compartilhados:

git worktree add -b feat/<slug> /absolute/sibling/Cotal-feature-<slug> <base>

Use o mesmo commit base para todas as funcionalidades, a menos que o usuário explicitamente queira trabalho empilhado.

2. Torne o contexto do repositório privado disponível

Antes do lançamento, verifique se cada worktree pode ler .internal/plans/STATUS.md e as diretrizes relevantes. Normalmente git submodule update --init .internal é suficiente.

Se a inicialização falhar porque o superprojeto fixa um commit não disponível:

1. Compare o ponteiro commitado (git ls-tree <base> .internal) com o HEAD ativo do submódulo local (git -C .internal rev-parse HEAD). Isso é desvio de estado do repositório, não um problema de ACL do Cotal.
2. Prefira corrigir/publicar o commit de submódulo pretendido e o ponteiro do superprojeto quando autorizado.
3. Para uma execução paralela temporária, materialize o commit .internal local conhecido como bom independentemente em cada worktree de funcionalidade a partir do repositório de submódulo local ativo.
4. Informe aos gerenciadores que o superprojeto pode mostrar M .internal; eles devem lê-lo, mas nunca stage, editar ou incluí-lo em commits de funcionalidade.

Não deixe gerenciadores bloqueados meramente porque um worktree novo não pode buscar um commit privado que já está disponível e verificado localmente. Também não finja que a incompatibilidade é limpa; relate o reparo permanente necessário.

3. Crie personas de gerenciador e revisor com política primeiro

Agentes gerenciadores precisam de capabilities: [spawn] mais ACLs de canal. Agentes revisores precisam de ACLs de canal e não devem ter spawn. cotal_persona não pode conceder política, e cotal_spawn não pode sobrescrever allowSubscribe ou allowPublish, então crie todo arquivo de persona antes de spawnar. Esses arquivos são locais/ignorados neste repositório. Uma máquina limpa que tem apenas uma persona padrão não pode preencher o painel: os nomes de spawn abaixo falham a menos que esses arquivos existam, e uma persona local residual não é um substituto porque suas concessões podem estar ausentes ou mais amplas que o canal.

---
name: mgr-<slug>
role: feature-manager
model: <modelo de gerenciador fixado>
description: Gerencia <funcionalidade> e seu painel de revisão.
tags: [manager, <slug>]
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>, review.<slug>.cold-record]
allowPublish: [review.<slug>]
capabilities: [spawn]
---

Crie arquivos correspondentes para os três assentos do painel e o assento frio antes de qualquer spawn. Dê a cada persona de revisor um nome de arquivo com escopo de canal, como review-<slug>-engineer; o catálogo de personas é compartilhado por canais concorrentes, então nomes de arquivo genéricos colidem mesmo quando os worktrees e canais não colidem. As personas do painel se inscrevem e publicam apenas em review.<slug>. A persona fria lista subscribe e allowSubscribe vazios para que a não-entrada seja uma propriedade do assento, não uma instrução, e pode publicar apenas para review.<slug>.cold-record. Não reutilize ou redefina uma persona de revisor de outro canal.

---
name: review-<slug>-engineer
role: reviewer
model: <modelo de painel fixado, família A>
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>]
allowPublish: [review.<slug>]
capabilities: []
---

---
name: review-<slug>-freelance
role: reviewer
model: <modelo frio fixado, não da família do autor>
subscribe: []
allowSubscribe: []
allowPublish: [review.<slug>.cold-record]
capabilities: []
---

Repita o template do painel para review-<slug>-security e review-<slug>-critic com diferentes famílias de modelos. Se um árbitro for necessário posteriormente, crie review-<slug>-referee da mesma forma que o assento frio, com subscribe e allowSubscribe vazios mais uma concessão allowPublish dedicada ao canal de registro, antes de spawná-lo.

O prompt do gerenciador deve incluir tudo a seguir:

• Contrato exato da funcionalidade, branch e caminho absoluto do worktree.
• Gerencie a funcionalidade de ponta a ponta e commite apenas arquivos de funcionalidade pretendidos.
• Leia as instruções do repositório, docs atuais e .internal antes de editar.
• Entre em review.<slug> primeiro.
• Spawne apenas personas criadas nesta seção. Spawne review-<slug>-engineer, review-<slug>-security e review-<slug>-critic, posicionados de modo que nenhum dois deles cujo acordo seja crítico compartilhe uma família de modelos. Essa é a regra ordinal acima e não uma contagem de cabeças. Onde o conjunto de fornecedores é curto, nomeie a colisão mecanicamente e a classe que ela deixa descoberta. Nomear é divulgação, não conclusão: um painel cujas aprovações críticas são ecos da mesma família não pode concluir, incluindo A, A, A e A, B, A. Não trate um painel preenchido mas colidido como um portão aprovado. Dê a cada um seu próprio worktree destacado como cwd. Um revisor avalia em sua própria árvore, nunca na árvore que está avaliando, e "somente leitura" deve nomear os verbos de escrita do Git explicitamente (checkout, switch, stash, reset, clean, restore) em vez de apenas dizer "não edite código-fonte".
• DM para cada identidade de revisor retornada pedindo para entrar no canal e permanecer somente leitura/revisão.
• Execute revisão do plano antes de editar, revisão de código/teste após implementação, incorpore descobertas válidas e peça a todos os três uma disposição final.
• Após o painel e a implementação convergirem, spawne exatamente um review-<slug>-freelance em seu próprio worktree destacado e o instrua sob a skill cold-review, que é dona do que esse assento recebe, para onde vai seu veredito, o que o veredito vincula e como as regras degradam quando o conjunto de fornecedores é curto. Não reafirme nada disso aqui.
• Resolva descobertas frias sob a regra canônica de cold-review, nunca dizendo àquele assento para reconsiderar. Se o gerenciador criou a alteração e um bloqueador precisa de refutação independente, envie ao coordenador apenas a descoberta com SHA exato e o artefato. O coordenador provisiona um novo review-<slug>-referee em seu próprio worktree destacado; esse assento não teve parte na criação, avaliação ou supervisão do canal, não compartilha família de modelos com o autor e não recebe nenhuma justificativa do autor. O coordenador provisiona o árbitro, mas não atua como ele. Se uma incorporação alterar código, retorne o resultado ao painel do canal para outra passada final e refixe o assento frio ao novo SHA com seu limite de entrega explicitamente redefinido por escrito. Se esse assento tiver sumido, crie uma nova persona fria com subscribe e allowSubscribe vazios mais apenas sua concessão allowPublish dedicada ao canal de registro, spawne-a e a instrua sob cold-review no novo SHA como um novo assento de uma entrega. Isso é um sucessor, não uma terceira rota de fechamento para o SHA antigo.
• Re-resolva o cabeçalho como uma ação, não como uma asserção posterior. Na instrução, em qualquer reivindicação de conclusão e novamente antes do merge, o gerenciador ou coordenador primeiro resolve o alvo da revisão. Para um PR, execute git ls-remote origin refs/pull/<n>/head e verifique cruzadamente gh pr view <n> --json headRefOid. Para um branch sem PR, resolva git ls-remote origin refs/heads/<branch> e omita a verificação cruzada da API apenas de PR. Busque o objeto resolvido no worktree de revisão destacado se ele ainda não estiver presente, então execute git cat-file -t nesse objeto com um controle conhecido como bom e um controle conhecido como ausente com id de objeto de largura total, como quarenta zeros, que deve falhar. Não faça o controle negativo anexando um caractere ao id real: o Git pode resolver o id de objeto inicial válido e retornar sucesso. Nomeie o ator que executou os instrumentos. Se instrumentos aplicáveis discordarem, pare. Um veredito ou refutação que nomeia um SHA diferente não fecha este cabeçalho.
• Execute os testes relevantes ele mesmo. Revisores não editam código-fonte.
• Escalone apenas escolhas consequenciais não resolvidas com esta estrutura exata:

DECISÃO NECESSÁRIA: <pergunta de uma linha>
Opções: <A>; <B>; ...
Recomendação: <recomendação do gerenciador e porquê>
Impacto: <comportamento observável / compatibilidade / risco>
Bloqueado: <o que não pode prosseguir>; Continuando: <o que pode prosseguir>

• Após a conclusão, DM para o coordenador o id do commit, testes executados, todas as três disposições do painel, o veredito frio terminal e quaisquer refutações públicas, e riscos residuais.

4. Crie canais e lance gerenciadores

Crie o canal do painel e o canal de registro frio dedicado antes de convidar a equipe, com replay habilitado e uma breve nota do operador. Em seguida, spawne cada gerenciador através de cotal_spawn:

name: mgr-<slug>
role: feature-manager
agent: <connector>
model: <modelo de gerenciador fixado>
cwd: /absolute/path/to/feature-worktree

Lance gerenciadores em paralelo apenas depois que todos os worktrees, personas e canais existirem. Rastreie a identidade do revisor retornada, não um nome assumido; um lançamento reiniciado ou duplicado pode ainda ser auto-numerado mesmo que o nome do arquivo de persona tenha escopo de canal.

Verifique com cotal_roster se cada gerenciador aparece e mantém seu painel completo. Não spawne duplicatas aparentemente faltando prematuramente; permita tempo de inicialização e verifique novamente primeiro.

Um spawn que relata um timeout não é evidência de que o spawn falhou. Ele pode já ter sido bem-sucedido, e tentar novamente submete um segundo objetivo que duplica o efeito. Leia o resultado da lista de processos antes de agir, e nunca tente novamente apenas com base em um timeout.

Verifique um assento por RESPOSTA, nunca por presença. Um assento pode ser relatado como em execução e estar silenciosamente inalcançável. Peça um artefato nonce que ele deve produzir, como um echo de um token aleatório concatenado ao commit curto em que está sentado, e verifique a saída bruta. Um handshake que declara a resposta esperada ("confirme que você está em no ") é indutor: uma resposta compatível com echo prova que algo pode espelhar texto, não que um shell foi executado.

O revisor independente é intencional

...

[truncado para tradução]