tink-harness 1.2.1 → 1.2.2

package/README.md

@@ -6,27 +6,27 @@
   <strong>Tink</strong>
 </h1>
 
-<p>A small harness layer for Claude Code and Codex</p>
-
-<p>
-  Tink helps Claude Code or Codex choose the right harness, keep run state visible, and improve the harness set as you work.
-</p>
+<p>A small harness layer for Claude Code and Codex</p>
+
+<p>
+  Tink helps Claude Code or Codex choose the right harness, keep run state visible, and improve the harness set as you work.
+</p>
 
 <p>
   <em>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.</em>
 </p>
 
-<p>
-  <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.2.1"><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.2.1 — focused Codex skills, visible context artifacts, portable verification, and safer external context.</p>
-
-**English** · [한국어](README.ko.md)
+<p>
+  <a href="https://github.com/dotoricode/tink-harness/releases/tag/v1.2.2"><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.2.2 — update confidence, planned work units, evidence details, and memory policy scaffolding.</p>
+
+**English** · [한국어](README.ko.md)
 
 ---
 
@@ -64,21 +64,21 @@ Claude Code plugin install:
 /tink:setup
 ```
 
-Standalone compatibility installer:
-
-```bash
-npx tink-harness@latest install
-```
-
-Standalone installer auto-detects `LANG` (English fallback). Pass `--lang=en|ko|zh` to override.
-
-Codex skill install:
-
-```bash
-npx tink-harness@latest install
-```
-
-During install, select `Codex` when asked which agent surface to install. You can select both `Claude Code` and `Codex` in the same run. Then open Codex and use `$tink:cast <task>`.
+Standalone compatibility installer:
+
+```bash
+npx tink-harness@latest install
+```
+
+Standalone installer auto-detects `LANG` (English fallback). Pass `--lang=en|ko|zh` to override.
+
+Codex skill install:
+
+```bash
+npx tink-harness@latest install
+```
+
+During install, select `Codex` when asked which agent surface to install. You can select both `Claude Code` and `Codex` in the same run. Then open Codex and use `$tink:cast <task>`.
 
 ## Update
 
@@ -106,53 +106,57 @@ If update does not find the latest version, uninstall and install again:
 /plugin install tink@tink-harness
 ```
 
-To update an existing standalone install (keeps user-modified files):
-
-```bash
-npx tink-harness@latest update
-```
-
-For Codex:
-
-```bash
-npx tink-harness@latest update
-```
-
-During update, select the installed agent surface you want to refresh.
-
-## What's new in 1.2.0
-
-This release makes Tink work as one harness layer across Claude Code and Codex.
-
-- Codex now installs focused `$tink:*` action skills instead of one broad visible `tink` skill, so the picker shows commands like `$tink:cast` and `$tink:verify` cleanly.
-- Non-trivial runs now create context artifacts: `context-pack.md`, `context-map.json`, and `excluded-context.md`.
-- Repo Signals help `/tink:cast` choose relevant tests, schemas, sync partners, and verification hints without adding a new `tink index` command.
-- `/tink:verify` and `$tink:verify` share one portable Verify Runner model and write compact evidence to `.tink/current/verification.json`.
-- External context now follows the MCP Safe Profile: include only the smallest useful source handle, mark confidence and sensitivity, exclude unsafe context visibly, and connect important claims to verification.
-
-## Commands
-
-Tink keeps the command surface small.
-
-Tink is plugin-first in Claude Code. Commands are namespaced under `tink`, so the public surface stays `/tink:*` and avoids generic command conflicts. In Codex, Tink installs matching `$tink:*` skills for autocomplete: `$tink:cast`, `$tink:verify`, `$tink:list`, `$tink:frog`, `$tink:weave`, `$tink:setup`, and `$tink:update`. Legacy `$tink cast` style prompts still work, but `$tink:*` is the preferred spelling.
-
-### `/tink:cast` / `$tink:cast`
+To update an existing standalone install (keeps user-modified files):
+
+```bash
+npx tink-harness@latest update
+```
+
+For Codex:
+
+```bash
+npx tink-harness@latest update
+```
+
+During update, select the installed agent surface you want to refresh.
+
+To quickly verify the updated install, see `docs/update-verification-recipe.md` or `docs/update-verification-recipe.ko.md`.
+
+If an update looks stale or incomplete, see `docs/update-troubleshooting.md` or `docs/update-troubleshooting.ko.md`.
+
+## What's new in 1.2.0
+
+This release makes Tink work as one harness layer across Claude Code and Codex.
+
+- Codex now installs focused `$tink:*` action skills instead of one broad visible `tink` skill, so the picker shows commands like `$tink:cast` and `$tink:verify` cleanly.
+- Non-trivial runs now create context artifacts: `context-pack.md`, `context-map.json`, and `excluded-context.md`.
+- Repo Signals and Context Graph Lite help `/tink:cast` and `$tink:cast` choose relevant tests, schemas, sync partners, and verification hints without adding a new `tink index` command.
+- `/tink:verify` and `$tink:verify` share one portable Verify Runner model and write compact evidence to `.tink/current/verification.json`.
+- External context now follows the MCP Safe Profile: include only the smallest useful source handle, mark confidence and sensitivity, exclude unsafe context visibly, and connect important claims to verification.
+
+## Commands
+
+Tink keeps the command surface small.
+
+Tink is plugin-first in Claude Code. Commands are namespaced under `tink`, so the public surface stays `/tink:*` and avoids generic command conflicts. In Codex, Tink installs matching `$tink:*` skills for autocomplete: `$tink:cast`, `$tink:verify`, `$tink:list`, `$tink:frog`, `$tink:weave`, `$tink:setup`, and `$tink:update`. Legacy `$tink cast` style prompts still work, but `$tink:*` is the preferred spelling.
+
+### `/tink:cast` / `$tink:cast`
 
 **cast** means to place the first loops on the needle (코잡기, Cast on). In knitting, casting on is the very first step — it sets the foundation for everything that follows.
 
-In Tink, `cast` is the main path. It reads the task, chooses or drafts the right harness, runs a quick internal sanity check, creates `.tink/current/` as the visible workbench, and starts the first safe step after approval.
-
-Use it when the task is more than a quick answer.
-
-### `/tink:verify` / `$tink:verify`
-
-`verify` runs the checks promised in `.tink/current/contract.json`.
-
-Tink now writes a small task contract for non-trivial runs: what kind of work this is, what must be true when it is done, what is forbidden, and which commands or manual checks prove it. `/tink:verify` uses that contract instead of relying on a vague "looks done" claim.
-
-Use it before release, publish, deploy, public PR, or any task where evidence matters.
-
-### `/tink:frog` / `$tink:frog`
+In Tink, `cast` is the main path. It reads the task, chooses or drafts the right harness, runs a quick internal sanity check, creates `.tink/current/` as the visible workbench, and starts the first safe step after approval.
+
+Use it when the task is more than a quick answer.
+
+### `/tink:verify` / `$tink:verify`
+
+`verify` runs the checks promised in `.tink/current/contract.json`.
+
+Tink now writes a small task contract for non-trivial runs: what kind of work this is, what must be true when it is done, what is forbidden, and which commands or manual checks prove it. `/tink:verify` uses that contract instead of relying on a vague "looks done" claim.
+
+Use it before release, publish, deploy, public PR, or any task where evidence matters.
+
+### `/tink:frog` / `$tink:frog`
 
 **frog** means to rip out stitches (풀시오, Frogging). In knitting, frogging unravels rows that went wrong — the name comes from the sound of pulling out yarn, "rip it, rip it."
 
@@ -160,7 +164,7 @@ In Tink, `frog` looks for harnesses that are unused, overlapping, too broad, or
 
 Use it when the harness set starts to feel noisy.
 
