forge-openclaw-plugin 0.3.9 → 0.3.11

package/README.md

@@ -561,7 +561,7 @@ If you explicitly want the old laptop-driven publish path, run the same script w
 `FORGE_RELEASE_MODE=prepare` and it will still publish directly after pushing.
 
 For the exact prerequisites, tags, and GitHub secret names, use
-`docs/release-cheat-sheet.md`.
+`docs/release/release-cheat-sheet.md`.
 
 ClawHub note:
 

package/dist/companion-iroh-src/src/lib.rs

@@ -1,6 +1,9 @@
+use std::collections::HashMap;
 use std::ffi::{CStr, CString, c_char};
-use std::time::Duration;
+use std::sync::{Arc, Mutex, OnceLock};
+use std::time::{Duration, Instant};
 
+use iroh::endpoint::Connection;
 use iroh::{Endpoint, SecretKey};
 use protocol::{
     BridgeRequest, BridgeResponse, COMPANION_ALPN, FORGE_AGENT_NAME, ForgeHttpRequest,
@@ -12,6 +15,129 @@ use tokio::io::{AsyncRead, AsyncReadExt, AsyncWrite, AsyncWriteExt};
 pub mod protocol;
 
 const MAX_FRAME_BYTES: usize = 50 * 1024 * 1024;
+const IROH_CLIENT_TIMING_HEADER: &str = "x-forge-iroh-client-timing-ms";
+const IROH_CLIENT_CONNECTION_REUSED_HEADER: &str = "x-forge-iroh-client-connection-reused";
+const FFI_RUNTIME_WORKER_THREADS: usize = 6;
+#[cfg(test)]
+const FOREGROUND_HEALTH_SYNC_STREAMS: usize = 6;
+
+struct FfiIrohState {
+    runtime: tokio::runtime::Runtime,
+    endpoint: Mutex<Option<Arc<Endpoint>>>,
+    connections: Mutex<HashMap<ConnectionCacheKey, Arc<Connection>>>,
+    secret_key: SecretKey,
+}
+
+static FFI_STATE: OnceLock<Result<FfiIrohState, String>> = OnceLock::new();
+
+#[derive(Debug, Clone, PartialEq, Eq, Hash)]
+struct ConnectionCacheKey {
+    node_id: String,
+    relay: Option<String>,
+    token: String,
+}
+
+impl ConnectionCacheKey {
+    fn from_payload(payload: &PairPayload) -> Self {
+        Self {
+            node_id: payload.node_id.clone(),
+            relay: payload.relay.clone(),
+            token: payload.token.clone(),
+        }
+    }
+}
+
+fn ffi_state() -> Result<&'static FfiIrohState, String> {
+    match FFI_STATE.get_or_init(FfiIrohState::new) {
+        Ok(state) => Ok(state),
+        Err(error) => Err(error.clone()),
+    }
+}
+
+impl FfiIrohState {
+    fn new() -> Result<Self, String> {
+        let runtime = tokio::runtime::Builder::new_multi_thread()
+            .worker_threads(FFI_RUNTIME_WORKER_THREADS)
+            .enable_all()
+            .build()
+            .map_err(|error| format!("building Forge Iroh runtime: {error}"))?;
+        Ok(Self {
+            runtime,
+            endpoint: Mutex::new(None),
+            connections: Mutex::new(HashMap::new()),
+            secret_key: SecretKey::generate(),
+        })
+    }
+
+    async fn cached_endpoint(&self) -> Result<Arc<Endpoint>, String> {
+        if let Some(endpoint) = self.endpoint.lock().map_err(lock_error)?.as_ref().cloned() {
+            return Ok(endpoint);
+        }
+
+        let endpoint = Arc::new(
+            Endpoint::builder(iroh::endpoint::presets::N0)
+                .secret_key(self.secret_key.clone())
+                .bind()
+                .await
+                .map_err(|error| format!("binding Iroh endpoint: {error}"))?,
+        );
+        let mut guard = self.endpoint.lock().map_err(lock_error)?;
+        if let Some(existing) = guard.as_ref().cloned() {
+            return Ok(existing);
+        }
+        *guard = Some(endpoint.clone());
+        Ok(endpoint)
+    }
+
+    async fn cached_connection(
+        &self,
+        payload: &PairPayload,
+    ) -> Result<(ConnectionCacheKey, Arc<Connection>, bool), String> {
+        let key = ConnectionCacheKey::from_payload(payload);
+        if let Some(connection) = self
+            .connections
+            .lock()
+            .map_err(lock_error)?
+            .get(&key)
+            .cloned()
+        {
+            return Ok((key, connection, true));
+        }
+
+        let endpoint = self.cached_endpoint().await?;
+        let connection = Arc::new(connect_iroh(endpoint, payload).await?);
+        let mut guard = self.connections.lock().map_err(lock_error)?;
+        if let Some(existing) = guard.get(&key).cloned() {
+            return Ok((key, existing, true));
+        }
+        guard.insert(key.clone(), connection.clone());
+        Ok((key, connection, false))
+    }
+
+    fn evict_connection(&self, key: &ConnectionCacheKey, connection: &Arc<Connection>) {
+        let Ok(mut guard) = self.connections.lock() else {
+            connection.close(
+                iroh::endpoint::VarInt::from_u32(1),
+                b"forge connection cache lock failed",
+            );
+            return;
+        };
+        if guard
+            .get(key)
+            .is_some_and(|existing| Arc::ptr_eq(existing, connection))
+        {
+            guard.remove(key);
+            connection.close(
+                iroh::endpoint::VarInt::from_u32(1),
+                b"forge request stream failed",
+            );
+        }
+    }
+}
+
+fn lock_error<T>(error: std::sync::PoisonError<T>) -> String {
+    format!("Forge Iroh client state lock poisoned: {error}")
+}
 
 #[derive(Debug, Deserialize)]
 #[serde(rename_all = "camelCase")]
