거친 돌 넣고, waystone 나와

"아무도 깨끗한 데이터로 여행을 시작 안 해. 난장으로 시작하고, 그 난장은 적이 아니라 raw 재료야."

진짜 출발점

구조화된 입력을 요구하는 여행 계획 도구는 이미 진 거야. 진짜 계획은 구조화된 채로 도착 안 하니까. 붙인 텍스트 벽, 반쯤 포맷된 노트, 전달된 이메일, 아니면 canonical 케이스인 엄마 OneNote 표 사진으로 도착해. Carve는 그 현실에 대한 Waystone의 답이야. 이름이 아이디어 전부를 말해. 거친 돌 넣고, waystone 나와. 존재하는 어떤 형태로든 raw 재료를 건네면, Pippa가 그걸 실제로 계획할 수 있는 깎인 scaffold로 깎아.

scaffold가 곧 plan이야

Carve가 만드는 건 옆에 따로 있는 별도 구조화 record가 아냐. canonical day-section 문법으로 쓰인 plan 문서 자체야. 각 날은 아래에 soft-라벨 bullet(숙소, 이동, 계획, 대안, 메모)이 달린 dated heading이야. dated heading이 유일한 하드 규칙이고. 앱 전체가 날 navigation, 그러니까 로그 사이드바랑 캘린더랑 날 chip을 그 heading에서 파생하고, 미래 Start Logging 트랜잭션이 같은 문법을 파싱해 날 record를 mint할 거니까. Carve는 새 포맷을 지어내지 않아. 난장을 엔진 전체가 이미 말하는 하나의 형태에 담아.

Vision은 first-class 입력이야

OneNote 사진은 파티 트릭이 아냐. first-class 입력 경로야. 스크린샷이 vision 레인을 타서, 사진 찍은 표랑 손글씨 itinerary랑 예약 확인 스크린샷이 전부 정당한 raw 돌이야. 이게 중요한 건 거친 계획을 준비한 사람(엄마, 여행사, 과거의 너)이 파서가 좋아할 포맷으로 준비하는 일이 거의 없어서야. 계획을 실제 사는 곳에서, 이미지로도 만나는 게, Carve를 단정한 여행뿐 아니라 진짜 여행에서 쓸모 있게 만들어.

Code

import 계약, 일곱 단계·text

1. 원본 artifact + checksum 보존
2. 텍스트와 구조 힌트 추출 (소스 절대 안 덮음)
3. 날짜, 장소, 이동, 숙소, 예약, 메모,
   미해결 질문 식별
4. 제안된 normalized Day/section 구조 생성
5. preview 나 diff 보여줌
6. 부분 accept 와 정정 허용
7. 각 accept 된 필드에서 소스로 provenance 유지

# Carve 는 이걸 plan 문서에 대해 실현해:
#   output = canonical day-section 문법
#   '## YYYY-MM-DD (D3) - title' + soft bullet (숙소/이동/...)
#   dated heading 이 유일한 HARD 규칙; 나머지는 soft.

Exercise

마지막으로 계획한 여행을 찾아서 계획의 원래 거친 형태를 찾아봐. 이메일, 노트, 스크린샷, 메시지 스레드. 컴퓨터가 깨끗이 파싱할 만한 거였어? 이제 바로 그 난장을 도구에 건네고 깎인, 편집 가능한 날짜별 scaffold를 되받는 걸 그려봐. 도구가 네 진짜 디테일을 하나도 안 잃고 안 지어내려면 뭐가 참이어야 할까?

Hint

import 도구의 정직성 테스트는, 정리된 버전이 아니라 네 실제 난장을 받아서 모든 진짜 fact를 보존하며 빚을 수 있느냐야. 입력을 먼저 정리하라고 하면, 어려운 부분을 너한테 떠넘긴 거야. Carve의 베팅은 도구가 깎아야지 네가 아니라는 거야.