omd:taste — Taste Dashboard
시스템이 사용자에 대해 알고 있는 취향을 한 뷰로 렌더한다. 신뢰는 가시성에서 나온다 — 루프가 뭘 배웠고, 뭘 기다리고, 뭘 모르는지 보여주면 사용자가 루프에 더 먹인다. 기본 동작은 읽기 전용 — 기록은 omd:remember, 반영은 omd:learn의 몫이고, 이 스킬은 보여주고 다음 행동만 안내한다. CLI 호출 없음 — Read/Edit 툴로 직접 처리.
입력 (모두 Read 툴)
.omd/preferences.md— canonical 포맷 (## <heading>+```omd-meta블록 + body —omd:remember스킬의 포맷 정의 참조). 모든 status의 엔트리를 파싱:id/timestamp/scope/signal/confidence/status.omd/foldin-proposal.json— 있으면status(proposed/applied/partial/snoozed)와scopes[](scope, count, score, summary)DESIGN.md— Core stable-anchor 라우팅 표시 + "모르는 것" 축 도출용. 유효한 hash-boundprofile: portable-corepackage가 있으면 graph object가 canonical이고 DESIGN.md는 표시용 portable projection이다. package가 없거나 invalid면 standalone DESIGN.md anchor만 읽는다. exact Core anchor가 전혀 없는 입력만 legacy compatibility로 읽어 의미 heading을 아래 anchor로 매핑하며, legacy 숫자 section은 출력하지 않는다.
빈 상태
.omd/preferences.md가 없거나 파싱된 엔트리가 0개면 두 줄로 끝낸다:
아직 학습된 취향이 없어요. 작업 중 "앞으로는 ~로 해"라고 말하면 omd:remember가 기록하고, 같은 취향이 쌓이면 omd:learn이 DESIGN.md에 정식 반영해요.
이때 .omd/ 디렉토리나 파일을 만들지 말 것 — 뷰 스킬이 상태를 생성하면 안 된다.
렌더 — 4 그룹 한 뷰
① 반영됨 (status: applied)
scope별 한 줄: body 요약 + 반영된 DESIGN.md stable anchor + applied_at
(있으면). anchor는 omd:learn의 Core object routing으로 도출:
| scope | DESIGN.md Core anchor / graph path |
|---|---|
components.* | components-states / graph.components_states |
color | foundations / graph.foundations.tokens |
typography | typography-assets / graph.typography_assets |
spacing | foundations / graph.foundations.tokens |
voice | content-locales / graph.content_locales |
motion | foundations / graph.foundations |
visualTheme | experience / graph.experience |
DESIGN.md 또는 valid graph에 해당 값이 실제로 없으면 anchor 표기는 생략한다 (추측으로 적지 말 것).
② 대기 중 (status: pending)
scope별로 그룹화해 한 그룹당 한 줄:
- 발생 횟수 — 해당 scope의 pending 엔트리 수
- confidence — explicit / inferred 구성 (예:
explicit ×2, inferred ×1) - 한 줄 요약 — 최신 엔트리 body의 첫 줄
- 폴드 제안까지 남은 횟수 — 자동 fold-in 게이트(session-end hook)의 기본 임계는 최근 7일 창 안에서 같은 scope 3회.
max(0, 3 - 7일 내 발생 횟수)로 계산해 "N회 더 쌓이면 제안돼요"로 표기. 이미 충족이면 "다음 세션 종료 시 제안 예정"
③ 보류됨 (snoozed)
.omd/foldin-proposal.json의 status가 snoozed면 그 scopes[]를 나열 — scope + summary + snoozed_at. "지금 반영하려면 omd:learn을 부르세요" 한 줄 덧붙임. proposal 파일이 없거나 snoozed가 아니면 이 그룹은 생략.
④ 시스템이 모르는 것 (가볍게)
DESIGN.md에는 정의돼 있지만 preference 엔트리(어느 status든)로 한 번도 확인된 적 없는 주요 축을 1-2개만 짚는다 (예: "motion은 DESIGN.md 기본값 그대로 — 아직 취향을 들은 적이 없어요"). 절대 전 축을 나열하지 말 것 — 가볍게 한두 줄.
다음 행동 안내 (뷰 끝에 항상)
다음 중 하나로 이어갈 수 있어요: - "지금 반영" → omd:learn — pending을 DESIGN.md에 fold - "잊어줘 <id|scope>" → 해당 엔트리 status를 rejected로 플립 - "수정: <내용>" → omd:remember로 재기록 (옛 엔트리는 superseded)
- "지금 반영" →
omd:learn트리거 (전체 또는 사용자가 지정한 scope만) - "잊어줘" → 해당 엔트리의 omd-meta 블록만 Edit 툴로
status: rejected+rejected_reason: "user-forget"플립 (omd:learn의 single-entry 플립과 동일 절차). body는 건드리지 않는다 - "수정" → body 직접 편집 금지 (영구 기록) —
omd:remember로 새 엔트리 재기록 후 옛 엔트리를status: superseded+superseded_by: <새 id>로 플립
금지
- "잊어줘"/"수정" 후속 요청의 status 플립 외에는 어떤 파일도 수정하지 말 것 — DESIGN.md 수정은 항상 omd:learn 경유
- 엔트리 전체 dump 금지 — scope 그룹 요약으로
- ④번 그룹을 채우려고 억지 축을 만들지 말 것 — 짚을 게 없으면 생략
- preferences.md 포맷 해석은 canonical 규칙(omd:remember)만 따를 것 — 자체 변형 포맷 발명 금지
