tink-harness 1.14.0 → 1.15.0

package/.claude-plugin/plugin.json

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

package/CHANGELOG.md

@@ -2,6 +2,17 @@
 
 All notable changes to Tink are tracked here.
 
+## Unreleased
+
+- Added a geobench product spec and runbook for measuring Tink's LLM answer visibility with hit rate, MRR, share of voice, and citation metrics. The runbook keeps benchmark execution separate from this repo and says to publish aggregate metrics only.
+
+## [1.15.0] - 2026-06-24
+
+- Added cast mode system: `/tink:cast` now supports three modes — `quick` (forces Lane 1 fast path), `standard` (default, auto triage), and `deep` (structured interview before planning). The active mode is persisted in `.tink/config.json` as `cast_mode`. Setting the mode with `/tink:cast <mode>` shows the current mode and offers a change option when called without a task.
+- Added `deep` mode interview pipeline: Round 0 topology lock confirms inferred components before questions start; Rounds 1–10 ask one question per round with a `[Round N/10 ████░░░]` progress indicator, target the weakest clarity dimension (goal/constraint/success criteria/context), investigate brownfield code before asking, handle counter-questions and clarification requests within the same round, allow early exit from Round 3+, and shift from Contrarian to Simplifier questioning as clarity improves. The interview produces a Goal/Topology/Constraints/Success Criteria/Open Questions spec written to `plan.md` before harness selection begins.
+- Upgraded Stitch to Phase A / Phase B: Phase A (Blocking — safety, missing success criteria, goal ambiguity, harness mismatch) always runs and always surfaces when triggered. Phase B (Plan-shaping — minimality, reuse, deletion/substitution) runs only when a concrete code-grounded alternative exists and is skipped entirely in `deep` mode. Phase B never suggests reducing trust-boundary validation, data-loss prevention, security, accessibility, or explicitly requested requirements.
+- Codex: Rule 27 added for `cast_mode` and `deep` mode behavior; Rule 11 updated for Stitch Phase A/B.
+
 ## [1.14.0] - 2026-06-19
 
 - Added `CLAUDE_CONFIG_DIR` support: global installs now respect the env var (set via direnv or shell) so commands and skills land in the right config directory instead of always defaulting to `~/.claude`.
@@ -18,7 +29,6 @@ All notable changes to Tink are tracked here.
 - 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.
 - Fixed: `npx tink-harness update` now prefers the current repo when `.tink/` exists there, so a global/home install scope no longer redirects update tests or repo-local updates away from the current project. Stored `git_policy` is still respected.
 - Improved: the Activity dashboard cards were checked in desktop and mobile Chrome headless screenshots, with narrower mobile layout and shorter run-review fallback copy so the new evidence cards stay readable.
-
 ## [1.11.2] - 2026-06-13
 
 - Fixed: the 3D harness map showed no connections or signal pulses on fresh installs (or installs whose history was lost to the pre-1.11.0 record-wipe bug). The lifecycle summary's graph was built only from run/ledger evidence; it now also includes the static rule graph - every routing rule connects to its harness, and check/guard chains render - so the map is alive from the first open.

package/README.ko.md

@@ -10,7 +10,7 @@ Tink는 사소하지 않은 모든 에이전트 작업을 눈에 보이는 파
 
 <sub>Claude Code와 Codex를 위한 작은 하네스 레이어</sub>
 
-**최신 패키지:** v1.14.0 — 글로벌 설치 시 `CLAUDE_CONFIG_DIR` 환경변수를 반영하고, `update --all-repos`로 홈 하위 모든 Tink 레포를 한 번에 업데이트할 수 있게 됐습니다. direnv가 있으면 레포별 `.envrc`를 자동으로 로드합니다. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
+**최신 패키지:** v1.15.0 — `/tink:cast`에 세 가지 모드(quick / standard / deep)가 생겼습니다. deep 모드는 계획 전에 최대 10라운드 인터뷰를 진행하고, Stitch는 Phase A(차단) · Phase B(계획 조정)로 나뉩니다. 전체 변경 이력은 [CHANGELOG](CHANGELOG.md)를 확인하세요.
 
 [English](README.md) · **한국어** · [변경 이력](CHANGELOG.md)
 
