@simplysm/sd-cli 14.1.8 → 14.1.10

package/tests/workers/client-worker-cleanup.verify.md

@@ -1,8 +0,0 @@
-# Feature 3.1 client.worker.ts 호출부 업데이트 — LLM 검증
-
-## 검증 항목
-
-- resolvePackageInfo에서 tsconfigPath 반환 제거: 반환 타입이 `{ pkgName: string }`으로 변경됨. 함수 내부에서 `tsconfigPath` 변수 선언 및 계산이 제거됨. 모든 호출부(startWatch:199, startLegacyWatch:266, build:396)에서 `{ pkgName }`으로만 구조분해.
-- startWatch에서 제거된 옵션 미전달: `createClientViteConfig` 호출에서 `tsconfigPath`, `browserslist`, `postCssPlugins`, `legacyModule`, `enableLint` 모두 제거됨.
-- startLegacyWatch에서 제거된 옵션 미전달: 동일하게 5개 옵션 모두 제거됨.
-- build에서 제거된 옵션 미전달: 동일하게 5개 옵션 모두 제거됨.

package/tests/workers/client-worker-initial-build-error.verify.md

@@ -1,7 +0,0 @@
-# 초기 빌드 에러 보고 — LLM 검증
-
-## 검증 항목
-
-- client.worker.ts onEnd에서 초기 빌드 시 errors 필드가 포함되는지: `client.worker.ts:285-291` — `initialBuildResolve`에 `errors: result.errors.map((e) => e.text)` 포함 확인
-- EsbuildClientEngine.startWatch에서 반환값의 success 확인 후 ResultCollector에 보고하는지: `EsbuildClientEngine.ts:129-138` — `!result.success` 조건으로 `resultCollector.add()` 호출 확인. logger.error는 Feature 1.2에서 제거됨 (중복 출력 방지)
-- esbuild-client-config.ts에서 logLevel이 "silent"인지: `esbuild-client-config.ts:191` — `logLevel: "silent"` 확인. Feature 1.2에서 dev/build 모두 "silent"로 통일됨

package/tests/workers/client-worker-initial-build-warnings.verify.md

@@ -1,7 +0,0 @@
-# 초기 빌드 warnings 전달 — LLM 검증
-
-## 검증 항목
-
-- client.worker.ts의 initialBuildResolve에 warnings 필드가 포함되는지: `client.worker.ts:305-315` — `initialBuildResolve`에 `warnings: result.warnings.length > 0 ? result.warnings.map(formatEsbuildMessage) : undefined` 포함 확인. 후속 빌드(line 295-298)와 동일 패턴
-- warnings가 없을 때 undefined인지: `client.worker.ts:312-314` — `result.warnings.length > 0` 조건으로 빈 배열일 때 undefined 반환 확인
-- ClientBuildResult 인터페이스에 warnings 필드가 있는지: `client.worker.ts:47` — `warnings?: string[]` 확인. 변경 불필요

package/tests/workers/client-worker-mtime-incremental.verify.md

@@ -1,10 +0,0 @@
-# client.worker mtime 증분 추적 — LLM 검증
-
-## 검증 항목
-
-- createSourceFileCachePlugin이 IncrementalMtimeTracker를 사용하는지 확인: `client.worker.ts:198` — `const mtimeTracker = new IncrementalMtimeTracker();` 확인됨
-- onStart에서 detectChanges 결과로 invalidate가 호출되는지 확인: `client.worker.ts:210-213` — `mtimeTracker.detectChanges(watchTargets)` 결과를 `sourceFileCache.invalidate(changedFiles)`에 전달. 기존 로직과 동작 동일
-- onEnd에서 updateMtimes가 호출되는지 확인: `client.worker.ts:228` — `mtimeTracker.updateMtimes(watchTargets)` 호출 확인. `prevMtimes.clear()` + 전체 순회 제거됨
-- esbuildResult == null 가드가 유지되는지 확인: onStart의 `if (esbuildResult != null)` (라인 202), onEnd의 `if (esbuildResult == null) return;` (라인 222) 모두 유지됨
-- isInitialBuild 가드와 sender.send("buildStart")가 유지되는지 확인: `client.worker.ts:216-218` — `if (!isInitialBuild) { sender.send("buildStart", {}); }` 유지됨
-- import 경로에 .js 확장자가 없는지 확인: `client.worker.ts:20` — `from "./incremental-mtime-tracker"` (확장자 없음)

