diff --git a/README.md b/README.md
index a7b1853..5b76354 100644
--- a/README.md
+++ b/README.md
@@ -137,6 +137,7 @@ Phase 1 可能至少需要以下幾層：
   - callback 可接收
   - state 可持久化
   - stop/continue 已能影響後續行為
+- Phase 1 acceptance 已完成，詳見 `reports/phase1-acceptance-success.md`
 - 目前正往可維護、可重現的正式實作路徑收斂
 
 ---
@@ -268,5 +269,6 @@ Phase 1 will likely need at least these layers:
 - scope narrowed to Telegram-only
 - Telegram/OpenClaw PoC has succeeded
 - PoC success report: `reports/telegram-openclaw-poc-success.md`
+- Phase 1 acceptance is complete; see `reports/phase1-acceptance-success.md`
 - core design documents now exist (state / policy / callback contract / OpenClaw adapter / PoC plan)
 - the current effort is focused on turning the successful PoC into a cleaner, maintainable implementation path
diff --git a/reports/phase1-acceptance-success.md b/reports/phase1-acceptance-success.md
new file mode 100644
index 0000000..3ff702d
--- /dev/null
+++ b/reports/phase1-acceptance-success.md
@@ -0,0 +1,122 @@
+# reply-end-controls - Phase 1 Acceptance Success Report
+
+- Date: 2026-05-13
+- Scope: Telegram-only, OpenClaw-backed acceptance
+- Environment: `openclawtest`
+- Status: Phase 1 acceptance successful
+
+## Acceptance result
+
+Phase 1 acceptance is successful.
+
+The project has now demonstrated, on a real Telegram bot and real Telegram chat, the full core interaction path that Phase 1 required.
+
+## What was validated
+
+### 1. Reply-end buttons appear on assistant replies
+
+A live assistant reply was sent through the rebuilt `openclawtest` runtime, and the user confirmed that the reply contained the expected reply-end buttons.
+
+### 2. Continue button flow works end-to-end
+
+For the continue acceptance case:
+
+- the user clicked `A. 繼續`
+- raw callback data was recorded
+- state persistence succeeded
+- button UI update succeeded
+- acknowledgement reply succeeded
+
+Observed persisted state shape:
+
+```json
+{
+  "864811879": {
+    "lastChoice": "continue",
+    "lastChoiceAt": "...",
+    "sourceMessageId": "47",
+    "sourceCallbackId": "...",
+    "active": true
+  }
+}
+```
+
+This proves the full callback-to-state path for `continue`.
+
+### 3. Stop button flow works end-to-end
+
+For the stop acceptance case:
+
+- the user clicked `B. 就這樣吧，不需要額外處理`
+- raw callback data was recorded as `rec:stop`
+- state persistence succeeded
+- button UI update succeeded
+- acknowledgement reply succeeded
+
+Observed persisted state shape:
+
+```json
+{
+  "864811879": {
+    "lastChoice": "stop",
+    "lastChoiceAt": "...",
+    "sourceMessageId": "49",
+    "sourceCallbackId": "...",
+    "active": true
+  }
+}
+```
+
+This proves the full callback-to-state path for `stop`.
+
+### 4. Stop state affects later assistant behavior
+
+After the `stop` state was written, a later inbound message was sent to the assistant.
+
+The resulting assistant reply was visibly more restrained and closing-oriented than before, including language such as:
+
+- `好，我先不打擾你。`
+- `你先這樣沒問題。`
+
+This proves that reply-end state is not merely recorded; it influences later behavior.
+
+## Rebuild acceptance also succeeded
+
+Acceptance was not only run on a long-lived patched runtime.
+
+The following was also validated:
+
+1. take pristine `openclaw@2026.5.7` runtime files
+2. apply the project patch set using the repo scripts
+3. restart the OpenClaw gateway
+4. verify the reply-end-controls interaction on the live Telegram path
+
+This proves the project has crossed from one-off hand patching into a reproducible acceptance-capable integration flow.
+
+## Phase 1 scope satisfied
+
+The original Phase 1 feature goals are now met:
+
+- buttons can be attached to replies
+- callback clicks can be received
+- callback state can be persisted
+- later turns can read the state and alter behavior
+
+## Known limitations after acceptance
+
+Phase 1 is accepted, but the feature is not yet fully productized.
+
+Remaining limitations include:
+
+- implementation still depends on runtime patching inside OpenClaw
+- stop behavior influences later turns but is not yet maximally strict
+- only Telegram is supported
+- acceptance still involves some manual verification on Telegram UI
+
+These are valid next-phase concerns, but they do not block Phase 1 acceptance.
+
+## Final judgment
+
+Phase 1 is complete and accepted.
+
+Further work should now be treated as next-phase hardening and productization, not as unfinished Phase 1 work.