meshcentral-openclaw-bridge/LIVE-TEST-PROCEDURE.md

Read-Only MeshCentral Live-Test Procedure

Status: Prepared and authorized for execution under the project scope Authorization: Rob authorized read-only MeshCentral access for this project on 2026-08-26.

Preconditions

Do not proceed unless all are confirmed:

• The bridge runs from an approved trusted management host.
• mesh.ledrew.me resolves to the intended internal MeshCentral instance.
• The control channel is the intended /control.ashx WebSocket endpoint.
• TLS certificate validation succeeds from the bridge host, or an approved private CA bundle is configured. Never disable verification.
• sa_clawdia is a dedicated read-only integration account.
• The exact PVE3 device ID/group is known and is the only configured target allowlist entry.
• The password is available only through a protected runtime secret mechanism (for example a 0600 environment file); it is not placed in source, prompts, command arguments, or logs.
• Audit-log destination and permissions are confirmed.
• Local verification has passed: tests, build, and lint.

Allowed operations

Only these read-only operations may be used:

1. Connect/authenticate and perform the health/connectivity check.
2. Query MeshCentral server version.
3. List device groups.
4. List devices, filtered to the approved scope.
5. Retrieve metadata for the single approved PVE3 target.

Do not request events, diagnostics, commands, shell access, file transfer, power operations, user/group changes, reboots, shutdowns, or any state-changing operation.

Execution checklist

1. Record the test start time and the approved target identifier without recording secrets.
2. Load the protected runtime secret without echoing it or placing it in the command line.
3. Run npm run build, then execute npm run live-test; the runner reads the protected credential file internally, uses the fixed MeshCentral endpoint/account, and has no target or operation CLI arguments.
4. The runner sends only server-version, device-group, and PVE3 inventory requests, one at a time.
5. Verify every result is scoped to the approved target and contains no unexpected credential/token material.
6. Confirm audit records contain operation, target, status, and timestamp, but no password, TOTP, auth header, session token, or raw sensitive output.
7. Disconnect cleanly.
8. Record pass/fail results, server version, target identifier, timestamps, and any non-secret error text.

Stop conditions

Stop immediately and do not retry automatically if:

• TLS validation fails or the endpoint/path is unexpected.
• Authentication or authorization is unclear.
• The target cannot be resolved unambiguously to PVE3.
• Any operation would execute a command or change state.
• Output contains credentials, tokens, or unexpected sensitive data.
• The server response fails schema/action validation.
• The bridge attempts to contact any target outside the allowlist.

Rollback

For a failed or ambiguous test: disconnect/stop the bridge, preserve non-secret logs, review audit records, and rotate the integration credential if exposure is suspected. Do not touch PVE1/PVE2 production infrastructure.