atlasray66-collab/dlm-close-release

DLM Close Release 7 Portátil

Propósito

Fechar um escopo de engenharia verificado sem conflitar conclusão de tarefa, sedimentação de conhecimento, produção de release, versionamento, commit Git ou deploy. Este skill pessoal orquestra o ciclo de vida; contratos de repositório e skills filhos mantêm suas regras técnicas.

Portão de governança de resultado

Leia e aplique o DLM Outcome Governance compartilhado antes de qualquer escrita de fechamento, mutação de release/versão, auditoria formal, staging ou commit.

• Mantenha separados: estado alvo de engenharia, estado de evidência, estado de coordenação DLM, estado de release, estado Git, estado de deploy e aceitação de campo. Avançar um não implica avançar outro.
• Resolva uma Baseline de Aceitação para o modo autorizado. Antes de escritas de fechamento ou mutação de release/Git, o Proprietário da Baseline congela seu alvo, não-objetivos, Escopo Autorizado, evidência necessária, critérios e linha de parada uma vez. Hashes, BOM/EOL, representação de checkout e recibos não o congelam ou invalidam.
• Registros de fechamento/sedimentação/release são trabalho alvo apenas quando solicitados ou consumidos pelo contrato/ decisão aplicável. Mudanças administrativas puras não reabrem build/teste/auditoria não relacionadas.
• Use no máximo uma auditoria formal completa para um estado alvo estável, e apenas quando o usuário, contrato aceito ou risco material a justificar. Após reparo, revalide apenas condições falhas e regressões diretas.

Selecione o modo autorizado mais restrito

Modo	Ações permitidas	Intenção típica
close-only	Revisão de Fechamento, sedimentação, validação DLM	"Fechar tarefa" "Finalizar sedimentação"
release-verify	close-only mais build de release/versão do repositório e verificação de metadados de artefato	"Preparar release" "Verificar versão de release"
release-commit	release-verify mais staging e commit por caminho exato	"Atualizar versão e commitar Git"

Padrão para close-only. Uma solicitação de commit não autoriza push, tag, deploy, publish ou cópia de artefato. Cada um é autorizado separadamente. Se a redação for insuficiente para distinguir uma mutação de Git/versão, pare e pergunte.

Bloqueio de repositório e contrato

1. Resolva uma raiz Git e leia seu AGENTS.md e contrato DLM.
2. Execute o mínimo dlm-load necessário para a tarefa e perfil de release.
3. Não copie este skill pessoal para o repositório nem o adicione a um manifesto de contexto.
4. Use o perfil de release declarado pelo repositório:
   • none: apenas fechamento, a menos que o usuário forneça um procedimento;
   • dotnet: use dlm-version-master em modo de composição;
   • custom: use o contrato de versão/build/verificação de propriedade do repositório.
5. Em trabalho multi-repositório ou submódulo, use uma lista de permissão separada, resultado de validação e commit por raiz Git. Não reivindique atomicidade cross-repositório.

Fase 0 — Snapshot de escopo

Antes de qualquer escrita, execute este snapshot combinado de escritor/segurança de escopo uma vez:

git status --short
git diff --name-status
git diff --cached --name-status
git ls-files --others --exclude-standard

Construa conjuntos exatos para candidatos de propriedade da tarefa, alterações pré-existentes não relacionadas e arquivos pré-stageados. Se a propriedade não puder ser estabelecida a partir da intenção do usuário, Escopo Autorizado Congelado, documentos da tarefa e diff, pare antes da mutação. Não repita o snapshot meramente para fabricar evidência de autorização. Nunca use git add . ou git add -A.

Fase 1 — Revisão de Fechamento

Realize Revisão de Fechamento direcionada contra os critérios Congelados e evidência correspondente à reivindicação. Use dlm-reflect; revisão independente formal é opcional a menos que o usuário a solicite, um contrato aceito a exija ou risco material a justifique. Continue quando o nível de conclusão declarado for comprovado, ou encaminhe uma lacuna material remanescente como trabalho/bloqueio do escopo atual. Sucesso de build por si só não é evidência de comportamento, UI, hardware, migração, segurança ou campo; igualmente, um índice administrativo obsoleto por si só não refuta comportamento comprovado.

Fase 2 — Sedimentação

Quando o usuário solicitou sedimentação, o contrato de repositório/tarefa aceito a exige, ou um consumidor real de carregamento/release/decisão precisar de sincronização, execute dlm-sediment uma vez em modo de composição. Escreva apenas conhecimento e status de tarefa/domínio confirmados. Portões de aprovação BRIEF/L0 permanecem ativos. Skills filhos devem retornar caminhos exatos alterados e não devem stagear ou commitar. Se não existir tal gatilho, registre sediment: not required e preserve a conclusão de engenharia verificada.

