tink-harness 1.15.4 → 1.16.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "tink",
3
3
  "description": "A small harness layer for Claude Code and Codex.",
4
- "version": "1.15.4",
4
+ "version": "1.16.0",
5
5
  "author": {
6
6
  "name": "dotori"
7
7
  }
package/CHANGELOG.md CHANGED
@@ -4,7 +4,9 @@ All notable changes to Tink are tracked here.
4
4
 
5
5
  ## Unreleased
6
6
 
7
- - Added a geobench product spec and runbook for measuring Tink's LLM answer visibility with hit rate, MRR, share of voice, and citation metrics. The runbook keeps benchmark execution separate from this repo and says to publish aggregate metrics only.
7
+ ## [1.16.0] - 2026-06-25
8
+
9
+ - `/tink:deep-cast` 신규 명령 추가: `cast_mode`를 변경하지 않고 이번 작업 한 번만 deep 모드(구조화 인터뷰)로 실행한다. `/tink:cast deep`이 기본값을 영구 변경하는 것과 구분된다.
8
10
 
9
11
  ## [1.15.4] - 2026-06-24
10
12
 
package/README.ko.md CHANGED
@@ -1,67 +1,30 @@
1
- <p align="center">
1
+ <p align="center">
2
2
  <img src=".github/assets/hero.webp" alt="Tink Hero Banner" width="100%">
3
3
  </p>
4
4
 
5
5
  # Tink
6
6
 
7
- **Claude Code · Codex 작업의 맥락이 더는 사라지지 않게.**
8
-
9
- Tink는 사소하지 않은 모든 에이전트 작업을 눈에 보이는 파일로 남깁니다 — 작업 계약, 실행 상태, 검증 단계, 그리고 승인해야만 저장되는 재사용 하네스. 서버도, 텔레메트리도, 숨은 상태도 없습니다.
7
+ **Claude Code · Codex 에이전트 작업을 눈에 보이게, 재사용 가능하게, 승인 게이트로. 서버도, 숨은 상태도 없이.**
10
8
 
11
9
  <sub>Claude Code와 Codex를 위한 작은 하네스 레이어</sub>
12
10
 
13
- **최신 패키지:** v1.15.4 — deep 모드 인터뷰 UX 개선: 라운드 표시 적응형 전환, 구성 요소 이모지 표기, 질문 없을 때 표시 생략. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
11
+ <p>
12
+ <a href="https://github.com/dotoricode/tink-harness/releases/latest"><img src="https://img.shields.io/github/v/release/dotoricode/tink-harness?label=release&color=2ea44f" alt="GitHub release"></a>
13
+ <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>
14
+ <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>
15
+ <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>
16
+ <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>
17
+ </p>
14
18
 
15
19
  [English](README.md) · **한국어** · [변경 이력](CHANGELOG.md)
16
20
 
17
21
  ---
18
22
 
