1    Recommended workflow

2    Documentation

3    Plan for Generating cljfmt and clj-kondo Rules for Custom Top-Level Forms

Plan for Generating cljfmt and clj-kondo Rules for Custom Top-Level Formsnn## ObjectivenTo systematically identify custom top-level forms within the /src directory of the foundation-base project and propose methods for generating appropriate cljfmt and clj-kondo rules.nn## Phase 1: Identification of Custom Top-Level FormsnnThe goal of this phase is to identify all unique custom top-level forms. This will involve more than just defmacro as other constructs might also define custom forms (e.g., def, defn with specific metadata, deftype, defrecord, defprotocol, defmulti, defmethod when used in a DSL-like manner).nn### Steps:n1. List all .clj files in /src: Obtain a comprehensive list of all Clojure source files.n2. Parse each file for top-level forms: For each .clj file, read its content and identify all top-level forms. This will require a more sophisticated approach than simple regex, possibly involving a basic Clojure parser or by looking for common patterns of top-level definitions.n3. Filter for custom forms:n Exclude standard Clojure forms (e.g., ns, require, def, defn, let, if, do, comment).n Identify forms that are likely custom macros or DSL constructs. This will involve looking for:n defmacro and its variants (defmacro.js, defmacro.lua, etc.).n def forms that define functions or macros (e.g., (def my-macro (macro/macro-fn ...))).n Forms with specific metadata that indicates custom behavior (e.g., ^{:static/lang :bash}).n deftype, defrecord, defprotocol, defmulti, defmethod if they are part of a custom DSL.n4. Categorize custom forms: Group identified custom forms by their type and behavior (e.g., function-like, variable-like, block-like, DSL-specific). This categorization will inform the type of cljfmt and clj-kondo rules needed.n5. Collect metadata: Extract any relevant metadata associated with these forms, especially ^:style/indent for cljfmt and any lint-as hints for clj-kondo.nn## Phase 2: Generation of clj-kondo RulesnnBased on the identified and categorized custom forms, generate clj-kondo lint-as rules.nn### Steps:n1. Default lint-as mappings: For each category of custom forms, propose a default lint-as mapping to a standard Clojure form (e.g., clojure.core/def, clojure.core/defn, clojure.core/do).n2. Automate lint-as generation: Develop a script or a systematic process to generate the lint-as entries for the .clj-kondo/config.edn file. This script would:n Read the identified custom forms and their categories.n Generate the corresponding lint-as entries.n Merge these new entries with the existing .clj-kondo/config.edn without overwriting existing custom rules.n3. Identify potential custom hooks: For complex custom forms that cannot be adequately handled by lint-as, identify them as candidates for custom clj-kondo hooks. This would require manual inspection and development of Clojure code for the hooks.nn## Phase 3: Generation of cljfmt RulesnnAddress cljfmt rules, focusing on indentation and formatting.nn### Steps:n1. Review existing ^:style/indent: For custom forms that already have ^:style/indent metadata, verify if the indentation is correct.n2. Identify missing ^:style/indent: For custom forms lacking ^:style/indent metadata, propose adding appropriate metadata based on their structure (e.g., {:style/indent 1} for forms with a body).n3. Generate .cljfmt.edn entries (if necessary): If ^:style/indent is insufficient or if specific formatting rules are required (e.g., for complex DSLs), generate entries for a .cljfmt.edn file. This would involve:n Identifying the custom forms that need explicit cljfmt rules.n Defining the appropriate indentation rules (e.g., [](#:block 1), [](#:inner 0)).n Creating or updating the .cljfmt.edn file with these rules.nn## Phase 4: Verification and RefinementnnAfter generating the rules, verify their effectiveness and refine as needed.nn### Steps:n1. Run clj-kondo: Execute clj-kondo across the entire codebase with the updated configuration and analyze the output for new warnings or errors related to the custom forms.n2. Run cljfmt: Apply cljfmt to the codebase and visually inspect the formatting of the custom forms.n3. Iterative refinement: Adjust lint-as rules, add custom hooks, or refine cljfmt rules based on the verification results.nn## Tools to be used:n default_api.glob: To list .clj files.n default_api.read_file: To read file contents.n default_api.search_file_content: To find patterns like defmacro.n default_api.write_file: To create the plan file and update config files.n default_api.replace: To modify existing config files.n clj_eval: Potentially for parsing Clojure forms if a simple regex is insufficient.n

4    Function Design Guide for foundation-base

Function Design Guide for foundation-basennThis guide outlines best practices and common patterns for designing functions within the foundation-base project, drawing examples directly from the codebase. The goal is to promote clarity, modularity, extensibility, and maintainability.nn### 1. Clarity and ReadabilitynnFunctions should be easy to understand at a glance. This is achieved through clear naming, comprehensive documentation, and consistent formatting.nn#### 1.1. Docstrings and MetadatannEvery public function must have a comprehensive docstring that explains its purpose, arguments, and return value. The {:added "version"} metadata is mandatory.nn Purpose: Clearly state what the function does.n Arguments: Describe each argument, its type, and its role.n Return Value: Explain what the function returns.n Examples: Provide illustrative examples of how to use the function.n Metadata: Use {:added "version"} to track when the function was introduced. Other custom metadata can provide additional context.nnExample: std.lib.collection/map-keysnn```clojuren(defn map-keysn "changes the keys of a mapn n (map-keys inc {0 :a 1 :b 2 :c})n => {1 :a, 2 :b, 3 :c}"n {:added "3.0"}n ([f m]n (reduce (fn [out [k v]]n (assoc out (f k) v))n {} n m)))n```nnExample: std.lib.network/port:check-availablenn```clojuren(defn port:check-availablen "check that port is availablen n (port:check-available 51311)n => anything"n {:added "4.0"}n ([port]n (tryn (with-open [<sup>ServerSocket</sup> s (ServerSocket. port)]n (.setReuseAddress s true)n (.getLocalPort s))n (catch Throwable tn false))))n```nn#### 1.2. Naming Conventionsnn Public Functions: Use spinal-case (e.g., create-directory, process-transform).n Namespaced Functions: Use a colon (:) to create "sub-namespaces" for related functions (e.g., atom:get, socket:port).n Predicate Functions: End with a question mark ? (e.g., component?, hash-map?).n Internal/Helper Functions: Often start with a hyphen (-) or are not explicitly exposed (e.g., -write-value, tf-macroexpand).nn#### 1.3. Arity and Parameter OrdernnFunctions should handle multiple arities gracefully, typically with the simpler arities calling the more complex ones. Positional arguments are preferred for mandatory inputs, while optional parameters are often passed in a map.nnExample: std.fs.api/create-directorynn```clojuren(defn create-directoryn "creates a directory on the filesystem"n {:added "3.0"}n ([path]n (create-directory path {}))n ([path attrs]n (Files/createDirectories (path/path path)n (attr/map->attr-array attrs))))n```nn### 2. Modularity and Single ResponsibilitynnFunctions should ideally do one thing and do it well. Complex tasks are broken down into smaller, composable functions.nnExample: std.timeseries.compute/process-transformnnThis function focuses solely on transforming an array based on a given interval and template, delegating sub-tasks like parse-transform-expr and transform-interval to other functions.nn```clojuren(defn process-transformn "processes the transform stage"n {:added "3.0"}n ([arr {:keys [transform template merge-fn]} type time-opts]n (let [len (count arr)n empty (-> template :raw :empty)n interval (range/range-op :to interval arr time-opts)n [tag val] intervaln arr (case tagn :time (let [{:keys [key order]} time-optsn {:keys [op-fn comp-fn]} (common/order-fns order)n start (key (first arr))n steps (quot (math/abs (- start (key (last arr))))n val)n sorted (group-by (fn [m]n (quot (math/abs (- start (key m)))n val))n arr)]n (mapv (fn [i] n (or (get sorted i)n [(case typen :map (assoc empty key (op-fn start ( i val)))n :time (op-fn start ( i val)))]))n (range steps)))n :ratio (let [num (math/ceil ( len val))]n (partition num arr))n :array (partition val arr))]n (mapv merge-fn arr))))n```nn### 3. Parameter Designnn#### 3.1. Positional vs. Map Argumentsnn Positional Arguments: Used for mandatory and frequently used parameters.n Map Arguments: Preferred for optional parameters, configurations, or when there are many parameters. This improves readability and allows for easy extension.nnExample: std.lib.future/submitnn```clojuren(defn submitn "submits a task to an executor"n {:added "3.0"}n ([<sup>ExecutorService</sup> service ^Callable f]n (submit service f nil))n ([<sup>ExecutorService</sup> service f {:keys [min max delay default] :as m}]n (let [<sup>Callable</sup> f (cond-> fn min (wrap-min-time min (or delay 0)))n opts (cond-> {:pool service}n max (assoc :timeout max)n default (assoc :default default)n delay (assoc :delay delay))]n (f/future:run f opts))))n```nnn### 4. Error HandlingnnRobust error handling is crucial. The h/error function is the standard way to throw exceptions with structured data, making debugging easier.nnExample: std.lib.foundation/errornn```clojuren(defmacro errorn "throws an error with messagen n (error "Error")n => (throws)"n {:added "3.0"}n ([message]n (throw (ex-info ~message {})))n ([message data]n (throw (ex-info ~message ~data))))n```nnExample: hara.lang.base.book/assert-modulenn```clojuren(defn assert-modulen "asserts that module exists"n {:added "4.0"}n [book module-id]n (or (has-module? book module-id)n (h/error "No module found." {:available (set (list-entries book :module)) n :module module-id})))n```nn### 5. Immutability vs. MutabilitynnClojure favors immutability, but mutable state is managed explicitly when necessary.nn Persistent Data Structures: Clojure's default data structures are immutable.n Atoms and Volatiles: atom and volatile! are used for managing mutable state with clear semantics.n* defmutable: For defining mutable data structures when performance or specific behavior requires it.nnExample: std.lib.mutable/defmutablenn```clojuren(defmacro defmutablen "allows definition of a mutable datastructure"n {:added "3.0"}n ([tp-name fields & protos] n {:pre [(symbol? tp-name)n (every? symbol? fields)]} (let [fields (mapv (fn [sym] n (with-meta sym n (assoc (meta sym) :volatile-mutable true)))n fields)]n n (deftype ~tp-name ~fields n IMutablen (-set [~'this ~'k ~'v] n (case ~'k n ~@(mapcat n (fn [x] n [~(keyword (name x)) n (~'set! ~x ~'v)]) n fields)) n ~'this)n n (-set-new [~'this ~'k ~'v] n (assert (not (~'k ~'this)) (str ~'k " is already set.")) n (case ~'k n ~@(mapcat n (fn [x] n [~(keyword (name x)) n (~'set! ~x ~'v)]) n fields)) n ~'this)nn (-fields [~'this] n ~(mapv (comp keyword name) fields))nn (-clone [~'this] n ~(let [cstr (symbol (str tp-name "."))] n (~cstr ~@fields)))n n clojure.lang.ILookup n (~'valAt [~'this ~'k ~'default] n (case ~'k n ~@(mapcat n (fn [x] n [~(keyword (name x)) n ~x]) n fields) n ~'default))n (~'valAt [~'this ~'k] n (.valAt ~'this ~'k nil))n ~@protos))))n```nn### 6. Extensibility (Multimethods and Protocols)nnFunctions are often designed to be extensible, allowing new behaviors to be added without modifying existing code.nn* **defmulti and defmethod:** Used for dispatching behavior based on the type or value of arguments.n* **Protocols (defprotocol, extend-type, defimpl):** Define interfaces that can be implemented by different types.nn**Example: net.http.common/-write-value (Multimethod)**nn```clojuren(defmulti -write-valuen "writes the string value of the datastructure according to format"n {:added "0.5"}n (fn [s format] format))nn(defmethod -write-value :ednn ([s _]n (pr-str s)))n```nn**Example: std.lib.component/IComponent (Protocol with defimpl)**nn```clojuren(defimpl LuceneSearch [type instance]n :string common/to-stringn :protocols [std.protocol.component/IComponentn :body {-start impl/start-lucenen -stop impl/stop-lucene}])n```nn### 7. hara.lang DSL IntegrationnnFunctions designed for the hara.lang DSL have specific patterns for cross-platform compatibility and code generation.nn* **defn. and defmacro.:** Functions and macros are defined with a language-specific tag (e.g., defn.js, defmacro.lua).n* **Cross-Platform Utilities (xt.lang.base-lib):** The k/ alias is commonly used for xt.lang.base-lib functions, which provide platform-agnostic operations.n* **Code Generation:** Functions often take grammar and mopts (macro options) as arguments to facilitate code generation.nn**Example: js.blessed.layout/LayoutMain (React Component in JS DSL)**nn```clojuren(defn.js LayoutMainn "constructs the main page"n {:added "4.0"}n ([#{[(:= header {:menu []n :toggle niln :user nil})n (:= footer {:menu []n :toggle nil})n initn routen setRouten indexn setIndexn sectionsn statusn setStatusn busyn setBusyn notifyn setNotifyn menuWidthn menuContentn menuFootern menuHiden consolen consoleHeight]}] ; ... rest of functionn```nn**Example: kmi.queue.common/mq-do-key (Lua DSL Function)**nn```clojuren(defn.lua mq-do-keyn "helper function for multi key ops"n {:added "3.0"}n ([key f acc]n (local k-space (cat key ":_"))n (local k-pattern (cat k-space ":[^\\:]+$"))n (local k-partitions (r/scan-regex k-pattern (cat k-space ":*")))n (k/for:array [[i pfull] k-partitions]n (local p (. pfull (sub (+ (len key) 4))))n (f key p acc))n (return acc)))n```nn### 8. Higher-Order Functions and Function CompositionnnFunctions are often designed to be composed, taking other functions as arguments or returning functions.nn* **comp, partial:** Used for creating new functions from existing ones.n* **Threading Macros (->, ->>):** Used for chaining function calls, improving readability of sequential operations.nn**Example: std.lib.transform.apply/wrap-hash-set**nn```clojuren(defn wrap-hash-setn "allows operations to be performed on sets"n {:added "3.0"}n ([f]n (fn [val datasource]n (cond (set? val)n (set (map #(f % datasource) val))nn :elsen (f val datasource)))))n```nn### 9. Macros for Abstraction and Code GenerationnnMacros are used to reduce boilerplate, create DSLs, and generate code at compile time.nn* **defmacro:** Standard Clojure macro definition.n* **h/template-entries:** A powerful macro for generating multiple definitions from a template, often used for binding external library functions or constants.nn**Example: std.lib.template/deftemplate and h/template-entries**nn```clojuren(deftemplate res-api-tmpln ([](#sym res-sym config)n (let [extra (count (:args config))n args (map :name (:args config))n default (:default (first (:args config)))])n ;; ... generates def formn ))nn(h/template-entries [res-api-tmpl] n [[res:exists? res-access-get {:post boolean}]n [res:set res-access-set {:args [{:name instance}]}]])n```nnThis guide provides a deeper insight into the function design principles and patterns prevalent in the foundation-base` codebase. By understanding and applying these principles, developers can contribute functions that are consistent, robust, and easily integrated into the existing architecture.

