@simplysm/sd-cli 14.0.47 → 14.0.49

package/tests/sd-cli-catch-all.verify.md

@@ -2,6 +2,6 @@
 
 ## 검증 항목
 
-- [x] catch 블록이 에러 코드를 확인하여 MODULE_NOT_FOUND/ERR_MODULE_NOT_FOUND만 무시: `sd-cli.ts:37-41` 확인 완료. `code` 프로퍼티를 체크하고 해당 코드가 아닌 경우 `console.warn`으로 경고 출력
-- [x] 예상 외 에러(SyntaxError 등)에 경고 로그 출력: `console.warn("[sd-cli] replaceDeps 사전 설정 실패:", ...)` 확인
-- [x] Phase 2로 정상 진행: catch 후 코드 흐름이 Phase 2(line 44~)로 계속됨 확인
+- catch 블록이 에러 코드를 확인하여 MODULE_NOT_FOUND/ERR_MODULE_NOT_FOUND만 무시: `sd-cli.ts:37-41` 확인 완료. `code` 프로퍼티를 체크하고 해당 코드가 아닌 경우 `console.warn`으로 경고 출력
+- 예상 외 에러(SyntaxError 등)에 경고 로그 출력: `console.warn("[sd-cli] replaceDeps 사전 설정 실패:", ...)` 확인
+- Phase 2로 정상 진행: catch 후 코드 흐름이 Phase 2(line 44~)로 계속됨 확인

package/tests/sd-cli-log-tag.verify.md

@@ -2,10 +2,10 @@
 
 ## 검증 항목
 
-- [x] sd-cli.ts에 `consola.withTag("sd:cli")` 모듈-레벨 로거가 생성됨: `src/sd-cli.ts:18` — `const logger = consola.withTag("sd:cli");`
-- [x] sd-cli.ts replaceDeps 경고에서 수동 `[sd-cli]` prefix가 제거됨: `src/sd-cli.ts:43` — `logger.warn("replaceDeps 사전 설정 실패:", ...)` (이전: `consola.warn("[sd-cli] replaceDeps ..."`)
-- [x] sd-cli.ts CPU affinity 경고가 consola로 전환됨: `src/sd-cli.ts:104-108` — `logger.warn("CPU affinity/priority 설정 실패:", ...)` (이전: `console.warn("Failed to configure ..."`)
-- [x] sd-cli.ts에서 `eslint-disable-next-line no-console` 주석이 제거됨: `src/sd-cli.ts:104` 부근에 해당 주석 없음
-- [x] sd-cli-entry.ts에 `consola.withTag("sd:cli:entry")` 모듈-레벨 로거가 생성됨: `src/sd-cli-entry.ts:20` — `const logger = consola.withTag("sd:cli:entry");`
-- [x] sd-cli-entry.ts .fail() 핸들러가 태그 로거를 사용함: `src/sd-cli-entry.ts:329` — `logger.error(msg);` (이전: `consola.error(msg)`)
-- [x] sd-cli-entry.ts의 `/* eslint-disable no-console */`이 유지됨: `src/sd-cli-entry.ts:1` — `collectYargsHelp`의 `console.log` 사용 때문에 필요
+- sd-cli.ts에 `consola.withTag("sd:cli")` 모듈-레벨 로거가 생성됨: `src/sd-cli.ts:18` — `const logger = consola.withTag("sd:cli");`
+- sd-cli.ts replaceDeps 경고에서 수동 `[sd-cli]` prefix가 제거됨: `src/sd-cli.ts:43` — `logger.warn("replaceDeps 사전 설정 실패:", ...)` (이전: `consola.warn("[sd-cli] replaceDeps ..."`)
+- sd-cli.ts CPU affinity 경고가 consola로 전환됨: `src/sd-cli.ts:104-108` — `logger.warn("CPU affinity/priority 설정 실패:", ...)` (이전: `console.warn("Failed to configure ..."`)
+- sd-cli.ts에서 `eslint-disable-next-line no-console` 주석이 제거됨: `src/sd-cli.ts:104` 부근에 해당 주석 없음
+- sd-cli-entry.ts에 `consola.withTag("sd:cli:entry")` 모듈-레벨 로거가 생성됨: `src/sd-cli-entry.ts:20` — `const logger = consola.withTag("sd:cli:entry");`
+- sd-cli-entry.ts .fail() 핸들러가 태그 로거를 사용함: `src/sd-cli-entry.ts:329` — `logger.error(msg);` (이전: `consola.error(msg)`)
+- sd-cli-entry.ts의 `/* eslint-disable no-console */`이 유지됨: `src/sd-cli-entry.ts:1` — `collectYargsHelp`의 `console.log` 사용 때문에 필요

package/tests/ts-compiler/SdTsCompiler-affected-files.verify.md

@@ -2,7 +2,7 @@
 
 ## 검증 항목
 
-- [x] Non-Angular 전역 변경 시 affectedFiles=undefined: `_findAffectedFilesForTsc`에서 `result.affected`가 `ts.SourceFile`이 아닌 경우(`"fileName" in result.affected` 실패) `return undefined`를 반환. (`SdTsCompiler.ts:272-275`)
-- [x] Angular TypeScript 5.9 크래시 방어: `_findAffectedFilesForAngular`에서 `getSemanticDiagnosticsOfNextAffectedFile`를 try-catch로 감싸고, catch 시 전체 소스를 affected로 처리 (`SdTsCompiler.ts:290-298`)
-- [x] Angular 리소스 의존성 기반 추가 affected: `_findAffectedFilesForAngular`에서 `sourceFileCache.modifiedFiles`와 `angularCompiler.getResourceDependencies(sourceFile)`를 비교하여 매칭 시 `_diagnosticCache.delete(sourceFile)` + `affectedSourceFiles.add(sourceFile)` (`SdTsCompiler.ts:317-334`)
-- [x] Angular .ngtypecheck.ts → 원본 .ts 매핑: `getSemanticDiagnosticsOfNextAffectedFile`의 두 번째 인자 콜백에서 `.ngtypecheck.ts` 파일을 원본 `.ts`로 매핑하여 affected에 추가 (`SdTsCompiler.ts:284-295`)
+- Non-Angular 전역 변경 시 affectedFiles=undefined: `_findAffectedFilesForTsc`에서 `result.affected`가 `ts.SourceFile`이 아닌 경우(`"fileName" in result.affected` 실패) `return undefined`를 반환. (`SdTsCompiler.ts:272-275`)
+- Angular TypeScript 5.9 크래시 방어: `_findAffectedFilesForAngular`에서 `getSemanticDiagnosticsOfNextAffectedFile`를 try-catch로 감싸고, catch 시 전체 소스를 affected로 처리 (`SdTsCompiler.ts:290-298`)
+- Angular 리소스 의존성 기반 추가 affected: `_findAffectedFilesForAngular`에서 `sourceFileCache.modifiedFiles`와 `angularCompiler.getResourceDependencies(sourceFile)`를 비교하여 매칭 시 `_diagnosticCache.delete(sourceFile)` + `affectedSourceFiles.add(sourceFile)` (`SdTsCompiler.ts:317-334`)
+- Angular .ngtypecheck.ts → 원본 .ts 매핑: `getSemanticDiagnosticsOfNextAffectedFile`의 두 번째 인자 콜백에서 `.ngtypecheck.ts` 파일을 원본 `.ts`로 매핑하여 affected에 추가 (`SdTsCompiler.ts:284-295`)

package/tests/ts-compiler/SdTsCompiler-diagnostics.verify.md

@@ -2,11 +2,11 @@
 
 ## 검증 항목
 