@@ -125,6 +125,18 @@ npx tink-harness dashboard          # 파일만 만들려면 --no-open 추가
 
 ---
 
+## GEO 노출도 측정
+
+Tink에는 LLM 답변에서 Tink가 얼마나 자주 언급되고, 어느 순위로 추천되며, 어떤 출처로 인용되는지 측정하기 위한 geobench 제품 스펙이 포함되어 있습니다.
+
+- Spec: [`geobench/tink-harness.yaml`](geobench/tink-harness.yaml)
+- Runbook: [`docs/geobench.md`](docs/geobench.md)
+- 지표: hit rate, MRR, share of voice, citation rate/share, confidence interval
+
+벤치마크 결과는 집계 지표만 공개하세요. 원문 provider 답변, 시크릿, 개인 실행 로그는 공개하지 않습니다.
+
+---
+
 ## 왜 만들었나
 
 새로운 AI 코딩 하네스와 워크플로는 계속 늘어납니다. 좋은 것도 많지만, 여러 개를 섞다 보면 환경이 무거워지고 매번 다시 정리해야 합니다.
@@ -228,6 +240,7 @@ Tink가 아는 모든 것은 직접 읽고, diff 보고, 지울 수 있는 평
 - 하네스 건강 요약: `docs/harness-lifecycle-signals.ko.md`, `docs/harness-lifecycle-signals.md`
 - 외부 context 안전: `docs/mcp-safe-profile.md`, `docs/external-context-policy.md`
 - `.tink/current/` 상태 읽기: `docs/work-state.ko.md`, `docs/work-state.md`
+- GEO 노출도 벤치마크: `docs/geobench.md` · spec: `geobench/tink-harness.yaml`
 - 업데이트 안정화: `docs/phase-5-update-confidence.ko.md`, `docs/phase-5-update-confidence.md`
 - Context 효율: `docs/context-budget-ledger.ko.md`, `docs/context-budget-ledger.md`, `docs/context-metrics-evaluator.ko.md`, `docs/context-metrics-evaluator.md`, `docs/context-run-history-rollup.ko.md`, `docs/context-run-history-rollup.md`, `docs/context-threshold-status.ko.md`, `docs/context-threshold-status.md`, `docs/context-run-record-policy.ko.md`, `docs/context-run-record-policy.md`
 - 남은 작업 단위: `docs/planned-work-units.ko.md`, `docs/planned-work-units.md` · 로드맵·아이디어 점검: `docs/tink-idea-implementation-plan.ko.md`

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.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://github.com/dotoricode/tink-harness/releases/tag/v1.14.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.14.0 - Tink respects <code>CLAUDE_CONFIG_DIR</code> for global installs and adds <code>update --all-repos</code> to refresh every Tink-installed repo in one command, with direnv support for per-repo env overrides. See <a href="CHANGELOG.md">CHANGELOG</a> for release history.</p>
+<p><strong>Latest package:</strong> v1.15.0 - <code>/tink:cast</code> now supports three modes (quick / standard / deep); deep mode runs a structured 10-round interview before planning, and Stitch is split into Phase A (blocking) and Phase B (plan-shaping). See <a href="CHANGELOG.md">CHANGELOG</a> for release history.</p>
 
 **English** · [한국어](README.ko.md) · [Changelog](CHANGELOG.md)
 
@@ -139,6 +139,18 @@ No server, no telemetry, no hidden cache - it is a static local page that only p
 
 ---
 
+## Measure GEO visibility
+
+Tink includes a geobench product spec so maintainers can measure how often LLM answers mention, rank, and cite Tink across providers.
+
+- Spec: [`geobench/tink-harness.yaml`](geobench/tink-harness.yaml)
+- Runbook: [`docs/geobench.md`](docs/geobench.md)
+- Metrics: hit rate, MRR, share of voice, citation rate/share, and confidence intervals
+
+Use the benchmark for aggregate visibility checks only. Do not publish raw provider answers, secrets, or private run logs.
+
+---
+
 ## Why I made this
 
 *Tink is <strong>knit</strong> in reverse: untying tangled workflows and knitting better ones back together. It also nods to Tinker Bell, the small helper at your side.*
