hermes - 💡(How to fix) Fix Background process completion notifications truncate output without marker [1 comments, 1 participants]

Bug Description

Background process completion notifications can truncate the beginning of command output without making the truncation explicit. In a long-running process demo, the notification started mid-line (g / down-right / inspecting-detail) and omitted the first completed rows, so the user could not tell whether the early steps had run unless the agent had separate state verification.

This is a low-severity observability/UX bug, but it matters for long-running demos, review scripts, and watchdog jobs where the completion notification is treated as the evidence record.

Evidence from live run

A background process was started with terminal(background=true, notify_on_complete=true) to cycle a Raspberry Pi presence display through 21 expressions, one minute each.

The completion notification reported exit code 0, but the captured output began mid-stream:

[IMPORTANT: Background process proc_378f6708df1a completed (exit code 0).
Command: bash /tmp/hamp_presence_expression_cycle.sh
Output:
g / down-right / inspecting-detail
[2026-05-10T16:44:49+02:00] 05 thinking-mode -> thinking / up-right / thinking-mode
...
[2026-05-10T17:01:49+02:00] demo complete: back to listening -> listening / center / listening-focus
Final state:
{
  "event": {
    "type": "state.change",
    "state": "listening",
    "gaze": "center",
    "behavior": "listening-focus",
    "source": "whatsapp/expression-demo-20260510",
    "messagePreview": null,
    "timestamp": "2026-05-10T15:01:49.770Z",
    "priority": 70
  },
  "expiresAt": null,
  "remainingTtlMs": null
}
Connection to 192.168.20.193 closed.
]

The missing start should have included rows such as 01 neutral-idle, 02 listening-focus, etc. The agent had already verified the first state separately, so this was not a failed demo, but the notification itself was incomplete.

Expected Behavior

When a background process completes and Hermes delivers the notification, one of these should be true:

1. Include the complete output if it is within limits; or
2. If output is truncated, explicitly mark it, for example:
   • [output truncated: showing last N lines / first M lines omitted]
   • include both head and tail snippets; and/or
   • provide a stable process log handle/instruction such as process log <id> for full retrieval.

The notification should not start mid-line without a truncation marker.

Actual Behavior

The completion notification started mid-line and omitted earlier output without an explicit truncation marker.

Suggested Fix

• Make background completion delivery truncation explicit.
• Prefer preserving line boundaries when trimming output.
• Consider including both head and tail for long outputs, or include counts: total bytes/lines, shown bytes/lines, omitted bytes/lines.
• If full output is retained by the process manager, include a stable reference so the user/agent can retrieve it.

Environment / Context

• Interface: WhatsApp gateway session
• Tool pattern: terminal(background=true, notify_on_complete=true) followed by background completion notification
• Repo where observed: Hermes Agent runtime, not the presence-display app
• Severity: P3 — low severity, evidence/logging UX

Acceptance Criteria

• A test covers a background process whose output exceeds the notification cap.
• The delivered completion message includes an explicit truncation marker.
• Truncation does not split the first displayed line mid-line unless clearly marked.
• The user has a way to retrieve or identify the full process log when available.