19
- ## 누구를 위한 도구인가
20
-
21
- 이런 순간에 쓰세요:
22
-
23
- - Claude Code나 Codex가 작업 사이에 맥락을 자꾸 잃을 때
24
- - 같은 리뷰 / 리팩터링 / 디버깅 절차를 매번 손으로 반복할 때
25
- - 숨은 채팅 기억 대신 눈에 보이는 실행 상태를 원할 때
26
- - 재사용 가능한 에이전트 워크플로를 원하지만, 명시적 승인 후에만 저장되길 원할 때
27
-
28
- 내 얘기 같다면, 버려도 되는 repo에서 먼저 시도해 보세요:
29
-
30
- ```bash
31
- npx tink-harness@latest install
32
- ```
33
-
34
- ## 실제로 남는 것
35
-
36
- 사소하지 않은 작업마다 열어보고, diff하고, 커밋할 수 있는 평범한 파일이 남습니다:
37
-
38
- ```text
39
- .tink/current/ # 진행 중인 실행 — 언제든 열람 가능
40
- contract.json # 작업이 끝났을 때 참이어야 하는 것
41
- plan.md # 눈에 보이는 계획
42
- checks.md # "완료" 선언 전 돌릴 검증
43
- .tink/runs/
44
- 2026-06-11-1430-auth-refactor.md # 끝난 실행의 간결한 기록
45
- .tink/harnesses/
46
- refactor-review.md # 재사용 작업 방식 — 승인해야 저장
47
- ```
48
-
49
- ## CLAUDE.md·슬래시 명령·스킬만으로는 왜 부족할까?
50
-
51
- | 도구 | 제공하는 것 | Tink가 얹는 것 |
52
- |---|---|---|
53
- | CLAUDE.md | 프로젝트 전역 지침 | 작업 단위 계약·실행 상태·검증 |
54
- | 슬래시 명령 | 재사용 프롬프트 | 하네스 선택, 실행 기록, 진행도 추적 |
55
- | 스킬 | 재사용 능력 | 사용 생애주기: 건강 점수·정리·개선 신호 |
56
- | MCP | 외부 컨텍스트·도구 | 로컬, 승인 게이트 워크플로 메모리 |
57
-
58
- Tink는 이들을 대체하지 않고 함께 동작합니다.
23
+ Tink가 없으면 에이전트 작업의 맥락은 매번 채팅 기록 속으로 사라집니다. 같은 리뷰·리팩터링·디버깅을 손으로 반복하고, 재사용하겠다고 적어둔 워크플로는 어딘가에 묻혀버립니다.
59
24
 
60
- ---
61
-
62
- ## 빠른 시작
25
+ Tink를 쓰면 사소하지 않은 모든 작업마다 읽고, diff하고, 커밋할 수 있는 파일이 남습니다 — 작업 계약, 눈에 보이는 계획, 검증 단계. 재사용 워크플로(하네스)는 명시적 승인 후에만 저장되고, 실제 run 기록을 바탕으로 점점 나아집니다. 그 기록이 로컬 건강 대시보드가 됩니다.
63
26
 
64
- 1분이면 Tink를 직접 써볼 수 있습니다.
27
+ ## 1분이면 시작됩니다
65
28
 
66
29
  **Claude Code (플러그인):**
67
30
 
@@ -78,7 +41,7 @@ Tink는 이들을 대체하지 않고 함께 동작합니다.
78
41
  npx tink-harness@latest install
79
42
  ```
80
43
 
81
- 설치 중 `Claude Code`, `Codex`, 또는 둘 다를 선택할 수 있고, 언어는 `LANG`을 자동 감지합니다(`--lang=en|ko|zh`로 변경). Codex에서는 `$tink:cast <task>`로 시작합니다.
44
+ 설치 중 `Claude Code`, `Codex`, 또는 둘 다를 선택할 수 있고, 언어는 `LANG`을 자동 감지합니다(`--lang=en|ko|zh`로 변경 가능).
82
45
 
83
46
  <details>
84
47
  <summary>repo 내부 Codex smoke 검증 (CODEX_HOME)</summary>
@@ -97,121 +60,107 @@ npx tink-harness@latest install
97
60
  $tink:cast 인증 모듈 리팩터링 # Codex
98
61
  ```
99
62
 
100
- `cast`는 작업에 맞는 하네스를 고르고(없으면 초안을 만들고), `.tink/current/`에 보이는 계획을 쓰고, 승인 후 첫 안전한 단계를 시작합니다. 끝난 run마다 간결한 기록이 남고 — 그 기록이 아래 대시보드가 됩니다.
101
-
102
- ## 하네스 건강을 눈으로 확인
103
-
104
- 몇 번의 run이 쌓이면, 명령 하나로 기록을 로컬 대시보드로 만들어 브라우저까지 열어 줍니다:
105
-
106
- ```bash
107
- npx tink-harness dashboard # 파일만 만들려면 --no-open 추가
108
- ```
109
-
110
- 내부적으로는 읽기 전용 helper 두 개(`node .tink/tools/generate-harness-lifecycle-summary.mjs` → `node .tink/tools/render-harness-health-report.mjs`)를 실행한 뒤 `.tink/maintenance/harness-health-report.html`을 엽니다.
63
+ `cast`는 작업에 맞는 하네스를 고르고(없으면 초안을 만들고), `.tink/current/`에 보이는 계획을 쓰고, 승인 후 첫 안전한 단계를 시작합니다.
111
64
 
