Skip to main content

Integrations

Documentation Map​

Integrations

planned vs implemented bleibt pro Eintrag ueber die Abschnitte Implemented und Planned getrennt.

Internal Helpifyr Integrations​

jhf-deployment​

  • Direction: outgoing
  • Type: execution-contract
  • Surface: upgrade/openclaw/2026.3.13-to-2026.3.24/run-manifest.json, upgrade/openclaw/2026.3.13-to-2026.3.24/terraform-artifact-inputs.auto.tfvars.json, jhf-deployment/environments/test/scripts/{plan,create,verify,destroy}.sh
  • Auth: lokaler Repo-Zugriff plus operator-provided credentials oder host-lokale jhf-deployment Credentials ausserhalb dieses Repositories; kanonische Env-Variablen JHF_DEPLOYMENT_DIR, OPENCLAW_HOST, SSH_BIN, SSH_OPTIONS; kein Secret-Write-Back
  • Stability: partial
  • Versioning: pinned OpenClaw-Zielversion 2026.3.24 plus repo-lokaler execution contract
  • Owner: jhf-beam als execution tool, jhf-deployment als execution substrate

Implemented:

  • genau ein integrierter Pfad nutzt artifact inputs, scenario=openclaw-only und den vorhandenen verify path
  • genau ein Source-Baseline-Check fuer 2026.3.13 laeuft ueber ein gepinntes OpenClaw-Artefakt plus kanonisches Deployment-Baseline-Metadata
  • genau ein source-side capture laeuft vor create
  • ein realer create -> verify -> destroy Lauf ist fuer diesen Pfad belegt
  • compatibility posture bleibt lokal im Upgrade-Kit
  • der Moduswechsel auf helpifyr-integrated uebernimmt keine Credentials automatisch; Operator und Host bleiben Credential-Owner

Planned:

  • weiterer direkter Vergleich zwischen Source- und Target-Laufzeit auf derselben Testumgebung
  • keine Generalisierung vor einem zweiten realen Bedarf

jhf-fabric​

  • Direction: outgoing read-only
  • Type: repo-read
  • Surface: upgrade/openclaw/2026.3.13-to-2026.3.24/read-fabric-metadata.py, jhf-fabric/fabric-manifest.json, jhf-fabric/tests/fixtures/openclaw_runtime.json, upgrade/openclaw/2026.3.13-to-2026.3.24/compatibility/latest.json
  • Auth: lokaler Repo-Read oder fixture-basierter Read-Pfad; keine Secrets, kein Write-Back, keine repo-eigene API-Authentifizierung
  • Stability: partial
  • Versioning: additive ueber bestehende Manifest- und Doku-Kontrakte
  • Owner: jhf-beam als execution tool, jhf-fabric als Kontextquelle

Implemented:

  • ein read-first Metadata-Read konsumiert genau jhf-fabric Tool-Identitaet und OpenClaw-Runtime-Marker fuer denselben run path
  • current verify path ist read-first only
  • compatibility/latest.json und compatibility/archive-discovery.json bilden die stabile read-only Export-Surface fuer Fabric oder Operatoren
  • repo-eigene HTTP-Health-, Readiness-, Status-, Metrics- und Version-Endpunkte sind aktuell nicht vorhanden
  • kein Write-Back ist implementiert
  • Fabric liefert in diesem Pfad keinen Secret- oder Credential-Input
  • Fabric ist in diesem Pfad Shared Context, aber kein Execution- oder Storage-Owner
  • fabric-manifest.json plus compatibility/latest.json und runs/<run-id>/evidence.json sind die kleine Runtime-Registration- und Attachment-Surface dieses Repositories

Planned:

  • read-first auf echte Laufzeitquellen aus jhf-fabric, wenn diese fuer denselben Pfad stabil verfuegbar sind

truenas cold data storage​

  • Direction: outgoing
  • Type: storage-offload
  • Surface: /mnt/truenas-container/jhf-beam/runs, upgrade/openclaw/2026.3.13-to-2026.3.24/offload-run.sh
  • Auth: Host-Dateisystemzugriff auf <internal-runtime-redacted>
  • Stability: partial
  • Versioning: additive ueber Run-Evidence und Offload-Stubs
  • Owner: jhf-beam execution tool

Implemented:

  • abgeschlossene Runs mit evidence.json, overall_result und .run-complete koennen automatisch offloaded werden
  • aktive Runs mit .run-active bleiben lokal
  • lokaler Stub unter runs/offloaded/<run-id>.json
  • TrueNAS ist cold-data Ziel fuer tool-owned run artifacts, kein Shared Runtime Store

Planned:

  • keine weitere Cold-Data-Architektur

shared stores and services intentionally not used​

  • Direction: none
  • Type: excluded
  • Surface: Shared Postgres, Shared Queue, Shared Event Bus
  • Auth: nicht zutreffend
  • Stability: explicit-non-goal
  • Versioning: nicht zutreffend
  • Owner: bewusst nicht diesem Repository zugeordnet

Implemented:

  • keine technische Verbindung im aktuellen Repo
  • run evidence, compatibility exports und offload stubs bleiben dateibasiert und tool-owned
  • Shared Postgres ist fuer den einen Pfad explizit not used

