mesh/repo-check head bb5a342863ee merged into trunk 9c166398f204 — pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (go), merge-…
The review of mesh-controller #304: a proposal of more than three keys showed only the names of the rest,
and its Details could carry no value, so Approve bound values the operator never saw. The router now
shows an ask's WholeDetails in the note in place of its Details on a kind that proves who answers, held
to the secret rule alone, and refuses an ask whose whole details carry a secret's shape. Telegram keeps
the note whole when a message is too long, cutting the body first and saying so, and escapes the note
as every other part. SDK at mesh-sdk f474544.
The operator would not read the Telegram ask for ADR 0343: thirty plain lines, every clause on one, no bold,
no summary. A settings proposal was the same wall of text, its values masked so the approval was blind.
- messenger: an ask's message is the asker's headline and explanation alone; who asked and when, what each
answer does, the expiry, where else it is answered and the asker's Details travel as the message's note
(asks.Message.Note). Answered, the message is one line, "You chose Approve at 16:06 on Telegram ·
<headline>". An explanation that does not read at a glance (asks.Glance) is shown and logged. On a kind
that proves who answers, an ask's values are shown whole (asks.Ask.Whole), held to the secret rule alone
(from the earlier work on issue 383, #178).
- telegram: every message in HTML, never reworded: the title bold, a key line monospace, the note apart in
a collapsed blockquote; markup escaped. A tap is compared by its words, whitespace aside, and a message
shown before is still compared by the digest it was kept under.
- desk-channel: the note follows the body.
- mesh-knowledge: a record that needs the operator carries a brief (headline, summary, at most three
points), the 30th per-record rule; its ask shows the brief and never the clauses. An ask made before is
composed again as it was asked (form), so its warrant still holds.
- claude-code: an instructions proposal's explanation is one summary line (the proposer's, or the
module's), its text in the Details; a question's context is at most 300 characters and its recommendation
one point. Older proposals and questions keep their form.
The SDK is pinned at mesh-sdk 9588871 (fix/639-an-ask-reads-at-a-glance), which adds Message.Note and
asks.Glance.
mesh/merge-gate pass: builds desk-channel, messenger, telegram → novox; no bus step; every machine composes with the change as it did without (4 of 4 compo…
- A comeback before the clearing was said rings when it is urgent now, and
says the reminder or escalation that was waiting when it cleared.
- Comebacks never said are counted apart, so "again, Nth time" counts only
what the operator was told; an urgent comeback after a said clearing rings
again in place of its message.
- telegram sends the new message before deleting the earlier one, so a
failed send leaves the operator a message.
- desk-channel keeps a machine's notification on record when its replace
fails, and says a message shown nowhere as failed.
- A store that cannot be read sends a new message instead of holding it.
- Tests for each, and for a reminder in a burst and a clearing the channel
could not take.
The operator stopped believing the mesh's notifications: one problem stood
twice on the desk (a reminder beside the message it followed, an escalation
then a reminder 31 s later), a unit failing again at each apply was said
again 22 times, and a question's buttons outlived it on a reminder the
ask's end never reached.
- messenger: a reminder or escalation is said in place of the problem's
message (Replace under its handle), alone, never as a digest line; a
problem first said in a digest gets its own message next time. A
reminder counts from when it was last said. A clearing is said once it
stays cleared 2 min (10 min once it came back); back before that, the
message continues without a word. Cleared before ever said and back:
said. An ask's expiry is said with its day.
- desk-channel: a send or show under a handle already shown replaces its
notification by the notifier's replace id.
- telegram: the same deletes the earlier message and sends the new one,
ringing as its kind rings; one it cannot delete loses its buttons.
The review found that a double tap while the phone's spinner turned would be
answered 'That answer was not taken', reading as if the approval failed; it is
now 'You already chose Approve at 13:30: recorded.' and does nothing more. The
fallback toast no longer promises a change that may not come (a stranger's
tap), the wait outlasts the router's 10 s wait for the controller's root word,
the channel's own refusals stay in the chat too, and the store's error words
stay in the journal.
At 13:30 on 2026-10-10 the operator approved two questions on Telegram and saw
nothing happen: the channel acknowledged each tap with no words, before the
router had judged it, and the edit that removed the buttons kept the question's
title, adding only a line under it that rings nothing.
The router now answers a chosen option in reply to the tap, once the ask's end
is recorded and before the question is edited: "You chose Approve: recorded,
and claude-code was told." (or, when the bus did not take the warrant, that it
is told when it does). A refusal already replied with its reason. Telegram
holds a tap's acknowledgement for the router's word and shows it as the tap's
own toast; a word with a body (a refusal's reason, Details) also stays in the
chat. Without a word in 8 seconds the toast claims nothing, and the late word
goes to the chat. A secret is never a toast.
An ask's own message, once answered, carries its outcome as its title:
"You chose Approve at 13:30 on Telegram · <headline>", then whether the asker
was told. The asks protocol carries no result back from the asker, so nothing
more is claimed of what it did.
The review of 2026-10-09 (M4): another holder of the token can change a message's words and leave its
buttons, so the operator taps Release under words that say something else. Each message's words are now
kept as a digest, per chat and message, and a tap on a message whose words differ, or that this channel
never showed, is refused on the phone and never said to the router.
The README says, as the operator directed (H5), that an approval from Telegram is meaningful only where
agents run under their own account without sudo, without the operator's X display, and with Telegram
Desktop's data readable by the operator alone; until then, approve from the phone.
jochen
jschoubben