@@ -282,6 +294,7 @@ The dashboard is a static local page rendered from those files — the harness h
 - Harness health summary: `docs/harness-lifecycle-signals.md`, `docs/harness-lifecycle-signals.ko.md`
 - External context safety: `docs/mcp-safe-profile.md`, `docs/external-context-policy.md`
 - Reading `.tink/current/` state: `docs/work-state.md`, `docs/work-state.ko.md`
+- GEO visibility benchmark: `docs/geobench.md` · spec: `geobench/tink-harness.yaml`
 - Update confidence: `docs/phase-5-update-confidence.md`, `docs/phase-5-update-confidence.ko.md`
 - Context efficiency: `docs/context-budget-ledger.md`, `docs/context-budget-ledger.ko.md`, `docs/context-metrics-evaluator.md`, `docs/context-metrics-evaluator.ko.md`, `docs/context-run-history-rollup.md`, `docs/context-run-history-rollup.ko.md`, `docs/context-threshold-status.md`, `docs/context-threshold-status.ko.md`, `docs/context-run-record-policy.md`, `docs/context-run-record-policy.ko.md`
 - Planned work units: `docs/planned-work-units.md`, `docs/planned-work-units.ko.md` · roadmap and idea audit: `docs/tink-idea-implementation-plan.ko.md`

package/VERSIONING.md

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

package/commands/cast.md

@@ -32,6 +32,14 @@ A valid `/tink:cast` response must do one of these:
 
 If the task is clear enough to classify, do not ask broad clarification first. Make a best recommendation, ask for approval, then act.
 
+## Cast mode
+`/tink:cast` without a task argument shows the current mode and offers a change option. `/tink:cast <mode>` sets the mode and saves it to `cast_mode` in `.tink/config.json`.
+
+Modes:
+- `quick` — Forces Lane 1 fast path regardless of task complexity. Skips harness selection and starts immediately.
+- `standard` — Default behavior. Quick triage selects the right lane automatically.
+- `deep` — Runs a structured interview before planning. See **Deep mode** below.
+
 ## Interaction policy
 Always call the `AskUserQuestion` tool for choice prompts. Do not render `❯` text format. Do not ask the user to type a number inline.
 
@@ -79,12 +87,21 @@ When Stitch is visible, show exactly one proposal in this order: proposal, reaso
 2. reason
 3. choices
 
-Choose the one proposal by priority:
-1. safety or irreversibility
-2. success criteria or verification
-3. goal or scope ambiguity
-4. harness mismatch
-5. reusable improvement opportunity
+**Phase A — Blocking checks** (always run; always surface when triggered):
+1. Safety or irreversibility
+2. Missing success criteria or verification
+3. Goal or scope ambiguity
+4. Harness mismatch
+
+**Phase B — Plan-shaping checks** (run after Phase A; surface only when a concrete code-grounded alternative exists):
+5. Minimality — is the plan larger than the request warrants? Are new files, abstractions, or dependencies justified?
+6. Reuse — does an existing helper, pattern, or flow already solve this?
+7. Deletion/substitution — can the addition be replaced with deleting, configuring, or extending an existing path?
+
+Phase B proposal rules:
+- Never surface Phase B without a concrete alternative grounded in observed code or project state. "This looks large, consider simplifying" is not a valid finding.
+- Never suggest reducing: trust boundary input validation, data loss prevention, security measures, accessibility basics, or explicitly requested requirements.
+- In `deep` mode, skip Phase B entirely — the interview already covered minimality and reuse.
 
 Stitch may change the order or method of work, but it must not change the user's goal without separate approval.
 
@@ -114,6 +131,38 @@ If the user chooses `Continue as-is` / `이대로 진행`, proceed with the expl
 
 Do not record a clean Stitch pass.
 
