v1.17.0 릴리즈

Author: dotoricode

.claude-plugin/plugin.json

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

.claude/commands/tink/cast.md

@@ -533,7 +533,7 @@ Rule: while such a run is active, END every assistant response with a progress b
 ## Base run (no harness)
 Generic task-type harnesses (`code-change`, `bug-fix`, `research`, `review`, `docs`) are retired from the default set. Generic work runs as a **base run**: the run state contract alone - `plan.md`, `checks.md`, `steps.json`, `contract.json` - already enforces scope, verification commands, and evidence for ordinary code, bug, research, review, and docs work.
 
-- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
+- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`, `loop-engineering`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
 - Never force a loose-fit harness just to show a harness name. "No harness" is a valid and common selection.
 - In user-facing output call this `기본 절차` (Korean) or `base run` (English), with one short explanation line such as `기본 절차로 진행합니다 - 별도 하네스 없이 실행 상태 계약(계획·검증·증거)만 사용`.
 - The base run does not weaken anything: contract checks, Stitch, overlay rules, and the progress display still apply unchanged.
@@ -580,6 +580,7 @@ This is the Lane 3 full path from Quick triage. Lanes 1 and 2 intentionally skip
    - Use `review-two-axis` for PR/branch/diff review when Standards and Spec should be reported separately.
    - Use `decision-map` only when a loose idea has multiple unresolved decisions that need research, prototype, or discussion tickets across sessions.
    - Use `architecture-deepening` only when the work is explicitly about module/interface/seam shape, deep modules, leverage, locality, or testability.
+   - Use `loop-engineering` only when the user explicitly asks to iterate until a measurable bar passes (tests/lint/build green, coverage, benchmark, score). Not for ordinary multi-step work (`goal-checkpoint`) or hard bugs (`bug-diagnosis-loop`).
 
    **Overlay selection is rule-bound, not taste.** After drafting the Goals list for the approval payload, re-check before presenting it:
    - `goal-checkpoint` is REQUIRED (not optional) when ANY of these is true: the Goals list has 2+ goals; 2+ harnesses run sequentially; the plan is expected to need 4+ steps; or the work spans multiple components/directories. Create `goals.json` after approval.

.claude/commands/tink/deep-cast.md

@@ -488,7 +488,7 @@ Rule: while such a run is active, END every assistant response with a progress b
 ## Base run (no harness)
 Generic task-type harnesses (`code-change`, `bug-fix`, `research`, `review`, `docs`) are retired from the default set. Generic work runs as a **base run**: the run state contract alone - `plan.md`, `checks.md`, `steps.json`, `contract.json` - already enforces scope, verification commands, and evidence for ordinary code, bug, research, review, and docs work.
 
-- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
+- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`, `loop-engineering`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
 - Never force a loose-fit harness just to show a harness name. "No harness" is a valid and common selection.
 - In user-facing output call this `기본 절차` (Korean) or `base run` (English), with one short explanation line such as `기본 절차로 진행합니다 - 별도 하네스 없이 실행 상태 계약(계획·검증·증거)만 사용`.
 - The base run does not weaken anything: contract checks, Stitch, overlay rules, and the progress display still apply unchanged.
@@ -535,6 +535,7 @@ This is the full path after the interview produces a spec.
    - Use `review-two-axis` for PR/branch/diff review when Standards and Spec should be reported separately.
    - Use `decision-map` only when a loose idea has multiple unresolved decisions that need research, prototype, or discussion tickets across sessions.
    - Use `architecture-deepening` only when the work is explicitly about module/interface/seam shape, deep modules, leverage, locality, or testability.
+   - Use `loop-engineering` only when the user explicitly asks to iterate until a measurable bar passes (tests/lint/build green, coverage, benchmark, score). Not for ordinary multi-step work (`goal-checkpoint`) or hard bugs (`bug-diagnosis-loop`).
 
    **Overlay selection is rule-bound, not taste.** After drafting the Goals list for the approval payload, re-check before presenting it:
    - `goal-checkpoint` is REQUIRED (not optional) when ANY of these is true: the Goals list has 2+ goals; 2+ harnesses run sequentially; the plan is expected to need 4+ steps; or the work spans multiple components/directories. Create `goals.json` after approval.