-- [x] Angular TS 5.9 getSemanticDiagnostics 크래시 방어: `_collectDiagnosticsForAngular`에서 `builderProgram.getSemanticDiagnostics(sourceFile)`를 try-catch로 감싸고, catch 시 빈 배열로 처리 (`SdTsCompiler.ts` `_collectDiagnosticsForAngular` 메서드 내 per-file 루프)
-- [x] Angular diagnosticCache 갱신: affected 파일이면 `getDiagnosticsForFile` 호출 후 `this._diagnosticCache.set(sourceFile, angularDiagnostics)` 수행 (`SdTsCompiler.ts` `_collectDiagnosticsForAngular` 메서드)
-- [x] Angular diagnosticCache 반환: 비-affected 파일이면 `this._diagnosticCache.get(sourceFile)` 캐시 결과 반환 (`SdTsCompiler.ts` `_collectDiagnosticsForAngular` 메서드)
-- [x] Angular ignoreForDiagnostics 건너뜀: per-file 루프에서 `angularCompiler.ignoreForDiagnostics.has(sourceFile)` 체크 후 continue
-- [x] Non-Angular 7종 진단 수집: `_collectDiagnosticsForTsc`에서 config + syntactic + options + global + semantic + declaration 진단 수집 (declaration은 `!output.dts` 조건)
-- [x] isWorkspaceDiagnostic 필터링: `_finalizeDiagnostics`에서 `rawDiagnostics.filter(d => isWorkspaceDiagnostic(d, this._options.cwd))` 적용
-- [x] serializeDiagnostic 직렬화: `_finalizeDiagnostics`에서 `filtered.map(serializeDiagnostic)` 적용
-- [x] formatDiagnosticError 포맷: `_finalizeDiagnostics`에서 Error 카테고리 진단을 `formatDiagnosticError`로 포맷하여 `errors` 배열 생성
+- Angular TS 5.9 getSemanticDiagnostics 크래시 방어: `_collectDiagnosticsForAngular`에서 `builderProgram.getSemanticDiagnostics(sourceFile)`를 try-catch로 감싸고, catch 시 빈 배열로 처리 (`SdTsCompiler.ts` `_collectDiagnosticsForAngular` 메서드 내 per-file 루프)
+- Angular diagnosticCache 갱신: affected 파일이면 `getDiagnosticsForFile` 호출 후 `this._diagnosticCache.set(sourceFile, angularDiagnostics)` 수행 (`SdTsCompiler.ts` `_collectDiagnosticsForAngular` 메서드)
+- Angular diagnosticCache 반환: 비-affected 파일이면 `this._diagnosticCache.get(sourceFile)` 캐시 결과 반환 (`SdTsCompiler.ts` `_collectDiagnosticsForAngular` 메서드)
+- Angular ignoreForDiagnostics 건너뜀: per-file 루프에서 `angularCompiler.ignoreForDiagnostics.has(sourceFile)` 체크 후 continue
+- Non-Angular 7종 진단 수집: `_collectDiagnosticsForTsc`에서 config + syntactic + options + global + semantic + declaration 진단 수집 (declaration은 `!output.dts` 조건)
+- isWorkspaceDiagnostic 필터링: `_finalizeDiagnostics`에서 `rawDiagnostics.filter(d => isWorkspaceDiagnostic(d, this._options.cwd))` 적용
+- serializeDiagnostic 직렬화: `_finalizeDiagnostics`에서 `filtered.map(serializeDiagnostic)` 적용
+- formatDiagnosticError 포맷: `_finalizeDiagnostics`에서 Error 카테고리 진단을 `formatDiagnosticError`로 포맷하여 `errors` 배열 생성

package/tests/ts-compiler/SdTsCompiler-emit.verify.md

@@ -2,8 +2,8 @@
 
 ## 검증 항목
 
-- [x] Angular emit — additionalTransformers 병합: `_emitAngular`에서 `emitOptions?.additionalTransformers`의 before/after를 `angularCompiler.prepareEmit().transformers`에 push 병합 (`SdTsCompiler.ts` `_emitAngular` 메서드)
-- [x] Angular emit — tsbuildinfo 영속화 크래시 방어: `builderProgram.emit(undefined, () => {})` 호출이 try-catch로 감싸져 있음 (`SdTsCompiler.ts` `_emitAngular` 메서드 하단)
-- [x] Angular emit — sourceFilter 적용: emitResults를 `emitOptions.sourceFilter`로 필터링하여 반환 (`SdTsCompiler.ts` `_emitAngular` 메서드 마지막)
-- [x] Angular emit — incrementalCompilation.recordSuccessfulEmit 호출: writeFileCallback에서 각 sourceFile에 대해 호출됨
-- [x] Angular emit — ignoreForEmit/isDeclarationFile/safeToSkipEmit 건너뜀: per-file emit 루프에서 세 조건 모두 continue 처리
+- Angular emit — additionalTransformers 병합: `_emitAngular`에서 `emitOptions?.additionalTransformers`의 before/after를 `angularCompiler.prepareEmit().transformers`에 push 병합 (`SdTsCompiler.ts` `_emitAngular` 메서드)
+- Angular emit — tsbuildinfo 영속화 크래시 방어: `builderProgram.emit(undefined, () => {})` 호출이 try-catch로 감싸져 있음 (`SdTsCompiler.ts` `_emitAngular` 메서드 하단)
+- Angular emit — sourceFilter 적용: emitResults를 `emitOptions.sourceFilter`로 필터링하여 반환 (`SdTsCompiler.ts` `_emitAngular` 메서드 마지막)
+- Angular emit — incrementalCompilation.recordSuccessfulEmit 호출: writeFileCallback에서 각 sourceFile에 대해 호출됨
+- Angular emit — ignoreForEmit/isDeclarationFile/safeToSkipEmit 건너뜀: per-file emit 루프에서 세 조건 모두 continue 처리

package/tests/ts-compiler/SdTsCompiler.verify.md

@@ -4,38 +4,38 @@
 
 ### Angular host 확장 (Slice 2)
 
-- [x] **readResource 콜백 등록**: `SdTsCompiler.ts:268` — `hostAny["readResource"]`가 `host.readFile` 위임. `angular-compiler.ts:181-183`의 패턴과 동일 확인
-- [x] **transformResource 콜백 등록**: `SdTsCompiler.ts:271-286` — `transformStylesheet` 옵션이 있을 때만 등록. context.type !== "style" 시 null 반환, 빈 데이터 시 `{ content: "" }` 반환. `angular-compiler.ts:186-203`의 패턴과 동일
-- [x] **getModifiedResourceFiles 콜백**: `SdTsCompiler.ts:289-292` — `sourceFileCache`가 있을 때만 등록, `cache.modifiedFiles` 반환. `angular-compiler.ts:206-208`의 패턴과 동일
-- [x] **resourceNameToFileName 콜백**: `SdTsCompiler.ts:295-312` — 경로 해석 + `externalStylesheets` 처리 + `hasTemplateExtension` 분기. `angular-compiler.ts:210-228`의 패턴과 동일
+- **readResource 콜백 등록**: `SdTsCompiler.ts:268` — `hostAny["readResource"]`가 `host.readFile` 위임. `angular-compiler.ts:181-183`의 패턴과 동일 확인
+- **transformResource 콜백 등록**: `SdTsCompiler.ts:271-286` — `transformStylesheet` 옵션이 있을 때만 등록. context.type !== "style" 시 null 반환, 빈 데이터 시 `{ content: "" }` 반환. `angular-compiler.ts:186-203`의 패턴과 동일
+- **getModifiedResourceFiles 콜백**: `SdTsCompiler.ts:289-292` — `sourceFileCache`가 있을 때만 등록, `cache.modifiedFiles` 반환. `angular-compiler.ts:206-208`의 패턴과 동일
+- **resourceNameToFileName 콜백**: `SdTsCompiler.ts:295-312` — 경로 해석 + `externalStylesheets` 처리 + `hasTemplateExtension` 분기. `angular-compiler.ts:210-228`의 패턴과 동일
 
 ### moduleResolutionCache 재사용 (Slice 2)
 
-- [x] **초기 생성**: `SdTsCompiler.ts:252-253` — `ts.createModuleResolutionCache(cwd, canonicalize, options, this._packageJsonCache)` 호출. 4번째 인자로 `this._packageJsonCache` 전달
-- [x] **packageJsonCache 추출**: `SdTsCompiler.ts:256-258` — 첫 호출 시 `moduleResolutionCache.getPackageJsonInfoCache()`로 추출하여 `_packageJsonCache`에 저장
-- [x] **후속 호출 시 재사용**: 두 번째 `compileAsync` 호출 시 `this._packageJsonCache`가 null이 아니므로 `createModuleResolutionCache`의 4번째 인자로 전달됨 → 패키지 해석 결과 재사용
+- **초기 생성**: `SdTsCompiler.ts:252-253` — `ts.createModuleResolutionCache(cwd, canonicalize, options, this._packageJsonCache)` 호출. 4번째 인자로 `this._packageJsonCache` 전달
+- **packageJsonCache 추출**: `SdTsCompiler.ts:256-258` — 첫 호출 시 `moduleResolutionCache.getPackageJsonInfoCache()`로 추출하여 `_packageJsonCache`에 저장
+- **후속 호출 시 재사용**: 두 번째 `compileAsync` 호출 시 `this._packageJsonCache`가 null이 아니므로 `createModuleResolutionCache`의 4번째 인자로 전달됨 → 패키지 해석 결과 재사용
 
 ### sourceFileCache 관리 (Slice 2-3)
 
