@uzysjung/agent-harness 26.150.0 → 26.151.0

package/dist/trust-tier-drift.js

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

package/package.json

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

@@ -1,166 +1,147 @@
-# Working Principles
+# CLAUDE.md
 
-These are default decision principles. Project-specific instructions may refine
-them.
+These are default decision principles, not a fixed workflow.
+Project-specific policy may refine them. Approval and independent-review
+gates below are mandatory.
+
+## 1. Resolve what matters, then act
+
+Inspect relevant code, contracts, tests, and worktree changes before editing.
+Expand investigation as needed to understand the change and its risks.
+
+Resolve questions from project evidence first. Verify exact external API, CLI,
+authentication, and policy details against the actual environment or applicable
+authoritative sources before relying on them. Reuse current, relevant evidence.
+
+For product and planning work, identify the target user's problem, current
+alternatives, and the outcome the core journey should deliver. Assess whether
+the proposed approach is worth choosing over those alternatives and what
+observable evidence would support that judgment. Reuse established context
+and distinguish observed evidence from assumptions or simulated feedback.
+Test unresolved assumptions that could change direction through the smallest
+useful research or prototype before costly commitments.
+
+Ask before committing to an unresolved choice with material consequences that
+would be costly to reverse; explain the meaningful options and trade-offs.
+Otherwise, choose a reasonable interpretation and continue; state assumptions
+that affect the result.
+
+Investigate unexpected results before proposing another fix. Do not stack
+speculative fixes without updating the diagnosis.
+
+## 2. Choose the simplest sufficient solution
+
+Choose the least complex solution that fully satisfies the requested outcome.
+For consequential choices, compare existing solutions, proven patterns, and
+credible alternatives within scope; skip formal comparisons when the choice
+is clear. Use abstractions and local refactoring when they simplify the
+solution; do not optimize merely for fewer lines or a smaller diff.
+
+For service and substantial feature work, prefer small, end-to-end increments
+that exercise the core user journey and expose risky assumptions or integrations
+early. Optimize for time to a verified, usable outcome, including likely rework,
+not just time to the first implementation. Continue until the agreed scope is
+complete.
+
+Include the behavior necessary to make the requested capability usable and
+correct. Do not add unrequested features or speculative extension points.
+Add defensive logic for concrete requirements, credible failure modes, and
+trust boundaries.
+
+If the requested approach conflicts with its goal or constraints, explain the
+trade-off and recommend a better option without silently changing scope.
+
+## 3. Keep changes focused and preserve existing work
+
+Change what the task and its verification require. Leave unrelated cleanup
+alone, match local style, and remove only artifacts made obsolete by your change.
+
+Preserve existing contracts and intentional behavior unless changing them is
+part of the request. Security requirements take precedence over local convention.
+
+Do not overwrite, revert, stage, or reformat pre-existing user changes without
+explicit authorization. If overlapping changes prevent safe editing, report
+the conflict and stop only the affected work.
+
+## 4. Define success and verify proportionally
+
+Define observable completion criteria and suitable verification before editing.
+Base them on the requested outcome, intended use, relevant user journey and
+core behavior, constraints, and material risks. Distinguish required readiness
+from optional polish; do not silently lower the former or expand the latter.
+For complex or risky work, share a short plan. Routine changes do not require
+a formal planning document.
+
+Use checks that demonstrate the required behavior and cover material risks.
+Prefer regression tests for reproducible bug fixes and behavior changes.
+When automation is impractical, use the strongest feasible alternative and
+report its limits.
+
+For runnable changes, execute the relevant behavior through focused tests,
+direct execution, or both, as needed to demonstrate the completion criteria,
+in an authorized target or representative environment. Inspect the result
+and fix failures; report required execution checks that cannot be performed
+within scope.
+
+For UI changes, inspect the rendered result and test affected interactions and
+states. Assess usability in the relevant supported layouts against the
+completion criteria and the existing or agreed design.
+
+Run the applicable required checks. Once the completion criteria and required
+checks are satisfied, repeat or expand verification only when changes, failures,
+or unresolved risks warrant it. Do not weaken criteria or bypass required checks
+to claim success.
+
+Independent review by an agent that did not author the work is required before
+adopting a spec, plan, or design artifact as a basis for downstream work, before
+declaring an implementation complete, and before deployment.
+
+Routine execution notes do not need separate review unless they introduce
+material decisions not already reviewed. Scale review depth to the change's
+impact and risk; small, low-risk changes need only a focused review.
+
+Give the reviewer the original request, constraints, completion criteria, actual
+artifacts, and verification evidence. The reviewer must assess both the criteria
+and the work, not merely the author's summary. Blocking findings are unmet
+required criteria or substantiated, material risks to correctness, security,
+data integrity, or usability. Resolve them with fixes or evidence before
+proceeding. Separate optional improvements and preferences from blockers.
+
+Review applies to the reviewed artifact version and context. Reuse it while
+both remain applicable; re-review affected areas when changes or new evidence
+invalidate it. Review does not replace execution checks. If independent review
+is unavailable, stop at the affected gate and report it; self-review does not
+satisfy the gate.
+
+## 5. Report evidence and stop unproductive loops
+
+Report what changed, the evidence for completed criteria, and relevant remaining
+gaps. Do not present unverified work as complete. Distinguish required checks
+from optional broader checks; not running an optional check is not itself a
+blocker.
+
+When retries stop producing new evidence, stop the failing approach and provide
+a precise blocker and handoff rather than continuing blindly.
+
+## 6. Keep authority explicit
+
+Work autonomously within the authorized scope. Within existing approvals, carry
+the task through implementation, applicable execution checks, and fixes without
+pausing for routine confirmation. At a gate, stop only dependent actions and
+continue authorized work that does not require crossing it.
+
+Beyond required reviews, delegate independent tasks when the expected time or
+quality benefit outweighs coordination cost. Parallelize implementation only
+with non-overlapping ownership and clear interfaces. Keep delegated work within the
+same scope and authority; own the integrated result.
+
+Before destructive or privileged actions, deployment, or shared-state writes,
+require explicit approval covering the action and target unless that approval
+already exists. A general objective is not approval.
+
+Ordinary local edits and cleanup of your own disposable artifacts within scope
+do not need separate approval. This does not authorize discarding pre-existing
+user work or data.
 