Planned:

  • kein Ausbau ohne neuen expliziten Scope

host docker hygiene​

  • Direction: internal
  • Type: maintenance
  • Surface: ops/host/jhf-beam-docker-hygiene.sh, ~/.local/state/jhf-beam/docker-hygiene.log
  • Auth: Host-Docker-Zugriff auf <internal-runtime-redacted>
  • Stability: partial
  • Versioning: additive ueber Host-Skript und systemd timer
  • Owner: Host-Betrieb

Implemented:

  • getrennte reporting-first Docker-Hygiene mit konservativen Schwellwerten
  • optionale dangling-image- und build-cache-Prune-Pfade sind vorhanden, aber standardmaessig deaktiviert
  • runtime-readback fuer Promote-Entscheidungen bleibt ueber ops/host/read-openclaw-runtime-readback.sh nachvollziehbar

Planned:

  • keine automatische Volume-Loeschung

External Integrations​

openclaw​

  • Direction: outgoing read-only
  • Type: provider-contract
  • Surface: upgrade/openclaw/2026.3.13-to-2026.3.24/, upgrade/openclaw/2026.3.13-to-2026.3.24/checks.sh
  • Auth: operator-provided SSH-Zugang und runtime-nahe Verify-Schritte ausserhalb des Repositories; keine externe API im Repo dokumentiert
  • Stability: partial
  • Versioning: expliziter Versionspfad 2026.3.13 -> 2026.3.24
  • Owner: jhf-beam fuer den Upgrade-Pfad, openclaw fuer Runtime und Versionsartefakte

Implemented:

  • genau ein verify path fuer einen OpenClaw-Upgrade-Pfad
  • genau eine Source-Baseline fuer 2026.3.13
  • genau ein source-side capture fuer denselben run path
  • artifact inputs sind auf die Zielversion gepinnt

Planned:

  • read-first Metadata fuer denselben Pfad bleibt auf jhf-fabric und die gepinnte OpenClaw-Runtime-Sicht begrenzt
  • keine zweite Tool- oder Multi-Path-Architektur

gitea​

  • Direction: bidirectional logical integration
  • Type: repository-intake
  • Surface: .gitea/workflows/ci.yml, Repository-Remote und Actions-Status
  • Auth: Gitea-Repository-Zugriff und vorhandene Runner-Berechtigungen; vorhandene Gitea Secrets bleiben CI-intern
  • Stability: stable
  • Versioning: git commits auf main
  • Owner: jhf-beam Repository auf Gitea

Implemented:

  • Promotion-Issue-Bridge fuer den standardisierten Intake ist ueber ops/host/process-promotion-issue.sh dokumentiert

Event Contracts​

  • aktuell nicht vorhanden

MCP Integration​

  • aktuell nicht vorhanden

Planned Connections​

jhf-pattern​

  • Direction: outgoing read-only
  • Type: downstream-certification-reference
  • Surface: ../jhf-pattern/docs/testing/JHF_PATTERN_PRODUCTION_CERTIFICATION_STANDARD.md, ../jhf-pattern/docs/testing/JHF_PATTERN_LIVE_E2E_WAVE.md, ../jhf-pattern/docs/testing/JHF_PATTERN_BULLETPROOF_RERUN_WAVE.md, ../jhf-pattern/scripts/testing/run_live_e2e_wave.sh, ../jhf-pattern/scripts/testing/run_bulletproof_rerun_wave.sh
  • Auth: lokaler Repo-Read im gemeinsamen Workspace; kein Secret-Read, kein Write-Back
  • Stability: partial
  • Versioning: downstream ueber die publizierten jhf-pattern-Zertifizierungsstandards und deren Script-Entrypoints
  • Owner: jhf-pattern fuer den eigenen Runtime- und E2E-Standard, jhf-beam nur fuer die read-only Referenz und Boundary-Einordnung

Implemented:

  • jhf-beam konsumiert jhf-pattern ausschliesslich als downstream Referenz fuer dessen eigenen Production-Certification-Standard und die zugehoerigen Rerun-Entrypoints
  • die tool-eigene Koexistenz-Regression prueft bereits die Boundary, dass jhf-beam in einer gemeinsamen Fabric-Basis mit jhf-pattern keine Projekt-/Task-Steuerung, keine Deployment-Steuerung und keinen Write-Back beansprucht
  • jhf-beam uebernimmt dabei bewusst keine Runtime-, Workflow- oder Release-Wahrheit aus jhf-pattern, sondern referenziert nur dessen kanonische Zertifizierungsoberflaechen fuer spaetere Cross-Tool-Readiness und Supportability-Einordnung

Planned:

  • keine weitergehende technische Kopplung ohne realen Upgrade-, Compatibility- oder Operator-Bedarf

jhf-wire​

  • Direction: outgoing read-only
  • Type: repo-read
  • Surface: aktuell nicht im Repository belegt
  • Auth: unklar
  • Stability: planned
  • Versioning: unklar
  • Owner: unklar

Implemented:

  • keine technische Verbindung im aktuellen Repo

Planned:

  • kein Ausbau ohne realen Integrationsbedarf