package/tests/workers/client-worker-onend-sync.verify.md

@@ -1,7 +0,0 @@
-# onEnd 비동기 동기화 — LLM 검증
-
-## 검증 항목
-
-- onEnd 타입이 `void | Promise<void>`를 허용: `esbuild-client-config.ts:29` — `onEnd?: (result: esbuild.BuildResult) => void | Promise<void>;`
-- sd-on-end 플러그인이 onEnd 반환값을 return: `esbuild-client-config.ts:220` — `return options.onEnd!(result);`
-- client.worker.ts onEnd가 async 직접 전달 (fire-and-forget 제거): `client.worker.ts:240` — `onEnd: async (result: esbuild.BuildResult) => {` (이전의 `void (async () => { ... })()` 패턴 제거됨)

package/tests/workers/client-worker-refactor.verify.md

@@ -1,22 +0,0 @@
-# client.worker.ts startWatch 서브함수 추출 — LLM 검증
-
-## 검증 항목
-
-- createSourceFileCachePlugin이 모듈 스코프에 존재하고 esbuild.Plugin을 반환한다: lines 192-250, `function createSourceFileCachePlugin(): esbuild.Plugin` 반환 타입 명시, `name: "sd-build-start"` 유지
-- createDevBuildEndHandler가 모듈 스코프에 존재하고 onEnd 콜백을 반환한다: lines 255-322, 반환 타입 `(result: esbuild.BuildResult) => Promise<void>`
-- startWatch에서 추출 함수를 호출한다: line 385 `plugins: [createSourceFileCachePlugin()]`, line 386 `onEnd: createDevBuildEndHandler(basePath, actualPort, outdir, entryNames, info.pkgDir)`
-- 파일 변경 감지 로직이 동일하다: createSourceFileCachePlugin onStart (lines 198-230) — watchFiles + typeScriptFileCache 순회, mtime 비교, invalidate 호출, buildStart 이벤트 전송 모두 원본과 동일
-- mtime 기록 로직이 동일하다: createSourceFileCachePlugin onEnd (lines 232-247) — prevMtimes.clear() + mtime 기록 원본과 동일
-- index.html 재생성 로직이 동일하다: createDevBuildEndHandler (lines 264-279) — lastMetafile 보관 + generateIndexHtml + writeFileSync 원본과 동일
-- HMR 디스패치 로직이 동일하다: lines 281-284, `hmrService.onBuildEnd(result.metafile)` 조건부 호출 원본과 동일
-- build 이벤트 전송 로직이 동일하다: lines 286-300, `sender.send("build", ...)` 조건부 호출 원본과 동일
-- 초기 빌드 resolve 로직이 동일하다: lines 302-312, `isInitialBuild = false` + `initialBuildResolve?.()` 원본과 동일
-- 에러 핸들링 로직이 동일하다: lines 313-320, catch 블록 원본과 동일
-- 외부 인터페이스가 변경되지 않았다: export는 `export default sender`만 존재 (line 501), ClientBuildInfo/ClientBuildResult/ClientWorkerEvents 타입 변경 없음
-- build 함수가 변경되지 않았다: lines 96-187, 원본과 동일
-- stopWatch에 리셋 로직이 추가되었다: lines 472-475, `lastMetafile = undefined`, `isInitialBuild = true`, `initialBuildResolve = undefined`
-- stopWatch 기존 정리 로직이 변경되지 않았다: lines 439-470, 5단계 정리(esbuild dispose, HMR 종료, HTTP 종료, public 감시 종료, index.html 감시 종료) 원본과 동일
-- 모듈 스코프 변수가 올바르게 선언되었다: lines 67-69, 기존 변수(62-66) 바로 아래 배치
-- startWatch가 ~110줄로 축소되었다: lines 327-434 = 107줄 (목표 ~110줄 달성)
-- index.html watcher에서 lastMetafile 접근이 정상 동작한다: line 400, `if (lastMetafile == null) return;` — 모듈 스코프 변수로 접근
-- 기존 테스트 6개 전부 통과: client-worker.spec.ts (3), client-worker.acc.spec.ts (3) — 회귀 없음

