Selecciona el contexto por responsabilidad, no por proximidad

2083. Identidad de la lección

Módulo

5.4 — Gestión del contexto

Lección

Selecciona el contexto por responsabilidad, no por proximidad

Tipo académico

Flujo de trabajo

Tipo de esquema

Mixto

Orden

Lección 1 del módulo

Tiempo estimado

30–40 minutos: unos 20 minutos de explicación y 15–20 minutos de práctica evaluada con el repositorio de muestra. La práctica de transferencia opcional no está incluida.

2084. Objetivo de aprendizaje

Al terminar esta lección, podrás construir un paquete de contexto mínimo para un cambio específico seleccionando archivos, contratos y evidencia del repositorio según su responsabilidad, propiedad y dependencia, y después aceptar o rechazar una solicitud de información generada por IA con una justificación escrita.

2085. Por qué importa

Un agente de IA puede producir un cambio plausible a partir de un contexto incompleto o saturado. Que parezca correcto no demuestra que haya visto al responsable de la regla, el contrato pertinente o el sistema que consume el resultado. Un paquete demasiado pequeño oculta restricciones necesarias; uno demasiado grande aumenta la ambigüedad y dificulta la revisión. Además, el árbol de trabajo no es automáticamente confiable: sus cambios sin confirmar pueden ser intencionales, accidentales o ajenos a la tarea. Seleccionar el contexto de forma deliberada acota el problema para el agente y te proporciona una base trazable para evaluar su propuesta.

2086. Conocimientos previos

Debes poder describir el papel de un agente, distinguir la orquestación de la ejecución y auditar una cadena en busca de afirmaciones no respaldadas, como en el trabajo anterior de la Etapa 5. También debes poder identificar un cambio solicitado, declarar qué comportamiento debe conservarse y usar información básica de estado, diff e historial de commits de Git para inspeccionar la evidencia del repositorio.

2087. Concepto central

El contexto se selecciona por responsabilidad, no por proximidad.

Un archivo cercano no es relevante automáticamente. Incluye un archivo cuando sea responsable del comportamiento que cambia, cuando defina un contrato que limite ese comportamiento o cuando sea una dependencia directa necesaria para evaluar el cambio. Incluye evidencia del repositorio cuando ayude a establecer cuál es el cambio actual, cuál era la implementación confirmada o qué comportamiento afecta una modificación reciente. Excluye los archivos que solo están al lado, se parecen visualmente o participaron en cambios anteriores sin afectar al comportamiento solicitado.

Para cada archivo candidato o fuente de evidencia, formula estas preguntas:

1. Responsabilidad: ¿Qué comportamiento o contrato posee o describe este elemento?
2. Dependencia: ¿El cambio solicitado lee, llama, implementa o valida algo que está aquí?
3. Evidencia: ¿Qué dato concreto necesita el agente para actuar o tú para revisar el resultado?
4. Confianza: ¿La evidencia aparece en el historial de commits, en el diff actual o solo en el árbol de trabajo?

Si no puedes responder con precisión al menos una de las tres primeras preguntas, probablemente el elemento no pertenece al paquete mínimo. Si la respuesta depende de un cambio sin confirmar, declara esa limitación en lugar de tratar el archivo como fuente válida.

2088. Modelo mental

Usa el paquete R-O-D-E:

Un paquete útil no es una descarga de archivos. Es una cadena breve:

comportamiento solicitado → responsable → dependencia directa → evidencia de verificación

Escribe una frase que explique la función de cada elemento incluido. Para la evidencia de Git, indica si procede del diff actual, de un commit específico o de ambos. Un archivo del árbol de trabajo puede ser útil para la inspección, pero su mera presencia no demuestra que sea intencional ni una fuente válida.

2089. Ejemplo concreto

Supón que el cambio solicitado es: «Cuando se active una respuesta de alerta, muestra el mensaje de alerta existente sin modificar el umbral de respuesta».

Un paquete mínimo podría contener:

• El responsable de la regla que decide cuándo se activa la respuesta de alerta. Esto establece el umbral que debe permanecer igual.
• El mensaje o contrato de presentación que consume la respuesta de alerta. Esto establece la forma esperada de entrada y salida.
• El llamador o coordinador directo que conecta el disparador con la respuesta. Esto permite comprobar cómo se alcanza el comportamiento.
• La prueba enfocada o regla de validación del umbral y del mensaje. Esto aporta evidencia de que el comportamiento protegido permanece intacto.
• El diff actual, si existe, y el cambio confirmado relevante que introdujo el comportamiento. Esto permite distinguir el estado visible del árbol de trabajo de la evidencia de una modificación intencional.

