verify

/tink:verify

Run the verification commands and manual checks listed in .tink/current/contract.json.

Use this when a Tink run needs evidence before it can be called done, especially before release, publish, deploy, public PR, or broad workflow changes.

Purpose

Tink should not rely on "I think it passed." It should run the checks named in the current contract, record what happened, and send failures back into weave as improvement signals.

Inputs

Read these files if present:

• .tink/current/contract.json
• .tink/current/checks.md
• .tink/current/plan.md
• .tink/current/notes.md
• .tink/current/verification.json
• .tink/current/evidence.md
• .tink/schemas/verification.schema.json
• .tink/maintenance/weave-queue.json
• .tink/maintenance/ledger.jsonl
• .tink/maintenance/friction.jsonl

If contract.json is missing, do not invent one silently. Summarize the missing contract and ask whether to create it from the current run files.

Contract fields

The command expects this shape:

{
  "task_type": "release",
  "risk": ["public_publish"],
  "success_conditions": [],
  "forbidden": [],
  "verification": {
    "commands": [],
    "manual_checks": []
  },
  "evidence": {
    "required": []
  }
}

Unknown fields are allowed. Missing required fields should be reported as contract gaps.

Verify runner contract

Use one runner model for Claude Code /tink:verify and Codex $tink:verify.

The runner has four phases:

1. Contract Coverage: map the semantic contract before commands can create a false sense of completion.
2. Plan: read the contract, normalize checks into a short runner plan, and classify each check as command or manual.
3. Run: execute safe command checks and inspect manual checks.
4. Record: write .tink/current/verification.json, write .tink/current/evidence.md, update notes, and append maintenance signals only when their files already exist.

Phase 0 — Contract Coverage

Before planning command checks:

• For every success_conditions[] item, assign SC-1, SC-2, and so on, then record whether it has a plan step, implementation result, verification item, and evidence. Use proven, missing_plan, missing_implementation, missing_check, or missing_evidence.
• For every forbidden[] item, assign F-1, F-2, and so on, then record proven_absent, violated, or not_proven with diff or review evidence.
• Review intent.open_questions[]; unresolved blocking questions must remain visible and cannot be treated as agent decisions.
• Review intent.assumptions[]; list every assumption whose status is not approved and that affected implementation.
• Review approval; record the revision as approved, unapproved, or legacy. A contract without the optional Understanding fields remains a supported legacy contract.