feat: plugins/ 시스템 + rules/ 엔진 — 연결 vs 삭제 결정

[justn-hyeok]

Summary

구현 완료되었지만 파이프라인에 연결되지 않은 두 서브시스템에 대한 결정 필요.

plugins/ 시스템 (530줄, 5파일)

구현 상태: 완전 구현

• types.ts — 4가지 플러그인 타입 (provider, backend, output, hook)
• registry.ts — 싱글톤 레지스트리
• loader.ts — 검증 + 로딩
• provider-manager.ts — 프로바이더 인스턴스 관리
• builtin-providers.ts — 8개 빌트인 프로바이더 래핑

문제:

• getPluginRegistry(), loadPlugins(), ProviderPluginManager이 plugins/ 밖에서 한 번도 import되지 않음
• config.plugins 설정 필드를 읽는 코드 없음
• 실제 프로바이더 실행은 별도의 l1/provider-registry.ts (24개 하드코딩)
• 이중 등록 문제 — 같은 프로바이더가 두 곳에 정의

연결 시 필요한 작업:

• orchestrator에서 loadPlugins() + getPluginRegistry() 호출
• L1 api-backend에서 ProviderPluginManager.getProvider() 폴백
• config.plugins 필드 활성화

rules/ 엔진 (223줄, 3파일)

구현 상태: 완전 구현

• types.ts — Rule, CompiledRule Zod 스키마
• loader.ts — .reviewrules YAML 로딩 + regex 컴파일
• matcher.ts — diff 매칭 → EvidenceDocument[] 생성 (source: 'rule')

문제:

• loadReviewRules, matchRules 호출자 0건
• 테스트 파일 없음

연결 시 필요한 작업 (간단):

• orchestrator에서 loadReviewRules(projectRoot) 호출
• matchRules(diffContent, compiledRules) 결과를 allEvidenceDocs에 merge
• confidence 계산이 이미 source: 'rule'을 skip하므로 호환됨

결정 옵션

1. 연결 — 두 시스템 모두 파이프라인에 통합. rules는 간단, plugins는 provider-registry 리팩터 필요
2. rules만 연결 + plugins 삭제 — rules는 ROI 높음, plugins는 현재 provider-registry로 충분
3. 둘 다 삭제 — dead code 제거, 필요 시 재구현