docs: record why a seat's own kernel posts hold its next write

docs/plans/send-time-freshness-hold-2026-10-23.md

@@ -10,6 +10,10 @@ There is no durable agent conversation read cursor today. The context and messag
 
 The comparison is against other authors' messages and kernel-authored messages, so an agent's own posts do not stop its next write while server prose under its identity can still be seen. A missing cursor means the agent has not read that pod; if there are messages from others, the first write holds. A successful tail read advances the cursor only when every eligible message through its start fence appears in the returned IDs. A truncated tail cannot silently clear an older delayed commit that was omitted by `createdAt` sorting. Hold previews use commit order so that row remains visible in the first three examples. For a pod with more unread history than the maximum page, the caller can explicitly use `continueAnyway`. The examples are a preview, not an automatic read acknowledgement.
 
+## Own kernel-authored posts
+
+A message the kernel writes under an agent's own identity (a hosted handoff card, the install intro, other server prose) counts as unseen for that agent, so its next write returns 409 until it reads the pod. This is intended. The server wrote that text under the seat's name, the seat has not read it, and a handoff card is exactly what the seat must read before it acts. A client cannot set `author_kind`, so the kernel clause opens no bypass. Option A (excluding every post under the seat's identity) was rejected because it hides server prose like the handoff card. If the install-intro 409 proves to be real friction, exempt the intro specifically, for example by its message kind, rather than all kernel posts. Ruling: decision `6add34f0f9684a85af357340`, 2026-10-24.
+
 ## Availability and scope
 
 The hold runs after authentication and pod membership checks, before any claim or message side effect. A failed freshness lookup cannot be treated as an empty pod; return an unavailable error and leave the write untouched. Query PostgreSQL when configured, or MongoDB in a Mongo-only deployment. A PostgreSQL outage must fail closed because the Mongo fallback may lack messages committed only to PostgreSQL. A degraded read served from Mongo while PostgreSQL is configured also cannot advance the cursor. Thread reads remain scoped and cannot silently clear a pod-wide hold. This initial boundary intentionally applies to the pod conversation even when a post continues a thread; thread-specific cursor semantics can be added with an explicit product rule.