quad/.claude/archive/preref-order-unguaranteed-withdrawn.md

[철회됨] 복수 PreRef/PostRef 간 fire 순서를 "미보장"으로 두려던 안

제안·철회 모두 2026-08-14 아홉 번째 세션(원 결정: 2026-08-07 아홉 번째 세션). 현재 유효한 계약은 "배열 index 순서 그대로 보장" — 즉 2026-08-07 결정이 그대로 살아 있음, 정본은 base/ref-plan.md의 "phase 옵션 폐기 → 위치로 표현, PreRef 신설" 절(복수 PreRef 간 순서 항목)과 "PostRef" 절. 이 파일은 한 세션 안에서 뒤집었다 되돌린 왕복의 기록이고, 남겨두는 이유는 양쪽 논거가 나중에 비슷한 판단(“보장할까 말까”)에서 다시 쓸 만해서임.

원래 계약 (2026-08-07 아홉 번째 세션, 지금도 유효)

복수 PreRef 간 순서 — 새 규칙 불필요, 배열 index 순서 그대로. 이 pre-pass는 "배열 파트는 index 순서대로" 계약을 그대로 재사용해 리터럴 순서대로 fire하면 됨.

미보장으로 바꾸자던 안 (제안 → 같은 세션에 철회)

사용자 원 메모:

각 PreRef 간의 순서는 보장 안함. PostRef간 순서는 보장 안함(실제로 하더라도, 안 한다고 두는게 버그를 차라리 덜 만든다고 생각함. 같은 계열 내 Ref 등록 순서에 의존하는 무언가가 생겨선 안된다는 생각, 그건 구조부터 잘못된거니까)

논지: (1) 순서에 의존하는 훅 코드는 애초에 설계가 잘못된 것이니 보장을 제공하면 그 구조를 권장하게 됨, (2) 보장을 안 하면 나중에 pre-pass 구현을 바꿀 자유가 남음, (3) 그 순서에 기대는 사용자 코드가 안 생겨 버그가 덜 남.

구현은 어차피 안 바뀌고 계약만 좁히는 변경이었음(pre-pass는 미보장 상태에서도 index 순서로 훑음).

왜 철회했나

결정적 반례 — FastQuery(...) -> PreRef류 조합(사용자 제시). 어떤 팩토리가 PreRef를 반환하면서 뭔가를 미리 해결해두면, 배열에서 그 뒤에 오는 OnCreated가 "그게 이미 끝났다"를 전제로 동작할 수 있음:

Frame {
    FastQuery(...),          -- PreRef를 반환하는 팩토리
    OnCreated(function(inst) -- 위가 끝난 뒤에 불림
        ...
    end),
}

이건 "잘못된 구조"가 아니라, 이 배열이 원래 제공하는 정당한 합성 방식임 — children의 마운트 선후가 배열 위치로 정해지는 것(base/ref-plan.md "phase 옵션 폐기 → 위치로 표현, PreRef 신설" 절이 phase 옵션을 없앨 수 있었던 바로 그 이유)과 정확히 같은 성격이고, 서로 다른 저자가 쓴 항목(팩토리 제공자 vs 호출자)이 한 배열에 섞이는 유일한 자리이기도 함.

곁들여 확인된 것들:

1. 보장 비용이 0 — pre-pass가 어차피 index 순서로 훑고, PostRef의 postRefList도 그 스윕이 만든 목록이라 push 순서가 곧 배열 순서.
2. 미래 구현 자유를 내주는 것도 없음 — base/dispatch-core-plan.md가 이미 "배열 파트는 index 순서대로"를 백엔드 이식성 때문에 명시적 계약으로 못박아 뒀으므로, 어떤 백엔드든 index 순서를 제공해야 함. PreRef 순서 보장은 새 약속이 아니라 그 계약의 자동 귀결.
3. 미보장인데 결정론적이면 실효가 없음 — 런타임이 항상 index 순서로 주는 이상 위반이 테스트에서 절대 안 걸림. (Go의 map 순회 무작위화처럼 디버그 모드에서 일부러 역순으로 돌려 노출시키는 방법은 있으나, 이 사소한 규범 하나를 위해 장치를 더 만들 가치는 없다고 판단.)
4. 계약 표면에 예외가 하나 느는 비용 — "배열 파트는 순서 보장, 단 그 안의 PreRef끼리는 아님"을 읽는 사람이 따로 기억해야 함.

남은 것

보장은 유지하되 스타일 권고만 문서에 남김 — 순서로 조율해야 할 만큼 얽힌 훅이면 대개 하나의 훅 안에서 순서대로 부르는 게 낫고, 위 FastQuery처럼 "앞의 것이 뒤의 것의 전제를 만들어주는" 명시적 합성이 아니면 순서에 기대지 말 것(base/ref-plan.md/base/lifecycle-hooks-plan.md 양쪽에 기재).