atlasray66-collab/dlm-version-master

DLM Version Master 7 Portátil

Propósito

Versionar, verificar, commitar e fazer push de alterações em repositórios .NET usando infraestrutura própria do repositório, sem assumir um nome de produto ou layout de diretório. Esta skill pessoal fornece o fluxo de trabalho genérico; cada repositório declara seus projetos, ponto de entrada de release, mapa de módulos, caminhos de saída e política de commit.

Portão de governança de resultados

Leia e aplique a Governança de Resultados DLM compartilhada antes de qualquer mutação de estado de versão, build Release, verificação de artefatos, staging, commit ou push.

• Estabeleça uma linha de base de release/versão congelada com o escopo autorizado, módulos/saídas necessárias, decisão de versão interna, evidências correspondentes à reivindicação e linha de parada. A invocação direta de dlm-version-master autoriza a avaliação de versão interna, build/verificação necessários, commit Git de escopo exato e push para o branch remoto; não autoriza cópia de artefatos, publicação, tag, implantação ou rollout em campo.
• Um hash de código-fonte suporta a reivindicação de mudança de módulo/decisão de versão; um hash de saída suporta identidade de byte quando o perfil o consome. Nenhum deles congela uma linha de base nem prova estado de runtime, coordenação, implantação ou campo.
• Execute apenas verificações exigidas pelo perfil ou de risco material. Metadados verdes não podem substituir evidências de comportamento, e falhas administrativas não relacionadas não podem se tornar critérios de release silenciosamente.
• Realize uma verificação combinada de identidade/escopo/pré-staging antes da mutação e, em seguida, avance pelo caminho de release mais curto. Não adicione recibos, resumos duplicados ou verificação completa repetida sem um consumidor real ou nova incerteza material.

Autoridade e composição

• Cada invocação direta de dlm-version-master carrega autorização permanente do usuário para:
  1. decidir autonomamente por meio de regras internas se deve incrementar versões (none vs. patch / minor / major), a menos que o usuário especifique explicitamente uma política de bump no prompt;
  2. executar o build Release e a verificação de metadados binários necessários sempre que versões de módulos ou entradas de código-fonte relevantes para build mudarem;
  3. preparar caminhos exatos da lista de permissões, executar revisões de pré-commit necessárias (ponytail-review), commitar no Git com uma mensagem de commit estruturada detalhada cobrindo 修改范围 (Escopo), 对应版本 (Versão), 怎么改的 (Como) e 为什么改的 (Por quê), e fazer push para o branch do repositório remoto (git push).
• Pule commit ou push na invocação direta apenas quando o usuário instruir explicitamente a não commitar/push na rodada atual, ou quando uma verificação de segurança/verificação concreta bloquear (build/teste/revisão necessária falhou, alterações não relacionadas misturadas em um arquivo alvo, remoto ausente/ambíguo ou branch remoto divergente).
• Criação de repositório remoto, force-push, tag, implantação, publicação e cópia de artefatos permanecem autoridades separadas.
• No modo de composição dlm-close-release, realize descoberta, decisão de versão interna, build, changelog e verificação de metadados e, em seguida, retorne os caminhos exatos alterados sem staging, commit ou push, a menos que o orquestrador proprietário delegue expressamente a fase Git compartilhada.
• Não copie esta skill pessoal para o repositório nem a referencie a partir de um manifesto de contexto de projeto.
• Mantenha engenharia, evidências de release, coordenação DLM, Git, implantação e aceitação em campo como estados separados.

Contexto inicial

1. Resolva uma raiz Git e leia seu AGENTS.md.
2. Se o repositório usar DLM, carregue doc_llm/dlm.json e a tarefa de release ativa.
3. Leia references/versioned-build-contract.md e references/git-sync.md.
4. Inspecione .sln, .slnx, .csproj de executável/biblioteca/plugin, Directory.Build.*, scripts de versão do repositório, definições de CI/release e estado da versão antes de editar.
5. Prefira infraestrutura de versão própria do repositório. Crie build/versioning/ apenas quando o usuário pedir para estabelecer versionamento e nenhum mecanismo compatível existir.

Resolver o perfil do repositório

Use esta ordem:

1. perfil de release/versão declarado em doc_llm/dlm.json ou docs do repositório;
2. script de versão/build existente e estado da versão;
3. projeto/solução especificado pelo usuário;
4. projeto de inicialização executável ou solução principal inequívoca;
5. se ainda ambíguo, relate candidatos e pergunte antes da mutação de versão.

Não incorpore caminhos de um produto conhecido na skill pessoal. Comportamento específico de projeto pertence ao contrato do repositório ou seus scripts.

Decisões de versão por hash de código-fonte (regra interna autônoma)

Se incrementar uma versão e qual nível de bump aplicar são decididos automaticamente por regras internas (a menos que o usuário substitua explicitamente o nível no prompt). Gere hash de entradas de código-fonte próprias do projeto, não de binários de saída.

Inclua conforme aplicável:

• .cs, .fs, .vb, .xaml, .axaml;
• .csproj, .fsproj, .vbproj, .props, .targets;
• recursos próprios do projeto, manifestos, referências de pacote/projeto e entradas de geração de código.

Exclua:

• bin/, obj/, out/, publish/, artifacts/, staging e saída de runtime copiada;
• props de versão geradas, changelogs e notas de release;
• estado da versão em si ao calcular o hash de código-fonte de um módulo;
• .pdb, .deps.json, DLL/EXE/pacotes de saída gerados.

Tabela de decisão interna:

