@uzysjung/agent-harness 26.170.0 → 26.172.0

package/dist/trust-tier-drift.js

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uzysjung/agent-harness",
-  "version": "26.170.0",
+  "version": "26.172.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/CLAUDE.md

@@ -90,7 +90,9 @@ Report what changed, what is supported by evidence, and material remaining gaps.
 Work autonomously through the authorized outcome, without seeking repeated
 confirmation for routine progress. Keep readiness and authority distinct:
 preparing or validating a change does not authorize applying it to shared
-systems or persistent application data.
+systems or persistent application data. An explicit user correction of a recorded
+procedure governs at once; before dependent work continues, align active plans and
+delegations, and record a standing change in its project-owned source.
 
 Reuse approval that covers the action and target. Obtain explicit approval for
 destructive or privileged actions, deployment, and shared-state writes when

package/templates/agents/reviewer.md

@@ -14,68 +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 (아키텍처)
-- 단일 책임 원칙을 따르는가?
-- 불필요한 추상화가 없는가?
+### Step 2: 판정 기준
+
+**블로커는 둘뿐이다 — 필수 완료 기준의 미충족, 그리고 정확성 · 보안 · 데이터 유실 · 무결성 · 사용성에 대한 입증된 중대 위험.** 완료 기준마다 충족 여부를 구현자의 요약이 아니라 산출물과 실행 결과로 확인한다. 위험을 어디서 찾을지는 변경의 종류가 정한다. 그 밖의 개선은 블로커와 섞지 않고 HIGH 이하로 따로 적는다 — 스타일 선호는 LOW 행 기준대로 거른다. 코드가 아닌 산출물(문서 · 계획 · UI · QA)도 같은 기준으로 판정한다.
+
+- 함수·파일 길이, 중첩 깊이는 **이 저장소의 관례에 비해** 눈에 띄게 큰지 본다 — 절대 숫자가 아니라 주변 코드와 비교하고, 관례를 따르는 코드에 리팩터를 요구하지 않는다.
 - 경우마다 분기 · 가드 · 복구를 덧댄 곳이 있다면, 그 경우들이 아예 생기지 않는 더 단순한 구조가 있는가?
-- 기존 패턴/컨벤션과 일치하는가?
-- 의존성 방향이 올바른가?
-- SPEC/PRD 범위 안에 있는가?
-
-#### Security (보안)
-- 하드코딩된 시크릿이 없는가?
-- 사용자 입력이 검증되는가?
-- SQL injection, XSS, CSRF 방어가 되어 있는가?
-- 인증/인가 확인이 있는가?
-- 에러 메시지가 민감 정보를 노출하지 않는가?
-
-#### Performance (성능)
-- N+1 쿼리가 없는가?
-- 불필요한 re-render가 없는가?
-- 캐싱이 필요한 곳에 적용되었는가?
-- 번들 크기에 영향을 주는가?
 
 ### 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
 
@@ -96,11 +59,6 @@ File: path/to/file.ts:42
 Issue: 설명
 Fix: 해결 방향
 
-[HIGH] Title
-File: path/to/file.ts:78
-Issue: 설명
-Fix: 해결 방안
-
 ### Positive Observations
 - [무엇이 잘 되었는지]
 
