# [역전됨] 복수 `PreRef` 간 fire 순서 = "배열 index 순서 그대로 보장" → 미보장

**역전 일자**: 2026-08-14 아홉 번째 세션 (원 결정: 2026-08-07 아홉 번째
세션). **현재 유효한 계약은 `base/ref-plan.md`의 "`phase` 옵션 폐기 →
위치로 표현, `PreRef` 신설" 절**(복수 `PreRef` 간 순서 항목)과 같은
문서의 "`PostRef`" 절 — 이 파일은 히스토리 보존용이라 여기 적힌 걸
근거로 코드를 짜지 말 것.

## 원문 (2026-08-07 아홉 번째 세션 확정, `bind-system-plan.md` → `ref-plan.md`)

> - **복수 `PreRef` 간 순서(2026-08-07 아홉 번째 세션, 사용자 확인) —
>   새 규칙 불필요, 배열 index 순서 그대로.** 같은 인스턴스에 `PreRef`가
>   여럿 있으면, 이 pre-pass는 위 "props 순회 순서" 절이 이미 확정해둔
>   "배열 파트는 index 순서대로" 계약을 그대로 재사용해 리터럴 순서대로
>   fire하면 됨 — 서로 다른 우선순위/순서 개념을 별도로 만들 필요 없음
>   (호이스팅은 "PreRef 전체 대 나머지"에만 적용되는 규칙이지, "PreRef끼리"
>   에는 적용될 게 없음 — PreRef끼리는 그냥 평범한 배열 순회).

## 무엇이 뒤집혔나

**구현이 아니라 계약이 뒤집힘.** pre-pass가 배열을 index 순서로 훑는다는
구현은 그대로이고, 실제 fire 순서도 사실상 리터럴 순서일 것임 — 바뀐 건
그걸 **사용자에게 보장하느냐**임.

| | 역전 전 | 현재 |
|---|---|---|
| `PreRef`끼리의 상대 순서 | **보장**(배열 index 순서) | **보장 안 함** |
| `PostRef`끼리의 상대 순서 | (당시 `PostRef` 없음) | **보장 안 함** |
| 호이스팅("`PreRef` 전체가 나머지보다 먼저") | 보장 | 보장(**변경 없음**) |
| `PostRef`("두 패스가 전부 끝난 뒤") | (없음) | 보장 |

## 역전 이유 (사용자)

> "PreRef는 프로퍼티/자식 들어오기 전에 설정됨. 각 PreRef 간의 순서는
> 보장 안함. PostRef는 프로퍼티/자식 들어온 후 설정됨, PostRef간 순서는
> 보장 안함(실제로 하더라도, 안 한다고 두는게 버그를 차라리 덜 만든다고
> 생각함. 같은 계열 내 Ref 등록 순서에 의존하는 무언가가 생겨선 안된다는
> 생각, 그건 구조부터 잘못된거니까)"

정리하면 셋:

1. **순서에 의존하는 코드는 애초에 설계가 잘못된 것** — 두 훅의 상대
   순서가 중요할 정도면 훅을 둘로 나눌 게 아니라 하나 안에서 순서대로
   부르면 됨. 보장을 제공하면 그 잘못된 구조를 오히려 권장하게 됨.
2. **보장하지 않으면 구현을 바꿀 자유가 남음** — pre-pass의 순회 방식을
   나중에 바꿔도(예: 최적화, 백엔드별 자료구조 차이) 계약 위반이 아님.
   `base/dispatch-core-plan.md`가 "다른 백엔드가 props를 Lua 테이블이
   아닌 자료구조로 표현할 수 있다"는 이유로 두 패스 순서를 **명시적
   계약**으로 고정했던 것과 같은 결의 판단 — 거기선 보장이 필요해서
   고정했고, 여기선 필요 없어서 안 고정함.
3. **버그가 덜 생김** — 보장이 없으면 그 순서에 기대는 사용자 코드가
   애초에 안 생김.

## 영향 범위

- `base/ref-plan.md` — 해당 bullet 교체(역전 표시 + 이유), 새 "`PostRef`"
  절도 같은 규칙으로 서술.
- `base/lifecycle-hooks-plan.md` — "다중 등록 가능" 절에 "같은 계열끼리
  순서 미보장" 경고 추가, ② 절의 "복수 `PostRef` 간 순서는 복수 `PreRef`와
  같은 원칙(배열 index 순서 그대로)" 문장 정정.
- `ROADMAP.md` M8 — "복수 `PreRef`는 배열 index 순서 그대로(별도 규칙
  없음)" 체크리스트 문구 정정.
- 코드 영향 없음(구현이 안 바뀌므로) — 바뀐 건 문서화 대상 계약뿐.