docs(index): add BTDB (Batch Tracking Database) as a sister project + analysis

Row in the sister-project table, a BTDB-edges subsection (Galaxy write contract, ScadaBridge inbound-API SAPID lookup on db-connection BTDB, Historian CLR/INSQL co-location), break-surface note, Windows-only build commands, and the DARS bullet now points at the unversioned WW_ARCH/BatchTracker_DB fork. Full schema/contract notes and the 2026-09-03 gap analysis live in .claude/skills/sister-project-history/btdb.md.

Claude-Session: https://claude.ai/code/session_01Wzg6NUCWHipSexLs2cgRFv

CLAUDE.md

@@ -40,10 +40,11 @@ own `CLAUDE.md` for the full picture. See [Refreshing this index](#refreshing-th
 | **MxAccessGateway** (`mxaccessgw`) | `~/Desktop/MxAccessGateway` | .NET 10 gateway (x64) + .NET 4.8 worker (**x86**), gRPC | `gitea.dohertylan.com/dohertj2/mxaccessgw` | gRPC gateway giving modern clients full MXAccess parity without loading 32-bit COM. Two-process: gateway (ASP.NET Core gRPC + Blazor dashboard) + per-session x86 worker that owns the MXAccess COM STA. **OtOpcUa depends on this.** |
 | **ScadaBridge** | `~/Desktop/ScadaBridge` | .NET 10, Akka.NET, Docker | `gitea.dohertylan.com/dohertj2/ScadaBridge` | Full implementation of the distributed SCADA platform — hub-and-spoke (1 central cluster + N site clusters). Projects prefixed `ZB.MOM.WW.ScadaBridge.*`; solution `ZB.MOM.WW.ScadaBridge.slnx`. Ships `src/`, `tests/`, `docker/` topology, and the design docs that are the spec. **Inbound API keys live on the shared SQL Server store on a central pair** (design 2026-09-02, ScadaBridge register row 108): ScadaBridge is Auth's first consumer of the new `ZB.MOM.WW.Auth.ApiKeys.SqlServer` package at `0.3.0`, pointing both central nodes at one `zbauth` schema in the configuration database instead of each node's own per-node SQLite file. |
 | **HistorianGateway** | `~/Desktop/HistorianGateway` | .NET 10 x64, gRPC, Blazor | `gitea.dohertylan.com/dohertj2/historiangw` | Single-process gRPC sidecar exposing (1) a full read/write API to the AVEVA Historian (5 gRPC services; 15 retrieval modes; historical/backfill writes; tag-config lifecycle; SQL live-value path; store-forward + redundancy resilience; all default-disabled) and (2) read-only Galaxy object-hierarchy browse via the shared `ZB.MOM.WW.GalaxyRepository` lib. No COM, no x86 worker. **Owns `AVEVA.Historian.Client`** at `histsdk/` (ordinary owned source, edited in place — the re-vendor model is retired). Dev: dashboard `:5220` (HTTP/1.1) + gRPC h2c `:5221`; production: one `Kestrel:Endpoints:Https` with `Protocols: Http1AndHttp2` (ALPN). Default-on leased session pools amortize the historian handshake (v6 pool + a separate v8 event-session pool). Client lib `ZB.MOM.WW.HistorianGateway.Client` + Contracts are on the Gitea feed at `0.3.0`; **OtOpcUa is the first consumer** (its sole historian backend since PR #423); ScadaBridge has no coupling. Known 2023 R2 server-side gates: native event reads return 0 rows (C2, won't-fix — SQL-path `ReadEvents` via `Runtime.dbo.Events` is the shipped workaround), `Int1`/`UInt1` analog-tag creation is degenerate (OtOpcUa maps Boolean → `Int2`), string historical writes non-convergent (follow-ups #18–#25). Only remaining archreview item: the secure-by-default TLS flip, deferred to 1.0.0. **Full change history (ArchReview cycles 1–2, pending.md items, PR list): `.claude/skills/sister-project-history/historiangateway.md`.** |
+| **BTDB** (Batch Tracker) | `~/Desktop/btdb` (**not a git checkout** — snapshot of `master` @ `d147c10e`, 2023-07-26) | SQL Server SSDT project + SQL CLR (net472); ASP.NET Core MVC **net6.0** manager (Windows service, `:9876`) | **`ZimmerBiomet/BTDB`** on the corporate Gitea `wonder-app-vd03:3000` (not on `gitea.dohertylan.com`) | The `BT` SQL Server database that is the plant's **batch / cycle / work-order system of record for data collection**. Galaxy machine objects write to it through `StartMachineBatch` / `StartMachineCycle` / `End*` / `AddMachineBatchWorkOrder` / `AddOtherData*` (auto-closes the prior batch/cycle unless `MultipleBatch`/`MultipleCycle`; all `GETUTCDATE()`); reports pull per-batch time-series **out of the AVEVA Historian through CLR sprocs** (`OPENQUERY(INSQL, … WideHistory …)` + `Runtime.dbo.*`), so **BT must be co-tenant with the Historian's `Runtime` DB** (`wonder-sql-*`, not the app-tier SQL). MESAPI and **ScadaBridge's inbound API** (`IpsenMESMoveIn`, MES alarm-status; db-connection `BTDB`) resolve `SAPID → Machine.Code` from `dbo.Machine`; ScadaBridge site scripts *can* write via `Database.Connection`, but no checked-in ScadaBridge script calls a BT sproc and the rig seeds no `BT`. `BTDBManager` = LDAP-gated machine/group config, audited batch edits, cross-environment config import. **`~/Desktop/DARS/WW_ARCH/BatchTracker_DB/` is an unversioned fork of the `Database` project** (2026-08-13: `MachineBatchTransfer`, `ContainerID`/`MoveOutTimestamp` on `MachineBatchWO`, `GetLinkedBatchTSV`) — the DARS sprint-1 target schema, not yet pushed anywhere. Checked-in plaintext SQL + service-account credentials (do not reproduce). **Full schema/contract notes, family edges and the 2026-09-03 gap analysis: `.claude/skills/sister-project-history/btdb.md`.** |
 
 ## Cross-project relationships
 
-The three indexed projects are **separate repos and separate processes**, coupled at
+The indexed sister projects are **separate repos and separate processes**, coupled at
 **runtime over wire protocols (gRPC + OPC UA)** — not by project/compile references. They
 share the `ZB.MOM.WW.*` product namespace (`ZB.MOM.WW.OtOpcUa.*`, `ZB.MOM.WW.ScadaBridge.*`;
 the gateway uses `MxGateway.*`). The common subject is **AVEVA System Platform (Wonderware)
@@ -104,6 +105,20 @@ the gateway uses `MxGateway.*`). The common subject is **AVEVA System Platform (
   Both adapters implement the same `IAlarmSubscribableConnection` seam, and a read-only
   `NativeAlarmActor` unifies OPC-UA-A&C and MxAccess alarms onto one condition model.
 
+### BTDB edges (batch tracker)
+
+BTDB is a **database**, not a service, so it couples by SQL, not gRPC/OPC UA:
+
+- **Galaxy → BT (write):** per-machine Galaxy scripts `EXEC` the lifecycle sprocs; the sproc signatures and
+  `Machine.Code`/`SAPID`/`ZTag` semantics are the contract.
+- **ScadaBridge → BT (read, verified):** inbound-API method scripts use the `Database` helper on the named
+  db-connection `BTDB` (prod id 1) for `SELECT Code FROM dbo.Machine WHERE SAPID=@s` before `Route.To(instance)`.
+  Site scripts can also write via `Database.Connection`/`CachedWrite`, but that is customer script config, not
+  platform code. ScadaBridge's inbound API is the designated successor of MESAPI's move-in/move-out surface.
+- **BT → Historian (read):** CLR sprocs resolve hierarchical tag names via `Runtime.dbo.TagExtendedPropertyInfo`
+  and query `WideHistory` through the `INSQL` linked server; alarm wrappers read `Runtime.dbo.Events` (the same
+  view HistorianGateway's SQL-path `ReadEvents` uses). No coupling to OtOpcUa or mxaccessgw.
+
 ### Net effect
 
 - `mxaccessgw` is a shared dependency of **both** OtOpcUa and ScadaBridge.
@@ -131,6 +146,9 @@ the gateway uses `MxGateway.*`). The common subject is **AVEVA System Platform (
   shape OtOpcUa publishes (browse paths, node IDs, A&C alarm model). Changes to any of these
   must be coordinated across the affected repos — a green build in one repo does not prove the
   others still interoperate.
+- **BTDB's break surface is its SQL contract:** the lifecycle sproc signatures, the `Machine` key columns
+  (`Code`/`SAPID`/`ZTag`), the `OtherData` JSON key conventions (DARS sprint 1 adds ~14), and the
+  `INSQL`/`Runtime` co-location assumption. Galaxy scripts, MESAPI and ScadaBridge inbound methods all bind to them.
 
 ## Component normalization
 
@@ -206,6 +224,11 @@ dotnet test ZB.MOM.WW.HistorianGateway.slnx --filter "Category=LiveIntegration"
 # runtime-only aspnet:10.0 image; login + gRPC API-key auth disabled; points at the REAL wonder datasources.
 dotnet publish src/ZB.MOM.WW.HistorianGateway.Server/ZB.MOM.WW.HistorianGateway.Server.csproj -c Release -o docker/publish -p:UseAppHost=false
 cd docker && docker compose up -d --build   # dashboard/health/metrics :5220, gRPC h2c :5221 (needs host VPN for egress)
+
+# BTDB  (~/Desktop/btdb) — Windows only: SSDT + SQL CLR + Telerik + System.DirectoryServices; nothing builds on macOS
+dotnet build Manager\BTDBManager.csproj                        # net6.0 MVC; needs Telerik Reporting R2 2022 at the HintPath
+msbuild Database\Database.sqlproj /p:Configuration=Release    # SSDT → bin\Release\Database.dacpac; publish with SqlPackage
+# Target instance must have CLR enabled, the `INSQL` linked server, and the Historian `Runtime` DB reachable by 3-part name
 ```
 
 > **Shared GLAuth (all three apps + HistorianGateway):** LDAP auth for every local dev/test stack is provided by a
@@ -259,7 +282,8 @@ Listed so they can be pulled into the index above if you decide they belong.
 - **OpcUaTestServer** — dual-instance OPC UA test server (.NET 10) for testing OPC UA clients / simulating automation.
 - **scada** (ScadaLink) — design docs + scaffolding for the distributed SCADA platform (`ZB.MOM.ScadaLink.*`).
 - **scadalink-design-opcua-browser** — ScadaBridge variant focused on OPC UA browser / Data Connection Layer work.
-- **DARS** — DARS → Wonderware SCADA migration (design phase, Q2 2026 go-live).
+- **DARS** — DARS → Wonderware SCADA migration (design phase, Q2 2026 go-live). Holds the unversioned fork of
+  BTDB's `Database` project at `WW_ARCH/BatchTracker_DB/` (see the BTDB row above).
 - **DARS_BU** — backup snapshot of DARS.
 - **plan** — 3-year SCADA IT/OT modernization roadmap (markdown).