docs: split inbox test plans into case files

docs/implementation-roadmap.md

@@ -20,7 +20,7 @@ As of now:
 - `inbox` is implemented end-to-end, including send/fetch/claim/renew/update/reply/done/fail/cancel/list/show/watch/wait-reply
 - `inbox` supports blocking waits, lease renewal, unread fetches backed by per-agent read cursors, `--body-file`, artifact attachments, and structured JSON errors with stable exit codes
 - integration tests cover the main inbox lifecycle, wait/watch flows, artifact persistence, and JSON error contracts
-- a human-readable inbox command test-plan set has not been authored yet
+- a human-readable inbox command test-plan set has been authored under `docs/tests/inbox/`
 - `orch` currently exists as a command skeleton only
 - no scheduler workflows have been implemented yet
 
@@ -270,13 +270,10 @@ Definition of done:
 
 If a new agent is taking over now, the next concrete step should be:
 
-1. create the inbox test documentation tree under `docs/tests/inbox/`
-2. write the shared testing conventions in `docs/tests/inbox/README.md`
-3. add `_shared/README.md` for common fixtures and assertion rules
-4. add command-level `README.md` files for the implemented inbox commands
-5. add `workflows/README.md` for cross-command cases such as unread, wait, and reply flows
+1. start `Milestone 4: Orch Core Scheduling`
+2. keep the authored inbox test-plan set in `docs/tests/inbox/` synchronized if CLI behavior changes during `orch` work
 
-This is the smallest meaningful documentation slice because the inbox implementation is already present and stable enough to document in detail before `orch` work begins.
+The inbox implementation and its human-readable test-plan set are already in place, so the next meaningful project step is to build scheduler behavior on top of that stable base.
 
 ## Recommended Driver Choices
 
@@ -302,6 +299,12 @@ Add these tests before the codebase grows too much:
 
 ## Inbox Test Documentation Roadmap
 
+Status:
+
+- completed for the current inbox CLI surface
+- command-level and workflow Markdown documents exist under `docs/tests/inbox/`
+- future updates should revise this section only when new inbox commands or materially new CLI-visible behavior are added
+
 Goal:
 
 - make inbox behavior easy for a new agent to understand and convert into automated tests without re-reading all code paths
@@ -312,6 +315,7 @@ Directory layout:
 - `docs/tests/inbox/_shared/README.md`
 - `docs/tests/inbox/workflows/README.md`
 - `docs/tests/inbox/<command>/README.md`
+- `docs/tests/inbox/<command>/<case-slug>.md`
 
 Initial command folders:
 
@@ -332,9 +336,11 @@ Initial command folders:
 
 Documentation rules:
 
-- organize by folder and `README.md`, not one file per test case
+- organize by folder with a `README.md` entrypoint
+- command folders use `README.md` as an index only
+- each command case lives in its own Markdown file named after the case slug
 - do not use numeric test case IDs
-- identify cases by file path plus a stable case title or `slug`
+- identify command cases by concrete file path
 - keep one command per directory, plus `workflows/` for cross-command behavior
 - use `_shared/` for common fixtures, database conventions, exit-code rules, and shared JSON assertions
 
@@ -346,9 +352,9 @@ Required per-case structure:
 - `预期输出`
 - `断言结论`
 
-Recommended case-title pattern:
+Case file naming pattern:
 
-- `## case: <stable-slug>`
+- `<stable-slug>.md`
 
 Authoring order:
 
@@ -382,7 +388,8 @@ Do not block v1 on these:
 - The design phase is complete enough to start coding.
 - Avoid reopening major design questions unless implementation forces it.
 - The repository already has compiling binaries and working schema init.
-- Finish the inbox test-plan docs before starting broad `orch` implementation.
+- The inbox test-plan docs are in place; keep them synchronized before and during broad `orch` implementation.
+- inbox command test-plan folders use `README.md` as an index plus one file per case; keep any further structural changes consistent with the documented rules above.
 - Preserve the separation:
   - `inbox` handles communication
   - `orch` handles scheduling