An ask reads at a glance on the phone: a headline, a summary and its points, the rest in a note (issues 383 and 639)

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.

modules/claude-code/README.md

@@ -179,9 +179,12 @@ said in the render's answer. What was registered before is still rendered and ma
 hand-over, the context a later session needs — or with `remove` for a section approved before. Nothing becomes
 active: the proposal is kept in the module's `proposals` state and the operator is asked through the operator
 channel (`operator-channel`, hq ADR 0259) with Approve and Decline, both at the level approve, so only a channel that
-proves who answered (Telegram) carries either. The phone shows the whole text when it is short and every line may
-leave the mesh, else its first lines and a fingerprint; the whole text is read at the controller's terminal with
-`mesh-cli ask claude-code claude_code_proposals '{"id": "<id>"}'`. Decline, or no answer within a day, discards it.
+proves who answered (Telegram) carries either. The ask reads at a glance (hq issue 639): its explanation is one
+line saying what the proposal does — the proposer's `summary`, at most 300 characters, or the module's own words —
+and its Details, which the phone shows collapsed after the answers, carry the text (whole when it is short and every
+line may leave the mesh, else its first lines), where it came from and its fingerprint; the whole text is read at the
+controller's terminal with `mesh-cli ask claude-code claude_code_proposals '{"id": "<id>"}'`. A proposal made before
+that change is asked, and its warrant held, in the form it was made in (`form`). Decline, or no answer within a day, discards it.
 **Every node proves the approval itself**: it reads the router's own record of the ask under this module's name,
 judges the record as this module would have made it, composes the ask again from the proposal and holds the warrant to it (the same ask digest, the option's bound act,
 the text's digest, in time), and only then writes the section into its own `approved.json`, which the managed