DLM Cierre y Liberación 7 Portátil

¿Qué hace DLM Cierre y Liberación 7 Portátil?

Propósito

Cerrar un alcance de ingeniería verificado sin mezclar finalización de tarea, sedimentación de conocimiento, producción de liberación, versionado, confirmación Git o despliegue. Esta habilidad personal orquesta el ciclo de vida; los contratos del repositorio y las habilidades secundarias mantienen sus reglas técnicas.

Puerta de gobernanza de resultados

Lee y aplica la Gobernanza de Resultados DLM antes de cualquier escritura de cierre, mutación de liberación/versión, auditoría formal, puesta en escena o confirmación.

• Mantén separados el estado objetivo de ingeniería, el estado de evidencia, el estado de coordinación DLM, el estado de liberación, el estado Git, el estado de despliegue y la aceptación en campo. Avanzar uno no implica otro.
• Resuelve una Línea Base de Aceptación para el modo autorizado. Antes de escrituras de cierre o mutación de liberación/Git, el Propietario de la Línea Base congela su objetivo, no-objetivos, Alcance Autorizado, evidencia requerida, criterios y línea de parada una vez. Hashes, BOM/EOL, representación de checkout y recibos no la congelan ni invalidan.
• Los registros de cierre/sedimentación/liberación son trabajo objetivo solo cuando son solicitados o consumidos por el contrato/decisión aplicable. Los cambios puramente administrativos no reabren compilación/prueba/auditoría no relacionados.
• Usa como máximo una auditoría formal completa para un estado objetivo estable, y solo cuando el usuario, un contrato aceptado o un riesgo material lo justifiquen. Después de la reparación, revalida solo las condiciones fallidas y las regresiones directas.

Selecciona el modo autorizado más estrecho

Modo	Acciones permitidas	Intención típica
close-only	Revisión de cierre, sedimentación, validación DLM	"Cerrar tarea" "Completar sedimentación"
release-verify	close-only más compilación de liberación/versión del repositorio y verificación de metadatos de artefactos	"Preparar liberación" "Verificar versión de liberación"
release-commit	release-verify más puesta en escena de ruta exacta y confirmación	"Actualizar versión y confirmar Git"

Valor predeterminado: close-only. Una solicitud de confirmación no autoriza empujar, etiquetar, desplegar, publicar ni copiar artefactos. Cada uno se autoriza por separado. Si la redacción es insuficiente para distinguir una mutación de Git/versión, detente una vez y pregunta.

Bloqueo de repositorio y contrato

1. Resuelve una raíz Git y lee su AGENTS.md y contrato DLM.
2. Ejecuta el mínimo dlm-load necesario para la tarea y el perfil de liberación.
3. No copies esta habilidad personal en el repositorio ni la añadas a un manifiesto de contexto.
4. Usa el perfil de liberación declarado por el repositorio:
   • none: solo cierre a menos que el usuario proporcione un procedimiento;
   • dotnet: usa dlm-version-master en modo composición;
   • custom: usa el contrato de versión/compilación/verificación propiedad del repositorio.
5. En trabajo con múltiples repositorios o submódulos, usa una lista blanca separada, un resultado de validación y una confirmación por raíz Git. No reclames atomicidad entre repositorios.

Fase 0 — Instantánea del alcance

Antes de cualquier escritura, realiza esta instantánea combinada de escritor/seguridad del alcance una vez:

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

Construye conjuntos exactos para candidatos propiedad de la tarea, cambios preexistentes no relacionados y archivos previamente preparados. Si no se puede establecer la propiedad a partir de la intención del usuario, el Alcance Autorizado Congelado, la documentación de la tarea y el diff, detente antes de la mutación. No repitas la instantánea solo para fabricar evidencia de autorización. Nunca uses git add . o git add -A.

Fase 1 — Revisión de cierre

Realiza una Revisión de Cierre dirigida contra los criterios congelados y la evidencia emparejada con las reclamaciones. Usa dlm-reflect; la revisión independiente formal es opcional a menos que el usuario la solicite, un contrato aceptado la requiera o un riesgo material la justifique. Continúa cuando se demuestre el nivel de finalización declarado, o canaliza una brecha material restante como trabajo/bloqueo del alcance actual. El éxito de compilación por sí solo no es evidencia de comportamiento, UI, hardware, migración, seguridad o campo; igualmente, un índice administrativo obsoleto por sí solo no refuta el comportamiento demostrado.

Fase 2 — Sedimentación

Cuando el usuario solicitó sedimentación, el contrato de repositorio/tarea aceptado lo requiere, o un consumidor real de carga/liberación/decisión necesita sincronización, ejecuta dlm-sediment una vez en modo composición. Escribe solo conocimiento y estado confirmados de la tarea/dominio. Las puertas de aprobación BREVE/L0 permanecen activas. Las habilidades secundarias deben devolver las rutas exactas modificadas y no deben hacer stage ni commit. Si no existe tal desencadenante, registra sediment: no requerido y preserva la conclusión de ingeniería verificada.

