diff --git a/extensions/pi/README.md b/extensions/pi/README.md
index a54c3cb..6a2eca7 100644
--- a/extensions/pi/README.md
+++ b/extensions/pi/README.md
@@ -117,7 +117,7 @@ side of the wiring.
 | `MEMPALACE_FEED_WING` | `wing_conversations` | Target wing — passed to both the exporter and the `mempalace_mine` call. |
 | `MEMPALACE_FEED_DEBOUNCE_MS` | `600000` (10 min) | Minimum gap between mid-session (`agent_settled`) feeds. Bounds crash loss to one window instead of a whole session. |
 | `MEMPALACE_FEED_PREPARE_TIMEOUT_MS` | `120000` | Kills a wedged `--prepare` subprocess. |
-| `MEMPALACE_FEED_MINE_TIMEOUT_MS` | `30000` | Caps the `mempalace_mine` call so a stalled palace can't hang session exit. |
+| `MEMPALACE_FEED_MINE_TIMEOUT_MS` | `300000` (5 min) | Bounds how long the extension *waits* for `mempalace_mine`, so a stalled palace can't hang session exit. It does **not** cancel the mine — see [Debugging](#debugging). Raised from `30000` in 2026-09: the mine is the slowest call this extension makes (30–60s in normal operation), so the old deadline fired routinely and reported healthy behaviour as an error. |
 
 **Remote palace:** if `$MEMPALACE_REMOTE_URL` is set (see
 [Transport](#transport-local-vs-external)), `mempalace_mine`'s source path is
@@ -465,6 +465,30 @@ the next tool call transparently respawns `mempalace-mcp` and retries.
   `mempalace-mcp` manually with raw JSON-RPC on stdin to read the
   server-side error — much faster than guessing.
 
+### `feed (tick) failed: mine timed out after …ms`
+
+**Nothing has been lost.** The deadline bounds only how long the extension
+*waits*; it cannot cancel the mine, which continues on the server. The
+transcript is already staged before the mine is invoked, and
+`mempalace mine --mode convos` dedups by `source_file` and is idempotent, so the
+work either completed after the deadline or is redone by the next tick.
+
+**Do not "fix" it by retrying harder from the client.** The palace is a single
+writer; a blind retry is what turns one slow mine into a queue of them.
+
+Before 2026-09 this message appeared many times per session, which made it look
+like a persistent failure. That was a real defect, now fixed: `lastFeedAt` was
+recorded only after a *successful* wait, so a timeout left the debounce clock
+stale and every following settled turn started another mine on top of the one
+still running. Two changes — recording the attempt before the wait, and raising
+the deadline to sit far above the slowest honest completion — mean a healthy
+fleet should now never see it.
+
+If you *do* still see it, it is now informative rather than noise: a mine
+exceeded five minutes. Check palace size and whether another writer (a
+host-side feeder, a scheduled `mine`) is holding the write lock, rather than
+raising the timeout again.
+
 ## The `Type.Unsafe` gotcha
 
 Earlier versions of this extension registered every MCP tool with