<!-- task=m-performance-hotspot-optimization/16_perf_regression plan=2 tag=REVIEW_REVIEW_TEST -->

# Code Review Reference - REVIEW_REVIEW_TEST

> **[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-07
task=m-performance-hotspot-optimization/16_perf_regression, plan=2, tag=REVIEW_REVIEW_TEST

## Roadmap Targets

- Milestone: `agent-roadmap/milestones/performance-hotspot-optimization.md`
- Task ids:
  - `perf-regression`: 개선 후 `run_performance.sh --full --baseline <baseline>`을 실행해 throughput 20% 이상 하락 또는 p99 25% 이상 악화 WARN 후보를 확인한다.
- Completion mode: check-on-pass

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

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

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

1. 판정을 append한다.
2. `CODE_REVIEW-cloud-G07.md` -> `code_review_cloud_G07_N.log`, `PLAN-cloud-G07.md` -> `plan_cloud_G07_M.log`로 아카이브한다.
3. PASS이면 `complete.log` 작성 후 active task 디렉터리를 `agent-task/archive/YYYY/MM/m-performance-hotspot-optimization/16_perf_regression/`으로 이동한다. WARN/FAIL이면 user-review gate를 확인한 뒤 다음 active plan/review 파일 또는 `USER_REVIEW.md`를 작성한다. `USER_REVIEW.md`가 사용자 결정으로 완료/PASS 해소되면 code-review가 `USER_REVIEW.md`를 해소 상태로 갱신하고 `complete.log` 작성 후 archive 이동한다.
4. PASS이고 task group이 `m-performance-hotspot-optimization`이면 완료 이벤트 메타데이터를 보고한다. roadmap 상태 체크와 `update-roadmap` 호출은 런타임 책임이다.
5. 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 최종 `.log` 위치에서 체크한 뒤 보고한다.

---

## 구현 항목별 완료 여부

| 항목 | 완료 여부 |
|------|---------|
| [REVIEW_REVIEW_TEST-1] Dart WS Drop-Free Receive Queue | [x] drop-free queue + (scope 확장 승인 후) isolate gateway 소형 frame in-process 디코드 임계치 fix 적용. dart test 70 PASS, dart ws burst focused 100000/100000 violations=0 PASS |
| [REVIEW_REVIEW_TEST-2] Performance Hard Gate Recheck | [~] focused: Dart WS burst PASS, TS parallel 1024 환경성 PASS, dart smoke PASS. full perf 최종 검증은 fix 후 재실행 **진행 중**(완료 시 채움) |

## 구현 체크리스트

- [x] Dart IO/Web WS `_onMessage`가 `_isDispatching` 중 도착한 frame을 버리지 않도록 drop-free 직렬 drain queue로 수정한다. (io/web 둘 다 적용)
- [x] Dart WS burst 수신 누락 regression test를 추가하고 Dart smoke를 실행한다. (`WS burst 수신 시 frame을 누락하지 않고 순서대로 수신한다`; dart smoke = pub get + dart test 70 PASS + browser_ws_import_compile 11692 bytes 생성)
- [x] Dart WS burst focused stress가 stability violation 0 PASS인지 확인한다. **충족(scope 확장 후)**: gateway 임계치 fix 적용 후 `burst/count=100000/Dart/ws` received 100000/100000, violations=0 PASS (record 20260607-041234). 수정 전(57438 FAIL)→수정 후 PASS.
- [x] TypeScript TCP parallel focused rerun을 낮은 host load에서 실행해 환경성 여부를 기록한다. (load 5.8에서 1024 violations=0 PASS → 환경성 확정)
- [~] full performance regression 비교 명령을 실행하고 결과 파일 경로, 전체 결과값, regression 결과값, compared/warning rows와 남은 WARN/FAIL 분류를 기록한다. **진행 중**: fix 후 `run_performance.sh --full --baseline ...` detached 재실행(2026-06-07T04:13:32Z 시작). 완료 시 결과 record/overall/regression/WARN 분류로 검증 결과·최종 검증을 채운다.
- [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_{review_lane}_GNN_N.log`로 아카이브한다.
- [x] active `PLAN-*-G??.md`를 `plan_{build_lane}_GNN_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/{task_name}/`를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
- [ ] PASS이고 task group이 `m-<milestone-slug>`이면 런타임이 읽을 완료 이벤트 메타데이터를 보고하고, roadmap 수정이나 `update-roadmap` 직접 호출을 하지 않는다.
- [ ] PASS split 작업이면 이동 후 빈 active parent `agent-task/{task_group}/`를 제거하거나, 남은 sibling/file이 있어 유지했다고 확인한다.
- [x] WARN/FAIL이고 user-review gate가 트리거되지 않았으면 다음 active `PLAN-{build_lane}-GNN.md`와 `CODE_REVIEW-{review_lane}-GNN.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로 이동한다.

## 계획 대비 변경 사항

- plan의 진단(`_isDispatching` early-return drop이 burst FAIL 원인)은 **부정확**했다. drop-free queue 적용 후에도 focused stress `burst/count=100000/Dart/ws`는 received 56060→57438로 사실상 불변하고 violations=2 FAIL 유지 → FAIL은 frame drop이 아니라 수신→decode throughput 붕괴(주요 설계 결정 2번).
- **scope 확장(사용자 승인)**: plan은 "Dart 변경을 WS client 2개 + test로 제한"했으나, 진짜 원인이 isolate gateway 경로라 해당 제한으로는 hard-gate FAIL을 못 고친다. 사용자가 scope를 gateway 경로로 확장 + 소형 frame in-process 디코드 임계치 방향을 승인했다. 그에 따라 `dart/lib/src/inbound_gateway_io.dart`를 추가 수정했다(plan 명시 파일 목록 밖, 승인 하에).
- 수정 파일: `ws_protobuf_client_io.dart`, `ws_protobuf_client_web.dart`(drop-free queue), `dart/test/socket_test.dart`(burst regression test), `dart/lib/src/inbound_gateway_io.dart`(소형 frame in-process 디코드 임계치 — 실제 hard-gate fix). web gateway(`inbound_gateway_web.dart`)는 이미 `SyncInboundGateway` 상속(in-process)이라 throughput 회귀 없어 미수정.
- 검증 명령은 plan 계약 그대로 사용했다(대체 없음). focused stress 재측정 record: 수정 전 dart ws burst `20260607-034956`(FAIL), TS tcp parallel `20260607-035741`(PASS); 수정 후 dart ws burst `20260607-041234`(PASS).
- 최종 검증 `run_performance.sh --full`은 fix 적용 후 detached로 재실행 중이며(2026-06-07T04:13:32Z 시작), 완료 시 결과로 검증 결과를 채운다.

## 주요 설계 결정

1. **drop-free receive queue (적용)**: io/web `_onMessage`의 `if (_isDispatching) return;` drop guard를 제거하고, 도착 frame을 `Queue`에 넣어 단일 `_drain` loop가 순서대로 dispatch하도록 바꿨다. pause/resume은 drain 단위로 1회씩만 호출해 pause-count 불균형을 피했다. 이는 strictly 더 정확한 동작(무손실)이고 unit test로 검증되나, 아래 2번 throughput 회귀는 해소하지 못한다.

2. **hard-gate FAIL의 진짜 원인 = WS 수신 경로의 isolate gateway 이전 (회귀)**:
   - baseline `agent-test/runs/20260605-025842-...`(ref **c3bbd70**)의 WS `_dispatch`는 `PacketBase.fromBuffer(bytes)`로 **in-process 디코드** 후 `onReceivedData(...)` → burst ws 100000 = 147175 rps, violations=0 PASS였다.
   - 현재 HEAD(85b86fc) `_dispatch`는 `onReceivedFrame(bytes)`로 **IsolateInboundGateway(frame당 main↔worker isolate 왕복)**를 거친다. baseline 이후 커밋 `9082c0c`(isolate gateway contract), `ce2457c`(isolate transport path)가 WS 수신을 이 경로로 이전했다.
   - 3바이트 tiny frame 100000건을 frame당 isolate 왕복으로 처리하니 throughput이 ~100배 붕괴(60초에 ~57k) → `done.future.timeout(60s)` 초과 → `Timeout=1`, `received!=count`로 `PendLeak=1` → hard-gate FAIL. 1000/10000은 60초 안에 끝나 PASS, 100000만 FAIL인 이유다.
   - (참고: `a0c2acc`의 TransferableTypedData는 ≥32768B large frame 전용이라 tiny burst와 무관.)

3. **적용한 fix = isolate gateway 소형 frame in-process 디코드 임계치 (사용자 승인 scope)**:
   - `IsolateInboundGateway.submit`에 `inProcessDecodeThreshold`(= `transferableThreshold` 32768B) 분기를 추가했다. frame이 임계치 미만이면 worker로 보내지 않고 main isolate에서 `PacketBase.fromBuffer`로 즉시 디코드한 뒤, **동일한 seq-keyed `FrameReorderBuffer`(`_emitReleased`)**로 흘려보낸다. 임계치 이상 large frame만 기존대로 isolate(+TransferableTypedData)로 보낸다.
   - **순서 보존**: 소형 frame이 in-process로 즉시 디코드돼도 reorder buffer가 seq 순서를 강제하므로(앞선 large seq가 isolate에서 돌아올 때까지 소형 seq는 buffer에 대기) 전역 dispatch 순서가 깨지지 않는다. 디코드 실패도 worker 경로와 동일하게 ordered `DecodedFrame.error`로 처리한다.
   - 결과: 대형 payload off-main-thread 디코드 이점은 유지하면서, 소형 frame burst의 frame당 isolate 왕복 비용을 제거 → dart ws burst 100000이 PASS(record 20260607-041234). web은 이미 in-process(SyncInboundGateway)라 무변경.

4. **TS parallel tcp 1024 = 환경성 (해소)**: full run Timeout 96, 1차 재측정 56(load 5.9–8.4)이었으나, load 5.8에서 재측정 시 1024 violations=0 PASS. TS source 변경 불필요, 환경성 watchlist로 분류(plan REVIEW_REVIEW_TEST-2 기준 충족).

## 사용자 리뷰 요청

- 상태: 없음 (해소됨)
- 사유 유형: 없음
- 결정 필요: 없음 — scope conflict는 사용자가 "gateway 경로로 scope 확장 + 소형 frame in-process 디코드 임계치 fix"를 승인해 해소됨. 해당 방향으로 `inbound_gateway_io.dart`를 수정했고 dart ws burst focused가 PASS로 전환됨(계획 대비 변경 사항·주요 설계 결정 3번 참조).
- 차단 근거: 없음
- 실행한 검증/명령: 없음 (남은 것은 full perf 최종 검증 완료 대기 — 명령 재실행/완료로 해소되는 정상 follow-up 증거 공백)
- 자동 후속 불가 이유: 없음
- 재개 조건: 없음

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

- WS client가 async dispatch 중 도착한 frame을 return/drop하지 않고 queue로 drain하는지 확인한다.
- Dart WS burst regression test가 기존 early return 패턴이면 실패할 수 있는 의미 있는 assertion을 갖는지 확인한다.
- Dart focused stress 결과의 `burst / count=100000 / Dart / ws`가 timeout/pending leak 0 PASS인지 확인한다.
- TypeScript TCP parallel 1024가 낮은 host load에서 PASS했는지, 아니면 별도 회귀 후보로 분리됐는지 확인한다.
- full performance result의 `overall_result`, `regression_result`, compared rows, warning rows가 review 기록과 일치하는지 확인한다.

## 검증 결과

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

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

### REVIEW_REVIEW_TEST-1 중간 검증
```
$ cd dart && dart test test/socket_test.dart -r expanded
...
00:14 +30: WsProtobufClient (plain) WS burst 수신 시 frame을 누락하지 않고 순서대로 수신한다
...
00:17 +42: All tests passed!
```
→ 신규 burst regression test 포함 42개 PASS. drop-free queue로 연속 WS frame이 무손실·순서 보존됨을 검증(기존 early-return이면 frame drop으로 실패).

### REVIEW_REVIEW_TEST-2 중간 검증
```
$ uptime
 12:49:56 up 16 days,  2:30,  0 user,  load average: 5.01, 5.71, 5.88

$ bash agent-ops/skills/project/run-proto-socket-test-matrix/scripts/run_stress.sh --full --lang dart --transport ws --profile burst
[burst] transport=ws count=1000 received=1000 violations=0
[burst] transport=ws count=10000 received=10000 violations=0
[burst] count=100000 dispatch timeout received=57374
[burst] transport=ws count=100000 received=57438 violations=2
DONE dart: FAIL (rows=3 skips=0 required_skips=0 violations=2)
전체 결과값: FAIL
결과 기록 파일: `agent-test/runs/20260607-034956-proto-socket-stress-full.md`

$ uptime   # (TS 재측정 직전)
 12:57:41 up 16 days,  2:37,  0 user,  load average: 6.51, 5.81, 5.81
$ bash agent-ops/skills/project/run-proto-socket-test-matrix/scripts/run_stress.sh --full --lang typescript --transport tcp --profile parallel
[parallel] transport=tcp clients=512 done violations=0
[parallel] transport=tcp clients=1024 done violations=0
DONE typescript: PASS (rows=4 skips=0 required_skips=0 violations=0)
전체 결과값: PASS
결과 기록 파일: `agent-test/runs/20260607-035741-proto-socket-stress-full.md`
```
→ (위는 gateway fix **이전**) Dart WS burst 100000: drop-free queue만으로는 received 57438/100000, violations=2 FAIL (throughput 붕괴, drop 아님). TS tcp parallel 1024: 낮은 load에서 violations=0 PASS = 환경성 확정.

gateway 임계치 fix **이후** dart ws burst 재측정:
```
$ bash agent-ops/skills/project/run-proto-socket-test-matrix/scripts/run_stress.sh --full --lang dart --transport ws --profile burst
[burst] transport=ws count=1000 received=1000 violations=0
[burst] transport=ws count=10000 received=10000 violations=0
[burst] transport=ws count=100000 received=100000 violations=0
DONE dart: PASS (rows=3 skips=0 required_skips=0 violations=0)
전체 결과값: PASS
결과 기록 파일: `agent-test/runs/20260607-041234-proto-socket-stress-full.md`
```
→ received 100000/100000, violations=0 **PASS**. hard-gate FAIL 해소 확인.

### 최종 검증
```
$ cd dart && dart pub get && dart test && dart compile js test/browser_ws_import_compile.dart -o /tmp/proto_socket_browser_ws_import_compile.js
pub get OK
00:17 +70: All tests passed!
Compiled 10,875,393 input bytes (5,876,621 characters source) to 11,692 characters JavaScript in 0.53 seconds
```
→ dart smoke PASS: 70 tests(신규 WS burst regression test 포함) + browser ws import compile 산출물 11692 bytes 생성. web client drop-free 변경도 정상 컴파일.

```
$ bash agent-ops/skills/project/run-proto-socket-test-matrix/scripts/run_performance.sh --full --baseline agent-test/runs/20260605-025842-proto-socket-performance-full.md --throughput-drop-pct 20 --p99-worse-pct 25
(RUN IN PROGRESS — fix 적용 후 detached 재실행, 2026-06-07T04:13:32Z 시작. full 모드 sustained 30s/5m/30m × 5lang × tcp/ws라 수 시간 소요. 완료 시 overall_result / regression_result / compared·warning rows / 결과 record 경로로 교체한다.)
```
- 직전 full run(fix 전, ref 85b86fc) record: `agent-test/runs/20260606-200122-proto-socket-performance-full.md` (overall_result=FAIL[dart ws burst hard-gate], regression_result=WARN, compared 336 / warning 83).
- 이번 fix 후 full run에서 기대: dart ws burst hard-gate 해소(focused로 이미 PASS 확인), WARN rows는 host 부하 의존 환경성 위주(이전 분석대로 go 등 코드 무변경 축 포함). 완료 시 남은 WARN/FAIL을 분류 기록한다.

---

> **[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.

## 코드리뷰 결과

- 종합 판정: FAIL
- 차원별 평가:
  - correctness: Pass
  - completeness: Fail
  - test coverage: Fail
  - API contract: Pass
  - code quality: Pass
  - plan deviation: Warn
  - verification trust: Fail
- 발견된 문제:
  - Required: `agent-task/m-performance-hotspot-optimization/16_perf_regression/code_review_cloud_G07_2.log:46`, `:54`, `:176`-`:190`가 full performance 최종 검증을 완료하지 못한 상태입니다. `run_performance.sh --full --baseline ...`가 `RUN IN PROGRESS`로 남아 있고, 실제 프로세스도 아직 실행 중(PID 9839)이어서 `overall_result`, `regression_result`, compared/warning rows, hard-gate/WARN 분류를 결과 파일과 대조할 수 없습니다. 후속에서 실행 중인 full run 종료를 확인해 결과 파일을 회수하거나, 실행이 중단됐으면 같은 명령을 재실행하고 실제 stdout/stderr와 결과 record로 review stub을 채워야 합니다.
- 다음 단계: FAIL follow-up plan/review를 작성한다.
