0471 docs: keep nwadmin frontends lightweight and plan nwwebui path

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:
 
-- `0470 docs: record remote nwadmin client and GUI roadmap`
+- `0471 docs: keep nwadmin frontends lightweight and plan nwwebui path`
 
 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,23 +67,24 @@ The active line is expected to include:
 
 Last generated patch:
 
-- `0470 docs: record remote nwadmin client and GUI roadmap`
+- `0471 docs: keep nwadmin frontends lightweight and plan nwwebui path`
 
 Purpose of that patch:
 
-- Record that `mars-nweadmin` is a historical Delphi/VCL/NwTP workflow reference,
-  not the runtime architecture for a new portable administrator client.
-- Keep the first admin-client target on the NetWare 3.x path: bindery/server
-  administration over NCP, with Directory/NDS/ConsoleOne-like features reserved
-  for the later directory phase.
-- Require remote administrator tools to use a portable admin client API over NCP
-  or later directory protocols instead of linking directly to local server
-  implementation libraries such as `libnwdirectory`, `libnwflaim`, or
-  server-private `libnwds` internals.
-- Leave the GUI toolkit open: Lazarus LCL/FreePascal is acceptable, but another
-  cross-platform GUI can be chosen if it is cleaner.  Linux should investigate
-  ncpfs behind a transport adapter; macOS may need an ncpfs port or a small
-  project-owned transport; Windows needs a later backend audit.
+- Keep the new `nwadmin`/admin-client architecture focused on a small portable
+  API first: console/CTest and 3.x NCP behaviour before a rich desktop or web
+  framework is selected.
+- Leave Lazarus LCL/FreePascal and other cross-platform GUI toolkits possible,
+  but make heavier stacks such as custom-drawn Lazarus/Delphi libraries or
+  browser-oriented Pascal frameworks later evaluations, not first-pass required
+  dependencies.
+- Record a server-local web admin direction that can eventually replace SMArT:
+  `nwserv` or service management may start/supervise `nwwebui`, while `nwwebui`
+  owns HTTP/HTTPS, TLS, sessions, PAM/login and static assets.
+- Require `nwwebui` management operations to go through the same portable admin
+  API over localhost NCP or an explicit control IPC, not through local storage
+  libraries such as `libnwdirectory`, `libnwflaim`, or private server-side
+  `libnwds` internals.
 
 Directory/NDS work order before any FLAIM storage conversion:
 

REDESIGN.md

@@ -2573,6 +2573,15 @@ Terminal UI, toolbox and curses replacement plan:
   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.
+- 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
+  admin client library or server daemons.
+- A server-local web admin frontend may eventually replace the old SMArT role:
+  `nwserv` or the service manager may start/supervise `nwwebui`, while `nwwebui`
+  owns HTTP/HTTPS, TLS, sessions, PAM/login and static assets.  Management
+  actions should still go through the portable admin API over localhost NCP or an
+  explicit control IPC, not through local storage libraries.
 - Production daemons must not depend on the TUI stack or on administrator GUI
   toolkits.
 - See `doc/TUI_TOOLBOX_PLAN.md` for the detailed UI/toolbox plan,

TODO.md

@@ -114,7 +114,8 @@ may remain active.
 | 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 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.  Directory/ConsoleOne-like features come later after the directory stack is ready. |
+| 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 nwwebui admin frontend | later / guarded | open | Allow `nwwebui` to grow into a SMArT replacement that is started or supervised by `nwserv`/service management, owns HTTP/HTTPS/TLS/login handling, and calls the same portable admin API over localhost NCP or explicit IPC instead of local storage libraries. |
 | NDS/NCP Fragger and related 4.x infrastructure | later / guarded | Keep out of default runtime until transport/client scope is explicit. |
 | TimeSync and NCP Extension families | later / guarded | Reference/stub only unless a real 3.x/4.x client path requires them. |
 | Migration, compression, data migration and later OES/MOAB-style selectors | reference-only | Study reusable data models only; do not add default live endpoints during the 3.x push. |

doc/NWADMIN_CLIENT_PLAN.md

@@ -69,6 +69,50 @@ If Lazarus LCL is used, treat the old Delphi forms as a workflow/screen referenc
 only.  Do not try to preserve the old VCL/NwTP implementation as the new runtime
 transport layer.
 
+
+## GUI and web frontend dependency policy
+
+Keep the first client simple.  The portable admin client API and the console/CLI
+frontend are more important than a rich desktop framework.  A graphical frontend
+can be Lazarus LCL/FreePascal or another cross-platform toolkit, but the selected
+toolkit must not pull a large runtime stack into the server or common libraries.
+
+Evaluate heavier Pascal GUI/web stacks only after the 3.x NCP admin API is
+proven.  Custom-drawn Lazarus/Delphi libraries such as Cross.Codebot can be
+looked at for a later modern desktop UI, and browser-oriented Pascal stacks such
+as TMS WEB Core or uniGUI can be compared for a later web UI, but none of them is
+a first-pass dependency.  The first-pass rule is: common admin logic stays in the
+portable client library, and every frontend remains replaceable.
+
+## Server-local web administration
+
+A server-local web admin path is allowed and may eventually replace the old
+SMArT role.  Treat it as a separate frontend, not as the architecture for the
+common admin client library.
+
+Preferred shape:
+
+```text
+nwserv / service manager
+  -> starts or supervises nwwebui when configured
+       -> owns HTTP/HTTPS, TLS, sessions, PAM/login and static assets
+       -> calls the same admin client API used by nwadmin
+            -> localhost/server NCP transport or explicit server-control IPC
+                 -> mars-nwe server
+```
+
+`nwwebui` may reuse the existing SMArT-derived web service direction for HTTP,
+HTTPS and login handling, but the management operations should move behind the
+same portable admin API used by console and GUI frontends.  The web UI must not
+call local storage libraries such as `libnwdirectory`, `libnwflaim`, or private
+server-side `libnwds` internals.
+
+For the first server-local web UI, prefer simple generated HTML, small static
+assets and normal forms.  Avoid making a large single-page-application framework
+or a Pascal-to-JavaScript compiler a required dependency for a server admin tool.
+A richer browser UI can be added later if the small web UI and admin API prove
+insufficient.
+
 ## Work order
 
 1. Audit `mars-nweadmin` workflows for the 3.x feature set: users, passwords,
@@ -79,9 +123,13 @@ transport layer.
    behind the transport adapter.
 4. Add a console/CLI test frontend so CTest can exercise the client API without a
    GUI.
-5. Add a GUI frontend only after the admin client API and transport behaviour are
-   stable.
-6. Later, when LDAPv2/LDAPv3, schema import, `libnwds`, console `nwsetup`, and
+5. Add a simple server-local `nwwebui` admin frontend only after the API is
+   stable enough to keep SMArT-style HTTP/HTTPS/login handling separate from
+   management operations.
+6. 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
    the FLAIM-backed directory stack are ready, extend the admin client toward
    directory administration in a ConsoleOne-like direction.
 
@@ -95,3 +143,7 @@ transport layer.
   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 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
+  equivalent frontend process responsible for the web surface.