docs: document flaim and tinyldap cmake integration policy

REDESIGN.md

@@ -1094,13 +1094,19 @@ third_party/wolfssl
   fixed TLS dependency used by mars-nwe TLS code
   configured through CMake for the server's supported platforms and features
 
+third_party/libflaim
+  planned fixed directory storage engine used through libdirectory
+  mars-nwe-maintained import/fork of the FLAIM source
+  converted to a real standalone-and-subdirectory CMake build
+
 third_party/zlog
   optional advanced logging backend used only through nwlog
 
 mars-tinyldap/
   forked/integrated tinyldap-derived component in the repository root
-  project-facing service name: nwdirectory
-  converted to the mars-nwe CMake build
+  upstream/standalone project identity remains tinyldap
+  mars-nwe service/binary name: nwdirectory
+  converted to a real standalone-and-subdirectory CMake build
   later wired to libdirectory/libflaim instead of tinyldap's original flat files
 ```
 
@@ -1162,29 +1168,89 @@ future backend changes centralized.  zlog can provide administrator-controlled
 category/rule/format routing, but it must never receive raw decoded NCP or
 handoff payloads from bypass paths.
 
+### libflaim storage engine rule
+
+`libflaim` should live under `third_party/libflaim`, not at the repository root.
+It is a bundled storage engine dependency for the future directory store, not a
+mars-nwe service component.  The initial import may come from the SourceForge
+FLAIM code base or from a distro-vetted source package such as the openSUSE
+`libflaim-4.9.1046` source package, but the exact source must be recorded.
+
+The imported tree is expected to need a mars-nwe-maintained fork because the
+original build system is too hard to integrate directly.  Do not merely wrap the
+old Makefiles from CMake.  Replace the build integration with a real CMake build
+that can work both ways:
+
+```text
+standalone:
+  cmake -S third_party/libflaim -B build-flaim
+
+inside mars-nwe:
+  add_subdirectory(third_party/libflaim)
+  target_link_libraries(directory PRIVATE FLAIM::flaim)
+```
+
+The CMake conversion should separate the library from optional tools/tests,
+expose a normal target such as `FLAIM::flaim`, and support static/shared choices
+where useful.  The original Makefiles may remain as reference material during the
+import, but they should not be the long-term build path.
+
+FLAIM is C++ code.  That is acceptable, but its C++ API must not leak into the
+old mars-nwe C code.  `nwbind`, future `nwnds`, `nwdirectory`, and `nwsetup`
+should use a C ABI through `include/libdirectory.h` or an equivalent internal
+`libdirectory` API.  Only the `libdirectory` implementation should know that the
+store underneath is libflaim.
+
+The final import must include `third_party/libflaim/README.mars-nwe.md` or an
+equivalent note listing:
+
+- import source and version/revision;
+- distro package and distro patches, if used;
+- library source license, observed as LGPL-2.1 in the inspected source;
+- separate helper/tool licenses such as BSD-3-Clause for files like `svn2cl.xsl`;
+- local CMake and portability changes;
+- how mars-nwe links it through `libdirectory`.
+
 ### Forked tinyldap / nwdirectory rule
 
-`tinyldap` is different from yyjson, wolfSSL, and zlog.  It is not merely a small
-library dependency.  The planned integration requires a fork because the original
-code needs mars-nwe-specific work:
+`tinyldap` is different from yyjson, wolfSSL, zlog, and libflaim.  It is not a
+small library dependency and it is not merely a storage engine.  It becomes the
+LDAP service component used by mars-nwe, so it follows the existing root-level
+component pattern used by `admin`, `dosutils`, `mail`, and `smart`.
 
-- CMake build support;
-- mars-nwe service naming (`nwdirectory`);
+The repository name can be `mars-tinyldap/`, but the upstream/standalone project
+identity should remain `tinyldap`.  In other words: when built standalone it is
+still tinyldap; when built as part of mars-nwe, the project-facing service/binary
+name is `nwdirectory`.
+
+The planned integration requires a fork because the original code needs
+mars-nwe-specific work:
+
+- a real CMake build, not only the original Makefile;
+- standalone tinyldap build support under the tinyldap name;
+- mars-nwe subdirectory build support producing the `nwdirectory` service;
 - LDAP/LDAPS/StartTLS integration through `nwtls`/wolfSSL;
 - replacement or bypass of the original flat-file storage;
 - later `libdirectory` and libflaim-backed storage integration;
 - directory schema, bootstrap, and setup integration through `nwsetup`.
 
-Because of that, the fork should live in the repository root as `mars-tinyldap/`,
-matching the existing pattern for project components that are not treated as
-plain third-party libraries.  The code may still document its upstream origin,
-license, and local changes, but it is part of the mars-nwe component tree.
+The CMake conversion should therefore support both use cases:
+
+```text
+standalone upstream-style build:
+  cmake -S mars-tinyldap -B build-tinyldap
+  # produces tinyldap-named targets/tools
+
+inside mars-nwe:
+  add_subdirectory(mars-tinyldap)
+  # produces the nwdirectory service/integration target
+```
 
 The architectural relationship remains:
 
 ```text
 LDAP/LDAPS client
