4303f06fc3
Design doc covers architecture, v2 protocol (TypedValue/QualityCode), COM threading model, session lifecycle, subscription semantics, error model, and guardrails. Implementation plans are detailed enough for autonomous Claude Code execution. Verified all dev tooling on windev (Grpc.Tools, protobuf-net.Grpc, Polly v8, xUnit).
99 lines
5.2 KiB
Markdown
99 lines
5.2 KiB
Markdown
# LmxProxy v2 Rebuild — Execution Prompt
|
|
|
|
Run this prompt with Claude Code from the `lmxproxy/` directory to execute all 7 phases of the rebuild autonomously.
|
|
|
|
## Prompt
|
|
|
|
You are executing a pre-approved implementation plan for rebuilding the LmxProxy gRPC proxy service. All design decisions have been made and documented. You do NOT need to ask for approval — execute each phase completely, then move to the next.
|
|
|
|
### Context
|
|
|
|
Read these documents in order before starting:
|
|
|
|
1. `docs/plans/2026-03-21-lmxproxy-v2-rebuild-design.md` — the approved design
|
|
2. `CLAUDE.md` — project-level instructions
|
|
3. `docs/requirements/HighLevelReqs.md` — high-level requirements
|
|
4. `docs/requirements/Component-*.md` — all component requirements (10 files)
|
|
5. `docs/lmxproxy_updates.md` — authoritative v2 protocol specification
|
|
|
|
### Execution Order
|
|
|
|
Execute phases in this exact order. Each phase has a detailed plan in `docs/plans/`:
|
|
|
|
1. **Phase 1**: `docs/plans/phase-1-protocol-domain-types.md`
|
|
2. **Phase 2**: `docs/plans/phase-2-host-core.md`
|
|
3. **Phase 3**: `docs/plans/phase-3-host-grpc-security-config.md`
|
|
4. **Phase 4**: `docs/plans/phase-4-host-health-metrics.md`
|
|
5. **Phase 5**: `docs/plans/phase-5-client-core.md`
|
|
6. **Phase 6**: `docs/plans/phase-6-client-extras.md`
|
|
7. **Phase 7**: `docs/plans/phase-7-integration-deployment.md`
|
|
|
|
### How to Execute Each Phase
|
|
|
|
For each phase:
|
|
|
|
1. Read the phase plan document completely before writing any code.
|
|
2. Read any referenced requirements documents for that phase.
|
|
3. Execute each step in the plan in order.
|
|
4. After all steps, run `dotnet build` and `dotnet test` to verify.
|
|
5. If build or tests fail, fix the issues before proceeding.
|
|
6. Commit the phase with message: `feat(lmxproxy): phase N — <description>`
|
|
7. Push to remote: `git push`
|
|
8. Move to the next phase.
|
|
|
|
### Guardrails (MUST follow)
|
|
|
|
1. **Proto is the source of truth** — any wire format question is resolved by reading `src/ZB.MOM.WW.LmxProxy.Host/Grpc/Protos/scada.proto`, not the code-first contracts.
|
|
2. **No v1 code in the new build** — the `src-reference/` directory is for reading only. Do not copy-paste and modify; write fresh code guided by the plan.
|
|
3. **Cross-stack tests in Phase 1** — Host proto serialize to Client code-first deserialize (and vice versa) must pass before any business logic.
|
|
4. **COM calls only on STA dispatch thread** — no `Task.Run` for COM operations. All go through the `StaDispatchThread` dispatch queue.
|
|
5. **status_code is canonical for quality** — `symbolic_name` is always derived from lookup, never independently set.
|
|
6. **Unit tests before integration** — every phase includes unit tests. Integration tests are Phase 7 only.
|
|
7. **Each phase must compile and pass tests** before the next phase begins. Do not skip failing tests.
|
|
8. **No string serialization heuristics** — v2 uses native TypedValue. No `double.TryParse` or `bool.TryParse` on values.
|
|
9. **Do not modify requirements or design docs** — if you find a conflict, follow the design doc's resolution (section 11).
|
|
10. **Do not ask for user approval** — all decisions are pre-approved in the design document.
|
|
|
|
### Error Recovery
|
|
|
|
- If a build fails, read the error messages carefully, fix the code, and rebuild.
|
|
- If a test fails, fix the implementation (not the test) unless the test has a clear bug.
|
|
- If a step in the plan is ambiguous, consult the requirements document for that component.
|
|
- If the requirements are ambiguous, consult the design document's resolution table (section 11).
|
|
- If you cannot resolve an issue after 3 attempts, skip that step, leave a `// TODO: <description>` comment, and continue.
|
|
|
|
### Phase 7 Special Instructions
|
|
|
|
Phase 7 requires SSH access to windev (10.100.0.48). See `windev.md` in the repo root for connection details:
|
|
- SSH: `ssh windev` (passwordless)
|
|
- Default shell: cmd.exe, use `powershell -Command` for PowerShell
|
|
- Git and .NET SDK 10 are installed
|
|
- The existing v1 LmxProxy service is at `C:\publish\` on port 50051
|
|
|
|
For Veeam backups, SSH to the Veeam server:
|
|
- SSH: `ssh dohertj2@10.100.0.30` (passwordless)
|
|
- Use `Add-PSSnapin VeeamPSSnapin` for Veeam PowerShell
|
|
|
|
### Commit Messages
|
|
|
|
Use this format for each phase commit:
|
|
|
|
- Phase 1: `feat(lmxproxy): phase 1 — v2 protocol types and domain model`
|
|
- Phase 2: `feat(lmxproxy): phase 2 — host core (MxAccessClient, SessionManager, SubscriptionManager)`
|
|
- Phase 3: `feat(lmxproxy): phase 3 — host gRPC server, security, configuration, service hosting`
|
|
- Phase 4: `feat(lmxproxy): phase 4 — host health monitoring, metrics, status web server`
|
|
- Phase 5: `feat(lmxproxy): phase 5 — client core (ILmxProxyClient, connection, read/write/subscribe)`
|
|
- Phase 6: `feat(lmxproxy): phase 6 — client extras (builder, factory, DI, streaming extensions)`
|
|
- Phase 7: `feat(lmxproxy): phase 7 — integration tests, deployment to windev, v1 cutover`
|
|
|
|
### After All Phases
|
|
|
|
When all 7 phases are complete:
|
|
|
|
1. Run `dotnet build ZB.MOM.WW.LmxProxy.slnx` to verify the full solution builds.
|
|
2. Run `dotnet test` to verify all unit tests pass.
|
|
3. Verify the integration tests passed in Phase 7.
|
|
4. Create a final commit if any cleanup was needed.
|
|
5. Push all changes.
|
|
6. Report: total files created, total tests, build status, integration test results.
|