@uzysjung/agent-harness 26.149.0 → 26.151.0

package/dist/trust-tier-drift.js

@@ -2,6 +2,7 @@
 import {
   CATEGORIES,
   CLI_BASES,
+  DEFAULT_OPTIONS,
   DEV_METHOD_SKILL_IDS,
   EXTERNAL_ASSETS,
   INTERNAL_BUNDLED_SKILL_IDS,
@@ -9,13 +10,14 @@ import {
   TRUST_TIER,
   assetCliSupport,
   assetCostRows,
+  buildAssetSpec,
   buildManifest,
   estimateTokens,
   formatResidentCostBlock,
   init_esm_shims,
   residentCost,
   resolveBundleRoot
-} from "./chunk-YSW3OLH4.js";
+} from "./chunk-3QBHZUVB.js";
 
 // src/trust-tier-drift.ts
 init_esm_shims();
@@ -66,6 +68,7 @@ function classifyDrift(tier, stars) {
 export {
   CATEGORIES,
   CLI_BASES,
+  DEFAULT_OPTIONS,
   DEV_METHOD_SKILL_IDS,
   EXTERNAL_ASSETS,
   INTERNAL_BUNDLED_SKILL_IDS,
@@ -74,6 +77,7 @@ export {
   TRUST_TIER,
   assetCliSupport,
   assetCostRows,
+  buildAssetSpec,
   buildManifest,
   classifyDrift,
   driftTargets,

package/dist/trust-tier-drift.js.map

@@ -1 +1 @@
-{"version":3,"sources":["../src/trust-tier-drift.ts"],"sourcesContent":["/**\n * A1 — Trust Tier star-drift 검출 데이터 + 순수 로직.\n *\n * TRUST_TIER 의 star 기반 라벨(vetted ≥ 1000★ / experimental < 1000★)이 실제 GitHub\n * star 와 어긋났는지(drift) 판정한다. `official` 은 star 무관(Anthropic 공식·하네스 자체)\n * 이라 검사 제외.\n *\n * repo 출처 = 각 자산 method (in-code authoritative — 주석이 아니라 실제 설치 source):\n *   skill  → method.source     (\"owner/repo\" 또는 github URL)\n *   plugin → method.marketplace (\"owner/repo\")\n *   npm    → NPM_REPO_OVERRIDE[id] (pkg 는 npm 명이므로 GitHub repo 를 별도 명시)\n *\n * fetch/네트워크는 본 모듈에 없음 — 순수 로직만(테스트 가능). 실 fetch 는\n * `scripts/trust-tier-drift.mjs` 가 담당.\n */\nimport { EXTERNAL_ASSETS, type ExternalAsset, TRUST_TIER } from \"./external-assets.js\";\n\n// v26.79.0 — gen-compatibility 의 카테고리 exhaustiveness 가드용 SSOT (하드코딩 drift 차단).\nexport { CATEGORIES } from \"./categories.js\";\n// v26.116.0 (ADR-043) — context-cost-report.mjs 가 dist 에서 비용 계측기를 읽도록 re-export.\n// v26.140.0 — formatResidentCostBlock: 리포트가 표를 직접 조립하지 않도록 표시 계약도 함께 노출.\nexport {\n  assetCostRows,\n  estimateTokens,\n  formatResidentCostBlock,\n  residentCost,\n  resolveBundleRoot,\n} from \"./context-cost.js\";\n// v26.76.0 — gen-compatibility.mjs 가 dist 에서 자산 카탈로그+tier 를 읽도록 re-export.\n// v26.93.0 — DEV_METHOD_SKILL_IDS 추가: gen-compatibility 의 CLI scope override 를\n//   하드코딩 id 목록 대신 SSOT 에서 derive (no-false-ship drift 구조 차단).\n// v26.95.0 — INTERNAL_BUNDLED_SKILL_IDS (dev-method + opt-in gemini-consult) 로 CLI scope derive.\nexport {\n  // v26.102.0 (ADR-031) — gen-compatibility 의 CLI 열이 도달 범위를 derive 하도록 re-export.\n  assetCliSupport,\n  DEV_METHOD_SKILL_IDS,\n  EXTERNAL_ASSETS,\n  INTERNAL_BUNDLED_SKILL_IDS,\n  TRUST_TIER,\n} from \"./external-assets.js\";\nexport { buildManifest } from \"./manifest.js\";\n// v26.102.0 (ADR-031) — 도달 라벨(\"N-CLI\")의 N 을 derive 하기 위한 re-export (매직 넘버 금지).\nexport { CLI_BASES, TRACKS } from \"./types.js\";\n\n/** vetted 경계 (NORTH_STAR / PRD v26-71 D2). */\nexport const STAR_THRESHOLD = 1000;\n\nexport type StarTier = \"vetted\" | \"experimental\";\nexport type DriftVerdict = \"ok\" | \"promote\" | \"demote\";\n\n/**\n * method 가 GitHub repo 를 안 담는 자산(npm.pkg / npx-run.cmd 는 npm 명) → 트러스트 근거가\n * 된 GitHub repo 를 명시 매핑. override 가 method 도출보다 우선.\n */\nconst REPO_OVERRIDE: Record<string, string> = {\n  \"vercel-cli\": \"vercel/vercel\", // npm\n  \"netlify-cli\": \"netlify/cli\", // npm\n  \"supabase-cli\": \"supabase/cli\", // npm\n  \"agent-browser\": \"vercel-labs/agent-browser\", // npm\n  openspec: \"Fission-AI/OpenSpec\", // npm (v26.75.0)\n  \"bmad-method\": \"bmad-code-org/BMAD-METHOD\", // npx-run (v26.75.0)\n};\n\n/** \"https://github.com/owner/repo\" 또는 \"owner/repo[/...]\" → \"owner/repo\". 실패 시 null. */\nexport function normalizeRepo(source: string): string | null {\n  const stripped = source.replace(/^https?:\\/\\/github\\.com\\//i, \"\");\n  const m = stripped.match(/^([^/\\s]+\\/[^/\\s]+)/);\n  return m?.[1] ?? null;\n}\n\n/** 자산의 GitHub owner/repo 도출. override 우선 → skill/plugin method. 도출 불가 시 null. */\nexport function repoForAsset(asset: ExternalAsset): string | null {\n  const override = REPO_OVERRIDE[asset.id];\n  if (override) return override;\n  const m = asset.method;\n  if (m.kind === \"skill\") return normalizeRepo(m.source);\n  if (m.kind === \"plugin\") return normalizeRepo(m.marketplace);\n  return null;\n}\n\nexport interface DriftTarget {\n  id: string;\n  tier: StarTier;\n  repo: string;\n}\n\n/** star 기반(vetted/experimental) 자산만 + repo 도출 가능한 것만 검사 대상. */\nexport function driftTargets(\n  assets: ReadonlyArray<ExternalAsset> = EXTERNAL_ASSETS,\n): DriftTarget[] {\n  const out: DriftTarget[] = [];\n  for (const a of assets) {\n    const tier = TRUST_TIER[a.id];\n    if (tier !== \"vetted\" && tier !== \"experimental\") continue;\n    const repo = repoForAsset(a);\n    if (!repo) continue; // 도출 불가 — 테스트가 0건을 강제하므로 정상 경로에선 발생 안 함\n    out.push({ id: a.id, tier, repo });\n  }\n  return out;\n}\n\n/** 정적 tier 가 실제 star 와 어긋났는지 판정. */\nexport function classifyDrift(tier: StarTier, stars: number): DriftVerdict {\n  if (tier === \"vetted\" && stars < STAR_THRESHOLD) return \"demote\";\n  if (tier === \"experimental\" && stars >= STAR_THRESHOLD) return \"promote\";\n  return \"ok\";\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;AAAA;AA6CO,IAAM,iBAAiB;AAS9B,IAAM,gBAAwC;AAAA,EAC5C,cAAc;AAAA;AAAA,EACd,eAAe;AAAA;AAAA,EACf,gBAAgB;AAAA;AAAA,EAChB,iBAAiB;AAAA;AAAA,EACjB,UAAU;AAAA;AAAA,EACV,eAAe;AAAA;AACjB;AAGO,SAAS,cAAc,QAA+B;AAC3D,QAAM,WAAW,OAAO,QAAQ,8BAA8B,EAAE;AAChE,QAAM,IAAI,SAAS,MAAM,qBAAqB;AAC9C,SAAO,IAAI,CAAC,KAAK;AACnB;AAGO,SAAS,aAAa,OAAqC;AAChE,QAAM,WAAW,cAAc,MAAM,EAAE;AACvC,MAAI,SAAU,QAAO;AACrB,QAAM,IAAI,MAAM;AAChB,MAAI,EAAE,SAAS,QAAS,QAAO,cAAc,EAAE,MAAM;AACrD,MAAI,EAAE,SAAS,SAAU,QAAO,cAAc,EAAE,WAAW;AAC3D,SAAO;AACT;AASO,SAAS,aACd,SAAuC,iBACxB;AACf,QAAM,MAAqB,CAAC;AAC5B,aAAW,KAAK,QAAQ;AACtB,UAAM,OAAO,WAAW,EAAE,EAAE;AAC5B,QAAI,SAAS,YAAY,SAAS,eAAgB;AAClD,UAAM,OAAO,aAAa,CAAC;AAC3B,QAAI,CAAC,KAAM;AACX,QAAI,KAAK,EAAE,IAAI,EAAE,IAAI,MAAM,KAAK,CAAC;AAAA,EACnC;AACA,SAAO;AACT;AAGO,SAAS,cAAc,MAAgB,OAA6B;AACzE,MAAI,SAAS,YAAY,QAAQ,eAAgB,QAAO;AACxD,MAAI,SAAS,kBAAkB,SAAS,eAAgB,QAAO;AAC/D,SAAO;AACT;","names":[]}
+{"version":3,"sources":["../src/trust-tier-drift.ts"],"sourcesContent":["/**\n * A1 — Trust Tier star-drift 검출 데이터 + 순수 로직.\n *\n * TRUST_TIER 의 star 기반 라벨(vetted ≥ 1000★ / experimental < 1000★)이 실제 GitHub\n * star 와 어긋났는지(drift) 판정한다. `official` 은 star 무관(Anthropic 공식·하네스 자체)\n * 이라 검사 제외.\n *\n * repo 출처 = 각 자산 method (in-code authoritative — 주석이 아니라 실제 설치 source):\n *   skill  → method.source     (\"owner/repo\" 또는 github URL)\n *   plugin → method.marketplace (\"owner/repo\")\n *   npm    → NPM_REPO_OVERRIDE[id] (pkg 는 npm 명이므로 GitHub repo 를 별도 명시)\n *\n * fetch/네트워크는 본 모듈에 없음 — 순수 로직만(테스트 가능). 실 fetch 는\n * `scripts/trust-tier-drift.mjs` 가 담당.\n */\nimport { EXTERNAL_ASSETS, type ExternalAsset, TRUST_TIER } from \"./external-assets.js\";\n\n// v26.79.0 — gen-compatibility 의 카테고리 exhaustiveness 가드용 SSOT (하드코딩 drift 차단).\nexport { CATEGORIES } from \"./categories.js\";\n// v26.116.0 (ADR-043) — context-cost-report.mjs 가 dist 에서 비용 계측기를 읽도록 re-export.\n// v26.140.0 — formatResidentCostBlock: 리포트가 표를 직접 조립하지 않도록 표시 계약도 함께 노출.\nexport {\n  assetCostRows,\n  estimateTokens,\n  formatResidentCostBlock,\n  residentCost,\n  resolveBundleRoot,\n} from \"./context-cost.js\";\n// v26.76.0 — gen-compatibility.mjs 가 dist 에서 자산 카탈로그+tier 를 읽도록 re-export.\n// v26.93.0 — DEV_METHOD_SKILL_IDS 추가: gen-compatibility 의 CLI scope override 를\n//   하드코딩 id 목록 대신 SSOT 에서 derive (no-false-ship drift 구조 차단).\n// v26.95.0 — INTERNAL_BUNDLED_SKILL_IDS (dev-method + opt-in gemini-consult) 로 CLI scope derive.\nexport {\n  // v26.102.0 (ADR-031) — gen-compatibility 의 CLI 열이 도달 범위를 derive 하도록 re-export.\n  assetCliSupport,\n  DEV_METHOD_SKILL_IDS,\n  EXTERNAL_ASSETS,\n  INTERNAL_BUNDLED_SKILL_IDS,\n  TRUST_TIER,\n} from \"./external-assets.js\";\nexport { buildAssetSpec, buildManifest } from \"./manifest.js\";\n// v26.102.0 (ADR-031) — 도달 라벨(\"N-CLI\")의 N 을 derive 하기 위한 re-export (매직 넘버 금지).\nexport { CLI_BASES, DEFAULT_OPTIONS, TRACKS } from \"./types.js\";\n\n/** vetted 경계 (NORTH_STAR / PRD v26-71 D2). */\nexport const STAR_THRESHOLD = 1000;\n\nexport type StarTier = \"vetted\" | \"experimental\";\nexport type DriftVerdict = \"ok\" | \"promote\" | \"demote\";\n\n/**\n * method 가 GitHub repo 를 안 담는 자산(npm.pkg / npx-run.cmd 는 npm 명) → 트러스트 근거가\n * 된 GitHub repo 를 명시 매핑. override 가 method 도출보다 우선.\n */\nconst REPO_OVERRIDE: Record<string, string> = {\n  \"vercel-cli\": \"vercel/vercel\", // npm\n  \"netlify-cli\": \"netlify/cli\", // npm\n  \"supabase-cli\": \"supabase/cli\", // npm\n  \"agent-browser\": \"vercel-labs/agent-browser\", // npm\n  openspec: \"Fission-AI/OpenSpec\", // npm (v26.75.0)\n  \"bmad-method\": \"bmad-code-org/BMAD-METHOD\", // npx-run (v26.75.0)\n};\n\n/** \"https://github.com/owner/repo\" 또는 \"owner/repo[/...]\" → \"owner/repo\". 실패 시 null. */\nexport function normalizeRepo(source: string): string | null {\n  const stripped = source.replace(/^https?:\\/\\/github\\.com\\//i, \"\");\n  const m = stripped.match(/^([^/\\s]+\\/[^/\\s]+)/);\n  return m?.[1] ?? null;\n}\n\n/** 자산의 GitHub owner/repo 도출. override 우선 → skill/plugin method. 도출 불가 시 null. */\nexport function repoForAsset(asset: ExternalAsset): string | null {\n  const override = REPO_OVERRIDE[asset.id];\n  if (override) return override;\n  const m = asset.method;\n  if (m.kind === \"skill\") return normalizeRepo(m.source);\n  if (m.kind === \"plugin\") return normalizeRepo(m.marketplace);\n  return null;\n}\n\nexport interface DriftTarget {\n  id: string;\n  tier: StarTier;\n  repo: string;\n}\n\n/** star 기반(vetted/experimental) 자산만 + repo 도출 가능한 것만 검사 대상. */\nexport function driftTargets(\n  assets: ReadonlyArray<ExternalAsset> = EXTERNAL_ASSETS,\n): DriftTarget[] {\n  const out: DriftTarget[] = [];\n  for (const a of assets) {\n    const tier = TRUST_TIER[a.id];\n    if (tier !== \"vetted\" && tier !== \"experimental\") continue;\n    const repo = repoForAsset(a);\n    if (!repo) continue; // 도출 불가 — 테스트가 0건을 강제하므로 정상 경로에선 발생 안 함\n    out.push({ id: a.id, tier, repo });\n  }\n  return out;\n}\n\n/** 정적 tier 가 실제 star 와 어긋났는지 판정. */\nexport function classifyDrift(tier: StarTier, stars: number): DriftVerdict {\n  if (tier === \"vetted\" && stars < STAR_THRESHOLD) return \"demote\";\n  if (tier === \"experimental\" && stars >= STAR_THRESHOLD) return \"promote\";\n  return \"ok\";\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;AAAA;AA6CO,IAAM,iBAAiB;AAS9B,IAAM,gBAAwC;AAAA,EAC5C,cAAc;AAAA;AAAA,EACd,eAAe;AAAA;AAAA,EACf,gBAAgB;AAAA;AAAA,EAChB,iBAAiB;AAAA;AAAA,EACjB,UAAU;AAAA;AAAA,EACV,eAAe;AAAA;AACjB;AAGO,SAAS,cAAc,QAA+B;AAC3D,QAAM,WAAW,OAAO,QAAQ,8BAA8B,EAAE;AAChE,QAAM,IAAI,SAAS,MAAM,qBAAqB;AAC9C,SAAO,IAAI,CAAC,KAAK;AACnB;AAGO,SAAS,aAAa,OAAqC;AAChE,QAAM,WAAW,cAAc,MAAM,EAAE;AACvC,MAAI,SAAU,QAAO;AACrB,QAAM,IAAI,MAAM;AAChB,MAAI,EAAE,SAAS,QAAS,QAAO,cAAc,EAAE,MAAM;AACrD,MAAI,EAAE,SAAS,SAAU,QAAO,cAAc,EAAE,WAAW;AAC3D,SAAO;AACT;AASO,SAAS,aACd,SAAuC,iBACxB;AACf,QAAM,MAAqB,CAAC;AAC5B,aAAW,KAAK,QAAQ;AACtB,UAAM,OAAO,WAAW,EAAE,EAAE;AAC5B,QAAI,SAAS,YAAY,SAAS,eAAgB;AAClD,UAAM,OAAO,aAAa,CAAC;AAC3B,QAAI,CAAC,KAAM;AACX,QAAI,KAAK,EAAE,IAAI,EAAE,IAAI,MAAM,KAAK,CAAC;AAAA,EACnC;AACA,SAAO;AACT;AAGO,SAAS,cAAc,MAAgB,OAA6B;AACzE,MAAI,SAAS,YAAY,QAAQ,eAAgB,QAAO;AACxD,MAAI,SAAS,kBAAkB,SAAS,eAAgB,QAAO;AAC/D,SAAO;AACT;","names":[]}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@uzysjung/agent-harness",
-  "version": "26.149.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/hooks/session-start.sh

@@ -27,9 +27,63 @@ fi
 # 실패 모드이기 때문이다(cli-development.md §Cross-Platform).
 ORPHAN_NOTE=""
 PROJ_DIR=$(pwd)
-ORPHANS=$(ps -eo pid,ppid,command 2>/dev/null | awk -v d="$PROJ_DIR" '$2==1 && index($0,d)>0 {n++} END{print n+0}')
-if [ "${ORPHANS:-0}" -gt 0 ]; then
-  ORPHAN_NOTE=" WARNING: ${ORPHANS} orphaned process(es) from a previous session still reference this project (parent died, reparented to init). Inspect with: ps -eo pid,ppid,etime,command | grep \$(pwd) | grep -v grep — then stop what you recognise. Leaving them costs memory and can hold ports or file locks."
+# **물리 경로도 함께 본다.** macOS 의 `/var` 는 `/private/var` 로의 심링크라 `pwd` 는
+# `/var/...`, 커널·`lsof` 는 `/private/var/...` 를 낸다. 논리 경로만 대면 접두사가 어긋나
+# 실재하는 고아를 **0건으로** 보고한다 — 실제로 그렇게 짰다가 진짜 고아를 만든 시험에서 잡혔다.
+PROJ_DIR_P=$(pwd -P 2>/dev/null || printf '%s' "$PROJ_DIR")
+
+# **한 번만 찍고 그 스냅샷을 읽는다.** `ps | grep <이름>` 은 grep 자신의 커맨드라인을 매치해
+# 항상 양성을 낸다 — 이 리포가 실제로 오판한 형태다.
+PS_SNAP=$(ps -eo pid,ppid,command 2>/dev/null || true)
+
+# ⓐ 커맨드라인에 프로젝트 경로가 **든** 고아 (`npm run dev /path/...` 처럼 경로를 인자로 받은 것).
+ORPHANS=$(printf '%s\n' "$PS_SNAP" | awk -v d="$PROJ_DIR" '$2==1 && index($0,d)>0 {n++} END{print n+0}')
+
+# ⓑ 커맨드라인에 경로가 **없는** 고아. 서브에이전트가 이 모양이다 — 경로는 cwd 에만 있어서
+#   ⓐ 는 이 부류를 **구조적으로 0건**으로 보고했다(#326 실측: 살아 있는 서브에이전트 2건 → 0건).
+#   0 을 내는 탐지기는 없는 것보다 나쁘다. 거짓 안심을 준다.
+#
+# **비용 때문에 후보를 먼저 좁힌다.** cwd 를 묻는 것은 macOS 에서 pid 당 약 4 ms 다(실측).
+#   ppid=1 전체(이 머신 433개)에 물으면 세션 시작이 배로 느려지고, 그 비용은 설치받은
+#   사람이 **매 세션** 낸다. 그래서 ⓐ 가 이미 세지 않은 것 중 **에이전트 부류만** 보고,
+#   후보가 0이면 cwd 를 아예 안 묻는다. 상한 40개.
+#
+#   **비용의 원인을 한 번 잘못 짚었다.** 처음엔 후보 수 탓인 줄 알고 범위를 좁혔는데, 재보니
+#   **후보 1개짜리 `lsof` 가 1,444 ms** 였다 — 비싼 것은 후보 수가 아니라 `lsof` 자신이었다.
+#   `-b`(블록 가능 호출 회피)를 붙이자 같은 답에 **74 ms** 가 됐고, 그래서 범위를 다시 넓힐 수
+#   있었다. 좁힌 채로 뒀으면 경로가 argv 에 없는 비-에이전트 고아(디렉터리 안에서 띄운
+#   `node server.js` 등)를 영영 못 봤을 것이다.
+CAND=$(printf '%s\n' "$PS_SNAP" | awk -v d="$PROJ_DIR" \
+  '$2==1 && index($0,d)==0 && /claude|node|python|bun|deno|--agent-name/ {print $1}' | head -40)
+CWD_ORPHANS=0
+if [ -n "$CAND" ]; then
+  if [ -d /proc ]; then
+    # Linux: /proc 는 사실상 공짜다.
+    for pid in $CAND; do
+      cwd=$(readlink "/proc/$pid/cwd" 2>/dev/null || true)
+      case "$cwd" in
+        "$PROJ_DIR" | "$PROJ_DIR"/* | "$PROJ_DIR_P" | "$PROJ_DIR_P"/*) CWD_ORPHANS=$((CWD_ORPHANS + 1)) ;;
+      esac
+    done
+  elif command -v lsof > /dev/null 2>&1; then
+    # macOS: /proc 이 없다. 한 번에 묻고, 접두사 일치로 **이 프로젝트 밑**만 센다 —
+    # 다른 프로젝트의 고아를 남의 세션이 판단해선 안 된다.
+    # `-b` 가 이 검사를 쓸 수 있게 만든다 — 블록 가능한 커널 호출을 피한다. 실측: 후보 1개에
+    # `-b` 없이 **1,444 ms**, 있으면 **74 ms**(19배)이고 답은 같다(cwd 28건 동일). `-w` 는 그때
+    # 나는 경고를 죽이고, `-n`·`-P` 는 우리가 안 쓰는 이름 해석을 건너뛴다.
+    CWD_ORPHANS=$(lsof -b -w -n -P -p "$(printf '%s' "$CAND" | tr '\n' ',' | sed 's/,$//')" -a -d cwd -Fn 2>/dev/null \
+      | awk -v d="$PROJ_DIR" -v dp="$PROJ_DIR_P" '
+          substr($0,1,1)=="n" {
+            p = substr($0,2)
+            if (p==d || index(p, d "/")==1 || p==dp || index(p, dp "/")==1) n++
+          } END {print n+0}')
+  fi
+  # lsof 도 /proc 도 없으면 CWD_ORPHANS 는 0 이다. 이 경우는 **못 본 것**이지 없는 것이 아니다.
+fi
+
+ORPHAN_TOTAL=$((${ORPHANS:-0} + ${CWD_ORPHANS:-0}))
+if [ "$ORPHAN_TOTAL" -gt 0 ]; then
+  ORPHAN_NOTE=" WARNING: ${ORPHAN_TOTAL} orphaned process(es) from a previous session still belong to this project (parent died, reparented to init); ${CWD_ORPHANS} of them are only visible by working directory, which is how subagents look. Inspect with: ps -eo pid,ppid,etime,command | grep \$(pwd) | grep -v grep — and for the rest, resolve each candidate's cwd. Then stop what you recognise. Leaving them costs memory and can hold ports or file locks."
 fi
 
 # 3. 세션 컨텍스트 출력