Files
ATOCore/docs/openclaw-atocore-shared-client-consolidation-preview.md

2.8 KiB

OpenClaw x AtoCore Shared-Client Consolidation Preview

Status

Proposal only. Not applied.

Why this exists

The current OpenClaw helper script duplicates AtoCore-calling logic that already exists in the shared operator client:

  • request handling
  • fail-open behavior
  • project detection
  • project lifecycle command surface

The preferred direction is to consolidate OpenClaw toward the shared operator client pattern documented in docs/architecture/llm-client-integration.md.

Goal

Keep the OpenClaw skill and operator policy in OpenClaw, but stop maintaining a separate Bash implementation of the AtoCore client surface when the shared client already exists in /home/papa/ATOCore/scripts/atocore_client.py.

Non-goals for this preview

  • no implementation in this phase
  • no runtime change in this phase
  • no new helper command in this phase
  • no change to approval policy in this preview

Preview diff

This is a conceptual diff preview only. It is not applied.

--- a/skills/atocore-context/scripts/atocore.sh
+++ b/skills/atocore-context/scripts/atocore.sh
@@
-#!/usr/bin/env bash
-set -euo pipefail
-
-BASE_URL="${ATOCORE_BASE_URL:-http://dalidou:8100}"
-TIMEOUT="${ATOCORE_TIMEOUT_SECONDS:-30}"
-REFRESH_TIMEOUT="${ATOCORE_REFRESH_TIMEOUT_SECONDS:-1800}"
-FAIL_OPEN="${ATOCORE_FAIL_OPEN:-true}"
-
-request() {
-  # local curl-based request logic
-}
-
-detect_project() {
-  # local project detection logic
-}
-
-case "$cmd" in
-  health) request GET /health ;;
-  projects) request GET /projects ;;
-  auto-context) ... ;;
-  register-project) ... ;;
-  refresh-project) ... ;;
-  ingest-sources) ... ;;
-esac
+#!/usr/bin/env bash
+set -euo pipefail
+
+CLIENT="${ATOCORE_SHARED_CLIENT:-/home/papa/ATOCore/scripts/atocore_client.py}"
+
+if [[ ! -f "$CLIENT" ]]; then
+  echo "Shared AtoCore client not found: $CLIENT" >&2
+  exit 1
+fi
+
+exec python3 "$CLIENT" "$@"

If and when this is implemented, the safer shape is:

  1. keep policy and approval guidance in OpenClaw instructions and skill text
  2. delegate actual AtoCore client behavior to the shared operator client
  3. avoid adding any new helper command unless explicitly approved
  4. keep read-path and approved-operator-path distinctions in the OpenClaw guidance layer

Risk notes

Potential follow-up concerns to handle before applying:

  • path dependency on /home/papa/ATOCore/scripts/atocore_client.py
  • what should happen if the AtoCore repo is unavailable from the OpenClaw machine
  • whether a thin compatibility wrapper is needed for help text or argument normalization
  • ensuring OpenClaw policy still blocks unapproved Discord-originated mutations even if the shared client exposes them

Bottom line

The duplication is real and consolidation is still the right direction. But in this phase it remains a proposal only.