40 lines
1.3 KiB
Markdown
40 lines
1.3 KiB
Markdown
# Architecture decision record
|
|
|
|
## ADR-0001 — Begin with a read-only integration
|
|
|
|
**Status:** Accepted
|
|
**Date:** 2026-08-24
|
|
|
|
### Decision
|
|
|
|
The first milestone will expose only device inventory, status, and safe metadata. Remote command execution and state-changing actions will not be part of the initial MVP.
|
|
|
|
### Rationale
|
|
|
|
This validates connectivity, authentication, data mapping, logging, and OpenClaw tool behavior while minimizing the blast radius of implementation mistakes.
|
|
|
|
### Consequences
|
|
|
|
- Initial usefulness is limited to visibility and reporting.
|
|
- Diagnostics require a later, separately reviewed capability.
|
|
- The bridge can be tested without risking endpoint changes.
|
|
|
|
## ADR-0002 — Prefer a local bridge over browser automation
|
|
|
|
**Status:** Proposed
|
|
**Date:** 2026-08-24
|
|
|
|
### Decision
|
|
|
|
Investigate a local API/MCP-style bridge first. Browser automation remains a fallback for discovery or occasional operations, not the primary architecture.
|
|
|
|
### Rationale
|
|
|
|
A typed local interface is easier to constrain, test, audit, and maintain than UI selectors and browser sessions.
|
|
|
|
### Open questions
|
|
|
|
- What supported MeshCentral API surface is available in the deployed version?
|
|
- Should the bridge run in the MeshCentral LXC, a separate LXC, or on ledclaw01?
|
|
- Which OpenClaw integration mechanism best fits the final tool contract?
|