Elnor Repo Reader

ELNOR REPO READER TEXT MIRROR
Original path: OP-A and Operations and Trackers/OPENCLAW_PRESERVATION_AND_INTEGRATION_CHECKLIST_R1.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# OpenClaw Preservation and Integration Checklist (R1)

Purpose: a working checklist for future ELNOR/Q/EC spec revisions and implementation planning so OpenClaw remains the native runtime owner and ELNOR adds orchestration without duplication, stale context, or feature loss.

## A. Non-negotiable ownership rules
- [ ] Gateway remains canonical for session truth, runtime truth, and control truth.
- [ ] OpenClaw remains owner of native prompt assembly, session history, compaction/pruning, tool loop, skill loading, plugin loading, channel behavior, heartbeat, cron, and background process execution.
- [ ] Q/EC expose, correlate, constrain, and observe; they do not silently re-implement OpenClaw-native features.
- [ ] No second capability registry becomes more authoritative than OpenClaw’s live runtime/skill/plugin/catalog reality.
- [ ] No second scheduler is introduced without an explicit arbitration rule.

## B. Scheduler / automation arbitration (heartbeat vs cron vs Q/EC jobs)
### Core rule
- [ ] "Run this every night at midnight" should default to a native OpenClaw cron job unless there is a clear product reason it must be a Q/EC-owned workflow.
- [ ] Heartbeat is for periodic lightweight review/check-in in a session, not for explicit scheduled tasks. Cron is the built-in scheduler for "run this every morning" or "poke the agent in 20 minutes." 
- [ ] Q/EC must never silently create both a cron job and a parallel ELNOR/Q recurring job for the same user intent.

### Spec / product requirements
- [ ] Add an explicit automation ownership decision table in future docs:
  - native OpenClaw cron
  - native OpenClaw heartbeat
  - native OpenClaw background exec/process
  - Q/EC workflow job
  - mixed/linked mode (rare, explicit)
- [ ] Add a user-visible explanation when Elnor schedules something: "Created OpenClaw cron job" vs "Created ELNOR workflow schedule" vs "Configured heartbeat review".
- [ ] Add a scheduler provenance field on all automation artifacts.
- [ ] Add dedupe protection so repeating a scheduling request updates/links an existing automation instead of creating a second overlapping one.
- [ ] Add a read-model/UI panel showing all active automations regardless of owner.

### Programming / implementation tasks
- [ ] Implement scheduler arbitration logic before broad automation features ship.
- [ ] Implement a canonical automation artifact schema or bridge schema with owner fields.
- [ ] Add automation conflict detection: same target + same cadence + same intent hash -> warn/block/merge.
- [ ] Add import/mirror hooks for native cron/heartbeat visibility into Q.

## C. Context injection and duplication prevention
### Core rule
- [ ] ELNOR/Q/EC may contribute only bounded, relevant, deduped, inspectable context.
- [ ] OpenClaw already injects workspace/project context and owns the system prompt; ELNOR must not re-inject the same material through another path.

### OpenClaw-native sources to account for
- [ ] AGENTS.md
- [ ] SOUL.md
- [ ] TOOLS.md
- [ ] IDENTITY.md
- [ ] USER.md
- [ ] HEARTBEAT.md
- [ ] BOOTSTRAP.md
- [ ] MEMORY.md / memory.md
- [ ] memory/YYYY-MM-DD.md
- [ ] tool schemas / tool list
- [ ] skills list (metadata) and on-demand SKILL.md reads
- [ ] conversation history
- [ ] compaction/pruning artifacts

### Spec requirements
- [ ] Every future spec that injects context must state whether its data is:
  - OpenClaw-native
  - ELNOR-generated
  - owner-doc-native
  - derived summary
  - by-reference only
- [ ] Add a "no duplicate source class" rule: the same source class cannot be injected by two systems in the same turn unless explicitly justified.
- [ ] Add a "no stale carry-forward" rule: prior chat summaries/memory snippets must not persist indefinitely without freshness checks / relevance checks.
- [ ] Add a "main private session only" rule where applicable for MEMORY.md-style personal memory, since OpenClaw docs already distinguish main/private vs shared/group contexts.
- [ ] Keep room/panel/forum bootstrap separate from ordinary lean annotation injection.
- [ ] Use ref+summary first; never default to full file dumps.
- [ ] Define explicit context profiles later (for example full cloud, lean local, room bootstrap, repair/coding, minimal fast path).

### Programming / implementation tasks
- [ ] Build a context dedupe layer keyed by source type + source id + content hash + freshness window.
- [ ] Build a hard context budget gate before dispatch.
- [ ] Build a stale-context rejection/degrade path.
- [ ] Add source-aware suppression for OpenClaw-native workspace files so Q/EC do not re-send them redundantly.
- [ ] Add profile-aware context assembly so smaller/local models can use leaner injection.

