tink-harness 1.8.0 → 1.9.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "tink",
   "description": "A small harness layer for Claude Code and Codex.",
-  "version": "1.8.0",
+  "version": "1.9.0",
   "author": {
     "name": "dotori"
   }

package/CHANGELOG.md

@@ -7,6 +7,23 @@ All notable changes to Tink are tracked here.
 No unreleased changes yet.
 
 
+## [1.9.0] - 2026-06-09
+
+### Added
+
+- Expanded the harness lifecycle summary generator with ordered harness parsing, repeated sequence hints, and rule/memory references from visible run records.
+- Added a derived graph view to harness lifecycle summaries so future reports can read harness, rule, memory, and stage relationships without adding a watcher or hidden cache.
+- Added timeline events to harness lifecycle summaries and rendered recent run history in the local harness health HTML report.
+- Added explainable candidate scores to harness lifecycle summaries and the local health report so weave, frog, merge, and observe candidates are easier to sort without automatic action.
+- Added lifecycle state fields, including a `dormant_candidate` state that treats old usage as an archive review signal rather than delete evidence.
+- Added a static graph overview to the local harness health report, summarizing lifecycle graph nodes and relationships without starting a server or watcher.
+
+### Changed
+
+- Updated README and planning docs to describe the implemented harness health summary, static report dashboard, lifecycle states, and remaining roadmap boundaries.
+- Moved README release highlights into the changelog path and added top-level changelog links in the English and Korean README files.
+
+
 ## [1.8.0] - 2026-06-09
 
 ### Added

package/README.ko.md

@@ -8,9 +8,9 @@ Claude Code와 Codex를 위한 작은 하네스 레이어입니다.
 
 Tink는 지금 작업에 맞는 하네스를 고르고, 실행 상태를 보이게 만들고, 실제 사용 중 생긴 실패와 피드백으로 하네스 세트를 개선합니다.
 