CHANGELOG.md

@@ -4,6 +4,11 @@ All notable changes to Tink are tracked here.
 
 ## Unreleased
 
+## [1.17.0] - 2026-06-30
+
+- `loop-engineering` 하네스 추가: 측정 가능한 수용 신호(테스트·lint·build 통과, 커버리지, 벤치마크, 점수 등)를 향해 한 번에 한 병목씩 반복하고, 예산 초과 시 현재 상태·원인·다음 행동을 보고한다. 독립 평가(자기 채점 금지)와 반복 로그를 강제. `goal-checkpoint`(일반 다단계)·`bug-diagnosis-loop`(버그 진단)와 `use_when`에서 명시적으로 구분됨.
+- README 경험 스토리 상단 배치 및 확장.
+
 ## [1.16.1] - 2026-06-25
 
 - Codex에서 `$tink:deep-cast` 명령이 보이지 않던 문제 수정 — `templates/codex/skills/tink-deep-cast/SKILL.md` 누락이 원인

VERSIONING.md

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

commands/cast.md

@@ -533,7 +533,7 @@ Rule: while such a run is active, END every assistant response with a progress b
 ## Base run (no harness)
 Generic task-type harnesses (`code-change`, `bug-fix`, `research`, `review`, `docs`) are retired from the default set. Generic work runs as a **base run**: the run state contract alone - `plan.md`, `checks.md`, `steps.json`, `contract.json` - already enforces scope, verification commands, and evidence for ordinary code, bug, research, review, and docs work.
 
-- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
+- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`, `loop-engineering`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
 - Never force a loose-fit harness just to show a harness name. "No harness" is a valid and common selection.
 - In user-facing output call this `기본 절차` (Korean) or `base run` (English), with one short explanation line such as `기본 절차로 진행합니다 - 별도 하네스 없이 실행 상태 계약(계획·검증·증거)만 사용`.
 - The base run does not weaken anything: contract checks, Stitch, overlay rules, and the progress display still apply unchanged.
@@ -580,6 +580,7 @@ This is the Lane 3 full path from Quick triage. Lanes 1 and 2 intentionally skip
    - Use `review-two-axis` for PR/branch/diff review when Standards and Spec should be reported separately.
    - Use `decision-map` only when a loose idea has multiple unresolved decisions that need research, prototype, or discussion tickets across sessions.
    - Use `architecture-deepening` only when the work is explicitly about module/interface/seam shape, deep modules, leverage, locality, or testability.
+   - Use `loop-engineering` only when the user explicitly asks to iterate until a measurable bar passes (tests/lint/build green, coverage, benchmark, score). Not for ordinary multi-step work (`goal-checkpoint`) or hard bugs (`bug-diagnosis-loop`).
 
    **Overlay selection is rule-bound, not taste.** After drafting the Goals list for the approval payload, re-check before presenting it:
    - `goal-checkpoint` is REQUIRED (not optional) when ANY of these is true: the Goals list has 2+ goals; 2+ harnesses run sequentially; the plan is expected to need 4+ steps; or the work spans multiple components/directories. Create `goals.json` after approval.

commands/deep-cast.md

@@ -488,7 +488,7 @@ Rule: while such a run is active, END every assistant response with a progress b
 ## Base run (no harness)
 Generic task-type harnesses (`code-change`, `bug-fix`, `research`, `review`, `docs`) are retired from the default set. Generic work runs as a **base run**: the run state contract alone - `plan.md`, `checks.md`, `steps.json`, `contract.json` - already enforces scope, verification commands, and evidence for ordinary code, bug, research, review, and docs work.
 
-- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
+- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`, `loop-engineering`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
 - Never force a loose-fit harness just to show a harness name. "No harness" is a valid and common selection.
 - In user-facing output call this `기본 절차` (Korean) or `base run` (English), with one short explanation line such as `기본 절차로 진행합니다 - 별도 하네스 없이 실행 상태 계약(계획·검증·증거)만 사용`.
 - The base run does not weaken anything: contract checks, Stitch, overlay rules, and the progress display still apply unchanged.
