<!-- task=m-provider-availability-capacity-queue-foundation/04+03_fifo_admission_queue plan=1 tag=REVIEW_REFACTOR -->

# Code Review Reference - REVIEW_REFACTOR

> **[IMPLEMENTING AGENT — READ FIRST] Filling in this file is the mandatory final step of implementation.**
> The task is NOT complete until every implementation-owned section below is filled in.
> Complete the `구현 체크리스트`; the final checklist item is mandatory before saving.
> Fill implementation-owned sections, then stop with active files in place and report ready for review.
> If implementation is blocked by a user-only decision, user-owned external environment prerequisite, or scope conflict, fill `사용자 리뷰 요청` with evidence and stop with active files in place; code-review decides whether to write `USER_REVIEW.md`. Evidence gaps that a follow-up agent can close by rerunning commands or collecting artifacts are normal follow-up issues, not user-review blockers by themselves.
> Do not ask the user directly, present choices in chat, or call `request_user_input` during implementation; record the needed decision in `사용자 리뷰 요청` and stop for code-review.
> Finalization (`코드리뷰 결과`, log rename, `complete.log`, archive moves, `코드리뷰 전용 체크리스트`) is review-agent-only, even after compaction/resume.
> Follow the ownership table at the bottom of this file for which sections you own.

## 개요

date=2026-06-14
task=m-provider-availability-capacity-queue-foundation/04+03_fifo_admission_queue, plan=1, tag=REVIEW_REFACTOR

## Roadmap Targets

- Milestone: `agent-roadmap/phase/inference-provider-extension/milestones/provider-availability-capacity-queue-foundation.md`
- Task ids:
  - `admission-gate`: Node provider executor가 `in_flight < capacity`일 때만 provider 호출을 시작하고, capacity가 찬 요청은 provider별 FIFO queue에 넣는다.
  - `queue-release`: 실행 중 요청이 응답, 실패, 취소, timeout으로 종료되면 `in_flight`를 줄이고 queue의 첫 요청을 실행 슬롯으로 승격한다.
  - `queue-reject`: `max_queue` 초과 또는 `queue_timeout` 초과 요청은 명확한 error/rejection reason으로 종료한다.
- Completion mode: check-on-pass

## 이 파일을 읽는 리뷰 에이전트에게

> **[REVIEW AGENT ONLY]** 아래 종결 절차는 코드리뷰 에이전트 전용이다. 구현 에이전트는 이 섹션을 실행하지 않는다.

각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
리뷰 완료는 아래 순서까지 끝난 상태를 의미합니다.