112
65
  ![Tink 대시보드 데모 — 건강 그룹 클릭, 하네스 카드 탐색, 3D 지도 조작](.github/assets/demo.gif)
113
66
 
114
- <sub>당신의 워크플로와 맞는다면, ⭐ 하나가 다른 개발자들이 찾는 데 도움이 됩니다.</sub>
115
-
116
- 하네스와 그들이 쓰는 규칙·메모리, 그 연결을 보여주는 인터랙티브 3D 지도 — 무리마다 고유한 색을 갖고, 살아있는 관계 위로 신호가 흐릅니다:
117
-
118
- ![Tink 하네스 지도 — 하네스·규칙·메모리·단계를 보여주는 인터랙티브 3D 뷰](.github/assets/dashboard-map.ko.png)
119
-
120
- 실제 사용량 순으로 정렬된 하네스 카드 — 쉬운 말 건강 요약, 주의 점수, 승인 이력, 그리고 Claude Code·Codex 양쪽 복사용 명령이 포함된 다음 행동 제안:
121
-
122
- ![사용량 순 하네스 카드와 쉬운 말 건강 요약·히스토리](.github/assets/dashboard-harnesses.ko.png)
123
-
124
- 서버도, 텔레메트리도, 숨은 캐시도 없습니다 — 제안만 준비하는 정적 로컬 페이지입니다. 재사용되는 변경은 여전히 Tink의 승인 절차를 거칩니다.
67
+ <sub>워크플로와 맞는다면 ⭐ 하나가 다른 개발자들이 찾는 데 도움이 됩니다.</sub>
125
68
 
126
69
  ---
127
70
 
128
- ## GEO 노출도 측정
129
-
130
- Tink에는 LLM 답변에서 Tink가 얼마나 자주 언급되고, 어느 순위로 추천되며, 어떤 출처로 인용되는지 측정하기 위한 geobench 제품 스펙이 포함되어 있습니다.
71
+ ## 이런 순간에 쓰세요
131
72
 
132
- - Spec: [`geobench/tink-harness.yaml`](geobench/tink-harness.yaml)
133
- - Runbook: [`docs/geobench.md`](docs/geobench.md)
134
- - 지표: hit rate, MRR, share of voice, citation rate/share, confidence interval
135
-
136
- 벤치마크 결과는 집계 지표만 공개하세요. 원문 provider 답변, 시크릿, 개인 실행 로그는 공개하지 않습니다.
73
+ - Claude Code나 Codex가 작업 사이에 맥락을 자꾸 잃을 때
74
+ - 같은 리뷰 / 리팩터링 / 디버깅 절차를 매번 손으로 반복할 때
75
+ - 숨은 채팅 기억 대신 눈에 보이는 실행 상태를 원할
76
+ - 재사용 가능한 에이전트 워크플로를 원하지만, 명시적 승인 후에만 저장되길 원할 때
137
77
 
138
78
  ---
139
79
 
140
- ## 만들었나
141
-
142
- 새로운 AI 코딩 하네스와 워크플로는 계속 늘어납니다. 좋은 것도 많지만, 여러 개를 섞다 보면 환경이 무거워지고 매번 다시 정리해야 합니다.
143
-
144
- Tink는 큰 프레임워크가 아닙니다. Claude Code나 Codex가 지금 작업에 필요한 절차만 고르고, 없으면 작은 임시 하네스를 만들고, 반복되는 실수만 승인 후 재사용 지식으로 남기도록 돕습니다.
145
-
146
- ## 업데이트
80
+ ## 실제로 남는 것
147
81
 
148
- Claude Code 플러그인:
82
+ 사소하지 않은 작업마다 열어보고, diff하고, 커밋할 수 있는 평범한 파일이 남습니다:
149
83
 
