# COKACDIR_MESSAGE_DIRECT_SPAWN_FEASIBILITY_PACKET (read-only — --message real invocation 0)

작성: 2026-06-09 KST / ANU 직접 read-only(help + 선별 strings) / --message 미실행
상태: `COKACDIR_MESSAGE_DIRECT_SPAWN_FEASIBILITY_PENDING_ACTIVE_FALSE`
질문: --message 가 activity-independent direct spawn 인가 + hygiene/isolated 적합한가.

## ★ 핵심 정정 (이전 packet 의 "--message=scheduler 우회 동기 spawn" 가설 하향)
- help: **`--message <TEXT> --to <BOT> --chat <ID> --key <HASH>`** = **"Send message to another bot (internal use)"** → **bot-to-bot 내부 메시지**(--to 필수). 범용 "prompt 실행" 명령 아님.
- strings: `handle_message`/`handle_text_message` → message file 작성 → `scheduler_loop` 처리. = **--cron 과 동일한 message-driven scheduler_loop 경로를 탐**. **scheduler_loop 우회 아님** — 오히려 message file 을 "공급".

## 15 항목

### 1. --message 플래그 사용법
- `cokacdir --message "<TEXT>" --to <BOT> --chat <ID> --key <HASH>`. internal use(봇 간). `--output-last-message`(마지막 메시지 회수) 병용 가능 추정.

### 2. --message 가 --cron/scheduler_loop 을 우회하는지 근거
- **우회 안 함(추정 HIGH)**. handle_message 가 message file 작성 → scheduler_loop 이 그 file 처리(process_bot_message). --cron 의 schedule 평가와 같은 loop. → --message 도 scheduler_loop 종속.
- 단 차이: --message 는 **message file 을 즉시 생성** = scheduler_loop cycle 을 유발하는 "활동" 자체. → **wake 가 자기 트리거 활동을 생성**하는 셈(외부 Telegram inbound 비의존). 이 점이 activity-independent 가능성(미검증).

### 3. --message 가 동기 실행인지 여부
- **미확정**. message file 작성이 scheduler_loop cycle 을 즉시/동기 유발하는지, 아니면 다음 cycle 대기인지 strings 만으론 불명. 동기 여부 = canary 검증 대상.

### 4. --message 가 새 세션 spawn 인지 기존 세션 주입인지
- strings: "directly in the chat's current session ... just send your next message"(inline=기존 세션 주입) AND "isolated path"(새 격리 세션) 둘 다 존재. **--to 봇의 세션 상태/설정에 따름**. wake 는 isolated 필요(8).
- → 모드 결정 가능 여부 = 추가 확인(8).

### 5. --output-last-message 의미
- 세션의 **마지막 AI 메시지를 출력**(회수). wake 시 spawned 세션의 CANARY_ACK 회수에 사용 가능(추정).

### 6. prompt 와 key 가 어느 로그에 남는지
- --message TEXT = `~/.cokacdir/messages` 의 message file 에 작성(handle_message). → **prompt 본문이 message file 에 평문 저장**. owner_key 제거(PR#196)면 prompt 에 key 0 → message file 에 key 0.
- `--key` = auth flag(transient argv). schedule_history 미경유(--message 는 schedule 아님). 단 message file/기타 로그에 --key 적재 여부 = 미확정(구현 전 추가 확인).

### 7. raw key / owner_key / key-derived identifier 노출 위험
- prompt body: owner_key 제거 적용 시 0. message file: prompt 평문이라 prompt 가 깨끗하면 0. --key flag: transient. → **prompt sanitize(owner_key 0) 전제면 노출 위험 낮음**, 단 --message 전용 로그 적재 미확정(확인 필요).

### 8. isolated workspace 지정 가능 여부
- strings 에 "isolated path" + "workspace/<schedule_id>" 존재(--cron 의 isolated workspace). --message 가 isolated 모드를 명시 지정 가능한지(예 플래그) = **미확정**. inline(기존 세션 주입)이 default 면 wake 에 부적합 → isolated 강제 방법 확인 필요.

### 9. spawned 세션 권한/행동 제한 가능 여부
- spawned 세션 = Claude Code 세션 → prompt scope + PreToolUse hook 으로 제한 가능(현 canary 와 동일). 단 --message inline 모드면 기존 세션 컨텍스트 혼입 위험 → isolated 필수.

### 10. PreToolUse hook 적용 가능 여부
- 가능(세션 settings). 단 --message 가 어느 세션/settings 로 spawn 하는지(--to 봇 설정)에 hook 결선이 달림. isolated + 전용 settings 확보 시 hook 적용.

### 11. owner-proof anchor S 와 결합 가능한지
- 가능. --message 발사 전 `resolve_authoritative_owner(S)=OWNER_ANU` 검증 게이트. anchor S(cron, 미발사)로 owner-proof 유지 → --message 는 발사 수단. 결합 설계 유효.

### 12. self-collector doctrine 과 충돌하지 않는지
- --message 는 **bot-to-bot**(--to) → 독립 ANU 봇 간. self-key 자가발사 아님. anchor S + owner-pin(ANU-key fail-closed) 적용 시 self-collector 아님(조건부). 단 --to 라우팅이 ANU 봇이어야 하고 owner-pin 강제 필요.

### 13. dry-run 또는 no-op 검증 가능 여부
- --message 는 action(실 메시지) → 순수 dry-run 제한적. **launcher 측 dry_run**(argv 구성·owner-proof·scope 경로만, 실 --message subprocess 미실행)은 가능. --message 자체의 no-op 모드는 미발견.

### 14. real canary 실행 전 필요한 patch 여부
- **필요**: launcher 에 --message 경로 추가(현재 --cron 만) + isolated 모드 지정 + --to 라우팅 + owner-proof 게이트 + scope/hook settings. → canary 전 구현 patch 선행(회장 승인 시). 즉 "patch 없이 바로 --message canary" 불가.

### 15. 구현 난이도와 리스크
- 난이도 **중-고**: (a) --message 의미가 bot-to-bot internal 이라 wake-spawn 용도 적합성 불확실 (b) scheduler_loop 우회 아님(message file 공급) → activity-independence 미확정 (c) isolated/라우팅/hook 결선 (d) --message 로그 hygiene 미확정.
- 리스크: --message 가 결국 scheduler_loop 경유면 **activity-independent fire 미달성 가능**(B 와 유사 결과 위험). → **B 의 교훈: cokacdir scheduler 의존 경로는 activity-independent 보장 안 됨**. --message 도 scheduler_loop 공유라 동일 위험 잔존.

## 종합 판정 (정직)
- **--message 는 scheduler_loop 우회 동기 spawn 이 아니다(이전 가설 하향)**. bot-to-bot 메시지 → message file → scheduler_loop 처리. 단 message file 생성이 cycle 을 자기-유발할 가능성(activity-independent 후보)은 남으나 **미검증**.
- → --message 만으로 activity-independent fire 가 보장되지 않을 수 있음. **systemd path(detection 독립) + --message(cycle 자기-유발 시도) 결합**이 더 유망하나, 둘 다 scheduler_loop 의존이라 근본 한계 잔존 가능.
- ★ 더 근본적 후보 재고 필요: scheduler_loop 완전 비의존(예 driver 가 cokacdir 거치지 않고 Claude Code 세션 직접 launch — 단 owner-proof/거버넌스 재설계 = 옵션 D 고리스크).

## 미해결 (구현/canary 전 추가 read-only/통제확인)
- (a) message file 생성이 scheduler_loop cycle 을 동기 유발하는가.
- (b) --message isolated 모드 강제 가능한가.
- (c) --message prompt/key 의 로그 적재 hygiene.
- (d) --message 가 결국 scheduler_loop 경유면 B 와 동일 coupling 한계 — activity-independent 미달 위험.

## capability matrix
- direct_spawn_mechanism = COKACDIR_MESSAGE_BOT_TO_BOT_SCHEDULER_LOOP_COUPLED (이전 "scheduler 우회" 하향).
- wake_fire_activity_independence = NOT_YET_VERIFIED (--message 도 미확정·coupling 위험).
- ACTIVE=false / production_activation_gate = HARD BLOCK.

## 금지 (현재)
production activation / ACTIVE=true / systemd 설치 / daemon restart / 추가 canary / production queue / direct spawn 구현 / PR / **--message real invocation**. **feasibility 분석까지만.**

## 판정
- **COKACDIR_MESSAGE_DIRECT_SPAWN_FEASIBILITY_PACKET_READY**. 핵심(정직): --message = bot-to-bot internal·scheduler_loop 경유(우회 아님). activity-independent 미확정·coupling 위험 잔존. systemd path 결합 또는 더 근본적 비-cokacdir launch 재고 필요. 다음 = 회장 방향 결정.