docs(plans): scrub LmxProxy references from design plans

Remove the LmxProxy work package (WP-8) from phase-3b, the CD-DCL-1..6
protocol details, Q9/Q-P3B-2 from the questions log, the LmxProxy
component-design rows in requirements-traceability, and the inline
mentions across phase-0, phase-4, the gRPC streaming plans, and the
primary/backup data-connection plans.

docs/plans/2026-03-21-grpc-streaming-channel.md

@@ -92,7 +92,7 @@ Also add `<FrameworkReference Include="Microsoft.AspNetCore.App" />` if not alre
 
 **Step 3: Generate C# stubs**
 
-Run `protoc` locally to generate stubs. Check generated files into `src/ScadaLink.Communication/SiteStreamGrpc/`. Follow the same pattern as `src/ScadaLink.DataConnectionLayer/Adapters/LmxProxyGrpc/` — pre-generated, no protoc at build time.
+Run `protoc` locally to generate stubs. Check generated files into `src/ScadaLink.Communication/SiteStreamGrpc/` — pre-generated and checked in, no `protoc` at build time.
 
 **Step 4: Verify build**
 

docs/plans/2026-03-22-primary-backup-data-connections-design.md

@@ -5,7 +5,7 @@
 
 ## Problem
 
-Data connections currently support a single endpoint. If that endpoint goes down, the connection retries indefinitely at 5s intervals against the same address. When redundant infrastructure exists (e.g., two LmxProxy instances, two OPC UA servers), there is no way to automatically fail over to a backup.
+Data connections currently support a single endpoint. If that endpoint goes down, the connection retries indefinitely at 5s intervals against the same address. When redundant infrastructure exists (e.g., two OPC UA servers), there is no way to automatically fail over to a backup.
 
 ## Design Decisions
 

docs/plans/2026-03-22-primary-backup-data-connections.md

@@ -685,7 +685,7 @@ Update the Data Connections workflow section to describe:
 
 ### Step 4: Update test_infra.md
 
-Add a note in the Remote Test Infrastructure section that the dual OPC UA servers (50000/50010) and dual LmxProxy instances (50100/50101) enable primary/backup testing.
+Add a note in the Remote Test Infrastructure section that the dual OPC UA servers (50000/50010) enable primary/backup testing.
 
 ### Step 5: Commit
 

docs/plans/grpc_streams.md

