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.
This commit is contained in:
@@ -72,7 +72,7 @@ as text. `get` serves each, and any other field a record of hq wrote under `fiel
|
||||
## Writing a record
|
||||
|
||||
1. `reserve` a number for its kind.
|
||||
2. `propose` the record whole. It is refused, naming every reason at once, when it breaks one of the **29 rules
|
||||
2. `propose` the record whole. It is refused, naming every reason at once, when it breaks one of the **30 rules
|
||||
that judge one record or its prose**. They are hq's checks moved to the write; `PerRecordRules` in `rules.go`
|
||||
lists each one with the check it comes from:
|
||||
- 25 on the structure: kind, reserved number, title, topic, date, deciders, research status, at least one
|
||||
@@ -81,7 +81,10 @@ as text. `get` serves each, and any other field a record of hq wrote under `fiel
|
||||
supersedes or changes is accepted, a changed clause is in force or changed (a drafted one too), a superseded record cited beside its
|
||||
superseder, a graduated effort says what it became, and the links in its text resolve;
|
||||
- 4 on the prose: no word the glossary retired, no daemon's line, a deferral names its tracking issue, and a
|
||||
progressive insight in the dated, marked form.
|
||||
progressive insight in the dated, marked form;
|
||||
- 1 on the operator's ask (hq issue 639): `brief`, a record that needs the operator carries a brief its ask reads
|
||||
at a glance — a headline of at most 60 characters, a one-line summary of at most 300, at most three points of
|
||||
at most 160, and no path, address, dotted name or long word. It holds records dated from 2026-10-13.
|
||||
|
||||
A rule holds a record from the day hq's checks began to hold it (`RuleFrom` in `rules.go`):
|
||||
- retired words from 2026-10-07 and daemons' lines from 2026-10-09 for a research effort; for a decision record
|
||||
@@ -122,7 +125,10 @@ as text. `get` serves each, and any other field a record of hq wrote under `fiel
|
||||
- On approve the record and its clauses are accepted and in force. Every clause it changes moves to
|
||||
`changed`, and every record it supersedes moves to `superseded`, each as a new version of that record. A record marked `needs-operator` is first asked of the
|
||||
operator (an ask that cannot be published is taken back, and the record is reviewed again later): an ask with
|
||||
Approve and Decline, both at the level approve, each bound to this version's digest. It is
|
||||
Approve and Decline, both at the level approve, each bound to this version's digest. The ask reads at a glance
|
||||
(hq issue 639): the record's `brief` — a headline saying what it changes for the operator, a summary, at most three
|
||||
points — and as its Details who proposed it, the review, the fingerprint and how to read its clauses; the clauses
|
||||
are never listed. An ask made before that change is composed again as it was asked (`form`). It is
|
||||
accepted only on the router's warrant for Approve, read back from the router's own record and held to the ask
|
||||
composed again. A record changed after it was asked finds the digests differ, and nothing is accepted. The
|
||||
warrant is kept with the record.
|
||||
|
||||
Reference in New Issue
Block a user