@@ -110,16 +68,6 @@ Fix: 해결 방안
 - [ ] SPEC/PRD 범위 내
 ```
 
-## Document / UI / QA Review Mode
-
-코드가 아닌 산출물을 리뷰할 때:
-
-**문서/제안서**: 논리 흐름, 설득력, 요청 범위 커버리지, 실행 가능성
-**UI**: 시각 디자인 일관성, 접근성, 반응형, 사용자 경험
-**QA**: 테스트 커버리지, 엣지케이스, 회귀 테스트, E2E 시나리오
-
-산출물 유형에 따라 적절한 기준을 자동 적용한다.
-
 ## Anti-Patterns (하지 말 것)
 
 - 코드를 쓰지 않는다 — Fix 는 방향만 적고, 수정은 구현 에이전트가 한다.

package/templates/rules/htmx-fastapi-ui.md

@@ -0,0 +1,36 @@
+---
+paths:
+  - "**/*.html"
+  - "**/*.jinja"
+  - "**/*.jinja2"
+  - "**/*.j2"
+---
+
+# htmx UI — FastAPI 템플릿
+
+FastAPI 가 렌더하는 htmx 화면(Jinja·HTML)은 Tailwind v4 + daisyUI 클래스(`btn` · `card` · `bg-base-100`)로 만든다. 다른 CSS 체계나 Tailwind v3 이면 바꾸기 전에 묻는다. 없으면 첫 UI 작업 때 `https://daisyui.com/docs/install/` 대로 설치한다.
+
+`@shadcn/lint` 는 템플릿을 못 읽으니 ast-grep(`pip install ast-grep-cli`)으로 검사한다. 없으면 아래 두 파일을 프로젝트 루트에 만들고 lint 명령에 `ast-grep scan` 을 더한다. UI 를 바꾼 뒤 돌려 보고된 줄을 고친다 — 오타·없는 클래스는 못 잡는다.
+
+`sgconfig.yml`:
+
+```yaml
+ruleDirs: [rules]
+languageGlobs: { html: ["*.jinja", "*.jinja2", "*.j2"] }
+```
+
+`rules/tailwind.yml`:
+
+```yaml
+id: tailwind-tokens
+language: html
+severity: error
+message: 원색 팔레트·임의 값·인라인 style 대신 daisyUI 테마 색·스케일 값·클래스를 쓴다
+rule:
+  any:
+    - kind: attribute_value
+      regex: (^|[^\w-])[a-z-]+-(slate|gray|zinc|neutral|stone|red|orange|amber|yellow|lime|green|emerald|teal|cyan|sky|blue|indigo|violet|purple|fuchsia|pink|rose)-(50|[1-9]00|950)(/\d+)?([^\w-]|$)
+      inside: &class { kind: attribute, has: { kind: attribute_name, regex: ^class$ }, stopBy: end }
+    - { kind: attribute_value, regex: '-\[[^\]]+\]', inside: *class }
+    - { kind: attribute, has: { kind: attribute_name, regex: ^style$ } }
+```

package/templates/rules/htmx-fastify-ui.md

@@ -0,0 +1,9 @@
+---
+paths:
+  - "**/*.tsx"
+  - "**/*.jsx"
+---
+
+# htmx UI — Fastify 서버 JSX
+
+Fastify 가 렌더하는 htmx 화면은 서버 JSX 템플릿(`.tsx`, 예: `@kitajs/html`)으로 쓰고 Tailwind v4 + daisyUI 클래스(`btn` · `card` · `bg-base-100`)로 만든다 — 브라우저 React 가 아니라 shadcn/ui 는 안 쓴다. 다른 템플릿 엔진·CSS 체계나 Tailwind v3 이면 바꾸기 전에 묻는다. 없으면 첫 UI 작업 때 `https://daisyui.com/docs/install/` 대로 설치하고, 린터 `@shadcn/lint` 는 `https://github.com/shadcn-ui/lint/blob/main/SETUP.md` 대로 등록한 뒤 켤 규칙을 사용자와 정한다(`class` 속성도 검사하고 daisyUI 클래스를 안다). UI 를 바꾼 뒤 lint 를 돌려 고친다.

package/templates/rules/ship-checklist.md

@@ -2,10 +2,10 @@
 
 무엇으로 검증할지는 이 저장소가 정한다. **어느 정도까지**는 Testing 룰이, 그 결과가 **언제** 있어야 하는지는 이 룰이 정한다.
 
