docs: record old direct sync layout audit results

AI.md

@@ -31,7 +31,7 @@ use, the current project status that the user pasted into the chat.
 
 - The current endpoint documentation/audit pass is scoped to NetWare 3.x-compatible NCPs.  Do not add NetWare 5.x / MOAB-only endpoints or TODOs unless the user explicitly asks for later-version coverage.
 - When a `0x2222` group is forwarded out of `nwconn.c`, document both layers: `nwconn.c` should explain the group handoff/header, and the destination file (for example `nwbind.c`) should document concrete subfunction request/reply layouts.
-- For documentation-only endpoint patches, do not change parser offsets, byte order, reply layout, or completion behavior.  If the code differs from the SDK layout, document the difference inline and mirror it in `TODO.md` for later testing.
+- For documentation-only endpoint patches, do not change parser offsets, byte order, reply layout, or completion behavior.  Always compare the code parser/reply layout against the NetWare 3.x SDK/WebSDK/PDF request format.  If the code differs from the SDK layout, document the concrete difference inline and mirror it in `TODO.md` for later testing.  If it matches, say so in the patch summary so the audit trail is clear.
 - Keep `TODO.md` endpoint audit notes grouped by logical endpoint family instead of as one long flat list.
 - The rejected `0152-docs-note-message-control-subfunction.patch` must not be applied: it documented `0x2222/21/0x0c Connection Message Control`, which is outside the NetWare 3.x MARS-NWE target scope.
 

TODO.md

@@ -129,7 +129,9 @@ Current status:
   not read.  This parser difference is documented inline but not changed yet.
 - `NCP 0x09 Log Logical Record (old)`, `NCP 0x0a Lock Logical Record Set
   (old)`, `NCP 0x0b Clear Logical Record`, and `NCP 0x0c Release Logical
-  Record` have inline SDK request-layout documentation.
+  Record` have inline SDK request-layout documentation.  The direct old
+  endpoints have been compared against the NDK/Core Protocols PDF request
+  offsets.
 - `NCP 0x0d Release Logical Record Set` and `NCP 0x0e Clear Logical Record
   Set` are implemented, but the SDK request contains a `LockFlag` byte that
   the current code does not read.  This parser difference is documented inline
@@ -140,8 +142,9 @@ Follow-up:
 - Decide whether `NCP 0x01` and `NCP 0x02` should be implemented for real
   old-client compatibility or should return a deliberate `0xfb` unsupported
   completion with normalized endpoint logging.
-- Verify `NCP 0x03 Log File (old)` against the Novell SDK request/reply layout
-  and a real DOS requester or direct test caller.
+- Verify `NCP 0x03 Log File (old)` against a real DOS requester or direct test
+  caller; the documented PDF/WebSDK request offsets already match the current
+  parser.
 - Decide whether the shared `0x04`/`0x6a` parser should keep the current
   big-endian timeout read for both functions or special-case old `0x04` as
   documented Lo-Hi after direct requester evidence is available.

src/nwconn.c

@@ -2755,7 +2755,11 @@ static int handle_ncp_serv(void)
        *
        *   SDK request: no additional request fields.
        *   SDK reply: no reply data.
-       *   SDK completion: 0x00 success, 0xff failure/lock error.
+       *   SDK completion: 0x00 success.
+       *
+       *   Compared against the SDK/PDF: the request has no payload after
+       *   FunctionCode.  MARS-NWE has no active case for this endpoint, so
+       *   this remains a TODO-only compatibility stub.
        *
        *   TODO: not implemented in MARS-NWE yet.
        *
@@ -2772,7 +2776,11 @@ static int handle_ncp_serv(void)
        *
        *   SDK request: no additional request fields.
        *   SDK reply: no reply data.
-       *   SDK completion: 0x00 success, 0xff failure.
+       *   SDK completion: 0x00 success.
+       *
+       *   Compared against the SDK/PDF: the request has no payload after
+       *   FunctionCode.  MARS-NWE has no active case for this endpoint, so
+       *   this remains a TODO-only compatibility stub.
        *
        *   TODO: not implemented in MARS-NWE yet.
        *
@@ -2804,9 +2812,13 @@ static int handle_ncp_serv(void)
          * A logged file may name a file that does not exist yet; locking it
          * reserves that name for the client.  The newer Log File variants
          * are 0x2222/105 and 0x2222/87/36, while 0x2222/04 and 0x2222/106
-         * lock the accumulated file set.  MARS-NWE records this old layout
-         * through nw_log_file(), which is the same table consumed by the
-         * file-set Lock/Release/Clear handlers below.
+         * lock the accumulated file set.
+         *
+         * Compared against the SDK/PDF: the current INPUT layout matches
+         * the documented old request offsets and reads LockTimeout in the
+         * documented Hi-Lo order.  MARS-NWE records this old layout through
+         * nw_log_file(), which is the same table consumed by the file-set
+         * Lock/Release/Clear handlers below.
          */
         struct INPUT {
           uint8   header[7];       /* Requestheader */
@@ -3030,6 +3042,10 @@ static int handle_ncp_serv(void)
          * They return no reply data and report success or Unlock Error
          * through the completion code.
          *
+         * Compared against the SDK/PDF: the current INPUT layout matches
+         * the documented old request offsets: FunctionCode at offset 6,
+         * SynchNameLen at offset 7, and SynchName at offset 8.
+         *
          * Important semantic difference: Release Logical Record leaves the
          * string in the caller's synchronization string table so a later
          * Lock Logical Record Set can relock it.  Clear Logical Record