Correct an overstatement: a sealed secret is readable on its node

An earlier paragraph implied a secret becomes unrecoverable once
accepted. It does not. It is sealed to the node, which holds the private
half and writes the plaintext into the module's own file at 0600 — the
value is there, on the machine, as an ordinary file.

What does not exist is a way to ask the mesh what a secret is. That is
the property worth having and it is narrower than what was written.

The reason to capture the old system's environment first is simply that
adoption means supplying those values, not that they become
unrecoverable.

03-DESIGN/01-to-be/00-work-breakdown.md

@@ -151,10 +151,14 @@ and proven — a credential moving at both ends with the old one ceasing to work
 the sort of thing to do deliberately on a quiet afternoon rather than as a side effect of moving a
 service between systems.
 
-**So there is a step before any of this: read the current environment out of the old system while
-it can still be read.** Once a value is accepted, the mesh cannot show it back — *a mesh that can
-reveal a secret is a mesh that holds it* — and once the old system is gone, neither can that. A
-password nobody wrote down is a service nobody can adopt.
+**So there is a step before any of this: read the current environment out of the old system**, because
+adoption means supplying those values and they live in its files today.
+
+*Corrected 2026-08-31 — an earlier version of this paragraph made that sound more dangerous than it
+is.* A sealed secret is not unreadable; it is sealed **to the node**, which holds the private half
+and writes the plaintext into the module's own file. The value is there, on the machine, as an
+ordinary file. What does not exist is a way to ask *the mesh* what a secret is, and there is no
+reveal command, because a mesh that can reveal a secret is a mesh that holds one.
 
 ## Where it starts, and what that costs