# OpenClaw Gap Next Steps — 3-Phase Implementation Plan **Date:** 2026-02-16 **Parent analysis:** `docs/plans/2026-02-06-openclaw-feature-gap-analysis.md` **Related roadmap:** `docs/plans/2026-02-15-openclaw-gap-roadmap.md` ## Goal Close the highest-impact remaining OpenClaw parity gaps that still affect day-to-day Flynn operator value, while keeping scope incremental and testable. ## Prioritization Rationale 1. Queue behavior parity improves real-world reliability under bursty chats. 2. Channel reach adds immediate user-facing utility with bounded engineering cost. 3. Protocol/app foundation unlocks companion-node and canvas-class features without committing to full mobile/mac app scope yet. ## Phase 1 — Queue Policy Parity v2 (P1) ### Scope - Extend current lane queue controls to include: - `followup` mode semantics. - `steer_backlog` semantics. - lane debounce support. - overflow summarize behavior. - Add runtime control surface for queue policy per session. ### File-Level Tasks - `src/gateway/lane-queue.ts` - Add additional queue modes (`followup`, `steer_backlog`). - Add debounce handling and summarize-on-overflow strategy. - Add typed enqueue options for policy and enqueue metadata. - `src/gateway/handlers/agent.ts` - Resolve new queue mode values from config/session overrides. - Add response payloads for summarized drops/interruption notices. - `src/commands/builtin/index.ts` - Add `/queue` command group for inspect/set/reset queue behavior in current session. - `src/session/manager.ts` - Persist per-session queue overrides (`queue.mode`, `queue.debounce_ms`, etc.). - `src/config/schema.ts` - Add new queue keys and validation (`debounce_ms`, summarize settings). - `src/gateway/handlers/config.ts` - Expose queue config fields in runtime config patch API (if applicable). - `README.md` - Document queue modes and `/queue` command usage. - `docs/api/PROTOCOL.md` - Update queue and cancellation behavior sections. ### Test Checklist - `src/gateway/lane-queue.test.ts` - [x] `followup` behavior under active+pending workloads. - [x] `steer_backlog` replacement behavior across multiple pending entries. - [x] debounce behavior timing and ordering. - [x] summarize overflow behavior and payload integrity. - `src/gateway/handlers/agent.test.ts` - [x] queue policy resolution for new modes and debounce. - [x] session override precedence over channel/global config. - `src/commands/builtin/*.test.ts` - [x] `/queue` parse and execution behavior. - `src/config/schema.test.ts` - [x] new queue schema defaults and validation errors. ### Acceptance Criteria - Bursty same-session request streams behave deterministically with selected mode. - Operators can inspect/change queue behavior per session without restart. - Queue policy behavior is visible in docs and auditable. ## Phase 2 — Channel Reach Expansion (Mattermost First) (P2) ### Scope - Add first additional high-value missing channel using existing adapter architecture. - Mattermost is first due to enterprise overlap with existing Slack/Teams patterns. - Keep LINE/Feishu/Zalo as follow-on adapters after Mattermost stabilizes. ### File-Level Tasks - `src/channels/mattermost/adapter.ts` - Implement channel adapter with connect/disconnect/send/onMessage. - Support allowlists and mention gating consistent with other adapters. - `src/channels/mattermost/index.ts` - Export adapter + types. - `src/channels/index.ts` - Register adapter export. - `src/daemon/channels.ts` - Wire config -> adapter construction and registry registration. - `src/config/schema.ts` - Add `mattermost` config block (token/webhook/team/channel constraints). - `src/gateway/handlers/services.ts` - Add services reporting entry for Mattermost. - `README.md` - Add setup section and config example. - `docs/architecture/CONTRIBUTOR_MAP.md` - Update channel map and ownership notes. ### Test Checklist - `src/channels/mattermost/adapter.test.ts` - [x] inbound normalization and sender/session IDs. - [x] outbound send path. - [x] allowlist and mention gating. - [x] reconnect behavior and error handling. - `src/config/schema.test.ts` - [x] mattermost schema defaults/validation. - `src/daemon/channels.test.ts` - [x] adapter wiring and enable/disable lifecycle. - `src/gateway/handlers/services.test.ts` - [x] channel presence/status reporting. ### Acceptance Criteria - Mattermost operates end-to-end with same safety model as existing channels. - Docs and diagnostics are sufficient for first-time setup. - No regressions in existing channel startup/wiring tests. ## Phase 3 — Companion Node + Capability Negotiation Foundation (P3) ### Scope - Build protocol/runtime foundation for future companion apps and advanced surfaces. - Do not build full macOS/iOS/Android nodes in this phase. - Deliver capability discovery, version negotiation, and node role model. ### File-Level Tasks - `src/gateway/protocol.ts` - Add capability/version negotiation types (`protocol.version`, feature flags). - Add `node.register`, `node.capabilities.get` RPC schema. - `src/gateway/server.ts` - Track node-role connections and scoped auth constraints. - `src/gateway/router.ts` - Route and validate node-specific RPC calls. - `src/gateway/handlers/system.ts` - Add capability introspection endpoint(s). - `src/config/schema.ts` - Add optional node policy config (`gateway.nodes.allowed_roles`, feature gates). - `src/gateway/auth.ts` - Add scoped auth checks for node-role methods. - `docs/api/PROTOCOL.md` - Document negotiation handshake and node method contracts. - `README.md` - Add node foundation section and constraints. ### Test Checklist - `src/gateway/protocol.test.ts` - [x] validation for negotiation and node method payloads. - `src/gateway/server.test.ts` - [x] node registration lifecycle. - [x] role-based method allow/deny behavior. - `src/gateway/handlers/node.test.ts` - [x] capability introspection output correctness. - `src/gateway/auth.test.ts` - [x] node-role scope enforcement. - Integration tests: - [x] backward compatibility for non-node clients with old flow. ### Acceptance Criteria - Gateway supports explicit capability/version negotiation. - Node connections can be constrained by role and method scope. - Existing WebChat/TUI clients remain fully compatible. ## Cross-Phase Delivery Rules - Keep each phase behind config flags where behavior risk is non-trivial. - Land in small atomic commits with docs and tests in the same commit. - Update `docs/plans/state.json` after each phase completion. - Run at least: - `pnpm test:run` for touched suites. - `pnpm typecheck`. - `pnpm build` for protocol/runtime touching phases. ## Suggested Execution Order 1. Phase 1 (Queue parity v2). 2. Phase 2 (Mattermost adapter). 3. Phase 3 (Node/capability foundation).