@lmctl-ai/lmctl 0.1.211 → 0.1.212

package/README.md

@@ -46,6 +46,7 @@ lmctl lint ./my-project/my-project.lmctl
 lmctl seed ./my-project/my-project.lmctl
 lmctl chat ./my-project/my-project.lmctl Lead "Inspect the repo and propose next steps."
 lmctl mail sent --json
+lmctl mail deliver msg_mbx_123 --json
 lmctl mail sent --limit 100 --cursor "$NEXT_CURSOR" --json
 ```
 
@@ -84,11 +85,17 @@ sqlite3 ~/.lmctl/state.db "INSERT OR REPLACE INTO lmctl_config(key,value,updated
 sqlite3 ~/.lmctl/state.db "INSERT OR REPLACE INTO lmctl_config(key,value,updated_at) VALUES('workspace.provider3','gemini',strftime('%Y-%m-%dT%H:%M:%fZ','now'));"
 ```
 
-`lmctl mail` exposes read-only primitives over the event-log substrate only:
-list messages sent from SELF, read a message's ordered event history, check its
-historical provider transcript, and render causal delegation lineage. It does
-not query the retired mailbox/chat/invocation tables. Missing causal capture is
-shown as an explicit tree root rather than guessed from timestamps.
+`lmctl mail` exposes low-level primitives over the event-log substrate: list
+pending or sent messages, read event history/content, inspect historical
+provider evidence and causal lineage, declare handling/acknowledgement, and
+deliver one specifically addressed queued message. A `mail deliver` call is
+one provider turn for only that message; same-lane messages stay queued for
+separate calls, leaving ordering and retry policy to the external consumer.
+Read commands stay event-substrate-only; deliver deliberately follows the
+CREATE event's legacy mailbox-row reference into the existing live delivery
+machinery until that write path is fully cut over.
+Missing causal capture is shown as an explicit tree root rather than guessed
+from timestamps.
 For every `mail` subcommand, `--json` is the stable external contract and
 includes `schema_version: 1`; default text output is for humans and may change.
 JSON failures use `{status:"error", errorKind, message}`. The unbounded `sent`
@@ -104,6 +111,15 @@ Stable top-level success fields are:
 - `history`: `schema_version`, `schema`, `message_id`, `events`.
 - `seen`: `schema_version`, `schema`, `message_id`, `receiver`, `db`,
   `transcript`, `answered`.
+- `pending`: `schema_version`, `schema`, `filters`, `messages`.
+- `read`: `schema_version`, `schema`, `message_id`, `message_type`,
+  `in_reply_to`, `sender`, `receiver`, `content`, `pending_state`.
+- `deliver`: `schema_version`, `schema`, `message_id`, `message_type`,
+  `receiver`, `outcome`, `provider_status`, `message`.
+- `handle`: `schema_version`, `schema`, `message_id`, `handling_by`,
+  `handling_at`, `appended`.
+- `ack`: `schema_version`, `schema`, `message_id`, `acked_by`, `appended`,
+  `pending_outcome`.
 - `tree`: `schema_version`, `schema`, `root`, `since`, `since_timestamp`,
   `sent`, `next_cursor`, `orphan_policy`, `incomplete_capture_note`.