일부러 파일을 바꿔 본 날 — AI workflow의 복구 회로를 실제로 검증한 기록

한 줄 요약

AI workflow가 정말 작동하는지 확인하려고 synthetic manifest.json을 일부러 바꿨습니다. 그 결과 Proof와 Gate는 stale을 감지했고, finding은 rn-ingestion을 수리 owner로 지정했습니다. 전체를 다시 만들지 않고 ingestion만 고친 뒤, 같은 strict 기준으로 다시 통과했습니다.

안전한 실험장을 먼저 만들다

이번 검증은 실제 연구자료나 기존 run을 대상으로 하지 않았습니다. OS 임시 디렉터리에 새 strict run을 만들고, synthetic manifest 하나만 넣었습니다.

사용한 것은 Research Navigator의 공식 CLI였습니다.

• rn_state.py

• rn_validate.py

• rn_proof.py

• rn_snapshot.py

• rn_findings.py

legacy run nrf-20260802-171626은 건드리지 않았습니다. 외부 검색·연락·예약·결제·제출·rollback도 실행하지 않았습니다.

정상일 때의 기준을 먼저 기록하다

먼저 strict 1.1 manifest에 material_scope approval을 기록했습니다. 그 다음 Proof를 만들고 검증한 뒤 ingestion을 advance해 Snapshot을 남겼습니다.

synthetic manifest
→ scoped material_scope approval
→ proof create / verify
→ ingestion advance
→ snapshot

여기까지만 보면 단순히 정상 흐름이 한 번 지나간 것입니다. 핵심은 그 다음이었습니다.

failure가 실제로 나타나는지 확인하다

Proof와 Snapshot이 만들어진 뒤 manifest를 의도적으로 바꿨습니다. 그러자 각 장치가 서로 다른 방식으로 같은 사실을 알려 줬습니다.

실패가 있다는 사실보다 더 중요했던 것은, failure가 막연한 오류로 남지 않았다는 점입니다. 무엇이 바뀌었고, 어디에서 다시 시작해야 하는지가 남았습니다.

정상인 부분을 버리지 않고 수리하다

finding이 정한 대로 ingestion만 invalidate했습니다. 다른 stage나 legacy 연구 산출물을 다시 쓰지 않았습니다.

그 다음 synthetic manifest를 정상 상태로 고치고, 같은 순서로 새 approval·새 Proof·새 Snapshot을 만들었습니다. 기준을 낮추거나 예외를 추가하지 않았습니다.

재검증 결과는 다음과 같습니다.

• strict validator: ok: true, errors/warnings 없음

• dashboard Proof: pass

• dashboard Gate: pass

• dashboard Snapshot: pass

• dashboard serialized projection: approval fingerprint와 approval note 미노출

수치와 영수증

strict harness: 1/1 passed
related dashboard API: 7/7 passed
full regression: 638/638 passed

실제 synthetic execution의 흐름과 제한은 아래 영수증에 남겼습니다.

• docs/superpowers/receipts/2026-08-11-rn-strict-harness-execution.md

최소 회로는 ingestion까지 검증했기 때문에 다음 profile stage는 BLOCKED — expected로 남았습니다. 필요한 입력과 승인 없이 다음 단계까지 통과시킨 것이 아니라, 증거가 있는 범위에서만 멈춘 것입니다.

이 날 얻은 운영 원칙

1. failure는 숨길 대상이 아니라 검증 대상이다. stale이 실제로 감지돼야 proof와 gate가 의미가 있다.

2. repair는 가장 작은 owner에서 시작한다. 정상인 부분을 다시 만들어야 한다면 책임 경계가 아직 너무 크다는 신호다.

3. 재평가는 같은 기준으로 한다. 수리 뒤 예외를 늘려 통과시키면 수리가 아니라 기준 변경이다.

4. 정직한 중단도 결과다. 증거와 승인이 없는 stage는 BLOCKED나 needs_confirmation으로 남겨야 한다.