0469 docs: record LDAPv2-first directory and console nwsetup order

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:
 
-- `0468 docs: record nwdirectory flatfile-first and storage-swap plan`
+- `0469 docs: record LDAPv2-first directory and console nwsetup order`
 
 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,20 +67,23 @@ The active line is expected to include:
 
 Last generated patch:
 
-- `0468 docs: record nwdirectory flatfile-first and storage-swap plan`
+- `0469 docs: record LDAPv2-first directory and console nwsetup order`
 
 Purpose of that patch:
 
-- Record the directory-service layering before touching TinyLDAP code: first
-  make the tinyldap-derived `nwdirectory` server pass LDAPv2/LDAPv3 and schema
-  import tests on its existing flatfile/mmap/journal storage.
-- Keep the later FLAIM conversion as a separate storage-engine swap: add
-  FLAIM-backed source files next to the current `mstorage_*`/`mduptab_*` files
-  and select one backend from CMake, while preserving the same exported storage
-  function names so the LDAP/server code does not change in the same patch.
-- Clarify that future `libnwds` sits above `libnwdirectory`, while
-  `libnwdirectory` later uses `libnwflaim`; the `nwdirectory` name itself is the
-  server/binary.
+- Refine the directory roadmap before touching TinyLDAP code: LDAPv2 support is
+  the first code block, with OpenLDAP 1.0.3 used only as the historical LDAPv2
+  behaviour/reference tree.
+- Keep the current `libnwdirectory` flatfile/mmap/journal backend active while
+  adding LDAPv2/LDAPv3 TCP CTests and NetWare/NDS schema handling.  Schema work
+  may be native `.sch` import or a reviewed `.sch` to LDIF conversion path.
+- Add `libnwds` and the first `nwsetup` implementation together, but keep that
+  first setup path console/CLI-only so CTest can exercise initial provisioning
+  before the future `nwtui` frontend exists.
+- Keep the FLAIM backend and interactive TUI setup as later, separate changes:
+  only after LDAPv2, schema handling, `libnwds`, and console `nwsetup` work on
+  flatfile storage should `libnwdirectory` gain the CMake-selected
+  `flaimstorage_*` backend below the existing storage function names.
 
 
 Directory/NDS work order before any FLAIM storage conversion:
@@ -92,11 +95,14 @@ Directory/NDS work order before any FLAIM storage conversion:
   start `nwdirectory` on `127.0.0.1:<free-port>` with a temporary flatfile
   workdir and test LDAPv2/LDAPv3 bind/search/unbind against test LDIF/schema
   data.
-- Later, when the flatfile LDAP path is stable, add FLAIM storage as parallel
-  backend source files selected by CMake.  For example, `flaimstorage_add_bin.c`
-  may provide the same exported `mstorage_add_bin()` function as the flatfile
-  file when the FLAIM backend is selected.  Do not break upstreamable flatfile
-  TinyLDAP code while adding the mars-nwe FLAIM backend.
+- Add `libnwds` and console-only `nwsetup` together after LDAPv2/schema flatfile
+  behavior is testable.  Do not make the first setup path depend on the TUI or
+  on acting as an LDAP client.
+- Later, when the flatfile LDAP/setup path is stable, add FLAIM storage as
+  parallel backend source files selected by CMake.  For example,
+  `flaimstorage_add_bin.c` may provide the same exported `mstorage_add_bin()`
+  function as the flatfile file when the FLAIM backend is selected.  Do not break
+  upstreamable flatfile TinyLDAP code while adding the mars-nwe FLAIM backend.
 
 
 Rejected or superseded patches that must not be reused as-is:

REDESIGN.md

@@ -1470,9 +1470,12 @@ not make LDAP the canonical internal representation.
 Do not combine the LDAP compatibility work and the FLAIM storage conversion in
 one patch series.  The tinyldap-derived `nwdirectory` server should first be
 made testable and compatible while it still uses its current flatfile/mmap/journal
-storage.  LDAPv2 support, LDAPv3 behaviour that already works, schema import
-under `opt/schema`, and `nwsetup`-driven provisioning should all be proven on the
-flatfile backend before the storage engine changes.
+storage.  LDAPv2 support comes first, using OpenLDAP 1.0.3 as the historical
+LDAPv2 server reference.  LDAPv3 behaviour that already works, NetWare/NDS schema
+import or `.sch` to LDIF conversion, and the first `libnwds` plus console-only
+`nwsetup` provisioning path should all be proven on the flatfile backend before
+the storage engine changes.  The interactive `nwtui` setup frontend comes later,
+after the flatfile path and the FLAIM storage backend are both stable.
 
 This keeps changes upstreamable to the tinyldap-derived code line: LDAPv2 work is
 generally useful, while the FLAIM storage backend is mars-nwe-specific.  The
@@ -1529,7 +1532,9 @@ before FLAIM is introduced.  Prefer existing tinyldap test clients and helpers
 where they are suitable.  A test should allocate a temporary workdir, start
 `nwdirectory` on `127.0.0.1:<free-port>`, load or prepare test LDIF/schema data,
 run LDAPv2 or LDAPv3 bind/search/unbind checks, stop the server, and remove the
-workdir.
+workdir.  The first `nwsetup` tests should be console/CLI tests that call the
+new `libnwds` API directly; they should not require a terminal UI and should not
+act as LDAP clients to bootstrap local directory state.
 
 
 ### NetWare 4.11 LDAP compatibility baseline

TODO.md

@@ -27,7 +27,7 @@ why it matters, and where the work belongs.
 | External file reconciliation | P1 | Planned next | Add libnwfs watcher/scanner support so Samba, rsync and host-created files receive `netware.metadata` and namespace records. |
 | Terminal UI/toolbox and curses replacement | P2 | Planned / pre-implementation | Use `doc/TUI_TOOLBOX_PLAN.md`; replace direct `curses.h` use with `nwtui`, add `nwi18n`, and keep future setup/filer/salvage tools as multi-call `nwtoolbox` applets. |
 | Shared libnwcore INI reader/writer | P1 | Planned / pre-implementation | Use `doc/NWCORE_INI_PLAN.md`; provide one robust parser/writer for server config, `nwsetup`, `nwtoolbox` and optional `nwi18n` catalogs instead of hiding config parsing inside the TUI layer. |
-| nwdirectory LDAP flatfile compatibility | P2 | Planned / flatfile first | Add LDAPv2/LDAPv3 CTests against the current tinyldap flatfile backend before any FLAIM storage swap. |
+| nwdirectory LDAPv2 flatfile compatibility | P2 | Planned / flatfile first | Add LDAPv2 support and LDAPv2/LDAPv3 CTests against the current tinyldap flatfile backend before any FLAIM storage swap. |
 
 ## nwdirectory LDAP and storage-backend staging
 
@@ -35,20 +35,26 @@ Do not make the tinyldap-derived `nwdirectory` work solve LDAP compatibility and
 FLAIM storage at the same time.  Keep the sequence explicit:
 
 1. keep the existing flatfile/mmap/journal backend active;
-2. add LDAPv2 and LDAPv3 CTests over TCP using isolated workdirs and free local
+2. add LDAPv2 support first, using OpenLDAP 1.0.3 only as the historical LDAPv2
+   server reference for behaviour and wire layout;
+3. add LDAPv2 and LDAPv3 CTests over TCP using isolated workdirs and free local
    ports;
-3. use existing tinyldap test/client helpers where they are suitable, rather than
+4. use existing tinyldap test/client helpers where they are suitable, rather than
    adding a mandatory OpenLDAP client dependency;
-4. make `opt/schema` import and flatfile-backed provisioning work before storage
-   changes;
-5. only after that, add a FLAIM backend as a CMake-selected replacement source
+5. make NetWare/NDS schema handling work on flatfile storage, either through
+   native `.sch` import or a reviewed `.sch` to LDIF conversion path;
+6. add `libnwds` together with a console/CLI-only `nwsetup` path that CTest can
+   exercise without the future TUI frontend;
+7. only after that, add a FLAIM backend as a CMake-selected replacement source
    set that exports the same storage function names as the flatfile files.
 
 The later FLAIM backend should live beside the current storage files, not replace
 them in-place.  For example, a future `flaimstorage_add_bin.c` can implement
 `mstorage_add_bin()` when the FLAIM backend is selected.  The flatfile backend
 must remain buildable and testable so generally useful LDAPv2 work can stay
