Skip to content

New-agent support roadmap: OpenClaw, Pi, goose, Crush, Cline, OpenHands, Hermes, Copilot, Gemini, Kilo, and qualification backlog #48

Description

@ImL1s

Summary

This is the execution umbrella for expanding Portable Resume beyond the original eight sources/destinations.

It links the scalable capability architecture, first-wave implementation issues, phased destination-first profiles, compatibility/migration support, and the second-wave research backlog. It does not replace the source-correctness umbrella #18 or destination/installer-hardening umbrella #30; implementation PRs must satisfy those existing safety and transaction contracts.

Research baseline: current upstream projects/docs reviewed on 2026-07-26.

Product boundary

Every new integration remains:

  • local/offline for source reads
  • immutable toward source stores
  • inert/untrusted at handoff
  • stdlib-only in the bundled Portable Resume runtime
  • no source CLI/server/gateway/cloud attachment
  • no execution of recovered commands/tool calls
  • no auth/settings/credential migration
  • no native live-process continuation claim

Source adapter, destination Skill, native package, activation and marketplace support are independent axes.

Foundation

No new profile should increase the blast radius of known installer P0s. Source-only fixtures/adapters can proceed independently when they do not use the mutating installer.

Tier 1 — full source + destination candidates

[ ] #37 OpenClaw

Scope:

  • current per-agent SQLite sessions/transcript events
  • multi-agent composite identity
  • branch/compaction/reset/internal-session rules
  • OpenClaw workspace/global Agent Skills and local-directory install evidence

Priority: P1, high user value and strong current storage/Skill contracts.

[ ] #38 Pi

Scope:

  • documented v1/v2/v3 tree JSONL
  • active leaf, branch and compaction summaries
  • native .pi/skills/~/.pi/agent/skills destination

Priority: P1, likely the cleanest first new source adapter after #36/#10.

[ ] #39 goose

Scope:

  • current SQLite schema 15 session/message store
  • user versus scheduled/subagent/hidden/gateway/ACP filtering
  • legacy JSONL later
  • direct Agent Skills destination

Priority: P1, implement current SQLite first.

[ ] #40 Crush

Scope:

  • current project/data-root SQLite and migrations
  • message parts JSON, parent/summary semantics
  • CRUSH_GLOBAL_DATA and Skill roots

Priority: P1, schema qualification PR before adapter.

[ ] #41 Cline

Scope:

  • authoritative per-session JSON plus SQLite index/fallback
  • root versus child/team/observer privacy
  • direct .cline/skills destination

Priority: P1, active product but schema/privacy qualification is substantial.

[ ] #42 OpenHands CLI

Scope:

  • current per-event JSON conversation directories
  • stable multi-file snapshot
  • action/observation and condensation semantics
  • local direct Agent Skills only; Cloud/SDK/plugins excluded

Priority: P1, exact current CLI product/version required.

[ ] #43 Hermes Agent

Scope:

  • WAL SQLite state/messages
  • profile/native ID, child/compaction lineage and messaging privacy
  • global $HERMES_HOME/skills destination

Priority: P1, direct global Skills first; no hub/gateway/skill_manage.

Tier 1 phased — destination first, source gated

[ ] #44 GitHub Copilot CLI

Phase A:

  • official project/personal Agent Skills roots
  • direct and local CLI-managed Skill install/activation evidence

Phase B:

  • authoritative qualification of session-state/<id>/events.jsonl and session-store.db
  • source profile remains planned until rewind/compaction/subagent/fleet/cloud-sync semantics are fixture-backed

Priority: Destination P1, source qualification P1 research.

Tier 2 compatibility / fork qualification

[ ] #45 Gemini CLI

  • preserve local/enterprise/API-backed histories and Gemini-specific Skill roots
  • consumer Login-with-Google access ended June 18, 2026; Antigravity remains separate
  • destination may land before current JSON source schema qualification
  • no auth/quota/settings migration

Priority: P2 compatibility/migration.

