tink-harness 1.7.1 → 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.7.1",
+  "version": "1.9.0",
   "author": {
     "name": "dotori"
   }

package/CHANGELOG.md

@@ -7,6 +7,38 @@ 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
+
+- Added four visible-thinking harnesses selected through `/tink:cast` and `$tink:cast`: `requirements-interview`, `plan-consensus`, `goal-checkpoint`, and `delegation-brief`.
+- Added optional current-run artifact guidance for `.tink/current/goals.json` and `.tink/current/delegation.md`.
+- Added rule graph routing for ambiguous requirements, broad plans, long runs, and safe delegation briefs without adding new public commands.
+- Added Korean PR history draft for the v1.8.0 release in `docs/pr/2026-06-09-v1.8.0.ko.md`.
+
+### Changed
+
+- Updated Claude Code and Codex cast guidance so GJC-style interview, consensus planning, goal checkpoint, and delegation concepts stay inside Tink's small harness model.
+- Updated README and work-state docs to explain the new harnesses and optional run-state files.
+
+
 ## [1.7.1] - 2026-06-09
 
 ### Fixed

package/README.ko.md

@@ -8,9 +8,9 @@ Claude Code와 Codex를 위한 작은 하네스 레이어입니다.
 
 Tink는 지금 작업에 맞는 하네스를 고르고, 실행 상태를 보이게 만들고, 실제 사용 중 생긴 실패와 피드백으로 하네스 세트를 개선합니다.
 