package/tests/workers/client-worker-ts-cache-invalidation.verify.md

@@ -1,12 +0,0 @@
-# sd-build-start 플러그인 TypeScript 파일 감시 — LLM 검증
-
-## 검증 항목
-
-- onStart에서 `typeScriptFileCache.keys()`가 watchTargets에 포함: `client.worker.ts:266` — `...typeScriptFileCache.keys()`가 `watchTargets` 배열에 spread되어 포함됨
-- onStart에서 `loadResultCache.watchFiles`도 여전히 watchTargets에 포함: `client.worker.ts:265` — `...loadResultCache.watchFiles`가 첫 번째로 spread됨 (기존 JS 동작 보존)
-- onStart에서 watchTargets의 각 파일에 대해 mtime 비교 수행: `client.worker.ts:268-279` — `for (const file of watchTargets)` 루프에서 `fs.statSync(file).mtimeMs`와 `prevMtimes.get(file)` 비교
-- 초기 빌드 직후 prevMtimes가 비어있으면 mtime 비교 스킵: `client.worker.ts:271-273` — `prev != null` 조건에 의해 `prevMtimes`에 없는 파일은 `changedFiles`에 추가되지 않음
-- onEnd에서 `typeScriptFileCache.keys()`가 prevMtimes 기록 대상에 포함: `client.worker.ts:297` — `...esbuildResult.sourceFileCache.typeScriptFileCache.keys()`가 watchTargets에 spread됨
-- onEnd에서 `loadResultCache.watchFiles`도 여전히 prevMtimes 기록 대상에 포함: `client.worker.ts:296` — `...esbuildResult.sourceFileCache.loadResultCache.watchFiles`가 첫 번째로 spread됨
-- `typeScriptFileCache`가 `sourceFileCache`에서 destructuring으로 접근: `client.worker.ts:260` — `const { loadResultCache, typeScriptFileCache } = esbuildResult.sourceFileCache;` SourceFileCache의 public 속성 (`source-file-cache.js:52`)
-- 삭제된 TS 파일에 대한 catch 처리: `client.worker.ts:275-279` — `catch` 블록에서 `prevMtimes.has(file)`인 경우 `changedFiles`에 추가 (기존 로직 동일)

package/tests/workers/dev-port-file.verify.md

@@ -1,6 +0,0 @@
-# 포트 파일 기록/삭제 — LLM 검증
-
-## 검증 항목
-- client.worker에서 dev 모드 serverReady 후 writeDevPort 호출: `client.worker.ts:250-253` — serverReady(248) 직후 `fs.writeFileSync(path.join(distDir, ".dev-port"), String(actualPort))` 확인
-- client.worker에서 legacy 모드 serverReady 후 writeDevPort 호출: `client.worker.ts:331-332` — serverReady(329) 직후 `fs.writeFileSync(path.join(info.pkgDir, "dist", ".dev-port"), String(serverPort))` 확인
-- ViteEngine.stop()에서 deleteDevPort 호출: `ViteEngine.ts:202-204` — `fs.unlinkSync(portFile)` with try-catch 확인

package/tests/workers/ngtsc-build-rootnames-refresh.verify.md

@@ -1,8 +0,0 @@
-# ngtsc watch rootNames 갱신 — LLM 검증
-
-## 검증 항목
-
-- onChange에서 addOrRemove === true일 때 parseTsconfig + getPackageSourceFiles + pipeline.updateRootNames 호출: `ngtsc-build.worker.ts:299-306` — `if (addOrRemove)` 블록 내에서 `parseTsconfig(watchInfo!.pkgDir)` → `getPackageSourceFiles()` 또는 `getPackageFiles()` → `pipeline.updateRootNames(newSourceFiles)` 호출 체인이 정확히 구현됨
-- includeTests 분기가 초기 설정(line 233-235)과 동일 패턴: 초기 설정 `watchInfo.output.includeTests === true ? getPackageFiles(...) : getPackageSourceFiles(...)` (line 233-235)와 onChange 내 분기 `watchInfo!.output.includeTests === true ? getPackageFiles(...) : getPackageSourceFiles(...)` (line 302-304)가 동일한 패턴을 사용
-- addOrRemove === false일 때 rootNames 미갱신: `if (addOrRemove)` 블록(line 300-306) 내부에서만 rootNames 재스캔이 수행되므로, addOrRemove가 false일 때는 `pipeline.updateRootNames()`가 호출되지 않음. `shouldSkipRebuild`(line 293)에서 `hasAddOrRemove`가 false이고 변경 파일이 lastSourceFilePaths에 있으면 정상적으로 `pipeline.update(modifiedFiles)`만 실행됨
-- rootNames 재스캔이 shouldSkipRebuild 이후 + pipeline.update() 이전에 위치: line 293에서 shouldSkipRebuild 체크 → line 299에서 rootNames 재스캔 → line 310에서 pipeline.update(). 올바른 순서

package/tests/workers/server-build-context-dispose.verify.md

@@ -1,8 +0,0 @@
-# esbuild context dispose 안전성 -- LLM 검증
-
-## 검증 항목
-
-- try-finally 패턴 적용: `server-build.worker.ts:434-442` — oldContext 캡처 후 try 블록에서 새 context 생성, finally에서 oldContext.dispose() 호출
-- 성공 시 dispose: try 블록에서 새 context 생성 성공 → finally에서 oldContext.dispose() 실행
-- 실패 시 dispose: createEsbuildWatchContext() 예외 시 → finally에서 oldContext.dispose() 실행 보장
-- null 안전: `if (oldContext != null)` 가드로 oldContext가 없는 경우(output.js=false 등) 안전

package/tests/workers/server-build-worker-plugin.verify.md

@@ -1,9 +0,0 @@
-# Feature 1.3 서버 빌드에 Worker 플러그인 적용 — LLM 검증
-
-## 검증 항목
-
-- 프로덕션 빌드에 Worker 플러그인 포함: `server-build.worker.ts:169`에서 `plugins: [createWorkerBundlePlugin(), tscPlugin.plugin]`로 설정됨. Worker 플러그인이 tsc 플러그인보다 앞에 위치.
-- Watch/dev 빌드에 Worker 플러그인 포함: `server-esbuild-context.ts:66-69`에서 `workerPlugin` 변수로 생성 후 tsc 유무에 따라 `[workerPlugin, tscPlugin.plugin]` 또는 `[workerPlugin]`으로 설정됨.
-- Worker 패턴 없는 서버 코드 투명 통과: `esbuild-worker-plugin.ts:83-85`에서 `content.includes("Worker")`가 false면 즉시 `undefined` 반환. `esbuild-worker-plugin.ts:197`의 onLoad에서 `result == null`이면 `undefined` 반환하여 다음 핸들러에 위임.
-- 기존 tsc 플러그인/external 처리 미변경: `createServerEsbuildOptions` 함수 미수정. tsc 플러그인 생성 로직 미변경. external 처리 미변경.
-- import 경로에 `.js` 확장자 미사용: 두 파일 모두 `from "../esbuild/esbuild-worker-plugin"` (확장자 없음)

package/tests/workers/server-build-worker-refactoring.verify.md

@@ -1,14 +0,0 @@
-# server-build.worker.ts 리팩토링 — LLM 검증
-
-## 검증 항목
-
-- rebuildAll()이 startWatch() 내부 클로저로 정의: `server-build.worker.ts:272` — startWatch (`:259`) 내부에 `async function rebuildAll()` 정의 확인
-- lastBuilderProgram이 startWatch 로컬 변수: `server-build.worker.ts:264` — `let lastBuilderProgram` startWatch 함수 스코프 내 정의 확인
-- watchLintRunner가 startWatch 로컬 변수: `server-build.worker.ts:265` — `let watchLintRunner` startWatch 함수 스코프 내 정의 확인
-- watchInfo 모듈 스코프 변수 제거: 모듈 스코프에 `watchInfo` 선언 없음 확인, startWatch의 `info` 파라미터를 직접 사용
-- cleanup()에서 lastBuilderProgram 참조 제거: `server-build.worker.ts:108-123` — cleanup 함수에 lastBuilderProgram 참조 없음 확인
-- startWatch에서 createContext에 tsc 옵션 전달: `server-build.worker.ts:348-359` — `tsc: { cwd, output: { dts }, env, includeTests }` 옵션 포함 확인
-- build() js=true에서 createTscPlugin 로컬 생성: `server-build.worker.ts:153-159` — build 함수 내 `const tscPlugin = createTscPlugin({...})` 확인
-- build() js=false에서 runTscPackageBuild 직접 호출: `server-build.worker.ts:192-199` — `runTscPackageBuild({...})` 직접 호출 확인
-- 외부 인터페이스(ServerBuildInfo/WatchInfo/Result/WorkerEvents) 변경 없음: 타입 정의 `:33-96` 변경 없음 확인
-- runTscPackageBuild import 유지: `server-build.worker.ts:19` — import 존재 확인 (js=false fallback용)

package/tests/workers/server-esbuild-context-integration.verify.md

@@ -1,10 +0,0 @@
-# rebuildAll이 esbuild context 모듈의 rebuild 사용 — LLM 검증
-
-## 검증 항목
-
-- rebuildAll()이 esbuildCtx.rebuild()를 호출한다: `server-build.worker.ts` line 252에서 `const esbuildPromise = info.output.js ? esbuildCtx.rebuild() : null;` 확인. 기존 inline esbuild.rebuild() 호출이 모듈 함수로 대체됨.
-- rebuild() 결과의 null 처리: line 301에서 `(await esbuildPromise) ?? { success: true, ... }` — esbuildCtx.rebuild()가 null 반환 시 (context 없음) 기본 성공 결과로 폴백.
-- cleanup()이 esbuildCtx.dispose()를 호출한다: `server-build.worker.ts` line 104에서 `await esbuildCtx.dispose();` 확인. 기존 inline context dispose가 모듈 함수로 대체됨.
-- startWatch()가 esbuildCtx.createContext()를 호출한다: line 345에서 `await esbuildCtx.createContext({...})` 확인. 기존 createEsbuildWatchContext 로컬 함수가 제거됨.
-- onChange의 context 재생성이 esbuildCtx.recreateContext()를 사용한다: line 395에서 `await esbuildCtx.recreateContext({...})` 확인. LOGIC-001 패턴이 모듈 내부로 캡슐화됨.
-- metafile 필터링이 esbuildCtx.getMetafile()/hasContext()를 사용한다: lines 408, 414에서 `esbuildCtx.hasContext()`, `esbuildCtx.getMetafile()` 확인.

package/tests/workers/server-esbuild-context-tsc.verify.md

@@ -1,7 +0,0 @@
-# server-esbuild-context tsc 통합 — LLM 검증
-
-## 검증 항목
-
-- `EsbuildContextOptions.tsc`가 optional이므로 `server-watch-manager.ts:66-71`의 기존 `recreateContext()` 호출이 타입 에러 없이 동작: 확인 — `tsc` 미전달 시 기존 플러그인 재사용 로직 정상
-- `server-watch-manager.spec.ts` 8개 테스트 전부 통과: 확인 — 회귀 없음
-- `server-watch-manager.ts`에 코드 변경 없음: 확인 — 파일 미수정