-- [x] **외부 제공 시 사용**: `SdTsCompiler.ts:117` — `this._options.sourceFileCache ?? new AngularSourceFileCache()` 패턴으로 외부 제공 시 우선 사용
-- [x] **미제공 시 내부 생성**: 위 라인에서 `??` 연산자로 `AngularSourceFileCache` 내부 생성
-- [x] **augmentHostWithCaching 적용**: `SdTsCompiler.ts:118` — Angular 프로그램 생성 직전에 `augmentHostWithCaching(host, this._sourceFileCache)` 호출
-- [x] **증분 빌드 시 무효화**: `SdTsCompiler.ts:74-76` — `modifiedFiles != null && size > 0 && _sourceFileCache != null` 조건으로 `sourceFileCache.invalidate(modifiedFiles)` 호출
+- **외부 제공 시 사용**: `SdTsCompiler.ts:117` — `this._options.sourceFileCache ?? new AngularSourceFileCache()` 패턴으로 외부 제공 시 우선 사용
+- **미제공 시 내부 생성**: 위 라인에서 `??` 연산자로 `AngularSourceFileCache` 내부 생성
+- **augmentHostWithCaching 적용**: `SdTsCompiler.ts:118` — Angular 프로그램 생성 직전에 `augmentHostWithCaching(host, this._sourceFileCache)` 호출
+- **증분 빌드 시 무효화**: `SdTsCompiler.ts:74-76` — `modifiedFiles != null && size > 0 && _sourceFileCache != null` 조건으로 `sourceFileCache.invalidate(modifiedFiles)` 호출
 
 ### Non-Angular writeFile 훅 (Slice 2)
 
-- [x] **emit 모드에서만 설정**: `SdTsCompiler.ts:238` — `!isForAngular && needsEmit` 조건으로 writeFile 훅 적용
-- [x] **createOutputPathRewriter 사용**: `SdTsCompiler.ts:239` — `createOutputPathRewriter(pkgDir)` 호출
-- [x] **addJsExtensionToImports 적용**: `SdTsCompiler.ts:243` — `.js` 파일에만 `addJsExtensionToImports` 적용
-- [x] **result null 시 쓰기 스킵**: `SdTsCompiler.ts:241` — `result != null` 체크로 다른 패키지 출력 무시
+- **emit 모드에서만 설정**: `SdTsCompiler.ts:238` — `!isForAngular && needsEmit` 조건으로 writeFile 훅 적용
+- **createOutputPathRewriter 사용**: `SdTsCompiler.ts:239` — `createOutputPathRewriter(pkgDir)` 호출
+- **addJsExtensionToImports 적용**: `SdTsCompiler.ts:243` — `.js` 파일에만 `addJsExtensionToImports` 적용
+- **result null 시 쓰기 스킵**: `SdTsCompiler.ts:241` — `result != null` 체크로 다른 패키지 출력 무시
 
 ### compilerOptions 구성 순서 (Slice 1)
 
-- [x] **순서 확인**: `SdTsCompiler.ts:170-225` — env 조정(171) → output 플래그(175-202) → angular 병합(205) → tsBuildInfoFile(210) → transformer(221) 순서 확인
+- **순서 확인**: `SdTsCompiler.ts:170-225` — env 조정(171) → output 플래그(175-202) → angular 병합(205) → tsBuildInfoFile(210) → transformer(221) 순서 확인
 
 ### Program 생성 분기 (Slice 3)
 
-- [x] **Non-Angular**: `SdTsCompiler.ts:138-142` — `createEmitAndSemanticDiagnosticsBuilderProgram(rootNames, options, host, oldBuilderProgram)` 4인자 오버로드
-- [x] **Angular**: `SdTsCompiler.ts:120-135` — NgtscProgram → getTsProgram → ensureSourceFileVersions → createEmitAndSemanticDiagnosticsBuilderProgram(tsProgram, host, old) → analyzeAsync
-- [x] **증분 빌드 상태**: `SdTsCompiler.ts:145` — `this._builderProgram = builderProgram` 저장. 다음 호출 시 `this._builderProgram`이 old로 전달됨
-- [x] **Angular 증분**: `SdTsCompiler.ts:123` — `this._ngtscProgram`을 NgtscProgram 4번째 인자로 전달. `SdTsCompiler.ts:136` — `this._ngtscProgram = angularProgram` 저장
+- **Non-Angular**: `SdTsCompiler.ts:138-142` — `createEmitAndSemanticDiagnosticsBuilderProgram(rootNames, options, host, oldBuilderProgram)` 4인자 오버로드
+- **Angular**: `SdTsCompiler.ts:120-135` — NgtscProgram → getTsProgram → ensureSourceFileVersions → createEmitAndSemanticDiagnosticsBuilderProgram(tsProgram, host, old) → analyzeAsync
+- **증분 빌드 상태**: `SdTsCompiler.ts:145` — `this._builderProgram = builderProgram` 저장. 다음 호출 시 `this._builderProgram`이 old로 전달됨
+- **Angular 증분**: `SdTsCompiler.ts:123` — `this._ngtscProgram`을 NgtscProgram 4번째 인자로 전달. `SdTsCompiler.ts:136` — `this._ngtscProgram = angularProgram` 저장

package/tests/ts-compiler/scss-lint-integration.verify.md

@@ -2,13 +2,13 @@
 
 ## 검증 항목
 
-- [x] transformResource 콜백 연결: `SdTsCompiler.ts:_extendHostForAngular()`에서 `effectiveTransformStylesheet` 매개변수로 전달받아 `hostAny["transformResource"]`에 등록 확인 (SdTsCompiler.ts:553-579)
-- [x] 라이브러리 SCSS 콜백 자동 생성 조건: `isForAngular && effectiveTransformStylesheet == null` 분기 (SdTsCompiler.ts:163-172) — transformStylesheet 제공 시 그대로 사용, 미제공 시 createLibraryTransformStylesheet 생성
-- [x] SCSS 상태 리셋 위치: compileAsync 내 program 생성 전에 `_scssErrors.length = 0`, `_scssDependencies.clear()` 호출 (SdTsCompiler.ts:158-160)
-- [x] createLibraryTransformStylesheet 이동: ngtsc-build-core.ts에 정의, angular-build-pipeline.ts에서 import 변경 확인 — `compileScssString` import 추가됨
-- [x] sideEffectScssRegistry getter: public getter로 외부 접근 가능 (SdTsCompiler.ts:83-86)
-- [x] compileSideEffectScss: 내부 _scssErrors와 _scssDependencies에 에러/의존성 기록 (SdTsCompiler.ts:89-98)
-- [x] _runLint: LintWithProgramRunner 인스턴스 lazy init + 재사용 (SdTsCompiler.ts:_lintRunner 필드, _runLint 메서드)
-- [x] lint + globalScss 병렬: Promise.all로 동시 실행 (SdTsCompiler.ts:271-283)
-- [x] ISdTsCompilerResult 타입: lint?, scssErrors, scssDependencies 필드 추가 (sd-ts-compiler-result.ts:17-21)
-- [x] ISdTsCompilerOptions 타입: lint?, globalScss? 필드 추가 (sd-ts-compiler-options.ts:41-45)
+- transformResource 콜백 연결: `SdTsCompiler.ts:_extendHostForAngular()`에서 `effectiveTransformStylesheet` 매개변수로 전달받아 `hostAny["transformResource"]`에 등록 확인 (SdTsCompiler.ts:553-579)
+- 라이브러리 SCSS 콜백 자동 생성 조건: `isForAngular && effectiveTransformStylesheet == null` 분기 (SdTsCompiler.ts:163-172) — transformStylesheet 제공 시 그대로 사용, 미제공 시 createLibraryTransformStylesheet 생성
+- SCSS 상태 리셋 위치: compileAsync 내 program 생성 전에 `_scssErrors.length = 0`, `_scssDependencies.clear()` 호출 (SdTsCompiler.ts:158-160)
+- createLibraryTransformStylesheet 이동: ngtsc-build-core.ts에 정의, angular-build-pipeline.ts에서 import 변경 확인 — `compileScssString` import 추가됨
+- sideEffectScssRegistry getter: public getter로 외부 접근 가능 (SdTsCompiler.ts:83-86)
+- compileSideEffectScss: 내부 _scssErrors와 _scssDependencies에 에러/의존성 기록 (SdTsCompiler.ts:89-98)
+- _runLint: LintWithProgramRunner 인스턴스 lazy init + 재사용 (SdTsCompiler.ts:_lintRunner 필드, _runLint 메서드)
+- lint + globalScss 병렬: Promise.all로 동시 실행 (SdTsCompiler.ts:271-283)
+- ISdTsCompilerResult 타입: lint?, scssErrors, scssDependencies 필드 추가 (sd-ts-compiler-result.ts:17-21)
+- ISdTsCompilerOptions 타입: lint?, globalScss? 필드 추가 (sd-ts-compiler-options.ts:41-45)

