diff --git a/README.md b/README.md
index 077b128..75626c3 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,118 @@
 # reply-end-controls
 
-Reply end controls: continue or stop buttons for chat responses.
\ No newline at end of file
+Reply end controls for chat responses.
+
+## Goal
+
+At the end of each assistant reply, attach explicit user controls so the user can quickly choose whether the conversation should continue or stop cleanly.
+
+The initial product goal is a two-button ending control:
+
+- `A. 繼續`
+- `B. 就這樣吧，不需要額外處理`
+
+The system should capture the user's button selection and feed it back into the assistant/runtime so future behavior can adapt accordingly.
+
+If the user has a new request instead of choosing a button, they should still be able to type normally without any extra workflow.
+
+## Scope
+
+This is a separate project from the OpenClaw governance interceptor work.
+
+This repo is for the interaction-control feature only:
+
+- rendering reply-end controls
+- receiving button callbacks
+- mapping user choice into conversation state
+- preserving the ability to type freely instead of pressing a button
+
+## Phase 1 target
+
+Build the first working version for **Telegram**.
+
+Telegram is the first target because it already supports inline buttons and callback payloads, which makes it the easiest place to validate the interaction model.
+
+## Expected behavior
+
+### At the end of every assistant reply
+
+The system appends two visible controls:
+
+- Continue
+- Stop here
+
+### If the user taps Continue
+
+The runtime records that the user wants to keep going.
+
+Possible future uses:
+
+- allow follow-up prompting
+- keep short-term task context active
+- suppress premature closure behavior
+
+### If the user taps Stop here
+
+The runtime records that the user does not want additional handling.
+
+Possible future uses:
+
+- avoid unnecessary follow-up suggestions
+- mark the reply as closed
+- reduce proactive continuation behavior
+
+### If the user types a new message instead
+
+The typed message takes priority.
+
+The user must not be forced to press a button before continuing the conversation.
+
+## Non-goals
+
+For the initial version, this project does **not** try to:
+
+- redesign the full chat UI
+- replace all reply delivery logic
+- solve governance / claim verification
+- support every chat platform at once
+
+## Initial implementation direction
+
+Phase 1 will likely need these parts:
+
+1. **Reply payload augmentation**
+   - append Telegram inline buttons to assistant replies
+
+2. **Callback handling**
+   - receive button presses from Telegram
+   - map callback data into internal conversation state
+
+3. **Conversation state storage**
+   - remember the most recent reply-end choice for a session or conversation
+
+4. **Policy hook**
+   - let the assistant/runtime inspect whether the user chose Continue or Stop here
+
+## Suggested milestones
+
+### Milestone 1
+
+- Telegram proof of concept
+- one reply can render the two buttons
+- one button click can be received and logged
+
+### Milestone 2
+
+- map button clicks into session state
+- confirm typed follow-up still works without pressing a button
+
+### Milestone 3
+
+- apply button state to runtime behavior
+- define exactly how Continue / Stop here influences future turns
+
+## Current status
+
+- Repository created
+- Initial README expanded
+- Technical design and implementation not yet started