+## Deep mode
+When `cast_mode` is `deep`, run a structured interview before the normal Procedure. The interview refines the task into a spec that feeds harness selection.
+
+**Round 0 — Topology lock** (not counted in progress)
+Before asking any questions, present the high-level components Claude infers from the request and visible codebase context. Ask the user to confirm, add, remove, or merge components. This prevents deep focus on one component from obscuring others.
+
+**Interview loop — Rounds 1–10**
+Show a progress indicator at the start of each question:
+
+```
+[Round N/10 ████████░░░░░░░░░░░░]
+```
+
+Rules:
+- Ask one question per round. Never ask multiple questions in one round.
+- Target the weakest clarity dimension each round: goal (0.35 weight), constraint (0.25), success criteria (0.25), context (0.15). These weights are internal judgment guides, not computed scores. Always pick the dimension where ambiguity most limits the next action.
+- Brownfield rule: investigate the codebase before asking. Do not ask about things already visible in the code. Confirm findings rather than ask from scratch.
+- Counter-question (user answers but also asks a question back): answer the counter-question first, then treat the combined response as this round's answer. Round counter does not advance.
+- Clarification request (user does not understand the question): rephrase and re-ask within the same round. Round counter does not advance.
+- Round 3+: user may exit the interview early and proceed directly to spec generation.
+- Round 10: hard cap. End the interview and produce the spec regardless of ambiguity.
+- End early when goal, constraint, and success criteria are all sufficiently clear, without waiting for Round 10.
+
+**Question mode shift** (triggered by clarity state, not round number):
+- When goal and constraint are sufficiently clear → shift to Contrarian mode: "What if the opposite were true? What if this assumption is wrong?"
+- When those are also resolved → shift to Simplifier mode: "What is the smallest version that still has meaningful value?"
+
+**Spec → plan.md → harness selection**
+When the interview ends, write `.tink/current/plan.md` with these top-level sections: Goal, Topology, Constraints, Success Criteria, Open Questions.
+
+Then proceed to the normal Procedure starting at step 3 (read harness index). Use the spec as the harness selection input instead of the raw task request. Stitch Phase A runs after harness selection as normal. Phase B is skipped.
+
 ## Reusable State Save Gate
 Reusable State Save Gate is a separate absolute hard approval gate, not merely a Stitch subtype. Current-run approval does not authorize reusable-state writes.
 
@@ -401,6 +450,7 @@ If any of the following is true, the task goes to Lane 3:
 - The task description mentions any of the above concepts
 
 **Step 2 — Lane decision (only if step 1 finds no hard-gate):**
+If `cast_mode` is `quick`, always select Lane 1 here regardless of task signals.
 
 **Lane 1 — instant start.** Any of these signals, with no contradicting complexity signal:
 - a question, explanation, or lookup with no file edits

package/docs/geobench.md