1. 판정을 append한다.
2. `CODE_REVIEW-cloud-G06.md` -> `code_review_cloud_G06_N.log`, `PLAN-cloud-G06.md` -> `plan_cloud_G06_M.log`로 아카이브한다.
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/m-provider-availability-capacity-queue-foundation/04+03_fifo_admission_queue/`로 이동한다. WARN/FAIL이면 user-review gate를 확인한 뒤 다음 active plan/review 파일 또는 `USER_REVIEW.md`를 작성한다.
4. PASS이고 task group이 `m-provider-availability-capacity-queue-foundation`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.

---

## 구현 항목별 완료 여부

| 항목 | 완료 여부 |
|------|---------|
| [REVIEW_REFACTOR-1] Gate Composition Fix | [x] |
| [REVIEW_REFACTOR-2] Verification Evidence Recovery | [x] |

## 구현 체크리스트

- [x] 교차 adapter global head-of-line blocking을 재현하는 failing regression test를 추가한다. (`TestAdmissionQueue_GlobalNoCrossAdapterHeadOfLine`: global=2, adapter A/B cap=1. A1/B1 실행 중 A2→B2 enqueue 후 B1만 release하면 B2가 즉시 시작, A2는 a1 release 전까지 queued 유지. 수정 전 `enqueue`에서는 A2가 freed global slot을 선점해 이 테스트가 실패한다.)
- [x] adapter gate가 실제 grant된 뒤에만 global gate를 reserve/wait하도록 admission ticket 흐름을 수정한다. (`enqueue()`는 adapter gate만 reserve. `wait()`에서 adapter grant 후 global을 reserve/wait.)
- [x] global wait 경로에서도 provider queue timeout 또는 admission timeout 정책이 일관되게 적용되는지 테스트로 고정한다. (`wait()`가 adapter `queueTimeout`로 단일 deadline context를 파생해 adapter+global wait 전체에 적용. `mapDeadline`이 deadline 기인 취소를 `queue_timeout` reason으로 재분류. `TestAdmissionQueue_QueueTimeoutAppliesAcrossGates`로 global-wait 단계 timeout 고정.)
- [x] 기존 FIFO ordering, max_queue overflow, queue_timeout, success/failure/cancel release tests가 계속 통과하게 한다. (전부 PASS.)
- [x] 필수 repo 내부 edge-node 진단 또는 full-cycle 검증 증거를 `agent-ops/skills/project/e2e-smoke/SKILL.md` 기준으로 기록한다. (아래 `repo 내부 edge-node 진단 / full-cycle 증거` 참조.)
- [x] 최종 검증 명령을 실행한다.
- [x] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.

## 코드리뷰 전용 체크리스트

> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.

- [x] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
- [x] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
- [x] active `CODE_REVIEW-*-G??.md`를 `code_review_cloud_G06_N.log`로 아카이브한다.
- [x] active `PLAN-*-G??.md`를 `plan_cloud_G06_M.log`로 아카이브한다.
- [x] `.gitignore`의 Agent-Ops 관리 block이 `agent-task/**/*.md`와 `agent-task/**/*.log`를 unignore하고 `agent-roadmap/current.md`를 ignore하는지 확인한다.
- [ ] PASS이면 `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준으로 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
- [ ] PASS이면 active task 디렉터리 `agent-task/m-provider-availability-capacity-queue-foundation/04+03_fifo_admission_queue/`를 `agent-task/archive/YYYY/MM/m-provider-availability-capacity-queue-foundation/04+03_fifo_admission_queue/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
- [ ] PASS이고 task group이 `m-provider-availability-capacity-queue-foundation`이면 런타임이 읽을 완료 이벤트 메타데이터를 보고하고, roadmap 수정이나 `update-roadmap` 직접 호출을 하지 않는다.
- [ ] PASS split 작업이면 이동 후 빈 active parent `agent-task/m-provider-availability-capacity-queue-foundation/`를 제거하거나, 남은 sibling/file이 있어 유지했다고 확인한다.
- [x] WARN/FAIL이고 user-review gate가 트리거되지 않았으면 다음 active `PLAN-cloud-G06.md`와 `CODE_REVIEW-cloud-G06.md`를 작성하고 `complete.log`를 작성하지 않는다.
- [ ] USER_REVIEW이면 `agent-ops/skills/common/code-review/templates/user-review-template.md` 기준으로 `USER_REVIEW.md`를 작성하고 active `PLAN-*.md`, `CODE_REVIEW-*.md`, `complete.log`를 남기지 않는다.
- [ ] USER_REVIEW가 사용자 결정으로 완료/PASS 해소되면 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log`를 작성한 뒤 task directory를 archive로 이동한다.

## 계획 대비 변경 사항

- **`fifoGate.waitOn`에서 내부 timer 제거 → ctx deadline 일원화.** 계획은 global wait 경로 timeout 적용만 요구했으나, gate별 개별 timer를 두면 adapter wait와 global wait에 timeout이 두 번 적용되어 총 대기가 최대 2×queueTimeout이 될 수 있었다. 이를 막기 위해 `waitOn`의 `applyTimeout` 파라미터와 내부 `time.Timer`를 제거하고, `admissionTicket.wait()`가 adapter `queueTimeout`로 단일 `context.WithTimeout`을 파생해 adapter+global 두 단계 전체에 하나의 deadline만 적용하도록 했다. deadline 기인 취소는 `mapDeadline`이 `queue_timeout` reason으로 재분류한다.
- 그 외에는 계획의 작업 항목(enqueue=adapter-only, wait=adapter→global, 실패 시 adapter slot release, 교차 adapter 회귀 테스트, global-wait timeout 테스트)을 그대로 따랐다.

## 주요 설계 결정

- **gate 합성 순서 = enqueue(adapter only) → wait(adapter grant 후 global reserve+wait).** 1차 구현의 결함(enqueue 시점에 adapter 대기 ticket이 global slot까지 선점 → 교차 adapter head-of-line blocking)을 근본 제거했다. global slot은 자기 adapter slot을 이미 보유한 run만 점유하므로, 한 provider의 큐 대기가 다른 provider의 실행 가능한 큐 head를 막지 못한다.
- **단일 deadline로 admission 대기 bound.** adapter `queueTimeout`만을 권위값으로 사용(global gate는 무제한/무timeout). adapter 또는 global wait 어디서 막혀도 동일 정책으로 종료되고 무기한 대기가 없다.
- **`max_queue` 우회 방지.** overflow 판정은 `enqueue()`의 adapter `reserve()` 단계에서만 일어나고, global gate는 무제한 큐라 max_queue를 우회하지 않는다.
- **release/leak/cancel 안전성 유지.** `wait()`는 실패 시 보유한 adapter slot을 `ticket.release()`로 항상 unwind. run의 `defer ticket.release()`가 success/failure/cancel/timeout 모든 종료 경로에서 슬롯 반납. cancel-while-queued는 run `execCtx`로 wait를 취소해 큐에서 제거. race detector clean(`go test -race`).