150
84
  ```text
151
- /plugin marketplace update tink-harness
152
- /plugin update tink@tink-harness
153
- /reload-plugins
85
+ .tink/current/ # 진행 중인 실행 — 언제든 열람 가능
86
+ contract.json # 작업이 끝났을 때 참이어야 하는 것
87
+ plan.md # 눈에 보이는 계획
88
+ checks.md # "완료" 선언 전 돌릴 검증
89
+ .tink/runs/
90
+ 2026-06-11-1430-auth-refactor.md # 끝난 실행의 간결한 기록
91
+ .tink/harnesses/
92
+ refactor-review.md # 재사용 작업 방식 — 승인해야 저장
154
93
  ```
155
94
 
156
- Standalone / Codex:
157
-
158
- ```bash
159
- npx tink-harness@latest update
160
- ```
95
+ ## CLAUDE.md·슬래시 명령·스킬만으로는 왜 부족할까?
161
96
 
162
- 업데이트는 질문 하나 어떤 agent surface를 갱신할지 — 만 묻고 나머지는 자동으로 처리합니다. 언어·설치 범위·git 정책은 설치 때 선택한 값을 그대로 재사용하며, ".tink 커밋 안 함"을 선택했다면 업데이트가 `.gitignore`를 절대 건드리지 않습니다. Tink가 관리하는 파일(commands, skills, 런타임 tools)은 항상 최신으로 덮어쓰고, 사용자가 수정한 하네스·메모리·설정과 `.tink/maintenance/`의 모든 기록(ledger 등)은 보존합니다.
97
+ | 도구 | 제공하는 | Tink가 얹는 |
98
+ |---|---|---|
99
+ | CLAUDE.md | 프로젝트 전역 지침 | 작업 단위 계약·실행 상태·검증 |
100
+ | 슬래시 명령 | 재사용 프롬프트 | 하네스 선택, 실행 기록, 진행도 추적 |
101
+ | 스킬 | 재사용 능력 | 사용 생애주기: 건강 점수·정리·개선 신호 |
102
+ | MCP | 외부 컨텍스트·도구 | 로컬, 승인 게이트 워크플로 메모리 |
163
103
 
164
- `CODEX_HOME`을 지정하지 않으면 Windows에서는 `%USERPROFILE%\.codex`, macOS/Linux에서는 `~/.codex`에 Codex skill이 설치됩니다.
104
+ Tink는 이들을 대체하지 않고 함께 동작합니다.
165
105
 
166
- ### 고급 옵션
106
+ ---
167
107
 
168
- Interactive install/update 중에는 **고급 옵션** 단계가 나옵니다. 예전에는 CLI flag를 직접 알아야 했지만, 이제는 선택 화면에서 볼 수 있습니다.
108
+ ## 하네스 건강 대시보드
169
109
 
170
- - `Preview only (--dry-run)`: 실제 파일을 바꾸기 전에 Tink가 무엇을 쓰고, 보존하고, 지울 예정인지 먼저 보고 싶을 때 씁니다. 파일은 변경하지 않습니다.
171
- - `Overwrite user-modified files (--force)`: 설치가 꼬였고 공식 템플릿으로 되돌리고 싶을 때만 씁니다. 일반 업데이트는 사용자가 고친 파일을 보존합니다.
172
- - `Clean Codex picker (--clean-codex-picker)`: 이 repo에서 Codex만 쓸 때, Codex picker에 `Source Command Tink ...` 중복 항목이 보여서 헷갈리면 씁니다. Claude Code와 Codex를 둘 다 쓰는 설치에서는 이 옵션을 보여주지 않습니다.
110
+ 번의 run 쌓이면, 명령 하나로 기록을 로컬 대시보드로 만들어 브라우저까지 열어 줍니다:
173
111
 