5    Clojure Style Guide for foundation-base

Clojure Style Guide for foundation-basennThis guide is based on the conventions observed in the src/ directory of the foundation-base project. The goal is to maintain a consistent, readable, and idiomatic codebase that leverages Clojure's strengths, especially its macro system and functional programming paradigms, while also accommodating multi-platform code generation via std.lang.nn### 1. Naming ConventionsnnNaming is a crucial part of writing clean, understandable code. The following conventions are used throughout the project.nn#### 1.1. Files and Namespacesnn File Names: File names use spinal-case.n Example: collection.clj, future.clj, emit_common.cljnn Namespaces: Namespaces follow the directory structure and use dots to separate components. The general pattern is std.lib.<file-name> or hara.lang.base.<sub-directory>.<file-name>.n Example: std.lib.collection, hara.lang.base.emit-commonnn#### 1.2. Functionsnn Public Functions: Public functions use spinal-case.n Example: apply-in, swap-return!, create-directorynn Namespaced Functions: For groups of related functions within a single namespace, a colon (:) is used to create a "sub-namespace". This improves organization and readability.n Example: atom:get, atom:set, socket:port, res:spec-addnn Predicate Functions: Functions that return a boolean value should end with a question mark ?.n Example: component?, started?, primitive?, hash-map?, qml-props?nn Internal/Helper Functions: Internal or helper functions that are not intended for public use often start with a hyphen (-) or are not explicitly exposed in the ns declaration.n Example: -write-value, tf-macroexpand, qml-props?nn#### 1.3. Variables and Constantsnn Dynamic Variables: Dynamic variables (those that can be rebound) follow the Clojure convention of using "earmuffs" (asterisks around the name).n Example: *registry*, *kill*, *current*, *macro-form*nn Constants: Constants or configuration values are denoted by surrounding the name with plus signs +.n Example: +primitives+, +hex-array+, +default-config+, +op-math+nn#### 1.4. Protocols, Records, and Typesnn Protocols: Protocols are defined in CamelCase and are prefixed with an I.n Example: IComponent, IApplicable, IString, IElementnn Records and Types: Records and types, often defined with defimpl or defrecord, are written in CamelCase.n Example: HostApplicative, Result, Link, Zipper, Image, Schema, Trace, NotifyServernn### 2. Code Structure and Formattingnn#### 2.1. Namespace Declarationsnn All require statements should be at the top of the file, immediately after the ns declaration.n Use aliases for required namespaces to keep the code clean and concise.n (:refer-clojure :exclude [...]) is used to avoid name clashes with Clojure's built-in functions.nn```clojuren(ns std.lib.applyn (:require [std.protocol.apply :as protocol.apply]n [std.lib.foundation :as h]n [std.lib.future :as f]n [std.lib.return :as r]n [std.lib.impl :refer [defimpl] :as impl]))n```nn#### 2.2. Function Definitionsnn Public functions should have a docstring ("...") explaining their purpose, arguments, and return value.n Use the {:added "version"} metadata to indicate when a function was introduced.n For functions with multiple arities, each arity should be clearly defined.nn```clojuren(defn apply-inn "runs the applicative within a contextn n (apply-in (host-applicative {:form '+})n niln [1 2 3 4 5])n => 15"n {:added "3.0"}n ([app rt args]n (let [input (protocol.apply/-transform-in app rt args)n output (protocol.apply/-apply-in app rt input)]n (r/return-chain output (partial protocol.apply/-transform-out app rt args)))))n```nn#### 2.3. MetadatannMetadata is used extensively to provide additional information about functions, macros, and variables. Common metadata keys include:nn {:added "version"}: Indicates when the function/macro was added.n {:refer ...}: Used in tests to link to the function being tested.n {:style/indent N}: Specifies indentation for macros.n {:macro-only true}: For hara.lang scripts, indicates the file contains only macros.n {:static ...}: Used in hara.lang for static analysis or configuration.n {:rt/redis ...}: Specific to Redis runtime configurations.nn#### 2.4. Polymorphismnn The defimpl macro is the preferred way to create new types and records that implement one or more protocols.n Use extend-protocol or extend-type when extending existing types.n defmulti and defmethod are used for extensible functions based on dispatch values.nn```clojuren(defimpl HostApplicativen [function form async]n :prefix "host-"n :invoke invoke-asn :protocols [std.protocol.apply/IApplicablen :body {-apply-default niln -transform-in argsn -transform-out return}])nn(defmulti map->keyn "transforms a map into a key"n {:added "3.0"}n (fn [{:keys [mode]}] mode))nn(defmethod map->key :defaultn ([{:keys [type encoded]}]n (SecretKeySpec. (to-bytes encoded) type)))n```nn### 3. hara.lang DSL for Multi-Platform DevelopmentnnThe foundation-base project heavily leverages a custom DSL provided by std.lang for writing code that can be compiled to multiple target languages (e.g., JavaScript, Lua, Python, R, SQL, Solidity). This DSL has its own conventions that differ significantly from standard Clojure.nn#### 3.1. Script Definitionnn l/script: All platform-specific code must be defined within an (l/script <lang> ...) block. The :lang keyword specifies the target language.n l/script-: Used in test files for setting up platform-specific test environments.nn```clojuren(l/script :jsn {:require [[xt.lang.base-lib :as k]]n })nn(l/script :luan {:runtime :basicn :config {:program :resty}n :require [[xt.lang.base-lib :as k]]})n```nn#### 3.2. Function and Variable Definitionsnn defn.<lang>: Functions intended for a specific target language are defined using defn.js, defn.lua, defn.py, defn.r, defn.pg, etc.n def.<lang>: Variables for a specific target language are defined using def.js, def.lua, etc.n def$.<lang>: Used for defining global variables in the target language.nn```clojuren(defn.js my-functionn [x]n (k/identity x))nn(def.lua KGROUP "group")nn(def$.js GLTFLoadern (. ThreeGLTF GLTFLoader))n```nn#### 3.3. Macros for Code Generationnn defmacro.<lang>: Macros specific to a target language are defined using defmacro.js, defmacro.lua, etc.n h/template-entries: This macro is used to generate multiple definitions from a template, often for binding external library functions or constants.nn```clojuren(defmacro.js newOSCn "creates a new OSC instance"n {:added "4.0"}n [& [m]]n (list 'new 'OSC m))nn(h/template-entries [l/tmpl-entry {:type :fragmentn :base "ValtioCore"n :tag "js"}]n [getVersionn proxyn [proxyRef ref]n snapshotn subscribe])n```nn#### 3.4. Cross-Platform Utilities (xt.lang.base-lib)nn The xt.lang.base-lib namespace (aliased as k) provides a set of cross-platform utility functions that should be used whenever possible to ensure consistency across target languages.n Example: k/obj-keys, k/arr-map, k/identitynn#### 3.5. Platform-Specific Execution in Testsnn !.<platform>: In test files, !.<platform> (e.g., !.js, !.lua, !.py, !.r) is used to execute a form directly in the context of the specified target language's runtime.nn```clojuren(fact "identity function works on all platforms"n (!.js (k/identity 1))n => 1nn (!.lua (k/identity 1))n => 1)n```nn### 4. Component-based ArchitecturennThe project extensively uses a component-based architecture for managing application lifecycle and resources.nn std.protocol.component/IComponent: The core protocol for defining components.n component/start, component/stop, component/kill: Standard functions for managing component lifecycle.n std.lib.resource: Provides a registry and management system for various resources.n res:spec-add: Registers a new resource specification.n res:create: Creates a new resource instance.n res:start, res:stop: Manages the lifecycle of registered resources.nn```clojuren(defimpl LuceneSearch [type instance]n :string common/to-stringn :protocols [std.protocol.component/IComponentn :body {-start impl/start-lucenen -stop impl/stop-lucene}])nn(res:spec-addn {:type :hara/lang.libraryn :mode {:allow #{:global}n :default :global}n :instance {:create #'lib/library:createn :start h/startn :stop h/stop}})n```nn### 5. Concurrency and AsynchronicitynnThe std.concurrent and std.lib.future namespaces are used for managing concurrent operations and asynchronous workflows.nn h/future: Creates a CompletableFuture for asynchronous execution.n f/on:complete, f/on:success, f/on:exception: Callbacks for handling future completion, success, or exceptions.n cc/pool: Manages thread pools for concurrent tasks.n cc/submit: Submits tasks to an executor.nn```clojuren(defn submitn "submits a task to an executor"n {:added "3.0"}n ([<sup>ExecutorService</sup> service ^Callable f]n (submit service f nil)))nn(defn ^CompletableFuture on:completen "process both the value and exception"n {:added "3.0"}n ([<sup>CompletableFuture</sup> future f]n (on:complete future f {})))n```nn### 6. Data Structures and TransformationsnnThe std.lib.collection and std.lib.transform namespaces provide utilities for manipulating data structures.nn merge-nested: Recursively merges maps.n tree-nestify: Nests keys in a map based on a separator.n wrap-model-pre-transform, wrap-model-post-transform: Functions for applying transformations in a data processing pipeline.nn```clojuren(defn merge-nestedn "Merges nested values from left to right."n {:added "3.0"}n ([& maps]n (apply merge-with (fn [& args]n (if (every? #(or (map? %) (nil? %)) args)n (apply merge-nested args)n (last args)))n maps)))nn(defn wrap-model-pre-transformn "Applies a function transformation in the :pre-transform step"n {:added "3.0"}n ([f]n (fn [tdata tsch nsv interim fns datasource]n (let [strans (:pre-transform interim)n output (process-transform strans tdata nsv interim tsch datasource)]n (f output tsch nsv (update-in interim [:ref-path]n #(-> %n (pop)n (conj output)))n fns datasource)))))n```nn### 7. Domain-Specific Languages (DSLs)nnThe project defines several internal DSLs for specific domains.nn SQL Generation (script.sql.table.select): Functions like build-query-select, build-query-from, build-query-where are used to construct SQL queries programmatically.n Redis Commands (kmi.redis): Macros like flushdb, zscoremin, zscoremax provide a Clojure-like interface to Redis commands.n QML (hara.lang.model.spec-js.qml): Functions like emit-qml, classify-container are used to generate QML code.nn```clojuren(defn sql:queryn "builds select query"n {:added "3.0"}n ([query]n (sql:query query common/options)))nn(defmacro.lua flushdbn "clears the redis db"n {:added "4.0"}n ([]n (list 'redis.call "FLUSHDB")))nn(defn emit-qmln "emits a qml string"n {:added "4.0"}n [form grammar mopts]n (let [tree (classify form)]n (emit-node tree grammar mopts)))n```nn### 8. Code Generation (code.gen)nnThe code.gen namespace provides tools for generating code from templates.nn gen/template-generator: Creates a function that can generate code from a template file.n gen/generate: Generates code by applying bindings to a template.nn```clojuren(def greeter-template-fnn (gen/template-generator "resources/my/templates/defgreeter.block.clj"))nn(def generated-code-listn (f/template-entries [greeter-template-fn]n greeter-entries))n```nn### 9. Comments and Documentationnn Docstrings: All public functions must have a clear and comprehensive docstring, explaining their purpose, arguments, and return value, along with examples.n Inline Comments: Inline comments (;) should be used sparingly. Use them to explain why a particular piece of code is necessary, especially if the logic is complex. Avoid comments that simply restate what the code is doing.n ^:hidden: Used in docstrings to indicate examples that are not meant to be displayed in generated documentation.nnThis comprehensive style guide aims to capture the essence of the foundation-base project's coding philosophy, promoting consistency, readability, and maintainability across its diverse codebase. By adhering to these guidelines, developers can contribute effectively and ensure the long-term health of the project.n

