적재 완료 판정에 계약이 없다 — coverage·정리 잔여·프로세스 경계

[epruseal]

opencrab.pack.load 의 적재 함수들은 (ok, skip, err) 계열 튜플만 돌려주고, 호출자는 그것으로 "이번 적재가 온전했는가"를 판정할 수 없다.

왜 판정이 안 되는가

err 는 필요조건도 충분조건도 아니다.

• 필요조건이 아니다: docs.upsert_source 예외가 except Exception: pass 에 삼켜지면 err=0 이 된다. 저장이 실패했는데 온전한 적재로 보인다. (load.py 의 삼킴 자리는 아래 재현 명령으로 전수 확인)
• 충분조건이 아니다: id_map[node_id] 가 try 밖(load.py:417)이라 문법위반으로 저장되지 않은 노드도 endpoint 로 등록된다. 그 노드를 참조하는 엣지는 endpoint 검사(:564)를 통과하고 add_edge 에서 저장 실패해 err 를 올린다. 문법위반은 결정적이라 다음 실행에도 같은 결과다.

함께 없는 것

• 정리 잔여(pending cleanup): 타입 변경에서 구 graph 노드는 지워지는데 구 doc 행 삭제가 실패하면 그 사실이 어디에도 안 남는다. 다음 실행은 same 으로 끝나 재시도조차 안 한다.
• 프로세스 경계: 운영 파이프라인은 로더를 subprocess 로 돌리고 종료 코드만 본다. 결과 객체를 아무리 정교하게 만들어도 경계를 못 넘는다. (호출자 쪽은 opencrab-dump 리포에 별도 등록)
• readback: 삭제가 실제로 반영됐는지 확인하지 않는다.

설계 요건

1. 어떤 identity 도 stored_ok | deterministic_skip | retryable_fail | unknown 중 정확히 하나에 속하고, 합이 입력과 다르면 그 자체가 unknown 이어야 한다.
2. 완료를 ingest_complete / cleanup_allowed / cleanup_complete 로 가른다.
3. unknown 이 있으면 그 축의 정리를 허용하지 않는다.
4. 정리 잔여를 durable 하게 남기고 다음 실행이 same 이어도 먼저 처리한다. write-first · fingerprint 조건부 삭제 · idempotent retry 를 만족해야 한다.
5. 기계 판독 가능한 완료 리포트를 내서 subprocess 소비자가 종료 코드 외에 상태를 읽게 한다.

범위

