Bring Cabra/OpenClaw to LifeOS operational readiness after update

[marcusglee11]

Objective

Bring Cabra/OpenClaw back to the required LifeOS operational authority level after the OpenClaw update by removing runtime drift and proving reconstructable governance readiness.

Hermes review verdict: Cabra is usable for supervised coordination, but not yet at LifeOS-required operational authority level. The gap is trustable, reconstructable execution: orientation access, config/model drift, stale automation, and insufficient readiness evidence.

Current observed state

• OpenClaw runtime: 2026.4.27; npm update available 2026.5.3-1 but not run.
• Live session model: openai-codex/gpt-5.5.
• Config/default drift: main agent config appears to prefer openai-codex/gpt-5.4 while current session uses gpt-5.5.
• Memory backend: qmd; 37 memory files found under workspace memory.
• Gateway config validates cleanly.
• LifeOS repo reachable at /mnt/c/Users/cabra/Projects/LifeOS through shell.
• First-class OpenClaw read tool is sandboxed to workspace and cannot read /mnt/c/... mandatory LifeOS orientation files.
• lifeos-read skill references scripts/lifeos.sh, but that script is not present in the workspace.
• Cron: 9 jobs exist, all disabled; several have stale delivery warnings.
• HEARTBEAT.md is empty/comment-only.
• TOOLS.md is still mostly template content.
• Native subagent allowlist exposes only main.
• Messaging posture appears mostly right: WhatsApp denied/disabled, Slack channel disabled, Telegram scoped, Webchat allowed.
• Dispatch inbox is empty except .gitkeep.

Required outcome

A fresh Cabra session can independently:

1. Read mandatory LifeOS orientation sources through an approved/repeatable lane.
2. Resolve and report the intended model/fallback chain reproducibly.
3. Access memory and retrieve relevant operating directives.
4. Verify LifeOS dispatch inbox and current WIP state.
5. Prove messaging/write gates are fail-closed where required.
6. Run a single readiness smoke gate and produce timestamped evidence.
7. Explain cron/heartbeat/tooling state without stale ambiguity.

Plan

Phase 0 — Evidence snapshot / no-change baseline

• Capture current OpenClaw version, gateway status, model status, config hash, enabled plugins, channels, cron jobs, node status, and active sessions.
• Capture current LifeOS orientation attempt using both first-class read path and shell fallback.
• Record all known failures as baseline, not regressions.

Acceptance evidence:

• Timestamped baseline artifact under artifacts/evidence/ or equivalent canonical evidence path.
• Includes redacted config excerpts, no secrets.

Phase 1 — Repair LifeOS orientation access

Problem: mandatory orientation currently depends on shell fallback; the approved skill path is broken.

Tasks:

• Decide canonical LifeOS local path for Cabra/OpenClaw reads.
• Repair lifeos-read skill so it works in the actual runtime, or retire/replace it with an explicitly supported local orientation command.
• Ensure the mandatory files are readable through the approved lane:
  • config/tasks/backlog.yaml
  • docs/11_admin/LIFEOS_STATE.md
  • config/governance/delegation_envelope.yaml
  • artifacts/dispatch/inbox/
• Document whether /mnt/c/... shell fallback is allowed, temporary, or forbidden.

Acceptance evidence:

• Fresh Cabra session reads all four orientation sources without ad hoc path guessing.
• Smoke output lists exact paths/tools used.
• No sandbox bypass surprise.

Phase 2 — Resolve model/config drift

Problem: live session uses gpt-5.5; config appears to define gpt-5.4 for main.

Tasks:

• Inspect effective model resolution order: config default, agent override, session override, env override, runtime override.
• Decide intended primary model for Cabra main.
• Align config/session behavior to the intended model.
• Keep fallbacks explicit.

Acceptance evidence:

• Fresh session status shows intended primary and fallbacks.
• Config readback matches intended behavior or documents intentional runtime override.
• Drift note closed with cause identified.

Phase 3 — Create LifeOS readiness smoke gate

Build a repeatable readiness command/procedure that proves Cabra can safely operate as COO.

Smoke must check:

• OpenClaw/gateway health.
• Effective model and fallbacks.
• Memory backend/search availability.
• LifeOS mandatory orientation read.
• Dispatch inbox visibility.
• GitHub bus visibility/auth status for canonical control-plane work.
• Messaging send policy / channel gates.
• Cron inventory state.
• Native subagent/EA routing capability.
• No paired nodes, or paired-node state if later enabled.

Acceptance evidence:

• One command/procedure documented.
• One timestamped smoke report with pass/fail rows.
• Failures are explicit and actionable.

Phase 4 — Clean cron/heartbeat/tooling authority

Problem: disabled/stale automation and empty canonical-looking files create false confidence.

