Skip to content

openclaw: harden 1.0 presentation and monitor delivery - #158

Draft
morajabi wants to merge 7 commits into
claude/openclaw-1.0from
codex/openclaw-1-review
Draft

morajabi wants to merge 7 commits into
claude/openclaw-1.0from
codex/openclaw-1-review

Conversation

@morajabi

@morajabi morajabi commented Nov 7, 2026

Copy link
Copy Markdown
Contributor

Review follow-up stacked on #157. The phase-1 migration is a useful foundation; this fixes concrete presentation and delivery gaps found by comparing OpenClaw 2026.11.1/current source, native Discord/Slack/Telegram adapters, Hermes, bridge v2, and current Inline primitives.

  • Preserve typed command buttons/select options as system-owned actions while opaque callbacks remain agent-owned. Omit disabled actions and map primary/destructive styles.
  • Retain canonical presentation fallback alongside authored text; honor authored fallback mode and avoid rendering the same presentation twice.
  • Recheck cancellation when borrowing, connecting, and invoking a shared-client lease without closing the monitor's connection.
  • Route all 15 direct monitor sends through bounded server flood-wait recovery with stable random IDs. Never retry transport uncertainty or unknown commit outcomes in this helper.
  • Use the SDK's named Working enum and remove the duplicate monitor button parser.

The internal rendered-button data now carries explicit command-kind metadata. Inline protocol, wire fields, database, and plugin configuration schema are unchanged. No version bump or release.

The source-backed review and remaining 1.0 plan explains the larger work still needed: inbound receipt ownership and metadata recovery, published output-settings APIs, composer integration, Detailed progress, grant-backed approvals, Auto-thread session continuity, and real-host bot hand-backs. The monitor retry helper is not a durable outbox.

Validation: bun run check passes type checking, lint, 48 test files / 770 tests with coverage, packed-artifact validation, and the runtime/declaration build. New regressions exercise typed-button dispatch through the monitor, disabled controls, URL fallback, cancellation, flood waits, stable send identity, and uncertain outcomes. A real gateway/live bots were not used.

Base is the existing 1.0 branch so the diff contains only this review's fixes.

Approvals, command auth, arg menus, session reads and patches, skill
command listing and remote media now use the async replacements that
2026.11.1 ships, ahead of the January 2027 removal. Buttons render from
MessagePresentation instead of the InteractiveReply bridge, including
presentation-only host replies. Zod 4 deprecations cleaned up.
Tools, outbound sends, commands and pairing notices reused nothing and
opened a connection per call. They now borrow the running monitor's
client for the same account, token and server, and fall back to a
short-lived client otherwise. The registry lives on a process-wide key
because each plugin entry is bundled separately.
Presence, reasoning, addressing, model menus, reply actions, history and
inbound media now live in their own files. Code moved verbatim; the
monitorInlineProvider closure is untouched and phase 2 rewrites it.
morajabi added a commit that referenced this pull request Nov 8, 2026
…itor sends

From the 1.0 review (draft #158): typed command actions keep their kind
and run as system commands instead of agent turns, disabled buttons stay
inert, presentation fallback text survives authored text, cancelled
callers can't borrow the shared client, and the monitor's 15 direct
sends share one sender that waits an explicit server flood hint (up to
60s, twice) with a stable randomId and never retries uncertain sends.
morajabi added a commit that referenced this pull request Nov 8, 2026
…itor sends

From the 1.0 review (draft #158): typed command actions keep their kind
and run as system commands instead of agent turns, disabled buttons stay
inert, presentation fallback text survives authored text, cancelled
callers can't borrow the shared client, and the monitor's 15 direct
sends share one sender that waits an explicit server flood hint (up to
60s, twice) with a stable randomId and never retries uncertain sends.
@morajabi
morajabi force-pushed the claude/openclaw-1.0 branch from 620ca31 to 9cde5a6 Compare November 8, 2026 12:46

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant