"여기선 말이 싸지 않아. 말이 itinerary 를 짓는 방식이야 — 단, 네가 yes 한 다음에."
턴 하나가 mutation 을 제안할 수 있다
대화가 곧 계획이면, 대화 턴은 계획을 바꿀 수 있어야 해 — 아니면 그냥 잡담이지. Waystone 에선 턴 하나가 하나 이상의 proposed 도메인 mutation 을 만들 수 있어: 날 추가·제거·재정렬; 후보 장소 추가하거나 planned 로 승격; route 나 호텔 비교; 추천과 rationale 기록; 아빠의 결정 기록; travel event 생성; 링크된 글 문서 열기. 대화는 폼 위의 장식이 아냐 — 구조화된 state 가 쓰이는 주된 방식이야.
Proposal, 그다음 accept — 절대 조용히 아냐
근데 여기 신뢰를 지키는 규율이 있어: Pippa 는 중요한 변경을 보이는 proposal 이나 diff 로 제시하고, 아빠가 같은 대화에서 accept·reject·refine 할 수 있어. 언급되는 순간 중요한 게 쓰이는 일은 없어. accept 만이 proposal 을 canonical Waystone state 로 바꿔. 이건 'AI 가 그냥 해버렸다' 패턴 — assistant 가 네 데이터를 조용히 mutate 하고 넌 나중에 발견하는 — 에 대한 의도적 거부야. Waystone 에선 'Pippa 가 제안했다' 와 '이제 이게 사실이다' 사이 경계가 명시적인 인간의 행위야.
Accept 된 state 는 provenance 를 실는다
proposal 이 accept 되면, 결과 state 는 고아로 도착하지 않아. 그걸 만든 대화와 결정으로 provenance 를 간직해. 몇 달 뒤, 추가된 날이나 승격된 장소를 보고 왜 인지 추적할 수 있어 — 어느 턴, 어떤 추론, 어떤 결정. 그 provenance 가 itinerary 편집 더미를 방어 가능한 history 로 바꿔. 설명 못 하는 편집은 신뢰 못 하는 편집이고, lineage 있는 편집은 audit·재방문·학습 가능한 거야.