El paquete no incluye automáticamente todos los archivos de interfaz cercanos, todos los demás tipos de respuesta, configuraciones no relacionadas ni el directorio completo. Solo deben entrar si el rastreo de dependencias demuestra que son necesarios. La diferencia importante no es si un archivo está cerca del código modificado, sino si aporta una responsabilidad, un contrato, una dependencia o evidencia revisable que sea necesaria.

2090. Flujo de trabajo con IA

Usa la IA para proponer una solicitud de información, no para decidir el paquete por ti.

1. Declara el cambio solicitado, el comportamiento protegido y las exclusiones conocidas.
2. Pide al agente que devuelva los archivos, contratos, pruebas y evidencias de Git que solicitaría, con una razón para cada elemento.
3. Compara esa solicitud con tu análisis R-O-D-E.
4. Acepta un elemento solo cuando puedas justificar su responsabilidad, dependencia, contrato o valor de verificación.
5. Rechaza un elemento cuando se incluya únicamente por estar cerca, ser parecido, aparecer con frecuencia o resultar cómodo. Registra el motivo del rechazo.
6. Añade por tu cuenta la evidencia que falte, especialmente un diff enfocado o un commit relevante que el agente no haya solicitado.

La solicitud del agente es una propuesta, no una autoridad. La comparación debe dejar un registro de qué sugerencias aceptaste, cuáles rechazaste y por qué.

2091. Flujo de trabajo con Git

Inspecciona la evidencia del repositorio antes de tratar los archivos actuales como el contexto completo:

• Consulta el estado del árbol de trabajo para identificar archivos sin confirmar.
• Revisa el diff enfocado para detectar cambios que puedan afectar al comportamiento solicitado.
• Consulta el historial de commits relevante para distinguir una implementación establecida de una edición local o de residuos accidentales.
• Registra si cada dato seleccionado procede del historial de commits, del diff actual o de ambos.

El árbol de trabajo no es automáticamente confiable. Es un estado que debe inspeccionarse, no una declaración de que cada cambio visible pertenece a la tarea. No uses silenciosamente una edición sin confirmar como contrato ni la descartes sin más. Si el diff no está relacionado o su intención es desconocida, marca esa situación como incertidumbre y mantenla separada del paquete de referencia hasta que puedas justificar su función.

2092. Error común

El error común es confundir la proximidad del directorio, la frecuencia en los resultados de búsqueda o el estado actual del árbol de trabajo con relevancia y autoridad. El resultado es un paquete grande lleno de ejemplos, implementaciones duplicadas, convenciones antiguas y ediciones locales ajenas. Entonces el agente debe adivinar cuál es la fuente de referencia y no puedes comprobar si su propuesta respeta al verdadero responsable.

Otro error es aceptar completa la solicitud de información generada por IA. El agente puede omitir una fuente de validación directa, pedir un ejemplo cercano o tratar un archivo sin confirmar como un contrato establecido. Debes comparar cada solicitud con la evidencia de responsabilidad y dependencia, y justificar tanto las decisiones de aceptación como las de rechazo.

2093. Práctica guiada

Realiza esta práctica evaluada usando únicamente el repositorio acotado que aparece a continuación. No inventes archivos, dependencias ni historial del repositorio.

Solicitud de cambio

Aplica la política existente de tiempo de reutilización del repositorio a la activación de santuarios. Conserva la condición de éxito actual, el mensaje de éxito, la estructura del resultado y el comportamiento de persistencia del registro de activación.

Mapa del repositorio y evidencia candidata

Fragmentos relevantes:

// src/shrine/ShrineInteraction.ts
activate(player, shrine, now) {
  if (!rules.canActivate(player, shrine)) {
    return InteractionResult.failure("unavailable");
  }
  const result = InteractionResult.success(messages.shrineActivated);
  store.recordActivation(player.id, shrine.id, now);
  return result;
}

// src/interaction/CooldownPolicy.ts
export const INTERACTION_COOLDOWN_MS = 30_000;
export function isReady(lastSuccessAt, now) {
  return lastSuccessAt === null || now - lastSuccessAt >= INTERACTION_COOLDOWN_MS;
}

