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

# Code Review Reference - 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`.

## 개요

date=2026-06-14
task=m-provider-availability-capacity-queue-foundation/04+03_fifo_admission_queue, plan=0, tag=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]** 아래 종결 절차는 코드리뷰 에이전트 전용이다. 구현 에이전트는 이 섹션을 실행하지 않는다.

각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.

---

## 구현 항목별 완료 여부

| 항목 | 완료 여부 |
|------|---------|
| [REFACTOR-1] FIFO Admission Manager | [x] |
| [REFACTOR-2] OnRunRequest Admission Path | [x] |
| [REFACTOR-3] Queue Rejection Events | [x] |

## 구현 체크리스트

- [x] predecessor `03_queue_capability_contract`의 `complete.log`가 active 또는 archive에 있는지 확인한다. (archive `agent-task/archive/2026/06/m-provider-availability-capacity-queue-foundation/03_queue_capability_contract/complete.log` 존재 확인. PASS 시에만 complete.log 작성 + archive 이동되는 워크플로 규칙상 존재 자체가 PASS 근거이며, predecessor가 추가한 `runtime.Capabilities`의 `MaxQueue`/`QueueTimeoutMS`/`RequestTimeoutMS` 필드를 본 구현이 직접 소비한다.)
- [x] `permitManager` 또는 새 admission manager를 FIFO queue semantics로 교체한다. (`permitManager`/`atomic.Int32`를 제거하고 FIFO-fair `fifoGate` + `admissionManager`/`admissionTicket`로 교체.)
- [x] `OnRunRequest`가 capacity 여유가 있으면 즉시 실행하고, capacity가 차면 provider별 FIFO queue에 요청을 대기시킨다.
- [x] 실행 완료, 실패, 취소, timeout 시 permit을 release하고 queue head를 실행 슬롯으로 승격한다. (`run` defer `ticket.release()` → `fifoGate.release()`가 FIFO head를 승격.)
- [x] `max_queue` 초과와 `queue_timeout_ms` 초과는 store status와 RunEvent error에 명확한 reason을 남긴다. (`reasonQueueFull`/`reasonQueueTimeout`/`reasonConcurrencyUnavailable`; store status `rejected` + RunEvent error에 동일 reason text.)
- [x] foreground/background run 모두 같은 admission path를 사용한다. (`launch()` 단일 경로. foreground는 동기, queued background는 enqueue 후 반환하고 goroutine에서 wait+execute.)
- [x] node unit/integration tests를 FIFO 정책에 맞게 추가/수정한다.
- [x] 최종 검증 명령을 실행한다.
- [x] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.

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

> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.

- [x] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
- [x] active `CODE_REVIEW-*-G??.md`를 `code_review_cloud_G06_N.log`로 아카이브한다.
- [x] active `PLAN-*-G??.md`를 `plan_cloud_G06_M.log`로 아카이브한다.
- [ ] PASS이면 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
- [ ] PASS이면 active task 디렉터리를 archive로 이동한다.
- [ ] PASS이고 task group이 `m-provider-availability-capacity-queue-foundation`이면 완료 이벤트 메타데이터를 보고하고 roadmap을 직접 수정하지 않는다.
- [x] `.gitignore`의 Agent-Ops 관리 block이 `agent-task/**/*.md`와 `agent-task/**/*.log`를 unignore하고 `agent-roadmap/current.md`를 ignore하는지 확인한다.
- [x] FAIL이고 user-review gate가 트리거되지 않았으므로 다음 active `PLAN-cloud-G06.md`와 `CODE_REVIEW-cloud-G06.md`를 작성하고 `complete.log`를 작성하지 않는다.

## 계획 대비 변경 사항

- **admit 단일 호출 → enqueue/wait 2단계 분리.** 계획 REFACTOR-2의 의사코드는 `admission.admit(ctx)` 단일 blocking 호출이었으나, 그대로 구현하면 queued background run이 `OnRunRequest` 안에서 승격될 때까지 caller(transport handler)를 막아 "enqueue 성공 후 반환" 요구를 위반하고 첫 통합 실행에서 deadlock이 발생했다(확인됨). 그래서 `admissionManager`를 non-blocking `enqueue()`(overflow만 즉시 판정) + blocking `admissionTicket.wait()`로 분리했다. foreground는 동기 wait, queued background는 enqueue 후 반환하고 goroutine에서 wait+execute한다.
- **store status 흐름에 `queued` 상태 추가.** 계획 REFACTOR-2 체크리스트의 "store status는 queued/running/rejected/completed 흐름이 추적 가능해야 한다. store schema 변경 없이 status string 업데이트로 가능한지 우선 확인"에 따라, schema 변경 없이 status string만으로 처리했다. 요청을 먼저 `queued`로 insert하고, 승격 시 `MarkRunning`으로 `running` 전환, reject 시 `rejected` 전환한다. 이를 위해 `store.Store`에 `MarkRunning(ctx, runID)` 1개 메서드만 추가했다(기존 `InsertRun`/`CompleteRun`은 그대로 사용).
- **`max_queue` 의미 확정.** `caps.MaxQueue`를 `>0`=큐 길이 상한, `==0`=큐 불가(가득 차면 즉시 queue_full reject, 즉 기존 reject-on-exceed와 동일), `<0`=무제한으로 정의했다. 노드 전역 global gate는 `-1`(무제한)로 구성해 per-provider 큐 정책만 reject를 좌우하게 했다.
- **`ProviderSnapshot.Queued`는 0 유지.** 계획 "제외" 항목(PLAN line 73)대로 queued snapshot 채우기는 후속 `05+04_queue_observe_snapshot` 범위라 capabilities 응답의 `queued`/`Queued`는 0으로 둔다. `fifoGate.queuedCount()` API는 05에서 쓰도록 미리 두었다.

