"시작일도 종료일도 없어. 타임라인은 잊힌 화요일로 거슬러 가고, 아직 안 지킨 약속으로 앞서 가."
양방향이 일급이야
건강엔 terminal state 가 없으니, 그 타임라인은 양쪽 으로 무한하고, 둘 다 평범해. 과거 scatter. 오늘 스캔한 2025 검진이 2025 아래 파일되고, 아빠가 잊은 증상이 지난 화요일로 옮겨가. 미래 scatter. 예정된 진료나 계획된 훈련 블록이 다음 달에 앉고. 이게 Track 3 의 date-picker 메커닉을 lifecycle 각도에서 본 거야. captured_at 은 적는 진짜 순간으로 남고, target_date 는 과거·미래 전 라인을 자유롭게 오가고, 둘은 절대 하나로 안 뭉개지고.
intervention 은 그냥 날짜 붙은 crumb 이야
'intervention' 을 loop 단계로 이름 붙이면 드는 유혹은, 시작·상태·workflow 를 가진 Intervention 엔티티를 짓는 거야. Forge 는 거부해. 새 처방, 바뀐 훈련 블록, 시술. 저마다 평범한 날짜 붙은 crumb 이고, symptom 이나 meal 이랑 종류가 다르지 않아. analysis 는 그 crumb 들에 대해 타임라인을 읽어. 훈련 블록이 바뀐 날을 찾고 그 양쪽의 trend 를 보고. intervention 은 스트림 속 마커지, 자기 기계장치를 가진 의식이 아냐.
왜 이 모양이 튼튼한가
날짜 붙은 이벤트의 append-only 스트림을 current state 로 projection 하는 건 오래 닳은 durable 한 패턴이야. 이름만 아닐 뿐 event sourcing 이고. 기록은 다시 쓰이지 않고 더해지기만 하고, '현재 그림' 은 언제나 다시 지을 수 있는 projection 이고, 과거·현재·미래가 세 시스템이 아니라 한 축에 살아. 도메인에 자연스러운 완료가 없을 때 이게 맞는 모양이야. 그리고 그게 정확히 Track 7 의 저장 층이 log 를 replay 해서 모든 derived view 를 다시 지을 수 있는 이유고.