docs: correct main send status and plan

docs/source-discovery/2026-07-11-a-route-uia-send.md

@@ -1,7 +1,7 @@
 # A-route UIA Send Implementation Note
 
 Date: 2026-07-11
-Branch: `codex/a-route-rpa-send`
+Branch: implemented on `codex/a-route-rpa-send`, merged to `main`
 
 ## Decision
 
@@ -25,6 +25,28 @@ $env:ISPHERE_SEND_UIA_BUTTON_AUTOMATION_ID = "btnSend"
 
 Then call `isphere_send_message` with `execution_mode="production"`.
 
+## Status correction after real-window work
+
+`uia_send_message` is a UI action connector. Its helper result fields such as
+`typed_text=true`, `clicked_ui=true`, and `sent_message=true` mean the editor was
+written and the send button was invoked/clicked. They do not mean the server
+accepted the message, the receiver got it, or a sent record was written.
+
+After this note was first written, the project also opened a real offline
+`frmP2PChat` window locally and confirmed:
+
+- root: `frmP2PChat`
+- editor: `rtbSendMessage`
+- send button: `btnSend`
+- receive area: `rtbRecvMessage`
+
+The real offline window still shows the client-side offline-send blocker, so it
+is useful for UI positioning and click verification, not for business delivery
+verification.
+
 ## Remaining real-environment work
 
-The local environment still cannot log in to iSphere. The code path is implemented and locally proven against synthetic UIA, but real iSphere success still needs a logged-in window handle and one real run in the online environment.
+The local environment still cannot log in to iSphere. The code path is
+implemented and locally proven against synthetic UIA plus the real offline chat
+window, but real iSphere success still needs a logged-in window handle and one
+online run with success/ack or sent-record evidence.