---
task_id: "task-2694+1"
type: enforcement
scope: callback-registration
status: completed
---

# Context Notes — task-2694+1

## 배경 (회장 verbatim 2026-05-27)
- task-2694는 dev8 라에 dispatch됐으나 BOT_DID_NOT_START + DISPATCH_FALSE_OK 회피
- 옵션 A로 dev7 이참나에게 재발의
- chair_authorization_id: CHAIR-AUTH-NORMAL-CALLBACK-REGISTRATION-ENFORCEMENT-20260527-JJONGS-REDISPATCH-001
- task-2694 namespace 그대로 사용 (allowed_resources path가 task-2694.* 로 정의됨)

## Codex 사전 검증 결과 (2026-05-27 03:54)
- pass: false, critical=1, high=2, medium=2
- 결과 파일: memory/events/task-2694+1.codex-gate
- Codex 지적은 "현재 코드가 설계 목표에 미달"이라는 갭 지적. 본 작업이 그 갭을 메움.

## 3 Step Why 자문

### 1st Why — 왜 이 설계가 필요한가?
**A**: task-2693에서 envelope 작성만으로 finish-task.sh가 .done 생성 시도했고, 실제 cokacdir cron registration은 0건이었음. 회장 verbatim "envelope 작성은 callback 증거가 아니다. actual cron 등록 + schedule_history + owner key + ANU inbound 또는 authoritative collector receipt 가 있어야 PASS." 코드 enforce 없으면 동일 사고 재발.

### 2nd Why — 왜 4-source validation이 최선의 접근인가?
**B**: 단일 source 의존 시 우회 패턴 발생.
- schedule_id 단독 → self-key channel 사용 시 false positive
- schedule_history 단독 → stale log 재사용
- owner_key 단독 → 다른 task의 receipt 재사용
- envelope 텍스트 단독 → task-2693 정확히 이 케이스로 우회

4-source AND 결합 + envelope sha256/task_id/chair_facing_sid 결속 → 모든 우회 패턴 차단.

### 3rd Why — 왜 4-source가 다른 대안보다 나은가?
**C**: 대안 비교
- 대안 1 (schedule_id만): envelope에 schedule_id 누락 가능 + sid 재사용 위험 → 단점
- 대안 2 (envelope 텍스트만): task-2693 정확히 envelope 텍스트로 통과 → 단점
- 대안 3 (4-source AND + envelope sha256/task_id/chair_facing_sid 결속): 모든 alone-evidence 차단 + sid 재사용/stale/self-key 차단 → 최선

회장 verbatim에서 직접 명시한 4 source 그대로 enforce가 최선. Codex suggestion 1 반영하여 sid 재사용/stale 방어 위해 task_id + schedule_id + owner_key + chair_facing_session_id + envelope sha256 결속 강화.

**A-B-C 일관성**: OK. 설계 진행.

## Codex 5 risks 처리
- (critical-1) finish-task.sh에 4-source 검증 부재 → Step 2.9.5 새 게이트 삽입으로 해결
- (high-2) 신규 파일 부재 → 본 작업으로 신규 생성 (task에서 신규로 명시됨)
- (high-3) sid 재사용/stale 위험 → validator가 task_id + envelope sha256 결속 검증
- (medium-4) marker 일관성 → escalation_marker.py와 동일한 emit() 패턴 사용 + .done.escalated 호환
- (medium-5) regression oracle 부족 → 6 fail + 1 pass 케이스 분리

## 주요 결정
1. **단일 Python validator 집중**: validator.py 한 곳에서 4-source 판정 + marker 발행
2. **finish-task.sh는 orchestrator만**: validator 호출 + exit code 반영 (shell grep 의존 최소화)
3. **차단 어구**: schedule_type ∈ {to_be_registered_by_finish_task_sh, deferred, pending} 시 즉시 fail
4. **결속 검증**: envelope의 task_id와 file 위치 task_id 일치 + envelope sha256 검증
5. **dogfood**: 본 작업 완료 시 본인 normal callback이 본 enforcement 통과해야 함

## Sanitize 게이트 적용
- Codex 호출 전 PII 마스킹 2건 감지 (codex_gate_check.py 로그 확인)
- ANU key `c119085addb0f8b7`는 task 파일에 verbatim 명시 (마스킹 대상 아님 — 회장 verbatim doctrine 항)