-  -> nwdirectory service built from mars-tinyldap
+  -> nwdirectory service built from mars-tinyldap/tinyldap code
       -> libdirectory
           -> libflaim-backed store
 ```
@@ -1203,7 +1269,9 @@ Each bundled or forked dependency should have a short mars-nwe note describing:
 - whether it is fixed, optional, or forked;
 - which mars-nwe facade owns access to it;
 - local changes carried by mars-nwe;
-- CMake options used by the mars-nwe build.
+- CMake options used by the mars-nwe build;
+- whether the component supports standalone builds, mars-nwe subdirectory builds,
+  or both.
 
 Do not silently update third-party submodules together with unrelated functional
 changes.  Dependency bumps should be separate patches.  Forked root components

third_party/README.md

@@ -41,6 +41,27 @@ src/nwtls_wolfssl.c
 Planned uses include LDAP/LDAPS/StartTLS in `nwdirectory` and any future
 TCP-based internal provider IPC that requires mTLS.
 
+
+## Planned: libflaim
+
+libflaim is the planned bundled persistent storage engine for the future
+`libdirectory` store.  It belongs under `third_party/libflaim` because it is a
+storage engine dependency, not a mars-nwe service fork.
+
+The import should be mars-nwe-maintained.  The initial source may come from the
+SourceForge FLAIM code base or from a distro-vetted source package such as the
+openSUSE `libflaim-4.9.1046` source package.  The exact source, version, distro
+patches, licenses, and local changes must be documented in
+`third_party/libflaim/README.mars-nwe.md`.
+
+The original FLAIM build system should be replaced with a real CMake build, not
+wrapped from the mars-nwe build.  The resulting tree should build both as a
+standalone library project and as a mars-nwe subdirectory, exposing a normal CMake
+target such as `FLAIM::flaim`.
+
+FLAIM is C++ code.  mars-nwe C components should not include FLAIM C++ headers
+directly.  Access should go through the future `libdirectory` C API.
+
 ## Planned: zlog
 
 zlog is the planned optional advanced logging backend.  If added, it should live
@@ -62,6 +83,9 @@ repository root, following the existing pattern used by `admin`, `dosutils`,
 `mail`, and `smart`.
 
 The planned tinyldap fork is such a component.  It should live as
-`mars-tinyldap/` at the repository root, build the project-facing `nwdirectory`
-service, gain CMake support, and later use `libdirectory`/libflaim-backed
-storage instead of tinyldap's original flat-file storage.
+`mars-tinyldap/` at the repository root.  Its standalone identity remains
+`tinyldap`, while the mars-nwe integration builds the project-facing
+`nwdirectory` service.  The fork should gain a real CMake build that works both
+standalone under the tinyldap name and as a mars-nwe subdirectory, and it should
+later use `libdirectory`/libflaim-backed storage instead of tinyldap's original
+flat-file storage.