@uzysjung/agent-harness 26.113.0 → 26.114.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uzysjung/agent-harness",
-  "version": "26.113.0",
+  "version": "26.114.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": {

package/templates/rules/benchmark-parity.md

@@ -1,7 +1,8 @@
 # Benchmark Parity (벤치마크 핵심 기능 완결성)
 
 레퍼런스 제품(벤치마크)을 실측해 핵심 기능을 도출하고, 자체 구현이 **올바르게 + 필요한 항목 전부**
-갖췄는지 반복 검토·발전시키는 워크플로우. 실서비스 운영(레퍼런스 audit 20회 내외 실행)에서 검증된
+갖췄는지 반복 검토·발전시키는 워크플로우. **기준선은 레퍼런스 또는 자기 배포본**(후자 = Dogfood
+pass) — 비교 대상이 다를 뿐 산출물(gap.md)과 규율은 같다. 실서비스 운영(레퍼런스 audit 20회 내외 실행)에서 검증된
 관행의 일반화. 목표는 **모방이 아니라 핵심 기능 완결성** — NORTH_STAR 핵심 경쟁력에 기여하지 않는
 단순 모방은 deferred (Will/Won't).
 
@@ -48,13 +49,29 @@ SSOT — 없으면 갭 판정 기준 자체가 없다.
 - **증거 = file:line + capture 참조.** 증거 없는 행은 갭이 아니라 추정이다 (기재 금지).
 - 선택 확장 열: Effort(S/M/L) · 벤치마크 구분(내부 버그 vs divergence).
 
+## Dogfood pass (배포본 전수 walkthrough)
+
+벤치마크 비교가 "남과 비교"라면, dogfood 는 **배포된 자기 서비스를 사용자처럼 끝까지 써보는
+것**이다. 둘은 기준선이 다를 뿐 산출물은 같다 — **새 스키마를 만들지 말고 위 gap.md 표를 그대로
+쓴다** (증거 열에 capture/영상 경로).
+
+- **대상 = 배포본**(로컬 dev 아님). 로그인 상태로 전 메뉴를 실제로 눌러본다.
+- **범위를 먼저 적는다** — "전체 서비스 / 주요 메뉴 N개" 처럼. 범위 미기재 보고는 커버리지를
+  부풀린다.
+- **심각도 롤업을 머리에 둔다**: `CRITICAL n · HIGH n · MEDIUM n · LOW n · 합계 n`. 개별 행만
+  나열하면 "얼마나 나쁜가"가 안 보인다.
+- **재현 아티팩트 필수** — 이슈마다 스크린샷/영상 경로. 없으면 증거 없는 행과 같다.
+- **게이트**: CRITICAL 0 이어야 dogfood 통과. HIGH 는 사유를 적고 사용자 판단으로 넘긴다.
+  (아래 "자율 루프 완료조건"의 `CRITICAL/HIGH 전부 [x]` 와 다른 게이트다 — 이쪽은 **패스 통과**
+  기준, 저쪽은 **루프 종료** 기준. 루프를 끝내려면 HIGH 까지 닫아야 한다.)
+
 ## PR 의무 필드 (UI/UX 변경 PR)
 
 UI/UX 에 영향하는 PR 의 description 에 다음 섹션 필수:
 
 ```markdown
 ## Fidelity (benchmark parity)
-- Benchmark: <벤치마크명>
+- Benchmark: <벤치마크명> (dogfood 발 PR 이면 `dogfood — 자기 배포본`)
 - Capture: docs/research/<area>_audit_<sprint>/<file>.png
 - 갭 매트릭스: docs/research/<area>_audit_<sprint>/gap.md §X
 ```

package/templates/skills/deep-research/SKILL.md

@@ -112,11 +112,35 @@ Structure the report:
 1. [Title](url) — [one-line summary]
 2. ...
 
+## Research Ledger — [N] confirmed · [M] killed
+
+| Killed claim/direction | Why rejected | Source that killed it |
+|---|---|---|
+| [what you looked into] | [contradicting evidence / legal or licensing block / vendor-only claim] | [url] |
+
+> **Caveats**: [which numbers are vendor-promotional or self-reported, which sources are
+> preprints, which claims you could not verify verbatim and are therefore follow-up work]
+
 ## Methodology
 Searched [N] queries across web and news. Analyzed [M] sources.
 Sub-questions investigated: [list]
 ```
 
+### The ledger is not optional
+
+A report that lists only what survived hides the most reusable part of the work. Record it as
+`N confirmed · M killed`, and for each killed item write **why** — contradicting evidence, a
+legal block, or a claim that turned out to be vendor-promotional. Two things follow:
+
+- **Nobody re-researches a dead end.** Next quarter the same idea resurfaces; the ledger answers
+  it in one line instead of another research cycle.
+- **A kill count is evidence of rigor.** `22 confirmed · 0 killed` means you were collecting
+  support, not testing claims. Zero kills is a signal to re-examine, not a clean result.
+
+The caveat block does the same job for what survived but is *weakly* sourced: vendor numbers with
+no independent verification, preprints whose self-reported performance you cite architecture from
+but not results, beta APIs. Naming them keeps a soft source from hardening into a fact downstream.
+
 ### Step 6: Deliver
 
 - **Short topics**: Post the full report in chat

package/templates/skills/eval-harness/SKILL.md

@@ -106,24 +106,51 @@ Risk Level: LOW/MEDIUM/HIGH
 ## Eval Workflow
 
 ### 1. Define (Before Coding)
-```markdown
-## EVAL DEFINITION: feature-xyz
 
-### Capability Evals
-1. Can create new user account
-2. Can validate email format
-3. Can hash password securely
+Write the spec to a file (`.claude/evals/<feature>.md`) before implementing. Give every eval a
+stable ID — `C1..Cn` for capability, `R1..Rn` for regression — so the same identifier carries
+from definition to the post-implementation status line, and a reviewer can check them off one by
+one. Prose-only lists ("Can create new user account") can't be referenced or scored.
 
-### Regression Evals
-1. Existing login still works
-2. Session management unchanged
-3. Logout flow intact
+````markdown
+# EVAL: <feature name> (<phase/PR>)
+
+**Feature**: <one line>
+**Baseline**: commit <sha>          # what "regression" is measured against
+**Target**: pass@1 = 100% for capability evals
+
+## Capability Evals
+
+### C1: <name>
+- <concrete, checkable expectation — inputs → expected output>
+
+### C2: <name>
+- <expectation>
 
-### Success Metrics
-- pass@3 > 90% for capability evals
-- pass^3 = 100% for regression evals
+## Regression Evals
+
+### R1: <existing behavior that must not move>
+- <expectation>
+
+## Test Command
+```bash
+pytest tests/test_<area>.py -v -k "<selector>"
 ```
 
+## Status (after implementation)
+- C1-Cn: PASS via <tests (N개) / route check / manual>
+- R1-Rn: PASS
+
+**Overall: pass@1 = <x>%**
+````
+
+Two fields carry most of the weight. **Baseline commit** makes "regression" falsifiable — without
+it, R-evals are opinions about the past. **Test Command** makes the spec re-runnable by someone
+who didn't write it; an eval nobody can re-run is documentation, not a gate.
+
+Fill the Status section *after* implementing, in the same file. A spec whose status is still empty
+at merge time means the evals were written and never used.
+
 ### 2. Implement
 Write code to pass the defined evals.