# QNE OpenClaw Capability Replacement Investigation V1

Date: 2026-06-14

## Status

Current planning doctrine and TODO marker.

## Purpose

QNE is expected to become capable of most or all useful OpenClaw-style personal
agent functions, but with stronger control, clearer ownership, lower cognitive
load, and a QNE-native user experience.

This doctrine records the future investigation task: study OpenClaw methods,
capabilities, and workflows, then decide which should be replaced by QNE-native
code, which should be ignored, and which may inform optional compatibility or
import paths.

## QNE Position

QNE should not copy OpenClaw as an architecture. QNE already has or is designing
its own corresponding system parts:

- Home Node as the user's private runtime.
- `QNENodeSkill` as the skill/capability boundary.
- PA scenes as the low-cognitive-load user interface.
- Persist as user-owned memory and evidence storage.
- qne-p2p as authenticated peer transport.
- Mobile/native view sessions as controlled access surfaces.
- AI provider relay skills for LLM access without every user needing their own
  provider account.

OpenClaw-style capabilities should be implemented only when they fit QNE
doctrine: user ownership, explicit approval, least authority, auditable actions,
recoverable state, and low cognitive load.

## Investigation Scope

The investigation should cover:

1. OpenClaw skill model and how it compares with `QNENodeSkill`.
2. Messaging interface patterns and whether any should influence QNE PA scenes.
3. Browser automation patterns and whether Obscura or another engine is useful.
4. File and local command authority boundaries.
5. Persistent memory structures and how QNE persist should differ.
6. Third-party skill risks and QNE skill signing/approval requirements.
7. Security incidents and failure modes reported around OpenClaw-like agents.
8. Which OpenClaw capabilities are worth replacing with QNE-native equivalents.

## Replacement Principle

Where OpenClaw uses broad autonomous authority, QNE should prefer narrow,
typed, user-visible actions. A QNE PA may propose and sequence actions, but
sensitive actions should remain explicit and inspectable.

For example:

- Browser export/download tasks become QNE data import jobs with provenance.
- Messaging tasks become QNE communication skills with contact and consent
  rules.
- File tasks become persist-scoped file operations unless the user grants a
  wider device capability.
- Financial tasks are read-only unless a later doctrine explicitly permits a
  narrower action.

## Timing

This work is deferred until the mobile-first PA scene, native keyboard,
conversation flow, Home Node connection, and semantic action transport are
stable enough to support real guided tasks.

## TODO Marker

Future work item:

Investigate OpenClaw capabilities and methods, then create a QNE replacement
matrix showing:

- OpenClaw capability
- QNE-native equivalent
- required QNENodeSkill or crate
- required approval boundary
- implementation priority
- security notes

The output should become either a new doctrine version or a project planning
document for QNE agent capability expansion.