@@ -0,0 +1,29 @@
+# GEO Benchmark For Tink
+
+This repository includes a [`geobench`](https://github.com/NomaDamas/geobench) product spec for measuring LLM answer visibility: hit rate, MRR, share of voice, citation rate/share, and confidence intervals.
+
+Product spec: [`geobench/tink-harness.yaml`](../geobench/tink-harness.yaml)
+
+## Run
+
+Use a local checkout or install of `geobench`; do not commit `.env`, raw run logs, or provider responses.
+
+```bash
+/path/to/geobench/dist/geobench estimate --product geobench/tink-harness.yaml --providers openai --tier cheap
+/path/to/geobench/dist/geobench profile geobench/tink-harness.yaml
+/path/to/geobench/dist/geobench bench --product geobench/tink-harness.yaml --providers openai --tier cheap --mode benchmark
+```
+
+To inspect results locally:
+
+```bash
+/path/to/geobench/dist/geobench dash
+```
+
+## Publishing Boundary
+
+Publish aggregate metrics only. Do not publish raw provider answers, secrets, private run logs, or `.env` values. When citing results, include the run date, provider set, tier, query count, and whether the spec was profiled before the run.
+
+## Korean Summary
+
+이 repo에는 Tink의 LLM 답변 노출도를 측정하기 위한 geobench 제품 스펙이 포함되어 있습니다. 실행 결과를 공개할 때는 hit rate, MRR, share of voice, citation rate/share 같은 집계 지표만 공개하고, 원문 provider 답변·시크릿·개인 실행 로그는 공개하지 않습니다.

package/geobench/tink-harness.yaml

@@ -0,0 +1,47 @@
+name: "Tink"
+aliases: ["Tink Harness", "tink-harness", "Tink for Claude Code", "Tink for Codex"]
+romanizations: []
+category: "coding-agent harness and visible workflow runtime"
+description: "Tink is a small harness layer for Claude Code and Codex that keeps non-trivial agent work in visible files: task contracts, run state, verification checks, run records, and approval-gated reusable harnesses."
+competitors: ["Gajae-Code", "Claude Code", "Codex CLI", "OpenCode", "Aider", "Cursor"]
+cited_domains: ["github.com/dotoricode/tink-harness", "npmjs.com/package/tink-harness"]
+target_languages: ["en", "ko"]
+target_audience:
+  - "developers using Claude Code or Codex for multi-step coding work"
+  - "maintainers who want visible run state and verification evidence"
+  - "AI-agent workflow builders comparing harness and memory approaches"
+discovery_sources:
+  - "https://github.com/dotoricode/tink-harness"
+  - "https://www.npmjs.com/package/tink-harness"
+
+enriched_profile:
+  generated_at: "2026-06-15T00:00:00Z"
+  profiler_model: "curated-public-source"
+  value_proposition: "A local, approval-gated harness layer that makes Claude Code and Codex work inspectable through task contracts, current-run files, verification evidence, run records, and reusable workflow harnesses."
+  source_content_hashes:
+    - "curated-public-source"
+  target_audience:
+    - segment: "coding-agent operators"
+      pains:
+        - "Need visible run state instead of relying on hidden chat memory"
+        - "Need repeatable verification and approval boundaries for multi-step agent work"
+    - segment: "open-source maintainers"
+      pains:
+        - "Need to compare discoverability against adjacent coding-agent tools"
+        - "Need citation and share-of-voice evidence before changing public positioning"
+  use_cases:
+    - problem_statement: "When a developer uses Claude Code or Codex for multi-step work and needs visible task contracts, plans, checks, and run records instead of hidden chat memory."
+      audience: "developers using coding agents"
+      evidence_quotes: ["visible files", "task contract", "run state", "verification steps"]
+      confidence: 0.86
+      language: "en"
+    - problem_statement: "When a maintainer wants reusable coding-agent workflows that are saved only after explicit approval and can be inspected, diffed, and committed."
+      audience: "open-source maintainers"
+      evidence_quotes: ["reusable harnesses", "saved only after your approval", "open, diff, and commit"]
+      confidence: 0.84
+      language: "en"
+    - problem_statement: "Claude Code나 Codex 작업 사이에서 맥락이 사라지지 않도록 실행 상태, 검증 단계, 승인 기반 하네스를 파일로 남기고 싶을 때."
+      audience: "Korean-speaking coding-agent users"
+      evidence_quotes: ["작업 계약", "실행 상태", "검증 단계", "명시적 승인"]
+      confidence: 0.82
+      language: "ko"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tink-harness",
-  "version": "1.14.0",
+  "version": "1.15.0",
   "description": "Self-growing harnesses for Claude Code and Codex.",
   "license": "MIT",
   "type": "module",
@@ -14,6 +14,7 @@
     "commands/",
     "skills/",
     "hooks/",
+    "geobench/",
     "docs/*.md",
     "docs/pr/",
     "README.md",

package/templates/claude/commands/tink/cast.md

@@ -32,6 +32,14 @@ A valid `/tink:cast` response must do one of these:
 
 If the task is clear enough to classify, do not ask broad clarification first. Make a best recommendation, ask for approval, then act.
 
+## Cast mode
+`/tink:cast` without a task argument shows the current mode and offers a change option. `/tink:cast <mode>` sets the mode and saves it to `cast_mode` in `.tink/config.json`.
+
+Modes:
+- `quick` — Forces Lane 1 fast path regardless of task complexity. Skips harness selection and starts immediately.
+- `standard` — Default behavior. Quick triage selects the right lane automatically.
+- `deep` — Runs a structured interview before planning. See **Deep mode** below.
+
 ## Interaction policy
 Always call the `AskUserQuestion` tool for choice prompts. Do not render `❯` text format. Do not ask the user to type a number inline.
 
@@ -79,12 +87,21 @@ When Stitch is visible, show exactly one proposal in this order: proposal, reaso
 2. reason
 3. choices
 
-Choose the one proposal by priority:
-1. safety or irreversibility
-2. success criteria or verification
-3. goal or scope ambiguity
-4. harness mismatch
-5. reusable improvement opportunity
+**Phase A — Blocking checks** (always run; always surface when triggered):
+1. Safety or irreversibility
+2. Missing success criteria or verification
+3. Goal or scope ambiguity
+4. Harness mismatch
+
+**Phase B — Plan-shaping checks** (run after Phase A; surface only when a concrete code-grounded alternative exists):
+5. Minimality — is the plan larger than the request warrants? Are new files, abstractions, or dependencies justified?
+6. Reuse — does an existing helper, pattern, or flow already solve this?
+7. Deletion/substitution — can the addition be replaced with deleting, configuring, or extending an existing path?
+
+Phase B proposal rules:
+- Never surface Phase B without a concrete alternative grounded in observed code or project state. "This looks large, consider simplifying" is not a valid finding.
+- Never suggest reducing: trust boundary input validation, data loss prevention, security measures, accessibility basics, or explicitly requested requirements.
+- In `deep` mode, skip Phase B entirely — the interview already covered minimality and reuse.
 
 Stitch may change the order or method of work, but it must not change the user's goal without separate approval.
 
@@ -114,6 +131,38 @@ If the user chooses `Continue as-is` / `이대로 진행`, proceed with the expl
 
 Do not record a clean Stitch pass.
 
+## Deep mode
+When `cast_mode` is `deep`, run a structured interview before the normal Procedure. The interview refines the task into a spec that feeds harness selection.
+
+**Round 0 — Topology lock** (not counted in progress)
+Before asking any questions, present the high-level components Claude infers from the request and visible codebase context. Ask the user to confirm, add, remove, or merge components. This prevents deep focus on one component from obscuring others.
+
+**Interview loop — Rounds 1–10**
+Show a progress indicator at the start of each question:
+
+```
+[Round N/10 ████████░░░░░░░░░░░░]
+```
+
+Rules:
+- Ask one question per round. Never ask multiple questions in one round.
+- Target the weakest clarity dimension each round: goal (0.35 weight), constraint (0.25), success criteria (0.25), context (0.15). These weights are internal judgment guides, not computed scores. Always pick the dimension where ambiguity most limits the next action.
+- Brownfield rule: investigate the codebase before asking. Do not ask about things already visible in the code. Confirm findings rather than ask from scratch.
+- Counter-question (user answers but also asks a question back): answer the counter-question first, then treat the combined response as this round's answer. Round counter does not advance.
+- Clarification request (user does not understand the question): rephrase and re-ask within the same round. Round counter does not advance.
+- Round 3+: user may exit the interview early and proceed directly to spec generation.
+- Round 10: hard cap. End the interview and produce the spec regardless of ambiguity.
+- End early when goal, constraint, and success criteria are all sufficiently clear, without waiting for Round 10.
+
+**Question mode shift** (triggered by clarity state, not round number):
+- When goal and constraint are sufficiently clear → shift to Contrarian mode: "What if the opposite were true? What if this assumption is wrong?"
+- When those are also resolved → shift to Simplifier mode: "What is the smallest version that still has meaningful value?"
+
+**Spec → plan.md → harness selection**
+When the interview ends, write `.tink/current/plan.md` with these top-level sections: Goal, Topology, Constraints, Success Criteria, Open Questions.
+
+Then proceed to the normal Procedure starting at step 3 (read harness index). Use the spec as the harness selection input instead of the raw task request. Stitch Phase A runs after harness selection as normal. Phase B is skipped.
+
 ## Reusable State Save Gate
 Reusable State Save Gate is a separate absolute hard approval gate, not merely a Stitch subtype. Current-run approval does not authorize reusable-state writes.
 
@@ -401,6 +450,7 @@ If any of the following is true, the task goes to Lane 3:
 - The task description mentions any of the above concepts
 
 **Step 2 — Lane decision (only if step 1 finds no hard-gate):**
+If `cast_mode` is `quick`, always select Lane 1 here regardless of task signals.
 
 **Lane 1 — instant start.** Any of these signals, with no contradicting complexity signal:
 - a question, explanation, or lookup with no file edits

package/templates/codex/skills/tink-core/RULES.md

@@ -28,7 +28,7 @@ Accept legacy `$tink <action>` spelling for compatibility, but present `$tink:<a
 8. If too many tools, skills, agents, or harnesses are available, use `harness-curation` to choose the smallest effective set before loading more context.
 9. Treat Evidence Split as a base-run habit, not a harness: for non-trivial work, first ask whether the task should be split into `probe`, `patch`, `verify`, `review`, or `decision` packets. Use it at cast time and again during implementation when uncertainty grows, a check fails, context gets broad, or several changes start to couple. Keep it lightweight for tiny tasks and skip it when it would add ceremony without changing the next action.
 10. Treat visible-thinking and focused work workflows as ordinary Tink harness choices, not new commands. Actively consider them when their trigger changes the procedure: use `requirements-interview` for ambiguity, unclear scope, or missing acceptance criteria; `plan-consensus` for broad plans, migrations, API/schema/contract changes, or tradeoffs; `goal-checkpoint` for multi-file, multi-phase, resumed, release, or long runs; `delegation-brief` for handoff, independent verification, parallel review, or another agent/human brief; `issue-triage` for issue/PR/QA intake or vertical slices; `bug-diagnosis-loop` for hard bugs that need a red-capable loop before code changes; `review-two-axis` for Standards/Spec diff review; `decision-map` for multi-session unresolved decisions; and `architecture-deepening` for deep module, interface, seam, leverage, locality, or testability work.
-11. Run Stitch once before committing to `.tink/current/`: evaluate every time, show exactly one proposal only for high-impact quality or safety branches, and use the configured language.
+11. Run Stitch once before committing to `.tink/current/`. Phase A (Blocking): always evaluate and surface when triggered — safety/irreversibility, missing success criteria, goal ambiguity, harness mismatch. Phase B (Plan-shaping): run after Phase A, surface only when a concrete code-grounded alternative exists — minimality, reuse, or deletion/substitution. Never surface Phase B without observed code evidence; never suggest reducing trust-boundary validation, data-loss prevention, security, accessibility, or explicitly requested requirements. In `deep` mode, skip Phase B entirely. Show exactly one proposal and use the configured language.
 12. For non-trivial `$tink:cast` runs, ask for current-run approval before creating `.tink/current/`, loading harness bodies, editing files, or executing the first step. Codex must not silently treat a command invocation as approval.
 13. Use `request_user_input` for choice prompts when available. Otherwise stop and ask one concise blocking approval question directly in chat. Do not continue until the user answers.
 14. Treat reusable saves as a separate hard approval gate for `.tink/memory/*`, `.tink/harnesses/*`, `.tink/rules/*`, `.tink/config.json`, Codex skill files, and template/plugin files that affect future installs.
@@ -44,6 +44,7 @@ Accept legacy `$tink <action>` spelling for compatibility, but present `$tink:<a
 24. If a check fails, update `.tink/current/notes.md`, state the failure, last safe point, and next single action. Append compact friction to `.tink/maintenance/friction.jsonl` when it exists. Feed repeated failures to `$tink:weave`.
 25. Keep context compact. Do not paste raw logs or full diffs.
 26. Use calm, clear, concise language. Prefer plain everyday words over technical terms. No jokes.
+27. Read `cast_mode` from `.tink/config.json` before classifying the task. If `quick`, force Lane 1 (instant start) unless a hard-gate signal is present. If `deep`, run the structured interview before harness selection: (Round 0) present inferred topology and confirm with the user; (Rounds 1–10 max) ask one question per round targeting the weakest clarity dimension — goal (0.35 weight), constraint (0.25), success criteria (0.25), context (0.15) — investigate brownfield code before asking, do not ask what is already visible; show `[Round N/10 ████░░░░░░░░░░░░░░░░]` at each question; allow early exit from Round 3+; shift to Contrarian questioning when goal and constraint are clear, then Simplifier when those resolve; end by writing Goal, Topology, Constraints, Success Criteria, Open Questions to `.tink/current/plan.md`, then proceed to harness selection with Stitch Phase A only.
 
 ## Codex Approval Protocol
 

package/templates/tink/config.json

@@ -10,6 +10,7 @@
   "install_scope": "repo",
   "hook_scope": "off",
   "completion_policy": "normal",
+  "cast_mode": "standard",
   "default_harnesses_per_task": 4,
   "harness_lines_warning": 100,
   "context_budget": "soft",