174
- 패키지는 이미 `tink-harness` 실행 파일 이름을 제공합니다. package manager가 이 실행 파일을 `PATH`에 설치한 환경에서는 `tink-harness update`처럼 입력할 수 있습니다. 아직 설치되어 있지 않다면 `npx tink-harness@latest update`를 계속 쓰면 됩니다. macOS와 Windows에서 직접 명령 경로를 확실히 검증한 뒤 README 예시를 더 짧게 바꾸는 작업은 계획 문서에 따로 남겨둡니다.
112
+ ```bash
113
+ npx tink-harness dashboard # 파일만 만들려면 --no-open 추가
114
+ ```
175
115
 
176
- 업데이트가 정상인지 빠르게 확인하려면 `docs/update-verification-recipe.ko.md` 또는 `docs/update-verification-recipe.md`를 확인하세요.
116
+ 하네스와 그들이 쓰는 규칙·메모리, 연결을 보여주는 인터랙티브 3D 지도:
177
117
 
178
- 업데이트 Codex skill, schema, Windows 경고가 이상해 보이면 `docs/update-troubleshooting.ko.md` 또는 `docs/update-troubleshooting.md`를 확인하세요.
118
+ ![Tink 하네스 지도 하네스·규칙·메모리·단계를 보여주는 인터랙티브 3D 뷰](.github/assets/dashboard-map.ko.png)
179
119
 
180
- ## 명령
120
+ 실제 사용량 순으로 정렬된 하네스 카드 — 쉬운 말 건강 요약, 주의 점수, 승인 이력, Claude Code·Codex 양쪽 복사용 다음 행동:
181
121
 
182
- Claude Code에서는 `/tink:*`, Codex에서는 `$tink:*`을 씁니다. 예전 `$tink cast` 형식도 호환되지만, 기본 안내와 자동완성 표면은 `$tink:*`입니다.
122
+ ![사용량 하네스 카드와 쉬운 건강 요약·히스토리](.github/assets/dashboard-harnesses.ko.png)
183
123
 
184
- ### `/tink:cast` / `$tink:cast`
124
+ 서버도, 텔레메트리도, 숨은 캐시도 없습니다 — 제안만 준비하는 정적 로컬 페이지입니다. 재사용되는 변경은 여전히 Tink의 승인 절차를 거칩니다.
185
125
 
186
- 작업을 읽고, 필요한 하네스만 고르고, `.tink/current/` 실행 상태를 만든 뒤 첫 번째 안전한 단계를 시작합니다.
126
+ ---
187
127
 
188
- Tink는 이제 비단순 작업에 대해 `.tink/current/contract.json`도 만듭니다. 이 파일에는 작업 종류, 위험, 성공 조건, 금지 사항, 검증 명령이 들어갑니다.
128
+ ## 만들었나
189
129
 
190
- 크거나 모호한 작업에서는 `cast`가 에이전트의 생각 단계를 파일로 드러내는 하네스를 고를 있습니다. 모호한 아이디어는 `requirements-interview`, 큰 계획은 `plan-consensus`, 긴 실행은 `goal-checkpoint`, 안전한 인수인계는 `delegation-brief`를 씁니다.
130
+ 새로운 AI 코딩 하네스와 워크플로는 계속 늘어납니다. 좋은 것도 많지만, 여러 개를 섞다 보면 환경이 무거워지고 매번 다시 정리해야 합니다.
191
131
 
192
- 특화된 작업에서는 focused harness도 선택할 있습니다. 이슈·PR·QA 정리는 `issue-triage`, 어려운 버그 재현 루프는 `bug-diagnosis-loop`, Standards와 Spec을 나누는 리뷰는 `review-two-axis`, 여러 세션에 걸친 미해결 결정은 `decision-map`, module/interface/seam 구조 개선은 `architecture-deepening`이 담당합니다. 모두 `/tink:cast` 또는 `$tink:cast`가 고르는 재사용 하네스이며, 별도 CLI 명령은 아닙니다.
132
+ Hermes Agent를 쓰면서 기억에 남은 *사용할수록 나아지는 방식*이었습니다. 반복 작업이 재사용 스킬이 되고, 실수가 메모리가 되고, 시스템이 쓰는 사람에 맞게 천천히 바뀌어갔습니다.
193
133
 
194
- ### `/tink:verify` / `$tink:verify`
134
+ Tink는 간단한 질문에서 시작했습니다:
195
135
 
196
- `contract.json`에 적힌 검증을 실제로 실행하고 증거를 남깁니다.
136
+ > Claude Code나 Codex도 같은 방식으로 나와 함께 성장할 수 있을까?
197
137
 
198
- 릴리스, 배포, 공개 PR처럼 "된 같다"가 아니라 "확인했다"가 필요한 작업에서 씁니다.
138
+ 프레임워크가 아니라, 많은 에이전트를 돌리는 아니라 지금 작업에 맞는 하네스를 고르고, 없으면 작은 걸 만들고, 시간이 지나면서 하네스 묶음이 조금씩 나아지도록.
199
139
 
200
- ### `/tink:frog` / `$tink:frog`
140
+ ---
201
141
 
202
- 거의 쓰지 않거나 겹치거나 너무 무거운 하네스를 정리 후보로 제안합니다. 사용자 승인 없이는 삭제하지 않습니다.
142
+ <details>
143
+ <summary><strong>명령 레퍼런스</strong></summary>
203
144
 
204
- ### `/tink:weave` / `$tink:weave`
145
+ Claude Code에서는 `/tink:*`, Codex에서는 `$tink:*`을 씁니다. 예전 `$tink cast` 형식도 호환됩니다.
205
146
 
206
- 실제 실패, 반복 사용, 사용자 수정 내용을 바탕으로 하네스를 조금 더 정확하게 고칩니다. 필요한 경우 `.tink/rules/`의 rule graph나 opt-in hook guard 후보로 승격합니다.
147
+ | 명령 | 하는 |
148
+ |---|---|
149
+ | `/tink:cast` | 작업을 읽고, 하네스를 고르거나 초안을 만들고, `.tink/current/`를 만든 뒤 첫 안전한 단계 시작 |
150
+ | `/tink:deep-cast` | `cast`와 동일하지만 구조화 인터뷰(deep 모드)를 항상 실행 — 기본 `cast_mode` 설정은 변경하지 않음 |
151
+ | `/tink:verify` | `contract.json`에 적힌 검증을 실행하고 증거를 남김 — "된 것 같다"가 아니라 "확인했다" |
152
+ | `/tink:frog` | 거의 쓰지 않거나 겹치거나 너무 무거운 하네스를 정리 후보로 제안 — 승인 없이는 삭제 안 함 |
153
+ | `/tink:weave` | 실제 실패·반복 사용·수정 내용으로 하네스를 조금 더 정확하게 고침 — 승인 후 저장 |
154
+ | `/tink:setup` | 언어, 설치 범위, git 추적, hook 정책 설정 |
155
+ | `/tink:list` | 사용 가능한 하네스와 사용 신호 확인 |
156
+ | `/tink:update` | 설치 출처를 확인하고 안전한 업데이트 안내 |
207
157
 
208
- ### 기타
158
+ **cast 상세:** 더 크거나 모호한 작업에서 `cast`는 생각 단계를 파일로 드러내는 하네스를 고를 수 있습니다. 모호한 아이디어는 `requirements-interview`, 큰 계획은 `plan-consensus`, 긴 실행은 `goal-checkpoint`, 안전한 인수인계는 `delegation-brief`. 특화 하네스(`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`)도 모두 `cast`가 고르는 하네스이며, 별도 명령이 아닙니다.
209
159
 
210
- - `/tink:setup` / `$tink:setup`: 언어, 설치 범위, git 추적, hook 정책 설정
211
- - `/tink:list` / `$tink:list`: 사용 가능한 하네스와 사용 신호 확인
212
- - `/tink:update` / `$tink:update`: 설치 출처를 확인하고 안전한 업데이트 안내
160
+ </details>
213
161
 
214
- ## 작동 방식
162
+ <details>
163
+ <summary><strong>작동 방식</strong></summary>
215
164
 
216
165
  Tink가 아는 모든 것은 직접 읽고, diff 보고, 지울 수 있는 평범한 파일입니다.
217
166
 
