tink-harness 1.12.0 → 1.13.0

package/.claude-plugin/plugin.json

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

package/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 All notable changes to Tink are tracked here.
 
+## [1.13.0] - 2026-06-19
+
+- Added focused opt-in harnesses for recurring agent workflows: `issue-triage`, `bug-diagnosis-loop`, `review-two-axis`, `decision-map`, and `architecture-deepening`.
+- Improved existing harnesses with selected workflow patterns: requirements interviews now inspect repo-discoverable answers first, plan consensus can compare interface alternatives and split unresolved decisions, delegation briefs reference existing artifacts and redact sensitive content, ship/PR merge records conflict intent, and harness curation has clearer idea-to-ship routing.
+- Updated `/tink:cast` routing and Codex core rules so the new focused harnesses are considered only when their trigger changes the procedure. README and README.ko now describe the new selection surface.
+
 ## [1.12.0] - 2026-06-18
 
 - Added evidence lifecycle manager groundwork: `/tink:verify` now records a human-readable `.tink/current/evidence.md` summary card, config includes a `completion_policy` field for optional strict "no evidence, no done" behavior, and the dashboard lifecycle summary now exposes ROI hints, trust levels, and Activity-tab run review cards for failed or blocked runs without adding a new public replay command.

package/README.ko.md

@@ -10,7 +10,7 @@ Tink는 사소하지 않은 모든 에이전트 작업을 눈에 보이는 파
 
 <sub>Claude Code와 Codex를 위한 작은 하네스 레이어</sub>
 
-**최신 패키지:** v1.12.0 — 검증 후 사람이 읽기 쉬운 evidence card를 남기고, strict 완료 정책의 “no evidence, no done” 기반을 추가했습니다. 대시보드에는 하네스 신뢰도, ROI, 실패/차단 run 복기 카드가 표시됩니다. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
+**최신 패키지:** v1.13.0 — 이슈 정리, 어려운 버그 진단 루프, 두 축 리뷰, decision map, architecture deepening을 위한 focused opt-in 하네스를 추가하고 Claude Code·Codex 양쪽 cast 라우팅과 문서를 갱신했습니다. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
 
 [English](README.md) · **한국어** · [변경 이력](CHANGELOG.md)
 
