tink-harness 1.5.0 → 1.6.0

package/.claude-plugin/plugin.json

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

package/CHANGELOG.md

@@ -7,6 +7,16 @@ All notable changes to Tink are tracked here.
 No unreleased changes yet.
 
 
+## [1.6.0] - 2026-06-09
+
+### Added
+
+- Graph-rule seed rules now route common Tink maintenance work to the right supporting files, harnesses, and verification checks without adding a public `tink index` command.
+- `/tink:weave`, `/tink:frog`, and `$tink:*` guidance now treats rule `reason`, `risk`, `include_paths`, and `checks` as reviewable context-engineering evidence.
+- Korean PR history draft for the graph-rule seed rules work in `docs/pr/2026-06-09-graph-rule-seed-rules.ko.md`.
+- Korean PR history draft for the v1.6.0 release in `docs/pr/2026-06-09-v1.6.0.ko.md`.
+
+
 ## [1.5.0] - 2026-06-08
 
 ### Changed

package/README.ko.md

@@ -1,4 +1,4 @@
-<p align="center">
+<p align="center">
   <img src=".github/assets/hero.gif" alt="Tink Hero Banner" width="100%">
 </p>
 
@@ -8,7 +8,7 @@ Claude Code와 Codex를 위한 작은 하네스 레이어입니다.
 
 Tink는 지금 작업에 맞는 하네스를 고르고, 실행 상태를 보이게 만들고, 실제 사용 중 생긴 실패와 피드백으로 하네스 세트를 개선합니다.
 
-**최신 릴리스:** v1.5.0 — Codex-only update에서 Codex skill picker에 `Source Command Tink ...`로 보이던 repo-local Claude Tink surface를 정리합니다.
+**최신 릴리스:** v1.6.0 — graph-rule seed routing으로 반복 작업에서 필요한 관련 파일, 하네스, 검증 체크를 더 잘 고릅니다.
 
 [English](README.md) · **한국어**
 
@@ -59,14 +59,14 @@ npx tink-harness@latest update
 
 업데이트 후 Codex skill, schema, Windows 경고가 이상해 보이면 `docs/update-troubleshooting.ko.md` 또는 `docs/update-troubleshooting.md`를 확인하세요.
 
-## 1.5.0에서 달라진 점
+## 1.6.0에서 달라진 점
 
