0475 docs: record nwadmin platform transport choices

AI.md

@@ -47,7 +47,7 @@ unfinished work out of `TODO.md` merely because its architecture is documented.
 
 Latest patch marker expected in an up-to-date bundle:
 
-- `0474 docs: name nwConsole and clarify web restart boundaries`
+- `0475 docs: record nwadmin platform transport choices`
 
 When a later chat receives a new `mars-nwe-master` bundle, compare `git log -1`
 with this marker.  If the uploaded bundle already contains this commit subject,
@@ -67,24 +67,21 @@ The active line is expected to include:
 
 Last generated patch:
 
-- `0474 docs: name nwConsole and clarify web restart boundaries`
+- `0475 docs: record nwadmin platform transport choices`
 
 Purpose of that patch:
 
-- Define user-facing names: `nwConsole` for the browser/web administration
-  surface and `nwAdmin` for the remote/desktop administrator client family.
-  The small web listener process may remain `nwwebui` internally.
-- Clarify lifecycle boundaries: a host-level systemd/init restart may restart
-  the whole MARS-NWE service family including `nwwebui`, but restarts requested
-  from nwConsole must keep the web listener alive unless the operator explicitly
-  restarts the web frontend itself.
-- Require embedded nwConsole static/status pages in `nwwebui` for backend
-  restart and reconnect states such as `Restarting nwadmin`, `Restarting
-  ncpserv`, `Restarting nwconn`, `Restarting nwbind`, backend unavailable and
-  reconnect pending.
-- Keep the split from the previous plan: `nwwebui` owns HTTP/HTTPS/TLS/session
-  and IPC frontend work, while `nwadmin` owns web/config plugins and backend
-  management dispatch.
+- Clarify the remote `nwAdmin` transport backend choices while keeping the
+  portable admin API as the only API visible to GUI, console and web/plugin
+  callers.
+- Keep Linux on the ncpfs-first investigation path for NetWare 3.x admin NCP
+  operations.
+- Treat Windows as Novell Client first where practical, because that client stack
+  is normally required there anyway; do not revive the old Pascal VLM/NWTP layer
+  as the new Windows runtime.
+- Treat the historical Novell NetWare Client for Macintosh as a Classic/PPC
+  compatibility/reference path only; modern macOS needs either an ncpfs
+  client-library port or a small project-owned NCP transport adapter.
 
 Directory/NDS work order before any FLAIM storage conversion:
 

REDESIGN.md

@@ -2571,8 +2571,12 @@ Terminal UI, toolbox and curses replacement plan:
   storage work are ready.
 - A future GUI may use Lazarus LCL/FreePascal or another cross-platform toolkit,
   but the GUI must stay above the portable admin client API.  On Linux the first
-  backend should investigate ncpfs; macOS may require an ncpfs port or a small
-  project-owned NCP client transport; Windows needs a later backend audit.
+  backend should investigate ncpfs.  On Windows, the practical first backend
+  should wrap the installed Novell Client because that client stack is normally
+  required there anyway; do not revive the old Pascal VLM/NWTP runtime layer for
+  new code.  For Classic/PPC macOS, the historical Novell NetWare Client for
+  Macintosh is only a compatibility/reference path; modern macOS needs either an
+  ncpfs client-library port or a small project-owned NCP transport.
 - Keep the first admin client simple.  Rich Pascal GUI/web stacks such as
   custom-drawn Lazarus libraries or browser-oriented Pascal frameworks can be
   evaluated later, but they must not become required dependencies for the common

TODO.md

@@ -113,7 +113,7 @@ may remain active.
 | `0x2222/22/51 Get Extended Volume Information` | partial / implemented compatibility | Keep active compatibility code; verify volume fields and ensure 3.x clients are not regressed. |
 | Other Directory Services 4.x high selectors | later / guarded | Document exact request/reply layout before enabling default runtime behaviour. |
 | Additional File Server Environment 4.x monitor/admin selectors | later / guarded | Implement only when a concrete admin tool or compatibility test requires it. |
-| Remote `nwadmin` 3.x client roadmap | 3.x | open | Audit `mars-nweadmin` workflows and define a portable NCP-based admin client API.  Linux should investigate ncpfs behind a transport adapter; macOS and Windows backends remain open until the 3.x NCP needs are known.  Do not link the admin GUI directly to local server libraries. |
+| Remote `nwadmin` 3.x client roadmap | 3.x | open | Audit `mars-nweadmin` workflows and define a portable NCP-based admin client API.  Linux should investigate ncpfs behind a transport adapter.  Windows should wrap the installed Novell Client first where practical, hidden behind the same adapter.  Classic/PPC macOS may use the historical Novell NetWare Client only as a compatibility/reference path; modern macOS needs either an ncpfs port or a project-owned NCP transport.  Do not link the admin GUI directly to local server libraries. |
 | Remote admin GUI frontend | later / guarded | open | A GUI may use Lazarus LCL/FreePascal or another cross-platform toolkit, but only after the portable admin client API has a console/CTest frontend.  Keep first-pass dependencies small; Cross.Codebot/TMS WEB Core/uniGUI-style stacks are later evaluations, not required dependencies.  Directory/ConsoleOne-like features come later after the directory stack is ready. |
 | Server-local nwConsole/nwadmin admin frontend | later / guarded | open | Replace the old SMArT role with a split design: `nwwebui` is the small HTTP/HTTPS/TLS/session/static frontend and SSL offloader exposed to users as nwConsole; `nwadmin` is the backend process that owns web/config plugins and calls the portable admin API.  Keep bindery/server authentication first for 3.x, later directory/`libnwds` authentication first for 4.x, PAM fallback only, `libowfat` for socket/helper work where suitable, and MatrixSSL/`libnwssl` for TLS.  A host-level systemd/init restart may restart the whole MARS-NWE service family including `nwwebui`, but nwConsole-requested backend restarts must keep `nwwebui` running unless the operator explicitly restarts the web frontend.  `nwwebui` needs embedded nwConsole status pages for `Restarting nwadmin`, `Restarting ncpserv`, `Restarting nwconn`, `Restarting nwbind`, backend unavailable and reconnect states.  Replace SMArT-style subprocess console-output coupling with an explicit local IPC socket between `nwwebui` and `nwadmin`. |
 | NDS/NCP Fragger and related 4.x infrastructure | later / guarded | Keep out of default runtime until transport/client scope is explicit. |