package/tests/utils/copy-public-outdir.verify.md

@@ -2,7 +2,7 @@
 
 ## 검증 항목
 
-- [x] `client.worker.ts:164`에서 `writeConfigJson(outdir, ...)` 사용 확인 — `writeConfigJson(outdir, info.configs)` (기존 `path.join(info.pkgDir, "dist")` 제거됨)
-- [x] `client.worker.ts:102`에서 `copyPublicFiles(info.pkgDir, false, outdir)` 전달 확인 — `outdir` 변수는 line 99에서 `info.outDir ?? path.join(info.pkgDir, "dist")`로 계산됨
-- [x] `server-build.worker.ts`의 호출이 변경되지 않음 확인 — line 225: `copyPublicFiles(info.pkgDir, false)`, line 374: `watchPublicFiles(info.pkgDir, true)` (2인자 호출 유지)
-- [x] `copy-public.ts`의 `watchPublicFiles` 내부 `copyPublicFiles` 호출에 `outDir` 전달 확인 — line 67: `await copyPublicFiles(pkgDir, includeDev, outDir)`
+- `client.worker.ts:164`에서 `writeConfigJson(outdir, ...)` 사용 확인 — `writeConfigJson(outdir, info.configs)` (기존 `path.join(info.pkgDir, "dist")` 제거됨)
+- `client.worker.ts:102`에서 `copyPublicFiles(info.pkgDir, false, outdir)` 전달 확인 — `outdir` 변수는 line 99에서 `info.outDir ?? path.join(info.pkgDir, "dist")`로 계산됨
+- `server-build.worker.ts`의 호출이 변경되지 않음 확인 — line 225: `copyPublicFiles(info.pkgDir, false)`, line 374: `watchPublicFiles(info.pkgDir, true)` (2인자 호출 유지)
+- `copy-public.ts`의 `watchPublicFiles` 내부 `copyPublicFiles` 호출에 `outDir` 전달 확인 — line 67: `await copyPublicFiles(pkgDir, includeDev, outDir)`

package/tests/utils/dev-http-server.verify.md

@@ -2,7 +2,7 @@
 
 ## 검증 항목
 
-- [x] `.dev-port` 파일 기록 패턴 유지: 기존 `client.worker.ts:246,319`에서 `fs.writeFileSync(path.join(distDir, ".dev-port"), String(port))` 패턴을 사용 중이며, 이 패턴은 호출자(worker/engine)에서 동일하게 사용 가능. `createDevHttpServer`의 `listen()` 반환값(port)을 사용하여 기록 가능.
-- [x] `.config.json` 기록 패턴 유지: 기존 `client.worker.ts:439-448`의 `writeConfigJson` 함수가 `fs.mkdirSync + fs.writeFileSync(JSON.stringify)` 패턴으로 구현되어 있으며, Feature 3.1(EsbuildClientEngine)에서 동일하게 호출 가능.
-- [x] configs 미설정 시 빈 객체: 기존 `writeConfigJson`에서 `configs ?? {}`로 처리 (`client.worker.ts:445`). 이 패턴은 호출자가 그대로 유지.
-- [x] 파일 기록 책임 분리: `createDevHttpServer`는 HTTP 서빙에만 집중하고, `.dev-port`/`.config.json` 기록은 호출자 책임 (설계 결정 D3 준수).
+- `.dev-port` 파일 기록 패턴 유지: 기존 `client.worker.ts:246,319`에서 `fs.writeFileSync(path.join(distDir, ".dev-port"), String(port))` 패턴을 사용 중이며, 이 패턴은 호출자(worker/engine)에서 동일하게 사용 가능. `createDevHttpServer`의 `listen()` 반환값(port)을 사용하여 기록 가능.
+- `.config.json` 기록 패턴 유지: 기존 `client.worker.ts:439-448`의 `writeConfigJson` 함수가 `fs.mkdirSync + fs.writeFileSync(JSON.stringify)` 패턴으로 구현되어 있으며, Feature 3.1(EsbuildClientEngine)에서 동일하게 호출 가능.
+- configs 미설정 시 빈 객체: 기존 `writeConfigJson`에서 `configs ?? {}`로 처리 (`client.worker.ts:445`). 이 패턴은 호출자가 그대로 유지.
+- 파일 기록 책임 분리: `createDevHttpServer`는 HTTP 서빙에만 집중하고, `.dev-port`/`.config.json` 기록은 호출자 책임 (설계 결정 D3 준수).

package/tests/utils/engine-watch-events.verify.md

@@ -4,14 +4,14 @@
 
 ### Slice 1: BaseEngine 적용
 
-- [x] BaseEngine lint 결과 보고 유지: `BaseEngine.ts:148-157` — build 이벤트에서 `event.lint`가 있으면 lint BuildResult를 ResultCollector에 추가. 기존 로직 그대로 유지됨.
-- [x] BaseEngine 경고 로깅 유지: `BaseEngine.ts:144-146` — `event.build.warnings`가 있으면 `logger.warn` 호출. 기존 로직 그대로 유지됨.
-- [x] setupWatchEvents가 index.ts의 public export에 포함되지 않음: 내부 유틸리티이므로 패키지 외부 API 불변. `engines/index.ts`의 export 목록에 engine-watch-events 없음 확인.
-- [x] resolveInitialBuild가 _callStartWatch catch에서 호출됨: `BaseEngine.ts:162-164` — `this._callStartWatch(output).catch(() => { resolveInitialBuild(); })`. 기존의 `isInitialBuild` 가드와 동등한 동작.
+- BaseEngine lint 결과 보고 유지: `BaseEngine.ts:148-157` — build 이벤트에서 `event.lint`가 있으면 lint BuildResult를 ResultCollector에 추가. 기존 로직 그대로 유지됨.
+- BaseEngine 경고 로깅 유지: `BaseEngine.ts:144-146` — `event.build.warnings`가 있으면 `logger.warn` 호출. 기존 로직 그대로 유지됨.
+- setupWatchEvents가 index.ts의 public export에 포함되지 않음: 내부 유틸리티이므로 패키지 외부 API 불변. `engines/index.ts`의 export 목록에 engine-watch-events 없음 확인.
+- resolveInitialBuild가 _callStartWatch catch에서 호출됨: `BaseEngine.ts:162-164` — `this._callStartWatch(output).catch(() => { resolveInitialBuild(); })`. 기존의 `isInitialBuild` 가드와 동등한 동작.
 
 ### Slice 2: EsbuildClientEngine 적용
 
