모든 인덱스는 파생 미러

"인덱스가 파일과 어긋나면, 인덱스가 틀린 거야. purge 하고 replay 해 — 화해로 patch 하지 마."

인덱스는 파생이지 절대 master 가 아냐

Rekindle 은 진짜 데이터베이스를 키워 — 노트 인덱스, 전문 검색, voice 레이어용 corpus 인덱스. 아무것도 진실이 아냐. 하나하나가 마크다운 파일의 파생 미러 고, 내용 전체를 버리고 디스크에서 다시 지어도 아무것도 안 잃어. 그 지위는 나중에 발견하는 게 아니라 처음에 정해져. 인덱스는 파일이 이미 말하는 것의 빠른 캐시야.

purge 하고 replay, diff 하고 patch 하지 마

이걸 정직하게 유지하는 규율이 복구 규칙이야. 인덱스와 파일이 어긋나면 — 외부 편집, 쓰기 도중 크래시, 버그 — 답이 절대 '델타를 알아내서 인덱스를 화해로 patch' 가 아냐. 파생 행을 purge 하고 파일에서 replay 야. diff-and-patch 화해가 딱 부패가 사는 곳이야. 모든 patch 가 뭐가 일어났는지에 대한 작은 추측이고, 추측은 쌓여. 다시 짓기엔 추측이 하나도 없어.

// 복구는 항상 이 모양 — 절대 화해 아님.
fn rebuild_index(vault: &Path) -> Result<(), Error> {
    purge_index()?;                       // 파생 행 전부 버림
    for file in markdown_files(vault) {   // 진실에서 replay
        index_note(&read_to_string(&file)?)?;
    }
    Ok(())
}

이게 cwkPippa 의 규율을 한 도메인 옆으로 가져온 거야. 거긴 JSONL 로그가 진실이고 SQLite 와 벡터 저장소가 purge-and-replay 로 다시 지어지는 파생 미러야. 여긴 마크다운 파일이 진실이고 모든 인덱스가 미러. 같은 규칙, 같은 이유: 하나의 권위, 다시 지을 수 있는 파생물, 어디에도 화해 로직 없음.

메타데이터는 frontmatter 에 살아

규칙은 메타데이터로 확장돼. 태그, 날짜, 노트의 초고 상태 — 사이드카 데이터베이스가 아니라 파일의 frontmatter 에 살아. 태그가 DB 에만 살면 그 DB 가 두 번째 master 가 돼 (잃으면 진짜 데이터를 잃은 거야) 고, file-canonical 주장 전체가 반쪽 진실이 돼. 메타데이터를 frontmatter 에 두면 파일이 여전히 자기에 대한 전부를 지니고, 인덱스는 마땅히 그래야 할 것 — 파일이 이미 담은 것의 빠르고 버려도 되는 뷰 — 으로 남아.

Code

복구는 purge-and-replay, 절대 diff-and-patch 아님·rust

// 인덱스가 디스크와 어긋나면, 인덱스가 틀린 거야. 다시 지어.
fn rebuild_index(vault: &Path) -> Result<(), Error> {
    purge_index()?;                        // 파생 행 전부 버림
    for file in markdown_files(vault) {    // 진실에서 replay
        index_note(&std::fs::read_to_string(&file)?)?;
    }
    Ok(())
}

// 의도적으로 reconcile_index() 가 없어: diff 없음, patch 없음,
// '뭐가 바뀌었나 알아내서 고치기' 없음. 모든 patch 가 추측이고,
// 추측은 부패로 쌓여. 다시 짓기엔 추측이 없어.

메타데이터는 사이드카 DB 가 아니라 파일을 타·markdown

---
title: The Rekindling
status: draft
tags: [editor, cm6, architecture]
date: 2026-07-16
---

파일이 자기에 대한 전부를 지녀. 인덱스를 잃어도 아무것도 안 잃고,
이 파일들에서 다시 지어. 태그를 소유한 사이드카 DB 를 잃으면
진짜 데이터를 잃은 거야 — 그게 두 번째 master 야.

Exercise

캐시나 인덱스가 있는 네가 아는 시스템에 다시-짓기 질문을 던져. 통째로 지우고 권위 있는 원천에서 데이터 손실 없이 재생성할 수 있어? 못 하면, 정확히 뭘 잃을지 나열해 — 그 목록이 네 '캐시' 가 몰래 소유한 데이터고, 그게 그걸 두 번째 master 로 만들어. 그다음 그 데이터가 실제로 어디 살아야 할지 정해.

Hint

흔한 범인은 계산됐다 잊힌 필드야. 사용자가 정한 태그, 정렬 순서, '마지막 열람', 커스텀 라벨. 캐시에만 있으면 캐시가 아냐 — 권위 있는 산물 (여기선 frontmatter) 로 옮기면 인덱스가 진짜로 버려도 되는 게 돼.