-- **검증의 리듬**: 구현 중에는 변경 부분의 빠른 검사만 한다. 사용자 씬의 수정분이 모였을 때가 독립 검토를 **판단하는** 시점이다 — 걸지는 아래 머지 전 기준으로 정한다. 수정이 끝난 뒤 통합 테스트 · 빌드 · 실제 사용자 흐름을 검증한다. 작은 수정마다 전체 검증을 반복하지 않고, 재검사는 영향받은 부분만 한다.
+- **검증의 리듬**: 구현 중에는 변경 부분의 빠른 검사만 한다. 사용자 씬의 수정분이 모였을 때가 독립 검토를 **판단하는** 시점이다 — 걸지는 아래 머지 전 기준으로 정한다. 수정이 끝난 뒤 통합 테스트 · 빌드 · 실제 사용자 흐름을 검증한다. 작은 수정마다 전체 검증을 반복하지 않고, 재검사는 영향받은 부분만 한다. 계획·위임문에 적었다는 것만으로는 검증을 넓히지 않는다.
 - **머지 전 독립 검증**은 핵심 사용자 기능 · 되돌리기 어려운 변경 · 돈·권한처럼 틀리면 큰 사고인 것에만 건다. UX 의 큰 변경은 사용자 페르소나 리뷰(선택). 그 밖(테스트 하네스 · 문서 · 리팩터 · 문구 · UI · 리뷰어 처방)은 리그레션 테스트로 들어온다. 독립 검증의 판정은 만든 쪽이 아니라 검증자가 요구사항·변경분·결과를 직접 확인하고 내린다. 어느 쪽이든 변경 위험에 맞는 검증을 **실행하고 결과를 확인한다** — high risk 는 더 많은 증거를 갖고 들어오고, **실행하지 않은 상태는 통과가 아니다.** 필수 보안 · 데이터 보호 검사는 유지한다.
 - **배포**: 배포 전에 풀 테스트 · E2E 를 거친다(Testing 룰의 CI/CD 일정 몫). 독립 검증은 **단계가 아니라** 머지 전과 같은 기준(영향 · 불확실성 · 복구 비용 · 이미 있는 증거)으로 판단한다 — 배포라는 이유로 다시 걸지 않는다. 머지 전에 검증된 것과 **같은 artifact** 를 내보내고, 배포 뒤 실제 환경에서 smoke · health · 핵심 기능을 확인한다.
-- **머지·게시 경로가 그 검증 통과에 의존해야 한다.** 별개 경로면 아무도 우회하려 하지 않았는데 red 가 그대로 나간다. 의존하지 않는 상태를 발견하면 경로를 고치기 전에 먼저 보고한다.
+- **머지·게시 경로가 위 기준대로 고른 검증과 저장소의 필수 체크 통과에 의존해야 한다.** 별개 경로면 아무도 우회하려 하지 않았는데 red 가 그대로 나간다. 의존하지 않는 상태를 발견하면 경로를 고치기 전에 먼저 보고한다.
 - 변경분이 사용자에게 닿는 경로가 여럿이면 **경로마다 실행 증거를 따로** 확보한다. 한 경로의 증거를 다른 경로에 전용하지 않는다.
 - 이 저장소가 정의한 **보안·취약점 검사도** 실행하고 결과를 확인한다 — 테스트만 돌리고 나가는 것이 기본값이 되기 쉽다.
 - 추적 문서가 코드와 어긋난 채로 나가지 않게 한다. **이 하네스가 설치해 둔 검사기**를 쓴다(스스로는 존재를 알 수 없으므로 여기 적는다): `bash .uzys-agent-harness/spec-drift-check.sh ship` — **exit 2 면 차단**(동기화 후 재시도), 1 은 경고, 0 이 통과. 백로그는 `ship-gate:ignore` 구간으로 감싸 면제한다(표식이 안 닫히면 면제를 통째로 무시한다).

package/templates/rules/test-policy.md

@@ -3,9 +3,10 @@
 **How far** to verify scales with the risk of the change; **when** those results must exist
 belongs to the Delivery rule.
 
-- An ordinary change gets the repository's baseline CI and regression across the affected scope;
-  independent verification only where the Delivery rule requires it. A high-risk one widens that in
-  proportion to what it touches and what its failure would cost.
+- An ordinary change gets static checks and regression across the affected scope — not the whole
+  suite merely because the repository's CI runs it; independent verification only where the
+  Delivery rule requires it. A high-risk one widens that in proportion to what it touches and what
+  its failure would cost.
 - Preserve required outcomes with the least burdensome reliable protection.
   Prefer fixing the cause and reusing or improving existing mechanisms within scope;
   no new guard is needed when those suffice. Judge safeguards by credible risk,