6    Plan for Constructing definvoke :task Functions

Plan for Constructing definvoke :task FunctionsnnThe definvoke macro, when used with the :task type, defines a structured, executable unit of work within the foundation-base project. It's designed for consistency in task definition, execution, and reporting.nnHere's a breakdown of its components and how to construct similar tasks:nn#### 1. Function Definition and Documentationnn Function Name: Choose a descriptive name for your task function (e.g., docstrings, compile-project).n Docstring: Provide a clear, concise docstring explaining the task's purpose, arguments, and expected return value. Include examples where appropriate.n Metadata: Always include {:added "version"} to track when the task was introduced.nn ```clojuren (definvoke my-new-taskn "A brief description of what this task does.n n (my-new-task \"arg1\" {:option true})n => expected-output"n {:added "X.Y"}n [:task ...])n ```nn#### 2. The :task DefinitionnnThe core of the task is a vector starting with :task, followed by a map containing various configuration keys.nn```clojuren[:task {:template :coden :params {...}n :main {...}n :item {...}n :result {...}}]n```nn#### 3. Key Components of the Task MapnnEach key within the task map configures a specific aspect of the task:nn :template (Required)n Purpose: Specifies a base template for the task, providing default behaviors and structures. Common templates include :code (for code-related tasks), :system, etc.n Value: A keyword representing the template (e.g., :code).n Example: :template :codenn :params (Optional, but highly recommended)n Purpose: Defines parameters for the task's execution, including display options and parallelism.n Keys:n :title (String): A human-readable title for the task, displayed during execution.n :parallel (Boolean): If true, task items will be processed in parallel. Defaults to false.n :print (Map): Controls what output is printed.n :result (Boolean): If true, prints the final result summary.n :summary (Boolean): If true, prints a summary of items processed.n Example:n ```clojuren :params {:title "MY NEW TASK"n :parallel truen :print {:result true :summary false}}n ```nn :main (Required)n Purpose: Defines the primary function or logic that the task will execute. n Keys:n :fn (Var or Function): The actual Clojure function to be invoked. This function typically takes arguments that represent the "items" the task operates on.n Example: :main {:fn #'my.namespace/my-processing-function}nn :item (Optional)n Purpose: Configures how individual items processed by the task are displayed or handled.n Keys:n :display (Function): A function that takes an item and returns a formatted string or data structure for display. Often uses std.lib.template/empty-status for consistent status messages.n Example:n ```clojuren :item {:display (comp (template/empty-status :info :none) vec keys)}n ```nn :result (Optional)n Purpose: Defines how the overall results of the task are aggregated, transformed, and displayed.n Keys:n :keys (Map): A map where keys are desired output keys and values are functions to extract/transform data from the raw task results.n :columns (Vector or Map): Defines how results should be displayed in a tabular format. Can specify columns and their styling (e.g., #{:bold}). Often uses std.lib.template/code-default-columns.n Example:n ```clojuren :result {:keys {:total-items (comp count keys)n :functions (comp vec keys)}n :columns (template/code-default-columns :functions #{:bold})}n ```nn#### 4. Generic TemplatennHere's a generic template you can use as a starting point:nn```clojuren(ns my-project.my-tasksn (:require [std.lib.system.task :refer [definvoke]]n [std.lib.template :as template]n [my-project.core :as core] ; Your core logic namespacen [clojure.string :as str]))nn(definvoke my-new-taskn "A concise description of what this task accomplishes.n n (my-new-task \"some-input\" {:option-key \"value\"})n => expected-output-structure"n {:added "0.1"}n [:task {:template :code ; Or another appropriate template like :systemn :params {:title "MY NEW TASK TITLE"n :parallel true ; Set to false if order matters or items are interdependentn :print {:result true :summary true}}n :main {:fn #'core/my-main-processing-function} ; The function that processes each itemn :item {:display (fn [item] (str "Processing: " item))} ; How to display each itemn :result {:keys {:total-items (comp count :items)n :processed-count (comp count :processed-items)}n :columns (template/code-default-columns :total-items #{:bold})}}])n```nn#### 5. Structure of :main :fn InputnnThe function specified by :main :fn is the core logic that processes each unit of work within the task. Its input signature generally depends on the task's design, but common patterns emerge:nn1. Single Item Processing:n [item]: The most common scenario. The function receives a single item that represents the current unit of work. This item could be a file path, a namespace symbol, a data record, or any other data relevant to the task.nn2. Item with Context/Options:n [item opts]: In more complex tasks, the function might also receive an opts map. This map typically contains:n Task-specific parameters: Any additional configuration or arguments passed to the definvoke task itself.n Runtime context: Information about the overall task execution, such as the current task configuration, shared resources, or other metadata.nnKey Points:nn Arity: The function can have different arities (number of arguments) to handle simpler or more complex processing needs. The task system will attempt to call the appropriate arity.n Item Type: The type of item is entirely dependent on the task's purpose and how the task is designed to feed data to the :main :fn.n Return Value: The :main :fn should return a value that the task system can collect and process further, especially for the :result aggregation.nnExample of a :main :fn signature:nn```clojuren(defn my-processing-functionn "Processes a single item with optional context."n ([item]n ;; Simple processing, no extra context neededn (println "Processing item:" item)n {:processed-item item :status :success})n ([item {:keys [config-param debug-mode] :as opts}]n ;; More complex processing with configurationn (if debug-moden (println "Debug processing item:" item "with config:" config-param))n (if config-paramn {:processed-item item :status :success :config-used config-param}n {:processed-item item :status :failed :reason "No config"})))n```nn#### 6. Key Considerationsnn Dependencies: Ensure you require necessary namespaces, especially std.lib.system.task for definvoke and std.lib.template for display utilities.n Main Function (:main :fn): The function referenced here should be designed to process a single "item" or a collection of items, depending on whether :parallel is true and how the task is invoked.n Result Transformation: The :result :keys and :result :columns are powerful for customizing the final output report, making it easy to understand the task's outcome.n* Error Handling: The underlying functions (:main :fn) should ideally handle errors gracefully, or the task system will report exceptions.nnBy following this structure, you can create consistent and well-defined tasks within the foundation-base project.

