Hello — we've been running a fork (jerryfane/tendwire) in production and have a correctness fix you may want. Writing it up as an issue rather than a PR because a straight merge conflicts in 14 places, and a 29-commit conflicted PR isn't reviewable by anyone.
The defect
command.submit records terminal_accepted once the instruction bytes reach the terminal. That is not the same as the agent receiving it. On a busy pane the text lands in the composer and sits there — the agent never reads it, no turn begins, and the request is marked handled.
It is not a rare race. Measured on our box:
- 2026-07-27 — a coordinator lane dispatched review instructions to four panes across an entire evening. None submitted. All four sat as unsent composer drafts while the lane looked idle, and three diagnostic sweeps went into deciding whether it was capacity or routing.
- 2026-07-30 — eight measured strandings in one day.
- A subsequent send replaces the composer, silently destroying the stranded draft. The text had no other copy.
The failure is silent in the direction that matters: the submitter believes it delivered.
What we changed
Submission verdicts, with the rule that an unverifiable submission is never reported as handled and is never auto-retried — an ambiguous submission may well have landed, and a replay submits twice. (jerryfane/herdr#16 is still open, so there is no attempt id that would make a replay safe.)
You already have terminal_uncertain and request_state_uncertain, so the vocabulary largely lines up — we added submission_verdict on top. Two rounds of adversarial review also caught, and fixed, an expired verification ledger leaving a receipt reading "queued for the next agent turn boundary" forever when the truth was terminal uncertainty; and a queued-request replay invoking host-wide settlement, where 40 open components produced 40 settlements from one sweep instead of 1.
Our issue with the full mechanism: jerryfane/tendwire#57.
Why a merge conflicts
Not because either side is wrong. Your 6975c51 reworked the herdr 0.7.5 backend layer including command_submission.py; our work changed command_submission.py and store/sqlite.py for submission verification. Same files, different reasons. tests/test_turn_submissions.py is also deleted on your side and modified on ours, so even a single-commit cherry-pick hits a modify/delete.
We checked before writing this — none of your changes are superseded by ours.
Two of yours we should take
b4caf91 — bound stable-owner turn reconciliation. Avoiding per-refresh hydration of every retained turn is exactly right; we don't have it.1aca3d0 — the byte-bounded sanitize cache. Also absent from ours.
We measured our own snapshot at 0.30–0.38 s against 5,612 turns, so we aren't feeling the cost yet — but the database is already 1.9 GB and these are the fixes that matter at 10×.
Offer
If you want the submission fix, we'll rebuild it against your main as a clean, self-contained PR with its tests re-sited — no conflicts, reviewable on its own merits. Say the word and we'll do the work; equally happy if you'd rather implement it your own way now that the failure mode is written down.
Hello — we've been running a fork (
jerryfane/tendwire) in production and have a correctness fix you may want. Writing it up as an issue rather than a PR because a straight merge conflicts in 14 places, and a 29-commit conflicted PR isn't reviewable by anyone.The defect
command.submitrecordsterminal_acceptedonce the instruction bytes reach the terminal. That is not the same as the agent receiving it. On a busy pane the text lands in the composer and sits there — the agent never reads it, no turn begins, and the request is marked handled.It is not a rare race. Measured on our box:
The failure is silent in the direction that matters: the submitter believes it delivered.
What we changed
Submission verdicts, with the rule that an unverifiable submission is never reported as handled and is never auto-retried — an ambiguous submission may well have landed, and a replay submits twice. (
jerryfane/herdr#16is still open, so there is no attempt id that would make a replay safe.)You already have
terminal_uncertainandrequest_state_uncertain, so the vocabulary largely lines up — we addedsubmission_verdicton top. Two rounds of adversarial review also caught, and fixed, an expired verification ledger leaving a receipt reading "queued for the next agent turn boundary" forever when the truth was terminal uncertainty; and a queued-request replay invoking host-wide settlement, where 40 open components produced 40 settlements from one sweep instead of 1.Our issue with the full mechanism:
jerryfane/tendwire#57.Why a merge conflicts
Not because either side is wrong. Your
6975c51reworked the herdr 0.7.5 backend layer includingcommand_submission.py; our work changedcommand_submission.pyandstore/sqlite.pyfor submission verification. Same files, different reasons.tests/test_turn_submissions.pyis also deleted on your side and modified on ours, so even a single-commit cherry-pick hits a modify/delete.We checked before writing this — none of your changes are superseded by ours.
Two of yours we should take
b4caf91— bound stable-owner turn reconciliation. Avoiding per-refresh hydration of every retained turn is exactly right; we don't have it.1aca3d0— the byte-bounded sanitize cache. Also absent from ours.We measured our own snapshot at 0.30–0.38 s against 5,612 turns, so we aren't feeling the cost yet — but the database is already 1.9 GB and these are the fixes that matter at 10×.
Offer
If you want the submission fix, we'll rebuild it against your
mainas a clean, self-contained PR with its tests re-sited — no conflicts, reviewable on its own merits. Say the word and we'll do the work; equally happy if you'd rather implement it your own way now that the failure mode is written down.