@@ -29,4 +30,6 @@ belongs to the Delivery rule.
   adding indiscriminate retries. Correct or consolidate tests when their expectations are
   wrong, obsolete, or redundant; preserve coverage of the accepted contract and follow project
   policy for changes to mandatory gates.
-- If the affected scope cannot be established confidently, broaden the validation.
+- If the affected scope cannot be established confidently, widen along what the change shares
+  (callers, data, configuration), not to the whole suite by default. After an environment or CI
+  fix, rerun what failed and what the fix could affect.

package/templates/skills/audit-harness-fit/references/apply.md

@@ -38,7 +38,12 @@ markers/imports. Modify the canonical editable source within authorization. Pres
 unrelated text, local customizations, headings, language, and formatting. Synchronize
 mirrors only where ownership, synchronization contract, and scope are established.
 When an installer would overwrite a local fix, report the source/integration change
-needed; generator changes belong to a separately authorized task.
+needed; generator changes belong to a separately authorized task. When re-applying
+edits saved in an update backup, move them to a project-owned place that update leaves
+alone and that gives the same behavior — such as the project's own part of CLAUDE.md /
+AGENTS.md outside the harness block for guidance — and confirm the agent loads or runs it.
+If no such place exists for that asset, report the limit. Not back into the harness-owned
+file: the next update replaces it again and keeps the edit only as a backup.
 
 Keep removed content recoverable. Clean tracked content can use existing history;
 dirty or untracked content needs an authorized snapshot. Store snapshots outside

package/templates/skills/audit-harness-fit/references/verification.md

@@ -72,6 +72,11 @@ Explicit project policy can bind even without CI enforcement. Preserve those gat
 route disproportionate mandatory requirements to a separate policy decision. Retain
 an unclear gate pending clarification while continuing work independent of it.
 Generic requests to "think again" are assessed for evidence value, not presumed gates.
+Check project gates against the stage schedule: a merge gate that waits for every CI
+check where CI runs the whole suite, or an evidence rule that voids every result when
+the tree changes, turns each change into a full run. Report that conflict as a policy
+decision without silently adding full-suite gates, standing a local run in for a required
+remote check, or weakening protections.
 Document-only effects normally need document checks unless policy or dependencies
 require more. State checks not run and the resulting limits.
 

package/templates/skills/objective-brief/SKILL.md

@@ -192,7 +192,9 @@ question nobody will answer.
 **success_criteria** — prefer conditions someone else can check by running something or looking at
 something. Counts and numbers inside the criteria get compared literally, so verify them against
 reality before writing them; a criterion that says "all 12 cases pass" when there are 11 cases
-makes the worker either invent a case or report failure.
+makes the worker either invent a case or report failure. Verification items follow the
+project's policy for that stage; add checks for the task's risk or the user's request, not
+broader gates.
 
 **verification / communication** — the `[N줄]` caps are meant to be replaced with a real number.
 Leaving the placeholder in tells the worker nothing, and an uncapped handoff drifts into a report

package/templates/track-mcp-map.tsv

@@ -16,7 +16,7 @@
 # 신규 MCP 추가 시: 이 파일에 1줄 추가만 하면 setup-harness.sh 수정 불필요.
 # 주석 (#) 라인은 무시.
 context7	*	npx	["-y", "@upstash/context7-mcp@latest"]
-railway-mcp-server	csr-supabase|csr-fastify|csr-fastapi|ssr-htmx|full	url	{"url":"https://mcp.railway.com"}
+railway-mcp-server	csr-supabase|csr-fastify|csr-fastapi|ssr-htmx|ssr-htmx-fastify|full	url	{"url":"https://mcp.railway.com"}
 supabase	csr-supabase|full	url	{"url":"https://mcp.supabase.com/mcp"}
 chrome-devtools	csr-*|ssr-*|full	npx	["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]
 vercel	-	url	{"url":"https://mcp.vercel.com"}