7    Testing Style Guide for foundation-base

Testing Style Guide for foundation-basennThis guide outlines the conventions and best practices for writing tests in the foundation-base project, based on the existing test suite.nn### 1. File and Namespace Namingnn Test Files: Test files should mirror the namespace of the code they are testing, with -test appended to the file name.n Example: The tests for std.lib.collection are in test/std/lib/collection_test.clj.nn Test Namespaces: Test namespaces should follow the same pattern as the file names, with _test appended to the namespace.n Example: std.lib.collection-testnn### 2. The code.test FrameworknnAll tests in the foundation-base project are written using the code.test framework. This framework provides a set of macros and functions for defining, running, and asserting the behavior of your code.nn#### 2.1. Test Structurenn fact Macro: The primary macro for defining tests is fact. Each fact should test a single, specific piece of functionality.nn ^{:refer ...} Metadata: The Cornerstone of Testabilitynn It is mandatory for every fact to have ^{:refer ...} metadata. This metadata links the test directly to the function it is testing. This is a crucial feature of the code.test framework for several reasons:nn Traceability: It provides a clear and explicit link between a test and the code it is testing, making it easy to understand what each test is for.n Code Coverage: It allows for accurate tracking of test coverage, ensuring that all public functions are tested.n Maintainability: When a function is changed or refactored, it is easy to find the corresponding tests and update them accordingly.nn ```clojuren (ns std.lib.collection-testn (:use code.test)n (:require [std.lib.collection :as c]))n n ^{:refer std.lib.collection/map-keys :added "3.0"}n (fact "changes the keys of a map"n (c/map-keys inc {0 :a 1 :b 2 :c})n => {1 :a, 2 :b, 3 :c})n ```nn#### 2.2. Scaffoldingnn fact:global: Use fact:global to define setup and teardown logic that should run before and after all tests in a namespace. This is the primary mechanism for scaffolding test environments.nn Fact-level Scaffolding: For more granular control, you can use the :setup and :teardown keys within the fact metadata to define setup and teardown logic for a single fact.nn ```clojuren ^{:refer std.lib.collection/map-keys :added "3.0"n :setup [(println "Setting up fact")]n :teardown [(println "Tearing down fact")]}n (fact "demonstrates fact-level setup and teardown"n (+ 1 1) => 2)n ```nn Component Management: fact:global is also used to manage test components, such as starting and stopping servers, clients, and other resources.nn Reusing Scaffolding: The :setup [(fact:global :setup)] pattern is used to inherit and extend the setup logic from a more general fact:global definition. This is particularly useful for creating complex scaffolding setups.nn#### 2.3. Assertionsnn => Operator: The => operator is used for assertions. The left side is the expression to be tested, and the right side is the expected result.n throws: To assert that an expression throws an exception, use => (throws).n Checkers: The code.test.checker.common namespace provides a set of checkers for more complex assertions.nn```clojuren(fact "demonstrates various assertions"n (+ 1 1) => 2nn (some? nil) => false?nn (throw (Exception. "error")) => (throws))n```nn#### 2.4. Advanced Featuresnn fact:let: Allows for running a test with different bindings, making it easy to test a function with various inputs.nn```clojuren(fact:template "a template for testing addition"n (fact:let [[a b c] [1 2 3]]n (+ a b) => c))n```nn fact:derive: Creates a new test that inherits the setup and teardown logic from another test.nn fact:template: Defines a test that can be used as a template for other tests.nn fact:check: A macro for property-based testing, allowing you to test a function with a range of generated inputs.nn fact:bench: A macro for running micro-benchmarks on your code.nn#### 2.5. Running Testsnn executive/run-namespace: Runs all tests in a given namespace.n executive/run-current: Runs all tests in the current namespace.nn#### 2.6. Debugging Testsnn print/print-failure: Prints a detailed report of a test failure.n print/print-thrown: Prints a detailed report of an exception that was thrown during a test.nn### 3. Cross-Platform Testing with hara.langnnThe foundation-base project uses a custom DSL provided by hara.lang for writing code that can be compiled to multiple platforms (e.g., JavaScript, Lua). This DSL is also used for writing cross-platform tests.nn l/script-: Use the l/script- macro to define platform-specific code and dependencies for your tests. You can have multiple l/script- blocks in a single test file, one for each platform you want to test against.nn !.<platform>: Use the !.<platform> macro to execute a form on a specific platform. This allows you to write a single test that runs the same code on the JVM, in JavaScript, and in Lua, and asserts that the results are the same.nn```clojuren(ns xt.lang.base-lib-testn (:use code.test)n (:require [hara.lang :as l]n [std.lib :as h]))nn(l/script- :jsn {:runtime :basicn :require [[xt.lang.base-lib :as k]]})nn(l/script- :luan {:runtime :basicn :require [[xt.lang.base-lib :as k]]})nn(fact "identity function works on all platforms"n (!.js (k/identity 1))n => 1nn (!.lua (k/identity 1))n => 1)n```nn### 4. Best Practicesnn Always use ^{:refer ...}: Every fact must have ^{:refer ...} metadata to link it to the function it is testing.n Keep tests small and focused: Each fact should test a single, specific piece of functionality.n Use descriptive names for tests: The description of a fact should clearly explain what the test is doing.n Write tests for all new code: All new features, bug fixes, and refactorings should be accompanied by tests.n Run tests often: Run your tests frequently to catch regressions early.nnBy following these conventions, you will ensure that your tests are consistent with the rest of the project, easy to read, and easy to maintain.n