## 사용자 리뷰 요청

_기본값은 `없음`이다. 구현 중 사용자 결정, 사용자 소유 외부 환경/secret/서비스 준비, 또는 계획 범위 변경 없이는 안전하게 진행할 수 없으면 아래 항목을 실제 내용으로 교체하고, 구현을 중단한 뒤 active 파일을 그대로 둔 채 리뷰를 요청한다. 구현 에이전트는 사용자에게 직접 질문하거나 선택지를 제시하거나 `request_user_input`을 호출하지 않는다. 후속 에이전트가 명령 재실행이나 산출물 수집으로 해소할 수 있는 검증 증거 공백만으로는 사용자 리뷰 요청을 작성하지 않는다._

- 상태: 없음
- 사유 유형: 없음
- 결정 필요: 없음
- 차단 근거: 없음
- 실행한 검증/명령: 없음
- 자동 후속 불가 이유: 없음
- 재개 조건: 없음

## 리뷰어를 위한 체크포인트

- global gate가 adapter gate grant 전에 선점되지 않는지 확인한다.
- 교차 adapter 회귀 테스트가 실패 조건을 실제로 고정하는지 확인한다.
- queue timeout 또는 admission timeout 정책이 global wait 경로에서도 무기한 대기를 만들지 않는지 확인한다.
- repo 내부 edge-node 진단/full-cycle 증거가 보조 smoke와 구분되어 기록됐는지 확인한다.

## 검증 결과

_구현 에이전트가 각 중간 검증 및 최종 검증 명령 실행 후 출력을 여기에 붙여 넣는다._

필수 규칙:
- 검증 명령은 고정된 계약이다. 임의로 대체하지 않는다.
- 대체가 필요하면 `계획 대비 변경 사항`에 이유와 대체 명령을 기록한다.
- `검증 결과`에는 실제 stdout/stderr를 붙여 넣는다.
- 사용자 리뷰 요청으로 명령을 끝까지 실행하지 못했다면 `사용자 리뷰 요청`에 실행한 명령, 실제 출력, 미실행 명령의 사유를 기록한다.
- mobile/UI hang, timeout, 또는 2분 무진행은 blind retry를 중단하고 focused rerun 명령과 screenshot/window/UI-tree evidence path를 남기며, 불가능하면 정확한 사유를 남긴다.

### REVIEW_REFACTOR-1 중간 검증
```bash
$ go test -count=1 ./apps/node/internal/node -run 'TestAdmissionQueue_.*Global|TestAdmissionQueue_.*Queue|TestConcurrencyLimit'
--- PASS: TestAdmissionQueue_BackgroundQueuedReturnsThenRuns (0.01s)
--- PASS: TestAdmissionQueue_MaxQueueOverflow (0.00s)
--- PASS: TestAdmissionQueue_QueueTimeout (0.12s)
--- PASS: TestConcurrencyLimit_Unlimited (0.00s)
--- PASS: TestAdmissionQueue_AdapterCapQueues (0.01s)
--- PASS: TestAdmissionQueue_GlobalBeatsAdapterCap (0.01s)
--- PASS: TestAdmissionQueue_GlobalBeatsAdapterCap_DifferentAdapters (0.01s)
--- PASS: TestAdmissionQueue_GlobalNoCrossAdapterHeadOfLine (0.11s)
--- PASS: TestAdmissionQueue_QueueTimeoutAppliesAcrossGates (0.12s)
--- PASS: TestConcurrencyLimit_RejectStoreAndEvent (0.00s)
PASS
ok  	iop/apps/node/internal/node	0.387s
```
신규/핵심: `TestAdmissionQueue_GlobalNoCrossAdapterHeadOfLine`(교차 adapter 회귀), `TestAdmissionQueue_QueueTimeoutAppliesAcrossGates`(global-wait 단계 timeout).

### REVIEW_REFACTOR-2 중간 검증
```bash
$ ./scripts/e2e-smoke.sh
[e2e] Auxiliary smoke test PASSED.
[e2e] Completion still requires scripts/dev/edge.sh + scripts/dev/node.sh user-flow verification.
```
(보조 smoke. full-cycle 증거는 아래 `repo 내부 edge-node 진단 / full-cycle 증거` 참조.)