## D. Context visibility / debugging (must-have)
- [ ] Provide a user-visible Context Inspector / Injection Manifest.
- [ ] For every dispatched turn, show:
  - source
  - owner
  - reason included
  - raw size / injected size / token estimate
  - freshness timestamp / freshness status
  - whether deduped, truncated, summarized, or dropped
  - whether dropped as stale / duplicate / over-budget / trust-blocked
- [ ] Make the failure mode visible: if context was degraded or rejected, Q must show that clearly.
- [ ] Keep a per-turn manifest so weird model behavior can be traced back to what was actually injected.

## E. Skills, plugins, and capability mirroring
- [ ] Treat OpenClaw’s live skill/plugin/tool catalogs as the runtime truth.
- [ ] ELNOR capability-awareness must mirror and organize that truth, not replace it.
- [ ] Third-party skills/plugins must remain installable later without requiring manual hardcoded ELNOR rewrites.
- [ ] Capability health and eligibility should be derived from runtime/bridge/catalog state, not assumed statically.
- [ ] Support session-snapshot reality: skills can be snapshotted per session and refreshed by watcher behavior; UI/specs must not assume instant universal propagation.

## F. Sub-agents, rooms, and native multi-agent behavior
- [ ] Visible ELNOR rooms must not replace native OpenClaw sub-agents.
- [ ] Visible participants can internally use native sub-agents if their runtime/tool policies allow it.
- [ ] Q/EC coordinate the visible transcript; OpenClaw retains runtime autonomy.
- [ ] No room participant may silently fall back to a default/main session when a participant binding is required.

## G. Channels, voice, remote, and external projection
- [ ] External channel behavior must stay capability-driven; Discord, WhatsApp, Telegram, iMessage, etc. are not equivalent.
- [ ] Do not assume thread binding or rich controls exist on every channel.
- [ ] Voice/talk mode, remote access, and node-host/Mac-specific behavior remain OpenClaw-owned capabilities.
- [ ] Q/EC should project and coordinate, not replace channel-native or talk-mode-native behavior.

## H. Cost / usage / local model readiness
- [ ] Keep provider/model/runtime controls provider-neutral.
- [ ] Do not assume cloud-only cost semantics.
- [ ] DOC13 should unify raw usage, cost, and budget logic later across cloud and local models.
- [ ] Preserve room/job/session usage producer seams now.
- [ ] Keep future room and ordinary chat dispatch compatible with lean local-model context profiles.

## I. Multiple gateways / advanced deployment
- [ ] Assume one Gateway by default.
- [ ] Treat multiple gateways as an advanced option for isolation, rescue mode, staging, or experimental local-model deployments.
- [ ] If multiple gateways are introduced later, require explicit ownership/routing rules so ELNOR does not create split-brain session truth.

## J. Specs to update or watch later
- [ ] DOC11: note provider-neutral / local-model / context-profile compatibility; keep Gateway canonical; keep context inspector/injection manifest.
- [ ] DOC10: preserve route/model separation; preserve context budget and dedupe requirements; expose failure/degrade telemetry.
- [ ] DOC12: preserve visible-room vs native-sub-agent split; add automation/channel projection cautions if needed.
- [ ] Running Brief: keep brief separate from room bootstrap; enforce stale/duplicate/over-budget protections.
- [ ] DOC13: define canonical usage/cost/budget schema that works for cloud and local.
- [ ] DOC3/DOC4: capability and visible-agent registries must mirror OpenClaw truth rather than replace it.
- [ ] DOC6/DOC7/DOC8/DOC9/DOC1/Freshness: verify they do not create hidden duplicate context or automation paths.

## K. Build / implementation checklist
- [ ] Before building any new feature, ask: "Does OpenClaw already own this?"
- [ ] Before adding any new context source, ask: "Is OpenClaw already injecting or making this available?"
- [ ] Before adding any recurring/scheduled behavior, ask: "Should this be cron, heartbeat, background process, or a Q/EC job?"
- [ ] Before adding any selector/control in Q, ask: "Is it bound to real OpenClaw runtime truth?"
- [ ] Before adding any capability UI, ask: "Is this coming from live runtime/bridge/catalog state?"
- [ ] Before adding any room/panel/forum feature, ask: "Does this collide with native sub-agent/channel/session behavior?"

## L. TODO / follow-up items
- [ ] Use this checklist during every remaining spec revision in the current wave.
- [ ] Fold the checklist into future integration/patch packs where relevant.
- [ ] Add scheduler arbitration requirements to the appropriate future spec pass.
- [ ] Add context dedupe / context inspector requirements anywhere prompt injection is discussed.
- [ ] Add unified automation visibility requirements later so cron/heartbeat/Q-jobs are not fragmented.