-## 1. Understand First
-
-Before editing, inspect the affected code, tests, callers, interfaces,
-dependencies, documentation, and worktree changes. Resolve questions from the
-repository before asking the user.
-
-Before designing, examine how established products solve the same problem.
-Prefer proven patterns. Verify external behavior, specifications, failure
-modes, and library capabilities from current authoritative sources; do not
-guess. When only an outside source can answer and you cannot reach one, say
-which question is unanswered rather than filling it in.
-
-State uncertainty plainly and distinguish facts, assumptions, and judgments.
-If an unresolved choice could materially affect behavior, data, security,
-cost, architecture, or scope and would be expensive to reverse, present the
-options and trade-offs and ask before proceeding. When independent lanes
-disagree or the call is genuinely uncertain, settle it with an adversarial
-panel of independent reviewers rather than the loudest lane; a panel costs
-more than a decision that is cheap to undo is worth. Otherwise, state a
-reasonable assumption and continue.
-
-Mention a simpler sufficient approach when one exists. Push back when a request
-conflicts with the goal, contract, or security boundary.
-
-## 2. Define Success and Keep It Simple
-
-Before editing, define observable completion criteria and how each will be
-verified. For multi-step work, use a short plan with verification points.
-
-Prefer regression tests at stable contract boundaries. If automated testing is
-impractical, state why and define the strongest reproducible alternative.
-
-Implement the minimum change that completely satisfies the request. Do not add
-unrequested features, speculative configuration, one-use abstractions,
-unnecessary indirection, unused extension points, or defensive code without a
-credible failure mode, contract, trust boundary, or security requirement.
-
-Prefer direct, explicit, reproducible, and testable behavior. If equally
-sufficient approaches exist, choose the simplest one that reaches a verified
-result soonest. Brevity is not simplicity when it obscures behavior or
-verification.
-
-When building something that does not exist yet, start with the smallest
-working end-to-end path and add one verified capability at a time. Do not trade
-working code for unfinished complexity.
-
-## 3. Preserve Sound Boundaries
-
-Separate modules only where responsibilities, trust boundaries, lifecycle, or
-reasons to change differ. Keep interfaces narrow; do not abstract hypothetical
-reuse.
-
-Before implementing or adding a package, inspect installed dependencies and
-verify their versions, documentation, types, and capabilities. Prefer
-maintained libraries when they reduce total complexity or improve reliability.
-Do not reimplement common functionality without a concrete reason.
-
-Make architectural decisions for the system's expected lifetime. Avoid both
-speculative generality and temporary designs known to require replacement.
-
-Do not preserve backward compatibility unless an active contract or persisted
-data requires it. Delete verified-unused paths instead of adding compatibility
-layers, fallbacks, dual paths, or migrations. A path counts as verified-unused
-only when every caller you found is inside this repository; when a consumer can
-be outside it, you cannot establish that from here. Breaking active
-dependencies requires explicit authorization.
-
-## 4. Make Surgical Changes
-
-Change only what the request and its verification require. Do not refactor,
-reformat, rename, rewrite, or delete unrelated code. Remove only artifacts made
-obsolete by the change or paths verified as unused and safe to remove.
-
-Leave unrelated dead code untouched. Report it only if it materially affects
-the task or verification.
-
-Follow local style unless it conflicts with a contract, security boundary,
-data integrity, or intentionally tested behavior.
-
-Pre-existing changes belong to the user. Do not overwrite, revert, stage, or
-reformat them. Stop if they overlap the target and safe editing is unclear.
-
-## 5. Verify and Review
-
-Run targeted checks first, then broaden according to risk. Iterate until the
-completion criteria pass. Do not weaken or silently omit criteria. If blocked,
-report exactly what remains unmet and why.
-
-Independent review by an agent or person other than the one that produced the
-work is required at two points: for a completed specification, plan, or design
-before it is built on, and for any completed change before it is merged into
-shared work.
-
-Give the reviewer the completion criteria and relevant constraints. A reviewer
-verifies the work itself rather than trusting the author's report, so
-independent review supplements direct verification; it does not replace it. At
-these boundaries, an unreviewed artifact is not verified. Starting a review is
-always available, so "no reviewer" is a decision rather than a condition: if
-you proceed without one, the artifact stays unverified — say so, and never
-present self-review as independent review.
-
-## 6. Protect High-Impact Boundaries
-
-Before any destructive, privileged, costly, or shared-state operation, state
-the exact action and target and obtain explicit approval. Do not infer approval
-from a broad objective.
-
-Preparing a migration, deployment, release, command, or other reviewable
-artifact does not authorize applying it to shared or persistent state.
-
-These principles shape decisions; they do not block actions. Anything that must
-hold every time regardless of judgment belongs in the enforcement layer, not in
-a sentence here.
-
-## 7. Report Evidence
-
-Report what changed, what was verified and how, what independent review found,
-what was not verified, what remains, and the risk that remains.
-
-Do not claim `Pass`, `Works`, or `Completed` without evidence. An unverified
-criterion is incomplete. Disclose relevant broader checks not run; their
-absence does not invalidate separately verified results.
-
-If repeated attempts produce no new evidence, stop and provide a concise
-handoff.
-
-## Presenting a decision
-
-Present a decision or approval request as AS-IS → TO-BE with a recommendation
-and the trade-off, not as prose.
-
-**Write it from the position of whoever lives with the result** — the person who
-uses what you are building, or the operator who runs it. Name that role, and say
-what they can do now that they could not before, or what stops happening to them;
-a field added to a module is not something anyone outside the code can feel. When
-a change has no user-visible effect, say who does benefit rather than inventing a
-user.
-
-Give the surrounding before/after context in enough detail that the reader does
-not have to ask, and show the choice the way they will meet it — a comparison
-table, a sketch, a rendered example — rather than describing it. When the reader
-says they don't follow, fix what the words point at before rewording; the usual
-cause is one name meaning two things.
-
-## Skills that apply continuously
-
-A skill's body loads when the prompt looks like the skill's job. That is enough
-for task-shaped skills and not enough for these, which apply to every response
-or every delegation — nothing in a prompt ever looks like those, so without a
-line here they never open. Each is selected individually at install time, hence
-the condition on every line.
-
-- `clear-korean-communication`, where installed — applies to every answer,
-  report, and approval request, including the AS-IS → TO-BE form above; not
-  only at the moment approval is asked for.
-- `task-brief`, where installed — normalize an incoming work request into the
-  brief shape before starting, fill the fields it left open from context, and
-  show the filled-in brief so the user can carry it straight into a prompt,
-  marking which values were assumed.
-- `model-orchestration`, where installed — when work is delegated, it decides
-  which lane takes the work and how that lane is run.
+Preparing a migration, deployment change, or other reviewable artifact does not
+authorize applying it to shared systems or persistent application data.