[ ] #46 Kilo Code CLI

  • destination and source profiles independent of OpenCode
  • active Kilo database/storage refactor must be pinned
  • reuse only generic helpers proven through Kilo/OpenCode divergence tests
  • CLI direct Skills first; IDE/Cloud/Marketplace later

Priority: P1/P2 staged, source remains research until current schema fixtures exist.

Tier 3 research backlog

[ ] #47 Qualification registry

Priority candidates:

  • Aider
  • Amp
  • Factory Droid
  • Codebuff
  • Kiro CLI
  • Zed Agent
  • Roo Code

Additional destination/source qualification:

  • Warp
  • Windsurf
  • Junie
  • Replit/Universal
  • Qoder
  • Trae
  • CodeBuddy
  • Command Code
  • Bob
  • Augment
  • Firebender
  • Cortex
  • Mistral Vibe
  • other current gh skill hosts

Archival/deferred review:

  • Continue
  • pre-SQLite Goose
  • old Hermes JSONL
  • old OpenHands single-file formats
  • archived/renamed Kilo repositories

Research entries never enter runtime/release matrices until promoted by a dedicated implementation issue.

Recommended execution order

Phase 0 — unblock architecture and safety

  1. Next-wave support architecture: decouple source adapters, destination hosts, and native package surfaces #36 registry/matrix PR 1
  2. ReadBudget invariants: reject all caller-raised global ceilings #17 bounds invariant
  3. Shared JSONL infrastructure: stable streaming scanner and metadata reducers #10 scanner API/tests
  4. installer P0 patch release work [P0 security] recover must not delete paths supplied by an untrusted complete journal #20/[P0 security] installer payload commits must be descriptor-relative and resist parent-directory swap escapes #31 and locked-plan/control-store prerequisites as required for destination installs

Phase 1 — simplest high-confidence sources

  1. Pi PR 1 fixtures/decision record
  2. Pi source adapter
  3. OpenClaw PR 1 fixtures/schema
  4. goose PR 1 schema/fixtures

Pi is recommended first because the versioned file format and Skill roots are publicly documented. OpenClaw/goose follow through the shared SQLite safety path.

Phase 2 — first destinations

  1. Next-wave support architecture: decouple source adapters, destination hosts, and native package surfaces #36 dynamic destination/source registry and matrix PRs complete
  2. Pi/OpenClaw/goose direct destination profiles after the installer security release gate
  3. Copilot destination profile
  4. exact-version isolated activation evidence per host, never inferred from the Python runner matrix

Phase 3 — remaining first wave

  1. Crush
  2. Cline
  3. OpenHands
  4. Hermes

Each starts with a decision-record/fixture PR; no large adapter/host monolith.

Phase 4 — compatibility/forks

  1. Gemini destination/lifecycle decision, then source only if qualified
  2. Kilo destination/storage decision, then source only if qualified

Phase 5 — qualification backlog

  1. Qualify second-wave agents: Aider, Amp, Droid, Codebuff, Kiro, Zed, Roo, Warp, Windsurf, Junie, and others #47 research registry
  2. open dedicated implementation issues only for qualified source/destination axes

Standard PR sequence per new tool

PR A — upstream contract and synthetic fixtures

Required:

  • exact upstream repository/product/version/commit/date
  • source root and override policy
  • schema/version/authority ordering
  • cwd/project identity
  • branch/rewind/compaction/child rules
  • privacy and cloud/local boundary
  • destination roots/precedence/activation
  • generated synthetic fixture family and manifest
  • explicit blockers and go/no-go

This PR may contain no runtime support key yet.

PR B — source adapter

  • profile registration
  • safe probe
  • metadata-only list
  • exact ID/path
  • selected public show/reducer
  • large-resource, corruption, race, path and privacy tests
  • immutable source proof

PR C — destination direct Skill

  • destination registration/root provenance
  • host-neutral payload profile
  • direct install/verify/uninstall lifecycle
  • dynamic installed-runner cells
  • shadow detection/docs/localizations

Requires destination installer security gates applicable to the selected roots.

PR D — exact-version host evidence

  • isolated host home/config/data
  • exact package/payload digest
  • native/local install or direct discovery
  • explicit activation
  • loaded owned-runner provenance
  • sanitized evidence tied to host version and date

