Skip to main content

Cómo funciona el drift

Desde un checkout local, driftless context get --diff cruza los archivos modificados contra los topics del workspace mediante sus paths y patrones glob. Con --mark, los topics reviewed que coinciden quedan marcados como drifted con un motivo legible. Por ejemplo, si el trabajo local cambia src/auth/guard.ts y src/auth/service.ts, el topic auth-flow anclado a src/auth/** puede pasar a:
Drifted: los cambios locales tocan src/auth/guard.ts y src/auth/service.ts.

Drift local explícito

La CLI reporta drift desde tu checkout local:
--mark es opt-in y explícito. El --diff a secas solo despliega, así que el trabajo en progreso nunca cambia el estado del equipo salvo que lo pidas. Es idempotente (los topics ya en drift se dejan tal cual).

Un empujón, no una alarma

El drift es un empujón, no un error: “el código bajo este topic se movió, vale la pena mirarlo”. Tolera falsos positivos por diseño: confía en el código y actualiza el topic solo si el cambio realmente alteró cómo funciona el área. Un archivo ancla borrado produce un empujón distinto: “archivo anclado borrado: re-ancla o archiva este topic”.

Ciclo de vida

Cuando un topic entra en drift:
  1. driftless sync expone el drift persistido a cada miembro del equipo
  2. Un agente o humano revisa el cambio
  3. Si el contexto sigue en pie, súmalo al knowledge (--status reviewed) para volverlo fresco otra vez
  4. Si ningún repo reclama ya el topic, pasa a orphaned

Cómo revisar el drift

Solo una llamada local explícita a context get --diff --mark. El --diff a secas recupera contexto sin cambiar el estado del workspace.
Sí. Corre driftless context get --diff --mark desde el checkout relevante. Actualiza el topic si cambió su explicación durable; de lo contrario confirma que sigue vigente.
La validación local de patterns detecta anchors ausentes al escribir desde la CLI. context doctor también lo marca como zombie, un ancla que apunta a nada. Arregla los patrones o archiva el topic.