[owjs3901]

Refs #683, #686 (W70/W82 후속: Windows Next webpack 프로세스 소유권 검증, 공지된 MAIN SETTLED 7af81664 통합 독립 PR)

PR #809 위에 쌓지 않았으며 선행 스택 의존성은 없습니다. theme/key-coercion 후속은 보호된 소유 영역과 겹쳐 별도 보고했고 이 PR에 포함하지 않았습니다. 변경은 기존 테스트 파일 하나와 packages/next-plugin/package.json: Patch changepack 하나뿐입니다.

요약

• 종료한 Windows job이 과거에 관찰한 숫자 PID를 process.kill(pid, 0)으로 전역 재조회하던 assertion을 제거했습니다. 그 숫자가 이후 무관한 프로세스에 재사용되면 job 정리가 완료되어도 실패하는 잘못된 판단입니다.
• 원래의 identity-bound 소유권 증거는 유지합니다. 실제 job의 active: [], 관찰한 복수 PID, 모든 fault descendant의 관찰 여부, 정상/실패 상태, 실제 Next HTML/CSS와 warm-cache 검증 및 fixture의 물리적 삭제를 계속 검사합니다.
• 프로덕션 코드, driver/supervisor/native job, receipt 형식, 의존성, 커버리지, 타임아웃 및 버전은 변경하지 않았습니다. 스타일링 런타임도 없습니다.

동작

Windows owner는 실제 프로세스를 suspended 상태로 만들고 실제 handle을 job에 배정한 뒤 실행합니다. 종료 시 정확한 job을 terminate하고 멤버가 0이 될 때까지 기다린 뒤 원래 root HANDLE도 기다립니다. supervisor는 이 성공 뒤에만 같은 job의 tree_exit를 기록하고, 실제 fixture 삭제 성공 뒤에만 cleanup을 기록합니다. 이 구현은 그대로입니다.

숫자 PID 목록은 과거 관찰의 증거이지 전역 프로세스 identity의 영구 예약이 아닙니다. 공통 테스트 assertion은 실제 job의 빈 membership과 관찰 증거를 판정하고, 종료 이후 무관한 identity가 같은 숫자를 소유했다는 이유로 이를 뒤집지 않습니다.

재현은 두 층으로 나누었습니다. 결정적 회귀 5개는 같은 assertion seam에서 숫자 재사용/전역 부재/owned survivor/관찰 부족/fault 관찰 누락을 구분합니다. 전역 lookup interception은 동기 호출 안에서만 적용하고 finally에서 복구하며 실제 OS에 signal을 보내지 않습니다. 별도로 실제 설치된 Next, webpack, HTTP/SSR/edge/CSS와 Windows kernel owner를 사용하는 기존 7개 시나리오를 그대로 실행했습니다. 가짜 receipt로 실제 kernel cleanup을 증명했다고 주장하지 않습니다.

새로 생기는 오류

새 build error, API 오류 및 생성되는 런타임 표현식은 없습니다. 프로덕션 변환/출력은 바꾸지 않았습니다. 테스트에서 진짜 owned survivor, descendant 관찰 부족 또는 fixture 삭제 실패가 발생하면 종전처럼 실패합니다.

남는 한계

OS scheduler가 실제로 PID를 재사용한 순간을 관찰한 재현은 아닙니다. main의 잘못된 assertion 결정은 좁은 전역 lookup 경계의 결정적 모델로 RED 확인했고, 실제 native 정리 증거는 별도의 진짜 Next 시나리오에서 확인했습니다. 기존 POSIX process-group 경로와 native owner의 보장 범위는 확장하지 않았습니다. 보호된 theme/coercion/추출기 후속은 이 테스트 전용 PR의 완료 주장에 포함하지 않습니다.

검증

최신 main 통합 (2026-11-01)