Tasks:

• Inventory all cron jobs.
• Classify each: keep disabled, delete stale, repair, or explicitly re-enable.
• Do not re-enable unattended automation without Boss/CEO approval.
• Populate HEARTBEAT.md with actual heartbeat policy/cadence or mark it intentionally empty/non-operational.
• Populate TOOLS.md with real local surfaces/path notes, or mark it explicitly non-authoritative template.

Acceptance evidence:

• Cron before/after inventory with purpose and disposition for every job.
• HEARTBEAT.md and TOOLS.md readback included.
• No stale route warnings left unexplained.

Phase 5 — Subagent / EA routing readiness

Problem: native subagent allowlist exposes only main, limiting conductor/worker architecture.

Tasks:

• Decide required bounded specialist lanes: e.g. quick/read-only, review, EA/coding-agent bridge, no-external-send worker.
• Add only minimal allowed agents with explicit tool/send/write policy.
• Verify unauthorized lanes remain blocked.

Acceptance evidence:

• Agent list readback after changes.
• Positive test for intended lane availability.
• Negative test for unauthorized send/write where applicable.

Phase 6 — Messaging safety verification

Tasks:

• Verify WhatsApp remains denied unless explicitly approved.
• Verify Slack channel disabled state.
• Verify Telegram is scoped to allowed sender/group policy.
• Verify Webchat remains allowed.
• Avoid live external send tests unless explicitly approved; prefer dry-run/policy readback.

Acceptance evidence:

• Redacted messaging config/policy snapshot.
• Dry-run or policy readback proving deny/allow gates.

Phase 7 — Update canary decision

Problem: update exists, but updating first may obscure known drift.

Tasks:

• Compare OpenClaw 2026.5.3-1 release notes against known failures.
• If relevant, create pre-update snapshot, canary plan, rollback plan.
• Only run update after explicit approval.

Acceptance evidence:

• Release relevance note.
• Pre-update baseline.
• Canary + rollback procedure.
• Post-update smoke, if update is approved and executed.

Definition of done

• Fresh Cabra session passes the LifeOS readiness smoke, or fails only on explicitly accepted non-blockers.
• Required model/fallback behavior is reproducible.
• Mandatory orientation is reliable and not dependent on hidden shell improvisation.
• Cron/heartbeat/tool authority state is documented and cleaned.
• Messaging gates are proven fail-closed.
• Subagent/EA routing readiness is either implemented or explicitly deferred with rationale.
• Evidence is stored in canonical LifeOS evidence location.

Risks

• Config changes may require OpenClaw restart; use safe restart path only.
• Updating OpenClaw before resolving known drift may create confounding failures.
• Expanding subagent access can broaden authority accidentally; keep roles narrow.
• Live external messaging tests can violate send policy; use dry-runs/policy readback unless approved.

Recommended owner split

• Cabra/COO: coordination, issue tracking, evidence requirements, status reconciliation.
• EA/coding agent: implementation of skill/config/script changes.
• Boss/CEO: approve config changes that affect providers, external messaging, autonomy, or update execution.

Source

Prompted by Cabra self-status report and Hermes CLI review on 2026-05-04.

[marcusglee11]

Control amendment — execution constraints before dispatch

Issue #108 is the umbrella/control issue. It must not be executed as one monolithic EA work order.

First implementation slice is limited to Phases 0–3 only:

• capture no-change baseline
• repair or replace LifeOS orientation access
• resolve model/config drift by inspection first
• create and run the LifeOS readiness smoke gate

The following actions require explicit Boss/CEO approval before execution:

• OpenClaw update
• OpenClaw restart
• provider/model config mutation
• cron re-enable
• external message send test
• messaging channel expansion
• native subagent/EA authority expansion
• deletion of existing automation/config state

Evidence must be written to:

artifacts/evidence/cabra-readiness/<UTC_TIMESTAMP>/

Required evidence files:

• manifest.yaml or manifest.json
• baseline.md
• smoke-report.md
• redacted config excerpts or hashes
• command transcript/log
• residual blockers list

The readiness smoke must be runnable from a fresh Cabra/OpenClaw session and must not depend on hidden shell improvisation or ad hoc path guessing.

Phases 4–7 require separate gated child issues after Phase 0–3 evidence is reviewed.

Preserve all existing phase content unless directly contradicted by these amendments.

No runtime/config/tooling changes are authorized by this amendment.

[marcusglee11]

Verdict: APPROVE as amended for first-slice dispatch.

Verified the control amendment posted in #108. The issue is now correctly framed as an umbrella/control issue rather than a monolithic EA work order.

Approved scope for first dispatch:

• Phases 0–3 only
• no-change baseline
• LifeOS orientation access repair/replacement
• model/config drift inspection before any mutation
• repeatable LifeOS readiness smoke gate

The amendment correctly adds hard Boss/CEO approval gates for:

• OpenClaw update
• OpenClaw restart
• provider/model config mutation
• cron re-enable
• external message send test
• messaging channel expansion
• native subagent/EA authority expansion
• deletion of automation/config state

Evidence requirements are now sufficiently concrete:

• artifacts/evidence/cabra-readiness/<UTC_TIMESTAMP>/
• manifest.yaml or manifest.json
• baseline.md
• smoke-report.md
• redacted config excerpts or hashes
• command transcript/log
• residual blockers list

Risk is acceptable for a bounded Phase 0–3 readiness slice. Phases 4–7 should remain deferred to separate gated child issues after Phase 0–3 evidence is reviewed.

No runtime/config/tooling changes are approved by this review comment.

[marcusglee11]

First-slice dispatch — Phase 0–3 readiness evidence

Status: APPROVED AS AMENDED for bounded first-slice dispatch.

Scope: Execute only the Phase 0–3 slice defined in the control amendment:

1. Capture no-change baseline.
2. Repair or replace LifeOS orientation access only if the repair stays within the approved Phase 0–3 scope and does not cross any approval gate.
3. Inspect model/config drift and produce a resolution plan. Do not mutate provider/model config without explicit Boss/CEO approval.
4. Create and run a repeatable LifeOS readiness smoke gate.

Hard constraints:

Do not perform any of the following without explicit Boss/CEO approval:

• OpenClaw update
• OpenClaw restart
• provider/model config mutation
• cron re-enable
• external message send test
• messaging channel expansion
• native subagent/EA authority expansion
• deletion of existing automation/config state

Evidence path:

artifacts/evidence/cabra-readiness/<UTC_TIMESTAMP>/

Required evidence files:

• manifest.yaml or manifest.json
• baseline.md
• smoke-report.md
• redacted config excerpts or hashes
• command transcript/log
• residual blockers list

Additional requirements:

• The readiness smoke must be runnable from a fresh Cabra/OpenClaw session.
• The smoke must not depend on hidden shell improvisation or ad hoc path guessing.
• If a repair would require crossing an approval gate, stop and report the exact approval needed instead of proceeding.
• Phases 4–7 are out of scope for this dispatch and require separate gated child issues after Phase 0–3 evidence review.

Return required:

• Evidence directory path.
• Summary of pass/fail readiness checks.
• Any residual blockers.
• Explicit confirmation that no approval-gated action was performed.

[marcusglee11]

First-slice readiness dispatch complete via Claude Code CLI (EA); Cabra verified evidence.

Evidence directory:
artifacts/evidence/cabra-readiness/20260504T132436Z/

Files verified:

• manifest.yaml
• baseline.md
• smoke-report.md
• config-hashes.md
• command-transcript.md
• blockers.md

Readiness verdict: CONDITIONAL PASS

Pass highlights:

• OpenClaw binary/status and gateway reachable.
• Mandatory LifeOS orientation sources accessible.
• Dispatch inbox visible and empty.
• GitHub auth/bus readable; issue Bring Cabra/OpenClaw to LifeOS operational readiness after update #108 readable.
• Memory plugin enabled.
• Python/test smoke passed: 3216 tests collected; codex-only dispatch tests 3/3 passed; auto-dispatch tests 29/29 passed.
• Messaging inspection was readback/dry-run only; no external send test performed.

Residual blockers:

1. ZEN_*_KEY env vars absent in the inspected shell, so Zen API dispatch would fail from that environment unless secrets are injected into the actual OpenClaw launch environment.
2. artifacts/health/provider_state.json is missing; needs explicit approval to initialize if desired.

Warn only:

• OpenClaw update available but not applied.
• Cron inventory empty; nightly queue exists but no trigger observed.
• Node service systemd unit not installed.

Confirmed not performed: no OpenClaw update/restart, no provider/model config mutation, no cron re-enable, no external message send, no messaging expansion, no native subagent/EA expansion, no deletion, no commit/push/PR/merge.

[marcusglee11]

Phase 0–3 reconciliation complete.

Corrected Zen-key classification

Reclassified from “missing secrets” to provider-key visibility resolved through the actual LifeOS key loader.

The prior finding only proved the shell environment did not expose ZEN_*_KEY; it did not prove secrets were absent. Verification was rerun from the LifeOS repo root through the loader path used by runtime.agents.opencode_client.OpenCodeClient, with key env names mapped by config/models.yaml.

Exact verification command used:

