docs: document flaim autotools to cmake conversion plan

REDESIGN.md

@@ -1195,6 +1195,46 @@ 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.
 
+The inspected FLAIM trunk snapshot (`flaim-code-r1112-trunk`) already contains
+Autotools files (`configure.ac`, `Makefile.am`, libtool usage, `config.h`
+generation) and several subprojects (`ftk`, `flaim`, `sql`, `xflaim`).  Even so,
+mars-nwe should still replace that build integration with native CMake.  The
+Autotools setup is useful as source inventory and feature-check documentation,
+but it does not match the mars-nwe build style and should not be invoked from the
+main CMake build.
+
+The first CMake import should be intentionally small and storage-focused:
+
+```text
+required first targets:
+  FLAIM::ftk      # cross-platform toolkit used by libflaim
+  FLAIM::flaim    # classic FLAIM database library used by libdirectory
+
+optional later targets:
+  FLAIM::sql      # SQL FLAIM, not needed for initial directory store
+  FLAIM::xflaim   # XML FLAIM, not needed for initial directory store
+  flaim tools     # checkdb/rebuild/view/dbshell/etc., off by default
+  flaim tests     # off by default
+  flaim docs      # off by default
+```
+
+`FLAIM::flaim` depends on the FTK toolkit, so the CMake conversion should model
+that dependency explicitly instead of relying on Autotools' installed-library
+search.  The initial mars-nwe directory-store work only needs the classic FLAIM
+library path; SQL FLAIM, XFLAIM, Java/C# bindings, Doxygen, OBS/debian package
+metadata, NetWare NLM files, and Windows project files should remain imported as
+reference material but disabled in the mars-nwe build until a real need exists.
+
+Autotools feature checks should be translated into CMake checks only when they
+matter for the required targets.  Examples from the inspected tree include
+pthread support, large-file support, selected POSIX headers/functions, optional
+ncurses/rt checks for utilities, debug defines such as `FLM_DEBUG`, and platform
+defines such as `OSX`.  OpenSSL support in FTK should not become a new TLS
+direction for mars-nwe; TLS policy remains wolfSSL through the `nwtls` facade.
+If any old FLAIM crypto/TLS-related option is required for building, it must be
+reviewed separately and kept isolated from mars-nwe provider IPC and LDAP TLS
+policy.
+
 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

third_party/README.md

@@ -55,9 +55,22 @@ 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`.
+wrapped from the mars-nwe build.  The uploaded r1112 trunk snapshot already has
+Autotools files, but those should be treated as source inventory and build-check
+reference material.  The resulting tree should build both as a standalone library
+project and as a mars-nwe subdirectory, exposing normal CMake targets.
+
+The first required targets are expected to be:
+
+```text
+FLAIM::ftk
+FLAIM::flaim
+```
+
+SQL FLAIM, XFLAIM, tools, tests, generated documentation, package metadata,
+Windows projects, NetWare NLM files, Java/C# bindings, and other legacy build
+outputs should remain optional/off by default until mars-nwe actually needs
+them.
 
 FLAIM is C++ code.  mars-nwe C components should not include FLAIM C++ headers
 directly.  Access should go through the future `libdirectory` C API.