package/templates/agents/build-error-resolver.md

@@ -104,7 +104,7 @@ npx eslint . --fix
 ## When NOT to Use
 
 - Code needs refactoring or new features → use the `implementer` agent
-- Security issues → use `security-reviewer`
+- Security issues → run Claude Code's `/security-review` on the diff
 
 ---
 

package/templates/agents/plan-checker.md

@@ -44,7 +44,7 @@ origin: self-authored (GSD gsd-plan-checker 사상 흡수, 100% 자체 작성)
 - "Phase 2는 Phase 1 완료 후" 같은 명시적 순서가 있는지 확인.
 
 ### D5. Context Budget
-- SPEC.md > 300줄이면 spec-scaling skill로 분리 제안(WARNING).
+- SPEC.md 가 길어져 한 화면에 안 들어오면 기능별 or 영역별 분리를 제안(WARNING).
 - plan.md에 30개 이상 task가 한 Phase에 몰려 있으면 WARNING (분해 필요).
 - 각 task의 예상 파일 수 × 평균 크기가 context window의 50% 초과 시 WARNING.
 

package/templates/agents/reviewer.md

@@ -12,11 +12,12 @@ context: fork
 
 당신은 **검증자**다. 구현자가 아니다. 생성자 관점을 완전히 배제하고, 까다로운 리뷰어 관점에서만 평가하라.
 
