상태를 디스크에 쓰면 압축도 살아남는다

TodoWrite와 Task의 차이점은?

s03의 TodoManager도 작업을 나열할 수 있습니다—하지만 메모리에 저장됩니다. s06에서 다룬 auto_compact가 트리거되면 messages[]가 summary로 교체되고 TodoManager의 상태도 사라집니다 (in-memory이기 때문에).

s07의 Task는 다릅니다: 각 task는 .tasks/task_42.json 파일입니다. context가 압축되든, 프로세스가 재시작되든, agent가 교체되든—디스크 파일이 남아있는 한 작업도 남아있습니다.

# .tasks/task_12.json
{
  "id": 12,
  "subject": "Refactor auth middleware",
  "description": "Extract JWT logic to shared module",
  "status": "pending",
  "blockedBy": [8, 11],   # #8과 #11을 먼저 완료해야 합니다
  "owner": ""
}

선택 규칙: 일회성 할 일(이번 세션 후 필요 없음)에는 todo; 지속적 작업(세션을 넘어 유지, 의존성 있음)에는 task.

blockedBy · 의존성 그래프의 특성

blockedBy는 task id 목록입니다—이것들이 모두 completed 상태가 되어야 현재 task가 "실행 가능"해집니다.

s07 구현에는 정교한 세부 사항이 있습니다: task가 완료되면 자동으로 모든 다른 task의 blockedBy 목록에서 자신을 제거합니다.

def _clear_dependency(self, completed_id: int):
    # Scan every task, remove completed_id from their blockedBy
    for f in self.dir.glob("task_*.json"):
        task = json.loads(f.read_text())
        if completed_id in task.get("blockedBy", []):
            task["blockedBy"].remove(completed_id)
            self._save(task)

이렇게 하면 agent가 별도의 "어떤 task가 차단 해제됐는가" 테이블을 관리할 필요가 없습니다—.tasks/를 순회하면서 status=="pending" and not blockedBy인 것을 찾으면 됩니다.

의존성 그래프 인터랙션

아래 widget에서 5개 task의 의존성 그래프를 확인하세요. "complete"를 클릭해 blockedBy가 자동으로 업데이트되고 어떤 task가 "실행 가능" (초록색 하이라이트)해지는지 관찰하세요.

압축 후에도 살아남는가?

s06에서 auto_compact가 messages[]를 하나의 summary로 교체한다고 배웠습니다. 하지만 task는 영향을 받지 않습니다. 디스크에 있기 때문입니다. 테스트해보세요: agent가 5개 task를 완료하고 대화가 압축된 후 .tasks/를 스캔하면 바로 이어서 진행할 수 있습니다.