### 최종 검증
```bash
$ go test -count=1 ./apps/node/internal/node
ok  	iop/apps/node/internal/node	0.672s

$ go test -race -count=1 ./apps/node/internal/node
ok  	iop/apps/node/internal/node	1.924s

$ go test -count=1 ./apps/node/...
ok  	iop/apps/node/cmd/node	0.012s
ok  	iop/apps/node/internal/adapters	0.010s
ok  	iop/apps/node/internal/adapters/cli	47.077s
?   	iop/apps/node/internal/adapters/cli/internal/testutil	[no test files]
ok  	iop/apps/node/internal/adapters/cli/status	39.853s
?   	iop/apps/node/internal/adapters/mock	[no test files]
ok  	iop/apps/node/internal/adapters/ollama	0.012s
ok  	iop/apps/node/internal/adapters/vllm	0.013s
ok  	iop/apps/node/internal/bootstrap	0.265s
ok  	iop/apps/node/internal/node	0.675s
ok  	iop/apps/node/internal/router	0.005s
?   	iop/apps/node/internal/runtime	[no test files]
ok  	iop/apps/node/internal/store	0.043s
ok  	iop/apps/node/internal/terminal	0.563s
ok  	iop/apps/node/internal/transport	5.137s

$ ./scripts/e2e-smoke.sh
[e2e] Auxiliary smoke test PASSED.
```

### repo 내부 edge-node 진단 / full-cycle 증거

`agent-ops/skills/project/e2e-smoke/SKILL.md` 기준 repo 내부 edge-node 진단을 실제로 수행했다. 1차 log의 "외부 field host 필요" 판단은 오인이었고, `scripts/dev/edge.sh`(`edge console`)와 `scripts/dev/node.sh`(`node serve`)는 임시 config/포트로 **로컬 두 프로세스**로 구동된다. 본 진단은 두 스크립트를 deterministic `fake-cli` adapter로 구동해 실행했다(driver: `IOP_E2E_PROMPT_INDEX=1 ./scripts/e2e-smoke.sh`가 `scripts/dev/edge.sh` < fifo, `scripts/dev/node.sh`를 별도 프로세스로 띄움; 본문 라인 247/261).

```text
검증 결과
- Go 테스트: go test ./apps/node/... - 통과
- Repo 내부 edge-node 진단: 통과 (scripts/dev/edge.sh + scripts/dev/node.sh, 임시 edge.yaml/node.yaml, port=37256, fake-cli)
- 메시지 왕복: message x2 (foreground, session=default) - 통과
- Node message relay: node local payload == edge rendered payload (run별 내용/순서 동일) - 통과 (check_node_messages_relayed_to_edge diff 통과)
- Edge command 응답: /nodes, /capabilities, /transport, /sessions, /terminate-session - 통과
- Background run: /background on → session2 background run start/msg/complete - 통과
- 보조 E2E smoke: mock - 통과 (위 진단과 동일 실행에서 수행)
- Full-cycle 실제 구동: 통과 (register → /nodes → /capabilities → /transport → fg msg x2 → bg run → /sessions → /terminate-session)
- Real CLI profile: 미실행 (실제 claude/codex/antigravity/opencode CLI/계정 미구비; 본 변경은 admission/queue 로직으로 deterministic fake-cli로 충분히 커버, 실 provider 큐 동작은 원격 runner 별도 검증 권장)
- 남은 위험: 실 provider가 capabilities로 MaxQueue/QueueTimeoutMS를 채워 보내는 환경의 큐 동작은 mock 기준 검증. priority/weighted queue는 범위 외.
```