## 주요 설계 결정

- **`fifoGate` = FIFO-fair counting semaphore.** mutex + `inFlight` + `[]chan struct{}` waiter 큐. `reserve()`는 non-blocking으로 즉시 슬롯/대기채널/overflow를 결정, `waitOn(ctx, ch, applyTimeout)`은 promotion/queue_timeout/ctx-cancel을 select로 처리. `release()`는 waiter가 있으면 head를 close해 슬롯을 그대로 이전(FIFO 승격), 없으면 `inFlight--`.
- **goroutine/leak 방지.** 대기 중 timeout/cancel 시 `abandon(ch)`이 waiter 슬라이스에서 제거하고, promotion과의 race는 `abandon` 반환값으로 구분(이미 승격됐으면 슬롯을 honor). run의 `defer ticket.release()`가 success/failure/cancel/timeout 모든 종료 경로에서 슬롯을 반납. race detector(`go test -race`) clean.
- **2-gate 합성 순서.** adapter gate를 먼저 reserve(per-provider FIFO 보장, cross-adapter head-of-line blocking 회피), 그다음 global gate. `wait()`는 adapter→global 순으로 대기하고 실패 시 보유 슬롯을 unwind. queue timeout은 두 wait에 각각 적용(global gate는 무제한/무timeout이라 실질 bottleneck은 adapter gate).
- **`ErrConcurrencyLimitExceeded` 호환 유지.** 새 `admissionError`가 `Is(ErrConcurrencyLimitExceeded)`를 만족하도록 구현해 기존 `errors.Is` 호출부/테스트를 깨지 않으면서, 구체 reason(`queue_full`/`queue_timeout`/`concurrency_unavailable`)을 `admissionRejectReason`/`admissionMessage`로 노출한다. RunEvent error와 store error에 동일 reason text가 들어간다.
- **cancel-while-queued 지원.** run을 enqueue 직후 `runManager`에 register하고, wait는 run의 `execCtx`(= `OnCancel`이 호출하는 cancel과 연결)로 대기하므로 큐에서 대기 중인 run도 취소 시 큐에서 빠지고 reject로 종결된다.

## 사용자 리뷰 요청

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

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

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

- predecessor `03_queue_capability_contract` 완료 근거가 있는지 확인한다.
- queue admission이 FIFO이며 goroutine/context leak 가능성이 없는지 확인한다.
- foreground/background semantics와 store/event side effects가 테스트와 일치하는지 확인한다.
- full-cycle/e2e 생략이 있으면 사유와 남은 위험이 기록됐는지 확인한다.

## 검증 결과

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

### REFACTOR-1 중간 검증
```bash
$ go test -count=1 ./apps/node/internal/node -run 'Test.*Queue|TestConcurrency'
ok  	iop/apps/node/internal/node	0.444s
```
포함 테스트(모두 PASS): TestAdmissionQueue_ForegroundSecondWaitsThenRuns, _BackgroundQueuedReturnsThenRuns, _FIFOOrdering, _MaxQueueOverflow, _QueueTimeout, _ReleaseAfterFailurePromotesNext, _ReleaseAfterCancelPromotesNext, _PermitReleasedAfterCompletion, _AdapterCapQueues, _GlobalBeatsAdapterCap, _GlobalBeatsAdapterCap_DifferentAdapters, TestConcurrencyLimit_Unlimited, _RejectStoreAndEvent, TestQueueOverflow_RejectEventObservedByEdge.

### REFACTOR-2 중간 검증
```bash
$ go test -count=1 ./apps/node/internal/node
ok  	iop/apps/node/internal/node	0.459s
```

### REFACTOR-3 중간 검증
```bash
$ go test -count=1 ./apps/node/internal/node -run 'Test.*Reject|Test.*Queue|TestConcurrencyLimit_.*Event'
ok  	iop/apps/node/internal/node	0.436s
```

