@uzysjung/agent-harness 26.112.0 → 26.113.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@uzysjung/agent-harness",
|
|
3
|
-
"version": "26.
|
|
3
|
+
"version": "26.113.0",
|
|
4
4
|
"description": "Curate vetted AI-coding skills & plugins by your tech stack — install only what you need, across Claude Code, Codex, OpenCode & Antigravity",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"publishConfig": {
|
|
@@ -164,6 +164,19 @@ it. How that plays out per lane:
|
|
|
164
164
|
This pairs with, not replaces, deterministic gates (tests, typecheck, CI) — the verifier
|
|
165
165
|
judges what automation can't: spec fit, missed edge cases, design drift.
|
|
166
166
|
|
|
167
|
+
**Verdict vocabulary (fixed).** A verifier's report never ends in free prose — it ends with
|
|
168
|
+
exactly one verdict, `PASS` / `PASS_WITH_NITS` / `FAIL`, and every finding carries one
|
|
169
|
+
severity label, `CRITICAL` / `HIGH` / `MEDIUM` / `LOW` (full contract: the verification-loop
|
|
170
|
+
skill's Verdict Contract). Two consequences for orchestration:
|
|
171
|
+
|
|
172
|
+
- **FAIL closes only on re-verification.** Fix → re-verify is one cycle; if the same
|
|
173
|
+
reviewer will re-verify, keep it alive via SendMessage and *declare* that intent
|
|
174
|
+
(worker lifecycle) — otherwise spawn a fresh verifier.
|
|
175
|
+
- **PASS_WITH_NITS is not silent PASS.** Its LOW/MEDIUM findings come back to the
|
|
176
|
+
orchestrator as recorded follow-ups, not as buried prose — deciding their fate is an
|
|
177
|
+
orchestrator judgment call, never the verifier's. (The name says nits, but the tier it
|
|
178
|
+
covers is LOW **and** MEDIUM.)
|
|
179
|
+
|
|
167
180
|
## Orchestrator handoff (quota exhaustion)
|
|
168
181
|
|
|
169
182
|
When the top-tier orchestrator's quota runs out mid-project, **Opus @ `max` takes over
|
|
@@ -203,6 +216,7 @@ build on. Hand off manually:
|
|
|
203
216
|
→ 오케스트레이터(Fable) 직접
|
|
204
217
|
기획·스펙·계획 문서 작성·관리 / 핵심 구현 / V&V
|
|
205
218
|
→ opus @ xhigh (또는 max) — pinned role 또는 Workflow opts
|
|
219
|
+
V&V 판정 → PASS | PASS_WITH_NITS | FAIL + CRITICAL~LOW (verification-loop 계약)
|
|
206
220
|
반복 구현 / E2E 테스트 / 리서치 스윕
|
|
207
221
|
→ sonnet @ high 이상
|
|
208
222
|
결정적 변환 (rename·포맷) → 모델 위임 금지 — sed/grep/스크립트 직접
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: verification-loop
|
|
3
|
-
description: "A comprehensive verification system for Claude Code sessions."
|
|
3
|
+
description: "A comprehensive verification system for Claude Code sessions. Every run ends with a fixed verdict — PASS / PASS_WITH_NITS / FAIL — plus severity-labeled findings (CRITICAL/HIGH/MEDIUM/LOW)."
|
|
4
4
|
origin: ECC
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -26,7 +26,9 @@ npm run build 2>&1 | tail -20
|
|
|
26
26
|
pnpm build 2>&1 | tail -20
|
|
27
27
|
```
|
|
28
28
|
|
|
29
|
-
If build fails, STOP and fix
|
|
29
|
+
If build fails, STOP and fix — then re-verify from Phase 1 in a fresh instance. Continuing
|
|
30
|
+
through the remaining phases yourself would make you the verifier of code you just wrote,
|
|
31
|
+
which the Verdict Contract below forbids.
|
|
30
32
|
|
|
31
33
|
### Phase 2: Type Check
|
|
32
34
|
```bash
|
|
@@ -100,13 +102,43 @@ Tests: [PASS/FAIL] (X/Y passed, Z% coverage)
|
|
|
100
102
|
Security: [PASS/FAIL] (X issues)
|
|
101
103
|
Diff: [X files changed]
|
|
102
104
|
|
|
103
|
-
|
|
105
|
+
Verdict: PASS | PASS_WITH_NITS | FAIL
|
|
104
106
|
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
107
|
+
Findings:
|
|
108
|
+
| ID | Severity | Finding | Evidence (file:line / command output) |
|
|
109
|
+
|----|----------|---------|---------------------------------------|
|
|
110
|
+
| F1 | HIGH | ... | ... |
|
|
108
111
|
```
|
|
109
112
|
|
|
113
|
+
## Verdict Contract
|
|
114
|
+
|
|
115
|
+
The report ends with exactly one verdict. Free-prose closings ("looks ready", "should be
|
|
116
|
+
fine") are banned — they leave room to bury defects. A fixed vocabulary makes the report
|
|
117
|
+
honest and machine-checkable.
|
|
118
|
+
|
|
119
|
+
| Verdict | Meaning | Action |
|
|
120
|
+
|---------|---------|--------|
|
|
121
|
+
| **PASS** | All gates green, zero findings at any severity | Ship |
|
|
122
|
+
| **PASS_WITH_NITS** | Ship-safe: only LOW/MEDIUM findings, each recorded with a follow-up | Ship + log follow-ups |
|
|
123
|
+
| **FAIL** | Any gate red, or one or more CRITICAL/HIGH findings | Block → fix → **re-verify** |
|
|
124
|
+
|
|
125
|
+
Every finding gets exactly one severity:
|
|
126
|
+
|
|
127
|
+
- **CRITICAL** — data loss, security hole, or the change misbehaves in real use if shipped
|
|
128
|
+
- **HIGH** — main-path defect or regression; users will hit it
|
|
129
|
+
- **MEDIUM** — edge-case or quality defect; unlikely to block real use
|
|
130
|
+
- **LOW** — nit: style, naming, doc wording
|
|
131
|
+
|
|
132
|
+
Rules:
|
|
133
|
+
- Severity is judged by impact evidence, not by how easy the fix is.
|
|
134
|
+
- FAIL → fix → re-verify is one cycle. A fix alone never upgrades the verdict — the
|
|
135
|
+
re-verification must reproduce green.
|
|
136
|
+
- A run that aborts early (Phase 1 build failure) still emits a report: verdict **FAIL**
|
|
137
|
+
with the failing gate as a CRITICAL finding. Stopping to fix is how you *reach* the next
|
|
138
|
+
verdict, not a reason to skip issuing this one — an unreported run reads as "not run".
|
|
139
|
+
- The instance that wrote the change never issues its own verdict: verification runs in a
|
|
140
|
+
fresh instance (see the model-orchestration skill's V&V separation).
|
|
141
|
+
|
|
110
142
|
## Continuous Mode
|
|
111
143
|
|
|
112
144
|
For long sessions, run verification every 15 minutes or after major changes:
|