PR E — optional compatibility/native marketplace

Legacy providers, IDE products, cloud/team/gateway surfaces or native marketplaces each require their own contract/evidence and are not bundled into basic CLI support.

Source acceptance contract

A new source cannot be marked supported until:

  • authoritative local source exists
  • closed format/schema profile and synthetic fixture exist
  • exact ID/path and cwd/project isolation work
  • probe/list do not parse full transcripts unnecessarily
  • show uses the correct source/record/transcript/output budgets
  • active branch/compaction/rewind semantics are proven
  • child/internal sessions cannot crowd root sessions before LIMIT
  • system/reasoning/credentials/private routing/binary data is filtered
  • source mutation produces retry/busy rather than mixed output
  • no source process/network/API is invoked
  • source tree/DB remains unchanged

Destination acceptance contract

A new destination cannot be marked supported until:

  • native/default project/global root and overrides are authoritative
  • precedence/alternate roots are machine-readable
  • direct payload parser/frontmatter/resource constraints pass
  • selected root provenance is reported
  • owned runner and typed request path are deterministic
  • direct install/verify/uninstall is transactional and safe
  • duplicate/shadow copies are handled under Detect duplicate and shadowed Portable Resume Skills across each host's discovery roots #34
  • installed-runner matrix cells pass for every enabled source
  • native activation is recorded separately on an exact host version

A destination-only profile is valid and does not require a source adapter.

Matrix and release-size expectations

Counts are always derived from enabled registries.

For example, after the original eight plus seven full first-wave tools:

15 supported sources × 15 supported direct destinations = 225 direct runner cells

If Copilot/Gemini/Kilo destinations land before their sources, the matrix becomes rectangular rather than symmetric. Reports must show dimensions and enabled key sets, not merely a single number.

To keep CI practical:

  • shard by source/destination
  • reuse one deterministic payload build per destination/profile
  • generate large fixtures at runtime
  • keep native proprietary host validation scheduled/manual
  • do not run network/account activation in normal CI

Release milestones

Milestone N1 — architecture ready

Milestone N2 — first new source

  • Pi source probe/list/show
  • no destination release claim required
  • current adapters still pass their backlogs

Milestone N3 — first new source+destination pair

  • Pi direct destination and exact-version activation evidence
  • dynamically expanded installed-runner matrix

Milestone N4 — SQLite wave

  • OpenClaw + goose current SQLite source/destination
  • shared SQLite/WAL security evidence

Milestone N5 — complete first wave

  • Crush, Cline, OpenHands, Hermes supported at approved axes
  • Copilot destination supported/source status explicit

Milestone N6 — compatibility and second wave

Partial releases are acceptable only when STATUS/CHANGELOG name exact completed axes and keep the remaining issues open.

Verification gates

Every implementation PR reports relevant focused tests and the canonical suite:

python3 scripts/self_verify.py
python3 scripts/check_docs.py
python3 scripts/check_secrets.py
PYTHONPATH=src python3 -m unittest discover -s tests -q
PYTHONPATH=src python3 scripts/smoke_installed_matrix.py

Additional per-tool gates:

  • fixture generation/manifest validation
  • source-tree immutability
  • no source-process static/runtime invocation
  • large history boundary
  • exact path/ID and cwd collision
  • privacy/redaction
  • destination root/shadow/runner provenance
  • exact native host evidence when claimed

Completion criteria

This roadmap closes only when:

Out of scope

  • supporting every name in a generic Skill installer catalog
  • popularity-only profile promotion
  • cloud/team/remote session retrieval
  • automatically invoking candidate CLIs to inspect user stores
  • combining all first-wave support in one PR
  • executing recovered commands or restoring workspaces
  • native live-process continuation

Security / privacy

All source fixtures, host homes and activation evidence must be generated/synthetic and isolated. Never attach real sessions, databases, WALs, event files, account/team/channel metadata, credentials, private source, tool arguments/results, worktrees, checkpoints or home paths.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions