openclaw - 💡(How to fix) Fix Integrate YOLT-style command classification with OpenClaw approvals

Cross-reference: https://github.com/voitta-ai/voitta-yolt/issues/43

Context: during a live OpenClaw production-debug/deploy loop, approval-gated commands created unnecessary friction:

• The operator approved the card, but approval UI/context could be on another machine/KVM.
• If the card timed out, the agent had to reconstruct or retry the command.
• Some commands were low-risk diagnostics/verification, but still required manual approval because the allowlist only saw the shell shape, not the semantic risk.

voitta-yolt is currently scoped around Claude Code / Codex command-hook workflows, but its command classifier is directly relevant to OpenClaw’s native approval flow.

Proposal: add an OpenClaw integration path for YOLT-style command classification.

Possible shape:

• OpenClaw approval pipeline can optionally call a command-risk classifier before presenting an approval card.
• Classifier returns: decision (allow, ask, deny), confidence, matched rule, normalized command/script, and explanation.
• Low-risk/read-only commands can be auto-approved under operator policy.
• Mutating, network-sensitive, destructive, or ambiguous commands still require explicit approval.
• Approval events remain fully auditable: exact command, classification result, policy source, and approval source.
• If approval cards land on another box/KVM or expire, operator intent should be recoverable without rerunning discovery or forcing the agent to blindly retry.

Why this is win-win:

• OpenClaw gets less noisy approval UX while preserving human oversight.
• YOLT gets a broader embedding target beyond Claude Code/Codex.
• The integration keeps policy and audit boundaries explicit instead of teaching agents to work around approvals.

Open questions:

1. Should OpenClaw consume YOLT as a subprocess/CLI, library, or protocol endpoint?
2. What minimum output schema should YOLT expose for OpenClaw approval decisions?
3. Should OpenClaw ship with built-in YOLT-compatible policy examples for common safe diagnostics (git status, vercel logs, aws s3api get-*, curl -I, etc.)?
4. How should expired approval cards be resumed or renewed without losing the original command identity?