tink-harness 1.2.0 → 1.2.2
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.
- package/.claude-plugin/plugin.json +2 -2
- package/CHANGELOG.md +103 -67
- package/README.ko.md +130 -120
- package/README.md +88 -81
- package/VERSIONING.md +2 -2
- package/bin/install.js +318 -257
- package/commands/cast.md +179 -172
- package/docs/context-change-review.ko.md +14 -0
- package/docs/context-change-review.md +14 -0
- package/docs/external-context-policy.ko.md +15 -0
- package/docs/external-context-policy.md +15 -0
- package/docs/graph-contracts-and-guards.md +61 -0
- package/docs/harness-lifecycle-signals.ko.md +23 -0
- package/docs/harness-lifecycle-signals.md +23 -0
- package/docs/hooks.md +49 -0
- package/docs/memory-decision-layers.ko.md +14 -0
- package/docs/memory-decision-layers.md +14 -0
- package/docs/memory.md +31 -0
- package/docs/phase-5-update-confidence.ko.md +99 -0
- package/docs/phase-5-update-confidence.md +97 -0
- package/docs/planned-work-units.ko.md +77 -0
- package/docs/planned-work-units.md +77 -0
- package/docs/pr/2026-06-07-phase-5-6-follow-up.ko.md +35 -0
- package/docs/pr/2026-06-07-v1.2.0-improvements.html +450 -0
- package/docs/pr/2026-06-07-v1.2.1.md +25 -0
- package/docs/pr/2026-06-08-planned-work-units.ko.md +27 -0
- package/docs/pr/2026-06-08-v1.2.2.ko.md +27 -0
- package/docs/repo-signals.ko.md +104 -0
- package/docs/repo-signals.md +95 -77
- package/docs/research.md +16 -0
- package/docs/tink-idea-implementation-plan.ko.md +201 -0
- package/docs/update-diagnosis.ko.md +16 -0
- package/docs/update-diagnosis.md +16 -0
- package/docs/update-troubleshooting.ko.md +113 -0
- package/docs/update-troubleshooting.md +100 -0
- package/docs/update-verification-recipe.ko.md +118 -0
- package/docs/update-verification-recipe.md +119 -0
- package/docs/verification-evidence-details.ko.md +14 -0
- package/docs/verification-evidence-details.md +14 -0
- package/docs/work-state.ko.md +94 -0
- package/docs/work-state.md +92 -0
- package/package.json +7 -9
- package/templates/claude/commands/tink/cast.md +179 -172
- package/templates/codex/skills/tink-cast/SKILL.md +14 -13
- package/templates/codex/skills/tink-core/RULES.md +163 -112
- package/templates/tink/memory/approved/README.md +5 -0
- package/templates/tink/memory/candidate/README.md +5 -0
- package/templates/tink/memory/evidence/README.md +5 -0
- package/templates/tink/memory/rejected/README.md +5 -0
- package/templates/tink/schemas/harness-lifecycle.schema.json +44 -0
- package/templates/tink/schemas/mcp-policy.schema.json +65 -0
- package/templates/tink/schemas/verification.schema.json +154 -141
|
@@ -0,0 +1,450 @@
|
|
|
1
|
+
<!doctype html>
|
|
2
|
+
<html lang="ko">
|
|
3
|
+
<head>
|
|
4
|
+
<meta charset="utf-8">
|
|
5
|
+
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
6
|
+
<title>Tink v1.2.0 개선 요약</title>
|
|
7
|
+
<style>
|
|
8
|
+
:root {
|
|
9
|
+
color-scheme: light;
|
|
10
|
+
--ink: #172033;
|
|
11
|
+
--muted: #5f6b7a;
|
|
12
|
+
--line: #d7dee8;
|
|
13
|
+
--paper: #f7f9fc;
|
|
14
|
+
--panel: #ffffff;
|
|
15
|
+
--green: #167a46;
|
|
16
|
+
--blue: #235fc6;
|
|
17
|
+
--violet: #6b45b8;
|
|
18
|
+
--amber: #946200;
|
|
19
|
+
--red: #b23333;
|
|
20
|
+
}
|
|
21
|
+
|
|
22
|
+
* {
|
|
23
|
+
box-sizing: border-box;
|
|
24
|
+
}
|
|
25
|
+
|
|
26
|
+
body {
|
|
27
|
+
margin: 0;
|
|
28
|
+
color: var(--ink);
|
|
29
|
+
background: var(--paper);
|
|
30
|
+
font-family: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
|
|
31
|
+
line-height: 1.6;
|
|
32
|
+
}
|
|
33
|
+
|
|
34
|
+
main {
|
|
35
|
+
width: min(1120px, calc(100% - 40px));
|
|
36
|
+
margin: 0 auto;
|
|
37
|
+
padding: 48px 0 72px;
|
|
38
|
+
}
|
|
39
|
+
|
|
40
|
+
header {
|
|
41
|
+
padding: 28px 0 30px;
|
|
42
|
+
border-bottom: 1px solid var(--line);
|
|
43
|
+
}
|
|
44
|
+
|
|
45
|
+
.eyebrow {
|
|
46
|
+
margin: 0 0 10px;
|
|
47
|
+
color: var(--blue);
|
|
48
|
+
font-size: 14px;
|
|
49
|
+
font-weight: 700;
|
|
50
|
+
text-transform: uppercase;
|
|
51
|
+
letter-spacing: 0;
|
|
52
|
+
}
|
|
53
|
+
|
|
54
|
+
h1 {
|
|
55
|
+
margin: 0;
|
|
56
|
+
max-width: 860px;
|
|
57
|
+
font-size: clamp(34px, 6vw, 64px);
|
|
58
|
+
line-height: 1.05;
|
|
59
|
+
letter-spacing: 0;
|
|
60
|
+
}
|
|
61
|
+
|
|
62
|
+
.lead {
|
|
63
|
+
max-width: 800px;
|
|
64
|
+
margin: 18px 0 0;
|
|
65
|
+
color: var(--muted);
|
|
66
|
+
font-size: 19px;
|
|
67
|
+
}
|
|
68
|
+
|
|
69
|
+
.meta {
|
|
70
|
+
display: flex;
|
|
71
|
+
flex-wrap: wrap;
|
|
72
|
+
gap: 10px;
|
|
73
|
+
margin-top: 22px;
|
|
74
|
+
}
|
|
75
|
+
|
|
76
|
+
.pill {
|
|
77
|
+
display: inline-flex;
|
|
78
|
+
align-items: center;
|
|
79
|
+
min-height: 34px;
|
|
80
|
+
padding: 6px 11px;
|
|
81
|
+
border: 1px solid var(--line);
|
|
82
|
+
border-radius: 6px;
|
|
83
|
+
background: var(--panel);
|
|
84
|
+
color: var(--muted);
|
|
85
|
+
font-size: 14px;
|
|
86
|
+
font-weight: 650;
|
|
87
|
+
}
|
|
88
|
+
|
|
89
|
+
section {
|
|
90
|
+
margin-top: 42px;
|
|
91
|
+
}
|
|
92
|
+
|
|
93
|
+
h2 {
|
|
94
|
+
margin: 0 0 14px;
|
|
95
|
+
font-size: 26px;
|
|
96
|
+
letter-spacing: 0;
|
|
97
|
+
}
|
|
98
|
+
|
|
99
|
+
h3 {
|
|
100
|
+
margin: 0 0 8px;
|
|
101
|
+
font-size: 18px;
|
|
102
|
+
letter-spacing: 0;
|
|
103
|
+
}
|
|
104
|
+
|
|
105
|
+
p {
|
|
106
|
+
margin: 0;
|
|
107
|
+
}
|
|
108
|
+
|
|
109
|
+
.grid {
|
|
110
|
+
display: grid;
|
|
111
|
+
gap: 16px;
|
|
112
|
+
}
|
|
113
|
+
|
|
114
|
+
.grid.two {
|
|
115
|
+
grid-template-columns: repeat(2, minmax(0, 1fr));
|
|
116
|
+
}
|
|
117
|
+
|
|
118
|
+
.grid.three {
|
|
119
|
+
grid-template-columns: repeat(3, minmax(0, 1fr));
|
|
120
|
+
}
|
|
121
|
+
|
|
122
|
+
.card {
|
|
123
|
+
min-height: 100%;
|
|
124
|
+
padding: 20px;
|
|
125
|
+
border: 1px solid var(--line);
|
|
126
|
+
border-radius: 8px;
|
|
127
|
+
background: var(--panel);
|
|
128
|
+
}
|
|
129
|
+
|
|
130
|
+
.card p {
|
|
131
|
+
color: var(--muted);
|
|
132
|
+
}
|
|
133
|
+
|
|
134
|
+
.tag {
|
|
135
|
+
display: inline-block;
|
|
136
|
+
margin-bottom: 12px;
|
|
137
|
+
padding: 4px 8px;
|
|
138
|
+
border-radius: 5px;
|
|
139
|
+
background: #edf3ff;
|
|
140
|
+
color: var(--blue);
|
|
141
|
+
font-size: 13px;
|
|
142
|
+
font-weight: 700;
|
|
143
|
+
}
|
|
144
|
+
|
|
145
|
+
.tag.green {
|
|
146
|
+
background: #e9f7ef;
|
|
147
|
+
color: var(--green);
|
|
148
|
+
}
|
|
149
|
+
|
|
150
|
+
.tag.violet {
|
|
151
|
+
background: #f0ebff;
|
|
152
|
+
color: var(--violet);
|
|
153
|
+
}
|
|
154
|
+
|
|
155
|
+
.tag.amber {
|
|
156
|
+
background: #fff4d8;
|
|
157
|
+
color: var(--amber);
|
|
158
|
+
}
|
|
159
|
+
|
|
160
|
+
.tag.red {
|
|
161
|
+
background: #ffecec;
|
|
162
|
+
color: var(--red);
|
|
163
|
+
}
|
|
164
|
+
|
|
165
|
+
.compare {
|
|
166
|
+
display: grid;
|
|
167
|
+
grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
|
|
168
|
+
gap: 16px;
|
|
169
|
+
}
|
|
170
|
+
|
|
171
|
+
.before,
|
|
172
|
+
.after {
|
|
173
|
+
padding: 20px;
|
|
174
|
+
border-radius: 8px;
|
|
175
|
+
border: 1px solid var(--line);
|
|
176
|
+
background: var(--panel);
|
|
177
|
+
}
|
|
178
|
+
|
|
179
|
+
.before {
|
|
180
|
+
border-top: 5px solid var(--red);
|
|
181
|
+
}
|
|
182
|
+
|
|
183
|
+
.after {
|
|
184
|
+
border-top: 5px solid var(--green);
|
|
185
|
+
}
|
|
186
|
+
|
|
187
|
+
ul {
|
|
188
|
+
margin: 10px 0 0;
|
|
189
|
+
padding-left: 20px;
|
|
190
|
+
color: var(--muted);
|
|
191
|
+
}
|
|
192
|
+
|
|
193
|
+
li + li {
|
|
194
|
+
margin-top: 7px;
|
|
195
|
+
}
|
|
196
|
+
|
|
197
|
+
code {
|
|
198
|
+
padding: 2px 5px;
|
|
199
|
+
border-radius: 4px;
|
|
200
|
+
background: #eef2f7;
|
|
201
|
+
color: #223049;
|
|
202
|
+
font-family: ui-monospace, "SFMono-Regular", Consolas, monospace;
|
|
203
|
+
font-size: 0.95em;
|
|
204
|
+
}
|
|
205
|
+
|
|
206
|
+
.timeline {
|
|
207
|
+
display: grid;
|
|
208
|
+
gap: 14px;
|
|
209
|
+
}
|
|
210
|
+
|
|
211
|
+
.step {
|
|
212
|
+
display: grid;
|
|
213
|
+
grid-template-columns: 112px minmax(0, 1fr);
|
|
214
|
+
gap: 16px;
|
|
215
|
+
padding: 18px;
|
|
216
|
+
border: 1px solid var(--line);
|
|
217
|
+
border-radius: 8px;
|
|
218
|
+
background: var(--panel);
|
|
219
|
+
}
|
|
220
|
+
|
|
221
|
+
.step strong {
|
|
222
|
+
color: var(--blue);
|
|
223
|
+
}
|
|
224
|
+
|
|
225
|
+
.evidence {
|
|
226
|
+
border-left: 4px solid var(--green);
|
|
227
|
+
}
|
|
228
|
+
|
|
229
|
+
.note {
|
|
230
|
+
margin-top: 18px;
|
|
231
|
+
padding: 16px 18px;
|
|
232
|
+
border: 1px solid var(--line);
|
|
233
|
+
border-radius: 8px;
|
|
234
|
+
background: #fbfcff;
|
|
235
|
+
color: var(--muted);
|
|
236
|
+
}
|
|
237
|
+
|
|
238
|
+
footer {
|
|
239
|
+
margin-top: 46px;
|
|
240
|
+
padding-top: 22px;
|
|
241
|
+
border-top: 1px solid var(--line);
|
|
242
|
+
color: var(--muted);
|
|
243
|
+
font-size: 14px;
|
|
244
|
+
}
|
|
245
|
+
|
|
246
|
+
@media (max-width: 800px) {
|
|
247
|
+
main {
|
|
248
|
+
width: min(100% - 28px, 1120px);
|
|
249
|
+
padding-top: 28px;
|
|
250
|
+
}
|
|
251
|
+
|
|
252
|
+
.grid.two,
|
|
253
|
+
.grid.three,
|
|
254
|
+
.compare {
|
|
255
|
+
grid-template-columns: 1fr;
|
|
256
|
+
}
|
|
257
|
+
|
|
258
|
+
.step {
|
|
259
|
+
grid-template-columns: 1fr;
|
|
260
|
+
}
|
|
261
|
+
}
|
|
262
|
+
</style>
|
|
263
|
+
</head>
|
|
264
|
+
<body>
|
|
265
|
+
<main>
|
|
266
|
+
<header>
|
|
267
|
+
<p class="eyebrow">Tink release note</p>
|
|
268
|
+
<h1>v1.2.0은 Tink를 “실행 전 선택”에서 “근거가 남는 실행”으로 끌어올린 패치입니다.</h1>
|
|
269
|
+
<p class="lead">
|
|
270
|
+
이번 작업의 핵심은 Claude Code와 Codex를 같은 기준으로 지원하면서, 큰 작업을 시작할 때
|
|
271
|
+
어떤 context를 쓰고 뺐는지, 무엇으로 검증했는지, 외부 정보를 얼마나 신뢰할 수 있는지 남기는 것입니다.
|
|
272
|
+
</p>
|
|
273
|
+
<div class="meta" aria-label="release metadata">
|
|
274
|
+
<span class="pill">npm feature release: v1.2.0</span>
|
|
275
|
+
<span class="pill">latest display patch: v1.2.1</span>
|
|
276
|
+
<span class="pill">verified: npm test 31 tests</span>
|
|
277
|
+
<span class="pill">surfaces: Claude Code + Codex</span>
|
|
278
|
+
<span class="pill">platforms: macOS + Windows</span>
|
|
279
|
+
</div>
|
|
280
|
+
</header>
|
|
281
|
+
|
|
282
|
+
<section>
|
|
283
|
+
<h2>한눈에 보기</h2>
|
|
284
|
+
<div class="compare">
|
|
285
|
+
<div class="before">
|
|
286
|
+
<span class="tag red">Before</span>
|
|
287
|
+
<h3>작업은 진행됐지만 근거가 흩어졌습니다.</h3>
|
|
288
|
+
<ul>
|
|
289
|
+
<li>Codex 스킬 목록에 넓은 <code>tink</code> 스킬이 보여서 action이 흐릿했습니다.</li>
|
|
290
|
+
<li>큰 작업에서 어떤 파일과 외부 정보를 기준으로 삼았는지 추적하기 어려웠습니다.</li>
|
|
291
|
+
<li>검증 결과가 pass/fail/blocked/skipped로 구조화되어 있지 않았습니다.</li>
|
|
292
|
+
<li>Figma, GitHub, docs 같은 외부 context를 안전하게 다루는 기준이 부족했습니다.</li>
|
|
293
|
+
</ul>
|
|
294
|
+
</div>
|
|
295
|
+
<div class="after">
|
|
296
|
+
<span class="tag green">After</span>
|
|
297
|
+
<h3>이제 선택, 실행, 검증의 흔적이 남습니다.</h3>
|
|
298
|
+
<ul>
|
|
299
|
+
<li>Codex는 <code>$tink:cast</code>, <code>$tink:verify</code> 같은 action skill 중심으로 정리됐습니다.</li>
|
|
300
|
+
<li><code>context-pack.md</code>, <code>context-map.json</code>, <code>excluded-context.md</code>로 context 근거를 남깁니다.</li>
|
|
301
|
+
<li><code>verification.json</code>이 검증 evidence를 구조화합니다.</li>
|
|
302
|
+
<li>MCP Safe Profile이 외부 context의 source, confidence, sensitivity, verification hint를 기록합니다.</li>
|
|
303
|
+
</ul>
|
|
304
|
+
</div>
|
|
305
|
+
</div>
|
|
306
|
+
</section>
|
|
307
|
+
|
|
308
|
+
<section>
|
|
309
|
+
<h2>개선된 점</h2>
|
|
310
|
+
<div class="grid three">
|
|
311
|
+
<article class="card">
|
|
312
|
+
<span class="tag">Codex surface</span>
|
|
313
|
+
<h3>스킬 목록이 action 중심으로 정리됨</h3>
|
|
314
|
+
<p>
|
|
315
|
+
넓은 <code>tink</code> 스킬을 없애고, 사용자가 바로 고를 수 있는
|
|
316
|
+
<code>$tink:cast</code>, <code>$tink:verify</code>, <code>$tink:list</code> 같은 alias를 전면에 둡니다.
|
|
317
|
+
공유 규칙은 보이지 않는 <code>tink-core/RULES.md</code>로 이동했습니다.
|
|
318
|
+
</p>
|
|
319
|
+
</article>
|
|
320
|
+
<article class="card">
|
|
321
|
+
<span class="tag green">Context artifacts</span>
|
|
322
|
+
<h3>작업 context가 눈에 보이게 됨</h3>
|
|
323
|
+
<p>
|
|
324
|
+
<code>context-pack.md</code>는 사람이 읽는 요약, <code>context-map.json</code>은 기계가 읽는 근거,
|
|
325
|
+
<code>excluded-context.md</code>는 의도적으로 뺀 것을 기록합니다.
|
|
326
|
+
</p>
|
|
327
|
+
</article>
|
|
328
|
+
<article class="card">
|
|
329
|
+
<span class="tag violet">Repo Signals</span>
|
|
330
|
+
<h3>새 명령 없이 관련 검증을 고름</h3>
|
|
331
|
+
<p>
|
|
332
|
+
새 <code>tink index</code> 명령을 만들지 않고, fixture 기반 repo signal로 테스트, 스키마,
|
|
333
|
+
동기화 파일, verification hint를 선택하는 근거를 남깁니다.
|
|
334
|
+
</p>
|
|
335
|
+
</article>
|
|
336
|
+
<article class="card">
|
|
337
|
+
<span class="tag amber">Verify Runner</span>
|
|
338
|
+
<h3>검증 결과가 구조화됨</h3>
|
|
339
|
+
<p>
|
|
340
|
+
<code>.tink/current/verification.json</code>이 pass, fail, blocked, skipped를 구분하고,
|
|
341
|
+
final report, notes summary, maintenance signal 흐름까지 테스트 fixture로 고정합니다.
|
|
342
|
+
</p>
|
|
343
|
+
</article>
|
|
344
|
+
<article class="card">
|
|
345
|
+
<span class="tag">MCP Safe Profile</span>
|
|
346
|
+
<h3>외부 context를 안전하게 다룸</h3>
|
|
347
|
+
<p>
|
|
348
|
+
Figma, GitHub, official docs, dashboards, attachments 같은 외부 source를 source_ref, confidence,
|
|
349
|
+
sensitivity, verification_hint와 함께 기록합니다. Sentry는 이번 active source set에서 제외했습니다.
|
|
350
|
+
</p>
|
|
351
|
+
</article>
|
|
352
|
+
<article class="card">
|
|
353
|
+
<span class="tag green">Compatibility</span>
|
|
354
|
+
<h3>Claude Code + Codex, macOS + Windows 기준</h3>
|
|
355
|
+
<p>
|
|
356
|
+
새 작업은 두 agent surface와 두 OS 계열을 함께 고려해야 한다는 compatibility policy를 문서화했습니다.
|
|
357
|
+
명령도 <code>npm</code>, <code>node</code>, <code>python</code> 중심의 portable check를 선호합니다.
|
|
358
|
+
</p>
|
|
359
|
+
</article>
|
|
360
|
+
</div>
|
|
361
|
+
</section>
|
|
362
|
+
|
|
363
|
+
<section>
|
|
364
|
+
<h2>사용할 때 무엇이 좋아지나</h2>
|
|
365
|
+
<div class="grid two">
|
|
366
|
+
<article class="card">
|
|
367
|
+
<h3>큰 작업을 시작할 때</h3>
|
|
368
|
+
<p>
|
|
369
|
+
Tink가 어떤 파일, 스키마, 문서, 외부 source를 기준으로 삼았는지 먼저 남기므로,
|
|
370
|
+
중간에 방향이 흔들려도 “처음에 무엇을 믿고 시작했는지” 되짚을 수 있습니다.
|
|
371
|
+
</p>
|
|
372
|
+
</article>
|
|
373
|
+
<article class="card">
|
|
374
|
+
<h3>릴리스나 PR을 준비할 때</h3>
|
|
375
|
+
<p>
|
|
376
|
+
검증 evidence가 명령 출력 하나에 묻히지 않고, checked items, remaining work, next action으로 남습니다.
|
|
377
|
+
PR 설명에도 문제, 해결, 검증, 참고 흐름을 그대로 옮기기 쉬워졌습니다.
|
|
378
|
+
</p>
|
|
379
|
+
</article>
|
|
380
|
+
</div>
|
|
381
|
+
</section>
|
|
382
|
+
|
|
383
|
+
<section>
|
|
384
|
+
<h2>검증 근거</h2>
|
|
385
|
+
<div class="grid two">
|
|
386
|
+
<article class="card evidence">
|
|
387
|
+
<h3>로컬 소스 검증</h3>
|
|
388
|
+
<ul>
|
|
389
|
+
<li><code>npm test</code> 통과: 31 tests OK</li>
|
|
390
|
+
<li>Claude command 3-copy sync 확인</li>
|
|
391
|
+
<li>Codex visible action skill set 확인</li>
|
|
392
|
+
<li>Sentry가 active external context set에 없음을 테스트로 보증</li>
|
|
393
|
+
</ul>
|
|
394
|
+
</article>
|
|
395
|
+
<article class="card evidence">
|
|
396
|
+
<h3>published package 검증</h3>
|
|
397
|
+
<ul>
|
|
398
|
+
<li><code>tink-harness@1.2.0</code> npm tarball 존재</li>
|
|
399
|
+
<li>v1.2.0 tarball에 핵심 docs, schemas, commands, Codex skills 포함</li>
|
|
400
|
+
<li>legacy <code>templates/codex/skills/tink/SKILL.md</code>는 tarball에 없음</li>
|
|
401
|
+
<li>v1.2.1은 README/GitHub Release 표시 정합성 패치로 분리</li>
|
|
402
|
+
</ul>
|
|
403
|
+
</article>
|
|
404
|
+
</div>
|
|
405
|
+
</section>
|
|
406
|
+
|
|
407
|
+
<section>
|
|
408
|
+
<h2>다음 계획 제안</h2>
|
|
409
|
+
<div class="timeline">
|
|
410
|
+
<div class="step">
|
|
411
|
+
<strong>Slice 1</strong>
|
|
412
|
+
<div>
|
|
413
|
+
<h3>릴리스 후 정리</h3>
|
|
414
|
+
<p>로컬에 남은 <code>.agents/</code>, <code>AGENTS.md</code>, <code>.tink/maintenance/ledger.jsonl</code>을 커밋할지, ignore할지, 로컬 전용으로 둘지 결정합니다.</p>
|
|
415
|
+
</div>
|
|
416
|
+
</div>
|
|
417
|
+
<div class="step">
|
|
418
|
+
<strong>Slice 2</strong>
|
|
419
|
+
<div>
|
|
420
|
+
<h3>업데이트 사용자 시나리오 검증</h3>
|
|
421
|
+
<p>기존 v1.1.x 또는 v1.2.0 설치 사용자가 <code>npx tink-harness@latest update</code>를 실행했을 때 Codex legacy skill cleanup과 새 schemas가 기대대로 들어오는지 smoke test를 추가합니다.</p>
|
|
422
|
+
</div>
|
|
423
|
+
</div>
|
|
424
|
+
<div class="step">
|
|
425
|
+
<strong>Slice 3</strong>
|
|
426
|
+
<div>
|
|
427
|
+
<h3>작업 상태 UX 개선</h3>
|
|
428
|
+
<p><code>.tink/current/verification.json</code>, <code>context-map.json</code>, <code>excluded-context.md</code>를 사람이 더 쉽게 읽도록 짧은 summary command 또는 README guide를 설계합니다. 새 command를 만들지는 않고 기존 <code>list</code>나 docs에서 시작합니다.</p>
|
|
429
|
+
</div>
|
|
430
|
+
</div>
|
|
431
|
+
<div class="step">
|
|
432
|
+
<strong>Slice 4</strong>
|
|
433
|
+
<div>
|
|
434
|
+
<h3>Phase 5 후보: update confidence</h3>
|
|
435
|
+
<p>설치/update/publish 이후 실제 사용자가 가장 먼저 만나는 흐름을 단단하게 만듭니다. 목표는 “설치 후 어떤 명령을 쓰면 되는지, 업데이트로 무엇이 바뀌는지, 문제가 생기면 어디를 보면 되는지”를 줄이는 것입니다.</p>
|
|
436
|
+
</div>
|
|
437
|
+
</div>
|
|
438
|
+
</div>
|
|
439
|
+
<p class="note">
|
|
440
|
+
추천 순서는 Slice 1 → Slice 2입니다. 지금은 릴리스 직후라 기능을 더 늘리기보다, 설치된 사용자가 안전하게 최신 구조로 넘어오는지 확인하는 쪽이 효과가 큽니다.
|
|
441
|
+
</p>
|
|
442
|
+
</section>
|
|
443
|
+
|
|
444
|
+
<footer>
|
|
445
|
+
Source: CHANGELOG.md, docs/pr/2026-06-07-v1.2.0.md, .tink/current/verification.json.
|
|
446
|
+
Generated for Tink v1.2.0 planning discussion.
|
|
447
|
+
</footer>
|
|
448
|
+
</main>
|
|
449
|
+
</body>
|
|
450
|
+
</html>
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# PR draft: v1.2.1 README and GitHub release display
|
|
2
|
+
|
|
3
|
+
## 문제
|
|
4
|
+
|
|
5
|
+
`tink-harness@1.2.0`을 npm에 publish한 뒤 GitHub README 상단과 GitHub Releases 카드도 최신 릴리스를 명확히 보여줘야 한다는 점을 확인했다. README 변경을 GitHub에만 두면 npm tarball과 repository source가 달라질 수 있었다.
|
|
6
|
+
|
|
7
|
+
## 해결
|
|
8
|
+
|
|
9
|
+
- README 상단에 GitHub Release badge를 추가했다.
|
|
10
|
+
- README와 한국어 README에 `Latest release` / `최신 릴리스` 문구를 추가했다.
|
|
11
|
+
- `1.2.1` 패치 버전으로 올려 README 표시 변경까지 npm package와 GitHub source가 같은 버전으로 맞도록 했다.
|
|
12
|
+
|
|
13
|
+
## 검증
|
|
14
|
+
|
|
15
|
+
- `npm test`
|
|
16
|
+
- `git diff --check`
|
|
17
|
+
- `npm pack --dry-run --json`
|
|
18
|
+
- `npm publish --dry-run`
|
|
19
|
+
- `npm publish`
|
|
20
|
+
- `npm view tink-harness version`
|
|
21
|
+
|
|
22
|
+
## 참고
|
|
23
|
+
|
|
24
|
+
- `1.2.0`은 기능 릴리스로 유지한다.
|
|
25
|
+
- `1.2.1`은 GitHub README와 Release 표시를 최신 상태로 맞추기 위한 릴리즈 정합성 패치다.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# 계획된 작업 단위 정리
|
|
2
|
+
|
|
3
|
+
## 문제
|
|
4
|
+
|
|
5
|
+
남은 로드맵이 번호가 붙은 단계 중심으로 설명되어 있어, 실제로 어떤 작업이 생기고 어떤 산출물이 필요한지 한눈에 보기 어려웠다. 또한 검증 증거, 외부 context 정책, 하네스 생애주기, memory 저장 경계 같은 항목은 자동화를 바로 넣기 전에 문서와 스키마로 경계를 먼저 고정할 필요가 있었다.
|
|
6
|
+
|
|
7
|
+
## 해결
|
|
8
|
+
|
|
9
|
+
- 남은 계획을 `docs/planned-work-units.ko.md`와 `docs/planned-work-units.md`에 작업 단위 이름으로 다시 정리했다.
|
|
10
|
+
- 검증 증거를 `evidence_kind`, `evidence_ref`, `observed`로 더 자세히 남길 수 있게 verification schema를 확장했다.
|
|
11
|
+
- 외부 context 정책을 `templates/tink/schemas/mcp-policy.schema.json`과 예시 fixture로 표현했다.
|
|
12
|
+
- 하네스 생애주기 추천을 `templates/tink/schemas/harness-lifecycle.schema.json`과 maintenance fixture로 표현했다.
|
|
13
|
+
- memory를 `approved`, `candidate`, `rejected`, `evidence` decision folder로 나누는 설치 template을 추가했다.
|
|
14
|
+
- 컨텍스트 변화 리뷰와 업데이트 진단은 새 command가 아니라 문서와 fixture로 먼저 고정했다.
|
|
15
|
+
|
|
16
|
+
## 검증
|
|
17
|
+
|
|
18
|
+
- `npm test`
|
|
19
|
+
- `git diff --check`
|
|
20
|
+
- `npm pack --dry-run --json`
|
|
21
|
+
|
|
22
|
+
## 참고
|
|
23
|
+
|
|
24
|
+
- 새 public command는 추가하지 않았다.
|
|
25
|
+
- Sentry는 현재 계획에 포함하지 않았다.
|
|
26
|
+
- release evidence bundling은 계속 제외했다.
|
|
27
|
+
- Claude Code와 Codex, macOS와 Windows 동시 지원을 기준으로 작성했다.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# v1.2.2 릴리스 기록
|
|
2
|
+
|
|
3
|
+
## 문제
|
|
4
|
+
|
|
5
|
+
GitHub main에는 업데이트 신뢰도 보강, Context Graph Lite 산출물, 작업 단위별 계획 문서가 merge되어 있었지만 npm과 GitHub Release의 최신 버전은 아직 `v1.2.1`이었다. Claude Code plugin 사용자도 `.claude-plugin/plugin.json` 버전이 바뀌지 않으면 업데이트를 받기 어렵다.
|
|
6
|
+
|
|
7
|
+
## 해결
|
|
8
|
+
|
|
9
|
+
- `package.json`, `package-lock.json`, `.claude-plugin/plugin.json`을 `1.2.2`로 맞췄다.
|
|
10
|
+
- README와 한국어 README의 최신 릴리스 표시를 `v1.2.2`로 갱신했다.
|
|
11
|
+
- `CHANGELOG.md`의 Unreleased 항목을 `1.2.2` 릴리스 항목으로 정리했다.
|
|
12
|
+
- 이번 릴리스는 npm publish와 GitHub Release를 통해 실제 사용자가 받을 수 있는 상태로 만든다.
|
|
13
|
+
|
|
14
|
+
## 검증
|
|
15
|
+
|
|
16
|
+
- `npm test`
|
|
17
|
+
- `git diff --check`
|
|
18
|
+
- `npm pack --dry-run --json`
|
|
19
|
+
- GitHub Actions CI
|
|
20
|
+
- `npm view tink-harness version`
|
|
21
|
+
- `gh release view v1.2.2`
|
|
22
|
+
|
|
23
|
+
## 참고
|
|
24
|
+
|
|
25
|
+
- 새 public command는 추가하지 않았다.
|
|
26
|
+
- Sentry는 포함하지 않았다.
|
|
27
|
+
- release evidence bundling은 기능으로 추가하지 않고, 이번 릴리스 기록 문서만 남겼다.
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
# Repo Signals
|
|
2
|
+
|
|
3
|
+
Repo signal은 `/tink:cast`와 `$tink:cast`가 관련 context와 검증 힌트를 고를 때 참고하는 작고 정적인 힌트다.
|
|
4
|
+
|
|
5
|
+
이것은 생성된 index가 아니고, cache가 아니며, 새 `tink index` command도 아니다. 현재 단계에서는 fixture로만 관리해서 동작을 리뷰하고 테스트할 수 있게 둔다.
|
|
6
|
+
|
|
7
|
+
Repo signal은 `docs/compatibility-policy.md`의 기본 원칙을 따른다. 새 동작은 Claude Code와 Codex를 모두 고려해야 하며, macOS와 Windows에서 모두 동작해야 한다.
|
|
8
|
+
|
|
9
|
+
## 목적
|
|
10
|
+
|
|
11
|
+
Repo signal은 네 가지 질문에 답한다.
|
|
12
|
+
|
|
13
|
+
1. 어떤 파일이 보통 같이 움직이는가?
|
|
14
|
+
2. 어떤 check가 그 파일들이 일관되게 유지됐음을 증명하는가?
|
|
15
|
+
3. 현재 signal set이 모르는 changed path는 무엇인가?
|
|
16
|
+
4. cast가 먼저 확인해야 할 작은 related context set은 무엇인가?
|
|
17
|
+
|
|
18
|
+
이 덕분에 Tink는 왜 어떤 파일을 `context-map.json`에 포함했는지, 왜 어떤 검증 check를 `contract.json`에 넣었는지, 언제 check를 지어내지 말아야 하는지 설명할 수 있다.
|
|
19
|
+
|
|
20
|
+
## Context Graph Lite
|
|
21
|
+
|
|
22
|
+
Phase 6에서는 static fixture에 `context_graph_lite`를 추가한다. 이것은 changed path를 작은 related context 후보로 연결하는 cast 내부 규칙이다.
|
|
23
|
+
|
|
24
|
+
중요한 경계:
|
|
25
|
+
|
|
26
|
+
- 새 command가 아니다.
|
|
27
|
+
- watch process가 아니다.
|
|
28
|
+
- generated cache가 아니다.
|
|
29
|
+
- runtime indexer가 아니다.
|
|
30
|
+
- `tink index`를 만들거나 요구하지 않는다.
|
|
31
|
+
|
|
32
|
+
각 rule은 다음 필드를 가진다.
|
|
33
|
+
|
|
34
|
+
- `when_paths`: rule을 활성화하는 changed path pattern.
|
|
35
|
+
- `include_paths`: cast가 먼저 고려할 관련 파일.
|
|
36
|
+
- `signal_refs`: 선택 이유를 설명하는 sync group, verification command, verification hint.
|
|
37
|
+
- `reason`: 사람이 읽는 근거.
|
|
38
|
+
- `confidence`: 선택 신뢰도.
|
|
39
|
+
|
|
40
|
+
Context Graph Lite는 넓은 파일 목록보다 작고 신뢰도 높은 context pack을 우선한다. 어떤 rule도 맞지 않으면 관계를 지어내지 않고 `unmatched_path` signal을 남긴다.
|
|
41
|
+
|
|
42
|
+
## 현재 Fixture
|
|
43
|
+
|
|
44
|
+
- `tests/fixtures/repo-signals/tink-harness.json`: sync group, instruction file, schema file, command surface, verification hint, Context Graph Lite rule.
|
|
45
|
+
- `tests/fixtures/repo-signals/path-cases.json`: changed path가 어떤 verification hint와 context graph rule을 선택해야 하는지 보여주는 예시.
|
|
46
|
+
- `tests/fixtures/current-run/context-map.json`: repo signal source를 인용하는 context signal 예시.
|
|
47
|
+
- `tests/fixtures/current-run/contract.json`: 선택된 verification hint가 manual check로 기록된 예시.
|
|
48
|
+
|
|
49
|
+
## 흐름
|
|
50
|
+
|
|
51
|
+
의도한 cast 흐름은 다음과 같다.
|
|
52
|
+
|
|
53
|
+
```text
|
|
54
|
+
changed path
|
|
55
|
+
-> matching context_graph_lite rules
|
|
56
|
+
-> small related context set
|
|
57
|
+
-> matching repo signal verification_hints
|
|
58
|
+
-> contract.verification.manual_checks[]
|
|
59
|
+
-> context-map.json signals
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
예:
|
|
63
|
+
|
|
64
|
+
```text
|
|
65
|
+
commands/cast.md
|
|
66
|
+
-> context_graph_lite.rules.claude-command-sync
|
|
67
|
+
-> matching command copies and tests/test_templates.py
|
|
68
|
+
-> verification_hints.command-template-sync
|
|
69
|
+
-> manual check: test_dual_format_paths_stay_in_sync
|
|
70
|
+
-> context-map signal: verification_hint
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
contract는 무엇을 검증해야 하는지 기록한다. context map은 왜 그 context와 check가 선택됐는지 기록한다.
|
|
74
|
+
|
|
75
|
+
## Unmatched Paths
|
|
76
|
+
|
|
77
|
+
changed path가 어떤 verification hint나 graph rule에도 맞지 않으면 Tink는 check를 지어내지 않는다.
|
|
78
|
+
|
|
79
|
+
대신 `context-map.json`에 `unmatched_path` signal을 남긴다.
|
|
80
|
+
|
|
81
|
+
예:
|
|
82
|
+
|
|
83
|
+
```text
|
|
84
|
+
docs/memory.md
|
|
85
|
+
-> no matching verification hint
|
|
86
|
+
-> no manual check added
|
|
87
|
+
-> context-map signal: unmatched_path
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
이렇게 하면 모르는 context도 보이지만, 가짜 확신을 만들지는 않는다.
|
|
91
|
+
|
|
92
|
+
## 경계
|
|
93
|
+
|
|
94
|
+
Repo signal fixture는 advisory input이다.
|
|
95
|
+
|
|
96
|
+
절대 하면 안 되는 일:
|
|
97
|
+
|
|
98
|
+
- command 실행
|
|
99
|
+
- tool 설치
|
|
100
|
+
- 파일 쓰기
|
|
101
|
+
- 새 command surface 생성
|
|
102
|
+
- runtime indexer처럼 행동
|
|
103
|
+
|
|
104
|
+
나중에 runtime 지원을 추가하더라도 같은 contract를 유지해야 한다. signal은 context와 verification 선택을 설명하고, 실제 check는 기존 verification flow를 통해 실행된다.
|