DLM Load 7 Portable

¿Qué hace DLM Load 7 Portable?

Propósito

Fijar un repositorio y cargar su propio contrato, restricciones, tarea activa, archivos de manifiesto y anclajes de origen. Esta habilidad personal define el método de carga; el estado del repositorio permanece completamente propiedad del repositorio.

Puerta de gobierno de resultados

Aplica el Gobierno de Resultados DLM compartido. Léelo antes de load-and-continue, antes de tratar una brecha de contexto como bloqueante, o siempre que la carga alimente una revisión formal, delegación, liberación u otra decisión de estado externo.

• Trata la carga como una verificación combinada de identidad/ámbito de seguridad seguida de los hechos mínimos necesarios para la siguiente decisión material.
• No repitas Init de Sesión, recongeles autoridad ni generes artefactos del plano de control cuando la identidad del repositorio/tarea ya sea estable.
• load-and-continue no omite el gobierno: antes de la primera escritura sustancial, delegación ejecutable, acción externa o mutación de estado/recursos, confirma que la Línea de Base de Aceptación aplicable está Congelada por su propietario o que una autorización de sesión explícita equivalente proporciona el mismo objetivo, criterios, Ámbito Autorizado, evidencia y línea de parada.
• Una brecha de contexto bloquea solo cuando un contrato aplicable la marca como requerida y su ausencia impide materialmente la afirmación o acción segura actual. La obsolescencia administrativa no relacionada se informa para cierre impulsado por el consumidor, no se permite retrasar el trabajo objetivo.
• La documentación, el código fuente, la evidencia de ejecución y el estado de coordinación permanecen separados; carga la capa que se ajuste a la decisión en lugar de usar una como proxy de otra.

Resolución del repositorio

1. Prefiere una raíz de repositorio proporcionada explícitamente por el usuario.
2. De lo contrario, usa la raíz de Git más cercana que contenga el doc_llm relevante.
3. En un monorepo o ambigüedad de checkout anidado, inspecciona las identidades candidatas en doc_llm/dlm.json y pregunta solo si el objetivo aún no se puede determinar de forma segura.
4. Lee los archivos AGENTS.md, doc_llm/dlm.json y doc_llm/README.md aplicables antes de interpretar rutas o estados.
5. Nunca cargues el DLM de un proyecto vecino porque sea familiar por memoria o una conversación anterior.

Si el proyecto tiene un contrato, la repository_root, doc_llm_root, project_id, los estados y las reglas de compatibilidad declaradas son autoritativos. Las rutas de habilidades personales nunca son archivos de contexto del proyecto.

Modos de intención

• load-only: el usuario solo pidió inspeccionar, resumir o evaluar contexto. Permanece de solo lectura y detente después del informe de contexto.
• load-and-continue: el usuario ya solicitó planificación, implementación, revisión o diagnóstico. Carga primero, luego continúa la tarea autorizada sin pedir una confirmación redundante.

La carga es una fase del flujo de trabajo, no un modo de plataforma ni autoridad de mutación.

Init de sesión

En la primera entrada, lee el contrato/README y las restricciones BRIEF/L0 aplicables; reutilízalos mientras la identidad del repositorio y las restricciones relevantes permanezcan estables. Para una tarea nombrada o ya bloqueada, ve directamente a su Epic/Subtask y las entradas de manifiesto requeridas. Lee el backlog/índice solo para descubrir propiedad, resolver dependencias o elegir trabajo dentro de una cola ya autorizada. Un diagnóstico o pregunta ad-hoc no autoriza la selección o ejecución de un elemento de backlog no relacionado.

Cuando la selección de tarea es parte de la solicitud del usuario o de una cola ya autorizada, selecciona de forma determinista:

1. Epic/Subtask especificado por el usuario;
2. tarea ya bloqueada en la conversación actual y aún activa;
3. tarea en progreso ordenada por las reglas de backlog/prioridad/ID del repositorio;
4. tarea planificada lista para dependencias usando el mismo orden;
5. las tareas bloqueadas se informan con su condición de liberación, no se tratan como ejecutables.

Si los candidatos permanecen empatados después de aplicar las reglas del repositorio, muestra el conjunto de candidatos útiles más pequeño en lugar de adivinar por marcas de tiempo de archivos o leer cada tarea histórica.

Identidad actual y reanudación