• Sem bump (none): Um hash de entrada de código-fonte de módulo inalterado nunca causa bump. Se apenas arquivos não-modulares (como docs, registros DLM ou scripts do repositório fora das entradas de hash do módulo) mudaram, ou se nenhuma entrada de código-fonte do módulo mudou desde o hash registrado, não incremente versões e não crie uma mutação de versão vazia; prossiga diretamente para a fase de commit Git e push remoto para as alterações reais na lista de permissões no escopo.
• Bump automático quando o hash de entrada de código-fonte do módulo mudou: Inspecione o impacto semântico do diff do módulo e as regras do repositório para selecionar o nível automaticamente sem parar para perguntar:
  • major / A: API pública quebrada, formato persistido, descoberta de plugin, execução, autorização ou contrato de implantação;
  • minor / B: recurso compatível com versão anterior, novo módulo/plugin/ferramenta ou adição de capacidade;
  • patch / C: correção de bug compatível com versão anterior, correção de layout/acessibilidade/localização, refatoração, ajuste de desempenho, logging ou manutenção interna;
  • auto: padrão declarado no repositório quando configurado, caso contrário, avalie por meio das regras major / minor / patch acima (padrão para patch).

Metadados binários

Para projetos estilo SDK, garanta que valores de versão pública fluam para as saídas geradas:

<Version>1.2.3</Version>
<AssemblyVersion>1.2.3.0</AssemblyVersion>
<FileVersion>1.2.3.0</FileVersion>
<InformationalVersion>1.2.3</InformationalVersion>
<IncludeSourceRevisionInInformationalVersion>false</IncludeSourceRevisionInInformationalVersion>

Não coloque branch, commit SHA, URL remoto, autor/email, mensagem de commit, caminho de máquina ou caminho de repositório em campos públicos de versão binária. Proveniência Git pertence aos logs do Git/CI/release.

Build e verificação

Quando as regras internas incrementarem um ou mais módulos (ou quando entradas de módulo relevantes para build mudarem), use o script do repositório quando presente; caso contrário, faça o build do escopo selecionado serialmente:

dotnet build <project-or-solution> -c Release -m:1

Não force exclusão de saída bloqueada. Relate o processo de bloqueio e pare, a menos que o usuário autorize um desligamento seguro do processo.

Após o build, valide apenas as reivindicações exigidas pela linha de base de release congelada e perfil do repositório:

1. execute testes afetados e verificações de release do repositório;
2. verifique pelo menos uma saída para cada módulo público alterado;
3. leia a versão de arquivo/produto/assembly/informacional por meio de ferramentas apropriadas;
4. verifique o caminho de saída esperado e, quando exigido, SHA-256/metadados do pacote;
5. garanta que módulos inalterados não sofreram bump;
6. gere o changelog/resumo de release conciso do repositório quando o perfil de release ou um consumidor real de release/decisão exigir.

Se metadados, testes, hashing ou identidade de saída necessários não puderem ser verificados, a reivindicação de release correspondente está incompleta e bloqueia a fase de commit/push Git. Relate falhas pré-existentes ou administrativas não relacionadas separadamente; elas não invalidam uma saída conforme, a menos que impacto material seja demonstrado.

Fase obrigatória de commit Git e push remoto

Siga Sincronização Git em toda invocação direta de dlm-version-master (a menos que explicitamente suprimida pelo usuário ou executando como filho composto sem delegação Git):

1. Execute a decisão de versão interna -> build verificado (quando houve bump ou entradas relevantes para build mudaram) -> revisão de pré-commit (ponytail-review e hooks do repositório) -> git commit de escopo exato -> git push para o branch remoto.
2. Cada commit criado por dlm-version-master deve usar uma mensagem de commit detalhada de múltiplas linhas, baseada no git diff --cached real e nas transições de versão (nunca um resumo de uma linha ou vago "bump version" / "atualizar arquivos"). Deve incluir explicitamente todas as quatro seções necessárias:
   • 修改范围 (Escopo): módulos/projetos/subsistemas alterados e principais arquivos na lista de permissões ou limites;
   • 对应版本 (Versão): nível de bump (none / patch / minor / major) e transição de versão antiga -> nova de cada módulo afetado (ou versão atual com none (sourceHash unchanged) quando nenhum módulo sofreu bump);
   • 怎么改的 (Como): implementação técnica concreta derivada do diff preparado (pontos de entrada, fluxo de dados/controle, ajustes de algoritmo/UI/config/build);
   • 为什么改的 (Por quê): causa raiz, requisito/direcionador de tarefa, gatilho de defeito ou razão arquitetural/compatibilidade para a alteração de código e a decisão de versão.
3. Quando as regras internas decidirem não incrementar versões (hashes de código-fonte do módulo inalterados), pule a mutação de versão e não crie um commit de versão vazio; ainda assim prepare, revise, commite (com a mesma mensagem de commit estruturada de quatro partes) e faça push de quaisquer alterações de repositório pretendidas na lista de permissões no escopo, ou faça push de commits verificados não enviados existentes no branch atual.

Saída

Relate fonte do perfil do repositório, linha de base de release congelada/linha de parada, decisão de versão interna (none / patch / minor / major) e justificativa, escopo e comandos do build (quando executado), transições de hash/versão do módulo, módulos inalterados, testes correspondentes à reivindicação, metadados/hashes de saída verificados, consumidor/caminho do changelog, lista de permissões de arquivos alterados, mensagem de commit estruturada completa (修改范围 / 对应版本 / 怎么改的 / 为什么改的), hash do commit, resultado verificado do push do branch remoto e lacunas Bloqueadoras vs. Consultivas. Mantenha níveis de evidência mais altos distintos do sucesso do build e da sincronização Git.