docs/tools/scheduling.md

@@ -3,17 +3,11 @@
 ## `scheduling` tool group
 
 Scheduled prompts fan a message body out to one or more agent inboxes
-at a future time, optionally recurring.
+at a future time, optionally recurring. All scheduling ops go through
-
+the operator approval queue (even self-targeted schedules — use
-**Creating** one goes through the operator approval queue, even when it
+`remind` for unapproved self-wake). Authorization for read/cancel/edit
-targets only yourself — use `remind` for an unapproved self-wake. The
+ops: you can act on schedules you own or any owned by a sub-agent in
-other four verbs need no approval: holding the `scheduling` tool group
+your topology subtree.
-is the whole gate.
-
-Authorization is one rule for all four verbs: you reach schedules you own
-and any owned by an agent in your topology subtree. `list_schedules`
-applies it too, so the snapshot only ever shows schedules you could also
-cancel.
 
 ### `request_schedule_prompt(targets, body, first_fire_at_unix, interval_seconds?, description?)`
 

hive-c0re/src/socket_server/mod.rs

@@ -1121,10 +1121,7 @@ pub(crate) fn handle_send(
 /// `-M` read needs root). `journalctl -M` wants the `h-<name>` machine
 /// name, which `container_name` derives.
 async fn handle_get_logs(agent: &str, lines: Option<u32>) -> Response {
-    // Clamped here and not only in the MCP layer that also clamps it: a
+    let n = lines.unwrap_or(50);
-    // caller-side limit is not a limit, and anything speaking this socket
-    // sets `lines` itself. Mirrors `handle_get_host_journal`'s own cap.
-    let n = lines.unwrap_or(50).min(500);
     let machine = crate::lifecycle::container_name(agent);
     tracing::info!(%agent, %machine, %n, "manager: get_logs");
     match crate::priv_client::read_container_journal(