claw init --from should support same-runtime and cross-runtime imports

[mostlydev]

Summary

claw init --from currently reads an existing OpenClaw config, then emits a legacy flat OpenClaw scaffold. That is too narrow and non-intuitive: operators should be able to import an existing OpenClaw or Hermes instance into a claw-managed project, either preserving the same runtime or selecting another supported runtime.

This issue tracks the generic migration/import UX. It is not tied to any one deployment.

Current behavior

• --from only looks for openclaw.json.
• The import path hardcodes FROM openclaw:latest and CLAW_TYPE openclaw.
• --type hermes is ignored when --from is present.
• The generated scaffold is legacy flat layout, not the canonical agents/<name>/ layout used by normal claw init.
• The importer detects enabled channels and primary model, but drops platform-specific routing such as Slack allowed channels.
• Slack import emits only SLACK_BOT_TOKEN / SLACK_BOT_ID style env placeholders, but Hermes socket mode requires SLACK_APP_TOKEN too.
• Provider refs from the source config are copied as-is, even when the selected target runtime cannot use that provider route.

Goal

Make runner migration a first-class claw workflow:

• OpenClaw config -> claw-managed OpenClaw
• OpenClaw config -> claw-managed Hermes
• Hermes config -> claw-managed Hermes
• Hermes config -> claw-managed OpenClaw, where mappings are supportable

Proposed direction

• Treat --type as the target runtime even when --from is present, or introduce an explicit --target if that is clearer.
• Detect or declare source runtime (openclaw, hermes) instead of assuming OpenClaw forever.
• Emit canonical project layout by default, preserving legacy flat import only behind an explicit compatibility flag if needed.
• Import identities, model slots, handles, platform env requirements, skills/contracts, and portable workspace/persona references where possible.
• Extract secrets into .env.example placeholders rather than writing raw tokens into generated pod YAML.
• Preserve platform routing intent in portable x-claw terms where the data model supports it; where it does not, emit explicit migration notes instead of silently dropping behavior.
• For model providers that the target runtime cannot use directly, fail with a clear migration note or require an explicit replacement model/provider choice such as OpenRouter or Vercel via cllama.

Dependencies / related work

• Hermes Slack parity should land first or alongside this work so Slack imports have a valid target surface.
• Existing Rails-style DX issue feat: Rails-style DX — claw new, claw g, claw model #90 is related but not sufficient; this issue is about importing native runner state into claw-managed projects, not just new-project generators.

Non-goals

• Do not implement channel://slack policy mapping unless the migration data model requires it and the scope is explicitly expanded.
• Do not preserve secrets inline in generated tracked files.
• Do not add deployment-specific references to docs, tests, or issue titles.

Acceptance criteria

• claw init <dir> --from <openclaw-config> --type openclaw produces a valid claw-managed OpenClaw project.
• claw init <dir> --from <openclaw-config> --type hermes produces a valid claw-managed Hermes project when the source features are supported.
• Unsupported source features are reported as actionable migration notes.
• Slack socket-mode imports include both bot and app token placeholders.
• Provider/model mismatches are handled explicitly rather than copied into a broken scaffold.
• Documentation explains same-runtime and cross-runtime import paths.

[mostlydev]

Codex adversarial review of Claude's draft docs/plans/2026-05-11-issue-230-init-from-cross-runtime.md:

Overall direction is sound: new importer package, canonical layout, source detection, target selected by --type, explicit migration notes, and no secret copying. I would tighten the plan before implementation in these ways:

1. Drop --legacy-flat for claw init --from v1. ADR-011 keeps claw agent add layout-preserving for existing projects, but a new import scaffold should have one canonical shape. The flat path is just extra matrix.

2. Do not stub channel://slack. OpenClaw supports HANDLE slack, but the current channel-policy surface is Discord-only. If Slack routing policy is present (SLACK_ALLOWED_USERS, allowed channels, etc.), preserve credentials/handle where possible and emit a fatal migration note unless --accept-loss=slack-routing is passed.

3. Prefer granular --accept-loss=<feature,...> plus --accept-loss=all over a generic --force. Suggested feature names: slack-routing, discord-routing, cron, identity-env, custom-provider. Fatal notes should name the exact token needed.

4. Make the IR typed, not a loose map[string]ChannelInfo. A map for lookup is fine, but ChannelInfo should carry platform-specific typed fields (Discord, Slack, Telegram) so the translator cannot accidentally map Slack policy into Discord policy. The draft's MIGRATION.md example currently says SLACK_ALLOWED_USERS -> channel://discord allowFrom; that must not survive.

5. For Hermes schema fidelity, import only the Clawdapus/Hermes fields we actually understand: model.default, model.provider, model.base_url, model.api_key, sibling .env, SOUL.md, skills/. Unknown config keys should become RawNotes/migration notes. Do not pretend to support arbitrary upstream Hermes config migration in v1.

6. Do not preserve HERMES_DEFAULT_AGENT_IDENTITY as raw env. The Clawdapus Hermes driver sets managed identity itself and does not pass that env through as an operator override. Preserve identity through SOUL.md and/or generated AGENTS.md; if the only source identity is that env var, fold it into the contract/SOUL and note the translation.

7. Model translation needs to preserve native routes where target supports them. The draft says openrouter/... always works through cllama; that is too strong. Hermes has a native OpenRouter provider path, and OpenClaw can carry provider refs directly. Use cllama when the source already used proxy/base_url semantics, when the target cannot represent a custom base URL natively, or when the operator explicitly requests --cllama; otherwise keep the source route and add required provider env placeholders.

8. Keep v1 target scope to OpenClaw and Hermes for --from. If --type nanobot|microclaw|... is passed with --from, fail with a clear "import target not supported yet" error. Otherwise the translation matrix explodes beyond claw init --from should support same-runtime and cross-runtime imports #230.

9. Treat Hermes cron as migration evidence, not active import. Copying cron files under agents/<name>/cron could imply Clawdapus will run them, but Hermes driver materializes jobs from INVOKE. Put cron files under an imported/ reference dir or skip copying and emit notes telling the operator to translate them to INVOKE.

10. Add tests for the failure paths, not just happy scaffolds: ambiguous source detection, unsupported target runtime, unmapped Slack routing without accept-loss, literal token redaction, and provider env placeholder generation.

With those changes, I think the plan is ready for implementation. The implementation should start by replacing the current runInitFrom legacy path with an internal/initimport package, but keep the first PR focused on OpenClaw/Hermes only and avoid release artifacts.