schedule-safety-checklisted

# Schedule Safety Check tiguclaw trigger plugin (scheduler 의 `add_schedule`, file-watch 의 `add_watch` 등) MCP 도구는 cron tick / daemon.boot / fs 이벤트 시점에 LLM 런타임을 `bypassPermissions` 로 발화시킨다. 사용자가 옆에 없는 시점이라 위험 도구가 자동 실행될 수 있는 회색지대 — 등록 *시점* 에 비서 능동 평가 + 사용자 명시 승인이 가장 안전한 가드. 본 스킬은 `add_schedule` (scheduler) 와 `add_watch` (file-watch) 둘 다에 적용 — `add_*` 일반화 패턴. 새 trigger plugin (webhook/inbox 등) 이 추가되어도 동일 패턴. **`register_endpoint` (http-bridge 커스텀 엔드포인트) 도 동일 회색지대 — 외부 토큰 보유자가 무인으로 비서 턴을 트리거.** 단 엔드포인트는 **기본 `mode: restricted`(도구 0 = 읽기·요약만) → 그 자체로 Layer A safe**(위험 도구 물리적 불가). 평가 대상은 **`mode: full` 로 명시 등록할 때만** — 그땐 본문 prompt 를 아래 3-layer 로 self-check 하고 gray/danger 면 사용자 명시 확인. 추가로 **공개 노출 차원**: full 엔드포인트는 토큰만 있으면 외부에서 반복 호출 가능하므로, "외부 송신·파일 변경·삭제·재귀" 류 prompt 면 restricted 유지를 우선 권하고 full 은 danger 로 취급. 개발 저장소의 ADR `2026-05-16-scheduler-v1`(배포본에 없다) §11 V2 후속 + `_workspace/file_watch_architect_contract.md` §7 보강 실현. ## §1. 위험 카테고리 3 layer 자연어 trigger 등록 요청을 받으면 prompt 본문 + 등록 인자(cron 표현식·path·event 등) 을 본 분류로 self-check. **판단 우선순위: danger > gray > safe.** 한 가지 위험 신호라도 있으면 상위 layer 로 격상. **의심스러우면 gray** — over-confirm 비용이 under-confirm 사고보다 항상 싸다. 각 layer 안 `[schedule]` `[file-watch]` 표기는 해당 trigger 종류 한정 예시 (공통은 표기 없음). ### Layer A — safe (즉시 등록, 추가 승인 0) 일상 정보 정리·조회·요약·생성. 외부 영향·삭제·인증 모두 0. 예시: - "오늘 뉴스 정리" - "내 캘린더 다음주 일정 요약" - "주식 시장 마감 상황 정리" - "코딩 문제 1개 생성" - "재미있는 사실 1개 알려줘" - `[file-watch]` `./docs` 자체 폴더 감시 + 요약 prompt (외부 영향 0) - `[file-watch]` `./notes` 같