Sincronize uma vez para consumidores reais de tarefa/conhecimento e reuse evidência existente. Não crie recibos sinônimos nem reexecute validação de engenharia não relacionada porque apenas registros de coordenação mudaram.

Para close-only, execute verificações de saúde DLM apenas quando o fechamento autorizado incluir estado DLM ou um contrato/consumidor atual depender delas, então pare após o relatório de fechamento. Uma verificação não aplicável ignorada não é uma falha.

Fase 3 — Verificação de release

Apenas para modos de release:

1. Resolva o perfil de release do repositório e o escopo de saída exato.
2. Determine a intenção de versão. Major/minor exigem intenção explícita. Patch/auto é permitido apenas quando a intenção de release existe e o contrato do repositório declara esse padrão.
3. Execute o processo de versão/build do repositório serialmente, a menos que seu contrato especifique o contrário.
4. Execute testes e verifique metadados de binário/package público e hashes exigidos pelos critérios/perfil de release Congelados; não adicione verificações de preferência do revisor como novas condições de release.
5. Adicione apenas estado de versão intencional, changelog, infraestrutura de release e arquivos fonte de propriedade da tarefa à lista de permissão candidata.

Uma falha de build, teste, hash ou metadados bloqueia reivindicações de commit/release quando essa verificação é exigida pela Baseline de release Congelada, perfil do repositório ou um risco de saída material demonstrado. Falhas administrativas ou pré-existentes não relacionadas são relatadas separadamente e não expandem silenciosamente os critérios de release.

Fase 4 — Portão de conjunto stageado exato

Apenas para release-commit:

• Normalize a lista de permissão para caminhos exatos relativos ao repositório.
• Compare os arquivos stageados atuais com o snapshot pré-stageado.
• Não desstageie trabalho do usuário. Se arquivos pré-stageados estiverem fora da lista de permissão, pare e relate.
• Se um arquivo na lista de permissão misturar alterações pré-existentes não relacionadas que não podem ser divididas com segurança, pare e pergunte.
• Exclua segredos, configuração local da máquina, bin/, obj/, out/, logs, capturas, saída de publish/staging e artefatos temporários, a menos que explicitamente solicitado e apropriado.
• Execute verificações de whitespace/codificação exigidas pelo repositório.

Fase 5 — Stage e commit

git add -- <caminhos-exatos>
git diff --cached --name-status
git diff --cached --stat
git diff --cached --check
git status --short

Exija igualdade exata entre caminhos stageados e a lista de permissão aprovada. Antes do commit, execute as revisões pré-commit exigidas pelo AGENTS.md global (o portão ponytail-review e seu marcador de guarda) e pelo repositório, contra este diff stageado exato; resolva ou retenha explicitamente cada descoberta conforme essas regras exigirem. Se um skill de revisão ou hook exigido estiver indisponível, pare antes de commitar e relate essa lacuna em vez de contorná-la. Faça commit uma vez por raiz Git usando as convenções do repositório. Não altere o commit a menos que solicitado. Após o commit, inspecione git show --stat --oneline HEAD e a árvore de trabalho restante.

Regras de falha

• Um comando filho com código de retorno diferente de zero bloqueia fases posteriores apenas quando falha em um critério Congelado atual, contrato aplicável, verificação de integridade de artefato tocado ou limite material de segurança/release. Falhas administrativas ou pré-existentes não relacionadas são relatadas sem se tornarem novos portões.
• Uma tarefa bloqueada não é fechada; persista sua razão, proprietário, tentativas e condição de release.
• Trabalho cancelado pode persistir estado de cancelamento sem fingir release bem-sucedido.
• Locks de saída são relatados, não forçados a exclusão.
• Trabalho não relacionado permanece intocado.
• Invalidação de Baseline é reservada para novo conflito SSOT, premissa falsa, segurança ou risco de perda de dados. Alterações de EOL/BOM, clean/smudge, timestamp, ordem de exibição ou apenas recibos não invalidam ou reabrem validação completa.

Relatório final

Relate modo, identidade do repositório/projeto, estado/proprietário/linha de parada da Baseline de Aceitação, tipo/veredito da Revisão de Fechamento, consumidores/caminhos de sedimentação, verificações DLM, perfil de release e alterações de versão, artefatos verificados correspondentes a reivindicações, lista de permissão stageada, hash do commit se houver, lacunas Bloqueantes versus Consultivas e arquivos não relacionados deliberadamente intocados. Declare explicitamente quais de commit/push/tag/deploy/cópia de artefato não foram executados. Pare no limite do modo autorizado; não ative automaticamente a próxima Subtarefa, item de trabalho, Descoberta Diferida, push, tag ou deploy.