-- [x] EsbuildClientEngine이 waitForInitialBuild() 미사용: `EsbuildClientEngine.ts:103-111` — setupWatchEvents 호출 후 반환값 사용 안 함. 111행에 "waitForInitialBuild 미사용" 주석 확인.
-- [x] serverReady 이벤트 처리 유지: `EsbuildClientEngine.ts:97-101` — serverReady 핸들러가 setupWatchEvents 전에 등록됨. `this.port = event.port` 로직 그대로.
-- [x] error 로깅 유지: `EsbuildClientEngine.ts:113-117` — setupWatchEvents 이후 별도 error 핸들러에서 `logger.error` 호출. 기존 동작 보존.
-- [x] worker.startWatch() await 패턴 유지: `EsbuildClientEngine.ts:119-130` — 기존과 동일하게 `await this._worker!.startWatch(...)` 로 완료 감지.
+- EsbuildClientEngine이 waitForInitialBuild() 미사용: `EsbuildClientEngine.ts:103-111` — setupWatchEvents 호출 후 반환값 사용 안 함. 111행에 "waitForInitialBuild 미사용" 주석 확인.
+- serverReady 이벤트 처리 유지: `EsbuildClientEngine.ts:97-101` — serverReady 핸들러가 setupWatchEvents 전에 등록됨. `this.port = event.port` 로직 그대로.
+- error 로깅 유지: `EsbuildClientEngine.ts:113-117` — setupWatchEvents 이후 별도 error 핸들러에서 `logger.error` 호출. 기존 동작 보존.
+- worker.startWatch() await 패턴 유지: `EsbuildClientEngine.ts:119-130` — 기존과 동일하게 `await this._worker!.startWatch(...)` 로 완료 감지.

package/tests/utils/esbuild-client-config-integration.verify.md

@@ -2,8 +2,8 @@
 
 ## 검증 항목
 
-- [x] `@angular/build/private`에서 `createCompilerPlugin`, `SourceFileCache`, `CompilerPluginOptions`, `BundleStylesheetOptions` import가 없다: grep 결과 `@angular/build/private` 매치 없음
-- [x] `createAngularCompilerPlugin`이 `./esbuild-angular-compiler-plugin.js`에서 import되어 있다: line 10에서 import, line 119에서 호출 확인
-- [x] `ClientSourceFileCache`가 `AngularSourceFileCache`를 확장하고 `typeScriptFileCache`, `loadResultCache` 프로퍼티를 가진다: line 46-49에서 `extends AngularSourceFileCache` + 두 프로퍼티 확인
-- [x] `ClientEsbuildResult.sourceFileCache` 타입이 `ClientSourceFileCache`이다: line 53 확인
-- [x] `client.worker.ts`의 `sourceFileCache.loadResultCache.watchFiles`, `sourceFileCache.typeScriptFileCache.keys()`, `sourceFileCache.invalidate()` 접근이 새 구조와 타입 호환된다: typecheck 0 에러로 타입 호환성 확인됨
+- `@angular/build/private`에서 `createCompilerPlugin`, `SourceFileCache`, `CompilerPluginOptions`, `BundleStylesheetOptions` import가 없다: grep 결과 `@angular/build/private` 매치 없음
+- `createAngularCompilerPlugin`이 `./esbuild-angular-compiler-plugin.js`에서 import되어 있다: line 10에서 import, line 119에서 호출 확인
+- `ClientSourceFileCache`가 `AngularSourceFileCache`를 확장하고 `typeScriptFileCache`, `loadResultCache` 프로퍼티를 가진다: line 46-49에서 `extends AngularSourceFileCache` + 두 프로퍼티 확인
+- `ClientEsbuildResult.sourceFileCache` 타입이 `ClientSourceFileCache`이다: line 53 확인
+- `client.worker.ts`의 `sourceFileCache.loadResultCache.watchFiles`, `sourceFileCache.typeScriptFileCache.keys()`, `sourceFileCache.invalidate()` 접근이 새 구조와 타입 호환된다: typecheck 0 에러로 타입 호환성 확인됨

package/tests/utils/esbuild-client-config-postcss.verify.md

@@ -2,5 +2,5 @@
 
 ## 검증 항목
 
-- [x] postcssConfigPath가 CreateClientEsbuildOptions 인터페이스에서 제거됨: `esbuild-client-config.ts`에서 `postcssConfigPath` 검색 결과 없음 (No matches found). `client.worker.ts`에서도 2곳 모두 제거 확인.
-- [x] createScssPlugin에 로딩된 PostCSS 인스턴스가 전달됨: `esbuild-client-config.ts:118`에서 `postcssPlugins: loadedPostcssPlugins`로 `createScssPlugin`에 전달 확인.
+- postcssConfigPath가 CreateClientEsbuildOptions 인터페이스에서 제거됨: `esbuild-client-config.ts`에서 `postcssConfigPath` 검색 결과 없음 (No matches found). `client.worker.ts`에서도 2곳 모두 제거 확인.
+- createScssPlugin에 로딩된 PostCSS 인스턴스가 전달됨: `esbuild-client-config.ts:118`에서 `postcssPlugins: loadedPostcssPlugins`로 `createScssPlugin`에 전달 확인.

package/tests/utils/esbuild-client-config.verify.md

@@ -2,25 +2,25 @@
 
 ## Feature 1.1a 검증 항목
 
-- [x] import 경로: `@angular/build/private`에서 `createCompilerPlugin`, `SourceFileCache`, `CompilerPluginOptions`, `BundleStylesheetOptions`를 정상 import — `private.d.ts` line 31-37에 모두 export 확인
-- [x] `createCompilerPlugin`의 2-param 시그니처(private export wrapper)와 일치하는 호출 — `createCompilerPlugin(pluginOptions, styleOptions)` 2개 인자로 호출 (private.d.ts의 wrapper 시그니처와 일치)
-- [x] `CompilerPluginOptions.sourcemap` 타입이 `boolean | 'external'` 범위 내 값 사용 — `isDev` (boolean)으로 전달, `true`/`false` 범위 내
-- [x] `BundleStylesheetOptions.sourcemap` 타입이 `boolean | 'external' | 'inline' | 'linked'` 범위 내 값 사용 — `isDev ? "linked" : false` 범위 내
-- [x] `sd-config.types.ts`의 `postCss.plugins` 타입이 Angular의 `PostcssConfiguration` 포맷과 일치 — `[string, (object | string)?][]` = Angular의 `[name: string, options?: object | string][]`
-- [x] `onEnd` 플러그인이 esbuild Plugin 규격(`name` + `setup`)을 준수 — `{ name: "sd-on-end", setup(build) { build.onEnd(...) } }` 규격 충족
-- [x] 패키지 루트 `index.ts`에서 신규 모듈 export 필요 여부 — 불필요. 기존 `esbuild-config.ts`도 내부 유틸로 export 안 함. `sd-config.types.ts`만 export 중
+- import 경로: `@angular/build/private`에서 `createCompilerPlugin`, `SourceFileCache`, `CompilerPluginOptions`, `BundleStylesheetOptions`를 정상 import — `private.d.ts` line 31-37에 모두 export 확인
+- `createCompilerPlugin`의 2-param 시그니처(private export wrapper)와 일치하는 호출 — `createCompilerPlugin(pluginOptions, styleOptions)` 2개 인자로 호출 (private.d.ts의 wrapper 시그니처와 일치)
+- `CompilerPluginOptions.sourcemap` 타입이 `boolean | 'external'` 범위 내 값 사용 — `isDev` (boolean)으로 전달, `true`/`false` 범위 내
+- `BundleStylesheetOptions.sourcemap` 타입이 `boolean | 'external' | 'inline' | 'linked'` 범위 내 값 사용 — `isDev ? "linked" : false` 범위 내
+- `sd-config.types.ts`의 `postCss.plugins` 타입이 Angular의 `PostcssConfiguration` 포맷과 일치 — `[string, (object | string)?][]` = Angular의 `[name: string, options?: object | string][]`
+- `onEnd` 플러그인이 esbuild Plugin 규격(`name` + `setup`)을 준수 — `{ name: "sd-on-end", setup(build) { build.onEnd(...) } }` 규격 충족
+- 패키지 루트 `index.ts`에서 신규 모듈 export 필요 여부 — 불필요. 기존 `esbuild-config.ts`도 내부 유틸로 export 안 함. `sd-config.types.ts`만 export 중
 
 ## Feature 1.1b-2 검증 항목
 
