dlm-version-master

DLM Version Master 7 Portable

Propósito

Versionar, verificar, confirmar y enviar cambios de repositorios .NET utilizando la infraestructura del propio repositorio sin asumir un nombre de producto o diseño de directorio. Esta habilidad personal proporciona el flujo de trabajo genérico; cada repositorio declara sus proyectos, punto de entrada de release, mapa de módulos, rutas de salida y política de confirmación.

Puerta de control de resultados

Leer y aplicar la Gobernanza de Resultados DLM compartida antes de la mutación del estado de versión, compilación Release, verificación de artefactos, preparación, confirmación o push.

• Establecer una línea base de release/versión Congelada con el alcance autorizado, módulos/salidas requeridos, decisión de versión interna, evidencia coincidente con la reclamación y línea de parada. La invocación directa de dlm-version-master autoriza la evaluación de versión interna, compilación/verificación requerida, confirmación Git de alcance exacto y push a la rama remota; no autoriza copia de artefactos, publicación, etiquetado, despliegue o implementación en campo.
• Un hash de origen respalda la reclamación de cambio de módulo/decisión de versión; un hash de salida respalda la identidad de byte cuando el perfil lo consume. Ninguno congela una línea base ni prueba el estado de ejecución, coordinación, despliegue o campo.
• Ejecutar solo verificaciones requeridas por el perfil o de riesgo material. Los metadatos verdes no pueden sustituir la evidencia de comportamiento, y las fallas administrativas no relacionadas no pueden convertirse silenciosamente en criterios de release.
• Realizar una verificación combinada de identidad/alcance/preparación antes de la mutación, luego avanzar por la ruta de release más corta. No agregar recibos, resúmenes duplicados o verificación completa repetida sin un consumidor real o nueva incertidumbre material.

Autoridad y composición

• Cada invocación directa de dlm-version-master conlleva la autorización permanente del usuario para:
  1. decidir autónomamente mediante reglas internas si incrementar las versiones (ninguno vs. patch / minor / major) a menos que el usuario especifique explícitamente una política de incremento en el prompt;
  2. ejecutar la compilación Release requerida y la verificación de metadatos binarios siempre que cambien las versiones de los módulos o las entradas de origen relevantes para la compilación;
  3. preparar rutas exactas en la lista blanca, ejecutar las revisiones previas a la confirmación requeridas (ponytail-review), confirmar en Git con un mensaje de confirmación estructurado detallado que cubra 修改范围 (Alcance), 对应版本 (Versión), 怎么改的 (Cómo) y 为什么改的 (Por qué), y enviar a la rama del repositorio remoto (git push).
• Omitir confirmación o push en la invocación directa solo cuando el usuario indique explícitamente no confirmar/enviar en el turno actual, o cuando una comprobación concreta de seguridad/verificación lo bloquee (compilación/prueba/revisión requerida fallida, cambios no relacionados mezclados en un archivo objetivo, remoto faltante/ambiguo o rama remota divergida).
• La creación de repositorios remotos, push forzado, etiquetado, despliegue, publicación y copia de artefactos siguen siendo autoridades separadas.
• En el modo de composición dlm-close-release, realizar descubrimiento, decisión de versión interna, compilación, registro de cambios y verificación de metadatos, luego devolver las rutas exactas cambiadas sin preparar, confirmar o enviar a menos que el orquestador propietario delegue expresamente la fase Git compartida.
• No copiar esta habilidad personal en el repositorio ni referenciarla desde un manifiesto de contexto de proyecto.
• Mantener la ingeniería, la evidencia de release, la coordinación DLM, Git, el despliegue y la aceptación en campo como estados separados.

Contexto inicial

