refactor(comm): retire ClusterClient naming after the gRPC cutover

Phase 4 of the ClusterClient -> gRPC migration deleted the Akka transports but left the naming behind: `ClusterClientSiteAuditClient` was transport- agnostic and worked unchanged, so it survived the deletion under a name that now describes a transport the repo no longer has. Same for a scatter of doc-comments still framing gRPC as "the new transport" beside an Akka one that is gone. Renames it to `SiteCommunicationAuditClient` (and its test file) and rewrites the stale comments to describe the single transport that exists. Also tightens CLAUDE.md: drops the self-describing directory listing and the 27-component enumeration in favour of the non-obvious parts only. Behaviour-neutral: names and prose only. Recorded as the Phase 4 follow-up in docs/plans/2026-07-22-clusterclient-to-grpc-plan.md.
2026-07-27 15:40:01 -04:00
parent b3dc17a5fe
commit 63c16d6912
57 changed files with 193 additions and 244 deletions
@@ -10,9 +10,9 @@ public class Site
    public string SiteIdentifier { get; set; }
    /// <summary>Optional description of the site.</summary>
    public string? Description { get; set; }
-    /// <summary>Akka remote address for site node A (ClusterClient contact point).</summary>
+    /// <summary>Akka remote address for site node A.</summary>
    public string? NodeAAddress { get; set; }
-    /// <summary>Akka remote address for site node B (ClusterClient contact point).</summary>
+    /// <summary>Akka remote address for site node B.</summary>
    public string? NodeBAddress { get; set; }
    /// <summary>gRPC endpoint for site node A used by the central SiteStreamGrpcClient.</summary>
    public string? GrpcNodeAAddress { get; set; }
@@ -28,7 +28,7 @@ public enum SiteCallRelayOutcome
    NotParked,

    /// <summary>
-    /// The owning site could not be reached (offline / no ClusterClient route /
+    /// The owning site could not be reached (offline / no route to the site /
    /// relay timed out). The action was NOT applied; the operator may retry once
    /// the site is back online.
    /// </summary>
@@ -19,8 +19,8 @@ namespace ZB.MOM.WW.ScadaBridge.Commons.Messages.DebugView;
 /// </para>
 /// <para>
 /// A new dedicated message type (<c>DebugViewInstanceNotFound</c>) was
-/// considered but rejected: the ClusterClient / ClusterClientReceptionist
-/// channel is typed on the request side and the bridge actor is already
+/// considered but rejected: the site↔central channel is typed on the request
+/// side and the bridge actor is already
 /// pattern-matching on <c>DebugViewSnapshot</c> for the initial-snapshot TCS
 /// in <c>DebugStreamService</c>.  Introducing a second reply type would require
 /// every consumer to handle an additional <c>Ask</c> result union — more change
@@ -1,7 +1,7 @@
 namespace ZB.MOM.WW.ScadaBridge.Commons.Messages.Deployment;

 /// <summary>
-/// Site→central (over ClusterClient) on node startup: the node's local deployed inventory,
+/// Site→central on node startup: the node's local deployed inventory,
 /// so central can reply with fetch tokens for whatever the node is missing or stale
 /// (self-heal a node that was down during a deploy).
 /// </summary>
@@ -108,8 +108,8 @@ public record SiteHealthReport(

 /// <summary>
 /// Broadcast wrapper used between central nodes to keep per-node
-/// CentralHealthAggregator state in sync. ClusterClient load-balances each
-/// incoming SiteHealthReport to one central node; that node re-publishes
+/// CentralHealthAggregator state in sync. A site delivers each
+/// SiteHealthReport to ONE central node; that node re-publishes
 /// this wrapper on a DistributedPubSub topic so the peer node's aggregator
 /// also processes the report (idempotently — sequence numbers guard against
 /// double-counting).
@@ -9,7 +9,7 @@ namespace ZB.MOM.WW.ScadaBridge.Commons.Messages.Instance;
 /// <b>Site-local only.</b> The optional <see cref="Predicate"/> is a non-serializable
 /// in-process delegate, so this message MUST flow only within a single site node's
 /// actor system (script execution → Instance Actor). It is never sent across the
-/// ClusterClient / gRPC boundary. The value-equality form (<see cref="TargetValueEncoded"/>)
+/// site↔central gRPC boundary. The value-equality form (<see cref="TargetValueEncoded"/>)
 /// would serialize, but the routed/inbound variant is deliberately out of scope here.
 /// </para>
 /// </summary>
@@ -6,7 +6,7 @@ namespace ZB.MOM.WW.ScadaBridge.Commons.Messages.Management;
 /// Bidirectional name registry for management command records. The registry contains
 /// exactly the non-abstract <c>*Command</c> types declared in the
 /// <c>ZB.MOM.WW.ScadaBridge.Commons.Messages.Management</c> namespace; these are the commands that
-/// travel over the HTTP / ClusterClient management boundary.
+/// travel over the HTTP management boundary.
 /// </summary>
 /// <remarks>
 /// <see cref="Resolve"/> and <see cref="GetCommandName"/> are symmetric:
@@ -2,7 +2,7 @@ namespace ZB.MOM.WW.ScadaBridge.Commons.Messages.Management;

 // Schema-library authoring commands. The reusable named JSON-Schema
 // library (the SharedSchema entity + ISharedSchemaRepository) gains its CRUD
-// surface here. These records travel the same HTTP / ClusterClient management
+// surface here. These records travel the same HTTP management
 // boundary as every other *Command and are auto-discovered by reflection in
 // ManagementCommandRegistry (no manual registry entry needed).
 //
@@ -14,7 +14,7 @@ namespace ZB.MOM.WW.ScadaBridge.Commons.Messages.RemoteQuery;
 /// </para>
 /// <para>
 /// Either site node may receive this: <c>SiteCommunicationActor</c> is registered per node
-/// (not as a singleton), and ClusterClient contact rotation reaches whichever answers. That is
+/// (not as a singleton), and central's gRPC dial reaches whichever node answers. That is
 /// fine — <c>Cluster.Leave(address)</c> is valid from any member, and the target is resolved
 /// from cluster state rather than from who received the message.
 /// </para>