-이번 릴리스는 기존 repo에서 Codex skill picker가 헷갈리게 보이는 문제를 고쳤습니다.
-
-- Codex-only `tink-harness update`가 repo-local `.claude/commands/tink/*.md`와 예전 repo-local `.claude/skills/tink/SKILL.md` Tink surface를 정리합니다.
-- 그래서 Codex에서 `$tink:*` action skill만 기대하는 상황에 `Source Command Tink Frog/List/...` 또는 넓은 `Tink` 항목이 같이 보이는 일을 줄입니다.
-- 의도적으로 Claude Code와 Codex를 둘 다 설치한 경우에는 repo-local Claude Code command가 남을 수 있고, 이때 `Source Command Tink ...` 항목은 정상일 수 있습니다. 자세한 내용은 `docs/update-troubleshooting.ko.md` 또는 `docs/update-troubleshooting.md`를 확인하세요.
+이번 릴리스는 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에서 같은 하네스 레이어로 쓰기 쉽게 정리합니다.
@@ -122,7 +122,7 @@ Tink는 직접 볼 수 있는 파일을 씁니다.
 
 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`에 정리되어 있고, 외부 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`에 정리되어 있습니다. 외부 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`에 정리되어 있습니다.
 
 중요한 원칙은 승인입니다. 현재 작업을 진행하는 승인과, 미래에도 재사용될 상태를 저장하는 승인은 별개입니다. 새 하네스, 메모리, rule graph, hook guard 저장은 항상 별도 승인이 필요합니다.
 

package/README.md

@@ -17,14 +17,14 @@
 </p>
 
 <p>
-  <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.5.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.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://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 release:</strong> v1.5.0 - Codex-only update now removes repo-local Claude Tink surfaces that appeared as <code>Source Command Tink ...</code>.</p>
+<p><strong>Latest release:</strong> v1.6.0 - Graph-rule seed routing now helps Tink pick supporting files, harnesses, and verification checks for repeated work.</p>
 
 **English** · [한국어](README.ko.md)
 
@@ -124,13 +124,14 @@ 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.5.0
+## What's new in 1.6.0
 
-This release fixes the Codex skill picker state after updating an existing repo.
+This release makes Tink's small rule graph more useful during real work.
 
-- Codex-only `tink-harness update` now removes repo-local `.claude/commands/tink/*.md` and the old repo-local `.claude/skills/tink/SKILL.md` Tink surface.
-- This prevents Codex from showing `Source Command Tink Frog/List/...` or a broad repo-local `Tink` entry when the user expects only `$tink:*` action skills.
-- If you intentionally install both Claude Code and Codex surfaces, repo-local Claude Code commands can remain and `Source Command Tink ...` entries may be expected. See `docs/update-troubleshooting.md` or `docs/update-troubleshooting.ko.md`.
+- 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+
 
@@ -201,7 +202,7 @@ Tink uses files you can inspect:
 
 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`. 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`. 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`.
 
 The important rule is approval.
 

package/VERSIONING.md

@@ -1,6 +1,6 @@
 # Versioning
 
-Current version: `1.5.0`
+Current version: `1.6.0`
 
 Tink follows semver from `1.0.0` onward.
 

package/commands/cast.md

@@ -369,8 +369,12 @@ A task is trivial only when ALL of the following are true:
 2. Read `.tink/rules/index.json` if present. Use it as a small rule graph to choose candidate harnesses, checks, and opt-in guard candidates from contract facts. Do not read every harness.
    - Load `mandatory` nodes first when their `when` facts match the contract.
    - Retrieve `retrievable` nodes only when their `when` facts or `keywords` fit the task.
+   - Treat `select_harnesses`, `include_paths`, `checks`, `reason`, and `risk` as first-class routing data when present.
    - Respect `budget_cost` and `selection_policy.retrieval.max_retrievable_per_phase` when present.
    - Record every loaded rule id in `.tink/current/session.json` under `loaded_rule_ids_by_phase.<phase>`.
+   - Record selected `include_paths` in `context-map.json.included[]` with `role: "supporting"` or `role: "verification_target"` when the rule also adds a check.
+   - Record rule `checks` in `contract.json.verification.manual_checks[]` or `commands[]` only when they are relevant and cheap; otherwise record them in `notes.md` as deferred checks.
+   - Record rule `reason` and `risk` in `context-map.json.signals[]` with `kind: "rule_graph"` so reviewers can see why the context or check was chosen.
    - If a rule id is already listed for the same phase, do not repeat its guidance; cite the existing session entry instead.
 3. Read `.tink/harnesses/index.json`. Use it to validate the candidates from the rule graph and to fall back when no rule node matches.
 4. Read small memory files where `config.json` sets `memory_has_entries.<name>: true`. Skip files set to `false`. After a Save Gate approves a new memory entry, set that file's flag to `true` in `config.json`.

package/commands/frog.md

@@ -26,6 +26,7 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
    - `.tink/runs/` summaries
    - `.tink/maintenance/ledger.jsonl`
    - `.tink/maintenance/weave-queue.json`
+   - `.tink/rules/index.json`
    - references in memory files
    - recent git history touching harness files as weak context only
 2b. Check `.tink/runs/` accumulation against TTL config:
@@ -53,6 +54,14 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
    - merge into another harness
    - delete
    - rewrite via `/tink:weave`
+6b. If `.tink/rules/index.json` exists, also inspect rule quality:
+   - keep: concrete `when`, `reason`, and useful `checks` or `include_paths`
+   - rewrite: too broad, unclear reason, or missing verification
+   - split: one rule mixes unrelated paths, tasks, or risks
+   - merge: multiple rules cover the same `when`, `include_paths`, and `checks`
+   - needs evidence: weak or no run, ledger, friction, or user-correction evidence
+   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`.
 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`:

package/commands/weave.md

@@ -24,42 +24,50 @@ Use Korean field values when `.tink/config.json` language is `ko` or `auto` with
 1. Read `.tink/harnesses/index.json`. If `.tink/maintenance/weave-queue.json` exists, read it to find:
    - Handoff packets from `/tink:frog` (entries where `auto` is absent or false)
    - 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.
+   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.
 2. Identify one or a few active harnesses to improve using real failures and evidence:
    - repeated mistakes
-   - user corrections
-   - failed checks
-   - repeated friction entries
-   - confusing approval prompts
+   - user corrections
+   - failed checks
+   - repeated friction entries
+   - confusing approval prompts
    - too much context footprint
    - missing done criteria
 3. Require concrete evidence handles before proposing a save:
-   - run record path or run ID
-   - current notes path when same-conversation certainty exists
-   - failed check name
-   - friction entry timestamp/type
-   - compact user correction snippet
+   - run record path or run ID
+   - current notes path when same-conversation certainty exists
+   - failed check name
+   - friction entry timestamp/type
+   - compact user correction snippet
    - purge handoff ID from `.tink/maintenance/weave-queue.json`
 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:
-   - harness edit: a procedure, ask-first question, check, or recovery step should change;
-   - rule graph update: a contract fact should select a harness, check, or guard candidate earlier;
-   - opt-in hook guard candidate: the same failure should be blocked by `PreToolUse`, `PostToolUse`, or `Stop` after user approval;
-   - friction logging update: the run should record a missing evidence pattern more clearly.
-7. Read only the target harness files and `.tink/rules/index.json` when the evidence points to rule selection.
-8. Propose small edits:
-   - clearer when-to-use trigger
-   - better ask-first question
-   - tighter checks
-   - smaller context footprint
-   - explicit failure recovery
-   - rule graph node or edge
-   - opt-in guard template
-9. Show an approval payload: destination files, exact patch summary, evidence handles, repeated vs single-run classification, why reusable, context-cost delta, sensitive content excluded, rollback path.
-10. Ask for approval before saving.
-11. Apply surgical changes, update index metadata or `.tink/rules/index.json` if needed, mark the weave queue item status, and append the approval/result to `.tink/maintenance/ledger.jsonl`.
+5. Explain why the change belongs in the harness rather than `.tink/memory/` or `.tink/current/notes.md`.
+6. Decide the right destination:
+   - harness edit: a procedure, ask-first question, check, or recovery step should change;
+   - rule graph update: a contract fact should select a harness, check, or guard candidate earlier;
+   - opt-in hook guard candidate: the same failure should be blocked by `PreToolUse`, `PostToolUse`, or `Stop` after user approval;
+   - friction logging update: the run should record a missing evidence pattern more clearly.
+7. Read only the target harness files and `.tink/rules/index.json` when the evidence points to rule selection.
+   For rule graph updates, run a structural gate before proposing a save:
+   - duplicate: does an existing rule already cover the same `when`, `include_paths`, or `checks`?
+   - breadth: is the rule too broad, such as "always check docs", instead of tied to concrete paths, task facts, or risks?
+   - evidence: does the proposal cite a run, failed check, user correction, or friction entry?
+   - verification: does the rule add a check or explain why no check is needed?
+   - compatibility: does the rule make sense for both Claude Code and Codex, and for macOS and Windows?
+   - portability: does it avoid OS-specific shell syntax unless alternatives are listed?
+8. Propose small edits:
+   - clearer when-to-use trigger
+   - better ask-first question
+   - tighter checks
+   - smaller context footprint
+   - explicit failure recovery
+   - rule graph node or edge
+   - opt-in guard template
+9. Show an approval payload: destination files, exact patch summary, evidence handles, repeated vs single-run classification, why reusable, context-cost delta, sensitive content excluded, rollback path.
+   For rule graph updates, also show structural gate results: duplicate, breadth, evidence, verification, compatibility, and portability.
+10. Ask for approval before saving.
+11. Apply surgical changes, update index metadata or `.tink/rules/index.json` if needed, mark the weave queue item status, and append the approval/result to `.tink/maintenance/ledger.jsonl`.
 
 ## Approval format
 ```text
@@ -72,11 +80,11 @@ Evidence:
 - observed failure: verification command was unclear in two runs
 
 Approval payload:
-- operation: weave
-- destination files: `.tink/harnesses/code-change.md`, `.tink/harnesses/index.json` if metadata changes, `.tink/rules/index.json` if routing changes
-- context-cost delta: neutral or smaller
-- ledger: append op ID to `.tink/maintenance/ledger.jsonl`
-- rollback: revert this patch or rerun `/tink:weave` with the previous trigger
+- operation: weave
+- destination files: `.tink/harnesses/code-change.md`, `.tink/harnesses/index.json` if metadata changes, `.tink/rules/index.json` if routing changes
+- context-cost delta: neutral or smaller
+- ledger: append op ID to `.tink/maintenance/ledger.jsonl`
+- rollback: revert this patch or rerun `/tink:weave` with the previous trigger
 
 Proposed improvement:
 - Checks 섹션에 “검증 명령과 실패 시 마지막 안전 지점 기록” 추가
@@ -89,7 +97,7 @@ Proposed improvement:
 
 ## Do not
 - Do not rewrite a harness from scratch unless the user asks.
-- Do not add broad principles that do not change behavior.
-- Do not save one-off task progress as harness knowledge.
-- Do not propose a harness edit without evidence handles.
-- Do not register enforcement hooks by default. Save guard templates as opt-in candidates unless the user explicitly approves installation.
+- Do not add broad principles that do not change behavior.
+- Do not save one-off task progress as harness knowledge.
+- Do not propose a harness edit without evidence handles.
+- Do not register enforcement hooks by default. Save guard templates as opt-in candidates unless the user explicitly approves installation.

package/docs/graph-rule-adoption-plan.ko.md

@@ -0,0 +1,215 @@
+# Graph 규칙 적용 계획
+
+이 문서는 Writ의 graph 기반 context 선택 아이디어를 Tink에 맞게 가볍게 적용하는 계획이다.
+
+목표는 Neo4j, FastAPI, vector DB, watcher, generated cache를 도입하는 것이 아니다. Tink의 장점인 작은 파일 기반 구조를 유지하면서, 작업에 맞는 하네스와 검증을 더 안정적으로 고르는 작은 규칙 지도를 만드는 것이다.
+
+## 왜 필요한가
+
+Tink는 현재 작업을 보고 `research`, `docs`, `code-change`, `ship` 같은 하네스를 고른다. 이 선택이 맞으면 context가 작고 검증도 선명하다. 하지만 작업이 애매하면 다음 문제가 생길 수 있다.
+
+- 릴리스 작업인데 `docs`만 골라서 `npm pack`이나 changelog 확인을 놓친다.
+- 작은 문서 수정인데 `ship`까지 골라 작업이 과해진다.
+- README를 고치면서 한국어 companion 문서를 빼먹는다.
+- version bump를 하면서 `.claude-plugin/plugin.json`을 놓친다.
+
+Graph 규칙은 이런 실수를 줄이기 위한 작은 연결 규칙이다.
+
+```text
+작업 사실
+  -> 필요한 하네스
+  -> 같이 봐야 하는 파일
+  -> 반드시 확인할 검증
+  -> 적용 이유
+```
+
+## 원칙
+
+1. **파일 기반으로 유지한다.**
+   `.tink/rules/index.json` 같은 작은 JSON을 사용한다.
+
+2. **사람 승인 없이 규칙을 저장하지 않는다.**
+   AI는 후보를 제안하고, 사람은 승인한다.
+
+3. **항상 필요한 규칙과 필요할 때만 가져오는 규칙을 나눈다.**
+   예: 비밀키 노출 금지는 항상 중요하지만, npm publish 검증은 release 작업에서만 필요하다.
+
+4. **규칙은 작고 구체적이어야 한다.**
+   “문서를 잘 확인한다”보다 “README.md를 수정하면 README.ko.md도 확인한다”가 좋다.
+
+5. **왜 선택됐는지 run artifact에 남긴다.**
+   선택된 규칙은 `.tink/current/session.json`, `context-map.json`, `verification.json`에서 추적 가능해야 한다.
+
+## 좋은 규칙의 모양
+
+좋은 규칙은 네 가지를 가진다.
+
+- 언제 적용되는가
+- 무엇을 context로 가져오는가
+- 무엇을 검증하는가
+- 왜 필요한가
+
+예시:
+
+```json
+{
+  "id": "readme-bilingual-sync",
+  "when": {
+    "changed_paths": ["README.md"]
+  },
+  "include_paths": ["README.ko.md"],
+  "checks": ["README language pair stays aligned"],
+  "reason": "README has a Korean companion document."
+}
+```
+
+## 작업 단위
+
+## 현재 구현 상태
+
+- 1차 구현: `templates/tink/rules/index.json`에 `node_shape`와 안전 seed rule을 추가했다.
+- 1차 구현: `$tink:cast` / `/tink:cast`가 `select_harnesses`, `include_paths`, `checks`, `reason`, `risk`를 기록 대상으로 다루도록 지침을 보강했다.
+- 1차 구현: `$tink:weave` / `/tink:weave`가 reusable rule graph update를 제안하기 전에 structural gate를 확인하도록 했다.
+- 1차 구현: `$tink:frog` / `/tink:frog`가 harness뿐 아니라 rule quality도 `keep`, `rewrite`, `split`, `merge`, `needs evidence`로 점검할 수 있게 했다.
+- 남은 구현: 실제 cast 실행 산출물 fixture에서 seed rule 선택 결과를 더 풍부하게 보여주는 예제를 늘릴 수 있다.
+- 남은 구현: 충분한 run 기록이 쌓인 뒤 rule 사용 빈도와 실패 신호 기반 정리 제안을 더 정량화할 수 있다.
+
+### 1. 규칙 schema 정리
+
+`templates/tink/rules/index.json`의 노드 형식을 더 명확히 한다.
+
+추가하면 좋은 필드:
+
+- `when`: 적용 조건
+- `select_harnesses`: 선택할 하네스
+- `include_paths`: 같이 볼 파일
+- `checks`: 추가할 검증
+- `reason`: 선택 이유
+- `load`: `mandatory` 또는 `retrievable`
+- `risk`: 잘못 적용됐을 때의 위험
+
+완료 기준:
+
+- Claude Code와 Codex 둘 다 같은 JSON을 읽을 수 있다.
+- macOS와 Windows 테스트에서 통과한다.
+- public `tink index` 명령, watcher, generated cache를 만들지 않는다.
+
+### 2. 첫 번째 안전 규칙 세트 추가
+
+처음에는 자주 실수할 수 있고 근거가 뚜렷한 규칙만 넣는다.
+
+후보:
+
+- `README.md` 변경 시 `README.ko.md` 확인
+- `package.json` version 변경 시 `package-lock.json`, `.claude-plugin/plugin.json`, `CHANGELOG.md`, `VERSIONING.md` 확인
+- `commands/*.md` 변경 시 3-copy sync 확인
+- `bin/install.js` 변경 시 install/update smoke 경로 확인
+- release/publish 작업 시 `npm test`, `git diff --check`, `npm pack --dry-run --json` 확인
+- Codex-only update 작업 시 repo-local `.claude/commands/tink/*.md`와 `.claude/skills/tink/SKILL.md` 정리 여부 확인
+
+완료 기준:
+
+- 각 규칙은 적용 조건과 검증 이유를 가진다.
+- 너무 넓은 규칙은 넣지 않는다.
+- 테스트 fixture로 선택 결과를 확인한다.
+
+### 3. `$tink:cast` 선택 기록 강화
+
+`$tink:cast`가 규칙을 적용했을 때 다음을 남긴다.
+
+- 어떤 rule id가 적용됐는지
+- 어떤 하네스가 선택됐는지
+- 어떤 파일이 context 후보가 됐는지
+- 어떤 검증이 추가됐는지
+- 어떤 후보를 제외했는지
+
+기록 위치:
+
+- `.tink/current/session.json`
+- `.tink/current/context-map.json`
+- `.tink/current/excluded-context.md`
+
+완료 기준:
+
+- 사람이 “왜 이 파일을 봤는지” 다시 추리하지 않아도 된다.
+- 불필요 context와 제외 context가 분리된다.
+
+### 4. reusable 규칙 제안 gate 추가
+
+`$tink:weave`가 새 rule을 저장하기 전에 다음을 확인한다.
+
+- 기존 규칙과 중복되는가
+- 너무 넓은가
+- 실제 evidence가 있는가
+- 검증 가능한가
+- Claude Code와 Codex 모두에서 의미가 있는가
+- macOS와 Windows에 묶인 명령은 아닌가
+
+완료 기준:
+
+- AI는 rule 후보를 제안할 수 있다.
+- 저장은 별도 승인 후에만 가능하다.
+- 거절된 후보는 반복 제안을 줄이기 위해 이유를 남길 수 있다.
+
+### 5. frog/weave 점검 루프 연결
+
+`$tink:frog`와 `$tink:weave`가 규칙 품질도 점검하게 한다.
+
+점검 대상:
+
+- 자주 적용됐지만 검증 도움이 없던 규칙
+- 자주 제외된 규칙
+- 너무 많은 context를 끌고 오는 규칙
+- 실패를 반복해서 놓친 규칙
+
+완료 기준:
+
+- 삭제보다 먼저 `keep`, `rewrite`, `split`, `merge`, `needs evidence`로 분류한다.
+- 강한 근거 없이 규칙을 삭제하지 않는다.
+
+## 나쁜 시나리오와 방어
+
+| 나쁜 시나리오 | 결과 | 방어 |
+| --- | --- | --- |
+| 너무 넓은 규칙 | context가 커짐 | `risk`, `cost`, `reason` 필수화 |
+| 필요한 규칙 누락 | 검증 빠짐 | 자주 실패한 check를 weave 후보로 기록 |
+| docs 작업에 release 규칙 적용 | 작업이 과해짐 | `when` 조건을 path와 task_type으로 좁힘 |
+| AI가 rule을 자동 저장 | 사용자의 작업 방식 침범 | reusable save 별도 승인 유지 |
+| OS 전용 명령이 rule에 고정 | Windows/macOS 한쪽 실패 | portable command 또는 플랫폼별 대안 요구 |
+
+## 권장 순서
+
+1. `templates/tink/rules/index.json` schema를 정리한다.
+2. README, version, command sync, release 같은 안전 규칙 5-6개만 넣는다.
+3. fixture 테스트로 규칙 선택 결과를 확인한다.
+4. `$tink:cast`가 적용 rule id를 current artifact에 남기게 한다.
+5. `$tink:weave`에 reusable rule proposal gate를 붙인다.
+6. 충분한 run 기록이 쌓인 뒤 `$tink:frog`에서 rule 정리 후보를 제안한다.
+
+## 지금 당장 만들지 않을 것
+
+- public `tink index` 명령
+- runtime watcher
+- generated graph cache
+- Neo4j, FastAPI, vector DB
+- Sentry integration
+- release evidence bundling
+- 사용자 승인 없는 rule 자동 저장
+
+## 첫 PR 제안
+
+첫 PR은 “Graph Rule Schema and Seed Rules”가 좋다.
+
+범위:
+
+- `templates/tink/rules/index.json`에 필드 의미를 명확히 반영한다.
+- README/version/command sync/release 관련 seed rule을 추가한다.
+- fixture와 테스트를 추가해 선택 결과를 확인한다.
+- 문서에 “이것은 public index가 아니라 작은 rule graph”라고 명시한다.
+
+완료 확인:
+
+- `npm test`
+- `git diff --check`
+- `npm pack --dry-run --json`
+- Claude Code와 Codex 설명 문구가 같은 방향을 가리키는지 수동 확인

package/docs/pr/2026-06-09-graph-rule-adoption-plan.ko.md

@@ -0,0 +1,26 @@
+# Graph 규칙 적용 계획
+
+## 문제
+
+Writ의 graph 기반 context 선택 아이디어를 Tink에 적용할 수 있을지 검토했음. 다만 Writ의 Neo4j, FastAPI, vector DB, watcher 같은 구조를 그대로 가져오면 Tink의 장점인 가벼운 파일 기반 흐름이 무거워질 수 있었음.
+
+또한 하네스를 잘못 고르면 릴리스 검증 누락, 과한 절차, companion 문서 누락, version metadata drift 같은 문제가 생길 수 있으므로, 작은 graph 규칙이 어떤 방식으로 안전하게 도움을 줄 수 있는지 먼저 계획으로 정리할 필요가 있었음.
+
+## 해결
+
+- `docs/graph-rule-adoption-plan.ko.md`를 추가해 Tink식 graph 규칙 적용 방향을 정리했음.
+- public `tink index`, watcher, generated cache, Neo4j/FastAPI/vector DB를 만들지 않는다는 경계를 명확히 했음.
+- `when`, `include_paths`, `checks`, `reason`, `load`, `risk` 중심의 작은 JSON rule graph 방향을 제안했음.
+- README와 한국어 README에서 새 계획 문서로 연결되도록 링크를 추가했음.
+
+## 검증
+
+- `npm test`
+- `git diff --check`
+- `npm pack --dry-run --json`
+
+## 참고
+
+- 구현은 포함하지 않았음.
+- publish와 release는 포함하지 않았음.
+- 새 하네스는 만들지 않았음. 기존 `research`, `docs`, `harness-curation` 관점으로 충분하다고 판단했음.

package/docs/pr/2026-06-09-graph-rule-seed-rules.ko.md

@@ -0,0 +1,27 @@
+# Graph rule seed rules 구현
+
+## 문제
+
+Graph 규칙 적용 계획은 문서화됐지만, 실제 설치 템플릿의 `.tink/rules/index.json`에는 README 동기화, version metadata 동기화, command 3-copy sync, installer smoke 같은 안전 규칙이 아직 들어가 있지 않았음.
+
+또한 `cast`, `weave`, `frog`가 새 rule 필드와 rule 품질 점검을 어떻게 다뤄야 하는지 지침이 충분히 구체적이지 않았음.
+
+## 해결
+
+- `templates/tink/rules/index.json`에 `node_shape`와 안전 seed rule을 추가했음.
+- `$tink:cast` / `/tink:cast`가 `select_harnesses`, `include_paths`, `checks`, `reason`, `risk`를 기록 대상으로 다루도록 보강했음.
+- `$tink:weave` / `/tink:weave`에 reusable rule graph update structural gate를 추가했음.
+- `$tink:frog` / `/tink:frog`가 rule quality를 `keep`, `rewrite`, `split`, `merge`, `needs evidence`로 점검하도록 보강했음.
+- Claude Code와 Codex surface가 같은 방향을 보도록 root command, Claude template command, repo-local command, Claude skill, Codex core rule을 함께 갱신했음.
+
+## 검증
+
+- `npm test`
+- `git diff --check`
+- `npm pack --dry-run --json`
+
+## 참고
+
+- public `tink index` 명령, watcher, generated cache, Neo4j/FastAPI/vector DB는 추가하지 않았음.
+- Sentry와 release evidence bundling은 포함하지 않았음.
+- 이 변경은 설치 템플릿과 명령 지침이 바뀌므로 배포가 필요함.

package/docs/pr/2026-06-09-v1.6.0.ko.md

@@ -0,0 +1,27 @@
+# v1.6.0 릴리스 이력 초안
+
+## 문제
+
+- graph-rule seed routing이 main에 머지됐지만, npm 최신 버전은 아직 `1.5.0`이었음.
+- 다른 레포에서 `npx tink-harness@latest update`를 실행하는 사용자는 새 rule graph seed와 cast/weave/frog 안내를 받을 수 없는 상태였음.
+- Claude Code plugin 버전도 함께 올리지 않으면 plugin update 경로와 npm update 경로가 서로 다르게 보일 수 있었음.
+
+## 해결
+
+- `package.json`, `package-lock.json`, `.claude-plugin/plugin.json`을 `1.6.0`으로 맞췄음.
+- `CHANGELOG.md`, `VERSIONING.md`, `README.md`, `README.ko.md`에 v1.6.0 내용을 반영했음.
+- README의 최신 릴리스 설명을 graph-rule seed routing 중심으로 바꿨음.
+- v1.6.0은 새 public command를 추가하지 않고, 기존 작은 file-based rule graph를 실제 작업 흐름에 연결하는 마이너 릴리스로 정리했음.
+
+## 검증
+
+- `npm test`로 템플릿, 버전 메타데이터, README 문구, package contents 회귀 테스트를 확인할 예정임.
+- `git diff --check`로 공백 문제를 확인할 예정임.
+- `npm pack --dry-run --json`으로 npm 패키지에 새 docs와 templates가 포함되는지 확인할 예정임.
+- publish 후에는 `npm view tink-harness version`과 임시 설치/update smoke로 `@latest` 경로를 확인할 예정임.
+
+## 참고
+
+- GitHub Release는 마이너 버전 업데이트이므로 생성 대상임.
+- 이번 릴리스는 Writ식 무거운 그래프 인프라를 도입하지 않음.
+- public `tink index`, watcher, generated cache, database, 외부 서비스는 추가하지 않음.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tink-harness",
-  "version": "1.5.0",
+  "version": "1.6.0",
   "description": "Self-growing harnesses for Claude Code and Codex.",
   "license": "MIT",
   "type": "module",