ADR 0277, progressive insight: a proposal's values are whole on a channel that proves who answers (issue 383)

The operator could not read what they were approving on the phone: the values were masked as
‹path› and ‹address›, and the fingerprint and a how-to paragraph made the message a wall of
text. On a channel that proves who answers the exact values are shown whole and only a value
shaped like a secret is withheld; the masking stays for conditions and for channels that prove
nothing; the fingerprint and the how-to are the Details answer's. To-be 46 takes the amendment
to the content rule and to exact-render.

02-DECISIONS/0277-a-trusted-setting-is-proposed-through-a-verb-and-set-on-the-operators-warrant-and-a-modules-own-secret-is-asked-for-and-typed-at-the-desk.md

@@ -84,6 +84,18 @@ controller ask it. Nothing bounded how often it could be asked.
    fingerprint, and where the whole is read.** Chosen. "recalbox=smb://host/share@/mnt/recalbox" is shown as
    "recalbox=‹address›@‹path›", and `settings proposals <id>` shows it whole, with the same fingerprint.
 
+   > **Progressive insight — 2026-10-10.** Issue 383 in the issue tracker: the first proposals reached the
+   > operator's phone as "+ shares: media=‹path›", and the operator said they could not see what they were being
+   > asked to approve: a mount point, a share name or a private address is the thing being approved. Option 1 was
+   > rejected on the fact that the content rule refuses a path or an address "in any message that leaves the
+   > mesh"; the operator decided, and the rule now reads, that on a channel that proves who answers
+   > (`verified-sender`, Telegram today) the exact values are shown WHOLE, and only a value shaped like a secret
+   > is withheld there — the ask carries its explanation twice (the SDK's `Whole` beside `Explanation`), the
+   > router shows the whole only on such a channel and holds it to the secret rule alone, and refuses the ask as
+   > a whole when a secret's shape is left in it. Option 3 stands as decided for every channel that proves
+   > nothing (the desk) and for every condition's words. The decision stands: the operator reads the exact
+   > change and approves it; what changed is where the values may be read whole.
+
 ### Where the record of the set is kept
 
 1. **A seat event of the controller's own**, beside the hand-act log. Rejected for now: nothing consumes it, and
@@ -131,6 +143,14 @@ One ask per proposal, published under the controller's name on the `operator-cha
   hexadecimal digits of its digest, in groups of four); when a part is not shown, where the whole is read
   (`settings proposals <id>`, through the mesh MCP server or `mesh-cli`), whose fingerprint must be the one on
   the phone; and that, approved, the layer is set at once and the machine takes it at its next push;
+
+  > **Progressive insight — 2026-10-10.** Issue 383: on the phone this read as one wall of text. The
+  > explanation is now the change alone — one line per key as above, then "Proposed by <who> at <time>" — and
+  > the router adds what every ask says (who asks, what each answer does, when it expires); on a channel that
+  > proves who answers the values are whole, as the insight above says. The fingerprint, where the whole is
+  > read and that the layer is set at once moved to the **Details** answer the ask's own message offers (the
+  > SDK's `Details`), shown line by line under the content rule. The telegram channel shows every message
+  > formatted, never reworded: the headline bold, a key line and a fingerprint in monospace, its markup escaped.
 - **two options, Approve and Decline, both at the level approve**, as the controller's rehearsal asks, so only a
   channel that proves who answered carries either. Each binds the digest of its act: the proposal's id, the
   answer, the module, the machine, the digest of the exact values, the digest of the layer they replace,
@@ -226,6 +246,7 @@ channel as every given secret is.
 |---|---|
 | A proposal changes nothing, and asks at the level approve with the exact change | the controller's test: the ask passes the SDK's check, offers Approve and Decline both at the level approve, each binding an act digest; the explanation carries each key with its value or its shape, the layer's fingerprint and the "was" of a changed key, and passes the content rule; the kept record is the controller's own, and no layer is set (`TestAProposalAsksAtTheLevelApproveWithTheExactChange`, `TestAClearIsProposedAndShowsWhatItRemoves`) |
 | What the phone is shown keeps a value's shape and passes the content rule | `TestAValueIsShownInItsShapeAndPassesTheContentRule` |
+| On a channel that proves who answers the values are whole and only a secret's shape is withheld; elsewhere they keep their shape; the message carries no fingerprint and no how-to (the insight of 2026-10-10) | the controller's `TestAProposalShowsItsValuesWholeOnlyWhereTheSenderIsProvenAndNeverASecret` (the masked and the whole change differ in exactly the masked lines); the router's `TestAnAsksWholeWordsAreShownWhereTheSenderIsProvenAndMaskedElsewhere` and `TestAnAskWhoseWholeWordsCarryASecretIsRefused`; the telegram channel's `TestAMessageIsRenderedInHTMLWithItsMarkupEscaped` |
 | A layer the mesh would refuse, or a silent removal, is not asked | `TestAProposalTheMeshWouldRefuseIsNotAsked` |
 | The layer is set once, on the operator's approval, with who approved it; a replay changes nothing | `TestTheLayerIsSetOnceOnTheOperatorsApproval`: the warrant heard twice sets once, no verb is called, the hand-act reads `warrant` with the answer and the values' digest, and counts as a person's decision |
 | Decline, expiry, cancel, replacement and the router's refusal discard | `TestDeclineExpiryAndRefusalDiscardAProposal`, each outcome, and an approval after the end refused |