@@ -19,7 +19,7 @@ Debug streaming events currently flow through Akka.NET ClusterClient (`InstanceA
 | **Reconnection** | ClusterClient auto-reconnect (coarse, cluster-level) | gRPC channel-level reconnect per subscription |
 | **Serialization** | Akka.NET Hyperion (runtime IL, fragile across versions) | Protocol Buffers (schema-driven, cross-platform) |
 
-The DCL already uses this exact pattern — `RealLmxProxyClient` opens gRPC server-streaming subscriptions to LmxProxy servers for real-time tag value updates. This plan applies the same pattern to site→central communication.
+gRPC server-streaming is an established pattern for real-time tag value updates; this plan applies the same pattern to site→central communication.
 
 ## Architecture
 
@@ -216,7 +216,7 @@ message AttributeValueUpdate {
   string instance_unique_name = 1;
   string attribute_path = 2;
   string attribute_name = 3;
-  string value = 4;           // string-encoded (same as LmxProxy VtqMessage pattern)
+  string value = 4;           // string-encoded
   string quality = 5;         // "Good", "Uncertain", "Bad"
   int64 timestamp_utc_ticks = 6;
 }
@@ -230,7 +230,7 @@ message AlarmStateUpdate {
 }
 ```
 
-Pre-generate C# stubs and check into `src/ScadaLink.Communication/SiteStreamGrpc/` (same pattern as LmxProxy — no `protoc` in Docker for ARM64 compatibility).
+Pre-generate C# stubs and check into `src/ScadaLink.Communication/SiteStreamGrpc/` — no `protoc` in Docker for ARM64 compatibility.
 
 ## Server-Streaming Pattern (Site Side)
 
@@ -304,8 +304,6 @@ builder.Services.AddGrpc();
 app.MapGrpcService<SiteStreamGrpcServer>();
 ```
 
-Reference: `infra/lmxfakeproxy/Program.cs` uses the identical Kestrel setup.
-
 ## Client-Streaming Pattern (Central Side)
 
 ### gRPC Client Implementation
@@ -346,8 +344,6 @@ public async Task<StreamSubscription> SubscribeAsync(
 }
 ```
 
-Reference: `src/ScadaLink.DataConnectionLayer/Adapters/RealLmxProxyClient.cs` uses the identical background-task-reading-stream pattern for LmxProxy subscriptions.
-
 ### Port Resolution
 
 ### Client Factory
@@ -744,11 +740,6 @@ case ScriptErrorEvent error:
 
 | Pattern | File | Relevance |
 |---------|------|-----------|
-| Proto file definition | `src/ScadaLink.DataConnectionLayer/Adapters/Protos/scada.proto` | Same proto3 syntax, server streaming (`stream VtqMessage`) |
-| Pre-generated C# stubs | `src/ScadaLink.DataConnectionLayer/Adapters/LmxProxyGrpc/` | Same approach — checked-in stubs, no `protoc` at build time |
-| gRPC client + stream reader | `src/ScadaLink.DataConnectionLayer/Adapters/RealLmxProxyClient.cs` | Background task reads `ResponseStream`, invokes callback |
-| gRPC server implementation | `infra/lmxfakeproxy/Services/ScadaServiceImpl.cs` | Service base class override pattern |
-| Kestrel HTTP/2 setup | `infra/lmxfakeproxy/Program.cs` | `HttpProtocols.Http2`, `AddGrpc()`, `MapGrpcService<T>()` |
 | SiteStreamManager | `src/ScadaLink.SiteRuntime/Streaming/SiteStreamManager.cs` | Subscribe/filter by instance, per-subscriber buffer, DropHead overflow |
 | Per-site client caching | `CentralCommunicationActor._siteClients` dictionary | One client per site, refresh on address change |
 | Bridge actor pattern | `src/ScadaLink.Communication/Actors/DebugStreamBridgeActor.cs` | Per-session actor with callbacks, adapted to use gRPC instead of Akka messages |

docs/plans/phase-0-solution-skeleton.md

@@ -614,7 +614,7 @@ Phase 0 covers REQ-COM and REQ-HOST requirements. The following are split with o
 
 | REQ ID | Phase 0 Scope | Other Phase(s) Scope |
 |--------|---------------|---------------------|
-| REQ-COM-2 | Interface definition only | Phase 3B: OPC UA and LmxProxy implementations |
+| REQ-COM-2 | Interface definition only | Phase 3B: OPC UA implementation |
 | REQ-COM-4a | Interface definition only | Phase 1: `IAuditService` implementation in Configuration Database |
 | REQ-COM-5a-4 | Noted in plan; versioning rules documented | Phase 1/3A: Akka serialization binding configuration |
 | REQ-HOST-2 | Skeleton role branching with stub `AddXxx()` calls | Phase 1: Full service registration with real implementations |

docs/plans/phase-3b-site-io-observability.md

@@ -11,7 +11,7 @@
 Phase 3B brings the site cluster to life as a fully operational data collection, scripting, alarm evaluation, and health reporting platform. Upon completion, a site can:
 
 - Communicate bidirectionally with the central cluster using all 8 message patterns.
-- Connect to OPC UA servers and LmxProxy endpoints, subscribe to tags, and deliver values to Instance Actors.
+- Connect to OPC UA servers, subscribe to tags, and deliver values to Instance Actors.
 - Execute scripts in response to triggers (interval, value change, conditional).
 - Evaluate alarm conditions, manage alarm state, and execute on-trigger scripts.
 - Compile and execute shared scripts inline.
@@ -25,7 +25,7 @@ Phase 3B brings the site cluster to life as a fully operational data collection,
 | Component | Scope |
 |-----------|-------|
 | Central-Site Communication | Full — all 8 message patterns, correlation IDs, per-pattern timeouts, transport heartbeat |
-| Data Connection Layer | Full — IDataConnection, OPC UA adapter, LmxProxy adapter, connection actor, auto-reconnect, write-back, tag path resolution, health reporting |
+| Data Connection Layer | Full — IDataConnection, OPC UA adapter, connection actor, auto-reconnect, write-back, tag path resolution, health reporting |
 | Site Runtime | Full runtime — Script Actor, Alarm Actor, shared scripts, Script Runtime API (core operations), script trust model, site-wide Akka stream |
 | Health Monitoring | Site-side collection + central-side aggregation and offline detection |
 | Site Event Logging | Event recording, retention/purge, remote query with pagination |
@@ -66,8 +66,8 @@ Each bullet extracted from docs/requirements/HighLevelReqs.md at the individual
 
 ### Section 2.4 — Data Connection Protocols
 
-- [ ] `[2.4-1]` System supports OPC UA and LmxProxy (gRPC-based custom protocol with existing client SDK).
-- [ ] `[2.4-2]` Both protocols implement a common interface supporting: connect, subscribe to tag paths, receive value updates, and write values.
+- [ ] `[2.4-1]` System supports OPC UA.
+- [ ] `[2.4-2]` Protocol adapters implement a common interface supporting: connect, subscribe to tag paths, receive value updates, and write values.
 - [ ] `[2.4-3]` Additional protocols can be added by implementing the common interface.
 - [ ] `[2.4-4]` Data Connection Layer is a clean data pipe — publishes tag value updates to Instance Actors but performs no evaluation of triggers or alarm conditions.
 
@@ -221,15 +221,6 @@ Constraints from CLAUDE.md Key Design Decisions (KDD) and Component-*.md (CD) th
 - [ ] `[KDD-ui-4]` Dead letter monitoring as a health metric.
 - [ ] `[KDD-ui-5]` Site Event Logging: 30-day retention, 1GB storage cap, daily purge, paginated queries with keyword search.
 
-### LmxProxy Protocol Details
-
-- [ ] `[CD-DCL-1]` LmxProxy: gRPC/HTTP/2 transport, protobuf-net code-first, port 5050.
-- [ ] `[CD-DCL-2]` LmxProxy: API key auth, session-based (SessionId), 30s keep-alive heartbeat via `GetConnectionStateAsync`.
-- [ ] `[CD-DCL-3]` LmxProxy: Server-streaming gRPC for subscriptions (`IAsyncEnumerable<VtqMessage>`), 1000ms default sampling, on-change with 0.
-- [ ] `[CD-DCL-4]` LmxProxy: SDK retry policy (exponential backoff via Polly) complements DCL's fixed-interval reconnect. SDK handles operation-level transient failures; DCL handles connection-level recovery.
-- [ ] `[CD-DCL-5]` LmxProxy: Batch read/write capabilities (ReadBatchAsync, WriteBatchAsync, WriteBatchAndWaitAsync).
-- [ ] `[CD-DCL-6]` LmxProxy: TLS 1.2/1.3, mutual TLS (client cert + key PEM), custom CA trust, self-signed for dev.
-
 ### Communication Component Design
 
 - [ ] `[CD-Comm-1]` 8 distinct message patterns: Deployment, Instance Lifecycle, System-Wide Artifact, Integration Routing, Recipe/Command Delivery, Debug Streaming, Health Reporting, Remote Queries.
@@ -282,7 +273,6 @@ Constraints from CLAUDE.md Key Design Decisions (KDD) and Component-*.md (CD) th
 - [ ] `[CD-DCL-12]` Value update message format: tag path, value, quality (good/bad/uncertain), timestamp.
 - [ ] `[CD-DCL-13]` When Instance Actor stopped, DCL cleans up associated subscriptions.
 - [ ] `[CD-DCL-14]` On redeployment, subscriptions established fresh based on new configuration.
-- [ ] `[CD-DCL-15]` LmxProxy connection actor holds SessionId, starts 30s keep-alive timer on Connected state. On keep-alive failure, transitions to Reconnecting, client disposes subscriptions.
 
 ---
 
@@ -411,30 +401,6 @@ Constraints from CLAUDE.md Key Design Decisions (KDD) and Component-*.md (CD) th
 
 ---
 
-### WP-8: Data Connection Layer — LmxProxy Adapter
-
-**Description**: Implement the LmxProxy adapter wrapping the existing `LmxProxyClient` SDK behind IDataConnection.
-
-**Acceptance Criteria**:
-- Implements all IDataConnection methods mapped per docs/requirements/Component-DCL concrete type mappings.
-- Connect: calls `ConnectAsync`, stores SessionId.
-- Subscribe: calls `SubscribeAsync`, processes `IAsyncEnumerable<VtqMessage>` stream, forwards updates.
-- Write: calls `WriteAsync`.
-- Read: calls `ReadAsync`.
-- Configurable sampling interval (default 1000ms, 0 = on-change).
-- gRPC/HTTP/2 transport on configured port (default 5050).
-- API key authentication passed in ConnectRequest.
-- TLS support: TLS 1.2/1.3, mutual TLS, custom CA trust, self-signed for dev.
-- 30s keep-alive heartbeat via `GetConnectionStateAsync`. On failure, marks disconnected, disposes subscriptions.
-- SDK retry policy (Polly exponential backoff) retained for operation-level transient failures.
-- Batch operations exposed (ReadBatchAsync, WriteBatchAsync) for future use.
-
-**Estimated Complexity**: L
-
-**Requirements Traced**: `[2.4-1]`, `[2.4-2]`, `[CD-DCL-1]`, `[CD-DCL-2]`, `[CD-DCL-3]`, `[CD-DCL-4]`, `[CD-DCL-5]`, `[CD-DCL-6]`, `[CD-DCL-15]`
-
----
-
 ### WP-9: Data Connection Layer — Auto-Reconnect & Bad Quality Propagation
 
 **Description**: Implement auto-reconnection at fixed interval with immediate bad quality propagation on disconnect.
@@ -460,7 +426,6 @@ Constraints from CLAUDE.md Key Design Decisions (KDD) and Component-*.md (CD) th
 **Acceptance Criteria**:
 - After reconnection, all subscriptions that were active before disconnect are re-subscribed.
 - Instance Actors require no action — they see quality return to good as fresh values arrive.
-- LmxProxy adapter: new session established, new subscriptions created (old session/subscriptions were disposed on disconnect).
 - OPC UA adapter: new session established, monitored items re-created.
 - Test: disconnect OPC UA server, reconnect, verify values resume without Instance Actor intervention.
 
@@ -476,7 +441,7 @@ Constraints from CLAUDE.md Key Design Decisions (KDD) and Component-*.md (CD) th
 
 **Acceptance Criteria**:
 - Instance Actor sends write request to DCL when script calls SetAttribute for data-connected attribute.
-- DCL writes value via appropriate protocol (OPC UA Write / LmxProxy WriteAsync).
+- DCL writes value via the appropriate protocol (e.g., OPC UA Write).
 - Write failure (connection down, device rejection, timeout) returned synchronously to calling script.
 - Successful write: in-memory value NOT optimistically updated. Value updates only when device confirms via existing subscription.
 - Write failures also logged to Site Event Logging.
@@ -531,7 +496,7 @@ Constraints from CLAUDE.md Key Design Decisions (KDD) and Component-*.md (CD) th
 - Tag value updates delivered directly to requesting Instance Actor.
 - When Instance Actor stopped (disable, delete, redeployment): DCL cleans up associated subscriptions.
 - On redeployment: subscriptions established fresh based on new configuration.
-- Protocol-agnostic — works for both OPC UA and LmxProxy.
+- Protocol-agnostic — works for OPC UA and any future protocol adapter.
 
 **Estimated Complexity**: M
 
@@ -896,7 +861,7 @@ Constraints from CLAUDE.md Key Design Decisions (KDD) and Component-*.md (CD) th
 
 **Acceptance Criteria**:
 - IDataConnection interface defined in Commons (Phase 0 — REQ-COM-2).
-- OPC UA adapter and LmxProxy adapter both implement IDataConnection.
+- The OPC UA adapter implements IDataConnection.
 - Connection actor instantiates the correct adapter based on data connection protocol type from configuration.
 - Adding a new protocol requires only implementing IDataConnection and registering the adapter — no changes to connection actor or Instance Actor.
 
@@ -933,7 +898,6 @@ Constraints from CLAUDE.md Key Design Decisions (KDD) and Component-*.md (CD) th
 |------|---------------|
 | Connection Actor | State machine transitions (Connecting -> Connected -> Reconnecting), stash/unstash behavior, bad quality propagation on disconnect |
 | OPC UA Adapter | IDataConnection contract compliance, subscribe/unsubscribe, write |
-| LmxProxy Adapter | IDataConnection contract compliance, SessionId management, keep-alive, subscription stream processing |
 | Script Actor | Trigger evaluation (interval, value change, conditional), minimum time between runs, concurrent execution |
 | Alarm Actor | Condition evaluation (Value Match, Range Violation, Rate of Change), state transitions (normal->active, active->normal), no script on clear |
 | Script Runtime API | GetAttribute, SetAttribute (data-connected + static), CallScript, CallShared |
@@ -1003,7 +967,6 @@ Phase 3B is complete when ALL of the following pass:
 | # | Question | Context | Impact | Status |
 |---|----------|---------|--------|--------|
 | Q-P3B-1 | What is the exact dedicated blocking I/O dispatcher configuration for Script Execution Actors? | KDD-runtime-3 says "dedicated blocking I/O dispatcher" — need Akka.NET HOCON config (thread pool size, throughput settings). | WP-15. Sensible defaults can be set; tuned in Phase 8. | Deferred — use Akka.NET default blocking-io-dispatcher config; tune during Phase 8 performance testing. |
-| Q-P3B-2 | Should LmxProxy adapter expose WriteBatchAndWaitAsync (write-and-poll handshake) through IDataConnection or as a protocol-specific extension? | CD-DCL-5 lists WriteBatchAndWaitAsync but IDataConnection only defines simple Write. | WP-8. Does not block core functionality. | Deferred — expose as protocol-specific extension method; not part of IDataConnection core contract. |
 | Q-P3B-3 | What is the Rate of Change alarm evaluation time window? | Section 3.4 says "changes faster than a defined threshold" but does not specify the time window (per-second? per-minute? configurable?). | WP-16. Needs a design decision for the evaluation algorithm. | Deferred — implement as configurable window (default: per-second rate). Document in alarm definition schema. |
 | Q-P3B-4 | How does the health report sequence number behave across failover? | Sequence number is monotonic within a singleton lifecycle. After failover, the new singleton starts at 1. Central must handle this. | WP-27, WP-28. Central should accept any report from a site marked offline regardless of sequence number. | Resolved in design — central accepts report when site is offline; for online sites, requires seq > last. On failover, site goes offline first (missed reports), so the reset is naturally handled. |
 
@@ -1123,7 +1086,6 @@ Codex received work package titles (not full acceptance criteria due to prompt s
 | 9 | UTC timestamps not covered | **False positive** — UTC is a Phase 0 convention (KDD-data-6). Message contracts in WP-1 specify "All timestamps in message contracts are UTC." Health report in WP-27 specifies "UTC from site clock." |
 | 10 | Event log schema and active-node behavior uncovered | **False positive** — WP-29 acceptance criteria list full schema and "Only active node generates and stores events. Event logs not replicated to standby." |
 | 11 | Remote query filters/pagination details uncovered | **False positive** — WP-31 acceptance criteria list all filter types, "default 500 events," and "continuation token." |
-| 12 | LmxProxy details uncovered in WP-8 | **False positive** — WP-8 acceptance criteria explicitly cover port, API key, SessionId, keep-alive, TLS, batch ops, Polly retry. |
 
 ### Step 2 — Negative Requirement Review
 

docs/plans/phase-4-operator-ui.md

@@ -196,7 +196,7 @@
 - Admin can assign/unassign data connections to/from sites.
 - Admin can edit data connection details.
 - Admin can delete a data connection (blocked if bound to any instance attribute).
-- Protocol type selection (OPC UA, LmxProxy).
+- Protocol type selection (OPC UA).
 - Connection details form varies by protocol type.
 - Non-Admin users cannot access data connection management.
 - Data connection changes are audit logged.

docs/plans/questions.md

@@ -27,7 +27,6 @@
 | Q7 | JWT signing key storage? | `appsettings.json` (per environment). | 2026-03-16 |
 | Q8 | OPC UA server for dev/test? | Azure IoT OPC PLC simulator in Docker. See `infra/opcua/nodes.json` and `docs/test_infra/test_infra_opcua.md`. | 2026-03-16 |
 | Q10 | Target site hardware? | Windows Server 2022, 24 GB RAM, 1 TB drive, 16-core Xeon. | 2026-03-16 |
-| Q9 | What is the custom protocol? Is there an existing specification or SDK? | LmxProxy — gRPC-based protocol (protobuf-net code-first, port 5050, API key auth). Client SDK: `LmxProxyClient` NuGet package. See docs/requirements/Component-DataConnectionLayer.md for full API mapping and protocol details. | 2026-03-16 |
 | Q11 | Are there specific external systems (MES, recipe manager) to integrate with for initial testing? | REST API test server (`infra/restapi/`) provides simulated external endpoints for External System Gateway and Inbound API testing. No real MES/recipe system needed for initial phases. | 2026-03-16 |
 | Q15 | Should the Machine Data Database schema be designed in this project, or is it out of scope? | Out of scope — Machine Data Database is a pre-existing database at customer sites. Test infra seeds sample tables/data in `infra/mssql/machinedata_seed.sql`. | 2026-03-16 |
 | Q13 | Who is the development team? | Solo developer with extensive Akka.NET experience and full availability. No parallelization constraints — phases are sequential. | 2026-03-16 |
@@ -45,7 +44,6 @@
 | Q-P3A-2 | Single SQLite file or separate files per concern? | Single file with separate tables. Simpler transaction management. | 2026-03-16 |
 | Q-P3A-3 | Akka.Persistence or direct SQLite for Deployment Manager singleton? | Direct SQLite. Recovery is full read-all-configs-and-rebuild, not event replay. | 2026-03-16 |
 | Q-P3B-1 | Blocking I/O dispatcher config for Script Execution Actors? | Use Akka.NET default blocking-io-dispatcher config. Tune during Phase 8 performance testing. | 2026-03-16 |
-| Q-P3B-2 | Should WriteBatchAndWaitAsync be on IDataConnection or protocol-specific? | Add to `IDataConnection` — both OPC UA and LmxProxy can implement it. | 2026-03-16 |
 | Q-P3B-3 | Rate of Change alarm evaluation time window? | Configurable window, default per-second rate. Document in alarm definition schema. | 2026-03-16 |
 | Q-P3B-4 | Health report sequence number across failover? | Resolved in design — offline detection handles the reset naturally. Central accepts lower seq after site goes offline/online. | 2026-03-16 |
 | Q-P3C-1 | S&F retry timers on failover — reset or continue? | Continue from `last_attempt_at` to avoid burst retries. | 2026-03-16 |

docs/plans/requirements-traceability.md

@@ -216,17 +216,6 @@ Design decisions from CLAUDE.md Key Design Decisions and docs/requirements/Compo
 | KDD-code-8 | EF Core migrations: auto-apply in dev, manual SQL scripts for production | CLAUDE.md | 1 | Pending |
 | KDD-code-9 | Script trust model: forbidden APIs (System.IO, Process, Threading, Reflection, raw network) | CLAUDE.md | 3B | Plan generated |
 
-### LmxProxy Protocol (Component Design)
-
-| ID | Constraint | Source | Phase(s) | Status |
-|----|-----------|--------|----------|--------|
-| CD-DCL-1 | LmxProxy: gRPC/HTTP/2 transport, protobuf-net code-first, port 5050 | Component-DCL | 3B | Plan generated |
-| CD-DCL-2 | LmxProxy: API key auth, session-based (SessionId), 30s keep-alive heartbeat | Component-DCL | 3B | Plan generated |
-| CD-DCL-3 | LmxProxy: Server-streaming gRPC for subscriptions, 1000ms default sampling | Component-DCL | 3B | Plan generated |
-| CD-DCL-4 | LmxProxy: SDK retry policy (exponential backoff) complements DCL.s fixed-interval reconnect | Component-DCL | 3B | Plan generated |
-| CD-DCL-5 | LmxProxy: Batch read/write capabilities (ReadBatchAsync, WriteBatchAsync) | Component-DCL | 3B | Plan generated |
-| CD-DCL-6 | LmxProxy: TLS 1.2/1.3, mutual TLS, self-signed for dev | Component-DCL | 3B | Plan generated |
-
 ---
 
 ## Split-Section Tracking