Initial project documentation and status
This commit is contained in:
@@ -0,0 +1,39 @@
|
||||
# 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?
|
||||
Reference in New Issue
Block a user