• 공지된 **MAIN SETTLED 7af8166487851bdfc884d735ec16160c9930443e**를 true merge했습니다. 검증된 snapshot 0f00b359와 settled main의 merge-tree 결과에 새 충돌은 없었으며, 실제 merge 상태에서 기존 테스트 충돌을 그 결과로 복원했습니다. main의 NEXT-EVENT/FAULT-PID/SERVER-PID producer와 이 PR의 exact-job assertion 및 5개 PID 대조군을 모두 보존했습니다.
• 최종 검토/테스트/staged/commit tree는 모두 **afce20ae89eb35e164a9e7fc773394b0c9e31abc**입니다. ONE 정상 훅 / ONE push, 새 head ff34a11691e00cde262ef5005505d8f3119c9e22, 실제 두 parent 9c2e54db + 7af81664, clean 작업 트리를 확인했습니다. settled main 대비 변경은 원래 Next 테스트와 next-plugin Patch changepack 두 경로뿐입니다.
• Bun 1.4.4, Node 26.12.0, default Rust stack, CI unset, CARGO_BUILD_JOBS=2 (workspace --jobs 1). frozen install, fresh WASM, root build, verify:dist, fmt/strict clippy/TS6-preload ESLint가 통과했습니다. workspace 10,862/0/0 ignored, 실제 설치된 Next의 전체 파일 12/0 (실제 7개 시나리오 + 결정적 5개 대조군), root 6,767/0 및 Vite 870/0, 양쪽 실제 All files 100.00% functions / 100.00% lines입니다.
• Window 64의 정상 훅 887.747초, peak 6,311,452,672 bytes (12 GB 상한), heartbeat 실패 0, 종료 후 정확한 owned job membership 0. 훅도 root 6,767/0, Vite 870/0, 양쪽 100.00/100.00을 확인했습니다. Windows Rust tarpaulin은 **97.79% (31832/32553)**이며 Linux 100%로 표현하지 않습니다. 창은 마지막 heavy 종료 직후 반환했습니다. LSP는 기존 미설치/거절 상태입니다.
• 정확한 새 head의 원격 CI **41271307903**를 확인 중입니다. 이전 head의 SUCCESS를 이번 통합의 Linux 100% 증거로 사용하지 않습니다.

최초 제출 당시 검증 (아래 수치와 CI는 이전 head의 역사적 기록)

• main 24a595763의 기존 global-PID assertion을 그대로 둔 공통 seam: 4 통과 / 1 실패, 유일한 실패는 무관한 identity가 과거 PID를 소유한 경우였습니다. 실제 원인은 기존 toThrow()의 Received function did not throw / Received value: true입니다. import/timeout 실패를 RED로 세지 않았습니다.
• 잘못된 3줄 lookup loop만 제거한 뒤 동일 결정적 회귀 5/0. 실제 Next 성공, singleCss 0/1 cold/repeat/warm 및 네 fault를 포함한 전체 파일 12/0. 포맷 정리 후 최종 파일도 다시 12/0을 확인했습니다. 각 실제 job은 active: []와 성공한 물리적 fixture cleanup을 기록했고 post-start-timeout은 reason: deadline, exit124를 유지했습니다.
• 최신 공식 Bun 1.4.4, Node 26.12.0에서 fresh install, WASM/전체 패키지 build, verify:dist, 최종 lint 통과. 기본 Rust 스택/jobs2의 workspace 9,428/0/0 ignored.
• 전체 root 6,257/0, Vite 868/0, 실제 양쪽 All files 100.00% functions / 100.00% lines. Lint의 첫 시도는 편집 파일의 줄바꿈/포맷 오류만 찾아 실패했고, 해당 파일에만 저장소 formatter를 적용한 뒤 최종 lint가 통과했습니다. 실패를 성공으로 바꾸어 기록하지 않았습니다.
• Oracle APPROVE / HIGH / blocker 없음. 원래 assertion 의도 및 진짜 kernel/Next 증거를 독립적으로 검토했습니다. 이후 delta는 포맷뿐이며 실제 최종 Next 파일을 재실행했습니다.
• 테스트·빌드는 직렬/기본 스택/CI unset/6 GiB watchdog, 시작 시 7 GiB RAM·25 GB 디스크 사전 조건으로 실행했습니다. 정상 훅은 별도 12 GiB/3300초 상한과 coordinator가 승인한 자원 창을 사용합니다. LSP는 기존 미설치/거절 상태라 clean LSP 주장은 하지 않습니다.
• coordinator가 승인한 자원 창에서 ONE 정상 훅 통과, 858.274초, 12 GiB 상한 내 peak 6,076,432,384 bytes, heartbeat 실패 없음. 정확한 검토/staged tree 5caa80181454211f7ecb57f84f04c20213b8e8e7에서 commit **9c2e54db2989ecdeb36278cf16ab1f5c20802313**가 생성되었으며 단일 parent는 main 24a595763, 작업 트리는 clean입니다. 실제 훅의 루트 6,257/0 및 Vite 868/0, 양쪽 100.00/100.00을 다시 확인했습니다. bypass/amend/force는 없습니다.
• 원격 CI 40429120601 SUCCESS, 정확한 head 9c2e54db2989ecdeb36278cf16ab1f5c20802313, 재실행 0회. publish / benchmark / landing-next-e2e / react-18 / vinext-rsc-css-e2e / webpack-extends-theme / release-compat / wasm-size 8개 validation job 모두 통과했습니다. main 전용 release/deploy-pages skip은 예상된 조건부 제외입니다.
• 실제 Linux 로그: Rust 100.00% (19990/19990), root 6,257/0, Vite 867/0, 양쪽 All files 100.00% functions / 100.00% lines, Bun preload race 10/0. Landing 두 CSS 모드 모두 71 routes / 0 skipped를 확인했습니다. Windows의 Vite868과 Linux의867을 혼동해 기록하지 않았으며, prerender skip/취소/성능/크기 예외나 rerun은 사용하지 않았습니다.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.