• Cuando el proyecto proporcionado por el usuario no tiene metadatos de Git, bloquee su directorio explícito más su propio contrato DLM. Informa el estado de Git como no disponible; nunca adoptes un repositorio padre o vecino para fabricar una identidad.
• Usa Epic/Subtask como la identidad canónica de la tarea. Resuelve una dependencia corta antigua dentro de su Epic propietario primero, luego solo si es globalmente única. Un ID simple compartido por varios Epics necesita desambiguación; no debe seleccionar silenciosamente la primera coincidencia.
• La tabla Meta principal actual (o sección ## Meta explícita) es autoritativa. Los registros históricos, planes archivados y una entrada Congelada antigua no anulan el estado actual o la aceptación. Lee evidencia histórica solo cuando la siguiente decisión la necesite.
• Prefiere un comando next/context existente propiedad del repositorio cuando proporcione identidad, dependencias, bloqueadores y orden de lectura. No instales un nuevo comando solo para cargar contexto ni trates su salida como autoridad de mutación.

Inmersión profunda en la tarea

1. Lee la tarea y localiza <context_manifest>.
2. Para esquema 2, requiere project, rutas / relativas al repositorio y un archivo concreto por entrada.
3. Cada <file> tiene path, intent y required; section y defer son opcionales.
4. Rechaza rutas absolutas, .., directorios, repositorios hermanos, raíces de habilidades personales y archivos de flujo de trabajo .agents/skills como contexto de tarea.
5. Los archivos faltantes requeridos por el contrato de la tarea actual bloquean la inmersión/afirmación profunda afectada. Los archivos opcionales faltantes, o registros administrativos no relacionados sin consumidor actual, se convierten en advertencias.
6. defer="true" es válido solo con required="false"; cárgalo solo cuando la decisión actual lo necesite.
7. Lee archivos independientes en paralelo cuando sea útil. Respeta section cargando la sección relevante con precisión.

Para manifiestos heredados, sigue la regla de compatibilidad del repositorio e informa la brecha. No migres silenciosamente durante la carga.

Contexto centrado en decisiones y reanudación

Después de las entradas requeridas, organiza la lectura adicional en torno a la siguiente pregunta material: restricciones aplicables, evidencia y contraevidencia, hechos faltantes y la siguiente entrada de origen. La relevancia por sí sola no establece suficiencia. En una reanudación real, conserva la última evidencia aplicable y las rutas fallidas excluidas; actualiza las dependencias cambiadas en lugar de repetir el Init de Sesión.

Para reutilización de evidencia, cambio de conocimiento L2 o fallo repetido, lee la sección correspondiente de Evidencia y decisiones. Para un conjunto útil de cambios explícitamente identificados, scripts/dlm_impact.py --repo-root <repo> --changed-file <archivo-relativo-al-repo> --json puede devolver candidatos de revisión L2 de solo lectura, incluida la propagación opcional de depends_on. No certifica la validez del conocimiento ni reemplaza las entradas de manifiesto requeridas. No lo ejecutes para cada lectura rutinaria.

Anclaje de código fuente

• Usa rg, navegación de símbolos, archivos de proyecto, pruebas, registros y evidencia generada para localizar la verdad de implementación.
• Comienza con lecturas de código fuente estrechas. Lee archivos completos cuando el ciclo de vida, la serialización, la máquina de estados o el comportamiento entre miembros hagan inseguros los extractos locales.
• Distingue afirmaciones de documentación, hechos de código fuente, evidencia de ejecución e inferencia no resuelta.
• Si DLM y el código fuente discrepan, informa la discrepancia y continúa desde el código fuente/evidencia actual a menos que la tarea sea explícitamente documentación primero.

Carga ad-hoc

Durante la ejecución, enruta a través de L1 global/L1 de dominio hasta el L2 relevante más pequeño y los anclajes de origen. No repitas todo el Init de Sesión cuando solo una decisión de dominio necesite más contexto.

Validación y salida

Ejecuta la verificación de salud del repositorio cuando la integridad del contrato/manifiesto sea relevante para la siguiente decisión o el usuario haya solicitado validación DLM. Usa el doctor genérico como evidencia de contrato de apoyo, no como un ritual:

python -B -X utf8 <directorio-habilidad>/scripts/dlm_doctor.py --repo-root <repo> --require-contract

Clasifica los fallos contra el objetivo y contrato actuales. Un fallo de contrato/ruta relevante puede bloquear la acción DLM afectada; una advertencia administrativa preexistente o no relacionada no puede invalidar un contexto de ingeniería por lo demás suficiente.

Informa la identidad del repositorio/proyecto, la tarea seleccionada y la base de selección, las restricciones cargadas y los anclajes de origen, el contexto faltante o desactualizado, el impacto material de cualquier brecha bloqueante, y si la tarea original continuará ahora. Una vez que la siguiente decisión tenga contexto suficiente, detén la carga y devuelve el esfuerzo a ese trabajo.

Breve opcional del Ledger v2 (scripts/dlm.py brief)

Al cargar un Epic que usa ledger.json, ejecuta python -X utf8 <directorio-habilidad>/scripts/dlm.py brief <E> <S> (o dlm.py status) para mostrar el breve de la tarea, las obligaciones activas, las hipótesis no resueltas y el estado del punto de control anterior junto con dlm_impact.py.