docs: audit SecretStore endpoint scope

AI.md

@@ -626,3 +626,19 @@ Latest endpoint audit checkpoint from patch 0224:
   unless the filesystem provider grows real backing state.
 
 Next patch number should be `0225`.
+
+Latest endpoint audit checkpoint from patch 0225:
+
+- SDK `0x2222/92` / wire `0x5c` SecretStore is now scope-audited as
+  later-generation and out of the current source-stub target.  The NDK PDF marks
+  SecretStore Services as NetWare Server 5.x and eDirectory 8.5 or later, with
+  subverbs `0` Query Server through `9` Get Service Information.
+- No active top-level `case 0x5c` exists in `src/nwconn.c`, and no indirect
+  handler/provider path was found during this audit.  Do not add a disabled
+  source stub for SecretStore while the target remains 1.x/2.x/3.x plus planned
+  4.x only.
+- SecretStore is not the same as the planned 4.x `libdirectory`/`nwnds` work.
+  If a future post-4.x/eDirectory target is ever added, it should be designed as
+  a separate secure secret-storage provider with strict no-secret logging rules.
+
+Next patch number should be `0226`.

TODO.md

@@ -243,14 +243,21 @@ Present in the code but not yet fully endpoint-audited:
 SDK-listed blocks that do not currently show a top-level handler in
 `src/nwconn.c`:
 
-- SDK `0x2222/92` / wire `0x5c` SecretStore, SDK `0x2222/123` / wire
-  `0x7b` service-address enumeration, and SDK `0x2222/131` / wire `0x83`
-  RPC/NLM-control style calls appear in the PDF/WebSDK index but do not
-  currently show top-level handlers in `src/nwconn.c`.  These are likely
-  later-generation buckets, but each must be confirmed against the
-  includes/WebSDK before adding guarded stubs.  Only endpoints bucketed as
-  1.x/2.x/3.x compatibility or planned 4.x work should receive disabled source
-  stubs.
+- SDK `0x2222/92` / wire `0x5c` SecretStore is scope-audited as a
+  later-generation SecretStore/eDirectory single-sign-on family.  The local NDK
+  PDF marks the family as NetWare Server 5.x and eDirectory 8.5 or later, with
+  subverbs `0` Query Server through `9` Get Service Information.  There is no
+  active top-level handler in `src/nwconn.c`, no indirect provider path was
+  found in the audited source, and no source stub should be added under the
+  current 1.x/2.x/3.x plus planned-4.x rule.  It remains prose-only/out of the
+  current compatibility target.
+- SDK `0x2222/123` / wire `0x7b` service-address enumeration and SDK
+  `0x2222/131` / wire `0x83` RPC/NLM-control style calls appear in the
+  PDF/WebSDK index but do not currently show top-level handlers in
+  `src/nwconn.c`.  These are likely later-generation buckets, but each must be
+  confirmed against the includes/WebSDK before adding guarded stubs.  Only
+  endpoints bucketed as 1.x/2.x/3.x compatibility or planned 4.x work should
+  receive disabled source stubs.
 
 Follow-up: