docs(secrets): gRPC hub implementation plan (9 tasks, subagent-executable) + cached-on-sites posture made explicit

Plan + tasks ledger for scadaproj#3 execution: package (proto/server/client/
tests/publish 0.4.0), ScadaBridge wiring + live gate, OtOpcUa pair-local
re-gate, closeout. GAPS + runbook now state the gRPC mode keeps the
cached-on-site-clusters last-known-good posture (owner-confirmed).

Claude-Session: https://claude.ai/code/session_014WNM4vjoVksyyBraTXSZE1
This commit is contained in:
Joseph Doherty
2026-08-07 05:36:32 -04:00
parent 591307c13e
commit ad7df925ae
4 changed files with 197 additions and 2 deletions
+4 -1
View File
@@ -176,7 +176,10 @@ project 38/38 green.
pair-local with one fleet-wide appsettings-delivered KEK; ScadaBridge = a new central gRPC hub
replicator (`ZB.MOM.WW.Secrets.Replicator.Grpc`, pull-only — updates originate at central only),
because the SqlServer hub's site-side connection string violates ScadaBridge's
sites-talk-to-central-not-the-DB rule. Enablement waits on the hub package (ScadaBridge) and the
sites-talk-to-central-not-the-DB rule. **The gRPC mode keeps the cached-on-site-clusters
posture:** each site node holds a full local store and serves last-known-good secrets when
central is unreachable, converging on the first successful sweep — same offline guarantee as
the SQL hub mode, without the site-side DB connection. Enablement waits on the hub package (ScadaBridge) and the
pair-local re-gate on the post-Phase-6 rig (OtOpcUa).
- ✅ ScadaBridge's hub topology **is** live-validated and technically safe to enable — but the
2026-08-07 decision rejects it for production on topology grounds (site nodes must not hold a