# QianjiangClaw Product Roadmap

Updated: 2026-03-23

## 1. Final Goal

The final product goal is locked as:

- Deliver a `Windows installer`
- The installer `bundles OpenClaw runtime`
- End users do `not` need to preinstall OpenClaw, Node, WSL2, or use the command line
- After install, users only need to:
  - open the desktop app
  - sign in with a company account
  - fetch profile, credit status, and skills through cloud APIs
  - start chatting and using skills directly

This means the final product is:

- not a Gateway connector only
- not a dev-only desktop shell
- not a "bring your own OpenClaw" tool
- not a desktop shell that expects users to configure provider/model/API keys by default

The final product is:

- a non-technical-user-friendly Windows desktop AI app
- with OpenClaw runtime bundled and managed by the installer
- with login, credits, and skills driven by cloud APIs

## 2. Fixed Product Decisions

These decisions are considered locked unless explicitly changed later:

- Use `Electron + React + TypeScript + pnpm workspace`
- Keep process boundaries:
  - `Renderer -> preload -> Electron Main -> GatewayClient / RuntimeManager / AuthClient / ProfileClient / CreditClient / SkillClient`
- Current external-Gateway mode is a transition phase, not the final form
- The final runtime delivery model is:
  - `installer bundles OpenClaw runtime`
- The target bundled runtime direction is:
  - `native Windows runtime`
- `runtime-manager` will return to the main path in the bundled-runtime phase
- The desktop app remains the single user-facing entry point
- The default product path does not require customer-provided API keys
- Profile, credit status, skill catalog, and skill availability are fetched from `cloud APIs`
- Platform credits are the default consumption model, and model usage is platform-managed

## 3. Current State

What is already true now:

- Desktop shell starts successfully
- Real preload/IPC path works
- The UI can connect to local OpenClaw Gateway
- Sessions/history work
- One real `chat.send` from the Electron UI path has already succeeded
- Smoke harness is now gated behind explicit smoke mode

Current reality:

- The desktop app is no longer just a skeleton
- The transition-phase desktop client is already functional on this machine
- The remaining work is about installer delivery, commercial API integration, and eventually bundled runtime

## 4. Delivery Stages

### Stage A: Transition MVP Cleanup

Goal:

- Turn the current desktop client into a stable, clean MVP baseline

Required outcomes:

- UI has:
  - loading state
  - error state
  - empty state
  - reconnect guidance
  - chat sending state
- Logs are readable enough for debugging
- Secret storage is upgraded from dev-file fallback to `keytar`
- Diagnostics export exists
- Smoke harness stays opt-in only and does not affect normal usage

Success criteria:

- On a machine with local OpenClaw already running, the app can:
  - launch
  - connect
  - show status
  - list sessions
  - show history
  - send chat
  - export diagnostics

### Stage B: Installer MVP

Goal:

- Prove the Windows installer delivery path before bundled runtime is introduced

Required outcomes:

- Build a working Windows installer
- Installer installs the desktop app correctly
- Installed app launches correctly
- Installed app still works against an already installed OpenClaw environment
- Installed app can also complete:
  - login
  - entitlement checks
  - profile fetch
  - credit fetch
  - skill catalog and availability fetch

Success criteria:

- On a test machine with existing OpenClaw:
  - install succeeds
  - app launches after install
  - preload and renderer assets load correctly
  - login and entitlement work
  - profile, credits, and skills load from APIs
  - connection and chat still work

### Stage C: Bundled Runtime PoC

Goal:

- Prove that bundled native Windows OpenClaw runtime can be shipped and started by the desktop app

Required outcomes:

- Define a fixed bundled runtime directory layout
- `runtime-manager` supports:
  - detect
  - resolve paths
  - start
  - stop
  - restart
  - health
  - tail logs
- Desktop app can run in bundled-runtime mode
- Desktop app no longer depends on user-installed OpenClaw in this mode
- Login, credits, and skills continue to work through APIs in bundled-runtime mode

Success criteria:

- On a clean Windows machine without OpenClaw preinstalled:
  - installer installs successfully
  - bundled runtime can be detected
  - bundled runtime can start
  - desktop app can connect to its bundled Gateway
  - login, profile, credits, and skills still work
  - chat works
  - failures are diagnosable

