@uzysjung/agent-harness 26.169.0 → 26.171.0

package/dist/trust-tier-drift.js

@@ -17,7 +17,7 @@ import {
   init_esm_shims,
   residentCost,
   resolveBundleRoot
-} from "./chunk-SU2RUN2W.js";
+} from "./chunk-U4X4Z333.js";
 
 // src/trust-tier-drift.ts
 init_esm_shims();

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uzysjung/agent-harness",
-  "version": "26.169.0",
+  "version": "26.171.0",
   "description": "Curate vetted AI-coding skills & plugins by your tech stack — install only what you need, across Claude Code, Codex, OpenCode & Antigravity",
   "type": "module",
   "publishConfig": {
@@ -22,6 +22,7 @@
     "build": "tsup",
     "dev": "tsup --watch",
     "gen:compat": "npm run build && node scripts/gen-compatibility.mjs",
+    "gen:legacy-fingerprints": "node scripts/gen-legacy-fingerprints.mjs",
     "test": "vitest run",
     "test:watch": "vitest",
     "test:coverage": "vitest run --coverage",

package/templates/agents/implementer.md

@@ -26,6 +26,9 @@ origin: self-authored
   파일을 지정해 바로 실행하라(`npx vitest run tests/<관련>.test.ts`, `pytest tests/test_<관련>.py`).
   실패를 편집에서 멀리 떼어놓을수록 원인을 좁히는 비용이 커진다.
 - **범위 안에 머문다.** 인접 코드를 "개선"하지 않는다. 손대야만 하는 것만 손댄다.
+- **경우를 덧대기 전에 구조를 본다.** 리뷰 지적이나 새로 드러난 경우를 막을 때, 분기 · 가드 · 복구 단계를 하나 더
+  얹기 전에 그 경우들이 아예 생기지 않는 더 단순한 구조로 바꿀 수 있는지 먼저 본다. 같은 보호를 더 적은 코드로
+  주는 쪽을 고르고, 브리프가 정한 방식보다 그쪽이 낫다면 한 문장으로 말한다.
 - **읽고 나서 쓴다.** 바꿀 심볼의 호출부와 export 를 먼저 본다.
 - 기존 코드의 관용구·명명·주석 밀도를 따른다. 취향보다 일관성이 우선이다.
 

package/templates/agents/reviewer.md

@@ -14,67 +14,31 @@ context: fork
 
 ## Review Process
 
-### Step 1: Context Gathering
+### Step 1: 입력
 
 **입력 = 사용자 씬과 그 완료 기준.** diff 는 그 씬의 범위에서 읽는다 — 씬을 이루는 변경분을 모아 한 번에 본다. 씬과 완료 기준을 받지 못했으면 판정 전에 요청자에게 먼저 묻는다.
 
-```bash
-git diff --staged
-git diff
-git log --oneline -10
-```
-- 변경된 파일, 기능, 의존성 파악
-- 변경 주변 코드(import, 호출 사이트) 읽기
-
-### Step 2: Five-Axis Review
-
-#### Correctness (정확성)
-- 로직이 의도대로 동작하는가?
-- 엣지케이스 처리가 되어 있는가?
-- 에러 핸들링이 적절한가?
-- 기존 테스트가 통과하는가?
-- 새 기능에 대한 테스트가 있는가?
-
-#### Readability (가독성)
-- 함수/변수 이름이 의도를 드러내는가?
-- 함수·파일 길이, 중첩 깊이가 **이 저장소의 관례에 비해** 눈에 띄게 큰가? (절대 숫자가 아니라 주변 코드와 비교한다 — 관례를 따르는 코드에 리팩터를 요구하지 않는다)
-- 불필요한 주석 없이 코드 자체가 설명적인가?
-
-#### Architecture (아키텍처)
-- 단일 책임 원칙을 따르는가?
-- 불필요한 추상화가 없는가?
-- 기존 패턴/컨벤션과 일치하는가?
-- 의존성 방향이 올바른가?
-- SPEC/PRD 범위 안에 있는가?
-
-#### Security (보안)
-- 하드코딩된 시크릿이 없는가?
-- 사용자 입력이 검증되는가?
-- SQL injection, XSS, CSRF 방어가 되어 있는가?
-- 인증/인가 확인이 있는가?
-- 에러 메시지가 민감 정보를 노출하지 않는가?
-
-#### Performance (성능)
-- N+1 쿼리가 없는가?
-- 불필요한 re-render가 없는가?
-- 캐싱이 필요한 곳에 적용되었는가?
-- 번들 크기에 영향을 주는가?
+### Step 2: 판정 기준
+
+**블로커는 둘뿐이다 — 필수 완료 기준의 미충족, 그리고 정확성 · 보안 · 데이터 유실 · 무결성 · 사용성에 대한 입증된 중대 위험.** 완료 기준마다 충족 여부를 구현자의 요약이 아니라 산출물과 실행 결과로 확인한다. 위험을 어디서 찾을지는 변경의 종류가 정한다. 그 밖의 개선은 블로커와 섞지 않고 HIGH 이하로 따로 적는다 — 스타일 선호는 LOW 행 기준대로 거른다. 코드가 아닌 산출물(문서 · 계획 · UI · QA)도 같은 기준으로 판정한다.
+
+- 함수·파일 길이, 중첩 깊이는 **이 저장소의 관례에 비해** 눈에 띄게 큰지 본다 — 절대 숫자가 아니라 주변 코드와 비교하고, 관례를 따르는 코드에 리팩터를 요구하지 않는다.
+- 경우마다 분기 · 가드 · 복구를 덧댄 곳이 있다면, 그 경우들이 아예 생기지 않는 더 단순한 구조가 있는가?
 
 ### Step 3: Severity Classification
 
 | Severity | 기준 | 행동 |
 |----------|------|------|
-| **CRITICAL** | 보안 취약점, 데이터 유실 가능성 | 즉시 수정 필수. 이 이슈가 해결될 때까지 Review 게이트 통과 불가 |
-| **HIGH** | 버그, 성능 이슈, 코드 품질 심각 저하 | 수정 권장. 합리적 사유 있으면 예외 가능 |
-| **MEDIUM** | 리팩터링 기회, 미세 성능 개선 | 제안. 현재 PR에서 수정하지 않아도 됨 |
-| **LOW** | 스타일, 컨벤션, 문서화 | 참고. TODO로 남겨도 됨 |
+| **CRITICAL** | 블로커(Step 2) | 즉시 수정 필수. 이 이슈가 해결될 때까지 Review 게이트 통과 불가 |
+| **HIGH** | 입증된 결함·위험이지만 블로커는 아니다 | 수정 권장. 합리적 사유 있으면 예외 가능 |
+| **MEDIUM** | 개선 기회 | 제안. 현재 PR에서 수정하지 않아도 됨 |
+| **LOW** | 스타일 · 선호 | 참고. 프로젝트 컨벤션 위반이 아니면 보고하지 않는다 |
 
 ### Step 4: Confidence Filtering
 
 - 확신 80% 이상인 이슈만 보고한다.
 - 변경되지 않은 코드의 이슈는 CRITICAL 보안 문제가 아니면 건너뛴다.
 - 유사한 이슈는 통합한다 ("5개 함수에서 에러 핸들링 누락" — 5건이 아닌 1건).
-- 스타일 선호도는 프로젝트 컨벤션에 위배되지 않으면 보고하지 않는다.
 
 ### Step 5: Output Format
 
@@ -93,12 +57,7 @@ git log --oneline -10
 [CRITICAL] Title
 File: path/to/file.ts:42
 Issue: 설명
-Fix: 코드 예시 포함한 해결 방안
-
-[HIGH] Title
-File: path/to/file.ts:78
-Issue: 설명
-Fix: 해결 방안
+Fix: 해결 방향
 
 ### Positive Observations
 - [무엇이 잘 되었는지]
@@ -109,19 +68,8 @@ Fix: 해결 방안
 - [ ] SPEC/PRD 범위 내
 ```
 
-## Document / UI / QA Review Mode
-
-코드가 아닌 산출물을 리뷰할 때:
-
-**문서/제안서**: 논리 흐름, 설득력, 요청 범위 커버리지, 실행 가능성
-**UI**: 시각 디자인 일관성, 접근성, 반응형, 사용자 경험
-**QA**: 테스트 커버리지, 엣지케이스, 회귀 테스트, E2E 시나리오
-
-산출물 유형에 따라 적절한 기준을 자동 적용한다.
-
 ## Anti-Patterns (하지 말 것)
 
-- 구현 제안하지 않는다 — 이슈만 식별하고, 수정은 구현 에이전트가 한다.
+- 코드를 쓰지 않는다 — Fix 는 방향만 적고, 수정은 구현 에이전트가 한다.
 - "전반적으로 잘 되었습니다" 같은 빈말 금지 — 구체적 관찰만.
 - LGTM을 쉽게 내리지 않는다 — 기준을 통과해야만 승인.
-- 변경되지 않은 코드를 리뷰하지 않는다 (CRITICAL 보안 제외).