# registered_schedule_id_present — PROVENANCE

## scenario
task-2635+1 §6 신규 fixture (1/5). build-then-register-then-update 순서 적용 직후의 envelope 박제: registrar 가 schedule_id 를 회수했고 envelope 의 5축이 정확히 갱신된 상태. collector 가 아직 durable-success marker 를 못 쓴 시점이므로 receipt=UNCONFIRMED.

이 fixture 가 핵심적으로 차단하는 모순:
- (task-2634 사고) `registration_status=NOT_REGISTERED` + `cron_schedule_id=None` 인데 실제 8A9EB65E 등록 → envelope 미갱신.
- 본 fixture 는 그 반대로 등록 즉시 envelope 의 5축이 통째로 갱신되는 정상 상태를 박제.

## input (evidence.json) 핵심
### 5축 (task-2635+1)
- `registration_intent` = `true`
- `registration_attempted` = `true`
- `registration_result_status` = `REGISTERED`
- `callback_delivery_status` = `DELIVERED`
- `collector_receipt_status` = `UNCONFIRMED`
### 보조 필드
- `cron_schedule_id` = `FIXTURE-CRON-REG-PRESENT-0001` 명시 (REGISTERED 동반 필수)
- `registered_at_ts` 명시 (axis-3 REGISTERED 동반 필수)
- legacy `registration_status` = `REGISTERED` (alias agreement)
- collector durable-success marker **없음** (TTL 진행 중)

## expected (expected.json) 핵심
- `finalize_result` = `success` (axis-3 REGISTERED + 모순 없음)
- `fail_closed` = `false`
- `fallback_cancel_signal` = `false` (durable-success marker 부재 → 안전망 유지)
- `collector_spawn_expected` = `true`
- `is_callback_complete` = `true`
- `contradictions_expected` = `[]` (정합)

## spec 근거
- task-2635+1 §2 REGISTERED 는 실제 schedule_id 생성 후에만 기록
- task-2635+1 §4 envelope 최종 5축 정확 반영 (build-then-register-then-update)
- §3.4 ANCHOR-4 fallback cancel = REGISTERED + schedule_id + durable-success marker (3 조건 모두)
- task-2635+1 §6 신규 fixture 정본 1번

## 비결정성 / 외부 의존
- 없음 (frozen fixture · live cokacdir 0 · subprocess 0)

## 변경 이력
- 2026-05-23 task-2635+1 최초 작성 (dev6 페룬)