8    Agent Main Workflow

Agent Main WorkflownnThis document outlines the main workflow for an AI agent performing software development tasks within the foundation-base ecosystem. The workflow is designed to leverage the powerful code analysis, manipulation, and execution libraries available in the project.nn## 1. Understand the RequestnnThe first step is to parse and understand the user's request. This involves identifying the user's intent (e.g., add a feature, fix a bug, refactor code), the relevant files or modules, and any constraints.nn## 2. Code and Documentation SearchnnTo gather context, the agent should use the code.query library to search for relevant code and documentation.nn Tool: code.queryn Key Functions:n code.query.match/p-pattern: To search for code structures that match a specific pattern.n code.query.match/p-form: To find forms with a specific function call.n code.query.walk/matchwalk: To traverse the code and find all occurrences of a pattern.nnExample: To find all functions related to "user authentication", the agent could search for patterns like (defn authenticate-user ...) or forms that call login.nn## 3. Analysis and PlanningnnBased on the search results, the agent should analyze the existing codebase and formulate a plan for implementing the requested changes. This may involve:nn Identifying the files that need to be modified.n Determining the scope of the changes.n Planning the implementation steps, including any new functions or components that need to be created.nnThe code.query.walk and code.query.traverse functions can be used to analyze the Abstract Syntax Tree (AST) of the code and understand its structure in detail.nn## 4. ImplementationnnThe agent can implement the changes using a combination of code.query for code transformation and standard file I/O.nn For complex code transformations: Use code.query.walk/matchwalk or code.query.traverse/traverse to programmatically modify the code's AST and then write the changes back to the file.n For simpler changes: Use standard file read/write operations.n For multi-language tasks: Leverage xt.lang to call functions and manipulate code across different languages (e.g., Clojure, Javascript, Lua).nn## 5. TestingnnTesting is a crucial part of the workflow. The agent must write and run tests to verify that the changes are correct and do not introduce any regressions.nn### Test FormatnnThe project uses a custom testing framework based on code.test. Tests are organized in fact blocks.nn File Naming: Test files must follow the *_test.clj naming convention.n fact Macro: Each test case is defined within a (fact ...) block.n Assertions: Assertions are made using the => operator.n Metadata: Each fact should be annotated with ^{:refer ...} metadata to link it to the function being tested.nn### Example Testnn```clojuren(ns my-awesome-feature-testn (:use code.test)n (:require [my-awesome-feature :as awesome]))nn<sup>{:refer</sup> my-awesome-feature/do-something-cool :added "1.0"}n(fact "checks if do-something-cool returns the correct value"n (awesome/do-something-cool) => "cool-value")n```nn### Running TestsnnThe agent should run all relevant tests after making changes. The exact command for running tests will depend on the project's setup, but it is typically a command like lein test or a similar command provided by the project's build tool.nn## 6. Task Execution and ReportingnnThe entire workflow can be encapsulated within a std.task. This allows for:nn Structured Execution: Defining the workflow as a series of steps.n Logging and Reporting: Using std.task.bulk to provide detailed reports on the outcome of the task, including successes, failures, and warnings.n Parallelism: Running parts of the workflow in parallel (e.g., running tests for different modules simultaneously).nnBy following this workflow, the agent can perform complex software development tasks in a structured, reliable, and efficient manner, making full use of the powerful tools provided by the foundation-base project.n

