|
| 1 | +# Plan: Roll Out OpenClaw as an OK Code Provider |
| 2 | + |
| 3 | +## Summary |
| 4 | + |
| 5 | +Add **OpenClaw** to OK Code as a third provider runtime alongside `codex` and `claudeAgent`. |
| 6 | + |
| 7 | +This should be implemented as a **provider integration**, not as a one-off model entry. OpenClaw would own model routing and execution, while OK Code continues to own thread UX, provider selection, health reporting, and session orchestration. |
| 8 | + |
| 9 | +## Goals |
| 10 | + |
| 11 | +- Let users select **OpenClaw** from the provider/model picker. |
| 12 | +- Support a practical MVP quickly without blocking on full provider parity. |
| 13 | +- Preserve OK Code's current provider architecture instead of adding ad-hoc special cases. |
| 14 | +- Keep the rollout safe by phasing higher-risk features after the basic session loop works. |
| 15 | + |
| 16 | +## Non-goals (initial rollout) |
| 17 | + |
| 18 | +- Full OpenClaw tool/event parity on day one. |
| 19 | +- Perfect rollback/history parity before an MVP exists. |
| 20 | +- Replacing existing Codex or Claude provider flows. |
| 21 | +- Supporting every OpenClaw capability in the first release. |
| 22 | + |
| 23 | +## Recommended rollout shape |
| 24 | + |
| 25 | +- **Phase 0:** architecture + contracts groundwork |
| 26 | +- **Phase 1:** UI + config plumbing |
| 27 | +- **Phase 2:** MVP OpenClaw adapter (usable provider) |
| 28 | +- **Phase 3:** richer session/history/approval parity |
| 29 | +- **Phase 4:** polish, observability, and hardening |
| 30 | + |
| 31 | +--- |
| 32 | + |
| 33 | +## Phase 0 — Architecture and contract groundwork |
| 34 | + |
| 35 | +### Objective |
| 36 | + |
| 37 | +Define OpenClaw as a first-class provider in contracts and app state without yet making it fully executable. |
| 38 | + |
| 39 | +### Checklist |
| 40 | + |
| 41 | +- [ ] Add `openclaw` to `ProviderKind`. |
| 42 | +- [ ] Decide whether OpenClaw-specific options live under `providerOptions.openclaw` or a new dedicated config object. |
| 43 | +- [ ] Define initial OpenClaw provider start options, likely including: |
| 44 | + - [ ] gateway/base URL |
| 45 | + - [ ] auth token or password reference |
| 46 | + - [ ] default agent/session mode |
| 47 | + - [ ] optional model override |
| 48 | +- [ ] Add OpenClaw model option strategy: |
| 49 | + - [ ] start with static built-ins **or** |
| 50 | + - [ ] start with manual custom model slugs only **or** |
| 51 | + - [ ] fetch dynamic models later as a follow-up |
| 52 | +- [ ] Set a clear default for session model switching support (`in-session`, `restart-session`, or `unsupported`). |
| 53 | +- [ ] Decide MVP behavior for unsupported provider features: |
| 54 | + - [ ] rollback |
| 55 | + - [ ] thread snapshot reads |
| 56 | + - [ ] approval routing |
| 57 | + - [ ] structured user input |
| 58 | + |
| 59 | +### Likely files |
| 60 | + |
| 61 | +- `packages/contracts/src/orchestration.ts` |
| 62 | +- `packages/contracts/src/model.ts` |
| 63 | +- `packages/contracts/src/provider.ts` |
| 64 | +- `packages/contracts/src/server.ts` |
| 65 | + |
| 66 | +### Exit criteria |
| 67 | + |
| 68 | +- `openclaw` exists in contracts/types without breaking existing providers. |
| 69 | +- MVP capability decisions are documented and not left implicit. |
| 70 | + |
| 71 | +--- |
| 72 | + |
| 73 | +## Phase 1 — UI and settings plumbing |
| 74 | + |
| 75 | +### Objective |
| 76 | + |
| 77 | +Make OpenClaw visible and selectable in the OK Code UI, even if execution is still stubbed or gated behind availability checks. |
| 78 | + |
| 79 | +### Checklist |
| 80 | + |
| 81 | +- [ ] Add OpenClaw to provider picker options. |
| 82 | +- [ ] Add an icon/label treatment for OpenClaw in the model picker. |
| 83 | +- [ ] Update provider-specific app settings and custom model handling. |
| 84 | +- [ ] Add settings UI for OpenClaw connection details. |
| 85 | +- [ ] Add provider install/configuration copy in settings. |
| 86 | +- [ ] Extend provider health banner/status display to recognize OpenClaw. |
| 87 | +- [ ] Ensure draft persistence/store logic can serialize OpenClaw provider selections. |
| 88 | +- [ ] Ensure thread/session display can show `providerName: "openclaw"` cleanly. |
| 89 | + |
| 90 | +### Likely files |
| 91 | + |
| 92 | +- `apps/web/src/session-logic.ts` |
| 93 | +- `apps/web/src/components/chat/ProviderModelPicker.tsx` |
| 94 | +- `apps/web/src/routes/_chat.settings.tsx` |
| 95 | +- `apps/web/src/appSettings.ts` |
| 96 | +- `apps/web/src/composerDraftStore.ts` |
| 97 | +- `apps/web/src/store.ts` |
| 98 | + |
| 99 | +### Notes |
| 100 | + |
| 101 | +For MVP, it is acceptable for the UI to show OpenClaw only when: |
| 102 | +- the provider is configured, or |
| 103 | +- a feature flag is enabled. |
| 104 | + |
| 105 | +### Exit criteria |
| 106 | + |
| 107 | +- Users can select OpenClaw in the UI. |
| 108 | +- App state and settings persist the choice correctly. |
| 109 | +- Existing Codex/Claude picker behavior remains unchanged. |
| 110 | + |
| 111 | +--- |
| 112 | + |
| 113 | +## Phase 2 — MVP OpenClaw adapter |
| 114 | + |
| 115 | +### Objective |
| 116 | + |
| 117 | +Ship a usable OpenClaw-backed provider that supports the core thread loop: |
| 118 | +**start session → send turn → stream output → stop session**. |
| 119 | + |
| 120 | +### Checklist |
| 121 | + |
| 122 | +- [ ] Implement `OpenClawAdapter` using the existing `ProviderAdapter` contract. |
| 123 | +- [ ] Register the adapter in the provider registry. |
| 124 | +- [ ] Wire the adapter into server layers. |
| 125 | +- [ ] Map OK Code thread lifecycle to OpenClaw session lifecycle. |
| 126 | +- [ ] Implement `startSession`. |
| 127 | +- [ ] Implement `sendTurn`. |
| 128 | +- [ ] Implement `interruptTurn` if OpenClaw supports it cleanly; otherwise define MVP fallback behavior. |
| 129 | +- [ ] Implement `stopSession`. |
| 130 | +- [ ] Implement `listSessions`. |
| 131 | +- [ ] Stream assistant output back into OK Code's canonical provider event stream. |
| 132 | +- [ ] Normalize OpenClaw errors into OK Code provider errors. |
| 133 | +- [ ] Add provider health probing for OpenClaw reachability/authentication. |
| 134 | +- [ ] Gate the provider as unavailable when config or auth is missing. |
| 135 | + |
| 136 | +### Likely files |
| 137 | + |
| 138 | +- `apps/server/src/provider/Layers/OpenClawAdapter.ts` |
| 139 | +- `apps/server/src/provider/Services/OpenClawAdapter.ts` |
| 140 | +- `apps/server/src/provider/Layers/ProviderAdapterRegistry.ts` |
| 141 | +- `apps/server/src/serverLayers.ts` |
| 142 | +- `apps/server/src/provider/Layers/ProviderHealth.ts` |
| 143 | + |
| 144 | +### MVP behavioral constraints |
| 145 | + |
| 146 | +- [ ] One OpenClaw session per OK Code thread. |
| 147 | +- [ ] Basic text streaming required. |
| 148 | +- [ ] Rich tool/request parity optional. |
| 149 | +- [ ] Rollback may be unsupported initially if surfaced honestly. |
| 150 | +- [ ] Thread readback may be shallow or best-effort in MVP. |
| 151 | + |
| 152 | +### Exit criteria |
| 153 | + |
| 154 | +- A user can select OpenClaw and successfully complete a normal prompt/response cycle. |
| 155 | +- Streaming feels native enough for regular use. |
| 156 | +- Health/auth failures are visible and understandable. |
| 157 | + |
| 158 | +--- |
| 159 | + |
| 160 | +## Phase 3 — Session, history, and approval parity |
| 161 | + |
| 162 | +### Objective |
| 163 | + |
| 164 | +Reduce the behavioral gap between OpenClaw and the native Codex/Claude integrations. |
| 165 | + |
| 166 | +### Checklist |
| 167 | + |
| 168 | +- [ ] Implement `readThread` with meaningful history reconstruction. |
| 169 | +- [ ] Implement `rollbackThread`, or explicitly model why rollback is unsupported. |
| 170 | +- [ ] Improve resume/reconnect behavior for long-lived OpenClaw sessions. |
| 171 | +- [ ] Decide how approval requests are surfaced: |
| 172 | + - [ ] OpenClaw-native approvals only |
| 173 | + - [ ] translated into OK Code approvals |
| 174 | + - [ ] hybrid with clear ownership |
| 175 | +- [ ] Support structured user-input prompts if OpenClaw exposes them. |
| 176 | +- [ ] Improve event translation for tools, progress states, and status updates. |
| 177 | +- [ ] Preserve provider refs/IDs where useful for resumability and debugging. |
| 178 | + |
| 179 | +### Design questions to resolve |
| 180 | + |
| 181 | +- [ ] Does OK Code own approvals, or does OpenClaw own approvals? |
| 182 | +- [ ] How should rollback behave if OpenClaw sessions are not trivially rewindable? |
| 183 | +- [ ] Should OpenClaw session state be persisted directly, indirectly, or only via transcript replay? |
| 184 | + |
| 185 | +### Exit criteria |
| 186 | + |
| 187 | +- OpenClaw threads behave predictably across refreshes, resumes, and longer conversations. |
| 188 | +- Missing parity is minimal and intentional rather than accidental. |
| 189 | + |
| 190 | +--- |
| 191 | + |
| 192 | +## Phase 4 — Polish, dynamic models, and hardening |
| 193 | + |
| 194 | +### Objective |
| 195 | + |
| 196 | +Make OpenClaw feel like a polished built-in provider rather than a basic bridge. |
| 197 | + |
| 198 | +### Checklist |
| 199 | + |
| 200 | +- [ ] Add dynamic model discovery from OpenClaw if available. |
| 201 | +- [ ] Support richer provider-specific model options where meaningful. |
| 202 | +- [ ] Improve install/setup guidance in settings. |
| 203 | +- [ ] Add better telemetry/logging around OpenClaw session failures. |
| 204 | +- [ ] Add browser/manual test coverage for picker/settings flows. |
| 205 | +- [ ] Add adapter-focused unit tests and integration tests. |
| 206 | +- [ ] Add resilience for network interruptions and transient gateway failures. |
| 207 | +- [ ] Add clearer recovery messaging for auth/config/session mismatch errors. |
| 208 | + |
| 209 | +### Exit criteria |
| 210 | + |
| 211 | +- Setup is understandable. |
| 212 | +- Errors are debuggable. |
| 213 | +- OpenClaw feels like a normal provider choice inside OK Code. |
| 214 | + |
| 215 | +--- |
| 216 | + |
| 217 | +## Cross-cutting risks |
| 218 | + |
| 219 | +- OpenClaw session semantics may not map perfectly onto OK Code's provider assumptions. |
| 220 | +- Approval handling may become confusing if both systems try to own the same UX. |
| 221 | +- Rollback/history parity may require deeper transcript/state mapping than the MVP needs. |
| 222 | +- Provider model discovery may be dynamic in OpenClaw while OK Code currently prefers static provider model catalogs. |
| 223 | + |
| 224 | +## Cross-cutting decisions to keep explicit |
| 225 | + |
| 226 | +- [ ] Is OpenClaw primarily a **remote runtime** or a **thin bridge** in MVP? |
| 227 | +- [ ] Are OpenClaw models static, custom-only, or dynamically discovered in the first release? |
| 228 | +- [ ] Is rollback required for launch, best-effort, or explicitly unsupported? |
| 229 | +- [ ] Who owns approval UX in the integrated flow? |
| 230 | + |
| 231 | +## Suggested order of implementation |
| 232 | + |
| 233 | +1. Phase 0 contracts |
| 234 | +2. Phase 1 picker/settings plumbing |
| 235 | +3. Phase 2 MVP adapter + health checks |
| 236 | +4. Manual smoke testing |
| 237 | +5. Phase 3 parity work |
| 238 | +6. Phase 4 polish/hardening |
| 239 | + |
| 240 | +## Validation checklist |
| 241 | + |
| 242 | +- [ ] Typecheck passes across contracts, web, and server. |
| 243 | +- [ ] Existing Codex and Claude flows still work. |
| 244 | +- [ ] OpenClaw shows correct provider health in settings/chat. |
| 245 | +- [ ] New OpenClaw thread can start, stream, and stop successfully. |
| 246 | +- [ ] Misconfigured OpenClaw setup fails with a useful message. |
| 247 | +- [ ] Re-opening the app preserves provider selection and model choice. |
| 248 | + |
| 249 | +## Done criteria |
| 250 | + |
| 251 | +- OpenClaw is selectable as a provider in OK Code. |
| 252 | +- A normal thread can run end-to-end through OpenClaw. |
| 253 | +- Provider health and configuration are understandable. |
| 254 | +- Advanced parity gaps are documented and tracked rather than hidden. |
0 commit comments