// src/persistence/InteractionStore.ts
lastActivationAt(playerId, shrineId): number | null;
recordActivation(playerId, shrineId, now): void;

// src/interaction/InteractionResult.ts
export type InteractionResult =
  | { ok: true; message: string }
  | { ok: false; reason: string };

Las relaciones de dependencia proporcionadas son:

• ShrineInteraction → ShrineRules.canActivate
• ShrineInteraction → InteractionResult
• ShrineInteraction → InteractionStore.recordActivation
• El tiempo de reutilización solicitado requiere CooldownPolicy.isReady e InteractionStore.lastActivationAt.
• InteractionPrompt consume el mensaje devuelto, pero no define el comportamiento de activación ni el tiempo de reutilización.
• ChestInteraction es un ejemplo de código cercano, no una dependencia de ShrineInteraction.

Evidencia de Git

$ git status --short
 M src/ui/InteractionPrompt.ts
?? notes/cooldown-ideas.md

# diff enfocado del árbol de trabajo: src/ui/InteractionPrompt.ts
- buttonLabel = "Activate"
+ buttonLabel = "Invoke"

Commits relevantes:

91ac4e2 Centralize interaction cooldown calculation
  src/interaction/CooldownPolicy.ts

64bd118 Persist shrine activation records
  src/shrine/ShrineInteraction.ts
  src/persistence/InteractionStore.ts
  tests/shrine/ShrineInteraction.test.ts

2f08c77 Refresh interaction prompt copy
  src/ui/InteractionPrompt.ts

Trata la evidencia de los commits como historial establecido del repositorio. Trata el diff mostrado de la interfaz y la nota sin seguimiento como evidencia del árbol de trabajo cuya intención no está establecida.

Solicitud de información de IA proporcionada

Para este ejercicio, compara tu análisis con esta solicitud fija generada por IA:

1. Envía el directorio src/interaction/ completo porque el comportamiento del tiempo de reutilización podría estar distribuido.
2. Incluye ShrineInteraction.ts, CooldownPolicy.ts e InteractionResult.ts.
3. Incluye ChestInteraction.ts como ejemplo de implementación.
4. Incluye InteractionPrompt.ts porque ahí ve el resultado la persona usuaria.
5. Incluye ShrineInteraction.test.ts y el diff enfocado del árbol de trabajo.

La solicitud omite ShrineRules.ts, InteractionStore.ts y los commits relevantes.

Entrega obligatoria

Primero clasifica todos los candidatos en una tabla:

Después entrega un paquete R-O-D-E que contenga:

1. Una frase que describa la solicitud de cambio.
2. Dos o tres criterios de aceptación, incluido el comportamiento que debe protegerse.
3. El conjunto mínimo justificado de archivos o contratos.
4. El diff enfocado y la evidencia de commits que incluirías, pondrías en duda o excluirías.
5. Una frase que explique la función de cada elemento incluido.
6. Al menos dos exclusiones explícitas con sus motivos.
7. Al menos un elemento aceptado de la solicitud de IA, con su justificación.
8. Al menos un elemento rechazado de la solicitud de IA, con su justificación.
9. Una incertidumbre sin resolver que deba aclararse antes de que un agente proponga código.

El paquete debe distinguir el historial de commits de la evidencia del árbol de trabajo. También debe explicar por qué una fuente de validación directa resulta más útil que un ejemplo cercano cuando solo se necesita una de las dos.

Práctica de transferencia opcional

Después de completar la práctica evaluada, repite el proceso en un proyecto real que tengas autorización para inspeccionar. Mantén ese paquete separado, ya que la evidencia de ese repositorio no forma parte de esta evaluación.

2094. Validación / evidencia

2095. Ideas clave

• La relevancia la determinan la responsabilidad y la dependencia, no la proximidad del directorio.
• Un paquete mínimo conecta el comportamiento solicitado con su responsable, su dependencia directa y la evidencia de verificación.
• Un diff o un commit relevante pueden explicar el estado y el alcance de un cambio; el árbol de trabajo por sí solo no demuestra la intención ni convierte su contenido en una fuente válida.
• Una solicitud de información generada por IA es una propuesta que debes comparar, no un paquete que debas aceptar automáticamente.
• Cada elemento incluido y cada sugerencia de IA aceptada o rechazada necesita un motivo escrito.

2096. Próxima lección

Continúa con 5.4 L2 — Detectar contexto obsoleto o engañoso.

2097. Comprobación