tencentmusic/modus

modus-reinit

Usado durante a revisão completa de conteúdos existentes. Compartilha o Guia de Evidências, o Framework de Geração e o Contrato de Publicação; este documento descreve apenas as diferenças do reinit.

Primeiro faça um inventário, depois prove a mudança

Leia completamente o conteúdo existente e os hashes, classificando os alvos em unchanged, anchor-only, implementation-change, scope-change, content-repair, suspeitas de descontinuação ou conteúdo manual. Identidades estáveis e definições principais são reutilizadas por padrão; alterações apenas de caminho de código/símbolo ajustam âncoras, mudanças no layout do conteúdo não são mudanças de Escopo.

content-repair inclui: parágrafos de template genérico substituindo cenários reais, âncoras representativas substituindo fatos, cópia entre Módulos, semântica confusa de conclusão/falha, relações complexas sem diagramas que ajudem significativamente na compreensão. Conteúdo que realmente atende às tarefas do leitor e cujos fatos não mudaram permanece unchanged e é pulado na escrita.

Execução

1. Construa sincronizadamente as evidências atuais do repositório único e obtenha o contexto reinit-diff; se falhar, reverta imediatamente para o código-fonte atual. Siga o Contrato de Pacote de Evidências Machine para expansão direcionada, sem ler diretamente arquivos internos do bundle e sem esgotar o cursor.
2. Seguindo a Modelagem de Escopo, julgue na ordem "identidade estável → responsabilidades de entrada/objeto → mudança semântica → mudança estrutural → mudança de arquivo", registrando escopo, handle, hash no momento da leitura, evidência/status exatos do Domain/Module, cobertura do Domain, resultado e candidatos a diagrama em um cartão de execução único schemaVersion: 2. Confirme apenas uma vez para adições, divisões, mesclagens, movimentações, renomeações ou descontinuações já comprovadas. Sequencial por padrão; se o usuário autorizar explicitamente e houver múltiplos Domínios impactados não sobrepostos, carregue a Escrita Paralela por Domain e use o Contrato de Worker de Domínio; o autor raiz continua exclusivo sobre o cartão de execução e artefatos compartilhados.
3. Para cada mudança ou Module com content-repair, solicite o contexto module-authoring usando um seletor exato, verifique o duplo resumo e o requestedScope; solicitações amplas que cobrem vários Modules independentes no mesmo domínio são inválidas. Solicitações exatas e não dependentes podem ocorrer concorrentemente, depois consolide e deduplic os caminhos/símbolos do Domain atual e leia de volta em lotes. Se a solicitação falhar, retornar vazia ou parcial, volte ao corpo do método atual, configuração, SQL e testes para complementar as evidências; não trate nomes de classe, assinaturas de interface ou âncoras de primeira linha como conteúdo restaurado. Não varra o mesmo link para tópicos diferentes e não escreva no mesmo conteúdo concorrentemente. Siga o Fechamento de Cenário para reprovar; revise a definição principal original, não adicione changelog, e não reescreva ou redesenhe em lote devido a mudanças de template.
4. Leia de volta o escopo impactado em lotes de Domain completo na ordem "definição principal dos seis tópicos → cenário do Module → rota do Domain". Caminhos de código-fonte e números de linha migram para um pequeno conjunto de anchors.locations no frontmatter de cada documento gerado; remova caminhos completos de código-fonte, path#L e listas de evidências do corpo. O objetivo do reparo é restaurar tarefas completas, semântica de campos, branches críticos, estados e recuperação de erros, não apenas fazer o arquivo recuperar títulos, âncoras ou tamanho semelhante. Após o fechamento das evidências, reavalie os candidatos seguindo a Expressão Visual com Texto e Imagem e atualize o único diagrama principal; tabelas de navegação não substituem diagramas explicativos. A auditoria de cobertura (coverage-audit) a nível de Domain deve reutilizar o escopo de candidate/capability/source path/symbol do próprio domínio, não pode usar modus/knowledge/**; resultados sem correspondência, vazios ou parciais disparam apenas complementação de evidências ou lacunas explícitas. Registre resultados válidos como cobertura do Domain; após concluir a leitura de volta para os três tipos de leitor, o autor raiz lê os arquivos reais e marca como reviewed. Atualize a visão geral raiz apenas quando houver mudanças de direção entre domínios, propriedade, status, condição, conclusão ou recuperação; Team Standard e negócios existentes são protegidos por padrão com bytes originais; novos Domínios usam modus knowledge seed-business --domain <slug> --json para criar índices ausentes.
5. Mudanças estruturais primeiro escrevem o novo destino e passam por leitura de volta semântica, reparam links de entrada e navegação no conteúdo gerado, e então deletam os arquivos gerados antigos de acordo com o hash no momento da leitura. Não derive descontinuação diretamente de desaparecimento de símbolo, resultados parciais ou lacunas de cobertura.
6. Após a leitura de volta semântica global, execute modus knowledge verify --publication --json, publique via CAS e leia de volta. A publicação deve verificar o cartão de execução schemaVersion: 2, corpo sem caminhos de código-fonte, âncoras estruturadas, evidências por Module, cobertura do Domain e decisão visual; clean ainda não é prova de qualidade do corpo. Continue revisando quando houver muitos textos curtos de mesmo comprimento, sem cenários reais, apenas tabelas de navegação, tópicos de estado sem transições ou evidências que recaem apenas na primeira linha dos arquivos. Não delete o cartão de execução prematuramente e não reconstrua um cartão menor (todo "reviewed") com base na saída após perdê-lo. Limpe o cartão de execução apenas quando todos os alvos confirmados atingirem o estado final e a leitura de volta semântica, a publicação real e a leitura de volta pós-publicação passarem; verificações mecânicas comuns não substituem a publicação. Relate genuinamente os itens não modificados (unchanged), revisados, excluídos, conflitos e lacunas.