-**최신 패키지:** v1.8.0 — 요구사항 인터뷰, 합의형 계획, 목표 체크포인트, 위임 브리프를 위한 visible-thinking 하네스를 추가합니다. 최신 마이너 릴리스 노트: [v1.8.0](https://github.com/dotoricode/tink-harness/releases/tag/v1.8.0).
+**최신 패키지:** v1.9.0 — 하네스 건강 요약, graph, timeline, 후보 점수, 생애주기 상태, 정적 로컬 리포트를 추가합니다. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
 
-[English](README.md) · **한국어**
+[English](README.md) · **한국어** · [변경 이력](CHANGELOG.md)
 
 ---
 
@@ -59,69 +59,6 @@ npx tink-harness@latest update
 
 업데이트 후 Codex skill, schema, Windows 경고가 이상해 보이면 `docs/update-troubleshooting.ko.md` 또는 `docs/update-troubleshooting.md`를 확인하세요.
 
-## 1.8.0에서 달라진 점
-
-이번 마이너 릴리스는 GJC식 사고 단계 노출 방식을 Tink의 작은 하네스 모델 안으로 가져옵니다.
-
-- `/tink:cast`와 `$tink:cast`가 `requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`를 선택할 수 있습니다.
-- 긴 실행은 `.tink/current/goals.json`, 인수인계나 병렬 검토 계획은 `.tink/current/delegation.md`에 보이는 상태로 남길 수 있습니다.
-- 이 하네스들은 worker, tmux pane, worktree를 자동 시작하지 않습니다. 위임은 별도 승인된 워크플로가 실행하기 전까지 브리프 상태로만 둡니다.
-
-## 1.7.1에서 달라진 점
-
-이번 패치는 "둘 다" surface와 "Clean Codex picker"를 함께 선택했을 때 Claude Code 명령과 skill이 삭제되는 문제를 수정합니다.
-
-- "둘 다 (Claude Code + Codex)"와 "Clean Codex picker"를 동시에 선택해도 Claude Code 명령과 skill이 삭제되지 않습니다. 이 옵션은 이제 Codex만 선택했을 때만 표시됩니다.
-
-## 1.7.0에서 달라진 점
-
-이번 마이너 릴리스는 installer UX의 두 가지 불편함을 해결합니다.
-
-- surface 선택 단계가 단일 선택 프롬프트(Claude Code / Codex / 둘 다(Claude Code + Codex))로 바뀌어, 커서가 이미 선택된 항목 위에 있어도 선택 상태를 바로 알 수 있습니다.
-- 컴포넌트 선택 프롬프트가 설정 중인 surface를 명시합니다. "Claude Code 설치 항목" 또는 "Codex 설치 항목"처럼 선택한 surface에 맞는 메시지가 표시됩니다.
-
-## 1.6.3에서 달라진 점
-
-이번 패치는 CLI 옵션을 interactive installer 안에서 직접 고를 수 있게 만듭니다.
-
-- wizard에 `Advanced options` 단계가 추가되어 `Preview only (--dry-run)`, `Overwrite user-modified files (--force)`, `Clean Codex picker (--clean-codex-picker)`를 선택할 수 있습니다.
-- install/update 출력에 선택된 옵션 상태를 표시해서 preview, force overwrite, Codex picker cleanup이 켜졌는지 바로 볼 수 있습니다.
-- 기존 CLI flag는 그대로 동작하며, interactive wizard에서는 같은 옵션의 초기 선택값으로 반영됩니다.
-## 1.6.2에서 달라진 점
-
-이번 패치는 Claude Code와 Codex를 함께 쓰는 설치 흐름을 더 명확하게 만듭니다.
-
-- Codex action skill이 이제 `Cast`/`Verify` 같은 일반 이름 대신 `Tink: Cast`, `Tink: Verify`, `Tink: Update`처럼 설치됩니다.
-- Claude Code와 Codex를 함께 선택했을 때 컴포넌트 선택지에서 `Claude Code Tink skill`과 `Codex Tink skills`가 분리되어 보입니다.
-- install/update 출력에 repo, shared `.tink`, Claude Code, Codex target 경로를 표시해서 선택한 항목이 어디에 설치되는지 바로 볼 수 있습니다.
-- `--clean-codex-picker` 또는 `TINK_CLEAN_CODEX_PICKER=1`로 Codex에 `Source Command Tink ...` 항목을 만들던 repo-local Claude Tink command/skill surface를 정리할 수 있습니다.
-
-## 1.6.1에서 달라진 점
-
-이번 패치는 기존 설치의 update 경로를 고칩니다.
-
-- `tink-harness update`가 v1.5.x에서 생성된 기본 `.tink/rules/index.json`을 새 v1.6.x rule graph seed로 갱신합니다.
-- custom rule이나 rule evidence가 들어간 사용자 수정 rule graph는 계속 보존합니다.
-
-## 1.6.0에서 달라진 점
-
-이번 릴리스는 Tink의 작은 rule graph를 실제 작업에서 더 쓸모 있게 만듭니다.
-
-- README 한/영 동기화, 버전 메타데이터 동기화, Claude Code 명령 3-copy 동기화, installer/update smoke check처럼 반복되는 작업에 필요한 관련 파일과 검증 체크를 seed rule로 연결합니다.
-- `/tink:cast`와 `$tink:cast`는 rule의 `reason`, `risk`, `include_paths`, `checks`를 context 증거로 남기도록 안내합니다.
-- `/tink:weave`와 `/tink:frog`는 rule quality를 함께 점검해서 keep, rewrite, split, merge, needs evidence로 정리할 수 있게 합니다.
-- 그래프는 계속 작고 파일 기반으로 유지합니다. 이번 릴리스도 public `tink index` 명령, watcher, generated cache, database, 외부 서비스를 추가하지 않습니다.
-## 1.2.0 이후 기반 개선
-
-이번 릴리스는 Tink를 Claude Code와 Codex에서 같은 하네스 레이어로 쓰기 쉽게 정리합니다.
-
-- Codex에는 하나의 넓은 `tink` 스킬 대신 `$tink:cast`, `$tink:verify` 같은 action skill만 보이도록 설치됩니다.
-- 비단순 작업은 `context-pack.md`, `context-map.json`, `excluded-context.md`로 어떤 context를 썼고 뺐는지 남깁니다.
-- Repo Signal과 Context Graph Lite는 새 `tink index` 명령을 만들지 않고도 관련 테스트, 스키마, 동기화 파일, 검증 힌트를 고르는 데 쓰입니다.
-- context 효율 점수화, fixture 비율 계산, run-history rollup, 90% threshold status, 실제 run 기록 경계 기준은 `docs/context-budget-ledger.ko.md`, `docs/context-budget-ledger.md`, `docs/context-metrics-evaluator.ko.md`, `docs/context-metrics-evaluator.md`, `docs/context-run-history-rollup.ko.md`, `docs/context-run-history-rollup.md`, `docs/context-threshold-status.ko.md`, `docs/context-threshold-status.md`, `docs/context-run-record-policy.ko.md`, `docs/context-run-record-policy.md`에서 확인할 수 있습니다.
-- `/tink:verify`와 `$tink:verify`는 같은 Verify Runner 모델을 쓰며 `.tink/current/verification.json`에 검증 증거를 남깁니다.
-- 외부 context는 MCP Safe Profile을 따릅니다. 가장 작은 source handle만 남기고, 신뢰도와 민감도를 표시하며, 위험하거나 너무 넓은 context는 `excluded-context.md`에 따로 기록합니다.
-
 ## 명령
 
 Claude Code에서는 `/tink:*`, Codex에서는 `$tink:*`을 씁니다. 예전 `$tink cast` 형식도 호환되지만, 기본 안내와 자동완성 표면은 `$tink:*`입니다.
@@ -166,17 +103,28 @@ Tink는 직접 볼 수 있는 파일을 씁니다.
 - `.tink/maintenance/`: 검증, friction, weave 신호 기록
 - `.tink/memory/`: 승인된 실수, 선호, 교훈
 
+Tink는 이 기록을 읽어 하네스 건강 요약도 만들 수 있습니다. 요약은 어떤 하네스가 쓰였는지, 어디서 check가 실패하거나 막혔는지, 어떤 하네스가 자주 함께 쓰였는지, 어떤 하네스가 weave 개선 후보인지, frog 정리 검토 후보인지, 병합 검토 후보인지, 오래 쉬어서 보관 검토 후보인지, 더 지켜봐야 하는지를 보여줍니다. 후보 점수, 생애주기 상태, graph 관계, 최근 run timeline도 함께 제공합니다. 이것은 여전히 제안일 뿐입니다. 하네스 수정, 병합, 보관, 삭제, memory 저장, rule 업데이트는 Tink의 기존 명시적 승인 절차를 거쳐야 합니다.
+
+설치된 읽기 전용 helper로 JSON 요약과 로컬 HTML 리포트를 만들 수 있습니다.
+
+```bash
+node .tink/tools/generate-harness-lifecycle-summary.mjs
+node .tink/tools/render-harness-health-report.mjs
+```
+
+리포트는 정적 대시보드 형태입니다. graph overview, 최근 run timeline, 하네스별 카드를 보여주지만 서버를 시작하거나, 파일을 감시하거나, hidden cache를 만들거나, 새 public `tink index` 명령을 추가하지 않습니다.
+
 선택된 하네스에 따라 `.tink/current/goals.json`에는 현재 실행의 목표 체크포인트가, `.tink/current/delegation.md`에는 인수인계 패킷이 추가될 수 있습니다. Tink는 이런 브리프를 보이는 상태로 준비하지만, 별도 승인된 워크플로가 아니면 worker, tmux pane, worktree를 시작하지 않습니다.
 
 Rule graph는 작게 유지합니다. Tink는 먼저 필수 규칙을 고르고, 작업 사실이나 keyword에 맞는 선택 규칙만 가져오며, phase별로 이미 읽은 rule id를 기록해 같은 안내를 반복하지 않습니다.
 
-설계 메모는 `docs/`에 둡니다. 기본 호환성 기준은 `docs/compatibility-policy.md`에 있으며, 새 작업은 Claude Code와 Codex, macOS와 Windows를 함께 고려해야 합니다. Repo Signal 동작은 `docs/repo-signals.ko.md` 또는 `docs/repo-signals.md`에 정리되어 있고, 가벼운 graph 규칙 적용 계획은 `docs/graph-rule-adoption-plan.ko.md`에 정리되어 있습니다. 외부 context 안전 기준은 `docs/mcp-safe-profile.md`에 정리되어 있습니다. `.tink/current/` 상태를 읽거나 검토할 때는 `docs/work-state.ko.md` 또는 `docs/work-state.md`부터 보면 됩니다. 다음 업데이트 안정화 계획은 `docs/phase-5-update-confidence.ko.md`와 `docs/phase-5-update-confidence.md`에 정리되어 있습니다. 더 큰 아이디어 구현 점검과 로드맵은 `docs/tink-idea-implementation-plan.ko.md`에 정리되어 있습니다.
+설계 메모는 `docs/`에 둡니다. 기본 호환성 기준은 `docs/compatibility-policy.md`에 있으며, 새 작업은 Claude Code와 Codex, macOS와 Windows를 함께 고려해야 합니다. Repo Signal 동작은 `docs/repo-signals.ko.md` 또는 `docs/repo-signals.md`에 정리되어 있고, 가벼운 graph 규칙 적용 계획은 `docs/graph-rule-adoption-plan.ko.md`에 정리되어 있습니다. 하네스 건강 요약은 `docs/harness-lifecycle-signals.ko.md` 또는 `docs/harness-lifecycle-signals.md`에 정리되어 있습니다. 외부 context 안전 기준은 `docs/mcp-safe-profile.md`와 `docs/external-context-policy.md`에 정리되어 있습니다. `.tink/current/` 상태를 읽거나 검토할 때는 `docs/work-state.ko.md` 또는 `docs/work-state.md`부터 보면 됩니다. 다음 업데이트 안정화 계획은 `docs/phase-5-update-confidence.ko.md`와 `docs/phase-5-update-confidence.md`에 정리되어 있습니다. Context 효율 관련 문서는 `docs/context-budget-ledger.ko.md`, `docs/context-budget-ledger.md`, `docs/context-metrics-evaluator.ko.md`, `docs/context-metrics-evaluator.md`, `docs/context-run-history-rollup.ko.md`, `docs/context-run-history-rollup.md`, `docs/context-threshold-status.ko.md`, `docs/context-threshold-status.md`, `docs/context-run-record-policy.ko.md`, `docs/context-run-record-policy.md`에서 확인할 수 있습니다. 남은 작업 단위는 `docs/planned-work-units.ko.md` 또는 `docs/planned-work-units.md`에 정리되어 있습니다. 더 큰 아이디어 구현 점검과 로드맵은 `docs/tink-idea-implementation-plan.ko.md`에 정리되어 있습니다.
 
 중요한 원칙은 승인입니다. 현재 작업을 진행하는 승인과, 미래에도 재사용될 상태를 저장하는 승인은 별개입니다. 새 하네스, 메모리, rule graph, hook guard 저장은 항상 별도 승인이 필요합니다.
 
 ## 계획된 작업 단위
 
-남은 계획은 번호가 붙은 단계보다 작업 단위 이름으로 관리합니다. 전체 목록은 `docs/planned-work-units.ko.md` 또는 `docs/planned-work-units.md`에 있으며, 세부 문서는 검증 증거 세분화, 외부 컨텍스트 정책, 하네스 생애주기 신호, 메모리 결정 계층, 컨텍스트 변화 리뷰, 업데이트 진단으로 나누어 둡니다.
+남은 계획은 번호가 붙은 단계보다 작업 단위 이름으로 관리합니다. 전체 목록은 `docs/planned-work-units.ko.md` 또는 `docs/planned-work-units.md`에 있으며, 세부 문서는 검증 증거 세분화, 외부 컨텍스트 정책, 메모리 결정 계층, 컨텍스트 변화 리뷰, 업데이트 진단으로 나누어 둡니다. 하네스 생애주기 신호는 이제 기본 JSON 요약과 정적 HTML 리포트까지 구현되어 별도 문서에서 관리합니다.
 
 ## Tink가 아닌 것
 

package/README.md

@@ -17,16 +17,16 @@
 </p>
 
 <p>
-  <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.6.0"><img src="https://img.shields.io/github/v/release/dotoricode/tink-harness?label=release&color=2ea44f" alt="GitHub release"></a>
+  <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.9.0"><img src="https://img.shields.io/github/v/release/dotoricode/tink-harness?label=release&color=2ea44f" alt="GitHub release"></a>
   <a href="https://www.npmjs.com/package/tink-harness"><img src="https://img.shields.io/npm/v/tink-harness?label=npm&color=cb3837" alt="npm version"></a>
   <a href="https://github.com/dotoricode/tink-harness/actions/workflows/ci.yml"><img src="https://img.shields.io/github/actions/workflow/status/dotoricode/tink-harness/ci.yml?branch=main&label=ci" alt="CI"></a>
   <a href="https://github.com/dotoricode/tink-harness/blob/main/LICENSE"><img src="https://img.shields.io/github/license/dotoricode/tink-harness" alt="License"></a>
   <a href="https://github.com/dotoricode/tink-harness/stargazers"><img src="https://img.shields.io/github/stars/dotoricode/tink-harness?style=social" alt="GitHub stars"></a>
 </p>
 
-<p><strong>Latest package:</strong> v1.8.0 - Adds visible-thinking harnesses for requirements interviews, consensus planning, goal checkpoints, and delegation briefs. Latest minor release notes: <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.8.0">v1.8.0</a>.</p>
+<p><strong>Latest package:</strong> v1.9.0 - Adds harness health summaries with graph, timeline, scoring, lifecycle states, and a static local report. See <a href="CHANGELOG.md">CHANGELOG</a> for release history.</p>
 
-**English** · [한국어](README.ko.md)
+**English** · [한국어](README.ko.md) · [Changelog](CHANGELOG.md)
 
 ---
 
@@ -124,71 +124,6 @@ To quickly verify the updated install, see `docs/update-verification-recipe.md`
 
 If an update looks stale or incomplete, see `docs/update-troubleshooting.md` or `docs/update-troubleshooting.ko.md`.
 
-## What's new in 1.8.0
-
-This minor release brings GJC-style visible thinking into Tink without adding new commands.
-
-- `/tink:cast` and `$tink:cast` can now select `requirements-interview`, `plan-consensus`, `goal-checkpoint`, and `delegation-brief`.
-- Long runs can record `.tink/current/goals.json`; handoff or parallel-review plans can record `.tink/current/delegation.md`.
-- Tink still does not start workers, tmux panes, or worktrees from these harnesses. Delegation remains a visible brief unless another approved workflow runs it.
-
-## What's new in 1.7.1
-
-This patch fixes a destructive interaction between the "Both" surface selection and "Clean Codex picker."
-
-- Selecting "Both (Claude Code + Codex)" and "Clean Codex picker" in the same install/update run no longer deletes the Claude Code commands and skills. The option is now hidden when both surfaces are selected — it only appears when Codex is the sole surface.
-
-## What's new in 1.7.0
-
-This minor release removes two installer UX rough edges.
-
-- The surface selection step now uses a single-choice prompt — Claude Code, Codex, or Both — instead of a multi-checkbox toggle, so the selected state is immediately visible on any terminal.
-- The component selection prompt now names the surface being configured, so you see a surface-specific prompt rather than the same generic message regardless of what you selected.
-
-## What's new in 1.6.3
-
-This patch makes CLI options visible in the interactive installer.
-
-- The wizard now has an `Advanced options` step with `Preview only (--dry-run)`, `Overwrite user-modified files (--force)`, and `Clean Codex picker (--clean-codex-picker)` when Codex is selected.
-- Install/update output now prints the selected option state, so you can see whether preview, force overwrite, or Codex picker cleanup is active.
-- CLI flags still work for non-interactive runs and seed the same visible choices when the wizard is used.
-
-## What's new in 1.6.2
-
-This patch makes the installer clearer for mixed Claude Code + Codex setups.
-
-- Codex action skills now install with names like `Tink: Cast`, `Tink: Verify`, and `Tink: Update` instead of generic `Cast`/`Verify` labels.
-- The component picker now separates `Claude Code Tink skill` from `Codex Tink skills` when both surfaces are selected.
-- Install/update output now prints the repo, shared `.tink`, Claude Code, and Codex target paths so you can see where the selected choices will land.
-- `--clean-codex-picker` and `TINK_CLEAN_CODEX_PICKER=1` can remove repo-local Claude Tink command/skill surfaces that make Codex show noisy `Source Command Tink ...` entries.
-
-## What's new in 1.6.1
-
-This patch fixes the update path for existing installs.
-
-- `tink-harness update` now refreshes the generated legacy `.tink/rules/index.json` from v1.5.x so existing users receive the v1.6.0 graph-rule seed rules.
-- User-modified rule graphs are still preserved when they contain custom rules or rule evidence.
-
-## What's new in 1.6.0
-
-This release makes Tink's small rule graph more useful during real work.
-
-- Seed rules now connect common maintenance work to related files, harnesses, and checks, such as README bilingual sync, version metadata sync, Claude Code command 3-copy sync, and installer/update smoke checks.
-- `/tink:cast` and `$tink:cast` guidance now records rule `reason`, `risk`, `include_paths`, and `checks` as reviewable context evidence instead of silently loading extra files.
-- `/tink:weave` and `/tink:frog` now include rule-quality review so reusable rules can be kept, rewritten, split, merged, or marked as needing more evidence.
-- The graph remains file-based and small. This release still does not add a public `tink index` command, watcher, generated cache, database, or external service.
-
-## Recent foundation from 1.2.0+
-
-This release makes Tink work as one harness layer across Claude Code and Codex.
-
-- Codex now installs focused `$tink:*` action skills instead of one broad visible `tink` skill, so the picker shows commands like `$tink:cast` and `$tink:verify` cleanly.
-- Non-trivial runs now create context artifacts: `context-pack.md`, `context-map.json`, and `excluded-context.md`.
-- Repo Signals and Context Graph Lite help `/tink:cast` and `$tink:cast` choose relevant tests, schemas, sync partners, and verification hints without adding a new `tink index` command.
-- Context Budget Ledger fields, fixture-ratio evaluation, run-history rollup, the 90 percent threshold status, and future real-run record boundaries are documented in `docs/context-budget-ledger.md`, `docs/context-budget-ledger.ko.md`, `docs/context-metrics-evaluator.md`, `docs/context-metrics-evaluator.ko.md`, `docs/context-run-history-rollup.md`, `docs/context-run-history-rollup.ko.md`, `docs/context-threshold-status.md`, `docs/context-threshold-status.ko.md`, `docs/context-run-record-policy.md`, and `docs/context-run-record-policy.ko.md` without adding a new command.
-- `/tink:verify` and `$tink:verify` share one portable Verify Runner model and write compact evidence to `.tink/current/verification.json`.
-- External context now follows the MCP Safe Profile: include only the smallest useful source handle, mark confidence and sensitivity, exclude unsafe context visibly, and connect important claims to verification.
-
 ## Commands
 
 Tink keeps the command surface small.
@@ -247,11 +182,22 @@ Tink uses files you can inspect:
 - `.tink/maintenance/`: verification, friction, and weave signals that help repeated failures become approved improvements
 - `.tink/memory/`: approved mistakes, preferences, and lessons
 
+Tink can also read those records into a harness health summary. The summary shows which harnesses were used, where checks failed or got blocked, which harnesses often appear together, and which ones may deserve a weave improvement, frog cleanup review, merge review, dormant archive review, or more observation. It also includes an explainable candidate score, lifecycle state, graph relationships, and recent run timeline. It only prepares suggestions. Tink does not edit, merge, archive, delete, save memory, or update rules without the same explicit approval gates as the rest of Tink.
+
+The installed read-only helpers can generate that JSON summary and turn it into a local HTML report:
+
+```bash
+node .tink/tools/generate-harness-lifecycle-summary.mjs
+node .tink/tools/render-harness-health-report.mjs
+```
+
+The report is a static dashboard-style page with a graph overview, recent run timeline, and one card per harness. It does not start a server, watch files, create a hidden cache, or add a public `tink index` command.
+
 When selected, current-run artifacts may also include `.tink/current/goals.json` for goal checkpoints or `.tink/current/delegation.md` for handoff packets. Tink prepares those briefs as visible state; it does not start workers, tmux panes, or worktrees unless a separate approved workflow does so.
 
 The rule graph stays small on purpose. Tink loads matching mandatory rules first, retrieves only relevant optional rules by task facts or keywords, and records loaded rule ids by phase so the same guidance is not repeated in one run.
 
-Design notes live in `docs/`. The compatibility baseline is `docs/compatibility-policy.md`: every new slice should consider Claude Code and Codex, plus macOS and Windows. Repo signal behavior is described in `docs/repo-signals.md` or `docs/repo-signals.ko.md`. The lightweight graph-rule adoption plan is `docs/graph-rule-adoption-plan.ko.md`. External context safety is described in `docs/mcp-safe-profile.md` and `docs/external-context-policy.md`. To read or review `.tink/current/` state, start with `docs/work-state.md` or `docs/work-state.ko.md`. Update confidence is still documented in `docs/phase-5-update-confidence.md` or `docs/phase-5-update-confidence.ko.md`. The planned work-unit list is `docs/planned-work-units.md` or `docs/planned-work-units.ko.md`, with details in the verification evidence, harness lifecycle, memory decision, context change, and update diagnosis docs. The broader Korean idea audit and roadmap is `docs/tink-idea-implementation-plan.ko.md`.
+Design notes live in `docs/`. The compatibility baseline is `docs/compatibility-policy.md`: every new slice should consider Claude Code and Codex, plus macOS and Windows. Repo signal behavior is described in `docs/repo-signals.md` or `docs/repo-signals.ko.md`. The lightweight graph-rule adoption plan is `docs/graph-rule-adoption-plan.ko.md`. Harness health summaries are described in `docs/harness-lifecycle-signals.md` or `docs/harness-lifecycle-signals.ko.md`. External context safety is described in `docs/mcp-safe-profile.md` and `docs/external-context-policy.md`. To read or review `.tink/current/` state, start with `docs/work-state.md` or `docs/work-state.ko.md`. Update confidence is still documented in `docs/phase-5-update-confidence.md` or `docs/phase-5-update-confidence.ko.md`. Context efficiency docs live in `docs/context-budget-ledger.md`, `docs/context-budget-ledger.ko.md`, `docs/context-metrics-evaluator.md`, `docs/context-metrics-evaluator.ko.md`, `docs/context-run-history-rollup.md`, `docs/context-run-history-rollup.ko.md`, `docs/context-threshold-status.md`, `docs/context-threshold-status.ko.md`, `docs/context-run-record-policy.md`, and `docs/context-run-record-policy.ko.md`. The planned work-unit list is `docs/planned-work-units.md` or `docs/planned-work-units.ko.md`, with details in the verification evidence, memory decision, context change, and update diagnosis docs. The broader Korean idea audit and roadmap is `docs/tink-idea-implementation-plan.ko.md`.
 
 The important rule is approval.
 

package/VERSIONING.md

@@ -1,6 +1,6 @@
 # Versioning
 
-Current version: `1.8.0`
+Current version: `1.9.0`
 
 Tink follows semver from `1.0.0` onward.
 
@@ -25,12 +25,14 @@ Use semver.
 
 ## Release checklist
 
-Before pushing a versioned release:
+Before publishing a versioned release, always work from a release branch and merge by squash. Do not commit release work directly to `main`; a direct `main` commit makes it impossible to attach the release to a normal PR without rewriting published history.
 
-1. Update `package.json`, `package-lock.json`, and `.claude-plugin/plugin.json` to the same version.
-2. Add a `CHANGELOG.md` entry for the version.
-3. Confirm README update instructions still match the actual Claude Code plugin path.
-4. Run:
+1. Create a release branch.
+2. Update `package.json`, `package-lock.json`, and `.claude-plugin/plugin.json` to the same version.
+3. Add a `CHANGELOG.md` entry for the version.
+4. Confirm README update instructions still match the actual Claude Code plugin path.
+5. Write the PR title with `fix`, `feat`, `chore`, or `docs`, and write the PR body in Korean using the relevant subtitles from `Problem`, `Fix`, `Summary`, `Changes`, `Behavior`, and `Testing`.
+6. Run:
 
 ```bash
 npm test
@@ -52,7 +54,20 @@ claude plugin validate .claude-plugin/marketplace.json
 npm pack --dry-run --json
 ```
 
-5. Push and verify GitHub Actions CI.
+7. Push the branch, open a PR, and verify GitHub Actions CI.
+8. Squash merge the PR into `main`. Do not use merge commits or rebase merge for release PRs.
+9. Create the version tag from the squash commit on `main`.
+10. Create the GitHub release. The body should list merged PRs as linked entries and use a linked compare range, for example:
+
+```md
+## What's Changed
+
+- feat(scope): concise change summary by @author in #123
+
+**Full Changelog**: [v1.7.1...v1.8.0](https://github.com/dotoricode/tink-harness/compare/v1.7.1...v1.8.0)
+```
+
+11. Publish to npm only after the GitHub release and package verification are complete.
 
 ## Existing-user update path
 

package/bin/install.js

@@ -664,6 +664,7 @@ function copySelected(scope, components, agent) {
     copyDir(path.join(templateRoot, 'tink/rules'), path.join(target, '.tink/rules'), target);
     copyDir(path.join(templateRoot, 'tink/schemas'), path.join(target, '.tink/schemas'), target);
     copyDir(path.join(templateRoot, 'tink/maintenance'), path.join(target, '.tink/maintenance'), target);
+    copyDir(path.join(templateRoot, 'tink/tools'), path.join(target, '.tink/tools'), target);
     writeFileFromTemplate(path.join(templateRoot, 'tink/config.json'), path.join(target, '.tink/config.json'), target);
   }
   if (components.includes('memory')) {

package/commands/cast.md

@@ -40,6 +40,12 @@ Map prompt content to `AskUserQuestion` fields:
 - `label`: 1–5 word option name (e.g. "승인", "조정", "취소"). Add "(권장)" to the first option label if it is recommended.
 - `description`: explanatory text for the option
 
+Label quality rules:
+- Use short, common, readable labels only. Good Korean labels are `승인`, `조정`, `취소`, `요구사항 입력`, `기본 하네스만 사용`, `새 하네스 초안 만들기`, `구조 점검`, `내용 점검`, `전체 점검`.
+- Do not invent compressed Korean labels, transliterated fragments, or unclear summaries such as `콘데의달 지질`.
+- If the idea is too specific for a clean 1-5 word label, put the detail in `description` and use a generic label such as `내용 점검` or `전체 점검`.
+- Before calling `AskUserQuestion`, reread each Korean label. If it looks misspelled, unnatural, or semantically unclear, replace it with a plain fallback label.
+
 Use Korean field values when `.tink/config.json` language is `ko` or `auto` with Korean input; use English otherwise.
 
 ## Readiness check
@@ -485,6 +491,15 @@ Do not save if the user approved only the current run. Saving reusable state nee
 ## Approval format
 Use concise, selection-oriented wording. The recommendation must include the first action Tink will perform, not only the harness name.
 
+User-facing approval wording:
+- Do not show internal terms such as `Probe`, `probe`, `합성 프로브`, `generic fit`, `제너릭 fit`, or `Stitch`.
+- Translate the synthesis probe result as `맞춤 절차 판단`.
+- Translate `generic fit` as `기본 하네스는 큰 틀만 맞음` or `기본 하네스만으로는 부족함`.
+- Translate visible Stitch output as `확인할 점`, not `Stitch 점검`.
+- Explain what each selected harness does in one short phrase before asking for approval.
+- Show a short `하네스 선택 과정` when more than one harness or a run-only draft is selected: candidate considered, selected harnesses, and why each was chosen.
+- Prefer natural scope wording such as `완료 기준을 먼저 나누겠습니다` or `이번 점검은 두 범위로 보겠습니다` instead of awkward wording like `"더 잘 동작하기"의 기준이 두 갈래입니다`.
+
 Approval option counts (always exactly one applies):
 - Default (no Stitch, no run-only draft): 4 options — 승인 / 조정 / 새 하네스 초안 만들기 / 취소
 - Run-only draft offered: 4 options — 승인 / 조정 / 기본 하네스만 사용 / 취소
@@ -497,9 +512,16 @@ Approval option counts (always exactly one applies):
 **🎯 Goals**
 - <goal>
 
-**🛠️ Harness**: `code-change + review`
-- **Probe:** 1 yes — built-in 하네스로 충분
-- **이유:** 변경 범위가 좁고, 회귀 확인이 필요합니다.
+**🛠️ 선택한 하네스**: `code-change + review`
+- `code-change`: 범위가 정해진 코드 변경을 작게 수행하는 하네스
+- `review`: 변경 위험과 누락을 확인하는 점검 하네스
+
+**하네스 선택 과정**
+- 후보: `code-change`, `review`, `harness-synthesis`
+- 선택: `code-change + review`
+- 이유: 변경 범위가 좁고, 회귀 확인이 필요합니다. 별도 맞춤 초안은 필요하지 않습니다.
+
+- **맞춤 절차 판단:** 기본 하네스로 충분
 - **첫 실행:** 관련 파일을 먼저 읽고 검증 명령 후보를 확정합니다.
 
 ? 진행할까요?
@@ -517,7 +539,16 @@ If a run-only draft or new harness is useful:
 **🎯 Goals**
 - <goal>
 
-**🛠️ Harness**: `<built-in>` (probe: 3 yes — generic fit)
+**🛠️ 선택한 하네스**: `<built-in> + 임시 초안`
+- `<built-in>`: 기본 작업 흐름을 잡는 하네스
+- `customer-interview-synthesis`: 이번 작업의 인터뷰 분석 순서를 보강하는 임시 초안
+
+**하네스 선택 과정**
+- 후보: `<built-in>`, `harness-synthesis`, `customer-interview-synthesis`
+- 선택: `<built-in> + customer-interview-synthesis`
+- 이유: 기본 하네스는 큰 틀만 맞고, 인터뷰 원문 근거와 pain point 구분은 별도 절차가 필요합니다.
+
+**맞춤 절차 판단:** 기본 하네스만으로는 부족함
 
 **임시 하네스 초안** (이번 작업 전용):
 - **name:** `customer-interview-synthesis`
@@ -536,7 +567,7 @@ If a run-only draft or new harness is useful:
   4. 취소
 ```
 
-If Stitch triggers as a soft gate, merge it into the approval format. The user-facing block uses plain language — never the word `Stitch`. The Korean default uses `점검 사항`; English uses `Review note`:
+If Stitch triggers as a soft gate, merge it into the approval format. The user-facing block uses plain language — never the word `Stitch`. The Korean default uses `확인할 점`; English uses `Review note`:
 
 ```text
 ### 🧶 Run: <task name>
@@ -544,13 +575,20 @@ If Stitch triggers as a soft gate, merge it into the approval format. The user-f
 **🎯 Goals**
 - <goal>
 
-**🔍 점검 사항**
+**🔍 확인할 점**
 - 제안: <one proposal>
 - 이유: <reason>
 - 이대로 진행 시 가정: <explicit assumption>
 
-**🛠️ Harness**: `<harness>`
-- **Probe:** ...
+**🛠️ 선택한 하네스**: `<harness>`
+- `<harness>`: <what this harness does in one short phrase>
+
+**하네스 선택 과정**
+- 후보: <candidate harnesses>
+- 선택: `<harness>`
+- 이유: <why selected>
+
+- **맞춤 절차 판단:** <기본 하네스로 충분 | 기본 하네스만으로는 부족함 | 새 맞춤 절차 필요>
 - **이유:** ...
 - **첫 실행:** ...
 
@@ -712,4 +750,4 @@ If a check fails:
 - Do not store raw logs, full diffs, secrets, or one-off task progress as reusable memory.
 - Do not ask "do you want to save?" before showing the Reusable State Save Gate payload. Show the payload directly.
 - Do not narrate .tink/ file writes (current/, runs/, memory/, config.json) in the response body. Do not show diff summaries, file lists, or "I created X / I updated Y" breakdowns. The tool-use header is sufficient on its own. At the end of the response, add at most one short sentence summarizing what changed across all .tink/ writes.
-- Do not use Tink-internal jargon (Stitch, hard gate, Save Gate, Reusable State, or temporary labels like G1/G2/G3) when writing user-facing responses. Translate to plain language matching `config.json` language. Internal documentation and code keep original terms for consistency.
+- Do not use Tink-internal jargon (Stitch, Probe, synthesis probe, generic fit, hard gate, Save Gate, Reusable State, or temporary labels like G1/G2/G3) when writing user-facing responses. Translate to plain language matching `config.json` language. Internal documentation and code keep original terms for consistency.

package/commands/frog.md

@@ -22,10 +22,15 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
 
 ## Procedure
 1. Read `.tink/harnesses/index.json`.
+1b. Prepare the harness health summary:
+   - If `.tink/tools/generate-harness-lifecycle-summary.mjs` exists, run `node .tink/tools/generate-harness-lifecycle-summary.mjs` from the repo root before ranking candidates.
+   - If the generator is missing, continue with the compact evidence below and say the health summary is unavailable.
+   - Treat the generated `.tink/maintenance/harness-lifecycle.json` as a report, not as approval or reusable memory.
 2. Check compact evidence if available:
    - `.tink/runs/` summaries
    - `.tink/maintenance/ledger.jsonl`
    - `.tink/maintenance/weave-queue.json`
+   - `.tink/maintenance/harness-lifecycle.json` or another lifecycle summary that follows `.tink/schemas/harness-lifecycle.schema.json`
    - `.tink/rules/index.json`
    - references in memory files
    - recent git history touching harness files as weak context only
@@ -43,6 +48,8 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
    - strong: multiple run or ledger records show non-use, repeated rejection, replacement, or accepted alternative
    - medium: one run or ledger record plus clear overlap or memory evidence
    - weak: static index, git-only evidence, stale current notes, or model judgment
+   If a lifecycle summary is present, treat it as a health summary, not as authority. Use its `confidence`, `evidence_grade`, `evidence_handles`, and `safe_next_action` to explain the recommendation. A low-confidence or weak lifecycle entry must default to `keep`, `observe`, or `needs evidence`.
+   Sort lifecycle-backed candidates first by evidence strength, then by recommendation: `frog_candidate`, `merge_candidate`, `weave`, `observe`, `keep`.
 5. Identify candidates:
    - never used with strong evidence
    - not used recently with strong evidence
@@ -63,6 +70,7 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
    Prefer keep, rewrite, split, merge, or needs evidence before any removal proposal.
    Report rule recommendations separately from harness recommendations.
 7. Only strong evidence may recommend `delete`. Medium evidence may recommend `merge` or `hone`. Weak evidence must default to `keep` or `needs evidence`.
+   Lifecycle recommendations follow the same rule: `frog_candidate` means "prepare a cleanup review," not "delete." Deletion, archive, merge, harness edit, rule update, and memory save still need the normal approval payload.
 8. For each non-keep action, prepare an operation-specific approval payload with exact files, op ID, evidence handles, and rollback.
 9. If the recommendation is `weave`, write or present a weave handoff packet and, after approval, add it to `.tink/maintenance/weave-queue.json`:
    - id

package/commands/weave.md

@@ -26,6 +26,8 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
    - Auto signals from completed runs (entries where `auto: true`)
    Count auto signals per harness: `check_failed` signals count as 2, all other outcomes count as 1. Use this frequency to rank improvement candidates — harnesses with the highest signal count should be improved first. If invoked from `/tink:frog`, also read the purge output and `.tink/current/notes.md` for the weave handoff packet.
    If `.tink/maintenance/friction.jsonl` exists, read only compact recent entries and count repeated `check_failed`, `check_skipped`, `blocked`, gate denial, or rollback events. Repeated friction can justify a harness edit, rule graph update, or opt-in guard candidate.
+   If `.tink/tools/generate-harness-lifecycle-summary.mjs` exists, run `node .tink/tools/generate-harness-lifecycle-summary.mjs` from the repo root before ranking candidates. The generated `.tink/maintenance/harness-lifecycle.json` is a report, not approval or reusable memory.
+   If `.tink/maintenance/harness-lifecycle.json` or another summary following `.tink/schemas/harness-lifecycle.schema.json` exists, read it as a harness health summary. Prefer entries with recommendation `weave`, high or medium confidence, and concrete `evidence_handles`. Low-confidence entries should stay as observation unless the user explicitly asks to act on them.
 2. Identify one or a few active harnesses to improve using real failures and evidence:
    - repeated mistakes
    - user corrections
@@ -34,6 +36,7 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
    - confusing approval prompts
    - too much context footprint
    - missing done criteria
+   Rank lifecycle-backed `weave` candidates ahead of raw queue counts when they cite concrete evidence handles and medium or high confidence. Use raw queue and friction counts to break ties.
 3. Require concrete evidence handles before proposing a save:
    - run record path or run ID
    - current notes path when same-conversation certainty exists
@@ -41,6 +44,7 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
    - friction entry timestamp/type
    - compact user correction snippet
    - purge handoff ID from `.tink/maintenance/weave-queue.json`
+   - lifecycle summary evidence handle plus the source run, ledger, queue, or friction entry it points to
 4. Classify the evidence as repeated or single-run. Single-run evidence may suggest a trial edit, but should not become broad policy unless the user explicitly approves.
 5. Explain why the change belongs in the harness rather than `.tink/memory/` or `.tink/current/notes.md`.
 6. Decide the right destination:

package/docs/harness-lifecycle-signals.ko.md

@@ -1,6 +1,12 @@
 # 하네스 생애주기 신호
 
-하네스 생애주기 신호는 Tink가 하네스를 계속 관찰할지, 개선할지, 정리 후보로 둘지, 겹치는 하네스와 병합 후보로 둘지 판단하는 데 도움을 준다.
+하네스 생애주기 신호는 재사용 하네스의 건강 요약이다.
+Tink가 지난 실행 기록을 읽고 다음 질문에 답할 수 있게 돕는다.
+
+- 어떤 하네스가 실제로 쓰였는가?
+- 어디서 check가 실패하거나 막혔는가?
+- 어떤 하네스는 `/tink:weave`로 조금 고치면 좋은가?
+- 어떤 하네스는 정리하거나 병합 후보로 볼 수 있는가?
 
 스키마는 `templates/tink/schemas/harness-lifecycle.schema.json`에 둔다.
 
@@ -10,8 +16,24 @@
 - `successes`: 필수 검증까지 완료한 실행.
 - `failures`: 필수 check 실패.
 - `blocked`: check를 실행할 수 없었던 경우.
+- `last_used`: 마지막으로 확인된 사용 시각. 기록이 없으면 `null`.
+- `success_rate`: 사용 횟수 대비 검증 완료 비율. 근거가 부족하면 `null`.
+- `failure_rate`: 사용 횟수 대비 필수 check 실패 비율. 근거가 부족하면 `null`.
+- `co_used_with`: 같은 run에서 자주 함께 나온 하네스.
+- `sequence_hints`: 한 하네스 뒤에 다른 단계가 반복해서 따라온 순서 힌트.
+- `rule_refs`: 같은 run 기록에 나온 rule id.
+- `memory_refs`: 같은 run 기록에 나온 memory 파일.
 - `context_cost`: low, medium, high, unknown.
 
+요약에는 이후 리포트와 대시보드가 읽기 쉬운 작은 `graph` 블록도 들어간다.
+
+- `graph.nodes`: harness, rule, memory, stage 노드.
+- `graph.edges`: `co_used`, `sequence`, `uses_rule`, `uses_memory` 같은 관계.
+
+이 graph는 같은 보이는 기록에서 만든 보기용 모델이다. hidden cache나 background index가 아니다.
+
+`timeline` 블록은 최근 run event를 최신순으로 담는다. 각 event에는 날짜, source, status, outcome, 선택된 하네스가 들어간다. HTML 리포트는 이 값을 사용해 브라우저에서 파일을 다시 replay하지 않고도 실패, blocked, 성공 검증 흐름을 보여준다.
+
 허용되는 추천은 다음과 같다.
 
 - `keep`
@@ -20,4 +42,53 @@
 - `merge_candidate`
 - `observe`
 
-추천은 제안일 뿐이다. reusable harness를 삭제, 병합, 재작성하려면 여전히 명시적인 승인이 필요하다.
+각 하네스에는 `candidate_score`가 들어갈 수 있다. 이 값은 0부터 100까지의 `total`과 evidence, trouble, context cost, overlap, recommendation priority 같은 factor로 구성된 정렬 보조 신호다. 승인으로 해석하면 안 되며 자동 수정으로 이어져도 안 된다.
+
+각 하네스에는 `lifecycle_state`도 있다.
+
+- `active`: 최근에도 쓰여서 일반 관찰을 유지한다.
+- `no_evidence`: run 기록에 나오지 않았다.
+- `dormant_candidate`: 최근에 쓰이지 않았지만, 오래됐다는 이유만으로는 보관 검토 신호일 뿐이다.
+- `cleanup_review`: 정리 검토 근거가 강하지만 여전히 승인이 필요하다.
+- `needs_weave`: 반복 문제로 weave 검토가 필요하다.
+- `merge_review`: 반복 overlap으로 merge 검토가 필요하다.
+
+근거 판단은 보수적으로 한다.
+
+- 기록이 없거나 근거가 약함 → `observe`
+- 실패나 blocked가 반복됨 → `weave`
+- 함께 쓰이는 패턴이 반복됨 → `merge_candidate`
+- 미사용, 반복 거절, 대체, 높은 context 비용 같은 강한 근거가 있음 → `frog_candidate`
+
+추천은 제안일 뿐이다. reusable harness 삭제, 병합, 재작성, memory 저장, rule 업데이트는 여전히 명시적인 승인이 필요하다. 생애주기 요약은 다음 행동을 준비할 수 있지만 자동으로 적용하면 안 된다.
+
+## 로컬 HTML 리포트
+
+설치된 repo에는 작은 읽기 전용 helper 두 개가 함께 들어간다. 먼저 보이는 `.tink/` 기록에서 JSON 요약을 만든다.
+
+```bash
+node .tink/tools/generate-harness-lifecycle-summary.mjs
+```
+
+기본값으로 `.tink/harnesses/index.json`, `.tink/rules/index.json`, `.tink/memory/*.md`, `.tink/runs/*.md`, `.tink/maintenance/weave-queue.json`, `.tink/maintenance/friction.jsonl`을 읽고 `.tink/maintenance/harness-lifecycle.json`을 쓴다.
+
+그 다음 이 요약을 로컬 HTML 리포트로 바꿀 수 있다.
+
+```bash
+node .tink/tools/render-harness-health-report.mjs
+```
+
+리포트 helper는 `.tink/maintenance/harness-lifecycle.json`을 읽고 `.tink/maintenance/harness-health-report.html`을 쓴다. 테스트할 때는 경로를 직접 줄 수 있다.
+
+리포트에는 정적 graph overview, 최근 run timeline, 하네스별 카드가 들어간다. graph overview는 JSON `graph` 블록의 node/edge 종류를 요약한다. 서버를 시작하거나 파일을 감시하지 않는다.
+
+```bash
+node .tink/tools/generate-harness-lifecycle-summary.mjs repo-root output.json
+node .tink/tools/render-harness-health-report.mjs input.json output.html
+```
+
+두 helper는 재사용 Tink 상태를 고치지 않는다. 요청한 요약 파일이나 리포트 파일만 쓴다. 하네스 수정, 병합, 보관, 삭제, memory 저장, rule 업데이트는 하지 않는다.
+
+`/tink:weave`와 `/tink:frog`는 생성기가 설치되어 있으면 후보를 정렬하기 전에 이 요약을 먼저 준비해야 한다. 요약은 근거 강도에 따라 후보를 보기 좋게 정렬하는 데 쓰지만, 재사용 상태를 바꾸기 전에는 여전히 기존 승인 payload를 보여줘야 한다.
+
+이 기능은 watcher, hidden cache, 새 public `tink index` 명령이 아니다. 기준이 되는 원본은 계속 `.tink/runs/`, `.tink/maintenance/`, `.tink/harnesses/`, `.tink/rules/` 아래의 보이는 파일이다.