# task-3036 — update-system-spec.py 정기 실행 (2026-08-27 12:15 슬롯)

- 담당: dev8 / 라(Ra)
- 유형: 스케줄 운영 (cron `8C2B2814`, `15 */6 * * *`)
- 결과: **정상 (실질 무결)** — 스크립트 exit code 1, 원인은 기지(旣知)의 `cron` 섹션 수집 실패 1건뿐
- 연속 회차: task-3015·3020·3022·3027·3030·3031·3032 에 이은 **8회 연속 동일 패턴**

## 1. 실행 결과

```
  [FAIL] cron: ANU_CHAT 환경변수가 설정되지 않았습니다.
  [OK] skills / services / projects / scripts / task_stats
[update-system-spec] 변경 감지: ['cron', 'task_stats']
[update-system-spec] 업데이트 완료 / 변경 로그 기록 완료
```

exit code = **1** (`return 0 if not errors else 1`, scripts/update-system-spec.py 말미).
errors 는 `cron` 1건. 데이터 손실 없음 → Critical 7 아님.

## 2. 검증 (실행 전 스냅샷 ↔ 실행 후 직접 재측정)

### 2-1. 전문 diff — 10줄 단일 hunk, `task_stats` 뿐

```
1168,1171c1168,1171
< | 총 작업 수 | 2274 |      > | 총 작업 수 | 2279 |
< | 완료된 작업 | 2211 |     > | 완료된 작업 | 2214 |
< | 완료율 | 97.2% |         > | 완료율 | 97.1% |
< | 평균 소요시간 | 1시간 10분 29초 |  > | ... 1시간 10분 24초 |
```

전문 대조는 매회 필수(생략 금지). 이번 회차엔 `services` 델타 없음.

### 2-2. `AUTO:cron` 블록 보존 — before ↔ after md5 동일

| 시점 | 마커 포함 구간 md5 |
|---|---|
| 실행 전 (`/tmp/spec_before_3036.md`) | `af7090faa1da20f713b9f6e31ae7eb8c` |
| 실행 후 (`anu-system-spec.md`) | `af7090faa1da20f713b9f6e31ae7eb8c` |

`created_at` 첫 항목 = `2026-04-16 11:16:10` — **8회 연속 동결 유지**.
즉 changelog 의 `- [cron] cron 데이터 변경` 은 이번에도 **거짓 양성**이며 문서는 무손상.

### 2-3. `services` — spec 18 = 실측 18, 집합까지 완전 일치

`systemctl --user list-units --state=running --type=service --no-legend` 실측 18개와
spec 블록 18개를 정렬 후 `diff` → **0줄 (IDENTICAL)**.

`at-spi-dbus-bus` · `dbus` · `gpg-agent` 는 3030(재등장)→3031→3032→3036 으로
**4회 연속 present**. 그럼에도 판정 유지 — **승격하지 않는다.**
무변화 누적은 "세션이 안 끊겼을 뿐"이라는 대안 설명을 배제하지 못한다.
승격 조건은 회차 수가 아니라 *세션 재시작을 관통한 생존*.
지속 신호는 여전히 `insuro-preview.service` 하나뿐.

### 2-4. `task_stats` 증가분 +5 의 정체 (자기참조 포함)

06:15 이후 신규 start 5건 = `task-3033`, `task-3025`(재시작), `task-3034`,
`task-3035`, **`task-3036`(본 태스크 자신)**. 완료 +3 = 3032·3033·3035.
완료율 97.2%→97.1% 하락은 분모 +5 / 분자 +3 의 산술 결과이며 **품질 퇴행 신호 아님.**
이 수치를 외부 활동량 지표로 읽지 말 것.

## 3. 미해소 항목 (변동 없음)

`cron` 섹션 수집 실패는 8회 연속 재발 중. 근본 해소 두 갈래:
1. 크론 실행환경에 **ANU 소유** `ANU_CHAT`/`ANU_KEY` 주입
2. `detect_changes()` 가 수집 실패 섹션(`new is None`)을 변경으로 계산하지 않도록 수정

★ **dev8 등 팀 봇 키로 대체 수집 금지** — `--cron-list` 는 key 소유자 스코프라
부분집합으로 덮어써져 문서가 퇴행한다. 현재의 "실패 → 기존 블록 보존"이 더 안전.
현 상태는 로그만 오염되고 문서는 안전하므로 **회장님 조치 불필요**.

## 4. 백업 스케줄러(`EE825F5E`) — 12:00 슬롯 정상, 단 **"1회성 확정"은 철회**

`schedule_history/EE825F5E.log` 실측(chat_id 6937032012 한정):

- `2026-08-26T18:02:18` ok (134.5s)
- `2026-08-27T00:02:01` ok (115.6s)
- `2026-08-27T06:01:47` ok (102.3s)
- `2026-08-27T12:04:55` ok (290.9s)

산출물 실재: `memory/backups/system-spec/2026-08-27_12` 생성 확인.

### ★ 직전 회차(3032) 자기보고 2건을 이번 실측으로 정정한다

**정정 ①** — 3032 보고서의 "08-26 12:00 결번은 1회성 미발화 확정"은 **틀렸다.**
ANU 검토가 지적한 대로이며, 이번 회차에서 독립 재측정해 확인했다.
보존창 내 결번은 **1건이 아니라 3건**이고 원인이 **두 갈래**다:

| 결번 슬롯 | 로그 레코드 | 원인 유형 |
|---|---|---|
| `2026-08-21_18` | `error` 존재 | 실행됐으나 실패 (모드A) |
| `2026-08-22_00` | `error` 존재 | 실행됐으나 실패 (모드A) |
| `2026-08-26_12` | **레코드 부재** | 미발화 (모드B) |

모드B 는 로그에 아무 흔적이 없어 `grep` 으로 잡히지 않는다.
**기대 슬롯 대조(6시간 격자 ↔ 백업 디렉터리 실재)만이 유일한 탐지법**이다.
백업 디렉터리 29개, 로그 443 레코드 기준으로 확인.

**정정 ②** — 3032 의 "초 오프셋 `00:49`·`06:38` 드리프트 중" 도 실측과 불일치.
실제 오프셋은 `+02:18` → `+02:01` → `+01:47` → `+04:55` 로 **단조 드리프트가 아니라
실행시간(102~291초)에 따른 지터**다. 드리프트 가설은 이번 회차 실측으로 기각.

## 5. 잠복 결함 (미해소, 이번 회차 코드 변경 없음)

ANU 가 3032 검토에서 발견한 `collect_services()` **returncode 미검사**는 그대로다.
세션 버스 실패 시 `services` 블록이 21줄→2줄로 소실될 수 있다(재현 완료, 실발생 0회).
본 태스크는 스케줄 실행 건이라 코드 변경 범위 밖 — **위임 대상으로 남긴다.**