-**최신 패키지:** v1.7.1 — "둘 다" surface와 "Clean Codex picker"를 함께 선택했을 때 Claude Code 명령이 삭제되던 버그를 수정합니다. 최신 마이너 릴리스 노트: [v1.7.0](https://github.com/dotoricode/tink-harness/releases/tag/v1.7.0).
+**최신 패키지:** v1.9.0 — 하네스 건강 요약, graph, timeline, 후보 점수, 생애주기 상태, 정적 로컬 리포트를 추가합니다. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
 
-[English](README.md) · **한국어**
+[English](README.md) · **한국어** · [변경 이력](CHANGELOG.md)
 
 ---
 
@@ -59,61 +59,6 @@ npx tink-harness@latest update
 
 업데이트 후 Codex skill, schema, Windows 경고가 이상해 보이면 `docs/update-troubleshooting.ko.md` 또는 `docs/update-troubleshooting.md`를 확인하세요.
 
-## 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:*`입니다.
@@ -124,6 +69,8 @@ Claude Code에서는 `/tink:*`, Codex에서는 `$tink:*`을 씁니다. 예전 `$
 
 Tink는 이제 비단순 작업에 대해 `.tink/current/contract.json`도 만듭니다. 이 파일에는 작업 종류, 위험, 성공 조건, 금지 사항, 검증 명령이 들어갑니다.
 
+더 크거나 모호한 작업에서는 `cast`가 에이전트의 생각 단계를 파일로 더 잘 드러내는 하네스를 고를 수 있습니다. 모호한 아이디어는 `requirements-interview`, 큰 계획은 `plan-consensus`, 긴 실행은 `goal-checkpoint`, 안전한 인수인계는 `delegation-brief`를 씁니다. 모두 `/tink:cast` 또는 `$tink:cast`가 고르는 재사용 하네스이며, 별도 CLI 명령은 아닙니다.
+
 ### `/tink:verify` / `$tink:verify`
 
 `contract.json`에 적힌 검증을 실제로 실행하고 증거를 남깁니다.
@@ -156,15 +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.7.1 - Fixes accidental deletion of Claude Code commands when "Both" surface and "Clean Codex picker" were selected together. Latest minor release notes: <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.7.0">v1.7.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,63 +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.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.
@@ -195,6 +138,8 @@ In Tink, `cast` is the main path. It reads the task, chooses or drafts the right
 
 Use it when the task is more than a quick answer.
 
+For bigger or fuzzier work, `cast` can expose more of the agent's thinking as files without adding new commands. Ambiguous ideas can start with `requirements-interview`, broad plans with `plan-consensus`, long runs with `goal-checkpoint`, and safe handoffs with `delegation-brief`. These are reusable harnesses selected by `/tink:cast` or `$tink:cast`, not separate CLI workflows.
+
 ### `/tink:verify` / `$tink:verify`
 
 `verify` runs the checks promised in `.tink/current/contract.json`.
@@ -237,9 +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.7.1`
+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
@@ -147,6 +153,11 @@ After approval, create `.tink/current/` with these files before doing deeper wor
 - `context-metrics-evaluation.json`: measured or estimated context-efficiency scores, formulas, evidence refs, and limits
 - `excluded-context.md`: notable omitted files, tools, sources, or claims and why they were excluded
 
+Optional current-run artifacts are created only when their harness is selected:
+
+- `goals.json`: current-run goals for `goal-checkpoint`; keep 2-6 goals, one active goal, status, done criteria, verification, and evidence.
+- `delegation.md`: handoff or parallel-work packets for `delegation-brief`; include packet scope, forbidden actions, expected evidence, and reconciliation notes. Do not start tmux panes, worktrees, workers, or external agents from this harness.
+
 Create `contract.json` before loading harness bodies. It should be short, factual, and based on the user request plus visible project context:
 
 ```json
@@ -389,34 +400,39 @@ A task is trivial only when ALL of the following are true:
    - docs
    - ship/release
    - new pattern not covered yet
-6. Pick the best existing harness set using the context budget policy below. Prefer 1-3 harnesses, but do not use a hard cap when several tiny harnesses add useful checks without crowding context. When the task is ambiguous (Stitch goal-ambiguity is expected to trigger), start with a single best-fit harness; add a second only after the user clarifies. Do not bundle 2+ harnesses for ambiguous tasks upfront.
+6. Consider GJC-style visible-thinking overlays as normal Tink harnesses, not as new command surfaces:
+   - If the request is an ambiguous idea, early product concept, or underspecified implementation prompt, prefer `requirements-interview` before planning or coding. This is the default harness when Stitch is expected to trigger for goal ambiguity.
+   - If the request asks for a plan, architecture decision, large refactor, migration, or broad public contract change, consider `plan-consensus`.
+   - If the work naturally splits into multiple durable milestones, add `goal-checkpoint` and create `.tink/current/goals.json` after approval.
+   - If parallel review, verification, or handoff would reduce risk, add `delegation-brief` and create `.tink/current/delegation.md` after approval. This harness prepares briefs only; it never starts tmux, worktrees, workers, or external agents.
+7. Pick the best existing harness set using the context budget policy below. Prefer 1-3 harnesses, but do not use a hard cap when several tiny harnesses add useful checks without crowding context. When the task is ambiguous (Stitch goal-ambiguity is expected to trigger), start with `requirements-interview` alone; add a second harness only after the user clarifies. Do not bundle 2+ harnesses for ambiguous tasks upfront.
 
    After selecting, run a quick quality check using the index metadata for each chosen harness:
    - If fewer than 2 words in `use_when` match the current task description (case-insensitive) → treat as a Stitch harness-mismatch signal
    - If `checks` is empty or missing → treat as a Stitch harness-mismatch signal
    - If `asks` is empty or missing and the task goal is not self-evident → treat as a Stitch goal-ambiguity signal
-   Feed any signals into the Stitch evaluation at step 11.
-
-7. Add any rule graph check candidates to `contract.json` verification if they are relevant and cheap. For risky commands, set `approval_required: true`.
-8. Add opt-in guard candidates to `notes.md` only as suggestions. Do not register enforcement hooks unless the user separately approves.
-9. Run the synthesis probe on the initial harness choice. The probe produces one of three outcomes: strong fit (0-1 yes), generic fit (2-3 yes), or no fit (4-5 yes or no harness matches).
-10. If the probe finds no fit, load `harness-synthesis` and draft a domain-specific harness for this run instead of forcing a bad fit.
-11. If the probe finds a generic fit (2-3 yes), propose a run-only draft harness or domain rules alongside the built-in harness. Do not save it by default.
-12. If too many tools, skills, agents, or harnesses are available, load `harness-curation` and choose the smallest effective set before loading more context.
-13. If lightweight signals show a recurring operating habit, use `harness-curation` (its habit calibration section) to make one advisory recommendation without loading a separate body.
-14. If the user points to research, notes, examples, prior failures, or "what I learned today", synthesize from those inputs. Extract behavior-shaping rules and reusable procedure, not a summary.
-15. Run Stitch once before committing to `.tink/current/`. If it triggers, show exactly one proposal before approval. Call `AskUserQuestion` as described in the Interaction policy section.
-16. Ask for explicit approval before non-trivial work.
-17. After approval, read only the selected harness files and any approved run-only draft.
-18. Create `.tink/current/` files from the run state contract, including `contract.json`, `session.json`, `context-pack.md`, `context-map.json`, `context-metrics-evaluation.json`, and `excluded-context.md`.
-19. Execute the first safe step immediately:
+   Feed any signals into the Stitch evaluation at step 16.
+
+8. Add any rule graph check candidates to `contract.json` verification if they are relevant and cheap. For risky commands, set `approval_required: true`.
+9. Add opt-in guard candidates to `notes.md` only as suggestions. Do not register enforcement hooks unless the user separately approves.
+10. Run the synthesis probe on the initial harness choice. The probe produces one of three outcomes: strong fit (0-1 yes), generic fit (2-3 yes), or no fit (4-5 yes or no harness matches).
+11. If the probe finds no fit, load `harness-synthesis` and draft a domain-specific harness for this run instead of forcing a bad fit.
+12. If the probe finds a generic fit (2-3 yes), propose a run-only draft harness or domain rules alongside the built-in harness. Do not save it by default.
+13. If too many tools, skills, agents, or harnesses are available, load `harness-curation` and choose the smallest effective set before loading more context.
+14. If lightweight signals show a recurring operating habit, use `harness-curation` (its habit calibration section) to make one advisory recommendation without loading a separate body.
+15. If the user points to research, notes, examples, prior failures, or "what I learned today", synthesize from those inputs. Extract behavior-shaping rules and reusable procedure, not a summary.
+16. Run Stitch once before committing to `.tink/current/`. If it triggers, show exactly one proposal before approval. Call `AskUserQuestion` as described in the Interaction policy section.
+17. Ask for explicit approval before non-trivial work.
+18. After approval, read only the selected harness files and any approved run-only draft.
+19. Create `.tink/current/` files from the run state contract, including `contract.json`, `session.json`, `context-pack.md`, `context-map.json`, `context-metrics-evaluation.json`, and `excluded-context.md`. If selected, also create `goals.json` for `goal-checkpoint` and `delegation.md` for `delegation-brief`.
+20. Execute the first safe step immediately:
    - inspect relevant files,
    - run a read-only diagnostic,
    - draft the first artifact,
    - or reproduce the issue.
-20. Keep `steps.json`, `notes.md`, `contract.json`, and `session.json` current as work progresses.
-21. Before final, run `/tink:verify` behavior for required contract checks or state why verification is blocked.
-22. If the task exposed a repeated mistake or reusable improvement, use the Reusable State Save Gate approval payload below. Save only after separate user approval.
+21. Keep `steps.json`, `notes.md`, `contract.json`, and `session.json` current as work progresses. When present, keep `goals.json` and `delegation.md` aligned with actual status and evidence.
+22. Before final, run `/tink:verify` behavior for required contract checks or state why verification is blocked.
+23. If the task exposed a repeated mistake or reusable improvement, use the Reusable State Save Gate approval payload below. Save only after separate user approval.
 
 
 ## Synthesis probe
@@ -475,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 — 승인 / 조정 / 기본 하네스만 사용 / 취소
@@ -487,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`
+- 이유: 변경 범위가 좁고, 회귀 확인이 필요합니다. 별도 맞춤 초안은 필요하지 않습니다.
+
+- **맞춤 절차 판단:** 기본 하네스로 충분
 - **첫 실행:** 관련 파일을 먼저 읽고 검증 명령 후보를 확정합니다.
 
 ? 진행할까요?
@@ -507,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`
@@ -526,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>
@@ -534,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>
+
+- **맞춤 절차 판단:** <기본 하네스로 충분 | 기본 하네스만으로는 부족함 | 새 맞춤 절차 필요>
 - **이유:** ...
 - **첫 실행:** ...
 
@@ -637,6 +685,42 @@ Before saving, score the candidate 1-5 on specificity, actionability, verifiabil
 }
 ```
 
+## `goals.json` template
+Use only when `goal-checkpoint` is selected:
+
+```json
+{
+  "goals": [
+    {
+      "id": "G1",
+      "status": "active",
+      "description": "",
+      "done_criteria": [],
+      "verification": [],
+      "evidence": [],
+      "next_action": ""
+    }
+  ]
+}
+```
+
+## `delegation.md` template
+Use only when `delegation-brief` is selected:
+
+```md
+# Delegation brief
+
+## Shared constraints
+-
+
+## Packets
+### Packet 1: <owner label>
+- Scope:
+- Forbidden:
+- Expected evidence:
+- Reconciliation notes:
+```
+
 ## Meaning of `context`
 When listing harnesses, define `context` once:
 
@@ -666,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