docs: close ndk endpoint audit inventory

AI.md

@@ -1257,4 +1257,26 @@ Next patch number should be `0253`.
   file and logical records still ignore the documented `LockFlag` byte until
   direct requester traces justify changing behavior.
 
-Next patch number should be `0260`.
+## 2026-06-02 - Patch 0260 final NDK/WebSDK/include endpoint-audit closure
+
+- Re-ran the endpoint-audit inventory NDK-first against the local Core Protocols
+  PDF text, uploaded WebSDK HTML, and uploaded SDK includes after patches
+  `0255` through `0259`.
+- No additional in-scope NetWare 1.x/2.x/3.x endpoint family or planned
+  NetWare-4.x endpoint family was found that still needs a new source-dispatch
+  stub in this documentation pass.
+- Current coverage state is considered documentation-complete for this audit:
+  each in-scope family is either actively handled, forwarded to the file that
+  parses it, represented by a disabled source stub with request/reply notes, or
+  explicitly documented as out of scope because it is NetWare 5.x/OES/MOAB/newer
+  or requires a future provider.
+- This does not mean all endpoints are behaviorally complete.  It only closes
+  the NDK/WebSDK/include source-stub inventory.  Remaining work should be driven
+  by tests, requester traces, and provider implementation tasks, not by adding
+  more placeholder endpoint stubs.
+- Keep using the corrected documentation rule from patches `0256` and `0259`:
+  do not split active fall-through control flow merely for documentation;
+  instead keep shared parser/handler branches shared and place the appropriate
+  `Request:`/`Response:` notes next to the relevant case labels.
+
+Next patch number should be `0261`.

TODO.md

@@ -156,21 +156,24 @@ NetWare 4.x planning/stub bucket:
   `#if MARS_NWE_4` while the macro remains `0`.  Do not add source stubs
   merely for NetWare 5.x/OES/MOAB/newer endpoints during the current audit.
 
-#### SDK-listed 0x2222 blocks not yet endpoint-audited
+#### SDK-listed 0x2222 endpoint-audit closure
 
 Current status:
 
-- The local NDK/Core-Protocols PDF and uploaded WebSDK/includes list several
-  `0x2222` endpoint families that are not yet covered by the detailed
-  per-endpoint audit above.  This section is an index only; do not treat an
-  entry here as implemented, missing, or in-scope until the block is compared
-  against the real dispatcher and bucketed by the oldest documented NetWare
-  generation.
-- Use SDK/PDF decimal numbers plus wire hex when drilling into a block.  For
-  example, SDK group `0x2222/23` is the top-level wire `case 0x17`; SDK group
-  `0x2222/89` would be top-level wire `case 0x59`.
+- Patch `0260` rechecked the local NDK/Core-Protocols PDF, uploaded WebSDK
+  HTML, and uploaded SDK includes after the documentation/source-stub series.
+- No remaining NetWare 1.x/2.x/3.x endpoint family or planned NetWare-4.x
+  endpoint family is known to need another placeholder source-dispatch stub in
+  this audit pass.
+- The list below is now a coverage index, not a queue of unaudited endpoint
+  families.  A listed family can still have behavioral TODOs, provider TODOs,
+  field-mapping TODOs, or tests to write, but its endpoint/stub inventory has
+  been compared against the available NDK/WebSDK/include sources.
+- Continue to use SDK/PDF decimal numbers plus wire hex when drilling into any
+  follow-up.  For example, SDK group `0x2222/23` is the top-level wire
+  `case 0x17`; SDK group `0x2222/123` is top-level wire `case 0x7b`.
 
-Present in the code but not yet fully endpoint-audited:
+Endpoint coverage index:
 
 - SDK `0x2222/23` / wire `0x17` File Server Environment: the audit has covered
   file-information, login/connection, bindery-object, bindery property,
@@ -1011,6 +1014,29 @@ Follow-up:
   authentication, request string parsing, `RPCccode` mapping, and failure paths.
 
 
+### Final NDK/WebSDK/include endpoint inventory closure
+
+Current status:
+
+- Patch `0260` closes the broad NDK/WebSDK/include source-stub inventory for
+  the current 1.x/2.x/3.x plus planned-4.x compatibility audit.
+- No additional in-scope endpoint family is currently known to require a new
+  placeholder `switch`/dispatcher stub.
+- Remaining work is intentionally behavioral and provider-oriented: add tests,
+  compare real DOS/Windows requester traces, finish missing backend state, and
+  correct field mappings where earlier audit notes recorded mismatches.
+- Do not add new placeholder stubs merely because an endpoint exists in the
+  SDK.  First verify that it is NetWare 1.x/2.x/3.x or planned 4.x, that it is
+  not already active/forwarded/documented, and that it is not 5.x/OES/MOAB or
+  newer.
+
+Follow-up:
+
+- Use the existing endpoint-family sections below for implementation work.
+- Use future patches for test/protocol behavior or real provider integration,
+  not for another generic endpoint inventory sweep unless new source material
+  or traces reveal a concrete gap.
+
 ### Extended volume information field mapping
 
 Current status:
@@ -1384,9 +1410,8 @@ Current status:
 Follow-up:
 
 - Keep the `MARS_NWE_4` stubs disabled until a real `nwnds`/fragment-state
-  design exists.  The next endpoint audit can continue with deeper `23`
-  bindery/property/admin coverage, `36`/`37` NCP Extension scope, print/spool
-  `17`, or another user-selected family.
+  design exists.  Further NDS work should be provider/test driven rather than
+  another generic endpoint-placeholder pass.
 
 
 ### Retrospective source-stub coverage for already audited blocks