**[Feature/Bug]: Missing CLI bounds-testing commands for WASM Enclave execution (`coreason-server engine`)**

[gitvishalshetty]

Overview

Currently, there is an architectural gap that prevents direct, automated testing of the WASM sandbox boundaries (like OpenShell) from the command line. Automated CI/CD diagnostics attempt to interact with the WASM execution engine directly via the CLI (e.g., using hypothetical subcommands like coreason-server engine sandbox-start or sandbox-exec), but these commands do not exist.

Because coreason-server is structured strictly as a backend daemon/orchestrator (exposing API endpoints like serve or admin features like authority), it does not expose a low-level CLI runner for the enclave engine. As a result, it is currently impossible to programmatically inject host-filesystem access attempts (like reading /etc/passwd) via the CLI to mathematically prove that the WASM isolation boundary is holding.

🛠️ Steps to Reproduce (The Architectural Gap)

1. Attempt to interact with the core engine directly via the CLI to boot an enclave:

   coreason-server engine sandbox-start --enclave "OpenShell" --memory-pages 128

2. Attempt to execute an isolation breach test against the host filesystem:

   coreason-server engine sandbox-exec --enclave "OpenShell" --cmd "cat /etc/passwd"

3. Observation: The CLI router immediately fails with:
   error: unrecognized subcommand 'engine' (or similar CLI parse failure).
4. Running coreason-server --help confirms that no low-level enclave testing subcommands are exposed.

🎯 Expected Behavior

The CoReason architecture should provide a designated, programmatic way to spin up an isolated WASM enclave and execute arbitrary commands inside it for boundary testing. If the enclave attempts to access the host filesystem (e.g., /etc/passwd), the engine should trap the execution and return a clear Permission Denied or Unauthorized exit code to the standard output.

💡 Action Items / Proposed Solutions

The engineering team needs to decide how boundary testing should interact with the enclave engine.

1. Option A (API-Driven Architecture):
   Declare that the CLI will never support direct enclave execution. If so, document the required HTTP/gRPC API endpoints that CI/CD pipelines should curl to trigger these sandbox isolation tests against a running daemon (coreason-server serve).
2. Option B (Diagnostic CLI Commands):
   Add a hidden or diagnostic CLI subcommand group (e.g., coreason-server sys-diagnostics sandbox-exec) specifically designed for automated isolation testing.
3. Option C (Dedicated Engine Binary):
   If coreason-server is strictly an orchestrator, expose a secondary standalone binary (e.g., coreason-engine) during the cargo build process that acts purely as a local WASM runner (similar to wasmtime or docker run), allowing automated bash testing to target it directly.