핵심 edge console 출력(요약, port=37256):
```text
edge> [node0-evt] connected reason="registered"
  node0 = test-node (test-node)
edge> [node0-capabilities] adapter=cli target=fake-cli session=default
  capacity = 4 / in_flight = 0 / queued = 0 / targets = fake-cli
edge> [node0-transport] connected = true / state = connected / node_id = test-node
edge> [edge] sent run_id=manual-...771988542 ... background=false
[node0-evt] start run_id=manual-...771988542
[node0-msg] IOP_E2E_HELLO_BASIC
[node0-msg] IOP_E2E_HELLO_BASIC_TAIL
[node0-evt] complete run_id=manual-...771988542 detail="idle-timeout"
edge> [edge] sent run_id=manual-...008341167 ... background=false
[node0-evt] start run_id=manual-...008341167
[node0-msg] IOP_E2E_HELLO_FORMAL
[node0-msg] IOP_E2E_HELLO_FORMAL_TAIL
[node0-evt] complete run_id=manual-...008341167 detail="idle-timeout"
edge> session → session2 ; background → on
edge> [node0-evt] start run_id=manual-...539497543 session=session2 background=true
[node0-msg] IOP_E2E_THANKS_SHORT
[node0-msg] IOP_E2E_THANKS_SHORT_TAIL
[node0-evt] complete run_id=manual-...539497543 detail="idle-timeout"
edge> [node0-sessions] sessions: 2
  [0] mode=persistent target=fake-cli session=default
  [1] mode=persistent target=fake-cli session=session2
edge> terminated session session2 node=node0
```
node-local `[node-message]` payload 목록(run별)과 edge `[node0-msg]` 목록이 내용/순서까지 동일하고, 각 run의 complete가 마지막 message 이후에만 도착했다(skill 판정 기준 충족).

---

> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**
> If anything is blank, go back and fill it in before saving this file.
> Leave review-agent-only sections unchanged.

Sections and their ownership:

| 섹션 | 소유자 | 설명 |
|------|--------|------|
| 헤더 주석, 개요(date/task/plan/tag), 리뷰 에이전트 지시 | 스텁 생성 시 고정 | 구현 에이전트가 수정하거나 실행하지 않음 |
| Roadmap Targets | follow-up plan에서 복사해 스텁 생성 시 고정 | 구현 에이전트가 수정하지 않음; PASS 시 code-review가 `complete.log`의 `Roadmap Completion`으로 복사 |
| 구현 항목별 완료 여부 (항목명) | 스텁 생성 시 고정 | `[ ]` -> `[x]` 체크만 구현 에이전트가 수행 |
| 구현 체크리스트 (항목 텍스트/순서) | follow-up plan에서 복사해 스텁 생성 시 고정 | 구현 에이전트가 `[ ]` -> `[x]` 체크만 수행; 마지막 체크박스는 저장 전 필수 |
| 코드리뷰 전용 체크리스트 | Review agent only | Implementing agent must not modify or check this section |
| 계획 대비 변경 사항, 주요 설계 결정 | 구현 에이전트가 채움 | placeholder 텍스트를 실제 내용으로 교체 |
| 사용자 리뷰 요청 | 구현 에이전트가 채움 | 진행에 사용자 입력이 필요하지 않으면 `상태: 없음` 유지; 구현 중 직접 질문은 금지; 필요하면 결정 항목, 근거, 명령 출력, 자동 후속 불가 이유, 재개 조건을 기록 |
| 리뷰어를 위한 체크포인트 | 스텁 생성 시 고정 | 계획에서 추출한 리뷰 포인트 |
| 검증 결과 (섹션 제목 + 명령) | 스텁 생성 시 고정 | 실행 출력만 구현 에이전트가 채움; 명령 변경은 `계획 대비 변경 사항`에 기록 |
| 코드리뷰 결과 | 리뷰 에이전트가 append | 스텁에 포함하지 않음 |

## 코드리뷰 결과

- 종합 판정: FAIL
- 차원별 평가:
  - correctness: Fail
  - completeness: Fail
  - test coverage: Fail
  - API contract: Pass
  - code quality: Pass
  - plan deviation: Pass
  - verification trust: Pass
- 발견된 문제:
  - Required: [run_manager.go](/config/workspace/iop/apps/node/internal/node/run_manager.go:332)의 `mapDeadline`은 `ctx.Err() == context.DeadlineExceeded`이면 어떤 deadline인지 구분하지 않고 `queue_timeout`으로 재분류합니다. 그런데 `ticket.wait(execCtx)`에 전달되는 `execCtx`는 [node.go](/config/workspace/iop/apps/node/internal/node/node.go:141)에서 `RunRequest.timeout_sec`로도 deadline이 걸릴 수 있습니다. 따라서 `queue_timeout_ms=0`인 provider queue에서 queued run이 request timeout으로 취소되어도 `queue timeout exceeded (queue_timeout=0s)`로 store/event에 기록되고, `queue_timeout_ms > timeout_sec`인 경우도 실제 원인은 request timeout인데 queue timeout으로 오분류됩니다. `queue_timeout`은 queue timeout mechanism이 실제로 만료된 경우에만 반환하도록 timeout cause/channel을 분리하고, parent deadline/cancel은 `concurrency_unavailable` 또는 별도 request-timeout reason으로 유지하는 회귀 테스트를 추가하세요.
- 다음 단계: WARN/FAIL 후속 plan/review 파일을 작성한다.
