chore(bindings): republish 0.19.1 with the deployed 0.19 ABI (0.19.0 was stale)

[drewstone]

The crates.io tnt-core-bindings 0.19.0 is stale vs the deployed 0.19 contract and needs a corrective republish before operators can install from published artifacts instead of git patches.

Why

• 0.19.0 was published 2026-07-07 22:24.
• feat(payments): EventDriven per-job billing in the service's settlement asset (native or ERC20) #209 (EventDriven per-job billing in the service settlement asset) merged 2026-07-09 04:39 and regenerated the ABI (i_tangle.rs +879, i_tangle_full.rs +921, …).
• So published 0.19.0 ships an intermediate 0.19 ABI that was never deployed — its i_tangle.rs differs from main by ~900 lines (diffed the extracted crate to confirm).
• Consumers pinning 0.19.0 — including blueprint-sdk (tnt-core-bindings = "0.19") — build against selectors that don't match the live 0.19 deployment. The operator worked on Tempo only because it consumed bindings via a git-pin override, which masked the staleness.

Change

• bindings/Cargo.toml: 0.19.0 → 0.19.1 (+ Cargo.lock). Carries main's current, deployed-matching ABI, and folds in the MSRV-declaration fix from fix(bindings): declare the real MSRV (rust-version 1.81 → 1.91) #211.
• CHANGELOG documents what 0.19.0 was missing (the feat(payments): EventDriven per-job billing in the service's settlement asset (native or ERC20) #209 payments ABI).

Verification

cargo publish --dry-run -p tnt-core-bindings --locked → packages 36 files, compiles clean in isolation on Rust 1.91; upload aborted only by --dry-run.

After merge

Publish 0.19.1 to crates.io, then bump blueprint-sdk's tnt-core-bindings dep to 0.19.1 and release it (unblocks the queued blueprint chore: release #1470) so operators install the aligned binary.

[tangletools]

✅ Auto-approved drewstone PR — 4895ce65

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-24T21:28:25Z}

[tangletools]

✅ Auto-approved drewstone PR — 4895ce65

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-24T21:28:28Z}

[tangletools]

🟡 Value Audit — sound-with-nits

Verdict	sound-with-nits
Concerns	1 (1 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	88.0s (2 bridge agents)
Total	88.0s

💰 Value — sound-with-nits

A corrective republish that cuts 0.19.1 so crates.io's tnt-core-bindings matches the deployed 0.19 contract ABI (0.19.0 shipped a stale intermediate); clean release-cut in the repo's grain, one docs-maintenance nit.

• What it does: Bumps bindings/Cargo.toml + Cargo.lock from 0.19.0 → 0.19.1 and adds a CHANGELOG entry documenting the corrective republish. No .rs source changes — the deployed-matching ABI already landed in #209 (i_tangle*.rs, +2698 lines) and the MSRV-declaration fix in #211; this commit is purely the version string + release notes that let cargo publish push a corrective 0.19.1 to crates.io (the bindings-v0
• Goals it achieves: Make a tnt-core-bindings = "0.19" caret dep resolve to an ABI that matches the LIVE 0.19 deployment. Today, blueprint-sdk and any consumer pinning 0.19 build against selectors ~900 lines divergent from the deployed contract (#209 merged 2 days AFTER 0.19.0 was published); the operator only works because it consumes bindings via a git-pin override that masks the staleness. After this, operators c
• Assessment: Good change on its merits. It achieves a real, valuable goal (kill the stale-publish footgun) using the repo's established release mechanism — CLAUDE.md documents cargo xtask bump-version / cargo xtask publish, and a republish is exactly that path. Hand-editing the CHANGELOG instead of running the xtask is the right call here: the xtask writes a generic 'Updated bindings from TNT Core contract
• Better / existing approach: none — this is the right approach. The existing xtask bump-version/publish workflow is the correct primitive and this PR follows it (manually, to allow the custom CHANGELOG body). Verified no existing equivalent to reuse: the regeneration is gen-bindings (#209 ran it), the release cut is xtask publish, and the CHANGELOG detail is necessarily bespoke for a corrective republish.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

Corrective republish that is verifiably needed and correct: the 0.19.0 tag predates #209 by ~30h, and the current crate source carries the deployed settlement-asset ABI; the bump wires into the existing tag-triggered crates.io publish flow and is consumed by blueprint-sdk.

• Integration: Reachable as intended. The version in bindings/Cargo.toml:3 (matched in Cargo.lock:3811) is the input the publish-bindings job consumes when a bindings-v* tag fires (.github/workflows/release.yml:97). Verified the staleness premise: tag bindings-v0.19.0 sits on commit 829a2cc (2026-07-07 22:21 UTC, PR #205), while #209 (settlement-asset billing) merged at ad527af (2026-07-09 04:39 UTC) ~30h
• Fit with existing patterns: Follows the established release pattern exactly. Every prior cut (0.4.x–0.19.0) used the identical Cargo.toml version bump + CHANGELOG entry + bindings-v* tag flow; this introduces no new mechanism and competes with nothing. The include list in bindings/Cargo.toml:14 already packages src/abi/TNT_CORE_VERSION/Cargo.toml/README/LICENSE, so the dry-run '36 files' claim is plausible.
• Real-world viability: A version bump + changelog — there is no runtime behavior to stress. The load-bearing correctness property (crate ABI == deployed contract ABI) holds: the settlement-asset selectors generated from #209 are present in the source that will ship as 0.19.1, which is precisely what 0.19.0 was missing. MSRV declaration (rust-version = 1.91, folding in #211) is consistent with the locked dep graph per th
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

💰 Value Audit

🟡 CHANGELOG compare-link footer is out of sync; [0.19.1] header has no link definition [maintenance] ``

bindings/CHANGELOG.md:10 adds a ## [0.19.1] - 2026-07-24 header, but the link-reference footer (lines 888-929) has no [0.19.1]: entry, and [Unreleased] at line 888 still points at bindings-v0.17.1...HEAD (stale since 0.18.0). This is pre-existing — 0.18.0 and 0.19.0 also lack defs — but this PR extends the gap. The hand-edit bypassed the xtask, which would have auto-fixed both (xtask/src/main.rs:407-421 rewrites [Unreleased] and appends the new version link). Cosmetic only: the headers r

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260724T213020Z}