[Feature] Design REPL / interactive shell for openhuman binary (skills & flow testing)

[senamakel]

Summary

Design an interactive terminal (REPL-style) experience for the openhuman CLI binary so contributors and operators can exercise core flows without the desktop app—with first-class support for skills (invoke, inspect state, errors, sandbox boundaries) and other domains as needed.

Problem

Today, validating behavior often means running the full stack (Tauri + sidecar + UI) or crafting JSON-RPC / HTTP calls by hand. That is slow for iteration, especially for skills (QuickJS runtime, tool wiring, registry, workspace paths). A lightweight, terminal-first loop would speed up:

• Skill authors and core developers debugging skill execution
• QA-style smoke checks of channel/agent/config flows from a shell
• Documentation and onboarding (“paste these commands in a REPL to see X”)

Constraints to call out in design: no accidental secret logging, same business rules as RPC where applicable (avoid a second implementation of skill policy), and clear scope (REPL for dev/test vs shipping to end users).

Solution (optional)

Treat this issue as design-first; implementation can follow in a separate PR.

Possible directions (not prescriptive):

• openhuman repl (or openhuman shell) subcommand that starts a read-eval-print loop with commands like skill list, skill run <id> …, rpc call <method> …, config show, help.
• Backing the REPL with existing internal APIs (call into openhuman::* / same paths the JSON-RPC server uses) so behavior matches production.
• Optional scriptable mode (--eval '…', stdin batch) for CI or quick one-liners.
• Heavy debug logging behind a flag, grep-friendly prefixes, redaction rules aligned with project norms.

Tradeoffs: REPL surface area vs maintenance; ensuring feature parity with RPC over time; Windows terminal UX.

Acceptance criteria

• Written design — Problem statement, target users (dev/core vs end user), and explicit non-goals for v1.
• Command / UX sketch — Example session for listing and invoking a skill, and at least one non-skill flow (e.g. config or a single JSON-RPC-style call).
• Architecture note — How the REPL reuses core code (vs duplicating logic); interaction with workspace, skills registry, and QuickJS runtime lifecycle.
• Safety — How secrets, tokens, and PII are avoided or redacted in REPL output and logs.
• Follow-up — Linked implementation issue(s) with rough milestones (MVP REPL → skills-focused commands → optional script mode).

Related

• Core binary and library: repo root Cargo.toml, src/main.rs / openhuman_core
• Skills runtime: src/openhuman/skills/
• JSON-RPC / CLI patterns: core_server, src/core/cli.rs, controller registry