Sincroniza una vez para consumidores reales de tarea/conocimiento y reutiliza la evidencia existente. No crees recibos sinónimos ni reejecutes validación de ingeniería no relacionada porque solo cambiaron los registros de coordinación.

Para close-only, ejecuta comprobaciones de salud DLM solo cuando el cierre autorizado incluya estado DLM o un contrato/reclamación de consumidor actual dependa de ellas, luego detente después del informe de cierre. Una verificación no aplicable omitida no es una falla.

Fase 3 — Verificación de liberación

Solo para modos de liberación:

1. Resuelve el perfil de liberación del repositorio y el alcance exacto de salida.
2. Determina la intención de versión. Mayor/menor requieren intención explícita. Parche/automático solo se permite cuando existe intención de liberación y el contrato del repositorio declara ese valor predeterminado.
3. Ejecuta el proceso de versión/compilación del repositorio en serie a menos que su contrato especifique lo contrario.
4. Ejecuta pruebas y verifica los metadatos de paquetes binarios/públicos y hashes requeridos por los criterios/perfil de liberación congelados; no añadas verificaciones de preferencia del revisor como nuevas condiciones de liberación.
5. Añade solo estado de versión intencional, registro de cambios, infraestructura de liberación y archivos fuente propiedad de la tarea a la lista blanca de candidatos.

Una falla de compilación, prueba, hash o metadatos bloquea las reclamaciones de confirmación/liberación cuando esa verificación es requerida por la línea base de liberación congelada, el perfil del repositorio o un riesgo material demostrado de salida. Las fallas preexistentes o administrativas no relacionadas se informan por separado y no expanden silenciosamente los criterios de liberación.

Fase 4 — Puerta de conjunto preparado exacto

Solo para release-commit:

• Normaliza la lista blanca a rutas exactas relativas al repositorio.
• Compara los archivos preparados actuales con la instantánea pre-preparada.
• No deshagas el trabajo del usuario. Si los archivos pre-preparados están fuera de la lista blanca, detente e informa.
• Si un archivo en la lista blanca mezcla cambios preexistentes no relacionados que no se pueden dividir de forma segura, detente y pregunta.
• Excluye secretos, configuración local de la máquina, bin/, obj/, out/, registros, capturas, salida de publicación/ensayo y artefactos temporales a menos que se soliciten explícitamente y sean apropiados.
• Ejecuta las comprobaciones de espacios en blanco/codificación requeridas por el repositorio.

Fase 5 — Stage y commit

git add -- <rutas-exactas>
git diff --cached --name-status
git diff --cached --stat
git diff --cached --check
git status --short

Exige igualdad exacta entre las rutas preparadas y la lista blanca aprobada. Antes del commit, ejecuta las revisiones previas al commit requeridas por el AGENTS.md global (la puerta ponytail-review y su marcador de guardia) y por el repositorio, contra este diff preparado exacto; resuelve o retiene explícitamente cada hallazgo como lo requieran esas reglas. Si una habilidad de revisión o hook requerido no está disponible, detente antes de confirmar e informa esa brecha en lugar de evitarla. Confirma una vez por raíz Git usando las convenciones del repositorio. No hagas amend a menos que se solicite. Después del commit, inspecciona git show --stat --oneline HEAD y el árbol de trabajo restante.

Reglas de fallo

• Un comando secundario con código de salida distinto de cero bloquea fases posteriores solo cuando falla un criterio congelado actual, un contrato aplicable, una verificación de integridad de artefacto tocado o un límite material de seguridad/liberación. Las fallas preexistentes y administrativas no relacionadas se informan sin convertirse en nuevas puertas.
• Una tarea bloqueada no está cerrada; persiste su razón, propietario, intentos y condición de liberación.
• El trabajo cancelado puede persistir el estado de cancelación sin pretender una liberación exitosa.
• Los bloqueos de salida se informan, no se eliminan por la fuerza.
• El trabajo no relacionado permanece intacto.
• La invalidación de línea base se reserva para nuevo conflicto SSOT, premisa falsa, seguridad o riesgo de pérdida de datos. Los cambios de EOL/BOM, clean/smudge, marca de tiempo, orden de visualización o solo de recibo no invalidan ni reabren la validación completa.

Informe final

Informa el modo, identidad del repositorio/proyecto, estado/propietario/línea de parada de la Línea Base de Aceptación, tipo/veredicto de Revisión de Cierre, consumidores/rutas de sedimentación, verificaciones DLM, perfil de liberación y cambios de versión, artefactos verificados emparejados con reclamaciones, lista blanca preparada, hash de confirmación si lo hay, brechas Bloqueantes versus de Asesoramiento, y archivos no relacionados deliberadamente no tocados. Indica explícitamente cuáles de confirmar/empujar/etiquetar/desplegar/copiar artefactos no se realizaron. Detente en el límite del modo autorizado; no actives automáticamente la siguiente Subtarea, elemento de trabajo, Hallazgo Diferido, push, tag o despliegue.