이관(#93)이 만든 결함이 아니라 이관 전부터 있던 구조다. #93 PR 은 이관 충실성에 집중하므로 여기서 분리한다.

재현

PYTHONPATH=/Users/asdf/localcrab-migration python3 - <<'PY'
import ast, pathlib
src = pathlib.Path("opencrab/pack/load.py").read_text()
for n in ast.walk(ast.parse(src)):
    if isinstance(n, ast.ExceptHandler) and len(n.body)==1 and isinstance(n.body[0], ast.Pass):
        print("삼킴:", n.lineno)
PY

관련

#93 (이관), #160 (타입 변경 공존 창), #158 (영수증 미검사 호출자)

[epruseal]

무로그 삼킴 위치 목록 (2026-08-12, 수정 라운드 7 별건 이월)

적대 완료 검증과 설계 검수가 opencrab/pack/load.py 의 침묵 예외 처리를 전수 실측했다. 이관 라운드가 만든 자리(타입 변경 doc 삭제, 노드 삭제 폴백, 같은-space 가드)는 해당 PR 에서 log.warning 과 caplog 회귀 테스트로 닫았고, 이관 전부터 동일했던 아래 자리들은 이 이슈의 coverage 축으로 이월한다.

자리	내용
delete_pack 의 doc_nodes 삭제	except Exception: pass — 팩 전량 삭제 중 doc 행 삭제 실패가 침묵
청크 적재 4자리의 docs.upsert_source	except Exception: pass — 본문이 이 이슈 본문에서 이미 인용한 그 삼킴(문서 저장 실패가 err=0)
incremental_finalize 의 FTS 삭제	예외 삼킴 시 본체만 지워지고 doc_sources_fts 그림자 행 생존 — 검수 실측 stale_fts_survives= True. readback 테스트는 수정 라운드에서 추가됐으나 삼킴 자체는 남아 있다

위치 특정은 행번호가 아니라 재현 명령으로 한다(행번호는 썩는다):

cd /Users/asdf/localcrab
python3 - <<'PY'
import ast, pathlib
src = pathlib.Path("opencrab/pack/load.py").read_text()
for n in ast.walk(ast.parse(src)):
    if isinstance(n, ast.ExceptHandler) and n.body \
       and all(isinstance(x, ast.Pass) for x in n.body):
        print("silent pass:", n.lineno)
PY

이 자리들의 올바른 처리는 개별 log.warning 덧대기가 아니라 이 이슈가 다루는 축별 coverage(어떤 identity 가 어떤 sink 에 반영됐는가의 계정)다 — 개별 로그는 그 계정의 부산물로 나온다.

[epruseal]

설계 완료 — 적재 완료 판정 계약

설계를 마치고 적대 검수 6라운드(새 컨텍스트 in-process 검수자 1회, 별도 CLI 프로세스 5회)를 거쳐 마지막 라운드에서 신규 P1 0건으로 통과했다. 잔여 P2 1건은 구현 계약 고정 사항으로 실행 이슈가 가져간다.

먼저: 이슈 본문의 근거 일부가 낡았다

본문이 인용한 except Exception: pass 목록은 대부분 이미 닫혔다. 현재 main 에서 무로그 pass 는 delete_pack 의 doc 행 삭제 1자리뿐이다. 청크 적재의 docs.upsert_source 삼킴은 err 계상으로, FTS 삭제는 log.warning 으로 바뀌었다.

그래도 이슈의 결론은 성립한다. 근거만 바뀐다.

(1) 로그는 계정이 아니다. 예외 핸들러를 전수 분류하면 계정맹(counter 증가도 re-raise 도 없이 로그만 남기는) 핸들러가 다수이고 대부분이 incremental_finalize 와 delete_pack 에 몰려 있다. 즉 삭제·정리 경로의 예외는 거의 하나도 반환값에 도달하지 않는다.

python3 - <<'PY'
import ast, pathlib
src = pathlib.Path("opencrab/pack/load.py").read_text()
tree = ast.parse(src)
func_of = {}
def walk(n, fn):
    for ch in ast.iter_child_nodes(n):
        nf = ch.name if isinstance(ch, (ast.FunctionDef, ast.AsyncFunctionDef)) else fn
        func_of[ch] = nf; walk(ch, nf)
walk(tree, "<module>")
COUNTERS = {"err","skip","ok","node_del","chunk_del","edge_del","chunk_sql_del",
            "chunk_vec_del","fts_del","doc_orphan_del","vec_orphan_del",
            "c_new","c_txt","c_meta","n_new","n_chg"}
blind = total = silent = 0
for h in ast.walk(tree):
    if not isinstance(h, ast.ExceptHandler): continue
    total += 1
    if all(isinstance(x, ast.Pass) for x in h.body): silent += 1
    counts = any(isinstance(s, ast.AugAssign) and isinstance(s.target, ast.Name)
                 and s.target.id in COUNTERS for s in ast.walk(h))
    raises = any(isinstance(s, ast.Raise) for s in ast.walk(h))
    if not counts and not raises:
        blind += 1; print("blind:", func_of.get(h))
print(f"total={total} blind={blind} silent_pass={silent}")
PY

(2) err 가 필요조건이 아닌 진짜 이유는 fail-open 영수증 판독이다. load_nodes·load_nodes_incremental·load_edges 는 store_write_failures() 를 쓰는데, 그 docstring 이 스스로 "DIAGNOSTIC, not authoritative — fail-open for any status shape it doesn't recognize" 라고 못박고 있고, 같은 모듈이 fail-closed 대안(store_write_succeeded_for, #163)을 제공하는데 load.py 는 그것을 import 하지 않는다.

정확히 적자면 갈리는 영수증 형태는 현재 OntologyBuilder 로 도달 불가다(add_node/add_edge 가 graph 상태를 항상 ok / error: … / unavailable 셋 중 하나로 채운다). 오늘 새는 건수는 0이고, 결함은 "판독 구조가 fail-open 이라 새 상태 문자열이 추가되는 순간 조용히 샌다" 이다. 이건 가정이 아니라 이 저장소의 이력이다 — store_write_succeeded 의 docstring 이 #66 을 인용해 같은 형태의 과금 게이트가 실제로 그렇게 깨졌다고 기록한다.

같은 자리의 반대 방향 결함도 검수가 찾았다. store_write_failures 는 어느 스토어든 error: 면 실패로 세므로 doc 쓰기 실패가 오늘은 err 다. 그런데 REQUIRED_STORES["node"] 는 graph 뿐이라 fail-closed API 로 그냥 갈아끼우면 doc 실패 신호를 잃는다. REQUIRED_STORES 는 과금 정책이지 적재 완료 정책이 아니다(그 표의 주석이 cross-file 결정이라고 경고한다).

(3) 충분조건이 아니라는 본문의 예시는 현행에도 그대로다. id_map[node_id] 가 try 밖·add_node 앞이라 문법위반 skip 노드도 endpoint 로 등록되고, 그 노드를 가리키는 엣지가 검사를 통과해 add_edge 에서 실패하며 err 를 올린다. 결정적이라 다음 실행도 같다.

(4) 정리는 적재 결과를 보지 않는다. incremental_finalize 는 err 를 인자로 받지 않는다. 방어는 0-항목 핀과 30% 비율 핀뿐인데 둘 다 비율 휴리스틱이라 25% 잘림은 통과한다.

설계 요지

요건 1 — 4상 처분과 합 불변식. 순수 모듈 opencrab/pack/receipt.py 에 축별 원장을 둔다. identity 확정 즉시 observed, 그 뒤 stored_ok/deterministic_skip/retryable_fail/unknown 중 정확히 하나. seal() 이 처분 없는 관측과 관측 없는 처분을 unknown 으로 흡수하므로 합 불변식이 구성상 항상 참이다. 모든 입력 루프를 try/finally 로 감싸 seal 을 보장한다(현행은 파싱 예외가 루프 밖으로 전파돼 아무 계정도 안 남는다).

• 행 카운트와 identity 카운트를 구분한다 — 노드·엣지 축에는 dedup 이 없고 sharded appender 가 재분할을 안 하므로 중복 identity 는 정상 입력이다. 중복을 계정 버그로 취급하면 무해한 입력 하나가 여러 축의 정리를 영구 정지시킨다.
• 입력 잘림은 unknown 이 아니라 축 수준 boolean 이다. 대응하는 identity 가 없어 카운트에 더하면 합 불변식이 스스로 깨진다.
• stored_ok 는 "이번에 썼다"가 아니라 "지금 있다" 이다. 증분 same 경로는 add_node 없이 지나가므로, 이 정의가 없으면 안 바뀐 노드 전량이 unknown 이 되어 정리가 막힌다.

적재 전용 required store 정책. REQUIRED_STORES(과금) 대신 PACK_AXIS_STORES 를 따로 둔다. add_node 한 번이 node(graph)·doc(docs)·vector(vector) 세 축에 각각 처분을 남긴다 — doc/vector 실패가 err 한 칸에 뭉개지던 것을 축으로 가른다. builder.py 에는 receipt_verdict(stores, required) 3상 판정을 추가하되 집합을 인자로 받아 과금 표와 적재 표가 판정 함수는 공유하고 정책만 분리하게 한다.

요건 2·3 — 완료 술어를 층으로 나눈다.

axis_plausible(a)   ⇔ ¬(claimed(a)=∅ ∧ live(a)≠∅) ∨ a ∈ assert_empty
axis_verified(a)    ⇔ claimed(a) ⊆ observed(a)
axis_sound(a)       ⇔ input_exhausted(a) ∧ unknown(a)=0 ∧ axis_plausible(a)
ingest_complete(a)  ⇔ axis_sound(a) ∧ retryable_fail(a)=0 ∧ axis_verified(a)
cleanup_allowed(a)  ⇔ axis_sound(a) ∧ ∀d ∈ CLEANUP_REQUIRES_SOUND[a]: axis_sound(d)
cleanup_complete(a) ⇔ cleanup_allowed(a) ∧ 계획된 삭제 전량 확정 ∧ 잔여 0

축은 node·edge·chunk·doc·vector 다섯. cleanup_allowed 가 다른 축의 cleanup_allowed 가 아니라 axis_sound 를 요구하는 것이 핵심이다 — delete_node 가 incident 엣지를 cascade 삭제하므로 node 도 edge 를 요구해야 하는데, 재귀로 두면 node ↔ edge 순환이 생긴다.

retryable_fail 은 정리를 막지 않고 unknown·잘림만 막는다. 저장에 실패한 identity 도 보호 집합에는 들어가므로(의도된 설계, 회귀 테스트가 못박고 있다) 저장 실패는 삭제 후보를 한 건도 늘리지 않는다. 반면 못 본 identity 는 보호 집합에서 빠져 라이브 행을 삭제 후보로 승격시킨다. retryable_fail 에 게이트를 걸면 만성 실패 행 하나가 정리를 영구 정지시켜 이 이슈가 막으려는 잔여 누적을 게이트가 직접 만든다.

axis_plausible 은 현행 0-항목 안전핀을 술어로 흡수한 것이다 — 빈 edges.jsonl 은 루프가 정상 종료하니 그냥 두면 sound 로 읽히고, 노드 삭제 cascade 로 라이브 엣지가 사라진다. axis_verified 는 거짓 완료를 막는다 — 벡터가 외부에서 지워져도 same 경로는 확인하지 않으므로 ingest_complete 가 참이 되어 버린다. axis_verified 는 ingest_complete 에만 넣고 cleanup_allowed 에는 넣지 않는다(넣으면 증분 벡터 축이 상시 차단돼 liveness 가 깨진다).

게이트 적용 기준: 후보가 집합 뺄셈(live - claimed)에서 나오는 삭제만 게이트를 받는다. 후보가 방금 처리한 identity 하나에서 파생되는 삭제(구 타입 행, 이종 space doc 행)는 잘림이 후보를 늘릴 수 없으므로 안 받는다. 처분·잔여 기록은 양쪽 다 받는다.

요건 4 — durable 잔여. LOCAL_DATA_DIR 아래 전용 sqlite 사이드카에 둔다(네 스토어 중 하나에 두면 doc 스토어 장애로 생긴 잔여를 doc 스토어에 못 적는다).

• write-first: 삭제 시도 전에 기록한다. 삭제 도중 사망하는 창이 잔여가 가장 필요한 창인데 "실패 후 기록"은 정확히 그 창에서 아무것도 못 남긴다. 기록 자체가 실패하면 그 축의 삭제를 중단한다(fail-closed) — 삭제만 되고 잔여가 없으면 재시도 근거가 사라진다.
• 재시도는 세 조건을 모두 만족해야 한다: ① 지문 일치 ② claimed 비소속 ③ cleanup_allowed(axis). ③이 없으면 일반 후보 삭제는 게이트가 막는데 잔여 삭제가 그 옆으로 새 나간다(잘린 실행에서 살아 있는 행을 지운다).
• ②의 claimed 가 이 설계에서 가장 여러 번 틀린 지점이다. 보호 집합(bypack_*_ids)은 타입 없는 id 집합이라 granularity 가 안 맞고, 축 원장의 stored_ok 는 질문 자체가 틀리다(쓰기가 실패했거나 그 축이 관측을 안 한 identity 를 지운다). 올바른 질문은 "이번 입력이 그 행의 존재를 주장하는가" 다. claimed 는 쓰기 성공 여부·관측 여부와 무관하게 기록하고, 후임이 stored_ok 가 된 경우에만 전임을 해제한다 — 단순 last-wins 로 두면 교체가 실패했을 때 전임이 보호를 잃어 구·신 데이터가 모두 사라진다.
• 지문은 축마다 full-row 다. 청크를 text 만으로 잡으면 메타 전용 갱신(_vec_meta_update 에 sqlalchemy 분기가 없어 pgvector 는 메타 전용 갱신에서 항상 재임베딩으로 떨어진다 #172 의 경로)이 만든 fresh row 를 지우고, 벡터를 metadata 만으로 잡으면 새 본문을 지운다. 해시는 sha256 + canonical JSON + fingerprint_version 이다 — Python 내장 hash() 는 프로세스마다 값이 달라(실측 확인) 안 바뀐 행이 매번 오종결된다. 버전 불일치 잔여는 폐기하고 이번 실행의 후보 계산이 재도출하게 둔다(자가 치유).
• 엣지 잔여는 5-tuple 로 좁힌다. 스토어의 실제 upsert conflict key 가 (from_type, from_id, relation, to_type, to_id) 인데 현행 경로는 전부 3-tuple 이라 같은 3-tuple 을 공유하는 다른 typed 엣지까지 지운다.
• readback 은 축마다 필요도가 다르다. 벡터 축은 필수(반환이 요청 수라 효과의 증거가 없다 — chroma 벡터 삭제가 요청 수를 삭제 수로 세고, 요약이 백엔드를 sqlite-vec 로 고정 표기한다 #165 의 자리). doc·graph 축은 실제 장애가 예외로 오므로 예외 없는 반환이 부재를 함의해 선택이다. cascade 효과는 어느 반환값에도 없어 재조회로만 안다.
• 동시성: 새 잠금을 만들지 않고 이미 있는 opencrab/locking.py 의 write_lock(fix: serialize REST and CLI writes with write.lock #138)을 새 진입점이 실행 전체에 건다.
• same 이어도 처리: 스윕을 건너뛰는 단축 경로를 두지 않고, 잔여가 남으면 cleanup_complete 가 거짓이라 전부 same 인 실행도 미완료로 보고된다.

요건 5 — 기계 판독 리포트. 인-프로세스 객체 + --report-json 파일 + 종료 코드 셋. 운영 오케스트레이터가 stdout 을 캡처하지 않고 흘리므로 파일이 주 운반체다. 신선도 계약을 건다 — 시작 시 completed:false 로 먼저 쓰고 finally 에서 덮어쓰되, completed 는 정상 종료 여부이고 예외 종료는 completed:false + outcome:"aborted" 다. 종료 코드 공간은 여기서 정의하고 #189 가 채택한다. identity 목록은 리포트에 안 싣고(팩 규모가 10^5~10^6) 잔여 테이블에 둔다.

운영자 플래그 셋은 각각 하나의 정확한 주장만 담는다 — --force-delete(기존, 30% 핀 전용), --assert-empty=<axis>(그 축이 비어 있는 게 맞다), --allow-cleanup-despite=<axis>(저 축이 unsound 여도 진행). 전역 플래그 하나로 뭉치면 노드 비율 핀 때문에 쓴 플래그가 "엣지가 비어 있는 게 맞다"까지 자동 주장해 cascade 구멍이 다시 열린다. 어느 것도 자기 축의 unknown·input_exhausted 나 잔여 조건은 우회하지 못한다.

호환

기존 함수 9개의 시그니처·반환 타입을 유지하고 선택적 ledger= 키워드만 늘린다. ledger is None 이면 판정기까지 현행 그대로여서 행동 변화가 0이다. 레거시 (ok, skip, err) 를 원장에서 파생시키지 않는 이유는 레거시 err 가 적재 실패와 정리 실패를 섞고 있고(구 타입 행 삭제 실패가 같은 err 를 올린다) 레거시는 행 단위인데 원장은 identity 단위이기 때문이다. 파생시켜 assert 하면 무해한 중복 입력에서 죽는다. 대신 대사값을 리포트에 싣는다.

행동이 바뀌는 것은 전부 기본 꺼짐 플래그 뒤에 둔다 — sys.exit 핀 제거(저수준 함수는 기본 유지, 새 진입점만 비활성), 잔여 재시도, 종료 코드 전환.

경계

• chroma 벡터 삭제가 요청 수를 삭제 수로 세고, 요약이 백엔드를 sqlite-vec 로 고정 표기한다 #165: 벡터 축 readback 을 필수로 정의해 chroma 의 과대계상이 cleanup_complete 를 막는 보고값이 되게 한다. 벡터 백엔드 코드는 안 건드린다.
• 타입 변경 공존 창에서 중단되면 구 타입 행이 live_pack_state 에서 덮여 회수 불가 #160: 잔여 identity 를 (node_type, node_id) 로 정의해 live_pack_state 의 collapse 가 표현 못 하는 구 타입 행을 회수 가능하게 한다 — 타입 변경 공존 창에서 중단되면 구 타입 행이 live_pack_state 에서 덮여 회수 불가 #160 의 선택지 3을 기반으로 제공한다. live_pack_state 의 키는 안 바꾼다.
• space 이동형 타입 변경에서 거짓 WARNING — stale_typed 와 F4-c 헬퍼의 doc 삭제 경로 중복 #173: already_absent 를 성공 처분으로 정의하고 두 삭제 경로가 같은 축 원장에 기록하게 해 거짓 경고를 구조적으로 없앤다. space 이동형 타입 변경에서 거짓 WARNING — stale_typed 와 F4-c 헬퍼의 doc 삭제 경로 중복 #173 이 제안한 "제외 인자 하나" 형태를 대체한다 — 인자 전달은 경로가 셋·넷으로 늘면 조합이 깨진다.
• load.py 돌연변이 스윕 생존자 정리 — 삭제·완료 경로에 양성 테스트가 없다 (#95 형제) #166: 삭제 인자·보호 집합·완료 술어를 바꾸는 돌연변이가 보고되는 필드를 바꾸게 되어, load.py 돌연변이 스윕 생존자 정리 — 삭제·완료 경로에 양성 테스트가 없다 (#95 형제) #166 이 "판정할 계약이 없어 테스트를 못 쓴다"고 적은 자리에 oracle 이 생긴다.
• 회수/대사 술어 폭이 load.py 안에서 3종으로 갈린다 — source_id-only 행이 증분에서 안 걷힌다 #164: 잔여 행에 predicate(reclaim/reconcile)를 보존해 차집합이 보고 가능한 값이 되게 한다. 술어 폭은 통일하지 않는다(의도된 분리).
• CLI extract 가 per-item 추출 실패에도 exit 0 을 반환 #189/Obsidian vault 임포터가 개별 노트 예외로 전체 임포트를 중단 #190: 종료 코드 공간과 처분 어휘만 제공한다.
• add_node/add_edge 영수증을 안 보고 성공을 세는 호출자 3파일 (#66 후속) #158/store_write_succeeded 에 작업별 required store 개념이 없다 (#66/#158 후속) #163: 영수증 체계를 재발명하지 않는다. store_write_succeeded 위에 얹고 적재 정책만 분리한다. REQUIRED_STORES 도 store_write_failures 도 안 바꾼다.

중요한 단서 — 이 저장소 안에는 생산 소비자가 없다

opencrab/ 과 apps/ 어디에서도 opencrab.pack.load 를 import 하지 않는다(opencrab/pack/__init__.py 가 의도적으로 재노출하지 않는다). 호출자는 전부 테스트이고, 실제 운영 호출자는 별도 저장소에 같은 이름·같은 시그니처의 복제본을 들고 있다. 그쪽은 ok/skip/err 를 출력만 하고 종료 코드에 싣지 않으며, subprocess 로 부르는 오케스트레이터는 종료 코드만 본다.

따라서 이 계약이 이 저장소에만 착지하면 라이브 효과는 0이다. 운영 저장소를 import 로 되돌리는 것이 선행 조건이고 이 저장소 밖 이슈다. 지연되면 opencrab/cli.py 에 pack load 명령을 신설해 저장소 안에 최초 소비자를 만드는 것이 대안이다.

실행 이슈 분해안

각 1 PR 분량, 기본 행동 변화 전부 없음(플래그 뒤).

키	내용	의존
A1	builder.py 에 receipt_verdict(stores, required) 3상 판정 + 진리표·등가성 고정 테스트	—
A2	opencrab/pack/receipt.py 신설 — 처분·원장·claimed·두 층 술어·PACK_AXIS_STORES·CLEANUP_REQUIRES_SOUND·canonical identity 인코딩	—
A3	적재 5함수 전부에 ledger= 배선, try/finally seal 경계, 원장 기반 endpoint 전파(id_map 불변), same → stored_ok	A1, A2
A4a	백엔드 삭제 계약 확정 — 축별 readback 가능성 실측, cascade 확인 방법, write_lock 직렬화 정책	—
A4b	잔여 저장소 — 스키마, write-first API, 세 조건 재시도, 5축 full-row 지문	A2, A4a
A5a	incremental_finalize 에 삭제 처분 + 잔여 배선, 적재 후·계획 전 스윕, strict_pins 키워드	A3, A4b
A5b	delete_pack 과 적재 루프 안 삭제 3자리에 처분 + 잔여 배선	A5a
A6a	load_pack() 진입점(락 획득 포함), LoadReport, --report-json + 신선도 계약	A5b
A6b	종료 코드 공간, 운영자 플래그 셋	A6a

순서: A1 → A2 → (A3 ∥ A4a → A4b) → A5a → A5b → A6a → A6b. A3 와 A4 계열은 병렬 가능하다.

별건 등록 필요 2건: ① 운영 저장소의 복제본을 import 로 전환(그 저장소 이슈, 락 획득 포함) ② 엣지 축의 3-tuple collapse — 스토어 실제 키는 5-tuple 인데 live_pack_state·stale 삭제가 3-tuple 이라 같은 3-tuple 을 공유하는 다른 typed 엣지까지 지운다. #160 이 노드 축에서 보고한 collapse 결함의 엣지 축 형제다.

반증된 방향

검수가 반증해 설계에서 뒤집은 것들이다. 같은 실수를 반복하지 않기 위해 남긴다.

• "stored_ok 인 노드만 id_map 에 등록" — applied.add 가 endpoint 미스 continue 뒤에 있어서, id_map 을 좁히면 실패 노드를 가리키는 엣지가 applied_edges 에서 빠지고 이전 증분의 라이브 엣지가 stale 로 삭제된다. 회귀 테스트가 이미 반대 불변식을 못박고 있다. id_map 은 space 해석표이지 쓰기 영수증이 아니다.
• "처분을 기록한 뒤 applied 에 넣는다" — 같은 결과다. applied.add 가 항상 먼저여야 하고 네 처분 경로 전부가 그 순서를 공유해야 한다.
• "같은 identity 에 처분이 두 번이면 unknown" — 중복 identity 는 정상 입력이라 무해한 입력이 정리를 영구 정지시킨다.
• "잘림을 unknown 카운트에 넣는다" — 합 불변식이 스스로 깨져, 잘림을 보고해야 할 상황에서 assert 가 터진다.
• "잔여 재시도는 지문만 보면 된다" / "스윕을 실행 맨 앞에 둔다" — 부활 삭제가 난다.
• "cleanup_allowed 가 다른 축의 cleanup_allowed 를 요구한다" — cascade 때문에 node ↔ edge 순환이 생긴다.
• "증분 same 노드는 쓰기가 없으니 처분도 없다" — 안 바뀐 노드 전량이 unknown 이 되어 정리가 막힌다.
• "sys.exit 핀을 바로 리포트 사유로 바꾼다" — 기존 테스트가 그 함수를 직접 부르며 SystemExit 를 기대한다.
• "잔여 보호는 축 원장의 stored_ok 로 판정" — 쓰기가 실패했거나 그 축이 관측을 안 한 identity 를 지운다.
• "axis_plausible 의 탈출구는 전역 플래그" — 노드 비율 핀 때문에 쓴 플래그가 엣지 축의 빈 입력까지 정당화해 cascade 구멍을 다시 연다.
• "claimed 는 단순 last-wins" — 교체가 실패했을 때 전임이 보호를 잃어 구·신 데이터가 모두 사라진다.