@@ -535,6 +535,7 @@ This is the full path after the interview produces a spec.
    - Use `review-two-axis` for PR/branch/diff review when Standards and Spec should be reported separately.
    - Use `decision-map` only when a loose idea has multiple unresolved decisions that need research, prototype, or discussion tickets across sessions.
    - Use `architecture-deepening` only when the work is explicitly about module/interface/seam shape, deep modules, leverage, locality, or testability.
+   - Use `loop-engineering` only when the user explicitly asks to iterate until a measurable bar passes (tests/lint/build green, coverage, benchmark, score). Not for ordinary multi-step work (`goal-checkpoint`) or hard bugs (`bug-diagnosis-loop`).
 
    **Overlay selection is rule-bound, not taste.** After drafting the Goals list for the approval payload, re-check before presenting it:
    - `goal-checkpoint` is REQUIRED (not optional) when ANY of these is true: the Goals list has 2+ goals; 2+ harnesses run sequentially; the plan is expected to need 4+ steps; or the work spans multiple components/directories. Create `goals.json` after approval.

package-lock.json

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

package.json

@@ -533,7 +533,7 @@ Rule: while such a run is active, END every assistant response with a progress b
 ## Base run (no harness)
 Generic task-type harnesses (`code-change`, `bug-fix`, `research`, `review`, `docs`) are retired from the default set. Generic work runs as a **base run**: the run state contract alone - `plan.md`, `checks.md`, `steps.json`, `contract.json` - already enforces scope, verification commands, and evidence for ordinary code, bug, research, review, and docs work.
 
-- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
+- Select a harness only when its specialized procedure changes what would actually happen: visible-thinking overlays (`requirements-interview`, `plan-consensus`, `goal-checkpoint`, `delegation-brief`), focused work harnesses (`issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, `architecture-deepening`, `loop-engineering`), risk gates (`ship`, `pre-publish-multi-agent-verify`, `pr-merge`), meta harnesses (`harness-curation`, `harness-synthesis`), `tink-feedback-apply`, or user-created and synthesized domain harnesses.
 - Never force a loose-fit harness just to show a harness name. "No harness" is a valid and common selection.
 - In user-facing output call this `기본 절차` (Korean) or `base run` (English), with one short explanation line such as `기본 절차로 진행합니다 - 별도 하네스 없이 실행 상태 계약(계획·검증·증거)만 사용`.
 - The base run does not weaken anything: contract checks, Stitch, overlay rules, and the progress display still apply unchanged.
@@ -580,6 +580,7 @@ This is the Lane 3 full path from Quick triage. Lanes 1 and 2 intentionally skip
    - Use `review-two-axis` for PR/branch/diff review when Standards and Spec should be reported separately.
    - Use `decision-map` only when a loose idea has multiple unresolved decisions that need research, prototype, or discussion tickets across sessions.
    - Use `architecture-deepening` only when the work is explicitly about module/interface/seam shape, deep modules, leverage, locality, or testability.
+   - Use `loop-engineering` only when the user explicitly asks to iterate until a measurable bar passes (tests/lint/build green, coverage, benchmark, score). Not for ordinary multi-step work (`goal-checkpoint`) or hard bugs (`bug-diagnosis-loop`).
 
    **Overlay selection is rule-bound, not taste.** After drafting the Goals list for the approval payload, re-check before presenting it:
    - `goal-checkpoint` is REQUIRED (not optional) when ANY of these is true: the Goals list has 2+ goals; 2+ harnesses run sequentially; the plan is expected to need 4+ steps; or the work spans multiple components/directories. Create `goals.json` after approval.