1. Resolver una raíz Git y leer su AGENTS.md.
2. Si el repositorio usa DLM, cargar doc_llm/dlm.json y la tarea de release activa.
3. Leer references/versioned-build-contract.md y references/git-sync.md.
4. Inspeccionar .sln, .slnx, .csproj ejecutable/biblioteca/plugin existentes, Directory.Build.*, scripts de versión del repositorio, definiciones de CI/release y estado de versión antes de editar.
5. Preferir la infraestructura de versionado propiedad del repositorio. Crear build/versioning/ solo cuando el usuario solicite establecer versionado y no exista un mecanismo compatible.

Resolver el perfil del repositorio

Usar este orden:

1. perfil de release/versión declarado en doc_llm/dlm.json o documentos del repositorio;
2. script de versión/compilación existente y estado de versión;
3. proyecto/solución especificado por el usuario;
4. proyecto de inicio ejecutable o solución principal inequívoca;
5. si aún es ambiguo, informar candidatos y preguntar antes de la mutación de versión.

No incrustar rutas conocidas de un producto en la habilidad personal. El comportamiento específico del proyecto pertenece al contrato del repositorio o sus scripts.

Decisiones de versión basadas en hash de origen (regla interna autónoma)

Si incrementar una versión y qué nivel de incremento aplicar se deciden automáticamente mediante reglas internas (a menos que el usuario anule explícitamente el nivel en el prompt). Generar hash de las entradas de origen propiedad del módulo, no de los binarios de salida.

Incluir según corresponda:

• .cs, .fs, .vb, .xaml, .axaml;
• .csproj, .fsproj, .vbproj, .props, .targets;
• recursos propiedad del proyecto, manifiestos, referencias de paquetes/proyectos y entradas de generación de código.

Excluir:

• bin/, obj/, out/, publish/, artifacts/, preparación y salida de tiempo de ejecución copiada;
• props de versión generados, registros de cambios y notas de release;
• el propio estado de versión al calcular el hash de origen de un módulo;
• .pdb, .deps.json, DLL/EXE/paquete generados.

Tabla de decisión interna:

• Sin incremento (ninguno): Un hash de entrada de origen de módulo sin cambios nunca se incrementa. Si solo cambiaron archivos que no son módulos (como documentos, registros DLM o scripts del repositorio fuera de las entradas hash del módulo), o si no cambiaron las entradas de origen del módulo desde el hash registrado, no incrementar versiones ni crear una mutación de versión vacía; proceder directamente a la fase de confirmación Git y push remoto para los cambios reales en la lista blanca dentro del alcance.
• Incremento automático cuando cambia el hash de entrada de origen del módulo: Inspeccionar el impacto semántico del diff del módulo y las reglas del repositorio para seleccionar el nivel automáticamente sin detenerse a preguntar:
  • major / A: API pública, formato persistente, descubrimiento de plugins, ejecución, autorización o contrato de despliegue que rompe la compatibilidad;
  • minor / B: característica compatible con versiones anteriores, nuevo módulo/plugin/herramienta o adición de capacidad;
  • patch / C: corrección de errores compatible con versiones anteriores, corrección de diseño/accesibilidad/localización, refactorización, ajuste de rendimiento, registro o mantenimiento interno;
  • auto: valor predeterminado declarado por el repositorio cuando está configurado; de lo contrario, evaluar mediante las reglas major / minor / patch anteriores (por defecto patch).

Metadatos binarios

Para proyectos de estilo SDK, asegurar que los valores de versión pública fluyan a las salidas generadas:

<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>

No colocar la rama, el SHA de confirmación, la URL remota, el autor/correo electrónico, el mensaje de confirmación, la ruta de la máquina o la ruta del repositorio en los campos de versión binaria pública. La procedencia de Git pertenece a los registros de Git/CI/release.

Compilar y verificar

Cuando las reglas internas incrementan uno o más módulos (o cuando cambian las entradas del módulo relevantes para la compilación), usar el script del repositorio cuando esté presente; de lo contrario, compilar el alcance seleccionado en serie:

dotnet build <proyecto-o-solución> -c Release -m:1