### 추가 검증 (race detector)
```bash
$ go test -race -count=1 ./apps/node/internal/node
ok  	iop/apps/node/internal/node	1.691s
```

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

$ go test -count=1 ./apps/node/...
ok  	iop/apps/node/cmd/node	0.014s
ok  	iop/apps/node/internal/adapters	0.016s
ok  	iop/apps/node/internal/adapters/cli	46.772s
?   	iop/apps/node/internal/adapters/cli/internal/testutil	[no test files]
ok  	iop/apps/node/internal/adapters/cli/status	39.730s
?   	iop/apps/node/internal/adapters/mock	[no test files]
ok  	iop/apps/node/internal/adapters/ollama	0.016s
ok  	iop/apps/node/internal/adapters/vllm	0.015s
ok  	iop/apps/node/internal/bootstrap	0.267s
ok  	iop/apps/node/internal/node	0.459s
ok  	iop/apps/node/internal/router	0.007s
?   	iop/apps/node/internal/runtime	[no test files]
ok  	iop/apps/node/internal/store	0.058s
ok  	iop/apps/node/internal/terminal	0.576s
ok  	iop/apps/node/internal/transport	5.141s

$ ./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: mock/fake-cli adapter로 같은 session 메시지 3회가 start → `[node-message]` → complete 순서로 정상 통과. 새 admission path가 기존 정상 실행 흐름을 회귀시키지 않음을 확인.)

### full-cycle 수동 검증 생략 사유 / 남은 위험
- node-smoke 필수 검증 중 "repo 내부 edge-node 진단 + full-cycle 실제 구동"(`scripts/dev/edge.sh` + `scripts/dev/node.sh` 사용자 흐름, 외부 Edge runtime `toki-labs.com:19090`)은 현재 작업 컨테이너에서 외부 field host/TCP 접근이 불가하여 생략했다(node-smoke 차단 기준: field host 또는 Edge-Node TCP port 접근 불가).
- 대체로 보조 `./scripts/e2e-smoke.sh`(mock adapter full pipeline)와 deterministic unit/integration + `-race`로 admission/queue/release/reject 경로를 커버했다.
- 남은 위험: 실제 외부 provider(ollama/vllm/CLI)가 `MaxQueue`/`QueueTimeoutMS`를 capabilities로 채워 보내는 실환경에서의 큐 동작은 mock 기준으로만 검증됨. 실 Edge 연동 full-cycle 검증은 원격 runner에서 별도 수행 필요.

---

> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**

## 코드리뷰 결과

- 종합 판정: FAIL
- 차원별 평가:
  - correctness: Fail
  - completeness: Fail
  - test coverage: Fail
  - API contract: Pass
  - code quality: Pass
  - plan deviation: Fail
  - verification trust: Fail
- 발견된 문제:
  - Required: [apps/node/internal/node/run_manager.go](/config/workspace/iop/apps/node/internal/node/run_manager.go:278)에서 `enqueue()`가 adapter gate가 아직 승격되지 않은 요청까지 global gate에 즉시 `reserve()`합니다. 이 상태에서 global slot이 비면 adapter slot을 아직 얻지 못한 요청이 global head를 선점할 수 있어, 다른 adapter의 큐 head가 실행 가능한데도 global slot을 쓰지 못합니다. 예: global=2, adapter A/B capacity=1에서 A1/B1 실행 중 A2를 먼저 큐에 넣고 B2를 큐에 넣은 뒤 B1만 release하면, B2는 adapter B slot이 비었는데도 A2가 global slot을 선점해 A1 release 전까지 시작하지 못합니다. `max_queue`/`queue_timeout`도 이 숨은 global 대기에 일관되게 적용되지 않습니다. 수정은 adapter gate가 실제로 grant된 뒤 global gate를 reserve/wait하도록 합성 순서를 바꾸고, 위 교차 adapter 회귀 테스트를 추가하세요.
  - Required: [code_review_cloud_G06_0.log](/config/workspace/iop/agent-task/m-provider-availability-capacity-queue-foundation/04+03_fifo_admission_queue/code_review_cloud_G06_0.log:155)에 필수 `scripts/dev/edge.sh` + `scripts/dev/node.sh` repo 내부 edge-node 진단/full-cycle 검증이 생략된 상태로 남아 있습니다. 이 작업은 node 실행/admission 경로 변경이므로 `agent-test/local/node-smoke.md` 기준상 보조 `./scripts/e2e-smoke.sh`만으로 완료 증거가 되지 않습니다. 후속 작업에서 임시 config/포트로 해당 진단을 실제 수행하거나, 수행 불가 시 실행한 명령과 실제 stdout/stderr가 있는 blocker evidence를 남기세요.
- 다음 단계: WARN/FAIL 후속 plan/review 파일을 작성한다.
