docs: add Hermes to ECC migration guide

2026-04-06 17:23:28 +08:00 · 2026-04-05 17:18:54 -07:00
parent 57e2435b4f
commit 4d759f91da
2 changed files with 225 additions and 0 deletions
--- a/WORKING-CONTEXT.md
+++ b/WORKING-CONTEXT.md
@@ -157,3 +157,4 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
 - 2026-04-05: Tightened `product-lens` so it no longer overlaps the new capability-contract lane. `product-lens` now explicitly owns product diagnosis / brief validation, while `product-capability` owns implementation-ready capability plans and SRS-style constraints.
 - 2026-04-05: Continued `#1213` cleanup by removing stale references to the deleted `project-guidelines-example` skill from exported inventory/docs and marking `continuous-learning` v1 as a supported legacy path with an explicit handoff to `continuous-learning-v2`.
 - 2026-04-05: Removed the last orphaned localized `project-guidelines-example` docs from `docs/ko-KR` and `docs/zh-CN`. The template now lives only in `docs/examples/project-guidelines-template.md`, which matches the current repo surface and avoids shipping translated docs for a deleted skill.
+- 2026-04-05: Added `docs/HERMES-OPENCLAW-MIGRATION.md` as the current public migration guide for issue `#1051`. It reframes Hermes/OpenClaw as source systems to distill from, not the final runtime, and maps scheduler, dispatch, memory, skill, and service layers onto the ECC-native surfaces and ECC 2.0 backlog that already exist.
--- a/docs/HERMES-OPENCLAW-MIGRATION.md
+++ b/docs/HERMES-OPENCLAW-MIGRATION.md
@@ -0,0 +1,224 @@
+# Hermes / OpenClaw -> ECC Migration
+
+This document is the public migration guide for moving a Hermes or OpenClaw-style operator setup into the current ECC model.
+
+The goal is not to reproduce a private operator workspace byte-for-byte.
+
+The goal is to preserve the useful workflow surface:
+
+- reusable skills
+- stable automation entrypoints
+- cross-harness portability
+- schedulers / reminders / dispatch
+- durable context and operator memory
+
+while removing the parts that should stay private:
+
+- secrets
+- personal datasets
+- account tokens
+- local-only business artifacts
+
+## Migration Thesis
+
+Treat Hermes and OpenClaw as source systems, not as the final runtime.
+
+ECC is the durable public system:
+
+- skills
+- agents
+- commands
+- hooks
+- install surfaces
+- session adapters
+- ECC 2.0 control-plane work
+
+Hermes and OpenClaw are useful inputs because they contain repeated operator workflows that can be distilled into ECC-native surfaces.
+
+That means the shortest safe path is:
+
+1. extract the reusable behavior
+2. translate it into ECC-native skills, hooks, docs, or adapter work
+3. keep secrets and personal data outside the repo
+
+## Current Workspace Model
+
+Use the current workspace split consistently:
+
+- live code work happens in cloned repos under `~/GitHub`
+- repo-specific active execution context lives in repo-level `WORKING-CONTEXT.md`
+- broader non-code context can live in KB/archive layers
+- durable cross-machine truth should prefer GitHub, Linear, and the knowledge base
+
+Do not rebuild a shadow private workspace inside the public repo.
+
+## Translation Map
+
+### 1. Scheduler / cron layer
+
+Source examples:
+
+- `cron/scheduler.py`
+- `jobs.py`
+- recurring readiness or accountability loops
+
+Translate into:
+
+- Claude-native scheduling where available
+- ECC hook / command automation for local repeatability
+- ECC 2.0 scheduler work under issue `#1050`
+
+Today, the repo already has the right public framing:
+
+- hooks for low-latency repo-local automation
+- commands for explicit operator actions
+- ECC 2.0 as the future long-lived scheduling/control plane
+
+### 2. Gateway / dispatch layer
+
+Source examples:
+
+- Hermes gateway
+- mobile dispatch / remote nudges
+- operator routing between active sessions
+
+Translate into:
+
+- ECC session adapter and control-plane work
+- orchestration/session inspection commands
+- ECC 2.0 control-plane backlog under:
+  - `#1045`
+  - `#1046`
+  - `#1047`
+  - `#1048`
+
+The public repo should describe the adapter boundary and control-plane model, not pretend the remote operator shell is already fully GA.
+
+### 3. Memory layer
+
+Source examples:
+
+- `memory_tool.py`
+- local operator memory
+- business / ops context stores
+
+Translate into:
+
+- `knowledge-ops`
+- repo `WORKING-CONTEXT.md`
+- GitHub / Linear / KB-backed durable context
+- future deep memory work under `#1049`
+
+The important distinction is:
+
+- repo execution context belongs near the repo
+- broader non-code memory belongs in KB/archive systems
+- the public repo should document the boundary, not store private memory dumps
+
+### 4. Skill layer
+
+Source examples:
+
+- Hermes skills
+- OpenClaw skills
+- generated operator playbooks
+
+Translate into:
+
+- ECC-native top-level skills when the workflow is reusable
+- docs/examples when the content is only a template
+- hooks or commands when the behavior is procedural rather than knowledge-shaped
+
+Recent examples already salvaged this way:
+
+- `knowledge-ops`
+- `github-ops`
+- `hookify-rules`
+- `automation-audit-ops`
+- `email-ops`
+- `finance-billing-ops`
+- `messages-ops`
+- `research-ops`
+- `terminal-ops`
+- `ecc-tools-cost-audit`
+
+### 5. Tool / service layer
+
+Source examples:
+
+- custom service wrappers
+- API-key-backed local tools
+- browser automation glue
+
+Translate into:
+
+- MCP-backed surfaces when a connector exists
+- ECC-native operator skills when the workflow logic is the real asset
+- adapter/control-plane work when the missing piece is session/runtime coordination
+
+Do not import opaque third-party runtimes into ECC just because a private workflow depended on them.
+
+If a workflow is valuable:
+
+1. understand the behavior
+2. rebuild the minimum ECC-native version
+3. document the auth/connectors required locally
+
+## What Already Exists Publicly
+
+The current repo already covers meaningful parts of the migration:
+
+- ECC 2.0 adapter/control-plane discovery docs
+- orchestration/session inspection substrate
+- operator workflow skills
+- cost / billing / workflow audit skills
+- cross-harness install surfaces
+- AgentShield for config and agent-surface scanning
+
+This means the migration problem is no longer "start from zero."
+
+It is mostly:
+
+- distilling missing private workflows
+- clarifying public docs
+- continuing the ECC 2.0 operator/control-plane buildout
+
+## What Still Belongs In Backlog
+
+The remaining large migration themes are already tracked:
+
+- `#1051` Hermes/OpenClaw migration
+- `#1049` deep memory layer
+- `#1050` autonomous scheduling
+- `#1048` universal harness compatibility layer
+- `#1046` agent orchestrator
+- `#1045` multi-session TUI manager
+- `#1047` visual worktree manager
+
+That is the right place for the unresolved control-plane work.
+
+Do not pretend the migration is "done" just because the public docs exist.
+
+## Recommended Bring-Up Order
+
+1. Keep the public ECC repo as the canonical reusable layer.
+2. Port reusable Hermes/OpenClaw workflows into ECC-native skills one lane at a time.
+3. Keep private auth and personal context outside the repo.
+4. Use GitHub / Linear / KB systems as durable truth.
+5. Treat ECC 2.0 as the path to a native operator shell, not as a finished product.
+
+## Decision Rule
+
+When reviewing a Hermes or OpenClaw artifact, ask:
+
+1. Is this reusable across operators or only personal?
+2. Is the asset mainly knowledge, procedure, or runtime behavior?
+3. Should it become:
+   - a skill
+   - a command
+   - a hook
+   - a doc/example
+   - a control-plane issue
+4. Does shipping it publicly leak secrets, private datasets, or personal operating state?
+
+Only ship the reusable surface.