---
task_id: task-3031
scope: task
team: dev8
owner: 라(Ra)
type: cron-execution
status: success_with_known_benign_exit1
created_at: "2026-08-27 00:15 KST"
---

# task-3031 — update-system-spec.py 정기 실행 (6회차)

## S (상황)

`python3 /home/jay/workspace/scripts/update-system-spec.py` 6시간 주기 정기 실행.
직전 5회(task-3015 / 3020 / 3022 / 3027 / 3030)에서 "exit code 1 +
`[cron] 데이터 변경`"이 `ANU_CHAT` 미설정 수집 실패에 기인한 **거짓 양성**임이
이미 규명되어 있다. 문서 갱신 루프는 `if section not in new_state: continue` 로
해당 섹션을 건너뛰므로 `AUTO:cron` 블록은 보존된다.

## C (복잡성)

직전 회차(task-3030)가 남긴 두 개의 미결 관찰이 이번 회차의 판정 대상이었다.

1. **services 플래핑 가설의 재검.** 3027 이 "실제 인프라 변경(17→15)"으로 확증한
   델타를 3030 이 절반 뒤집었다(15→18, 세 유닛 전부 재등장). 3030 은 이를
   *세션 스코프 플래핑*으로 분류하고 "지속되는 유닛은 `insuro-preview.service`
   하나뿐"이라고 판정했다. 이번 회차는 그 분류가 맞는지 확인할 차례였다.
2. **spec 백업 결번**(별개 스케줄러 `backup-spec.sh`)이 08-26 12:00 한 번
   빠진 뒤 18:00 정상 발화했다. 러너 생존이 이어지는지 확인 대상이었다.

## Q (질문)

이번 exit 1 도 거짓 양성인가, 아니면 진짜 회귀가 섞였는가.
services 는 또 흔들렸는가.

## A (답변 / 실행 결과)

### 실행

- 실행 시각 `2026-08-27 00:15`, **exit code 1**
- 수집: `skills` `services` `projects` `scripts` `task_stats` → **[OK] 5/5**
- 수집 실패: `cron` → `[FAIL] ANU_CHAT 환경변수가 설정되지 않았습니다.`
- 변경 감지: `['cron', 'task_stats']`

### 검증 (실행 전 `cp` 스냅샷 → 실행 → 전문 `diff` 대조)

**전문 diff = 3줄, 전부 `task_stats`.** 다른 섹션 변동 0.

```
1168,1169c1168,1169
< | 총 작업 수 | 2272 |          > | 총 작업 수 | 2273 |
< | 완료된 작업 | 2209 |         > | 완료된 작업 | 2210 |
1171c1171
< | 평균 소요시간 | 1시간 10분 32초 |  > | 평균 소요시간 | 1시간 10분 30초 |
```

**`AUTO:cron` 블록 보존 확인** — 마커 포함 구간 md5
before `af7090faa1da20f713b9f6e31ae7eb8c` = after `af7090faa1da20f713b9f6e31ae7eb8c`
(3027·3030 과 동일 구간 정의). 블록 `created_at` 은 **`2026-04-16 11:16:10`**
으로 6회 연속 동결. → 로그만 찍히고 문서는 그대로, 기존 판정 그대로 재현.

### services — 3030 의 플래핑 분류가 유지됐다

이번 회차 변경 감지 목록에 **`services` 가 없다**(old == new). 실측 교차검증:

- spec `AUTO:services` 블록 엔트리 **18**
- `systemctl --user list-units --state=running --type=service` 실측 **18**
- 일치.

3030 이 재등장을 확인한 `at-spi-dbus-bus`·`dbus`·`gpg-agent` 가 이번엔 **그대로
머물렀다**. 즉 6시간 만에 다시 사라지지 않았고, 3030 의 "세션 유무로 뜨고 지는
user 유닛" 분류와 모순되지 않는다(세션이 계속 살아 있으면 계속 보인다).
`insuro-preview.service` 도 유지 — 3030 이 "지속되는 신호"로 지목한 판정이
한 회차 더 버텼다.

**다만 이것을 "안정화 확증"으로 승격하지 않는다.** 무변화 1회는 플래핑 가설을
반증하지 못한다(세션이 안 끊겼을 뿐일 수 있다). 판정 유지: *신호는 지속되는
유닛뿐이고, 왕복하는 세 유닛은 여전히 플래핑 후보.*

### spec 백업 스케줄러 — 러너 생존 재확인

`memory/backups/system-spec/` 버킷 mtime:

```
2026-08-27 00:00:49  2026-08-27_00   ← 이번 주기 정상 발화
2026-08-26 18:00:25  2026-08-26_18
2026-08-26 06:00:17  2026-08-26_06
(2026-08-26_12 결번 — 1회성 미발화로 확정)
```

08-26 12:00 이후 **18:00 · 00:00 연속 2회 정상**. 영구 고장 아님이 재확증됐다.

## 판정

| 항목 | 결과 |
|---|---|
| 스크립트 실행 | 성공 (문서 갱신 완료) |
| exit code 1 | **알려진 거짓 양성** — `cron` 섹션 단일 원인, 데이터 손실 0 |
| 문서 갱신 | `task_stats` 3줄만 반영 |
| `AUTO:cron` 보존 | before=after md5 일치, 회귀 없음 |
| services 무결성 | spec 18 = 실측 18 |
| changelog 기록 | `anu-system-spec-changelog.md` 최상단 `[2026-08-27 00:15]` 기록됨 |
| Critical 7 해당 | **아니오** — 제이회장님 알림 불요 |

## 미결 / 이월

1. **`cron` 섹션 6회 연속 미갱신.** 스펙의 cron 블록은 `2026-04-16` 기준 동결
   상태가 계속된다. 근본 해소는 두 갈래이며 **둘 다 ANU 권한 영역**이다.
   - (1) 크론 실행 환경에 ANU 소유 `ANU_CHAT`/`ANU_KEY` 주입
   - (2) `detect_changes()` 가 *수집 실패* 섹션을 변경으로 계산하지 않도록 수정
   → dev8 은 착수하지 않는다. **팀 봇 키로 대체 수집은 금지**(`--cron-list` 는
   key 소유자 스코프라 부분집합으로 덮어써져 문서가 퇴행함).
2. 다음 회차(06:15)에도 동일 검증법 적용: 스냅샷 → 전문 diff → `AUTO:cron` md5
   before↔after. **"어차피 task_stats 뿐"이라 가정하고 diff 를 건너뛰지 말 것**
   (task-3027 에서 실제 services 변경이 섞여 나온 선례).

## 산출물

- `memory/specs/anu-system-spec.md` (갱신)
- `memory/specs/anu-system-spec-changelog.md` (`[2026-08-27 00:15]` 항목 추가)
- `memory/reports/task-3031.md` (본 문서)
- `memory/events/task-3031.json`