python3 - <<'PY'
from runtime.agents.models import load_model_config
from runtime.agents.opencode_client import OpenCodeClient
cfg = load_model_config('config/models.yaml')
roles = sorted(cfg.agents.keys())
for role in roles:
    client = OpenCodeClient(role=role, log_calls=False)
    val = client._load_api_key_for_role(role, provider='zen')
    print(f'{role}: {"FOUND" if bool(val) else "MISSING"}')
PY

Redacted output — values not printed:

build_cycle: FOUND
builder: FOUND
council_reviewer: FOUND
council_reviewer_security: FOUND
designer: FOUND
reviewer_architect: FOUND
steward: FOUND

provider_state.json ownership finding

artifacts/health/provider_state.json is not a blocking canonical source for active Phase 0–3 Codex/Cabra COO operation.

Finding:

• config/dispatch.yaml names it as provider health state.
• runtime/orchestration/dispatch/provider_pool.py defines it as HEALTH_STATE_RELATIVE_PATH and writes it only via ProviderPool.persist().
• runtime/orchestration/dispatch/engine.py::DispatchEngine.provider_health() currently returns Phase 1 stub data with note: ProviderPool not active in Phase 1.
• Therefore its absence is best classified as generated/future health cache, expected absent/non-blocking in Phase 0–3, not an active readiness blocker.

Evidence durability

Preferred PR durability was attempted through Claude Code EA, but commit/PR was not completed because the repo had a stale .git/index.lock. I did not delete the lock under this narrow pass. Using the approved alternative: hashes/readbacks posted here.

Evidence directory on local workspace:
artifacts/evidence/cabra-readiness/20260504T132436Z/

SHA256 / size readback:

1348ef9088490b0b05603723cdfa5838cb313d38d4459381673011edd3d7e2c7  baseline.md               6902 bytes
c7990e3872c7ccc6a25d51a5b6882400154158a96c3b1ee4d98ba598975c531d  blockers.md               4753 bytes
98d2230ff2e49ed78b4b8f7ec5d42fcb586aa88c2d3a292917119c7364809171  command-transcript.md      9008 bytes
7ebe6f8f50236c7d6fbf1f9ffd7137de9e8b8ee548782ebe2411af20d5e12f28  config-hashes.md           1715 bytes
6200ab61600e63d3c7cc9da51047f92a448bd4e84c809c0df9a8655a7f35ef49  manifest.yaml              2499 bytes
b8eb0bac0de87503ae2c8c92eb62041e3d664e2c0fa0f8ecd067cb2fc96aa572  reconciliation.md          3891 bytes
70e4ad7aa446d79aeaf68d59aa980cdf7845ed7323db091f70901b097fc224c6  smoke-report.md            6272 bytes

Readback summary:

• manifest.yaml: Phase 0–3 manifest, issue/comment refs, authority constraints, files and commands.
• baseline.md: OpenClaw/gateway/model/memory/orientation/GitHub/messaging/cron/node/EA routing baseline.
• smoke-report.md: smoke table and repeatable procedure; original Zen/provider-state findings superseded by this reconciliation.
• config-hashes.md: redacted config hashes and no secret values.
• command-transcript.md: command/output transcript.
• blockers.md: original blocker list; Zen/provider-state classifications superseded by reconciliation.
• reconciliation.md: corrected Zen-key loader verification, provider_state ownership finding, revised PASS verdict.

Revised Phase 0–3 verdict

PASS

Rationale:

• Zen keys verify as FOUND through the actual LifeOS loader.
• provider_state.json is a generated/future health cache and non-blocking for active Phase 0–3 operation.
• No active Codex/Cabra COO operation depends on a missing/failed provider state in this phase.

Confirmed not performed: no OpenClaw update/restart, no provider/model config mutation, no cron re-enable, no external message send, no messaging expansion, no native subagent/EA authority expansion, no automation/config state deletion, no secret disclosure.

[marcusglee11]

Phase 4 child issue opened: #109 — cron / heartbeat / tooling authority cleanup.

Link: #109

Per instruction, issue created only. No implementation started.

[marcusglee11]

Phase 0–3 readiness evidence has now been persisted remotely.

PR: #110
Branch: evidence/issue-108-phase0-3-readiness
Commits:

• 1fe9a756 — Phase 0–3 readiness evidence under artifacts/evidence/cabra-readiness/20260504T132436Z/
• b76b726d — branch quality-gate fixes in runtime/tests/test_codex_only_dispatch_policy.py

Verification: pytest runtime/tests/test_codex_only_dispatch_policy.py -q → 3 passed.

Constraints honored: no OpenClaw update/restart, no provider/model config mutation, no cron re-enable, no external send test, no messaging expansion, no native subagent authority expansion, no unrelated file inclusion. artifacts/github_issue_pr_fetches_2026-04-29.md remains untouched/untracked.