-- [x] `browserslist-to-esbuild` import 정상 — `import browserslistToEsbuild from "browserslist-to-esbuild"` 추가. `vite-config.ts:5`와 동일한 패턴
-- [x] `browserslistToEsbuild` 반환값이 esbuild target 및 BundleStylesheetOptions.target에 동시 적용 — `esbuildTarget` 변수로 통합하여 두 곳에 사용 (line 51-56, 82, 122)
-- [x] 에셋 복사: `copyPublicFiles(pkgDir, false)` 시그니처가 build 모드 호출 가능 — `copy-public.ts:15` 시그니처 `(pkgDir: string, includeDev: boolean): Promise<void>` 확인. build 모드에서 `false` 전달 적합
-- [x] 에셋 감시: `watchPublicFiles(pkgDir, true)` 시그니처가 dev 모드 호출 가능 — `copy-public.ts:58` 시그니처 `(pkgDir: string, includeDev: boolean): Promise<FsWatcher | undefined>` 확인. dev 모드에서 `true` 전달 적합
-- [x] 에셋 복사 함수는 `createClientEsbuildContext` 외부 호출자 담당 (설계 결정 D4) — `createClientEsbuildContext` 내부에 `copyPublicFiles`/`watchPublicFiles` 호출 없음 확인. 실제 호출 통합은 Feature 3.1에서 수행
+- `browserslist-to-esbuild` import 정상 — `import browserslistToEsbuild from "browserslist-to-esbuild"` 추가. `vite-config.ts:5`와 동일한 패턴
+- `browserslistToEsbuild` 반환값이 esbuild target 및 BundleStylesheetOptions.target에 동시 적용 — `esbuildTarget` 변수로 통합하여 두 곳에 사용 (line 51-56, 82, 122)
+- 에셋 복사: `copyPublicFiles(pkgDir, false)` 시그니처가 build 모드 호출 가능 — `copy-public.ts:15` 시그니처 `(pkgDir: string, includeDev: boolean): Promise<void>` 확인. build 모드에서 `false` 전달 적합
+- 에셋 감시: `watchPublicFiles(pkgDir, true)` 시그니처가 dev 모드 호출 가능 — `copy-public.ts:58` 시그니처 `(pkgDir: string, includeDev: boolean): Promise<FsWatcher | undefined>` 확인. dev 모드에서 `true` 전달 적합
+- 에셋 복사 함수는 `createClientEsbuildContext` 외부 호출자 담당 (설계 결정 D4) — `createClientEsbuildContext` 내부에 `copyPublicFiles`/`watchPublicFiles` 호출 없음 확인. 실제 호출 통합은 Feature 3.1에서 수행
 
 ## Feature 1.1b-1 검증 항목
 
-- [x] tsconfig 옵션이 CompilerPluginOptions와 esbuild context에 동일 기본값 사용 — 둘 다 `options.tsconfig ?? path.join(options.pkgDir, "tsconfig.json")`. CompilerPluginOptions(line 65)와 esbuild context(line 151)에서 동일 패턴
-- [x] esbuild tsconfig 옵션이 서버 빌드 패턴(D1)과 일치 — `esbuild-config.ts:94` `tsconfig: path.join(options.pkgDir, "tsconfig.json")`과 동일. 클라이언트는 추가로 `options.tsconfig` 커스텀 경로 지원 (기존 인터페이스에 이미 존재)
-- [x] scssPlugin loadPaths가 buildScssLoadPaths 패턴과 일치 — `ngtsc-build-core.ts:91-96`의 `[pkgDir/scss, cwd/node_modules]`와 `esbuild-client-config.ts:105-108`의 `[options.pkgDir/scss, options.cwd/node_modules]` 동일
-- [x] plugins 배열 순서가 구현계획과 일치 — `[angularPlugin, scssPlugin, ...customPlugins, ...onEndPlugin]` (line 153-169)
+- tsconfig 옵션이 CompilerPluginOptions와 esbuild context에 동일 기본값 사용 — 둘 다 `options.tsconfig ?? path.join(options.pkgDir, "tsconfig.json")`. CompilerPluginOptions(line 65)와 esbuild context(line 151)에서 동일 패턴
+- esbuild tsconfig 옵션이 서버 빌드 패턴(D1)과 일치 — `esbuild-config.ts:94` `tsconfig: path.join(options.pkgDir, "tsconfig.json")`과 동일. 클라이언트는 추가로 `options.tsconfig` 커스텀 경로 지원 (기존 인터페이스에 이미 존재)
+- scssPlugin loadPaths가 buildScssLoadPaths 패턴과 일치 — `ngtsc-build-core.ts:91-96`의 `[pkgDir/scss, cwd/node_modules]`와 `esbuild-client-config.ts:105-108`의 `[options.pkgDir/scss, options.cwd/node_modules]` 동일
+- plugins 배열 순서가 구현계획과 일치 — `[angularPlugin, scssPlugin, ...customPlugins, ...onEndPlugin]` (line 153-169)

package/tests/utils/esbuild-index-html.verify.md

@@ -2,9 +2,9 @@
 
 ## 검증 항목
 
-- [x] FileInfo 타입이 IndexHtmlGenerator의 FileInfo와 호환: IndexHtmlGeneratorProcessOptions.files는 `{file: string, name?: string, extension: string}` — 동일 구조 확인
-- [x] entrypoints 타입이 IndexHtmlGenerator의 Entrypoint와 호환: `[string, boolean][]` — `Entrypoint = [name: string, isModule: boolean]`과 동일
-- [x] SRI 옵션이 mode에 따라 정확히 설정: `sri: options.mode === "build"` — build일 때만 true
-- [x] cssBundle 연결 로직의 정확성: JS entry의 `output.cssBundle` 경로를 normalize하여 CSS output의 경로와 매칭. esbuild metafile 구조상 cssBundle은 output key와 동일 형식
-- [x] postTransform이 IndexHtmlGeneratorOptions에 올바르게 전달: `IndexHtmlTransform = (content: string) => Promise<string>` — GenerateIndexHtmlOptions.postTransform과 동일 타입
-- [x] Windows 경로 호환성: `replace(/\\/g, "/")` 로 모든 경로를 POSIX 형식으로 정규화
+- FileInfo 타입이 IndexHtmlGenerator의 FileInfo와 호환: IndexHtmlGeneratorProcessOptions.files는 `{file: string, name?: string, extension: string}` — 동일 구조 확인
+- entrypoints 타입이 IndexHtmlGenerator의 Entrypoint와 호환: `[string, boolean][]` — `Entrypoint = [name: string, isModule: boolean]`과 동일
+- SRI 옵션이 mode에 따라 정확히 설정: `sri: options.mode === "build"` — build일 때만 true
+- cssBundle 연결 로직의 정확성: JS entry의 `output.cssBundle` 경로를 normalize하여 CSS output의 경로와 매칭. esbuild metafile 구조상 cssBundle은 output key와 동일 형식
+- postTransform이 IndexHtmlGeneratorOptions에 올바르게 전달: `IndexHtmlTransform = (content: string) => Promise<string>` — GenerateIndexHtmlOptions.postTransform과 동일 타입
+- Windows 경로 호환성: `replace(/\\/g, "/")` 로 모든 경로를 POSIX 형식으로 정규화

package/tests/utils/esbuild-pwa.verify.md

@@ -2,8 +2,8 @@
 
 ## 검증 항목
 
-- [x] augmentAppWithServiceWorker 호출 인자가 정확한가: `esbuild-pwa.ts:108-113` — `(options.pkgDir, options.cwd, options.outdir, options.baseHref)` 순서로 호출 확인
-- [x] 기본 ngsw-config.json에 $schema, index, assetGroups(app, assets)가 포함되는가: `esbuild-pwa.ts:83-104` — `$schema`, `index: "/index.html"`, `assetGroups: [{name: "app"}, {name: "assets"}]` 확인
-- [x] 등록 스크립트에서 ngsw-worker.js를 등록하는가: `esbuild-pwa.ts:119` — `register("ngsw-worker.js")` 확인. `sw.js` 참조 없음
-- [x] SdPwaConfig.workbox 필드를 참조하지 않는가: grep 결과 "workbox" 0건 확인. D4 결정 준수
-- [x] generatePwaIcons 호출 결과를 dist/icons/로 복사하는 로직이 있는가: `esbuild-pwa.ts:51-58` — `srcIconsDir(public/icons/)` → `dstIconsDir(outdir/icons/)` copyFileSync 로직 확인
+- augmentAppWithServiceWorker 호출 인자가 정확한가: `esbuild-pwa.ts:108-113` — `(options.pkgDir, options.cwd, options.outdir, options.baseHref)` 순서로 호출 확인
+- 기본 ngsw-config.json에 $schema, index, assetGroups(app, assets)가 포함되는가: `esbuild-pwa.ts:83-104` — `$schema`, `index: "/index.html"`, `assetGroups: [{name: "app"}, {name: "assets"}]` 확인
+- 등록 스크립트에서 ngsw-worker.js를 등록하는가: `esbuild-pwa.ts:119` — `register("ngsw-worker.js")` 확인. `sw.js` 참조 없음
+- SdPwaConfig.workbox 필드를 참조하지 않는가: grep 결과 "workbox" 0건 확인. D4 결정 준수
+- generatePwaIcons 호출 결과를 dist/icons/로 복사하는 로직이 있는가: `esbuild-pwa.ts:51-58` — `srcIconsDir(public/icons/)` → `dstIconsDir(outdir/icons/)` copyFileSync 로직 확인