-### `/tink:weave` / `$tink:weave`
+### `/tink:weave` / `$tink:weave`
 
 **weave** means to weave in the ends (실오라기 정리, Weave in). In knitting, weaving in secures the loose threads left after finishing, giving the work its final shape.
 
@@ -170,27 +174,27 @@ Use it when a harness is useful but slightly wrong.
 
 ### Other commands
 
-- `/tink:setup` / `$tink:setup`: choose language, install scope, git tracking, and hook policy.
-- `/tink:list` / `$tink:list`: inspect available harnesses and recent usage signals.
-- `/tink:update` / `$tink:update`: detect install source and show the safe update command.
+- `/tink:setup` / `$tink:setup`: choose language, install scope, git tracking, and hook policy.
+- `/tink:list` / `$tink:list`: inspect available harnesses and recent usage signals.
+- `/tink:update` / `$tink:update`: detect install source and show the safe update command.
 
 ## How it works
 
 Tink uses files you can inspect:
 
-- `.tink/harnesses/`: reusable task harnesses
-- `.tink/rules/`: a small rule graph that chooses only relevant harnesses, checks, and opt-in guard candidates
-- `.tink/schemas/`: structured file schemas, including the current run contract
-- `.tink/current/`: the current run state
-- `.tink/runs/`: compact records from finished, blocked, canceled, or replaced runs
-- `.tink/maintenance/`: verification, friction, and weave signals that help repeated failures become approved improvements
-- `.tink/memory/`: approved mistakes, preferences, and lessons
-
-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`. External context safety is described in `docs/mcp-safe-profile.md`.
-
-The important rule is approval.
+- `.tink/harnesses/`: reusable task harnesses
+- `.tink/rules/`: a small rule graph that chooses only relevant harnesses, checks, and opt-in guard candidates
+- `.tink/schemas/`: structured file schemas, including the current run contract
+- `.tink/current/`: the current run state
+- `.tink/runs/`: compact records from finished, blocked, canceled, or replaced runs
+- `.tink/maintenance/`: verification, friction, and weave signals that help repeated failures become approved improvements
+- `.tink/memory/`: approved mistakes, preferences, and lessons
+
+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`.
+
+The important rule is approval.
 
 Tink may suggest a harness, a memory entry, a cleanup, or an improvement. Before each run is committed, Tink runs one quick sanity check and surfaces a proposal only when something important is at stake. Low-risk steps let you continue with recorded assumptions; irreversible or externally visible actions (publish, deploy, deletions, broad changes) require explicit approval. Saving anything reusable — a new harness, a memory entry, a `.claude/` workflow file — always needs its own separate approval; approving the current run does not authorize saves that future installs would inherit.
 

package/VERSIONING.md

@@ -1,6 +1,6 @@
 # Versioning
 
-Current version: `1.2.1`
+Current version: `1.2.2`
 
 Tink follows semver from `1.0.0` onward.
 
@@ -19,7 +19,7 @@ Claude Code uses `.claude-plugin/plugin.json` to decide whether plugin users can
 
 Use semver.
 
-- Patch, for example `1.1.2`: docs, tests, installer polish, command wording, small template fixes, non-breaking maintenance structure. Prefer a patch release for each user-visible improvement instead of letting many small changes pile up in `[Unreleased]`.
+- Patch, for example `1.1.2`: docs, tests, installer polish, command wording, small template fixes, non-breaking maintenance structure. Prefer a patch release for each user-visible improvement instead of letting many small changes pile up in `[Unreleased]`.
 - Minor, for example `1.1.0`: new command behavior, meaningful installer flow change, new persisted state shape, or anything existing users should deliberately notice — all backwards compatible.
 - Major, for example `2.0.0`: breaking change to the command surface, plugin contract, persisted state shape, or installer flow that existing users must migrate for.