@@ -87,12 +213,9 @@ fn into_c_string(value: String) -> *mut c_char {
 }
 
 fn run_ffi_http_request(request: FfiHttpRequest) -> Result<FfiHttpResponse, String> {
-    let runtime = tokio::runtime::Builder::new_current_thread()
-        .enable_all()
-        .build()
-        .map_err(|error| format!("building Forge Iroh runtime: {error}"))?;
-    runtime.block_on(async move {
-        let response = send_http_request_over_iroh(request).await?;
+    let state = ffi_state()?;
+    state.runtime.block_on(async move {
+        let response = send_http_request_over_iroh(state, request).await?;
         Ok(FfiHttpResponse {
             ok: true,
             status: Some(response.status),
@@ -103,74 +226,141 @@ fn run_ffi_http_request(request: FfiHttpRequest) -> Result<FfiHttpResponse, Stri
     })
 }
 
-async fn send_http_request_over_iroh(request: FfiHttpRequest) -> Result<ForgeHttpResponse, String> {
+async fn send_http_request_over_iroh(
+    state: &FfiIrohState,
+    request: FfiHttpRequest,
+) -> Result<ForgeHttpResponse, String> {
     validate_pair_payload(&request.pair_payload)?;
     validate_proxy_path(&request.path)?;
 
-    let endpoint = Endpoint::builder(iroh::endpoint::presets::N0)
-        .secret_key(SecretKey::generate())
-        .bind()
-        .await
-        .map_err(|error| format!("binding Iroh endpoint: {error}"))?;
-    let result = async {
-        let node_id = request
-            .pair_payload
-            .node_id
-            .parse()
-            .map_err(|error| format!("parsing Iroh node id: {error}"))?;
-        let mut addr = iroh::EndpointAddr::new(node_id);
-        if let Some(relay) = request.pair_payload.relay.as_deref() {
-            addr = addr.with_relay_url(
-                relay
-                    .parse()
-                    .map_err(|error| format!("parsing Iroh relay URL: {error}"))?,
-            );
+    let total_started_at = Instant::now();
+    let connection_started_at = Instant::now();
+    let (cache_key, conn, connection_reused) =
+        state.cached_connection(&request.pair_payload).await?;
+    let connection_ms = elapsed_ms(connection_started_at);
+    match send_request_over_connection(&conn, request).await {
+        Ok((mut response, mut timing)) => {
+            timing.connection_ms = connection_ms;
+            timing.connection_reused = connection_reused;
+            timing.total_ms = elapsed_ms(total_started_at);
+            response.headers.push(HeaderPair {
+                name: IROH_CLIENT_TIMING_HEADER.to_string(),
+                value: timing.to_header_value(),
+            });
+            response.headers.push(HeaderPair {
+                name: IROH_CLIENT_CONNECTION_REUSED_HEADER.to_string(),
+                value: if connection_reused { "1" } else { "0" }.to_string(),
+            });
+            Ok(response)
         }
-        let conn = endpoint
-            .connect(addr, COMPANION_ALPN)
-            .await
-            .map_err(|error| format!("connecting over Forge Iroh bridge: {error}"))?;
-        let (mut send, mut recv) = conn
-            .open_bi()
-            .await
-            .map_err(|error| format!("opening Iroh stream: {error}"))?;
-        write_json_frame(
-            &mut send,
-            &BridgeRequest::Connect {
-                v: PROTOCOL_VERSION,
-                token: request.pair_payload.token.clone(),
-                agent: FORGE_AGENT_NAME.to_string(),
-            },
-        )
-        .await?;
-        let ack: BridgeResponse = read_json_frame(&mut recv).await?;
-        validate_bridge_response(&ack)?;
-        write_json_frame(
-            &mut send,
-            &ForgeHttpRequest {
-                v: PROTOCOL_VERSION,
-                method: request.method,
-                path: request.path,
-                headers: request.headers,
-                body_base64: request.body_base64,
-            },
-        )
-        .await?;
-        let response = tokio::time::timeout(
-            Duration::from_secs(60),
-            read_json_frame::<ForgeHttpResponse, _>(&mut recv),
-        )
-        .await
-        .map_err(|_| "timed out waiting for Forge Iroh response".to_string())??;
-        conn.close(
-            iroh::endpoint::VarInt::from_u32(0),
-            b"forge request complete",
+        Err(error) => {
+            state.evict_connection(&cache_key, &conn);
+            Err(error)
+        }
+    }
+}
+
+async fn connect_iroh(
+    endpoint: Arc<Endpoint>,
+    payload: &PairPayload,
+) -> Result<Connection, String> {
+    let node_id = payload
+        .node_id
+        .parse()
+        .map_err(|error| format!("parsing Iroh node id: {error}"))?;
+    let mut addr = iroh::EndpointAddr::new(node_id);
+    if let Some(relay) = payload.relay.as_deref() {
+        addr = addr.with_relay_url(
+            relay
+                .parse()
+                .map_err(|error| format!("parsing Iroh relay URL: {error}"))?,
         );
-        Ok(response)
     }
-    .await;
-    endpoint.close().await;
-    result
+    endpoint
+        .connect(addr, COMPANION_ALPN)
+        .await
+        .map_err(|error| format!("connecting over Forge Iroh bridge: {error}"))
+}
+
+async fn send_request_over_connection(
+    conn: &Connection,
+    request: FfiHttpRequest,
+) -> Result<(ForgeHttpResponse, IrohClientTiming), String> {
+    let mut timing = IrohClientTiming::default();
+    let open_started_at = Instant::now();
+    let (mut send, mut recv) = conn
+        .open_bi()
+        .await
+        .map_err(|error| format!("opening Iroh stream: {error}"))?;
+    timing.open_stream_ms = elapsed_ms(open_started_at);
+
+    let bridge_started_at = Instant::now();
+    write_json_frame(
+        &mut send,
+        &BridgeRequest::Connect {
+            v: PROTOCOL_VERSION,
+            token: request.pair_payload.token.clone(),
+            agent: FORGE_AGENT_NAME.to_string(),
+        },
+    )
+    .await?;
+    let ack: BridgeResponse = read_json_frame(&mut recv).await?;
+    validate_bridge_response(&ack)?;
+    timing.bridge_ack_ms = elapsed_ms(bridge_started_at);
+
+    let write_started_at = Instant::now();
+    write_json_frame(
+        &mut send,
+        &ForgeHttpRequest {
+            v: PROTOCOL_VERSION,
+            method: request.method,
+            path: request.path,
+            headers: request.headers,
+            body_base64: request.body_base64,
+        },
+    )
+    .await?;
+    timing.write_request_ms = elapsed_ms(write_started_at);
+
+    let response_started_at = Instant::now();
+    let response = tokio::time::timeout(
+        Duration::from_secs(60),
+        read_json_frame::<ForgeHttpResponse, _>(&mut recv),
+    )
+    .await
+    .map_err(|_| "timed out waiting for Forge Iroh response".to_string())??;
+    timing.response_wait_ms = elapsed_ms(response_started_at);
+    Ok((response, timing))
+}
+
+#[derive(Debug, Default)]
+struct IrohClientTiming {
+    connection_reused: bool,
+    connection_ms: u128,
+    open_stream_ms: u128,
+    bridge_ack_ms: u128,
+    write_request_ms: u128,
+    response_wait_ms: u128,
+    total_ms: u128,
+}
+
+impl IrohClientTiming {
+    fn to_header_value(&self) -> String {
+        format!(
+            "reused={},total={},connection={},openStream={},bridgeAck={},writeRequest={},responseWait={}",
+            if self.connection_reused { 1 } else { 0 },
+            self.total_ms,
+            self.connection_ms,
+            self.open_stream_ms,
+            self.bridge_ack_ms,
+            self.write_request_ms,
+            self.response_wait_ms
+        )
+    }
+}
+
+fn elapsed_ms(started_at: Instant) -> u128 {
+    started_at.elapsed().as_millis()
 }
 
 fn validate_pair_payload(payload: &PairPayload) -> Result<(), String> {
@@ -276,4 +466,73 @@ mod tests {
     fn proxy_path_rejects_absolute_urls() {
         assert!(validate_proxy_path("https://example.com/api/v1/health").is_err());
     }
+
+    #[test]
+    fn ffi_reuses_runtime_and_endpoint_between_requests() {
+        let state = ffi_state().expect("ffi state");
+        let first = state
+            .runtime
+            .block_on(state.cached_endpoint())
+            .expect("first endpoint");
+        let second = state
+            .runtime
+            .block_on(state.cached_endpoint())
+            .expect("second endpoint");
+
+        assert!(Arc::ptr_eq(&first, &second));
+    }
+
+    #[test]
+    fn connection_cache_key_tracks_remote_and_token() {
+        let payload = PairPayload {
+            v: PROTOCOL_VERSION,
+            node_id: "node-a".to_string(),
+            token: "token-a".to_string(),
+            host_name: Some("host".to_string()),
+            relay: Some("https://relay.example".to_string()),
+        };
+        let same = PairPayload {
+            host_name: None,
+            ..payload.clone()
+        };
+        let different_token = PairPayload {
+            token: "token-b".to_string(),
+            ..payload.clone()
+        };
+
+        assert_eq!(
+            ConnectionCacheKey::from_payload(&payload),
+            ConnectionCacheKey::from_payload(&same)
+        );
+        assert_ne!(
+            ConnectionCacheKey::from_payload(&payload),
+            ConnectionCacheKey::from_payload(&different_token)
+        );
+    }
+
+    #[test]
+    fn iroh_client_timing_header_names_response_wait() {
+        let timing = IrohClientTiming {
+            connection_reused: true,
+            connection_ms: 1,
+            open_stream_ms: 2,
+            bridge_ack_ms: 3,
+            write_request_ms: 4,
+            response_wait_ms: 5,
+            total_ms: 15,
+        };
+
+        assert_eq!(
+            timing.to_header_value(),
+            "reused=1,total=15,connection=1,openStream=2,bridgeAck=3,writeRequest=4,responseWait=5"
+        );
+    }
+
+    #[test]
+    fn ffi_runtime_keeps_up_with_foreground_health_sync_window() {
+        assert!(
+            FFI_RUNTIME_WORKER_THREADS >= FOREGROUND_HEALTH_SYNC_STREAMS,
+            "Iroh FFI runtime workers should not be narrower than foreground HealthKit streams"
+        );
+    }
 }

package/dist/companion-iroh-src/src/main.rs

@@ -1,5 +1,5 @@
 use std::path::{Path, PathBuf};
-use std::time::Duration;
+use std::time::{Duration, Instant};
 
 use anyhow::{Context, anyhow};
 use base64::Engine;
@@ -16,6 +16,7 @@ use tracing::{info, warn};
 use tracing_subscriber::EnvFilter;
 
 const MAX_FRAME_BYTES: usize = 50 * 1024 * 1024;
+const IROH_HOST_TIMING_HEADER: &str = "x-forge-iroh-host-timing-ms";
 
 #[derive(Parser, Debug)]
 #[command(version, about = "Forge Companion transport over Iroh QUIC")]
@@ -276,9 +277,12 @@ async fn proxy_http_request(
             .context("decoding request body")?;
         builder = builder.body(bytes);
     }
+    let request_started_at = Instant::now();
     let response = builder.send().await.context("forwarding HTTP request")?;
+    let upstream_response_ms = request_started_at.elapsed().as_millis();
     let status = response.status().as_u16();
-    let headers = response
+    let body_started_at = Instant::now();
+    let mut headers: Vec<HeaderPair> = response
         .headers()
         .iter()
         .filter_map(|(name, value)| {
@@ -292,6 +296,15 @@ async fn proxy_http_request(
         .bytes()
         .await
         .context("reading HTTP response body")?;
+    let body_read_ms = body_started_at.elapsed().as_millis();
+    let total_ms = request_started_at.elapsed().as_millis();
+    headers.push(HeaderPair {
+        name: IROH_HOST_TIMING_HEADER.to_string(),
+        value: format!(
+            "total={},upstreamResponse={},bodyRead={}",
+            total_ms, upstream_response_ms, body_read_ms
+        ),
+    });
     Ok(ForgeHttpResponse {
         v: PROTOCOL_VERSION,
         status,

package/dist/server/server/src/app.js

@@ -5455,16 +5455,18 @@ function buildAgentOnboardingPayload(request) {
             saveSuggestionTone: "gentle_optional",
             maxQuestionsPerTurn: 1,
             psycheExplorationRule: "When a Psyche entity needs understanding first, begin with one exploratory question before any working formulation, replacement belief, suggested title, or save pitch. Keep the opening reflection to one or two short sentences, stay in plain prose instead of bullets or numbered lists, keep that first reply short, do not mention Forge search or save structure yet, avoid colons or list-shaped phrasing, prefer what/when/how over why until the experience is grounded, wait for the user's answer before offering a fuller formulation, ask permission before moving from charged exploration into naming or challenge when needed, make the next question help the user feel more able to name the experience rather than more examined, do not widen into adjacent entities until the current one has a working sentence the user recognizes, and once the lived experience is coherent stop deepening and help the user name it cleanly. After one concrete example is clear and a hypothesis lands or is corrected, translate it into a saveable record shape such as a belief sentence, functional loop, behavior, mode, trigger report, value, event type, or emotion definition; ask one accuracy question instead of reopening broad exploration, then use the shared batch entity routes after the user accepts the wording or explicitly asks to save. When the user is updating a Psyche record because of one fresh episode, anchor in that episode before renaming the durable formulation, begin with the smallest part of the old wording that no longer fits, and do not reopen the full origin story unless the new understanding is truly structural. If the user accepts the wording, move toward the save instead of reopening deeper exploration.",
-            specializedSurfaceRule: "For Movement, Life Force, and Workbench, clarify the job first, then choose the dedicated route family internally and do not guess at a generic CRUD path. Use specializedDomainSurfaces.routeSelectionQuestions when they are present so the next follow-up selects the right route instead of asking generic questions. When available, use forge_call_movement_route, forge_call_life_force_route, or forge_call_workbench_route after the lane is clear. In user-facing language, talk about timeline, overlay, weekday template, published output, run detail, or node result rather than surfaces, payloads, read paths, mutation paths, or CRUD. If the truth of the current state is still uncertain, read the relevant dedicated view before you mutate it. When the user already named a precise correction or review target, confirm only the route-selecting detail that is still missing. After a concrete Movement, Life Force, or Workbench correction, read the relevant view back when the user is trying to understand the result rather than just store it. The canonical runtime routes stay under /api/v1/*, and the OpenClaw HTTP mirror exposes the same families under /forge/v1/movement, /forge/v1/life-force, and /forge/v1/workbench.",
+            progressiveDisclosureRule: "Treat partial answers as progress, not as failed intake. Before asking another question, identify what is already usable: operation, entity or surface, target record or time span, working wording, owner or placement, route lane, and consent. Say the usable part back briefly, then ask only for the first missing detail that changes the action: duplicate disambiguation, hierarchy parent, time window, weekday, flow, run, node, correction, link, or save consent. For normal batch entities, do not ask for optional tags, priority, status, dates, color, links, or assignees when the accepted wording and meaningful body are already enough unless that metadata changes accountability, retrieval, or execution. For Movement, Life Force, and Workbench, if the user's wording already implies the dedicated lane, skip the broad route-family question and ask only for the target span, place, weekday, profile field, flow, run, node, output, correction, or consent that is still missing. For direct Psyche saves or updates, treat an offered belief sentence, functional loop, part voice, trigger episode, value phrase, event kind, emotion signature, or flashcard message as real data; ask one accuracy or consent question instead of reopening origin, evidence, or repair.",
+            writeConfirmationRule: "After create, update, delete, restore, run, read, or repair actions, confirm the user-facing record, action, and result in the user's language instead of reopening intake. For batch creates and updates, confirm the working title or accepted wording, container, and owner or placement only when those changed retrieval, accountability, or execution; if optional tags, priority, status, color, links, dates, or assignees were left provisional, say that plainly once instead of asking for all of them. For action workflows, confirm the real product action such as task run started or completed, work adjustment applied, preference judgment or signal submitted, questionnaire run updated or completed, calendar connection synced, or self-observation note written. For Psyche saves, confirm the accepted wording and whether it was saved as a first version, update, link, archive, or distinct version; do not reopen origin, evidence, repair, or adjacent entity mapping after the save unless that next object is already visible and materially useful. Ask a follow-up only if it changes the next action: correction, link, schedule, run, publish, enrichment, preservation choice, or UI handoff.",
+            specializedSurfaceRule: "For Movement, Life Force, and Workbench, clarify the job first, then choose the dedicated route family internally and do not guess at a generic CRUD path. Use specializedDomainSurfaces.routeSelectionQuestions when they are present so the next follow-up selects the right route instead of asking generic questions. When available, use forge_call_movement_route, forge_call_life_force_route, or forge_call_workbench_route after the lane is clear. In user-facing language, talk about timeline, overlay, weekday template, published output, run detail, or node result rather than surfaces, payloads, read paths, mutation paths, or CRUD. If the truth of the current state is still uncertain, read the relevant dedicated view before you mutate it. When the user already named a precise correction or review target, confirm only the route-selecting detail that is still missing. After a concrete Movement, Life Force, or Workbench correction, mutation, or result-producing run, read the relevant view back when the user is trying to understand the result rather than just store it: timeline or place/settings detail for Movement, the Life Force overview for energy-planning impact, and flow detail, run detail, node result, latest node output, published output, or run history for Workbench. The canonical runtime routes stay under /api/v1/*, and the OpenClaw HTTP mirror exposes the same families under /forge/v1/movement, /forge/v1/life-force, and /forge/v1/workbench.",
             reviewShortcutRule: "When the user is reviewing or correcting an existing record, ask what practical question they want the read or correction to answer, then narrow the saved object, timeframe, or route family first. Use the correct read posture before asking write-shaped questions: shared batch search or read hints for normal entities, wiki/calendar dedicated reads for specialized CRUD, read-model routes for overviews, and Movement, Life Force, or Workbench dedicated reads for those domain surfaces. After the read, answer the practical question before asking for any save, correction, link, run, enrichment, or publish detail. Do not reopen the whole intake unless the user is actually redefining the record.",
             readModelWriteRule: "Self-observation is note-backed and should be written through observed notes with frontmatter.observedAt only when a lightweight episode observation is the right container. Do not use it as the default bucket for Psyche material: prefer trigger_report for one emotionally meaningful episode, behavior_pattern for functional analysis of a recurring loop, behavior for one repeated move, belief_entry for a core sentence, mode_guide_session or mode_profile for a central part-state, and wiki_page for durable memory such as books, articles, concepts, sources, or personal manuals. Sleep and workout sessions stay on batch CRUD by default; use the reflective review helpers only when enriching one already-known record after review.",
             psycheOpeningQuestionRule: "Prefer a concrete opening question tied to the entity: ask when the value mattered, what happened the last time the pattern appeared, what cue or body signal came first before the behavior, what the belief starts saying about self or outcome, what feels most at risk inside the mode, what the part is trying to get the user to do or stop doing, or where the shift began in the incident. Reflect briefly before the question, choose one follow-up lane at a time, say what is becoming clearer before the next deeper question, and if several Psyche entities are visible hold the adjacent ones lightly until the main container is clear.",
-            psycheHypothesisRule: "When one concrete Psyche example is visible, a helpful hypothesis should start from evidence in the user's own example, offer one testable interpretation, name the function without blame such as protection, prediction, relief, or cost, and ask whether the danger, need, or wording fits. Use the hypothesis timing checkpoint before asking a second or third deepening question: offer a hypothesis when one concrete episode, body cue, belief sentence, behavior, or mode voice is visible and the hypothesis would change the record shape, wording, links, or next action. Do not keep asking broad exploratory Psyche questions after the cue, meaning, protection, payoff, or cost is already visible. For behavior_pattern, belief_entry, mode_profile, mode_guide_session, and trigger_report, the next helpful move is usually one active formulation plus one correction question, not another passive reflection. Do not hypothesize yet when no concrete moment is visible, the user only wants a direct mechanical save, the user is flooded or unsafe, or the only available interpretation would be diagnosis-like, an origin story, or a certainty claim. Do not present schema, mode, belief, or pattern language as a verdict. If the user corrects the hypothesis, revise it once and move toward the saveable record shape instead of asking for another broad story.",
+            psycheHypothesisRule: "When one concrete Psyche example is visible, a helpful hypothesis should start from evidence in the user's own example, offer one testable interpretation, name the function without blame such as protection, prediction, relief, or cost, and ask whether the danger, need, or wording fits. Use the hypothesis timing checkpoint before asking a second or third deepening question: offer a hypothesis when one concrete episode, body cue, belief sentence, behavior, or mode voice is visible and the hypothesis would change the record shape, wording, links, or next action. Do not keep asking broad exploratory Psyche questions after the cue, meaning, protection, payoff, or cost is already visible. For behavior_pattern, belief_entry, mode_profile, mode_guide_session, and trigger_report, the next helpful move is usually one active formulation plus one correction question, not another passive reflection. Hypotheses should reduce the formulation burden. Do not make the user prove the experience: after one hypothesis, ask one fit-or-correction question rather than a stack of evidence, origin, and repair questions. If accuracy needs grounding, ask for the smallest lived cue or contrast that would change the wording, danger, protection, payoff, cost, or record shape. Do not hypothesize yet when no concrete moment is visible, the user only wants a direct mechanical save, the user is flooded or unsafe, or the only available interpretation would be diagnosis-like, an origin story, or a certainty claim. Do not present schema, mode, belief, or pattern language as a verdict. If the user corrects the hypothesis, revise it once and move toward the saveable record shape instead of asking for another broad story.",
             mixedIntentSequencingRule: "When one user message combines several Forge jobs, identify the primary job and the order of operations before asking a follow-up. If a read changes the truth of a later write, read first: Movement timeline or box detail before correction, Workbench run or node detail before editing or publishing, and Life Force overview before changing durable assumptions when the current energy picture is uncertain. If the user asks to understand and save Psyche material plus create a support record, formulate the primary Psyche record first, then derive the flashcard, note, link, task, or habit from the accepted wording. If the user already gave the concrete action, do not ask a broad lane question; say the product sequence briefly and ask only for the missing span, wording, flow, run, node, weekday, or link that changes the next action.",
             duplicateDisambiguationRule: "Before creating or updating a normal stored entity when duplicate risk is plausible, search the shared batch entity route by entity type, distinctive title or wording, owner scope, and linked content. If a likely existing record appears, ask whether the user wants to update that record, link to it, or save a separate new record; do not reopen the whole create flow. For Psyche records, a similar belief, pattern, mode, trigger report, value, or flashcard is a formulation choice, not a duplicate error: compare the sentence, cue/payoff/cost, protective job, episode, urge sentence, or message and let the user choose update, link, or new version. For wiki_page and calendar_connection, use dedicated search/list/read routes before creating another page or connection. For Movement, Life Force, and Workbench, use the dedicated read lanes instead of batch duplicate search.",
             destructiveActionRule: "Before deleting, archiving, invalidating, overwriting, disconnecting, or substantially replacing a Forge record or specialized object, confirm the exact target and what should remain understandable. Prefer normal soft-delete for stored entities unless the user explicitly asks for permanent removal. For Psyche records, preserve therapeutic history by asking whether the old belief, pattern, mode, trigger report, value, or flashcard should be updated, linked as history, archived, or kept distinct; do not delete it just because a cleaner formulation exists. For Movement, distinguish user-defined overlay deletion from automatic-box invalidation and stay/trip/point deletion, and read the specific span first when the target is uncertain. For calendar connections, Workbench flows, wiki pages, and questionnaire instruments, ask what downstream sync, published output, backlinks, run history, or completed runs should remain understandable before deleting or replacing the saved object.",
             followUpQuestionRule: "After a substantive answer, do not restart the opener or jump to the next schema field. First say what became clearer in concrete language, then choose exactly one next lane: wording, boundary, placement, timing, route scope, link, hypothesis, or write confirmation. Ask the smallest question that would change the record shape, route choice, useful wording, timing, or links. If nothing decision-relevant would change, stop asking, summarize the working record, and act with consent.",
-            antiDriftRule: "Avoid vague reflective filler and internal route language. Replace phrases like 'that sounds important' with the specific stake you heard, and replace API nouns like surface, CRUD, payload, mutation path, or endpoint with user-facing product nouns such as belief, pattern, note, wiki page, timeline, overlay, weekday template, flow, run, node result, or published output. If a question would only decorate the intake, skip it.",
+            antiDriftRule: "Avoid vague reflective filler and internal route language. Keep a private action trace: intent, entity or dedicated domain lane, exact read/write/run tool, required target identifiers, and the one missing detail that would change the action. Do not narrate that trace to the user. Replace phrases like 'that sounds important' with the specific stake you heard, and replace API nouns like surface, CRUD, payload, mutation path, route key, or endpoint with user-facing product nouns such as belief, pattern, note, wiki page, timeline, overlay, missing stay, weekday template, flow, run, node result, or published output. Ask one product-language question when the trace is unclear; with the user, ask about the real thing: the span, place, weekday, flow, run, node, belief sentence, parent record, or save confirmation. When reporting actions, say the product result first: saved the belief, corrected the missing stay, updated the weekday energy pattern, or read the failed node. Mention route keys, HTTP paths, payloads, or batch routes only for implementation debugging. If a question would only decorate the intake, skip it.",
             duplicateCheckRoute: "/api/v1/entities/search",
             uiSuggestionRule: "offer_visual_ui_when_review_or_editing_would_be_easier",
             browserFallbackRule: "Do not open the Forge UI or a browser just to create or update normal entities when the batch entity tools can do the job. Batch CRUD is the default for simple entities; avoid spamming the agent with a large one-route-per-entity mental model.",
@@ -8440,9 +8442,14 @@ export async function buildServer(options = {}) {
     });
     app.post("/api/v1/mobile/healthkit/sync-sessions/:id/chunks", { bodyLimit: 40_000_000 }, async (request) => {
         const { id } = request.params;
+        const startedAt = performance.now();
         const rawPayloadJson = JSON.stringify((request.body ?? {}).payload ?? {});
+        const chunk = ingestMobileHealthSyncChunk(id, mobileHealthSyncChunkSchema.parse(request.body ?? {}), rawPayloadJson);
         return {
-            chunk: ingestMobileHealthSyncChunk(id, mobileHealthSyncChunkSchema.parse(request.body ?? {}), rawPayloadJson)
+            chunk: {
+                ...chunk,
+                serverProcessingMs: Math.max(0, Math.round(performance.now() - startedAt))
+            }
         };
     });
     app.post("/api/v1/mobile/healthkit/sync-sessions/:id/complete", async (request) => {

package/dist/server/server/src/health.js

@@ -3347,78 +3347,6 @@ function applyWorkoutChunkImmediately(session, family, workouts) {
         }), workouts.length, createdCount, updatedCount, mergedCount, now, now, runId);
     });
 }
-function mobileSyncWorkoutRowsByExternalUid(userId, externalUids) {
-    const uniqueExternalUids = [...new Set(externalUids.filter(Boolean))];
-    const rowsByExternalUid = new Map();
-    const chunkSize = 500;
-    for (let lowerBound = 0; lowerBound < uniqueExternalUids.length; lowerBound += chunkSize) {
-        const chunk = uniqueExternalUids.slice(lowerBound, lowerBound + chunkSize);
-        if (chunk.length === 0) {
-            continue;
-        }
-        const placeholders = chunk.map(() => "?").join(", ");
-        const rows = getDatabase()
-            .prepare(`SELECT *
-         FROM health_workout_sessions
-         WHERE user_id = ?
-           AND source = 'apple_health'
-           AND external_uid IN (${placeholders})`)
-            .all(userId, ...chunk);
-        for (const row of rows) {
-            rowsByExternalUid.set(row.external_uid, row);
-        }
-    }
-    return rowsByExternalUid;
-}
-function applyWorkoutEvidenceChunkImmediately(session, payload) {
-    const timeSeries = payload.workoutTimeSeries ?? [];
-    const routes = payload.workoutRoutes ?? [];
-    if (timeSeries.length === 0 && routes.length === 0) {
-        return;
-    }
-    const pairing = mobileSyncSessionPairing(session);
-    runInTransaction(() => {
-        const rowsToRecompute = new Map();
-        const rowsByExternalUid = mobileSyncWorkoutRowsByExternalUid(pairing.user_id, [
-            ...timeSeries
-                .filter((entry) => entry.samples.length > 0)
-                .map((entry) => entry.externalUid),
-            ...routes
-                .filter((entry) => entry.routePoints.length > 0)
-                .map((entry) => entry.externalUid)
-        ]);
-        for (const entry of timeSeries) {
-            const row = rowsByExternalUid.get(entry.externalUid);
-            if (!row || entry.samples.length === 0) {
-                continue;
-            }
-            upsertWorkoutTimeSeries({
-                workoutId: row.id,
-                userId: pairing.user_id,
-                samples: entry.samples
-            });
-            rowsToRecompute.set(row.id, row);
-        }
-        for (const entry of routes) {
-            const row = rowsByExternalUid.get(entry.externalUid);
-            if (!row || entry.routePoints.length === 0) {
-                continue;
-            }
-            upsertWorkoutRoutePoints({
-                workoutId: row.id,
-                userId: pairing.user_id,
-                points: entry.routePoints
-            });
-            rowsToRecompute.set(row.id, row);
-        }
-        for (const row of rowsToRecompute.values()) {
-            recomputeAndStoreWorkoutAnalytics(row);
-        }
-        for (const dateKeyValue of new Set([...rowsToRecompute.values()].map((row) => dayKey(row.started_at)))) {
-            summarizeUserHealthDay(pairing.user_id, dateKeyValue);
-        }
-    });
-}
 function markMobileHealthSyncChunkApplied(input) {
     const now = nowIso();
     getDatabase()
@@ -3474,8 +3402,10 @@ function applyMobileHealthSyncChunkImmediately(session, family, payload) {
             return "workout_progressive_apply";
         case "workout_time_series":
         case "workout_routes":
-            applyWorkoutEvidenceChunkImmediately(session, payload);
-            return "workout_evidence_progressive_apply";
+            // Evidence chunks can be very large. Applying them here made the phone wait
+            // for route/sample upserts plus analytics recomputation before each chunk
+            // response. Store them quickly and apply once during completion instead.
+            return null;
         case "movement":
             return applyMovementChunkImmediately(session, payload)
                 ? "movement_progressive_apply"
@@ -3733,8 +3663,10 @@ function mergeMobileHealthSyncChunks(session, chunks, options = {}) {
     const workoutsByExternalUid = new Map();
     const tombstones = [];
     for (const chunk of chunks.sort((left, right) => left.sequence - right.sequence)) {
+        const keepWorkoutSummaryForDeferredEvidence = chunk.family === "workout_summaries" || chunk.family === "workout_archive";
         const skipRecords = options.skipImmediatelyApplied === true &&
-            mobileHealthSyncChunkWasImmediatelyApplied(chunk);
+            mobileHealthSyncChunkWasImmediatelyApplied(chunk) &&
+            keepWorkoutSummaryForDeferredEvidence === false;
         if (skipRecords) {
             continue;
         }
@@ -3967,7 +3899,10 @@ function listMobileSyncCompletionChunks(syncSessionId) {
         .prepare(`SELECT id, payload_json
        FROM health_mobile_sync_chunks
        WHERE sync_session_id = ?
-         AND applied_at IS NULL`)
+         AND (
+           applied_at IS NULL
+           OR family IN ('workout_summaries', 'workout_archive')
+         )`)
         .all(syncSessionId);
     if (payloadRows.length === 0) {
         return chunks;

package/dist/server/server/src/services/companion-iroh.js

@@ -23,6 +23,16 @@ export async function buildCompanionPairingTransport(input) {
             "Manual HTTP/TCP pairing was explicitly requested."
         ]);
     }
+    if (selectedFallback) {
+        const fallbackMode = fallbackModeFor(selectedFallback.apiBaseUrl, input.fallbackMode);
+        return manualHttpTransport(selectedFallback.apiBaseUrl, selectedFallback.uiBaseUrl, [
+            fallbackMode === "tailscale"
+                ? "Tailscale HTTPS pairing was selected as the primary companion transport."
+                : "A phone-reachable direct companion URL was selected as the primary transport.",
+            "Forge did not include Iroh transport metadata because direct pairing is active.",
+            "Run pairing again without a phone-facing public URL if you want an Iroh pairing instead."
+        ]);
+    }
     if (!shouldAutoStartIrohHost()) {
         return manualHttpTransport(requestApiBaseUrl, requestUiBaseUrl, [
             "Forge Iroh companion transport is unavailable in this runtime, so Forge fell back to direct HTTP."
@@ -34,18 +44,14 @@ export async function buildCompanionPairingTransport(input) {
             pairPayload: snapshot.pairPayload,
             alpn: snapshot.alpn ?? COMPANION_IROH_ALPN,
             localBaseUrl: snapshot.localBaseUrl,
-            fallbackApiBaseUrl: selectedFallback?.apiBaseUrl ?? null,
-            fallbackUiBaseUrl: selectedFallback?.uiBaseUrl ?? null,
-            fallbackMode: selectedFallback
-                ? fallbackModeFor(selectedFallback.apiBaseUrl, input.fallbackMode)
-                : "none",
+            fallbackApiBaseUrl: null,
+            fallbackUiBaseUrl: null,
+            fallbackMode: "none",
             recreateCommand: snapshot.recreateCommand ?? undefined,
             startedAt: snapshot.startedAt ?? undefined,
             notes: [
                 "Default pairing uses Forge's Rust Iroh transport over QUIC first.",
-                selectedFallback
-                    ? "The QR includes the selected direct URL only as an explicit fallback/direct path."
-                    : "No direct HTTP fallback was selected for this QR.",
+                "No direct HTTP fallback was selected for this QR.",
                 "The QR payload carries the Iroh node id, host token, optional relay, and ALPN forge-companion/1.",
                 "Manual HTTP/TCP pairing remains available with --manual-http for advanced local setups."
             ]

package/openclaw.plugin.json

@@ -2,7 +2,7 @@
   "id": "forge-openclaw-plugin",
   "name": "Forge",
   "description": "Curated OpenClaw adapter for the Forge collaboration API, UI entrypoint, and localhost auto-start runtime.",
-  "version": "0.3.9",
+  "version": "0.3.11",
   "activation": {
     "onStartup": true,
     "onCapabilities": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forge-openclaw-plugin",
-  "version": "0.3.9",
+  "version": "0.3.11",
   "description": "Curated OpenClaw adapter for the Forge collaboration API, UI entrypoint, and localhost auto-start runtime.",
   "type": "module",
   "license": "Apache-2.0",

package/skills/forge-openclaw/SKILL.md

@@ -70,6 +70,14 @@ stored-entity CRUD, an action workflow, specialized CRUD, or a specialized domai
 surface. Name the path plainly enough that another agent could follow it without
 guessing.
 
+Keep that route plan internal unless the user asks for implementation detail. Track
+the intent, entity or dedicated domain lane, exact tool or route key, target
+identifiers, and one missing detail privately; with the user, ask about the real
+thing: the span, place, weekday, flow, run, node, belief sentence, parent record, or
+save confirmation. Report product actions such as "saved the belief", "corrected the
+missing stay", "updated the weekday energy pattern", or "read the failed node" before
+any route-key or endpoint detail.
+
 - Batch CRUD is the default for normal stored entities, including `goal`, `project`,
   `strategy`, `task`, `habit`, `tag`, `note`, `insight`, `calendar_event`,
   `work_block_template`, `task_timebox`, all main Psyche records, basic Preferences
@@ -243,6 +251,14 @@ Entity conversation rule:
   time scope, and any ownership/placement that changes later use are already clear,
   summarize once and write, read, run, or update instead of collecting optional
   fields.
+- Treat partial answers as progress. Before another follow-up, identify what is
+  already usable: operation, entity or surface, target record or time span, working
+  wording, owner or placement, route lane, and consent. Ask only for the first missing
+  detail that changes the action: duplicate disambiguation, hierarchy parent, time
+  window, weekday, flow, run, node, correction, link, or save consent.
+- Do not ask for optional tags, priority, status, dates, color, links, or assignees
+  when accepted wording and meaningful body are enough unless that metadata changes
+  accountability, retrieval, or execution.
 - Let each question have one job. Know what you are trying to clarify before you ask it.
 - Before you ask, decide the exact missing thing you need and how that answer will help you name, place, or save the record.
 - Prefer a progression of:
@@ -271,6 +287,19 @@ Entity conversation rule:
   Movement, Life Force, or Workbench dedicated reads for those domain surfaces. After
   the read, answer the practical question before asking for any save, correction,
   link, run, enrichment, or publish detail.
+- After create, update, delete, restore, run, read, or repair actions, confirm the
+  user-facing record, action, and result in the user's language instead of reopening
+  intake. For batch creates and updates, confirm the working title or accepted wording,
+  container, and owner or placement only when those changed retrieval, accountability,
+  or execution; if optional tags, priority, status, color, links, dates, or assignees
+  were left provisional, say that plainly once. For action workflows, confirm the real
+  product action: task run started or completed, work adjustment applied, preference
+  judgment or signal submitted, questionnaire run updated or completed, calendar
+  connection synced, or self-observation note written. For Psyche saves, confirm the
+  accepted wording and whether it was saved as a first version, update, link, archive,
+  or distinct version; do not reopen origin, evidence, repair, or adjacent entity
+  mapping after the save unless that next object is already visible and materially
+  useful.
 - When updating an entity, start with what is changing, what should stay true, and what prompted the update now.
 - When enough is clear, briefly summarize what you heard in the user's own language before asking for the last missing structural detail.
 - Treat `userId` and human/bot assignees as accountability and scope, not as opening form fields. Ask whose human or bot record it is only when ownership changes visibility, review scope, collaboration, automation behavior, or later filtering; for read requests, ask user scope only when the answer would differ across owners.
@@ -300,6 +329,7 @@ Psyche interview rule:
 - After the first real answer, choose one follow-up lane at a time: situation, sequence, meaning, protection, cost, longing/value, or tentative name.
 - Do not minimize functional analysis, trigger chains, behavior patterns, modes, beliefs, or schema themes. Once at least one concrete example is clear, offer one careful interpretive hypothesis when it would help the user understand the function, protection, cost, belief, mode, or schema theme.
 - Phrase interpretive hypotheses as collaborative and testable, not as verdicts. A good hypothesis says what the reaction may be protecting, predicting, relieving, or costing, then asks whether that lands or needs correction.
+- For Psyche hypotheses, reduce the formulation burden. After one concrete example, offer one tentative function, danger, protection, payoff, or cost hypothesis and ask one fit-or-correction question. Do not make the user prove the experience, list evidence, or design repair before the wording feels held.
 - Do not keep asking broad exploratory Psyche questions after the cue, meaning, protection, payoff, or cost is already visible. For `behavior_pattern`, `belief_entry`, `mode_profile`, `mode_guide_session`, and `trigger_report`, the next helpful move is usually one active formulation plus one correction question, not another passive reflection.
 - Use the hypothesis timing checkpoint before asking a second or third deepening question: offer a hypothesis when one concrete episode, body cue, belief sentence, behavior, or mode voice is visible and the hypothesis would change the record shape, wording, links, or next action. Do not hypothesize yet when no concrete moment is visible, the user only wants a direct mechanical save, the user is flooded or unsafe, or the only available interpretation would be diagnosis-like, an origin story, or a certainty claim.
 - If several Psyche containers are plausible, do not ask the user to choose from a taxonomy menu first. Reflect the lived difference, offer one careful hypothesis when a concrete example is visible, then distinguish the options in plain language: one episode as a `trigger_report`, a recurring loop as a `behavior_pattern`, one repeated move as `behavior`, one sentence as `belief_entry`, a part-state as `mode_profile` or `mode_guide_session`, or reusable future-labeling as `event_type` or `emotion_definition`.
@@ -320,6 +350,10 @@ Psyche interview rule:
 - If the user already offers a usable belief sentence, value phrase, or mode name,
   refine from their wording first instead of replacing it with a cleaner label too
   early.
+- If the user already offers a usable belief sentence, functional loop, part voice,
+  trigger episode, value phrase, event kind, emotion signature, or flashcard message,
+  treat it as real data and ask one accuracy or consent question instead of reopening
+  origin, evidence, or repair.
 - When the conversation reveals an adjacent entity such as a linked belief, mode, value, pattern, or note, name that gently and ask whether the user wants to map it too.
 - If nuance matters, preserve it in a linked Markdown `note` instead of forcing every detail into normalized fields.
 - If the user shows imminent risk of self-harm, suicide, violence, inability to stay safe, or severe disorientation, stop normal intake and prioritize urgent human support or emergency help instead.
@@ -621,7 +655,7 @@ through `forge_create_entities` or `forge_update_entities`.
   into a new run, note, or generic entity update unless the user asks for that.
 - If you are unsure which specialized route family applies, check `forge_get_agent_onboarding` and use its `entityRouteModel.specializedDomainSurfaces` section before guessing.
 - If the truth of the current Movement, Life Force, or Workbench state is still unclear, prefer the dedicated read before the mutation so the correction stays truthful.
-- After a concrete Movement, Life Force, or Workbench correction, read the relevant specialized view back when the user is trying to understand the result rather than only store it.
+- After a concrete Movement, Life Force, or Workbench correction, mutation, or result-producing run, read the relevant specialized view back when the user is trying to understand the result rather than only store it: timeline or place/settings detail for Movement, the Life Force overview for energy-planning impact, and flow detail, run detail, node result, latest node output, published output, or run history for Workbench.
 
 Use live work tools for `task_run`:
 `forge_log_work`, `forge_start_task_run`, `forge_heartbeat_task_run`, `forge_focus_task_run`, `forge_complete_task_run`, `forge_release_task_run`

package/skills/forge-openclaw/entity_conversation_playbooks.md

@@ -101,6 +101,10 @@ Forge correctly, and gather only the structure that still matters.
   opener. Move straight to the next missing clarification.
 - After a substantive answer, briefly say what is becoming clear so the user can
   correct the direction early.
+- Treat partial answers as progress. Before asking again, mark what the user already
+  supplied: the operation, container, target record or span, working wording, route
+  lane, placement, and consent. Ask only for the first missing detail that would
+  change the save, read, run, correction, or link.
 - Once the record is clear enough to name, stop exploring broadly and ask only for the
   last missing structural detail.
 - When the record is already clear enough to save, save it instead of performing a
@@ -120,6 +124,24 @@ With the user, say the human thing:
 The API path still matters, but it should not leak into the question unless the user
 is explicitly asking about implementation.
 
+## Internal action trace, external wording
+
+Before you ask or act, keep a private action trace: intent, entity or dedicated
+domain lane, exact read/write/run tool, required target identifiers, and the one
+missing detail that would change the action. Do not narrate that trace to the user.
+
+- If the trace is clear, ask the user only for the missing real-world detail:
+  which span, place, weekday, flow, run, node, belief sentence, parent record, or
+  save confirmation.
+- If the trace is not clear, ask one product-language question that resolves it
+  instead of presenting API options.
+- When you report what you did, say the product action first: saved the belief,
+  corrected the missing stay, updated the weekday energy pattern, read the failed
+  node, or published the flow output. Mention route keys, HTTP paths, payloads, or
+  batch routes only for implementation debugging.
+- This is especially important after mixed-intent requests. The user should feel a
+  coherent sequence, not see your internal routing table.
+
 ## Dedicated surface lane translation
 
 Use this when Movement, Life Force, or Workbench work needs a route choice. The route
@@ -138,6 +160,28 @@ choice is an internal classification step, not a user-facing menu.
 - Once the lane is selected, use the exact route key internally and do not invent a
   friendlier path.
 
+## Dedicated surface verification loop
+
+Use this after a Movement, Life Force, or Workbench mutation or result-producing run.
+The dedicated route family is not finished just because a write returned `ok`.
+
+- After Movement overlays, place edits, settings changes, stay/trip repairs, or
+  deletion/invalidation work, read back the timeline, place list, settings, box
+  detail, or selection view that proves the user's practical question was answered.
+- After Life Force profile edits, weekday-template edits, or fatigue signals, read
+  the overview back when the user is making a planning decision or wants to understand
+  the practical impact of the change.
+- After Workbench flow creation/edit/deletion, saved-flow execution, one-off
+  execution, chat follow-up, or publish-related work, read back the flow detail, run
+  detail, node result, latest node output, published output, or run history that
+  matches the user's real goal.
+- Do not perform a read-back as ceremony when the user only asked for a narrow save
+  and the write response already gives enough confirmation. Use it when it changes
+  understanding, verifies a repair, or grounds the next decision.
+- In user-facing language, say what you checked: the corrected span, the weekday
+  energy picture, the flow result, the node output, or the published artifact. Keep
+  route keys and HTTP paths internal unless the user asks for implementation detail.
+
 ## Mixed-intent sequencing
 
 Use this when one user message combines several Forge jobs, such as "review this and
@@ -187,6 +231,30 @@ worked.
   write at all. Do not widen into a new taxonomy choice unless the read made the
   container genuinely ambiguous.
 
+## Write/read/run confirmation loop
+
+Use this after create, update, delete, restore, run, read, or repair actions. The
+agent should close the loop in the user's language instead of reopening intake.
+
+- Confirm the user-facing record, action, and result, not the internal route. Mention
+  the route family only if the user asked for implementation detail or the agent is
+  reporting an API-contract problem.
+- For batch creates and updates, confirm the working title or accepted wording, the
+  container, and the owner or placement only when those changed later retrieval,
+  accountability, or execution.
+- If optional tags, priority, status, color, links, dates, or assignees were left
+  provisional, say that plainly once instead of asking for all of them.
+- For action workflows, confirm the real product action: task run started or
+  completed, work adjustment applied, preference judgment or signal submitted,
+  questionnaire run updated or completed, calendar connection synced, or
+  self-observation note written.
+- For specialized Movement, Life Force, and Workbench actions, pair the confirmation
+  with the dedicated verification loop only when the read-back changes understanding,
+  proves a repair, or grounds the next decision.
+- Ask a follow-up only if it changes the next action: a correction, link, schedule,
+  run, publish, enrichment, preservation choice, or UI handoff. If the action is
+  complete and no decision-relevant next step is visible, stop cleanly.
+
 ## Review-before-write checkpoint
 
 Use this when the user asks to review, guide, inspect, compare, or understand before
@@ -269,6 +337,35 @@ but not necessarily a full Psyche formulation: `questionnaire_instrument`,
   uses questionnaire run actions; `self_observation` is note-backed; `wiki_page` uses
   the wiki routes.
 
+## Progressive disclosure after partial answers
+
+Use this when the user has already given part of the answer. The next question should
+show that you heard what is already settled.
+
+- First identify what is already usable: operation, entity or surface, target record,
+  time span, working wording, owner or placement, route lane, and consent.
+- Say the usable part back briefly, then ask only for the first missing detail that
+  would change the action: duplicate disambiguation, hierarchy parent, time
+  window, weekday, flow, run, node, correction, link, or save consent.
+- For normal batch entities, if the accepted title or distinctive wording and the
+  meaningful body are present, do not ask for tags, priority, status, color, links,
+  dates, or assignees unless that metadata changes accountability, retrieval, or
+  execution.
+- For specialized Movement, Life Force, and Workbench work, if the user's wording
+  already implies the lane, skip the route-family question and ask only for the
+  target span, place, weekday, profile field, flow, run, node, output, correction, or
+  consent that is still missing.
+- For review-first work, once the practical question and scope are clear, read before
+  asking about the possible write. Do not ask the user to design a report shape unless
+  the answer would change the read.
+- For direct Psyche saves or updates, if the user has already given a usable belief
+  sentence, functional loop, part voice, trigger episode, value phrase, event kind,
+  emotion signature, or flashcard message, ask one accuracy or consent question
+  instead of reopening origin, evidence, or repair.
+- If the remaining unknown is only decorative optional metadata, state the provisional
+  choice and act with consent. The flow should feel like progressive clarification,
+  not a restarted form.
+
 ## Conversation arc
 
 Most good Forge intake flows follow this sequence:
@@ -1934,6 +2031,9 @@ Direct action rules:
 - For known-place creation or cleanup, ask what the place should be called, what
   counts inside its boundary, and how future movement reads should use it. Use the
   dedicated place routes, not a tag or batch entity write.
+- After a Movement repair, known-place edit, settings change, overlay deletion, or
+  automatic-box invalidation, verify through the relevant dedicated read when the
+  user is trying to understand whether the movement picture is now truthful.
 
 Helpful follow-up lanes:
 
@@ -2064,6 +2164,9 @@ Direct action rules:
   then read the overview back if they want to see the updated picture.
 - After a profile or weekday-template change, read the overview back when the user is
   trying to understand the practical impact of the change, not just store it silently.
+- After a fatigue signal, profile patch, or weekday-template edit, verify through the
+  Life Force overview when the next planning decision depends on the updated energy
+  picture.
 
 Ready to act when:
 
@@ -2176,6 +2279,10 @@ Direct action rules:
 - For flow chat follow-ups, use the saved flow chat route only when the user wants to
   continue a flow-specific conversation. Do not turn a chat follow-up into a new flow
   run, note, or generic entity update unless that is what the user asks for.
+- After Workbench execution, flow edits, chat follow-ups, or publish-related work,
+  verify through the matching dedicated read: run detail, node result, latest node
+  output, flow detail, run history, or published output. Do not leave a run or edit
+  as an abstract success message when the user asked to inspect or use the result.
 
 Ready to act when:
 

package/skills/forge-openclaw/psyche_entity_playbooks.md

@@ -256,6 +256,28 @@ example makes the hypothesis plausible, then let the user correct the danger,
 protection, payoff, cost, or wording. If the correction is usable, revise once and move
 toward the record shape instead of asking for another broad story.
 
+## Hypothesis Without Cross-Examination
+
+A hypothesis is meant to reduce the user's burden of formulation, not make them prove
+the experience. It should help the user feel, "yes, that is closer to what is
+happening," or "no, the danger is actually over here."
+
+- Do not turn a tentative formulation into a demand for evidence. Avoid following a
+  hypothesis with a stack of questions about evidence, origin, and repair.
+- After a hypothesis, ask one fit-or-correction question such as, "Does that fit, or
+  is the danger/need somewhere else?"
+- If accuracy still needs grounding, ask for the smallest lived cue or contrast that
+  would change the formulation, not a courtroom-style proof.
+- For `belief_entry`, test the sentence, prediction, or danger it names.
+- For `behavior_pattern`, test the cue, protection, short-term payoff, long-term
+  cost, or replacement need.
+- For `mode_profile` and `mode_guide_session`, test the part's job, fear, burden, or
+  impulse.
+- For `trigger_report`, test the sequence, meaning, felt stake, or consequence.
+- For `psyche_value`, `event_type`, and `emotion_definition`, test whether the wording
+  would help future recognition rather than asking the user to justify why the record
+  matters.
+
 ## Hypothesis To Record Bridge
 
 Once a hypothesis lands or is corrected, turn it into a saveable Forge shape instead
@@ -276,6 +298,28 @@ of leaving it as warm reflective prose.
 - Save through shared batch entity routes only after the user accepts the working
   wording or explicitly asks to save.
 
+## Psyche progressive disclosure
+
+Use this when the user has already supplied meaningful Psyche material. The next move
+should preserve momentum instead of making them retell the whole story.
+
+- Treat an offered belief sentence, value phrase, part voice, urge sentence, trigger
+  episode, event kind, emotion signature, or functional loop as real data, not as a
+  prompt to restart intake.
+- Say what is already usable in plain language, then ask only for the missing detail
+  that changes the record: accuracy, the cue or situation, payoff or cost, protective
+  job, linked episode, whether it is a new version or an update, or save consent.
+- If the user's wording is serviceable, keep it and refine at most one phrase. Do not
+  replace it with a prettier formulation before the user feels recognized.
+- If the user asks to update a Psyche record and already gives the new wording, ask
+  what part of the old formulation it replaces or whether it should stand as a new
+  version. Do not reopen origin, evidence, or repair unless the new meaning is still
+  unclear.
+- If the working material is already accurate enough, ask one accuracy or consent
+  question instead of reopening origin, evidence, or repair.
+- If the remaining unknown is optional therapeutic metadata, save a provisional
+  version after one accuracy check and preserve nuance in a linked note when needed.
+
 ## Psyche save-readiness checkpoint
 
 Use this before asking another deepening question. Psyche work should feel careful,
@@ -307,6 +351,23 @@ save the record instead of reopening the whole story.
 - After the minimum is present, ask one accuracy question at most: "Is this true
   enough to save as a first version?" If yes, save through shared batch CRUD.
 
+## Psyche after-save close
+
+Use this after a Psyche record is created or updated. The user should feel the
+formulation was held accurately, not that a new worksheet has started.
+
+- Confirm the accepted wording, primary container, and whether it was saved as a
+  first version, update, link, archive, or distinct version.
+- Do not reopen origin, evidence, repair, or adjacent entity mapping after the save.
+  Only offer a flashcard, note, value link, task, or habit when that next object is
+  already visible and would materially help retrieval or action.
+- If nuance was preserved in a linked note or left provisional, say that briefly and
+  keep the door open for later correction without asking another broad exploration
+  question.
+- For belief, pattern, mode, trigger report, value, event type, emotion definition,
+  or flashcard saves, the clean close is one accurate sentence plus any concrete next option
+  that genuinely follows from the user's request.
+
 ## Psyche Hypothesis Map
 
 Use these shapes after at least one concrete example is clear. The hypothesis should