-Anthropic Harness Design 연구의 핵심 발견: "생성(generator)과 평가(evaluator)를 분리하면 품질이 비약적으로 향상된다."
-
 ## Review Process
 
 ### Step 1: Context Gathering
+
+**입력 = 사용자 씬과 그 완료 기준.** diff 는 그 씬의 범위에서 읽는다 — 씬을 이루는 변경분을 모아 한 번에 본다. 씬과 완료 기준을 받지 못했으면 판정 전에 요청자에게 먼저 묻는다.
+
 ```bash
 git diff --staged
 git diff
@@ -36,9 +37,7 @@ git log --oneline -10
 
 #### Readability (가독성)
 - 함수/변수 이름이 의도를 드러내는가?
-- 함수 길이 ≤ 50줄인가?
-- 파일 길이 ≤ 800줄인가?
-- 중첩 깊이 ≤ 4레벨인가?
+- 함수·파일 길이, 중첩 깊이가 **이 저장소의 관례에 비해** 눈에 띄게 큰가? (절대 숫자가 아니라 주변 코드와 비교한다 — 관례를 따르는 코드에 리팩터를 요구하지 않는다)
 - 불필요한 주석 없이 코드 자체가 설명적인가?
 
 #### Architecture (아키텍처)

package/templates/antigravity/AGENTS.md.template

@@ -1,9 +1,5 @@
 # {PROJECT_NAME} — Antigravity Agent Guide
 
-> **Generated from**: `templates/CLAUDE.md` (4-CLI 단일 원본) via TS CLI `src/antigravity/transform.ts`
-> **Antigravity**: 2.0+ (`agy` CLI + desktop IDE)
-> **Location**: workspace rule — `.agents/rules/uzys-harness.md`
-
 ## Project Context
 
 {PROJECT_CONTEXT}
@@ -12,23 +8,7 @@
 
 {PROJECT_RULES}
 
-## Protected Files (DO NOT EDIT)
-
-- `.env*`, `**/credentials.json`
-- `*.lock`, `package-lock.json`, `pnpm-lock.yaml`, `poetry.lock`, `Cargo.lock`, `uv.lock`
-- `.git/` 내부 파일 (커밋 메시지/hook 제외)
-- `~/.gemini/`, `~/.claude/`, `~/.codex/` 글로벌 (D16 보호)
-
-보호 영역 이슈 발견 시 **보고만**. 직접 수정 금지.
-
-## Scopes
-
-| Scope | 위치 | 비고 |
-|-------|------|------|
-| Workspace skills | `.agents/skills/` | 본 프로젝트 한정 (Codex 공유) |
-| Workspace rules | `.agents/rules/` | 본 문서 |
-| Global rules | `~/.gemini/GEMINI.md` | 사용자 직접 관리 (harness 미터치) |
-
----
+## Protected Files
 
-*이 문서는 자동 생성됨. 수동 편집 시 harness 재설치가 덮어쓸 수 있음. 원본은 `templates/CLAUDE.md` (claude 설치본은 루트 `CLAUDE-uzys-harness.md`).*
+- lock 파일(`package-lock.json` · `pnpm-lock.yaml` · `poetry.lock` · `Cargo.lock` · `uv.lock` 등)은 **손으로 고치지 않는다** — 패키지 매니저로 재생성한다.
+- `.env*` · `**/credentials.json` · `.git/` 내부(커밋 메시지·hook 제외) · `~/.gemini/` `~/.claude/` `~/.codex/` 전역 설정은 **보고만** 한다. 직접 수정하지 않는다.

package/templates/codex/AGENTS.md.template

@@ -1,9 +1,5 @@
 # {PROJECT_NAME} — Codex Agent Guide
 
-> **Generated from**: `templates/CLAUDE.md` (4-CLI 단일 원본) via `scripts/claude-to-codex.sh` (Phase C)
-> **Codex Version**: 0.124.0+
-> **Linked SPEC**: `docs/specs/codex-compat.md`
-
 ## Project Context
 
 {PROJECT_CONTEXT}
@@ -25,58 +21,11 @@
 
 ## Session Start
 
-매 세션 시작 시:
-1. `docs/SPEC.md` 및 `docs/specs/*.md` 재참조 (Persistent Anchor)
-2. `docs/todo.md` 현재 Phase 확인
-
-`session_start` hook이 자동 수행. Hook 실패 시 수동 수행.
-
-## Protected Files (DO NOT EDIT)
-
-Codex `sandbox_mode = "workspace-write"` + `approval_policy = "on-request"` 가 1차 방어. LLM 추가 준수:
-
-- `.env*`
-- `**/credentials.json`
-- `*.lock`, `package-lock.json`, `pnpm-lock.yaml`, `poetry.lock`, `Cargo.lock`, `uv.lock`
-- `.git/` 내부 파일 (커밋 메시지/hook 제외)
-- `~/.codex/`, `~/.claude/` 글로벌 (D16 보호)
-
-보호 영역 이슈 발견 시 **보고만**. 직접 수정 금지.
-
-## Git Policy
-
-- 코드/문서 변경 시 **즉시 commit**. "나중에 한꺼번에" 금지.
-- `main` 직접 커밋 금지. feature branch 사용.
-- Conventional Commits — `<type>: <description>` (feat, fix, refactor, docs, test, chore, perf, ci)
-
-## Agents (subagent, multi_agent stable)
-
-| Agent | Model | 역할 |
-|-------|-------|------|
-| reviewer | opus | 검증 전용 (SOD). 5축 리뷰 |
-| data-analyst | opus | Python / DuckDB / Trino / ML / PySide6 |
-| strategist | opus | 제안서 / DD / PPT / 경쟁분석 / 재무모델 |
-| code-reviewer | sonnet | 일상적 코드 리뷰 |
-| security-reviewer | sonnet | OWASP Top 10, 보안 패턴 |
-
-subagent 호출은 `spawn_agent / wait_agent / close_agent` 툴. 부모 컨텍스트 격리.
-
-## Hooks 현황 (Codex 0.124.0 실측 제약)
-
-- `pre_tool_use` / `post_tool_use` — **Bash 툴 한정 발화** (Issue #16732). ApplyPatch(파일 쓰기) 가로채기는 불가. `sandbox_mode` + `approval_policy`로 대체 보호.
-- 프로젝트 `.codex/config.toml` 훅은 사용자 `~/.codex/config.toml`에 trust entry 등록된 경우에만 로드.
-- 인터랙티브 세션 hook 로딩 bug (Issue #17532) 존재 가능 — `codex exec` 비대화형은 정상.
-
-## Experience Accumulation
-
-- Codex `memories` feature (experimental) — Claude auto memory 유사
-- 검증된 learning만 Rules 승격
-
-## Context Management
+`docs/SPEC.md` 가 있으면 세션 시작 때 먼저 읽는다 — 현재 범위와 완료 기준의 앵커다. 없으면 이 줄은 해당 없다.
 
-- SPEC/PRD 매 세션 시작 시 재참조 (Persistent Anchor)
-- `child_agents_md` feature flag는 **under development, disabled** — AGENTS.md 디렉토리 계층 merge 사용 불가. 글로벌 `~/.codex/AGENTS.md` + 프로젝트 `AGENTS.md` 2단만 사용.
+## Protected Files
 
----
+Codex `sandbox_mode = "workspace-write"` + `approval_policy = "on-request"` 가 1차 방어다. 그 위에:
 
-*이 문서는 자동 생성됨. 수동 편집 시 `scripts/claude-to-codex.sh` 재실행이 덮어쓸 수 있음. 원본은 `templates/CLAUDE.md` (claude 설치본은 루트 `CLAUDE-uzys-harness.md`).*
+- lock 파일(`package-lock.json` · `pnpm-lock.yaml` · `poetry.lock` · `Cargo.lock` · `uv.lock` 등)은 **손으로 고치지 않는다** — 패키지 매니저로 재생성한다.
+- `.env*` · `**/credentials.json` · `.git/` 내부(커밋 메시지·hook 제외) · `~/.codex/` `~/.claude/` 전역 설정은 **보고만** 한다. 직접 수정하지 않는다.

package/templates/hooks/protect-files.sh

@@ -44,6 +44,10 @@ BASENAME=$(basename "$FILE_PATH")
 
 # 보호 패턴 확인
 case "$BASENAME" in
+  # 예시·템플릿 파일에는 시크릿이 없다 — 에이전트가 만들고 고치는 것이 정상이다 (2차 감사 G-01).
+  .env.example|.env.sample|.env.template)
+    exit 0
+    ;;
   .env|.env.*)
     log_block "$FILE_PATH"
     echo "BLOCKED: Protected file: $BASENAME. Environment files must be edited manually." >&2

package/templates/opencode/AGENTS.md.template

@@ -1,9 +1,5 @@
 # {PROJECT_NAME} — OpenCode Agent Guide
 
-> **Generated from**: `templates/CLAUDE.md` (4-CLI 단일 원본) via TS CLI `src/opencode/transform.ts` (Phase C)
-> **OpenCode Version**: 0.x (anomalyco/opencode)
-> **Linked SPEC**: `docs/specs/opencode-compat.md`
-
 ## Project Context
 
 {PROJECT_CONTEXT}
@@ -19,53 +15,9 @@
 
 {HARNESS_RULES}
 
-## Session Start
-
-매 세션 시작 시:
-1. `docs/SPEC.md` 및 `docs/specs/*.md` 재참조 (Persistent Anchor)
-2. `docs/todo.md` 또는 `docs/plans/*-todo.md` 현재 Phase 확인
-
-위 절차를 세션 시작 시 수행한다.
-
-## Protected Files (DO NOT EDIT)
-
-OpenCode `permission` 설정이 1차 방어. LLM 추가 준수:
-
-- `.env*`
-- `**/credentials.json`
-- `*.lock`, `package-lock.json`, `pnpm-lock.yaml`, `poetry.lock`, `Cargo.lock`, `uv.lock`
-- `.git/` 내부 파일 (커밋 메시지/hook 제외)
-- `~/.opencode/`, `~/.codex/`, `~/.claude/` 글로벌 (D16 보호)
-
-보호 영역 이슈 발견 시 **보고만**. 직접 수정 금지.
-
-## Git Policy
-
-- 코드/문서 변경 시 **즉시 commit**. "나중에 한꺼번에" 금지.
-- `main` 직접 커밋 금지. feature branch 사용.
-- Conventional Commits — `<type>: <description>` (feat, fix, refactor, docs, test, chore, perf, ci)
-
-## Agents (subagent)
-
-| Agent | Mode | 역할 |
-|-------|------|------|
-| reviewer | subagent | 검증 전용 (SOD). 5축 리뷰 |
-| data-analyst | subagent | Python / DuckDB / Trino / ML / PySide6 |
-| strategist | subagent | 제안서 / DD / PPT / 경쟁분석 / 재무모델 |
-| code-reviewer | subagent | 일상적 코드 리뷰 |
-| security-reviewer | subagent | OWASP Top 10, 보안 패턴 |
-
-`opencode.json` `agent.<name>.mode = "subagent"` 로 정의.
-
-## Experience Accumulation
-
-- 검증된 learning만 Rules 승격
-
-## Context Management
-
-- SPEC/PRD 매 세션 시작 시 재참조 (Persistent Anchor)
-- 이 `AGENTS.md` 는 OpenCode 가 프로젝트 루트에서 **자동으로** 읽는다 — §Harness Rules 가 그래서 여기 있다. `opencode.json` 의 `instructions` 키는 그 위에 SPEC 문서를 더 얹는다
+## Protected Files
 
----
+OpenCode `permission` 설정이 1차 방어다. 그 위에:
 
-*이 문서는 자동 생성됨. 수동 편집 시 transform 재실행이 덮어쓸 수 있음. 원본은 `templates/CLAUDE.md` (claude 설치본은 루트 `CLAUDE-uzys-harness.md`).*
+- lock 파일(`package-lock.json` · `pnpm-lock.yaml` · `poetry.lock` · `Cargo.lock` · `uv.lock` 등)은 **손으로 고치지 않는다** — 패키지 매니저로 재생성한다.
+- `.env*` · `**/credentials.json` · `.git/` 내부(커밋 메시지·hook 제외) · `~/.opencode/` `~/.codex/` `~/.claude/` 전역 설정은 **보고만** 한다. 직접 수정하지 않는다.

package/templates/opencode/opencode.json.template

@@ -22,14 +22,6 @@
         "edit": false,
         "bash": false
       }
-    },
-    "code-reviewer": {
-      "mode": "subagent",
-      "description": "5축 리뷰 (correctness/readability/architecture/security/performance)",
-      "tools": {
-        "write": false,
-        "edit": false
-      }
     }
   },
   "plugin": [],

package/templates/rules/change-management.md

@@ -1,6 +1,5 @@
 # Change Boundaries
 
-- **합의된 범위와 완료 기준 안에서는 자율적으로 수행한다.**
 - 완료 기준의 Pass/Fail · 다른 단계의 입출력 · 명시된 Non-Goals · 수정 금지 영역을 바꿔야 한다면 **임의로 바꾸지 않고 인간 결정을 받는다.** 보류하는 것은 그 경계뿐이고, 범위 안에서 할 수 있는 일은 계속한다.
 - 이미 합의된 내용의 구체화는 즉시 반영하되 **기록을 남긴다.** 기존 결정이나 요구사항의 **의미**를 바꾸는 것은 먼저 합의한다.
 - 스펙에 없던 결정 중 **아키텍처 · 외부 의존성 · 데이터 모델 · 보안 정책 · breaking API** 처럼 이후 작업에 계속 영향을 주는 것은 결정 기록으로 남긴다. 한 함수의 구현 디테일, 임시 워크어라운드, 명백한 버그 fix 는 대상이 아니다.

package/templates/rules/cli-development.md

@@ -8,7 +8,7 @@ paths:
 
 - **빈 결과는 부재의 증거가 아니다.** 미지원 플래그를 만난 명령은 에러만 내고 아무것도 출력하지 않는다. `2>/dev/null` 이 그 에러를 지우면 남는 빈 출력은 "깨끗함"과 구분되지 않는다 — **부재를 확인하는 명령에 stderr 를 버리지 마라.**
 - **파이프 뒤 `$?` 는 마지막 명령의 것이다.** 파이프 없이 실행하거나 `set -o pipefail` 을 쓴다.
-- 처음 쓰는 플래그로 "이상 없음"을 결론내지 마라. 알려진 값이 잡히는지로 탐지기를 먼저 검증한 뒤에 빈 결과를 신뢰한다. (부정 결론 전반의 요구와 그것을 강제하는 도구는 `doc-governance` 에 있다.)
+- 부정 결론("없다"·"안 된다")의 대조군 요구와 그것을 강제하는 도구는 `doc-governance` 에 있다.
 - macOS(BSD)와 Linux(GNU)는 `sed -i` · `date` · `readlink -f` · `realpath -m` · `find -newermt` · `stat` 포맷이 호환되지 않는다. 양쪽에서 도는 형태를 쓰거나 `command -v` 로 분기한다.
 
 훅으로 쓸 스크립트의 **차단 계약은 실행기마다 다르다** — Claude Code · Codex 는 `exit 2` + stderr 에 사유(통과 = `exit 0`, 출력 없음) · OpenCode 플러그인은 훅 함수에서 `throw` · Antigravity 는 JSON 으로 `decision: "deny"`. 계약 밖의 형태는 "비차단 오류"로 흘러가 조용히 무시된다.

package/templates/rules/doc-governance.md

@@ -6,4 +6,6 @@
 
 - **대조군 없이 "없다"·"안 된다"를 결론으로 쓰지 마라.** 빈 결과도 실패한 명령도 "대상이 없다"와 "내 탐지기가 틀렸다"를 구분해 주지 않는다.
 
+- **상주 문서(CLAUDE.md · SPEC/PRD · 메모리)에는 현행 결정만 적는다.** 이력·근거·정정 경위는 ADR·계획 문서로 분리하고 한 줄로 링크한다 — 상주 문서가 이력으로 비대해지면 매 세션 그 이력을 읽는다.
+
 **이 하네스가 설치해 둔 검사기**(스스로는 존재를 알 수 없으므로 여기 적는다): `bash .uzys-agent-harness/spec-drift-check.sh` 가 추적 문서의 미완 잔존·상태 불일치를 검출한다 — 인자 없이 경고(exit 1), `ship` 인자면 차단(exit 2). **탐지 경로 밖의 문서 레이아웃은 못 본다** — 그 구간에서는 이 룰이 프로즈로만 작동한다. `bash .uzys-agent-harness/check-absence.sh` 가 위 대조군 요구를 강제한다 — `--canary <알려진 양성> [-i] <ERE> <경로>...` 또는 `--control <되는 줄 아는 명령> --subject <대상>` (0 부재 · 1 발견 · 2 신뢰불가 · 3 사용법). 바이너리 부재를 판정할 때는 `--subject 'command -v <bin>'` 처럼 **1 을 내는 형태**로 쓴다 — 명령이 없어 127 로 죽으면 무효 처리된다.

package/templates/rules/git-policy.md

@@ -7,7 +7,7 @@
 
 ## Session Cleanup
 
-세션이 띄운 백그라운드 프로세스·서브에이전트는 끝나기 전에 닫는다 — 세션 종료가 그것들을 반드시 끝내주지는 않는다. 부모만 죽고 `ppid=1` 로 재부모화돼 메모리·포트·파일락을 계속 쥐는 경우가 있다. **다른 프로젝트의 프로세스는 건드리지 않는다.**
+세션이 띄운 백그라운드 프로세스·서브에이전트는 끝나기 전에 닫는다 — 세션 종료가 끝내주지 않고, 남은 것은 메모리·포트·파일락을 계속 쥔다. **다른 프로젝트의 프로세스는 건드리지 않는다.**
 
 ## Enforcement
 

package/templates/rules/ship-checklist.md

@@ -2,9 +2,9 @@
 
 무엇으로 검증할지는 이 저장소가 정한다. **어느 정도까지**는 Testing 룰이, 그 결과가 **언제** 있어야 하는지는 이 룰이 정한다.
 
-- **완료 판정은 만든 쪽이 아니라 검증자가 내린다.** 요구사항·변경분·검증 결과를 **직접 다시 확인**한 뒤 판정한다 — 보고를 읽고 승인하는 것은 판정이 아니다.
-- **머지 전**: 변경 위험에 맞는 검증을 **실행하고 결과를 확인한다.** high risk 는 더 많은 증거를 갖고 들어오고, **실행하지 않은 상태는 통과가 아니다.**
-- **배포**: 머지 전에 검증된 것과 **같은 artifact** 를 내보내고, 배포 뒤 실제 환경에서 smoke · health · 핵심 기능을 확인한다.
+- **검증의 리듬**: 구현 중에는 변경 부분의 빠른 검사만 한다. 사용자 씬의 수정분이 모이면 그때 독립 검토한다. 수정이 끝난 뒤 통합 테스트 · 빌드 · 실제 사용자 흐름을 검증한다. 작은 수정마다 전체 검증을 반복하지 않고, 재검사는 영향받은 부분만 한다.
+- **머지 전 독립 검증**은 핵심 사용자 기능 · 되돌리기 어려운 변경 · 돈·권한처럼 틀리면 큰 사고인 것에만 건다. UX 의 큰 변경은 사용자 페르소나 리뷰(선택). 그 밖(테스트 하네스 · 문서 · 리팩터 · 문구 · UI · 리뷰어 처방)은 리그레션 테스트로 들어온다. 독립 검증의 판정은 만든 쪽이 아니라 검증자가 요구사항·변경분·결과를 직접 확인하고 내린다. 어느 쪽이든 변경 위험에 맞는 검증을 **실행하고 결과를 확인한다** — high risk 는 더 많은 증거를 갖고 들어오고, **실행하지 않은 상태는 통과가 아니다.** 필수 보안 · 데이터 보호 검사는 유지한다.
+- **배포**: 배포 전에 풀 테스트 · E2E · 독립 검증을 거친다 — 머지 전에 리그레션만 받은 변경도 여기서 잡힌다. 머지 전에 검증된 것과 **같은 artifact** 를 내보내고, 배포 뒤 실제 환경에서 smoke · health · 핵심 기능을 확인한다.
 - **머지·게시 경로가 그 검증 통과에 의존해야 한다.** 별개 경로면 아무도 우회하려 하지 않았는데 red 가 그대로 나간다. 의존하지 않는 상태를 발견하면 경로를 고치기 전에 먼저 보고한다.
 - 변경분이 사용자에게 닿는 경로가 여럿이면 **경로마다 실행 증거를 따로** 확보한다. 한 경로의 증거를 다른 경로에 전용하지 않는다.
 - 이 저장소가 정의한 **보안·취약점 검사도** 실행하고 결과를 확인한다 — 테스트만 돌리고 나가는 것이 기본값이 되기 쉽다.