9    Consolidated documentation manifest

Consolidated documentation manifestnnThe former guides/ and plans/slop/ sources are retained verbatim in the authored documentation pages listed below.nn## src-doc/documentation/code/code_manage.cljnn- guides/code.manage.mdnn## src-doc/documentation/code/code_query.cljnn- guides/code.query.mdn- plans/slop/summary/code_query_block_tutorial.mdn- plans/slop/summary/code_query_common_tutorial.mdn- plans/slop/summary/code_query_compile_tutorial.mdn- plans/slop/summary/code_query_match_tutorial.mdn- plans/slop/summary/code_query_summary.mdn- plans/slop/summary/code_query_traverse_tutorial.mdn- plans/slop/summary/code_query_walk_tutorial.mdnn## src-doc/documentation/code/code_test.cljnn- guides/code.test.mdnn## src-doc/documentation/foundation_code_guides.cljnn- plans/slop/summary/documentation_helper.mdnn## src-doc/documentation/hara/hara_model.cljnn- guides/MANAGE_XTALK.mdn- plans/slop/deftype_pg_usage.mdn- plans/slop/doc_pg.mdnn## src-doc/documentation/hara/hara_runtime.cljnn- plans/slop/summary/rt_postgres_summary.mdnn## src-doc/documentation/main_contributing.cljnn- plans/slop/top-level/CLJ_LINTING_PLAN.mdn- plans/slop/top-level/FUNCTION_DESIGN_GUIDE.mdn- plans/slop/top-level/STYLE_GUIDE.mdn- plans/slop/top-level/TASK_CONSTRUCTION_GUIDE.mdn- plans/slop/top-level/TESTING_STYLE_GUIDE.mdn- plans/slop/top-level/main_workflow.mdnn## src-doc/documentation/std/lib_index.cljnn- plans/slop/summary/std_lib_context_pointer_summary.mdn- plans/slop/summary/std_lib_context_registry_summary.mdn- plans/slop/summary/std_lib_context_space_summary.mdn- plans/slop/summary/std_lib_context_summary.mdn- plans/slop/summary/std_lib_deps_summary.mdn- plans/slop/summary/std_lib_diff_seq_summary.mdn- plans/slop/summary/std_lib_diff_summary.mdn- plans/slop/summary/std_lib_extend_summary.mdn- plans/slop/summary/std_lib_function_summary.mdn- plans/slop/summary/std_lib_generate_summary.mdn- plans/slop/summary/std_lib_impl_summary.mdn- plans/slop/summary/std_lib_invoke_summary.mdn- plans/slop/summary/std_lib_link_summary.mdn- plans/slop/summary/std_lib_memoize_summary.mdn- plans/slop/summary/std_lib_mustache_summary.mdn- plans/slop/summary/std_lib_mutable_summary.mdn- plans/slop/summary/std_lib_origin_summary.mdn- plans/slop/summary/std_lib_os_summary.mdn- plans/slop/summary/std_lib_protocol_summary.mdn- plans/slop/summary/std_lib_result_summary.mdn- plans/slop/summary/std_lib_return_summary.mdn- plans/slop/summary/std_lib_signal_summary.mdn- plans/slop/summary/std_lib_template_summary.mdn- plans/slop/summary/std_lib_trace_summary.mdn- plans/slop/summary/std_lib_version_summary.mdn- plans/slop/summary/std_lib_watch_summary.mdnn## src-doc/documentation/std/std_block.cljnn- guides/std.block.mdn- plans/slop/summary/std_block_base_tutorial.mdn- plans/slop/summary/std_block_check_tutorial.mdn- plans/slop/summary/std_block_construct_tutorial.mdn- plans/slop/summary/std_block_grid_tutorial.mdn- plans/slop/summary/std_block_parse_tutorial.mdn- plans/slop/summary/std_block_reader_tutorial.mdn- plans/slop/summary/std_block_summary.mdn- plans/slop/summary/std_block_type_tutorial.mdn- plans/slop/summary/std_block_value_tutorial.mdnn## src-doc/documentation/std/std_concurrent.cljnn- plans/slop/summary/std_concurrent_summary.mdnn## src-doc/documentation/std/std_dispatch.cljnn- guides/DISPATCH_STRATEGIES.mdn- plans/slop/summary/std_dispatch_summary.mdnn## src-doc/documentation/std/std_fs.cljnn- plans/slop/summary/std_fs_summary.mdnn## src-doc/documentation/std/std_index.cljnn- plans/slop/summary/std_config_summary.mdn- plans/slop/summary/std_contract_summary.mdn- plans/slop/summary/std_dom_summary.mdn- plans/slop/summary/std_html_summary.mdn- plans/slop/summary/std_image_summary.mdn- plans/slop/summary/std_json_summary.mdn- plans/slop/summary/std_lib_recommendations.mdn- plans/slop/summary/std_lib_summary.mdn- plans/slop/summary/std_log_summary.mdn- plans/slop/summary/std_make_summary.mdn- plans/slop/summary/std_math_summary.mdn- plans/slop/summary/std_object_summary.mdn- plans/slop/summary/std_pretty_summary.mdn- plans/slop/summary/std_print_summary.mdn- plans/slop/summary/std_protocol_summary.mdn- plans/slop/summary/std_text_summary.mdnn## src-doc/documentation/std/std_lib_apply.cljnn- plans/slop/summary/std_lib_apply_summary.mdnn## src-doc/documentation/std/std_lib_atom.cljnn- plans/slop/summary/std_lib_atom_summary.mdnn## src-doc/documentation/std/std_lib_bin.cljnn- plans/slop/summary/std_lib_bin_summary.mdnn## src-doc/documentation/std/std_lib_class.cljnn- plans/slop/summary/std_lib_class_summary.mdnn## src-doc/documentation/std/std_lib_collection.cljnn- plans/slop/summary/std_lib_collection_summary.mdnn## src-doc/documentation/std/std_lib_component.cljnn- plans/slop/summary/std_lib_component_summary.mdnn## src-doc/documentation/std/std_lib_encode.cljnn- plans/slop/summary/std_lib_encode_summary.mdnn## src-doc/documentation/std/std_lib_enum.cljnn- plans/slop/summary/std_lib_enum_summary.mdnn## src-doc/documentation/std/std_lib_env.cljnn- plans/slop/summary/std_lib_env_summary.mdnn## src-doc/documentation/std/std_lib_foundation.cljnn- plans/slop/summary/std_lib_foundation_recommendations.mdn- plans/slop/summary/std_lib_foundation_summary.mdnn## src-doc/documentation/std/std_lib_future.cljnn- plans/slop/summary/std_lib_future_summary.mdnn## src-doc/documentation/std/std_lib_io.cljnn- plans/slop/summary/std_lib_io_summary.mdnn## src-doc/documentation/std/std_lib_network.cljnn- plans/slop/summary/std_lib_network_summary.mdnn## src-doc/documentation/std/std_lib_resource.cljnn- plans/slop/summary/std_lib_resource_summary.mdnn## src-doc/documentation/std/std_lib_schema.cljnn- plans/slop/summary/std_lib_schema_summary.mdnn## src-doc/documentation/std/std_lib_security.cljnn- plans/slop/summary/std_lib_security_summary.mdnn## src-doc/documentation/std/std_lib_sort.cljnn- plans/slop/summary/std_lib_sort_summary.mdnn## src-doc/documentation/std/std_lib_stream.cljnn- plans/slop/summary/std_lib_stream_summary.mdnn## src-doc/documentation/std/std_lib_system.cljnn- plans/slop/summary/std_lib_system_summary.mdnn## src-doc/documentation/std/std_lib_time.cljnn- plans/slop/summary/std_lib_time_summary.mdnn## src-doc/documentation/std/std_lib_transform.cljnn- plans/slop/summary/std_lib_transform_summary.mdnn## src-doc/documentation/std/std_lib_walk.cljnn- plans/slop/summary/std_lib_walk_summary.mdnn## src-doc/documentation/std/std_lib_zip.cljnn- plans/slop/summary/std_lib_zip_summary.mdnn## src-doc/documentation/std/std_scheduler.cljnn- guides/std.scheduler.mdn- plans/slop/summary/std_scheduler_summary.mdnn## src-doc/documentation/std/std_string.cljnn- plans/slop/summary/std_string_summary.mdnn## src-doc/documentation/std/std_task.cljnn- guides/std.task.mdn- plans/slop/summary/std_task_summary.mdnn## src-doc/documentation/std/std_time.cljnn- plans/slop/summary/std_time_summary.mdnn## src-doc/documentation/std/std_timeseries.cljnn- guides/std.timeseries.mdn- plans/slop/summary/std_timeseries_summary.mdnn## src-doc/documentation/std_lang_introduction.cljnn- plans/slop/summary/std_lang_base_book_summary.mdn- plans/slop/summary/std_lang_base_emit_summary.mdn- plans/slop/summary/std_lang_base_grammar_summary.mdn- plans/slop/summary/std_lang_base_runtime_summary.mdn- plans/slop/summary/std_lang_base_script_summary.mdn- plans/slop/summary/std_lang_summary.mdnn## src-doc/documentation/xt/xt_lang.cljnn- plans/slop/summary/xt_lang_base_lib_recommendations.mdn- plans/slop/summary/xt_lang_summary.mdn