-upstreamable to the tinyldap-derived component.
+upstreamable to the tinyldap-derived component.  Interactive `nwtui` setup comes
+after the flatfile and FLAIM paths are proven; the first `nwsetup` path is a
+console/CLI test target.
 
 ## NCP provider handoff cleanup
 

doc/DIRECTORY_STACK_PLAN.md

@@ -55,19 +55,37 @@ and any NetWare-facing directory policy code.
 
 ## Implementation order
 
-Do not combine the LDAP work and the storage-engine swap.
+Do not combine LDAP protocol compatibility, NetWare schema import, setup tooling
+and the storage-engine swap.  The first directory implementation phase is
+flatfile-only.
 
 1. Keep `libnwdirectory` on the current flatfile/mmap/journal backend.
-2. Add LDAPv2 CTests over TCP against `nwdirectory` with isolated temporary
+2. Add LDAPv2 support to the TinyLDAP-derived server first.  TinyLDAP is
+   currently treated as the LDAPv3-era baseline; the uploaded OpenLDAP 1.0.3
+   tree is the historical LDAPv2 server reference for bind/search/result/BER
+   behaviour, not a source tree to import wholesale.
+3. Add LDAPv2 CTests over TCP against `nwdirectory` with isolated temporary
    workdirs and free loopback ports.
-3. Add LDAPv3 CTests for behaviour that is already present or intentionally
-   supported.
-4. Make schema import under `opt/schema` work on the flatfile backend.
-5. Add `nwsetup`/tooling flows against the flatfile-backed directory state.
-6. Only after those tests are stable, add a FLAIM storage backend.
+4. Keep/add LDAPv3 CTests for behaviour that is already present or intentionally
+   supported, but do not make LDAPv3 the NetWare 4.11 compatibility baseline.
+5. Make NetWare/NDS schema handling work on the flatfile backend.  Prefer native
+   `.sch` import if practical; otherwise add a reviewed `.sch` to LDIF
+   conversion path.
+6. Add `libnwds` and the first `nwsetup` path together.  The first `nwsetup`
+   implementation should be console/CLI-only so CTest can exercise initial
+   setup without the future `nwtui` frontend.  It should call `libnwds`, and
+   `libnwds` should call `libnwdirectory`; it should not bootstrap by acting as
+   an LDAP client to `nwdirectory`.
+7. Only after LDAPv2, LDAPv3 smoke coverage, schema import, `libnwds` and the
+   console `nwsetup` path are stable on flatfile storage, add a FLAIM storage
+   backend.
+8. After the FLAIM backend is working, add the interactive `nwtui`/`nwtoolbox`
+   setup frontend and the certificate/TLS directory-storage work as separate
+   follow-up changes.
 
-This keeps LDAPv2 improvements generally useful to the TinyLDAP-derived code and
-keeps the later FLAIM backend as a clearly mars-nwe-specific storage change.
+This keeps LDAPv2 improvements generally useful to the TinyLDAP-derived code,
+keeps `nwsetup` testable before the UI exists, and keeps the later FLAIM backend
+as a clearly mars-nwe-specific storage change.
 
 ## Future storage-backend swap
 
@@ -128,7 +146,8 @@ Suggested future test names:
 ```text
 nwdirectory.ldap.v2.bind-search-flatfile
 nwdirectory.ldap.v3.bind-search-flatfile
-nwdirectory.schema.import-flatfile
+nwdirectory.schema.sch-import-flatfile
+nwds.setup.console-flatfile
 nwdirectory.storage.flatfile.smoke
 nwdirectory.storage.flaim.smoke   # later, after the backend swap
 ```