### Stage D: One-Click Product Version

Goal:

- Turn the bundled-runtime PoC into the real end-user product

Required outcomes:

- Installer includes runtime payload
- First launch handles initialization automatically
- Desktop app defaults to bundled-runtime mode
- Versioning and diagnostics are stable enough for user delivery
- Login, profile, credits, and skills are fully cloud-driven

Success criteria:

- A non-technical user can:
  - install the app
  - open it
  - sign in
  - see profile, credits, and available skills
  - use chat and skills
- without manually installing any OpenClaw dependency
- without configuring provider/model/API keys manually

## 5. Execution Order

Do the work in this order:

1. Finish Stage A cleanup
2. Build and verify Stage B installer MVP
3. Implement and validate Stage C bundled-runtime PoC
4. Turn the PoC into Stage D production-style bundled delivery

Do not skip ahead:

- Do not make bundled runtime the immediate next step before installer MVP is stable
- Do not promise one-click install until bundled-runtime PoC passes on a clean machine
- Do not move secret, entitlement, credits, or skill API logic into renderer

## 6. Stage A Implementation Checklist

This is the next practical work queue:

1. UI state completion
   - gateway loading state
   - gateway error state
   - no-session state
   - no-message state
   - chat sending state
   - reconnect hint text
2. Logs cleanup
   - strip ANSI escape codes
   - strip control characters
   - normalize noisy log text
   - prefer readable summary text over raw noisy payloads when possible
3. SecretManager upgrade
   - replace dev-file secret storage with `keytar`
   - keep a safe fallback strategy only when absolutely needed for development
4. Diagnostics export
   - export config summary
   - export gateway/runtime status
   - export recent logs
   - export version/path metadata
5. Keep smoke tooling opt-in only

## 7. Stage B Implementation Checklist

1. Finalize `electron-builder` config
2. Verify install paths and asset paths
3. Verify installed app launch behavior
4. Integrate and verify login / entitlement / profile / credits / skills APIs
5. Verify installed app can still connect to an existing OpenClaw environment
6. Record installer smoke-test checklist and failure cases

## 8. Stage C Implementation Checklist

1. Define bundled runtime layout
2. Restore `runtime-manager` as a primary runtime subsystem
3. Add bundled-runtime mode detection and boot flow in Electron Main
4. Add runtime health and lifecycle UI exposure
5. Keep login, credits, and skills APIs working in bundled-runtime mode
6. Validate bundled runtime on a clean Windows machine

## 9. Acceptance Criteria

### Transition MVP accepted when:

- Desktop UI is stable enough for repeated local use
- Errors and empty states are understandable
- Secrets are not stored in the current dev-file-only path
- Diagnostics export works

### Installer MVP accepted when:

- Installer installs cleanly
- Installed app launches
- Installed app works with an already-installed OpenClaw environment
- Installed app displays profile, credits, and skills from APIs correctly

### Bundled Runtime PoC accepted when:

- A clean machine without OpenClaw can use the app after install
- Runtime lifecycle is manageable from the app
- Runtime failures can be diagnosed
- Login, credits, and skills do not regress in bundled-runtime mode

### Final product accepted when:

- User installs once and can use the app directly
- User does not need to install OpenClaw separately
- User does not need to provide model/API keys
- Desktop app is the only visible entry point

## 10. Important Boundaries For Future AI Work

Any future AI agent continuing this project should assume:

- The current external-Gateway implementation is transitional
- The final business/product direction is bundled runtime inside the installer
- The desktop app is not meant to stay a connector-only tool
- `runtime-manager` must come back as a first-class subsystem later
- Electron Main remains responsible for:
  - runtime process management
  - config management
  - auth/session token management
  - diagnostics
  - API client orchestration
- Renderer should stay UI-only and not directly own secrets, runtime control, or cloud entitlement logic
- Skill catalog and availability should come from APIs, not be hardcoded into the installer

## 11. Recommended Next Task

The recommended next implementation task is:

- finish Stage A productization work, then move directly into installer smoke testing plus commercial API integration

Concrete next steps:

1. installer smoke test
2. login / entitlement API integration
3. profile / credits / skills API integration
4. then move to bundled-runtime work
