mirror of
https://github.com/affaan-m/ECC.git
synced 2026-09-18 15:50:25 +02:00
* feat: consolidate offline eval and operator workflows
Compose the retained framework, operator skill, roadmap and cleanup ranges on current main. Preserve current release dependencies and keep candidate execution disabled pending OS containment. Repair draft/DOCX behavior, obligation uniqueness, trusted send and audience guidance, runner provenance and eval diagnostics.
Source-PR: 2930 0abe3727d2b500c6e4830bdeb47ed67cae3f4785
Source-PR: 2931 992b49c44ed872def49675b791168b8fcd091df6
Source-PR: 2932 4a193dd13041cb7a6bebf4d2e910a0cd32bcc797
Source-PR: 2933 59cdfe500a91949ba1415f1edd7279620f21e804
Source-Base: ca185ef5f7
* fix: repair foundation CI and update js-yaml
* fix: reconcile pending-delete capsule locks after close
---------
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
240 lines
6.8 KiB
Markdown
240 lines
6.8 KiB
Markdown
# 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 direction lives in the repo's planning docs under `docs/`, shipped change history in `CHANGELOG.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 planning docs under `docs/` and `CHANGELOG.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
|
|
|
|
ECC 2.0 now ships a bounded migration audit entrypoint:
|
|
|
|
- `ecc migrate audit --source ~/.hermes`
|
|
- `ecc migrate plan --source ~/.hermes --output migration-plan.md`
|
|
- `ecc migrate scaffold --source ~/.hermes --output-dir migration-artifacts`
|
|
- `ecc migrate import-skills --source ~/.hermes --output-dir migration-artifacts/skills`
|
|
- `ecc migrate import-tools --source ~/.hermes --output-dir migration-artifacts/tools`
|
|
- `ecc migrate import-plugins --source ~/.hermes --output-dir migration-artifacts/plugins`
|
|
- `ecc migrate import-schedules --source ~/.hermes --dry-run`
|
|
- `ecc migrate import-remote --source ~/.hermes --dry-run`
|
|
- `ecc migrate import-env --source ~/.hermes --dry-run`
|
|
- `ecc migrate import-memory --source ~/.hermes`
|
|
|
|
Use that first to inventory the legacy workspace and map detected surfaces onto the current ECC2 scheduler, remote dispatch, memory graph, templates, and manual-translation lanes.
|
|
|
|
## 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.
|