package/tests/utils/esbuild-scss-plugin.verify.md

@@ -2,7 +2,7 @@
 
 ## 검증 항목
 
-- [x] createCompilerPlugin 컴포넌트 스타일과 비충돌: `createCompilerPlugin`은 `BundleStylesheetOptions`를 받아 컴포넌트 `styleUrls`를 TypeScript 변환 과정에서 내부 처리한다. 이들은 esbuild의 일반 `onLoad` 경로를 타지 않으므로, `sd-scss` 플러그인의 `onLoad({ filter: /\.scss$/ })` 콜백은 side-effect `import "./global.scss"` 같은 일반 import만 인터셉트한다. 충돌 없음 확인.
-- [x] onLoad filter 정확성: `/\.scss$/` 정규식이 `.scss` 파일만 매칭 — `.css`, `.scss.ts` 등은 매칭하지 않음. 단위 테스트(`esbuild-scss-plugin.spec.ts`)에서 검증 완료.
-- [x] sass 라인 번호 변환: sass `span.start.line`은 0-based, esbuild `location.line`은 1-based. `line + 1` 변환 적용 확인 (`esbuild-scss-plugin.ts:31`).
-- [x] fileURLToPath import 정상: `url` 모듈에서 import. `scss-compiler.ts`의 `pathToFileURL`과 동일 모듈.
+- createCompilerPlugin 컴포넌트 스타일과 비충돌: `createCompilerPlugin`은 `BundleStylesheetOptions`를 받아 컴포넌트 `styleUrls`를 TypeScript 변환 과정에서 내부 처리한다. 이들은 esbuild의 일반 `onLoad` 경로를 타지 않으므로, `sd-scss` 플러그인의 `onLoad({ filter: /\.scss$/ })` 콜백은 side-effect `import "./global.scss"` 같은 일반 import만 인터셉트한다. 충돌 없음 확인.
+- onLoad filter 정확성: `/\.scss$/` 정규식이 `.scss` 파일만 매칭 — `.css`, `.scss.ts` 등은 매칭하지 않음. 단위 테스트(`esbuild-scss-plugin.spec.ts`)에서 검증 완료.
+- sass 라인 번호 변환: sass `span.start.line`은 0-based, esbuild `location.line`은 1-based. `line + 1` 변환 적용 확인 (`esbuild-scss-plugin.ts:31`).
+- fileURLToPath import 정상: `url` 모듈에서 import. `scss-compiler.ts`의 `pathToFileURL`과 동일 모듈.

package/tests/utils/hmr-service.verify.md

@@ -2,16 +2,16 @@
 
 ## 검증 항목
 
-- [x] ws 의존성이 sd-cli package.json dependencies에 추가되었는가: `"ws": "^8.20.0"` 확인 (package.json:51)
-- [x] @types/ws가 sd-cli package.json devDependencies에 추가되었는가: `"@types/ws": "^8.18.1"` 확인 (package.json:57)
-- [x] dev-http-server.ts의 onRequest 훅 타입 시그니처가 올바른가: `onRequest?: (req: http.IncomingMessage, res: http.ServerResponse) => boolean` — Node.js 표준 타입 사용, boolean 반환으로 처리 완료 여부 표시
-- [x] hmr-service.ts의 handleRequest가 angularComponentMiddleware와 동일한 encodeURIComponent 패턴을 사용하는가: `templateUpdates.get(encodeURIComponent(componentId))` (hmr-service.ts:65) — vite-angular-plugin.ts:553과 동일 패턴
-- [x] WebSocketServer가 httpServer의 upgrade 이벤트를 통해 연결되는가: `new WebSocketServer({ server: httpServer })` (hmr-service.ts:27) — ws 라이브러리가 httpServer의 upgrade 이벤트를 자동 처리
+- ws 의존성이 sd-cli package.json dependencies에 추가되었는가: `"ws": "^8.20.0"` 확인 (package.json:51)
+- @types/ws가 sd-cli package.json devDependencies에 추가되었는가: `"@types/ws": "^8.18.1"` 확인 (package.json:57)
+- dev-http-server.ts의 onRequest 훅 타입 시그니처가 올바른가: `onRequest?: (req: http.IncomingMessage, res: http.ServerResponse) => boolean` — Node.js 표준 타입 사용, boolean 반환으로 처리 완료 여부 표시
+- hmr-service.ts의 handleRequest가 angularComponentMiddleware와 동일한 encodeURIComponent 패턴을 사용하는가: `templateUpdates.get(encodeURIComponent(componentId))` (hmr-service.ts:65) — vite-angular-plugin.ts:553과 동일 패턴
+- WebSocketServer가 httpServer의 upgrade 이벤트를 통해 연결되는가: `new WebSocketServer({ server: httpServer })` (hmr-service.ts:27) — ws 라이브러리가 httpServer의 upgrade 이벤트를 자동 처리
 
 ## Slice 2 검증 항목
 
-- [x] import.meta.hot 폴리필이 esbuild banner로 주입되는가: `esbuild-client-config.ts`에서 `templateUpdates != null && legacyModule !== true` 조건으로 banner 생성. `import.meta.hot.on()`, `import.meta.hot.off()`, `globalThis.__hmr_dispatch()` 제공.
-- [x] legacyModule일 때 폴리필이 주입되지 않는가: `options.legacyModule !== true` 조건으로 legacyModule에서 banner 미생성.
-- [x] ngHmrMode 가드가 있어 prod에서 실행되지 않는가: banner 코드가 `if(typeof ngHmrMode!=="undefined"&&ngHmrMode)` 가드로 래핑. prod에서 `ngHmrMode="false"`로 정의되므로 실행 안됨.
-- [x] sd-hmr-reset 플러그인이 onStart에서 templateUpdates.clear()를 호출하는가: `esbuild-client-config.ts`에 `sd-hmr-reset` 플러그인 추가. `build.onStart(() => { options.templateUpdates!.clear(); })` 확인.
-- [x] sd-hmr-reset이 angularPlugin보다 먼저 등록되는가: plugins 배열에서 `sd-hmr-reset`이 첫 번째 위치 (angularPlugin, scssPlugin보다 앞). createCompilerPlugin이 templateUpdates에 쓰기 전에 clear됨.
+- import.meta.hot 폴리필이 esbuild banner로 주입되는가: `esbuild-client-config.ts`에서 `templateUpdates != null && legacyModule !== true` 조건으로 banner 생성. `import.meta.hot.on()`, `import.meta.hot.off()`, `globalThis.__hmr_dispatch()` 제공.
+- legacyModule일 때 폴리필이 주입되지 않는가: `options.legacyModule !== true` 조건으로 legacyModule에서 banner 미생성.
+- ngHmrMode 가드가 있어 prod에서 실행되지 않는가: banner 코드가 `if(typeof ngHmrMode!=="undefined"&&ngHmrMode)` 가드로 래핑. prod에서 `ngHmrMode="false"`로 정의되므로 실행 안됨.
+- sd-hmr-reset 플러그인이 onStart에서 templateUpdates.clear()를 호출하는가: `esbuild-client-config.ts`에 `sd-hmr-reset` 플러그인 추가. `build.onStart(() => { options.templateUpdates!.clear(); })` 확인.
+- sd-hmr-reset이 angularPlugin보다 먼저 등록되는가: plugins 배열에서 `sd-hmr-reset`이 첫 번째 위치 (angularPlugin, scssPlugin보다 앞). createCompilerPlugin이 templateUpdates에 쓰기 전에 clear됨.

package/tests/utils/lint-core-import-paths.verify.md

@@ -2,9 +2,9 @@
 
 ## 검증 항목
 
-- [x] lint.worker.ts가 `../utils/lint-core`에서 import: `import { executeLint, type LintOptions, type LintResult } from "../utils/lint-core";` (line 2) 확인
-- [x] lint-utils.ts가 `./lint-core`에서 import: `import type { LintOptions, LintResult } from "./lint-core";` (line 2) 확인
-- [x] check.ts가 `../utils/lint-core`에서 import: `import { executeLint, type LintResult } from "../utils/lint-core";` (line 4) 확인
-- [x] commands/lint.ts�� `../commands/lint` import가 없음: `import { executeLint, type LintOptions } from "../utils/lint-core";` (line 1)만 존재
-- [x] lint-core.ts에 runLint가 없음: `executeLint`, `loadIgnorePatterns`, `LintOptions`, `LintResult`만 export
-- [x] commands/lint.ts에 runLint만 존재: 13줄의 thin wrapper
+- lint.worker.ts가 `../utils/lint-core`에서 import: `import { executeLint, type LintOptions, type LintResult } from "../utils/lint-core";` (line 2) 확인
+- lint-utils.ts가 `./lint-core`에서 import: `import type { LintOptions, LintResult } from "./lint-core";` (line 2) 확인
+- check.ts가 `../utils/lint-core`에서 import: `import { executeLint, type LintResult } from "../utils/lint-core";` (line 4) 확인
+- commands/lint.ts�� `../commands/lint` import가 없음: `import { executeLint, type LintOptions } from "../utils/lint-core";` (line 1)만 존재
+- lint-core.ts에 runLint가 없음: `executeLint`, `loadIgnorePatterns`, `LintOptions`, `LintResult`만 export
+- commands/lint.ts에 runLint만 존재: 13줄의 thin wrapper

package/tests/utils/replace-deps-split.verify.md

@@ -2,14 +2,14 @@
 
 ## 검증 항목
 
-- [x] 파일 구조: `replace-deps-resolve.ts` 신규 생성, `replace-deps.ts` 기존 유지 확인
-- [x] 해석 함수 이동: `resolveReplaceDepEntries`, `parseWorkspaceGlobs`, `collectSearchRoots`, `resolveAllReplaceDepEntries`가 `replace-deps-resolve.ts`에 위치
-- [x] 타입 위치: `ReplaceDepEntry`가 `replace-deps-resolve.ts`에서 export, `replace-deps.ts`에서 `export type` re-export
-- [x] `WatchReplaceDepResult`가 `replace-deps.ts`에서 export
-- [x] `replace-deps.ts`에서 `resolveAllReplaceDepEntries`를 import하여 사용
-- [x] `commands/publish.ts` import 경로가 `../utils/replace-deps-resolve`로 변경
-- [x] `sd-cli.ts`, `BaseOrchestrator.ts`, `commands/replace-deps.ts`의 import 경로는 변경 없음 (실행 함수만 사용)
-- [x] `tests/utils/replace-deps.spec.ts` import 경로가 `../../src/deps/replace-deps-resolve`로 변경
-- [x] `tests/utils/replace-deps-watch.spec.ts`, `replace-deps-watch.acc.spec.ts`의 import 경로는 변경 없음
-- [x] `replace-deps.ts`에서 `glob` import가 제거됨 (해석 로직 전용)
-- [x] `replace-deps-resolve.ts`에서 `fsx`, `FsWatcher`, `exec` import가 없음 (실행 로직 전용)
+- 파일 구조: `replace-deps-resolve.ts` 신규 생성, `replace-deps.ts` 기존 유지 확인
+- 해석 함수 이동: `resolveReplaceDepEntries`, `parseWorkspaceGlobs`, `collectSearchRoots`, `resolveAllReplaceDepEntries`가 `replace-deps-resolve.ts`에 위치
+- 타입 위치: `ReplaceDepEntry`가 `replace-deps-resolve.ts`에서 export, `replace-deps.ts`에서 `export type` re-export
+- `WatchReplaceDepResult`가 `replace-deps.ts`에서 export
+- `replace-deps.ts`에서 `resolveAllReplaceDepEntries`를 import하여 사용
+- `commands/publish.ts` import 경로가 `../utils/replace-deps-resolve`로 변경
+- `sd-cli.ts`, `BaseOrchestrator.ts`, `commands/replace-deps.ts`의 import 경로는 변경 없음 (실행 함수만 사용)
+- `tests/utils/replace-deps.spec.ts` import 경로가 `../../src/deps/replace-deps-resolve`로 변경
+- `tests/utils/replace-deps-watch.spec.ts`, `replace-deps-watch.acc.spec.ts`의 import 경로는 변경 없음
+- `replace-deps.ts`에서 `glob` import가 제거됨 (해석 로직 전용)
+- `replace-deps-resolve.ts`에서 `fsx`, `FsWatcher`, `exec` import가 없음 (실행 로직 전용)

package/tests/utils/replace-deps-watch.acc.spec.ts

@@ -134,4 +134,89 @@ describe("watchReplaceDeps onChanged 콜백", () => {
     // 콜백 호출 대기
     await changedPromise;
   }, 10_000);
+
+  it("동일 source를 참조하는 복수 entry가 있으면 모든 target에 복사된다", async () => {
+    // 추가 target 디렉토리 생성 (@test/pkgB)
+    const targetDirB = path.join(tmpDir, "project", "node_modules", "@test", "pkgB", "src");
+    await fs.promises.mkdir(targetDirB, { recursive: true });
+    await fs.promises.writeFile(path.join(targetDirB, "index.ts"), "export const a = 1;");
+
+    const projectRoot = path.join(tmpDir, "project");
+    const sourcePath = path.join(tmpDir, "source-pkg");
+
+    // 두 패턴이 동일 sourcePath를 참조
+    const replaceDeps = {
+      "@test/pkg": sourcePath,
+      "@test/pkgB": sourcePath,
+    };
+
+    let callCount = 0;
+    watchResult = await watchReplaceDeps(projectRoot, replaceDeps, {
+      onChanged: () => {
+        callCount++;
+      },
+    });
+
+    // 소스 파일 변경
+    await fs.promises.writeFile(
+      path.join(sourcePath, "src", "index.ts"),
+      "export const a = 9;",
+    );
+
+    // 배칭 + 복사 완료 대기
+    await new Promise((r) => setTimeout(r, 1500));
+
+    // 두 target 모두 업데이트
+    const targetAContent = await fs.promises.readFile(
+      path.join(tmpDir, "project", "node_modules", "@test", "pkg", "src", "index.ts"),
+      "utf-8",
+    );
+    const targetBContent = await fs.promises.readFile(
+      path.join(targetDirB, "index.ts"),
+      "utf-8",
+    );
+    expect(targetAContent).toBe("export const a = 9;");
+    expect(targetBContent).toBe("export const a = 9;");
+
+    // 동일 source의 중복 watchPath는 하나로 통합되므로 이벤트가 1회만 배칭됨 → onChanged 1회
+    expect(callCount).toBe(1);
+  }, 10_000);
+
+  it("소스 파일이 삭제되면 대상 파일도 삭제된다", async () => {
+    const projectRoot = path.join(tmpDir, "project");
+    const sourcePath = path.join(tmpDir, "source-pkg");
+    const replaceDeps = { "@test/pkg": sourcePath };
+
+    let resolveChanged: () => void;
+    const changedPromise = new Promise<void>((resolve) => {
+      resolveChanged = resolve;
+    });
+
+    watchResult = await watchReplaceDeps(projectRoot, replaceDeps, {
+      onChanged: () => {
+        resolveChanged();
+      },
+    });
+
+    const destPath = path.join(
+      tmpDir, "project", "node_modules", "@test", "pkg", "src", "index.ts",
+    );
+
+    // 삭제 전 target 파일 존재 확인
+    await expect(fs.promises.access(destPath)).resolves.toBeUndefined();
+
+    // 소스 삭제
+    await fs.promises.unlink(path.join(sourcePath, "src", "index.ts"));
+
+    await changedPromise;
+
+    // 삭제 반영까지 여유 대기
+    await new Promise((r) => setTimeout(r, 500));
+
+    // target도 삭제됨
+    const targetExists = await fs.promises
+      .access(destPath)
+      .then(() => true, () => false);
+    expect(targetExists).toBe(false);
+  }, 10_000);
 });