diff --git a/04-ISSUES/017-an-action-succeeded-into-a-state-its-verify-rejects/00-report.md b/04-ISSUES/017-an-action-succeeded-into-a-state-its-verify-rejects/00-report.md
new file mode 100644
index 0000000..8797f41
--- /dev/null
+++ b/04-ISSUES/017-an-action-succeeded-into-a-state-its-verify-rejects/00-report.md
@@ -0,0 +1,44 @@
+---
+status: resolved
+opened: 2026-08-31
+located-in: [mesh-host]
+fixed-by: mesh-host — the store's readiness is checked over TCP, not the socket
+amended-design:
+---
+
+# 017 — An action succeeded into a state its own verify rejects
+
+## Symptom
+
+The substrate's `store-ready` action waits for the store to answer, then the host runs the
+action's `verify` to read back that it worked. Intermittently the host reported:
+
+> the action ran without error and its own verify still fails
+
+Both statements were true. The action waited on the **unix socket**; its verify checked the same
+way, a moment later, and found nothing. Roughly one bootstrap in three.
+
+## Why this matters
+
+**The action and its verify were asking different questions without appearing to.** While the
+store initialises it runs a temporary server on the socket only, then stops it and starts the real
+one. The action's loop saw the temporary server and exited happy; the verify landed in the gap
+between the two.
+
+So an action can **succeed into a state its own verify rejects** — and when it does, the host's
+report is accurate and useless. It says the command worked and the read-back did not, which is
+exactly what the mechanism is for, and names nothing a person can act on. It read as a slow
+machine, and the remedy people reach for is a longer timeout, which cannot help.
+
+**The general rule, which the host's design should carry:** an action's verify is the *definition*
+of what the action is for. If the action's own waiting decides it is done by a different test than
+the verify uses, the two can disagree — and the disagreement surfaces as an intermittent failure
+in the one place designed to catch silent success.
+
+## What was done
+
+Both check the store over TCP, which the init phase deliberately does not open — so neither can
+mistake the temporary server for the real one, and neither can be satisfied while the other is not.
+
+*Checked by the bootstrap itself, which is where it failed: this action gates everything after it,
+so a mesh coming up at all is the check.*