Why start here?
Tenter shows whether execution is truly ready and stable instead of having looked green once.
Execution / Runtime
The proof that it actually runs
Runtime evidence, readiness, and provable execution.
Tenter shows whether execution is truly ready and stable instead of having looked green once.
jhf-tenter is the runtime toolkit and verification baseline for the OpenClaw voice and operator lane. It owns checked-in runtime contracts, Asterisk stack definitions, voice verification flows, package artifacts, and the repo-side documentation that other repos can consume safely.
This repository is not a product backend and not a second control plane. When Fabric already publishes canonical contract, readiness, or combination truth, jhf-tenter only consumes that truth read-only and documents its own consumer or runtime boundary.
Status Available now README sync 29 Apr 2026
When do I need this?
Start here when you want to know whether the system truly runs instead of merely sounding good.
What role it plays here
Runtime evidence, readiness, and provable execution.
Without Tenter, runtime remains a gut feeling. With Tenter, operational state becomes verifiable.
What the module actually does
It makes visible whether execution is truly ready, stable, and traceable instead of merely having looked green once.
At the core
Canonical voice contract keys present in this repo:
VOICE_ROUTER_RUNTIME_SLICE
VOICE_ASTERISK_ARI_ADAPTER_SLICE
VOICE_STT_TTS_OPENCLAW_FLOW_SLICE
VOICE_RUNTIME_VALIDATION_MATRIX
VOICE_DISCORD_ADAPTER_READINESS
Producer namespace posture for future shared event emission:
tenter.voice.*
Machine-readable repo identity and capability export:
fabric-manifest.json
scripts/export-fabric-metadata.py
Canonical Asterisk stack definition owned in this repo:
docs/ASTERISK_RUNTIME_STACK_SOURCE_OF_TRUTH.md
docs/CPU_SAFE_RUNTIME_GUARDRAILS_V1.md
docs/WINDOWS_SOFTPHONE_SMOKE_PATH.md
docs/WINDOWS_TRAY_LOCAL_AUDIO_RUNTIME_CONTRACT.md
runtime/asterisk-ari-live/docker-compose.yml
runtime/asterisk-ari-live/config/*
runtime/asterisk-gui-live/docker-compose.yml
these are the canonical Asterisk stack artifacts for tenter-owned ARI and GUI runtime definition
the canonical rendered live runtime state lives under .runtime/asterisk-ari-live/ and .runtime/asterisk-gui-live/ in the tenter checkout
the first Windows headset smoke path is now repo-owned through SIP on :15060 plus RTP :12000-12019
Repo-local voice runtime modules and smoke evidence:
src/jhf_tenter_voice
router, Asterisk adapter, STT, TTS, OpenClaw client, runtime, bring-up, live-call path
Verified Fabric read-only consumption for:
combinations profiles
producer-/consumer matrix
docs-standard
voice-events
Host-near verification against 192.168.1.172 for:
OpenClaw health on :18789
Fabric API on :28080
Asterisk ARI on :19088
Asterisk GUI runtime on :19089
Packaging and package verification workflow:
.gitea/workflows/ci.yml
scripts/package/*
What role it plays in the stack
Live-read back on 192.168.1.172 during this documentation pass:
openclaw-gateway is running on :18789, and /healthz returns {"ok":true,"status":"live"}. jhf-fabric-api is running on :28080. Fabric surfaces return 200 on: - /api/v1/contracts/matrix - /api/v1/contracts/docs-standard - /api/v1/voice/contracts/events - /api/v1/combinations/profiles jhf-voice-asterisk-ari is running on :19088. jhf-voice-asterisk-gui is running on :19089. jhf-heddle-keycloak is running on :18090.
Known live nuance:
The GUI runtime is verified as healthy by container health and reachable on the host IP, but health probing should follow the tenter-owned verifier and deployment execution path instead of inventing a second ad hoc liveness rule. The only active external blocker from the broader runtime suite remains the host-owned OpenClaw status wrapper issue in openclaw-environment#30.
What this looks like in practice
Without Tenter, runtime remains a gut feeling. With Tenter, operational state becomes verifiable.
A signal comes in.
The system assigns the right role and path.
Execution happens through controlled handoffs.
Result and evidence return together.
How it fits into the system
Tenter does not stand alone. It connects to neighboring modules so a single capability becomes dependable follow-through.
Important boundary
Tenter stays bounded to its role as Runtime evidence, readiness, and provable execution. It does not replace other modules; it makes its part of the system traceable, connectable, and reviewable.
What comes next
What is intentionally out of scope
No repo-owned public dashboard or PBX admin suite.
No browser/WebRTC operator call surface yet.
No local replacement for Fabric combination or contract truth.
No automatic host mutation from CI.
No mandatory carrier runtime for the core agent-call path.
No production Discord runtime in this repo.
What keeps this page honest
This explanation stays anchored to the module’s current truth, including its real boundaries, responsibilities, and contracts.
Tenter is the layer for runtime proof, readiness, and operational evidence.
It makes visible whether execution is truly ready, stable, and traceable instead of merely having looked green once.
Without Tenter, runtime remains a gut feeling. With Tenter, operational state becomes verifiable.
Active part of the system with clearly defined boundaries.
Source and repo truth
This page is rendered from the repo-owned projection truth and remains tied to the README, module boundaries, and status.
GitHub JaddaHelpifyr/jhf-tenterTenter
Without Tenter, runtime remains a gut feeling. With Tenter, operational state becomes verifiable.