계획: 08의 분할 진행과 다음 착수 주의를 문서에 고정한다

presence 분할이 끝났고 RPC 클라이언트와 서버 조각이 남았다는 사실, 그리고 다음 사람이
같은 함정에 빠지지 않도록 착수 주의를 적었다.

_pending이 여덟 곳에 얽혀 있고 그 경로의 검증 루프가 설치 패키지 레인이라 한 번 도는 데
10분이다. 시행착오 비용이 높으므로 presence처럼 순수 자료구조를 먼저 떼어 시계 주입으로
판정한 뒤 배선을 옮기는 순서를 권한다.

검증: npm test 3337 passed 0 failed

Author: eddmpython

mainPlan/08_kernelDecomposition/README.md

@@ -8,11 +8,19 @@
 중복을 `pausedCapture.js`로. 오류 계약(map 결과의 code, 미등록 코드 관측, 정적 게이트 둘).
 메시지 언어 통일과 가드.
 
-남은 것: `KernelElection`의 3파일 분할. 이 항목의 **정확성 목표는 위에서 이미 달성**됐다
+분할 1/3 완료: presence를 `src/session/kernel/kernelPresence.js`로 갈랐다. 시계를 주입하게
+만들어 정책을 실 함수로 판정했고, 그 판정이 곧바로 불일치를 잡았다(`expire`는 자기 자신을
+지우지 않는데 `liveIds`는 만료로 걸러내고 있었다).
+
+남은 것: RPC 클라이언트와 서버 조각의 분할. 이 항목의 **정확성 목표는 이미 달성**됐다
 (다음 회귀의 진원지로 지목된 것이 정책 이중화였고 그것이 게이트로 닫혔다). 남은 이득은
-가독성이고, 676줄을 세 파일로 가르는 작업은 28개 상태 필드가 `status()`에서 다시 합쳐지는
-구조라 한 번에 끝나지 않는다. 착수할 때는 membership(presence + heartbeat) 추출부터 한다:
-`_participants`가 13곳에서 쓰이지만 전부 note/expire/remove/entries로 환원된다.
+가독성이다.
+
+착수 시 주의: `_pending`이 여덟 곳에 얽혀 있다(리더 승격, 응답 수락, park/resend, 거부,
+요청 생성). 추출하려면 `_post`, `_leaderId`, `_epoch`, `_notify`, `_journalDir`을 주입해야
+하고, 그 경로의 검증 루프가 설치 패키지 레인이라 한 번 도는 데 10분이다. 즉 시행착오 비용이
+높은 리팩터이므로 한 번에 옳게 옮기거나, presence처럼 순수 자료구조(pending 표와 park 정책)만
+먼저 떼어 시계 주입으로 판정한 뒤 배선을 옮기는 순서를 권한다.
 
 최대 파일을 책임별로 가르고, 그 과정에서 이미 두 벌로 갈린 커밋 정책을 하나로 만든다. 오류 계약도 여기서
 기계 검사 대상으로 올린다.