No forzar la eliminación de la salida bloqueada. Informar el proceso de bloqueo y detenerse a menos que el usuario autorice un cierre seguro del proceso.

Después de la compilación, validar solo las reclamaciones requeridas por la línea base de release Congelada y el perfil del repositorio:

1. ejecutar las pruebas afectadas y las comprobaciones de release del repositorio;
2. verificar al menos una salida para cada módulo público cambiado;
3. leer la versión de archivo/producto/ensamblado/informativa a través de las herramientas adecuadas;
4. verificar la ruta de salida esperada y, cuando sea necesario, SHA-256/metadatos del paquete;
5. asegurar que los módulos sin cambios no se incrementaron;
6. generar el registro de cambios/resumen de release conciso del repositorio cuando el perfil de release o un consumidor real de release/decisión lo requiera.

Si los metadatos requeridos, las pruebas, el hash o la identidad de salida no se pueden verificar, la reclamación de release correspondiente está incompleta y bloquea la fase de confirmación Git/push remoto. Informar las fallas preexistentes o administrativas no relacionadas por separado; no invalidan una salida conforme a menos que se demuestre un impacto material.

Fase obligatoria de confirmación Git y push remoto

Seguir la Sincronización Git en cada invocación directa de dlm-version-master (a menos que el usuario la suprima explícitamente o se ejecute como un hijo compuesto sin delegación de Git):

1. Ejecutar la decisión de versión interna -> compilación verificada (cuando se incrementó o cambiaron las entradas relevantes para la compilación) -> revisión previa a la confirmación (ponytail-review y hooks del repositorio) -> git commit de alcance exacto -> git push a la rama remota.
2. Cada confirmación creada por dlm-version-master debe usar un mensaje de confirmación detallado de varias líneas estructurado basado en el git diff --cached real y las transiciones de versión (nunca un resumen de una línea o un vago "incrementar versión" / "actualizar archivos"). Debe incluir explícitamente las cuatro secciones requeridas:
   • 修改范围 (Alcance): módulos/proyectos/subsistemas cambiados y archivos clave en la lista blanca o límites;
   • 对应版本 (Versión): nivel de incremento (ninguno / patch / minor / major) y la transición de versión antigua -> nueva de cada módulo afectado (o versión actual con ninguno (sourceHash sin cambios) cuando ningún módulo se incrementó);
   • 怎么改的 (Cómo): implementación técnica concreta derivada del diff preparado (puntos de entrada, flujo de datos/control, ajustes de algoritmo/UI/config/compilación);
   • 为什么改的 (Por qué): causa raíz, requisito/controlador de tarea, desencadenante de defecto o razón arquitectónica/de compatibilidad tanto para el cambio de código como para la decisión de versión.
3. Cuando las reglas internas decidan no incrementar versiones (hashes de origen de módulo sin cambios), omitir la mutación de versión y no crear una confirmación de versión vacía; aún así preparar, revisar, confirmar (con el mismo mensaje de confirmación estructurado de cuatro partes) y enviar cualquier cambio de repositorio intencionado en la lista blanca dentro del alcance, o enviar confirmaciones verificadas existentes sin enviar en la rama actual.

Salida

Informar la fuente del perfil del repositorio, la línea base de release Congelada/línea de parada, la decisión de versión interna (ninguno / patch / minor / major) y su justificación, el alcance y los comandos de compilación (cuando se ejecutó), las transiciones de hash/versión del módulo, los módulos sin cambios, las pruebas coincidentes con la reclamación, los metadatos/hashes de salida verificados, el consumidor/ruta del registro de cambios, la lista blanca de archivos modificados, el mensaje de confirmación estructurado completo (修改范围 / 对应版本 / 怎么改的 / 为什么改的), el hash de confirmación, el resultado verificado del push de la rama remota y las brechas Bloqueantes versus de Asesoramiento. Mantener los niveles de evidencia más altos distintos del éxito de la compilación y la sincronización Git.