@@ -226,11 +175,9 @@ Tink가 아는 모든 것은 직접 읽고, diff 보고, 지울 수 있는 평
226
175
 
227
176
  이 전부를 움직이는 원칙은 세 가지입니다.
228
177
 
229
- 1. **일반 작업에는 하네스가 필요 없습니다.** 평범한 코드 변경·리뷰·문서 작업은 기본 절차(계획 → 단계 → 검증 증거)만으로 진행합니다. 하네스는 특화된 절차가 실제로 결과를 바꿀 때만 로드됩니다 — 출시 안전판, 목표 체크포인트, 계획 비평, 요구사항 인터뷰, 이슈 정리, 어려운 버그 진단 루프, 두 축 리뷰, decision map, architecture deepening, 도메인 워크플로.
230
- 2. **제안만 합니다.** 대시보드·`frog`·`weave`는 실제 사용 신호로 제안을 준비할 뿐입니다. 재사용되는 것(하네스, 메모리, 삭제)은 반드시 별도 명시 승인을 거칩니다. 오늘 실행의 승인이 미래 실행이 물려받을 변경을 허가하지 않습니다.
231
- 3. **느낌이 아니라 증거.** 실행 기록, 실패한 체크, evidence summary card, friction 이벤트가 무엇을 개선하고(`weave`), 초안에서 하네스로 승격하고, 정리할지(`frog`)를 결정합니다. 증거가 약하면 삭제가 아니라 유지·관찰이 기본입니다.
232
-
233
- 대시보드는 이 파일들로 만든 정적 로컬 페이지입니다. harness health summary가 사용량, 실패한 체크, run review 카드, ROI 힌트, weave/frog 후보를 보여줍니다. 서버, 파일 감시, hidden cache, public `tink index` 명령, replay 명령은 없습니다.
178
+ 1. **일반 작업에는 하네스가 필요 없습니다.** 평범한 코드 변경·리뷰·문서 작업은 기본 절차(계획 → 단계 → 검증 증거)만으로 진행합니다. 하네스는 특화된 절차가 실제로 결과를 바꿀 때만 로드됩니다.
179
+ 2. **제안만 합니다.** 대시보드·`frog`·`weave`는 실제 사용 신호로 제안을 준비할 뿐입니다. 재사용되는 것은 반드시 별도 명시 승인을 거칩니다. 오늘 실행의 승인이 미래 실행이 물려받을 변경을 허가하지 않습니다.
180
+ 3. **느낌이 아니라 증거.** 실행 기록, 실패한 체크, evidence summary card, friction 이벤트가 무엇을 개선하고(`weave`), 승격하고, 정리할지(`frog`)를 결정합니다. 증거가 약하면 삭제가 아니라 유지·관찰이 기본입니다.
234
181
 
235
182
  <details>
236
183
  <summary><strong>설계 문서 색인</strong> — 기여자용 세부 내용</summary>
@@ -240,16 +187,52 @@ Tink가 아는 모든 것은 직접 읽고, diff 보고, 지울 수 있는 평
240
187
  - 하네스 건강 요약: `docs/harness-lifecycle-signals.ko.md`, `docs/harness-lifecycle-signals.md`
241
188
  - 외부 context 안전: `docs/mcp-safe-profile.md`, `docs/external-context-policy.md`
242
189
  - `.tink/current/` 상태 읽기: `docs/work-state.ko.md`, `docs/work-state.md`
243
- - GEO 노출도 벤치마크: `docs/geobench.md` · spec: `geobench/tink-harness.yaml`
244
190
  - 업데이트 안정화: `docs/phase-5-update-confidence.ko.md`, `docs/phase-5-update-confidence.md`