doc/NWADMIN_CLIENT_PLAN.md

@@ -57,15 +57,22 @@ Initial direction:
 
 - Linux: prefer the existing ncpfs client library where it can provide the 3.x
   NCP operations needed by the admin client.
-- macOS: investigate whether ncpfs can be ported or whether a small project-owned
-  NCP client transport is required.
-- Windows: do not rely on the old Delphi/VLM/NWTP layer for new code.  Choose a
-  backend only after auditing realistic options: native client API if available,
-  a ported ncpfs-like backend, or a project-owned NCP transport.
+- Windows: expect the Novell Client to be the practical first backend.  A
+  Windows administrator workstation normally needs that client stack anyway for
+  authentic NetWare access, so `nwAdmin` should wrap a Windows Novell Client
+  backend through the same transport adapter instead of reviving the old Pascal
+  VLM/NWTP layer.  A project-owned NCP backend can remain a later fallback only
+  if the native client path is unavailable or too limited.
+- Classic/PPC macOS: treat the historical Novell NetWare Client for Macintosh as
+  a compatibility reference for old systems where it is available, not as a
+  modern portable dependency.
+- Modern macOS: plan for either an ncpfs client-library port or a small
+  project-owned NCP transport behind the adapter, because the old Macintosh
+  client does not solve current macOS targets.
 
 The GUI must call only the portable admin client API.  Platform-specific NCP
-attachment, login, request framing, timeouts, and reconnect behaviour belong
-below that API.
+attachment, login, request framing, timeouts, reconnect behaviour, and native
+client integration belong below that API.
 
 ## GUI direction
 
@@ -223,15 +230,20 @@ the IPC socket when the backend comes back, and show an embedded nwConsole
 2. Define a portable admin client API over NCP for the 3.x path.
 3. Implement a Linux backend using ncpfs where practical, with the backend hidden
    behind the transport adapter.
-4. Add a console/CLI test frontend so CTest can exercise the client API without a
+4. Add a Windows transport adapter that wraps the installed Novell Client where
+   practical, because that is the expected first Windows backend.
+5. Audit the old Macintosh NetWare client as a Classic/PPC reference only, then
+   decide whether modern macOS needs an ncpfs port or a project-owned NCP
+   transport.
+6. Add a console/CLI test frontend so CTest can exercise the client API without a
    GUI.
-5. Add a simple server-local nwConsole (`nwwebui`) plus `nwadmin` pair only after the API is
+7. Add a simple server-local nwConsole (`nwwebui`) plus `nwadmin` pair only after the API is
    stable enough: `nwwebui` handles HTTP/HTTPS/TLS/session/static frontend work,
    while `nwadmin` owns plugin dispatch and management operations.
-6. Add a desktop GUI frontend only after the admin client API and transport
+8. Add a desktop GUI frontend only after the admin client API and transport
    behaviour are stable and the toolkit choice does not force large dependencies
    into the common/server side.
-7. Later, when LDAPv2/LDAPv3, schema import, `libnwds`, console `nwsetup`, and
+9. Later, when LDAPv2/LDAPv3, schema import, `libnwds`, console `nwsetup`, and
    the FLAIM-backed directory stack are ready, extend the admin client toward
    directory administration in a ConsoleOne-like direction.
 
@@ -243,8 +255,12 @@ the IPC socket when the backend comes back, and show an embedded nwConsole
   server.
 - Do not combine the 3.x admin-client transport work with the later Directory/NDS
   management work.
-- Do not choose the final macOS or Windows transport backend before the 3.x NCP
-  API needs have been audited.
+- Do not make modern macOS depend on the old Classic/PPC Novell Client.  Use it
+  only as a compatibility/reference path; modern macOS needs either an ncpfs port
+  or a project-owned NCP transport adapter.
+- Do not revive the old Pascal VLM/NWTP runtime layer for Windows.  Prefer the
+  installed Novell Client backend first, hidden behind the portable transport
+  adapter.
 - Do not make Cross.Codebot, TMS WEB Core, uniGUI, or any other large GUI/web
   framework a required first-pass dependency.
 - Do not merge HTTP/HTTPS/session handling into `nwserv`; keep `nwwebui` or an