# [철회됨] 복수 `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`가 "그게 이미 끝났다"를 전제로** 동작할 수 있음:

```lua
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`
양쪽에 기재).