245
- - 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`
246
- - 남은 작업 단위: `docs/planned-work-units.ko.md`, `docs/planned-work-units.md` · 로드맵·아이디어 점검: `docs/tink-idea-implementation-plan.ko.md`
191
+ - Context 효율: `docs/context-budget-ledger.ko.md`, `docs/context-budget-ledger.md` `docs/`
192
+ - 남은 작업 단위: `docs/planned-work-units.ko.md`, `docs/planned-work-units.md`
247
193
 
248
194
  </details>
195
+ </details>
196
+
197
+ <details>
198
+ <summary><strong>업데이트</strong></summary>
199
+
200
+ **Claude Code 플러그인:**
201
+
202
+ ```text
203
+ /plugin marketplace update tink-harness
204
+ /plugin update tink@tink-harness
205
+ /reload-plugins
206
+ ```
249
207
 
250
- ## 계획된 작업 단위
208
+ 최신 버전을 찾으면 재설치:
251
209
 
252
- 남은 계획은 번호가 붙은 단계보다 작업 단위 이름으로 관리합니다. 전체 목록은 `docs/planned-work-units.ko.md` 또는 `docs/planned-work-units.md`에 있으며, 세부 문서는 검증 증거 세분화, 외부 컨텍스트 정책, 메모리 결정 계층, 컨텍스트 변화 리뷰, 업데이트 진단으로 나누어 둡니다. 하네스 생애주기 신호는 이제 기본 JSON 요약과 정적 HTML 리포트까지 구현되어 별도 문서에서 관리합니다.
210
+ ```text
211
+ /plugin uninstall tink@tink-harness
212
+ /plugin install tink@tink-harness
213
+ ```
214
+
215
+ **스탠드얼론 (Claude Code 또는 Codex):**
216
+
217
+ ```bash
218
+ npx tink-harness@latest update
219
+ ```
220
+
221
+ 업데이트는 질문 하나 — 어떤 agent surface를 갱신할지 — 만 묻고 나머지는 자동으로 처리합니다. 언어·설치 범위·git 정책은 설치 때 선택한 값을 그대로 재사용하며, `.tink` 커밋 안 함을 선택했다면 업데이트가 `.gitignore`를 절대 건드리지 않습니다. Tink가 관리하는 파일은 항상 최신으로 덮어쓰고, 사용자가 수정한 하네스·메모리·설정과 `.tink/maintenance/`의 모든 기록은 보존합니다.
222
+
223
+ `CODEX_HOME`을 지정하지 않으면 Windows에서는 `%USERPROFILE%\.codex`, macOS/Linux에서는 `~/.codex`에 설치됩니다.
224
+
225
+ **고급 옵션** (대화형 마법사에서 표시):
226
+
227
+ - `Preview only (--dry-run)`: 실제 파일을 바꾸기 전에 무엇을 쓰고·보존하고·지울지 먼저 확인.
228
+ - `Overwrite user-modified files (--force)`: 설치가 꼬였을 때만. 일반 업데이트는 사용자가 고친 파일을 보존합니다.
229
+ - `Clean Codex picker (--clean-codex-picker)`: Codex 전용으로 전환할 때 중복 항목 제거. Claude Code+Codex 혼합 설치에는 표시 안 됨.
230
+
231
+ 검증: `docs/update-verification-recipe.ko.md`. 문제 해결: `docs/update-troubleshooting.ko.md`.
232
+
233
+ </details>
234
+
235
+ ---
253
236
 
254
237
  ## Tink가 아닌 것
255
238
 
@@ -257,7 +240,7 @@ Tink는 코딩 에이전트, 워크플로 엔진, 멀티 에이전트 런타임,
257
240
 
258
241
  ## 기여
259
242
 
260
- 이슈와 PR을 환영합니다. [CONTRIBUTING.md](CONTRIBUTING.md)를 참고하세요 — 핵심은 `npm test` 실행, 명령 템플릿 3벌 동기화, [문제/해결/검증] 구조의 설명입니다.
243
+ 이슈와 PR을 환영합니다. [CONTRIBUTING.md](CONTRIBUTING.md)를 참고하세요 — 핵심은 `npm test` 실행, 명령 템플릿 3벌 동기화, 문제/해결/검증 구조의 설명입니다.
261
244
 
262
245
  Tink가 시간을 아껴줬다면 ⭐ 하나가 다른 개발자들이 Tink를 찾는 데 큰 도움이 됩니다.
263
246