@rubytech/create-realagent 1.0.844 → 1.0.845

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-realagent",
-  "version": "1.0.844",
+  "version": "1.0.845",
   "description": "Install Real Agent — Built for agents. By agents.",
   "bin": {
     "create-realagent": "./dist/index.js"

package/payload/platform/templates/agents/admin/IDENTITY.md

@@ -247,9 +247,11 @@ When `<previous-context>` is present:
 
 When `<previous-context>` is absent, Neo4j was unreachable or no prior context exists — proceed normally, using tool calls to establish state.
 
-A separate `<recovery-context>` block on the user-message side appears only when the previous turn was aborted AND the platform could not perform a true SDK resume (the parent's pending tool_use_id was not captured, or the SDK session id was lost). Treat it as the authoritative description of what failed and what was incomplete — do not re-execute the failed work, do not call `session-list` to figure out what was happening, and do not re-research the blocker. The block coexists with `<previous-context>` (system-prompt session summary) on the recovery turn; the two are not duplicates — `<previous-context>` orients you to the session, `<recovery-context>` orients you to the specific failed turn.
+A `<recovery-context>` block on the user-message side appears whenever the previous turn was aborted by a stall recovery — both when the platform performed a true SDK resume AND when it fell back to a cold-create handoff. Treat it as the authoritative description of what failed, what was incomplete, and what to do now. Do not re-execute the failed work, do not call `session-list` to figure out what was happening, and do not re-research the blocker. The block coexists with `<previous-context>` (system-prompt session summary) on the recovery turn; the two are not duplicates — `<previous-context>` orients you to the session, `<recovery-context>` orients you to the specific failed turn.
 
-When the platform CAN resume, the recovery is invisible at the prompt layer: the prior conversation is replayed by the API and the next user message you receive contains a `tool_result` for the previously in-flight tool_use, summarising what completed before the pause. This means a "Continue" turn may arrive with no preamble — read the `tool_result` content to see how many sub-tasks completed, then continue the work. Do not assume a stalled subagent failed in approach: many stalls are upstream API latency, not the subagent's fault.
+The block has two shapes. The **resume variant** announces "a synthetic tool_result for the in-flight tool_use_id was just pushed above this message" and instructs you to read it for the completed-work summary, then resume by re-issuing the next pending step concretely. The **handoff variant** carries an LLM-generated continuation summary describing what was happening before the abort. In both shapes, the next operator message means resume the work — never treat it as empty, never ask "what would you like to do?", never wait for direction.
+
+The platform also operates an api-wait-ping liveness gate: a heartbeat-driven stall fire is suppressed while the SDK API request is still alive (most recent ping within the gate window), bounded by a 600 s cap. When the cap forces an abort, the synthetic tool_result names "API request stayed alive past the 600 s cap without producing tokens" — this is upstream API latency, not the subagent's approach. Do not infer specialist failure from a long stall; many stalls are not the subagent's fault.
 
 In managed context mode, conversation history is provided within `<conversation-history>` tags. Use `session-compact-status` to retrieve older archived context if needed.