플래너

마지막 수정 2026-08-21

일지가 지나간 일이라면 플래너는 지금의 계획입니다. 다른 점이 하나 있습니다 — 사람이 관리하는 할 일 목록이 아니라, 에이전트가 일을 마칠 때마다 스스로 갱신하는 문서입니다.

파일은 .oculpm/planner/*.md, 역시 평범한 마크다운입니다.

계획 한 편의 모양

---
oculpm_plan: v1
id: session-attribution
title: "세션 귀속 정리"
status: active
owner: claude-code
---

## Phase 기반 다지기 {#foundation}
- [x] 타임스탬프 귀속 함수 {#resolve-by-time}
- [~] MCP 도구가 라이브 세션을 채택 {#mcp-adopt}
  - [x] sessions.json 동기 읽기 {#sync-read}
  - [ ] 폴백 경로 테스트 {#fallback-test}
- [ ] 링크 파생 {#derive-links}
  • Phase 는 ## 헤딩으로 묶는 단계입니다. 글리프가 없습니다 — 진척은 하위 항목에서 자동 계산됩니다
  • 항목은 한 줄, 끝에 {#안정적인-id} 가 붙습니다
  • 중첩은 한 단계까지. 하위가 있는 부모의 글리프는 하위에서 굴러 올라오므로 직접 건드리지 않습니다

글리프 여섯 개

글리프뜻
[ ]할 일
[~]진행중
[x]완료
[!]막힘
[>]이월
[-]폐기

지금 상태의 정답은 본문 글리프입니다. 아래의 변경 로그는 이력이고요.

변경 로그 — 누가 언제 왜 바꿨나

계획 문서 맨 아래에는 표가 하나 붙습니다. 에이전트는 항목을 옮길 때마다 여기에 한 줄을 덧붙이기만 합니다 (기존 행은 절대 고치지 않습니다):

| 시각 | #항목id | 에이전트 | 이전→새 글리프 | 일지 경로 | 짧은 메모 |

일지 경로가 함께 적히므로 계획의 한 줄에서 그 일을 설명하는 일지로 바로 건너갈 수 있습니다. 계획에 일지 내용을 복사해 넣지 않는 것이 규칙입니다 — 참조만 합니다.

팁

"이 항목이 왜 폐기됐지?" 가 궁금할 때, 로그의 그 줄에 달린 일지를 열면 당시 판단이 그대로 남아 있습니다.

결정 잠그기

되돌리기 어려운 선택은 ## 결정 섹션에 블록으로 못 박습니다:

### Decision 3 — SQLite 캐시를 파생으로 유지 {#dec-cache-derived}
잠금: 2026-08-21 · claude-code
근거: 디스크 마크다운이 SSOT. 캐시를 정본으로 삼으면 …
영향: #resolve-by-time, #derive-links

나중에 "왜 이렇게 했더라" 를 다시 논쟁하지 않기 위한 장치입니다.

상태와 잠금

계획 문서 자체도 상태를 가집니다.

status뜻에이전트가 고칠 수 있나
active진행 중예
done끝남아니오
archived보관아니오

done 이나 archived 인 계획은 에이전트가 수정하지 않습니다. 끝난 계획이 슬금슬금 되살아나 이력이 흐려지는 것을 막기 위해서고, 이어서 할 일이 생기면 새 계획을 만듭니다. 사이드바에서는 「완료·잠금」으로 표시됩니다.

플래너 화면에서 할 수 있는 것

  • 정렬 — 최근순 · 진척순 · 남은 일 순 · 이름순
  • 묶기 — 상태별 · 최근활동별 · 작성자별
  • 멈춘 계획 표시 — 12일째 멈춤 처럼, 손 놓은 계획이 눈에 띕니다
  • 검색 — 계획 이름으로 좁히기

새 계획은 누가 만드나

보통은 에이전트에게 시키는 게 편합니다 — "이 작업들 계획으로 정리해줘" 라고 하면 규격에 맞는 파일을 만듭니다. 직접 만들어도 됩니다. 위의 머리말 + Phase 헤딩 + 항목 줄 + 빈 로그 블록 순서면 앱이 읽습니다.

주의

항목 줄을 쓸 때 {#id} 는 반드시 줄 끝에 두고 줄바꿈하지 마세요. 둘째 줄로 넘어간 {#id} 는 파서가 읽지 못합니다.

다음 걸음