Learning — Contract first

한 줄: 폴더·페이지보다 분류 계약을 먼저 고정하지 않으면, AI가 매 세션 기준을 다시 지어 위키가 쓰레기 서가 된다.

맥락

wiki1은 도구·도메인·verify가 많았지만, 최상단 “무엇을 어떤 기준으로” 단일 owner가 약했다.
wiki2 설계에서 명시한 실패: 규정집 없이 서가(토폴로지)만 운영 → 사서(AI)가 주제/저자/기분으로 제각각 꽂음.

Karpathy 패턴은 schema 층을 두라고 한다. wiki2는 그 schema를 ontology → taxonomy → topology → ops 순서로 강제했다.

배운 것

1. 계약 비용은 앞당길수록 싸다. 불변식 V1을 페이지 0일 때 잠근 것이, 나중에 폴더를 축으로 쪼개다 마이그레이션하는 것보다 싸다.
2. 축은 폴더로 복제하지 않는다. corpus/domain을 디렉터리에 미러하면 분류 진실이 두 곳이 된다. flat + frontmatter가 맞았다.
3. layer 분리가 없으면 orbit 클리핑이 곧 “내 결론”이 된다. source/model/judgment를 갈라야 external을 owned judgment로 위장하지 않는다.
4. 닫힌 집합 + 확장 절차가 없으면 type/domain이 태그 덤프가 된다. project 목록 P0(빈 집합)도 같은 이유다.
5. 첫 ingest는 규율을 검증하는 재료이지, 양 확보가 아니다. gist 1건으로 brief/concept/map 경로를 통과시킨 뒤 judgment를 채웠다.

앞으로의 기본 자세

• 새 폴더·새 type·새 domain이 필요해 보이면 → 먼저 ontology 개정 제안.
• 답이 좋아도 fileback 시 축·불변식을 채운 뒤에만 커밋 단위로 인정.
• reference 본문을 키우고 싶어지면 → 그건 새 owned 페이지이지 reference 확장이 아니다.

폐기·수정 조건

• 단일 축으로도 혼란이 사라졌다고 반복 입증되면 layer 축 축소를 논의 (지금은 축소하지 않음).
• topology를 축 미러로 바꿔야 할 명확한 도구 제약(예: 도구가 폴더만 검색)이 생기면 그때 재설계 — 습관만으로 변경 금지.

근거

• ../ontology.md — §1 순서 원칙, §4 불변식, §7 확장 절차
• ../AGENTS.md — 운영이 ontology에 종속
• brief-karpathy-llm-wiki — schema/wiki/raw 패턴
• concept-llm-wiki-three-layers — schema 두껍게 만들기
• map-llm-wiki-pattern — wiki2 덧붙인 것
• concept-persistent-wiki-vs-rag — 규율 없으면 덤프

관련

• 이후 template은 이 learning의 실행 장치 (형식 편차 감소).
• 템플릿: templates/template-learning, templates/template-decision