@@ -175,7 +175,9 @@ Claude Code에서는 `/tink:*`, Codex에서는 `$tink:*`을 씁니다. 예전 `$
 
 Tink는 이제 비단순 작업에 대해 `.tink/current/contract.json`도 만듭니다. 이 파일에는 작업 종류, 위험, 성공 조건, 금지 사항, 검증 명령이 들어갑니다.
 
-더 크거나 모호한 작업에서는 `cast`가 에이전트의 생각 단계를 파일로 더 잘 드러내는 하네스를 고를 수 있습니다. 모호한 아이디어는 `requirements-interview`, 큰 계획은 `plan-consensus`, 긴 실행은 `goal-checkpoint`, 안전한 인수인계는 `delegation-brief`를 씁니다. 모두 `/tink:cast` 또는 `$tink:cast`가 고르는 재사용 하네스이며, 별도 CLI 명령은 아닙니다.
+더 크거나 모호한 작업에서는 `cast`가 에이전트의 생각 단계를 파일로 더 잘 드러내는 하네스를 고를 수 있습니다. 모호한 아이디어는 `requirements-interview`, 큰 계획은 `plan-consensus`, 긴 실행은 `goal-checkpoint`, 안전한 인수인계는 `delegation-brief`를 씁니다.
+
+더 특화된 작업에서는 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 명령은 아닙니다.
 
 ### `/tink:verify` / `$tink:verify`
 
@@ -212,7 +214,7 @@ Tink가 아는 모든 것은 직접 읽고, diff 보고, 지울 수 있는 평
 
 이 전부를 움직이는 원칙은 세 가지입니다.
 
-1. **일반 작업에는 하네스가 필요 없습니다.** 평범한 코드 변경·리뷰·문서 작업은 기본 절차(계획 → 단계 → 검증 증거)만으로 진행합니다. 하네스는 특화된 절차가 실제로 결과를 바꿀 때만 로드됩니다 — 출시 안전판, 목표 체크포인트, 계획 비평, 요구사항 인터뷰, 도메인 워크플로.
+1. **일반 작업에는 하네스가 필요 없습니다.** 평범한 코드 변경·리뷰·문서 작업은 기본 절차(계획 → 단계 → 검증 증거)만으로 진행합니다. 하네스는 특화된 절차가 실제로 결과를 바꿀 때만 로드됩니다 — 출시 안전판, 목표 체크포인트, 계획 비평, 요구사항 인터뷰, 이슈 정리, 어려운 버그 진단 루프, 두 축 리뷰, decision map, architecture deepening, 도메인 워크플로.
 2. **제안만 합니다.** 대시보드·`frog`·`weave`는 실제 사용 신호로 제안을 준비할 뿐입니다. 재사용되는 것(하네스, 메모리, 삭제)은 반드시 별도 명시 승인을 거칩니다. 오늘 실행의 승인이 미래 실행이 물려받을 변경을 허가하지 않습니다.
 3. **느낌이 아니라 증거.** 실행 기록, 실패한 체크, evidence summary card, friction 이벤트가 무엇을 개선하고(`weave`), 초안에서 하네스로 승격하고, 정리할지(`frog`)를 결정합니다. 증거가 약하면 삭제가 아니라 유지·관찰이 기본입니다.
 

package/README.md

@@ -17,14 +17,14 @@
 <p><sub>A small harness layer for Claude Code and Codex</sub></p>
 
 <p>
-  <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.12.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.13.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.12.0 - Tink now records a human-readable evidence card after verification, adds the strict completion-policy groundwork for "no evidence, no done", and shows dashboard hints for harness trust, ROI, and failed/blocked run review. See <a href="CHANGELOG.md">CHANGELOG</a> for release history.</p>
+<p><strong>Latest package:</strong> v1.13.0 - Tink adds focused opt-in harnesses for issue triage, hard-bug diagnosis loops, two-axis reviews, decision maps, and architecture deepening, with cast routing and docs updated for both Claude Code and Codex. See <a href="CHANGELOG.md">CHANGELOG</a> for release history.</p>
 
 **English** · [한국어](README.ko.md) · [Changelog](CHANGELOG.md)
 
@@ -219,7 +219,9 @@ 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.
+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`.
+
+More specialized work can opt into focused harnesses: `issue-triage` for issue/PR/QA intake, `bug-diagnosis-loop` for hard bugs that need a red-capable repro loop, `review-two-axis` for Standards vs Spec review, `decision-map` for multi-session unknowns, and `architecture-deepening` for module/interface/seam design. These are selected by `/tink:cast` or `$tink:cast`; they are not separate CLI workflows.
 
 ### `/tink:verify` / `$tink:verify`
 
@@ -266,7 +268,7 @@ Everything Tink knows lives in plain files you can read, diff, and delete:
 
 Three rules drive all of it:
 
-1. **Generic work runs without a harness.** An ordinary code change, review, or doc edit runs on the base run contract alone — plan, steps, verification evidence. A harness is loaded only when a specialized procedure actually changes what happens: release gates, goal checkpoints, plan critique, requirements interviews, domain workflows.
+1. **Generic work runs without a harness.** An ordinary code change, review, or doc edit runs on the base run contract alone — plan, steps, verification evidence. A harness is loaded only when a specialized procedure actually changes what happens: release gates, goal checkpoints, plan critique, requirements interviews, issue triage, hard-bug diagnosis loops, two-axis reviews, decision maps, architecture deepening, or other domain workflows.
 2. **Suggestions only.** The dashboard, `frog`, and `weave` prepare proposals from real usage signals. Nothing reusable — a harness, a memory entry, a deletion — is saved without its own explicit approval. Approving today's run never authorizes changes that future runs would inherit.
 3. **Evidence over vibes.** Run records, failed checks, evidence summary cards, and friction events decide what gets improved (`weave`), promoted from draft to harness, or cleaned up (`frog`). Weak evidence defaults to keep-and-observe, never to delete.
 

package/VERSIONING.md

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

package/commands/cast.md

@@ -445,7 +445,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`), 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`), 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.
@@ -485,12 +485,18 @@ This is the Lane 3 full path from Quick triage. Lanes 1 and 2 intentionally skip
    - 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, independent 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. Consider focused work harnesses only when their trigger is strong enough to change the procedure:
+   - Use `issue-triage` for issue/PR/QA intake, ready-for-agent briefs, needs-info/wontfix decisions, or vertical issue slices.
+   - Use `bug-diagnosis-loop` for hard bugs, regressions, intermittent failures, or performance problems where a red-capable loop must come before code changes.
+   - 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.
 
    **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.
    - `plan-consensus` must be explicitly considered for any from-scratch implementation, reimplementation, migration, or public contract/API design. If skipped, record a one-line reason in the 오버레이 점검 line.
    - The context budget and the "prefer 1-3 harnesses" guidance never justify dropping a REQUIRED overlay: overlays are cheap state files, not extra loaded context. A large task judged "fine with default harnesses" because the synthesis probe found a fit is a selection bug - the probe only answers whether a custom procedure is needed, not whether overlays are needed.
-7. Pick the smallest effective set using the context budget policy below: the base run plus 0-3 specialized harnesses. When no specialized harness fits, select the base run alone - do not force a generic fit. 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.
+8. Pick the smallest effective set using the context budget policy below: the base run plus 0-3 specialized harnesses. When no specialized harness fits, select the base run alone - do not force a generic fit. 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
@@ -498,26 +504,26 @@ This is the Lane 3 full path from Quick triage. Lanes 1 and 2 intentionally skip
    - 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 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 base run or selected 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:
+9. Add any rule graph check candidates to `contract.json` verification if they are relevant and cheap. For risky commands, set `approval_required: true`.
+10. Add opt-in guard candidates to `notes.md` only as suggestions. Do not register enforcement hooks unless the user separately approves.
+11. 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).
+12. If the probe finds no fit, load `harness-synthesis` and draft a domain-specific harness for this run instead of forcing a bad fit.
+13. If the probe finds a generic fit (2-3 yes), propose a run-only draft harness or domain rules alongside the base run or selected harness. Do not save it by default.
+14. If too many tools, skills, agents, or harnesses are available, load `harness-curation` and choose the smallest effective set before loading more context.
+15. 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.
+16. 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.
+17. 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.
+18. Ask for explicit approval before non-trivial work.
+19. After approval, read only the selected harness files and any approved run-only draft.
+20. 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`.
+21. Execute the first safe step immediately:
    - inspect relevant files,
    - run a read-only diagnostic,
    - draft the first artifact,
    - or reproduce the issue.
-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. When the Progress display trigger applies, end every response with the progress block.
-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.
+22. 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. When the Progress display trigger applies, end every response with the progress block.
+23. Before final, run `/tink:verify` behavior for required contract checks or state why verification is blocked.
+24. 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

package/docs/planned-work-units.ko.md

@@ -2,6 +2,10 @@
 
 이 문서는 남은 로드맵을 번호가 붙은 단계가 아니라 실제 작업 단위로 다시 정리한다. 모든 작업은 Claude Code와 Codex를 함께 지원하고, macOS와 Windows에서 동작해야 하며, 사용자가 명시적으로 원하지 않는 한 새 public command surface를 만들지 않는다.
 
+## 관리 규칙
+
+포괄적인 아이디어는 바로 구현 목록에 넣지 않고 먼저 요구사항, 성공 기준, 제외 범위, 검증 근거로 좁힌다. 구현이 완료된 작업 단위는 이 활성 목록에서 제거하고, 완료 사실은 구현된 기반, PR 문서, changelog, 또는 별도 완료 기록에 남긴다.
+
 ## 구현된 기반
 
 ### 하네스 생애주기 신호
@@ -87,6 +91,19 @@ Standalone CLI를 더 짧게 입력하고, 로컬 health report를 더 쉽게
 - `dashboard`는 기본적으로 로컬 정적 파일만 만든다. 서버, watcher, hidden cache, 자동 하네스 수정은 하지 않는다.
 - 생성 파일 경로가 플랫폼별로 안정화된 뒤에만 선택적인 open/export flag를 검토한다.
 
+## Swarm Fast Lane
+
+작업 병렬화를 위한 멀티 에이전트 하네스를 연구하되, Tink를 별도 multi-agent runtime으로 만들지 않는다. 상세 계획은 `docs/swarm-fast-lane.ko.md`와 `docs/swarm-fast-lane.md`에 둔다.
+
+- worker는 전체 작업이 아니라 1-3개 입력만 가진 작은 packet을 본다.
+- worker는 기본적으로 파일을 직접 수정하지 않고 evidence와 patch candidate만 반환한다.
+- 메인 에이전트만 최종 patch 선택, 파일 수정, 검증을 책임진다.
+- 성공 지표는 "항상 더 빠름"이 아니라 main context 감소, 재작업 감소, 실패 조기 발견, 검증 통과율 유지 또는 개선으로 둔다.
+- 초기 모드는 `parallel-probe`, `patch-candidate-race`, `micro-contract-split`, `speculative-verifier`, `context-starvation-mode` 후보를 검토한다.
+- `/tink:cast`와 `$tink:cast`가 이 하네스를 언제 선택하고 언제 거절할지 문서화한다.
+- worker 출력은 300단어 이하, evidence-only, confidence 포함으로 제한한다.
+- public contract, secrets, 넓은 repo scan, 동일 파일 동시 수정이 필요한 작업에서는 선택하지 않는다.
+
 ## 제외
 
 release evidence bundling은 계속 제외한다. release history, public release note, portfolio framing은 사용자나 팀의 판단 영역이다. Tink는 검증 artifact를 남길 수 있지만, 공개 release evidence를 어떻게 묶을지는 대신 결정하지 않는다.

package/docs/planned-work-units.md

@@ -2,6 +2,10 @@
 
 This document restates the remaining roadmap as work units instead of numbered phases. Each unit should support Claude Code and Codex, work on macOS and Windows, and avoid new public command surfaces unless the user explicitly asks for one.
 
+## Management Rule
+
+Broad ideas should not enter the implementation list directly. First narrow them into requirements, success criteria, out-of-scope boundaries, and verification evidence. Once a work unit is implemented, remove it from this active list and record the completion in the implemented baseline, PR docs, changelog, or another completion record.
+
 ## Implemented Baseline
 
 ### Harness Lifecycle Signals
@@ -87,6 +91,19 @@ Make the standalone CLI easier to type and make the local health report easier t
 - Keep `dashboard` local and static by default: no server, watcher, hidden cache, or automatic harness edits.
 - Allow an optional open/export flag only after the generated file path behavior is stable across platforms.
 
+## Swarm Fast Lane
+
+Research a multi-agent harness for parallel work without turning Tink into a separate multi-agent runtime. The detailed plan lives in `docs/swarm-fast-lane.ko.md` and `docs/swarm-fast-lane.md`.
+
+- Workers see small packets with only 1-3 inputs, not the whole task.
+- Workers do not edit files by default; they return evidence and patch candidates.
+- The main agent owns final patch selection, file edits, and verification.
+- Success is measured by less main-agent context, less rework, earlier failure detection, and equal or better verification pass rate, not by claiming universal raw speed.
+- Initial mode candidates are `parallel-probe`, `patch-candidate-race`, `micro-contract-split`, `speculative-verifier`, and `context-starvation-mode`.
+- `/tink:cast` and `$tink:cast` should document when to select or reject this harness.
+- Worker output is capped at 300 words and must include evidence and confidence.
+- Do not select it for unclear public contracts, secrets, broad repository scans, or same-file concurrent edits.
+
 ## Excluded
 
 Release evidence bundling remains excluded. Release history, public release notes, and portfolio framing belong to the user or team. Tink may keep verification artifacts, but it should not decide how public release evidence is packaged.

package/docs/pr/2026-06-19-skill-adoption-harnesses.ko.md

@@ -0,0 +1,46 @@
+# 스킬 패턴 기반 Tink 하네스 확장
+
+## 문제
+
+Matt Pocock 계열 스킬과 일반 워크플로 스킬을 Tink에 적용하고 싶었지만, 스킬을 그대로 모두 하네스로 복사하면 Tink의 기본 경로가 무거워지고 역할이 흐려질 위험이 있었습니다.
+
+이번 작업의 핵심은 "스킬 목록을 많이 넣기"가 아니라, 반복적인 작업 절차 중 Tink의 선택과 검증 행동을 실제로 바꾸는 것만 선별하는 것이었습니다.
+
+## 해결
+
+새 opt-in 하네스 5개를 추가했습니다.
+
+- `issue-triage`
+  - 이슈, 외부 PR, QA 보고, 넓은 계획을 상태·agent-ready brief·세로 slice로 정리합니다.
+- `bug-diagnosis-loop`
+  - 어려운 버그, 회귀, flake, 성능 문제에서 코드 수정 전 red-capable feedback loop를 먼저 확보하게 합니다.
+- `review-two-axis`
+  - PR·브랜치·diff 리뷰를 Standards와 Spec 두 축으로 나눠 한쪽 통과가 다른 쪽 실패를 가리지 않게 합니다.
+- `decision-map`
+  - 여러 세션이 필요한 느슨한 아이디어를 research/prototype/discuss ticket 지도와 frontier로 관리합니다.
+- `architecture-deepening`
+  - deep module, interface, seam, leverage, locality, testability 관점으로 구조 개선 후보와 계획을 정리합니다.
+
+기존 하네스도 보강했습니다.
+
+- `requirements-interview`: 코드·문서에서 찾을 수 있는 답은 먼저 탐색하고, 결정 분기에는 추천 답안을 제시합니다.
+- `plan-consensus`: interface 대안 비교와 미해결 결정 ticket 분해를 반영했습니다.
+- `delegation-brief`: handoff 문서처럼 기존 artifact 참조, suggested harnesses/skills, 민감정보 제외 원칙을 추가했습니다.
+- `ship`, `pr-merge`: 충돌이나 범위 의심 시 primary source와 원 의도를 확인하고 tradeoff를 기록하게 했습니다.
+- `harness-curation`: idea → planning → issue intake → implementation → review/ship/merge 라우팅 힌트를 추가했습니다.
+
+`/tink:cast`와 Codex core rules도 갱신해 새 하네스들이 실제 선택 후보로 고려되도록 했습니다. README와 한국어 README에는 focused harness 선택 표면을 설명했습니다.
+
+## 검증
+
+- `npm test`
+- `git diff --check`
+- `commands/cast.md`, `templates/claude/commands/tink/cast.md`, `.claude/commands/tink/cast.md` 3-copy 동기화 확인
+- `templates/tink/harnesses/index.json` JSON parse 확인
+- 새 하네스 필수 섹션 및 100줄 이하 기준 확인
+
+## 참고
+
+- 일반 코드 변경·문서·리뷰는 여전히 기본 절차(base run)가 기본값입니다.
+- 새 하네스들은 "조금 더 무거워져도 되는" opt-in 절차로 추가했지만, 기본 cast 경로에서 무조건 로드하지 않도록 trigger를 좁게 두었습니다.
+- writing/teaching 계열 스킬은 Tink 핵심 역할과 거리가 있어 하네스로 복사하지 않았습니다.

package/docs/swarm-fast-lane.ko.md

@@ -0,0 +1,132 @@
+# Swarm Fast Lane 연구 계획
+
+이 문서는 멀티 에이전트를 작업 병렬화에 쓰되, Tink가 별도 거대 런타임이 되지 않도록 제한하는 연구 계획이다. 목표는 "에이전트를 많이 띄우기"가 아니라, 작은 컨텍스트 패킷을 병렬로 탐색해 메인 에이전트의 재작업과 전체 컨텍스트 부담을 줄이는 것이다.
+
+## 문제 정의
+
+일반적인 멀티 에이전트 병렬화는 토큰을 더 많이 쓴다. 각 worker가 같은 문맥을 다시 읽고, 서로 다른 수정이 충돌하며, 메인 에이전트가 합산 비용을 다시 치르기 때문이다.
+
+`swarm-fast-lane`은 이 문제를 반대로 접근한다.
+
+- worker가 전체 작업을 이해하지 않는다.
+- worker가 넓은 파일을 읽지 않는다.
+- worker가 기본적으로 직접 수정하지 않는다.
+- worker 출력은 짧은 evidence와 patch candidate로 제한한다.
+- 메인 에이전트만 최종 경로를 선택하고 파일을 수정한다.
+
+## 핵심 가설
+
+작업이 작게 나뉘고 경계 계약이 명확하다면, 여러 worker가 좁은 관측을 병렬 수행하는 편이 단일 에이전트가 넓은 컨텍스트를 순차 탐색하는 것보다 빠르고 덜 낭비적일 수 있다.
+
+성공 기준은 "항상 Codex fast mode보다 빠름"이 아니다. Tink가 직접 통제할 수 있는 1차 지표는 다음이다.
+
+- 메인 에이전트가 읽는 총 컨텍스트 감소
+- 재작업 감소
+- 실패 지점 조기 발견
+- worker 출력 합산 비용 제한
+- 최종 검증 통과율 유지 또는 개선
+
+## 생물학적 모델
+
+개미 군집처럼 각 worker는 전체 지도를 보지 않는다. 각 worker는 단일 자극에 반응한다.
+
+예:
+
+- 한 worker는 테스트 위치만 찾는다.
+- 한 worker는 public contract 위험만 찾는다.
+- 한 worker는 docs drift만 찾는다.
+- 한 worker는 작은 patch strategy 하나만 제안한다.
+
+메인 에이전트는 중앙 지휘자가 아니라 면역계처럼 행동한다. 들어온 제안을 그대로 합치지 않고, 충돌, 중복, 보안 위험, 검증 누락을 먼저 거른다.
+
+## 양자역학적 모델
+
+worker는 확정된 구현자가 아니라 가능성 샘플러다. 여러 patch 경로를 짧게 만든 뒤, 메인 에이전트가 evidence를 보고 하나의 경로로 collapse한다.
+
+규칙:
+
+- 관측 전 상태: patch candidate, risk candidate, test candidate.
+- 관측 조건: evidence handle, file reference, expected check.
+- collapse 조건: 가장 작은 수정, 가장 낮은 충돌 위험, 가장 명확한 검증.
+- 폐기 조건: 넓은 컨텍스트 요구, 직접 파일 수정 필요, evidence 부족.
+
+## 우주론적 모델
+
+작업 전체를 하나의 큰 우주로 보지 않고, 서로 인과 연결이 약한 국소 영역으로 나눈다.
+
+- 같은 public API, schema, command surface를 공유하면 같은 영역에 둔다.
+- 서로 다른 docs/test/fixture 영역은 독립 탐색 후보로 둔다.
+- public contract, release, schema, CLI surface는 중력장이 강한 경계로 보고 메인 에이전트만 수정한다.
+
+## 제안 모드
+
+### parallel-probe
+
+worker는 파일 수정 없이 관련 파일, 위험, 테스트 후보만 찾는다. 초기 버전의 기본 모드로 둔다.
+
+### patch-candidate-race
+
+여러 worker가 서로 다른 최소 patch strategy를 제안한다. 메인 에이전트는 하나만 선택해 적용한다.
+
+### micro-contract-split
+
+메인 에이전트가 작업을 3-5개의 작은 계약으로 나누고, worker는 계약 하나만 검토한다.
+
+### speculative-verifier
+
+구현 중간에 worker들이 "이 접근이 실패할 이유"만 찾는다. 구현 병렬화보다 안전하고 비용 대비 효과가 클 수 있다.
+
+### context-starvation-mode
+
+worker에게 의도적으로 불완전한 최소 컨텍스트만 준다. 목적은 좋은 구현이 아니라, 작은 정보로도 잡히는 문제를 싸게 찾는 것이다.
+
+## 하네스 계약
+
+`swarm-fast-lane` 하네스는 다음 조건을 만족할 때만 선택한다.
+
+- 작업이 2-5개의 독립 packet으로 나뉜다.
+- 각 packet은 입력 파일 또는 질문이 1-3개로 제한된다.
+- 각 worker의 출력은 300단어 이하로 제한된다.
+- worker는 기본적으로 직접 파일을 수정하지 않는다.
+- worker 출력에는 evidence, 추천 행동, confidence가 포함된다.
+- 메인 에이전트가 최종 patch와 검증을 책임진다.
+
+선택하지 않아야 하는 경우:
+
+- public contract 경계가 불명확하다.
+- secrets, credentials, private payload가 필요하다.
+- worker가 넓은 repository scan을 해야만 한다.
+- 여러 worker가 같은 파일을 수정해야 한다.
+- 합산 비용이 단일 base run보다 커질 가능성이 높다.
+
+## 측정 항목
+
+초기 구현은 추정값부터 시작하되, run artifact에 근거를 남겨야 한다.
+
+- `worker_count`
+- `packet_count`
+- `input_context_refs`
+- `worker_output_words`
+- `accepted_candidates`
+- `rejected_candidates`
+- `merge_conflicts_avoided`
+- `main_context_saved_estimate`
+- `checks_passed`
+- `checks_failed_or_blocked`
+
+## 완료 기준
+
+첫 구현 slice는 다음을 완료로 본다.
+
+- `swarm-fast-lane` 하네스 초안이 있다.
+- `/tink:cast`와 `$tink:cast`가 이 하네스를 언제 선택하고 언제 거절할지 문서화되어 있다.
+- worker packet 형식이 `.tink/current/delegation.md` 또는 별도 run artifact로 표현된다.
+- worker 직접 수정은 기본 비활성이다.
+- 최소 하나의 fixture 또는 문서 예제가 있다.
+- 검증은 "더 빠름"을 단정하지 않고, context 감소와 재작업 감소 근거를 기록한다.
+
+## 열린 질문
+
+- 실제 worker 실행은 Codex/Claude Code의 기존 기능을 얇게 호출할지, Tink는 packet 문서화까지만 할지 결정해야 한다.
+- worker 결과 schema를 `delegation-brief`에 통합할지, 별도 하네스로 둘지 결정해야 한다.
+- fast lane이라는 이름이 과도한 성능 보장을 암시하지 않도록 사용자 문구를 조정해야 한다.

package/docs/swarm-fast-lane.md

@@ -0,0 +1,132 @@
+# Swarm Fast Lane Research Plan
+
+This document describes a constrained research plan for using multi-agent parallelism without turning Tink into a large standalone runtime. The goal is not to spawn more agents by default. The goal is to split work into tiny context packets so workers can explore independent evidence while the main agent reduces rework and context load.
+
+## Problem
+
+Naive multi-agent parallelism usually spends more tokens. Each worker rereads context, independent edits conflict, and the main agent still pays a reconciliation cost.
+
+`swarm-fast-lane` inverts that model.
+
+- Workers do not understand the whole task.
+- Workers do not read broad context.
+- Workers do not edit files by default.
+- Worker output is limited to short evidence and patch candidates.
+- The main agent chooses the final path and owns file edits.
+
+## Core Hypothesis
+
+When a task can be split into small contracts with clear boundaries, several workers with narrow observations may reduce rework and main-agent context load compared with one agent scanning broad context sequentially.
+
+The first success metric is not "always faster than Codex fast mode." Tink can directly control these metrics instead:
+
+- less total context read by the main agent
+- less rework
+- earlier failure detection
+- bounded worker-output reconciliation cost
+- equal or better final verification pass rate
+
+## Biological Model
+
+Like an ant colony, each worker responds to a local signal rather than reading the whole map.
+
+Examples:
+
+- one worker finds test locations only
+- one worker checks public contract risk only
+- one worker checks docs drift only
+- one worker proposes one small patch strategy only
+
+The main agent acts more like an immune system than a central commander. It rejects conflicts, duplicates, security risks, and missing verification before accepting any candidate.
+
+## Quantum Model
+
+Workers are possibility samplers, not final implementers. Several patch paths stay tentative until the main agent collapses one path based on evidence.
+
+Rules:
+
+- Pre-observation state: patch candidate, risk candidate, test candidate.
+- Observation condition: evidence handle, file reference, expected check.
+- Collapse condition: smallest edit, lowest conflict risk, clearest verification.
+- Rejection condition: broad context demand, direct edit requirement, weak evidence.
+
+## Cosmological Model
+
+The task is split into local universes with weak causal links.
+
+- Files sharing a public API, schema, or command surface stay in the same region.
+- Separate docs, tests, and fixtures can become independent exploration candidates.
+- Public contracts, release surfaces, schemas, and CLI surfaces are high-gravity boundaries edited only by the main agent.
+
+## Proposed Modes
+
+### parallel-probe
+
+Workers do not edit files. They only find related files, risks, and test candidates. This should be the first default mode.
+
+### patch-candidate-race
+
+Workers propose different minimal patch strategies. The main agent picks one and applies it.
+
+### micro-contract-split
+
+The main agent splits work into 3-5 small contracts. Each worker reviews one contract.
+
+### speculative-verifier
+
+Workers look only for reasons the current implementation approach will fail. This can be safer and cheaper than parallel implementation.
+
+### context-starvation-mode
+
+Workers intentionally receive incomplete minimal context. The point is not high-quality implementation; it is cheaply detecting problems that are visible with little information.
+
+## Harness Contract
+
+The `swarm-fast-lane` harness is eligible only when:
+
+- the task splits into 2-5 independent packets
+- each packet is limited to 1-3 input files or questions
+- each worker output is limited to 300 words
+- workers do not edit files by default
+- worker output includes evidence, recommended action, and confidence
+- the main agent owns final patching and verification
+
+Do not select it when:
+
+- public contract boundaries are unclear
+- secrets, credentials, or private payloads are required
+- workers need a broad repository scan
+- multiple workers must edit the same files
+- reconciliation is likely to cost more than a single base run
+
+## Metrics
+
+The first version can start with estimates, but run artifacts should record evidence.
+
+- `worker_count`
+- `packet_count`
+- `input_context_refs`
+- `worker_output_words`
+- `accepted_candidates`
+- `rejected_candidates`
+- `merge_conflicts_avoided`
+- `main_context_saved_estimate`
+- `checks_passed`
+- `checks_failed_or_blocked`
+
+## Done Criteria
+
+The first implementation slice is done when:
+
+- a `swarm-fast-lane` harness draft exists
+- `/tink:cast` and `$tink:cast` document when to select or reject it
+- worker packet format is represented in `.tink/current/delegation.md` or another run artifact
+- direct worker edits are disabled by default
+- at least one fixture or example exists
+- verification records context reduction and rework reduction evidence instead of claiming raw speed
+
+## Open Questions
+
+- Should actual worker execution call existing Codex/Claude Code features, or should Tink only document packets?
+- Should worker result schema extend `delegation-brief`, or should this be a separate harness?
+- Should the user-facing name avoid implying guaranteed speed?

package/docs/tink-idea-implementation-plan.ko.md

@@ -33,7 +33,7 @@
 | Productivity dashboard | 정적 기반 구현 | harness lifecycle summary, graph overview, run timeline, candidate score, lifecycle state, local HTML health report | token/context cost, 검증 누락, update 이슈까지 포함하는 더 넓은 대시보드와 interactive UI |
 | Harness 자동 개선과 삭제 | 안전한 제안 기반 구현 | `/tink:weave`, `/tink:frog`, evidence grade, maintenance ledger, lifecycle summary, dormant candidate, approval gate | 승인 전 preview UX 강화, 실제 archive/merge 작업을 별도 승인 흐름으로 더 선명하게 분리 |
 | Harness registry/signing/lockfile | 미구현 | plugin/package release 흐름은 있음 | `.tink/lock.json`, registry metadata, source trust, version pinning |
-| Subagent adapter | 미구현 | multi-agent 자체 런타임을 만들지 않는 방향만 정해짐 | Claude/Codex의 기존 subagent 기능에 맞춘 얇은 adapter contract |
+| Subagent adapter / Swarm Fast Lane | 연구 계획 추가 | multi-agent 자체 런타임을 만들지 않는 방향, worker 직접 수정 비활성 기본값, 작은 packet 기반 병렬 탐색 원칙 | `swarm-fast-lane` 하네스 초안, worker packet schema, cast 선택/거절 규칙, fixture 또는 예제 |
 | Memory knowledge layers | 부분 구현 | `.tink/memory/`, reusable save gate | `approved/`, `candidate/`, `rejected/`, `evidence/` 계층화와 승인 이력 |
 
 ## 다음 구현 원칙
@@ -176,6 +176,31 @@ Tink의 장점은 "AI가 알아서 했다"가 아니라 "왜 이 context와 검
 - 사용자 승인 전에는 candidate로만 남긴다.
 - 왜 어떤 기억이 저장되었는지 evidence를 추적할 수 있다.
 
+### Phase 11: Swarm Fast Lane
+
+작업 병렬화를 위한 멀티 에이전트 하네스를 연구한다. 단, Tink가 자체 multi-agent runtime이 되거나 "항상 fast mode보다 빠름"을 약속하지 않는다. 상세 계획은 `docs/swarm-fast-lane.ko.md`와 `docs/swarm-fast-lane.md`에 둔다.
+
+생기는 기능:
+
+- 1-3개 입력만 가진 worker packet
+- worker 직접 파일 수정 비활성 기본값
+- evidence, patch candidate, confidence 중심의 300단어 이하 worker report
+- `parallel-probe`, `patch-candidate-race`, `micro-contract-split`, `speculative-verifier`, `context-starvation-mode` 후보 모드
+- `/tink:cast`와 `$tink:cast`의 선택/거절 규칙
+
+개선 효과:
+
+- 메인 에이전트가 넓은 repo context를 읽기 전에 작은 독립 탐색을 먼저 수행할 수 있다.
+- 재작업과 뒤늦은 실패 발견을 줄일 수 있다.
+- 병렬화가 유효한 작업과 오히려 낭비인 작업을 하네스 단계에서 구분할 수 있다.
+
+명시적 비목표:
+
+- Tink 전용 worker runtime 만들기
+- worker가 기본적으로 파일을 직접 수정하기
+- secrets, public contract, 넓은 repo scan이 필요한 작업에 fast lane 강제 적용하기
+- 실제 측정 없이 "Codex fast mode보다 빠르다"고 주장하기
+
 ## 더 추가하면 좋은 아이디어
 
 ### Context Diff Review

package/package.json

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