Library to execute a set of commands

These tests are more or less always true (fail if an exception).
Their value are to catch knowledge on how to use commands.
And be able to watch bb log to check if results are as expected

Proxy to deps.edn file

Edn file manipulation

Operating enviroment variables

Tools to manipulate local files
Is a proxy to babashka.fs tools

Adapter to java properties

Adapter to regular expressions
Seamless access to regular expressions between cljs and clj
Managing both back and frontend to have a seamless experience

Validate the data against the schema.
Is a proxy for malli

String manipulation usable both in clj and cljs

Adapter to time functions.

Like formatting the date from #inst to str and way back
Will be a proxy for `clojure.instant`, `java.text.SimpleDateFormt`

Version of an application

Adapter to `build_config.edn`

Configuration parameters, stored in configuration file.
 This namespace is the entry point to call conf

Design decision:
* Configuration used to be based on outpace, it was too complicated for a small benefit,
* The `config.edn` file was first unique, it needs to be updatable by environment to allow different
value between production and repl, test and dev, but also monorepo vs app
* The different version of parameter `config.edn` was first based on classpath (differentitated
with aliases). It is ok for one app, but it renders the monrepo build complicated as it was naturally
gathering all classpath, so all `config.edn` versions. The solution was to be based on environment
parameter. So each alias can tell which version it uses, especially monorepo could be different.

Get environment data stored in the configuration

Namespace for simple configuration based on local file.
Just like in core configuration, we are not using log nor outside dependencies to comply with the configuration requirements.

Used to init test environment

Will be `refer :all` in the subproject `user` namespace, default namepsace for subproject REPL

Linter doesn't detect that all that functions are callable from the user namespace of the repl.

Namespace for http requests

Dictionary for translation of text in automaton-core

Is empty right now but will contain all translation factorized for all applications

All known languages in `automaton-core`, subsequent namespaces are forced to use only known languages there.
Language concept could be enriched with language definition or other data, for instance, the flag of a language, ...

It is only a place for language description, not to tell where it is supposed to be used
See cust-app themselves to know what language they use

Helper functions to test correctness of translation data including dictionaries

Protocol for translation logic

Implementation of `automaton-core.i18n.translator/Translator` protocol with [tempura](https://github.com/taoensso/tempura)

Is an adapter for translation in `automaton-core`, so no web related technology is mentionned there, even if tempura provides them.
It will be the job of `automton-web` to provide that features

Main entrypoint to automaton core logging, defines basic levels that we use to log.

Logical order of logs is:
trace -> debug -> info -> warn -> error -> fatal

Design decision:
* the log is relying on configuration namespace, so nothing will be logged before that
* the log api is hosted in a `cljc` file so log is accessible to namespaces in cljc
   * Rationle:
      * deciding to push code in cljc should not prevent to log
      * postponing the decision to host code in frontend or backend is an objective
   * Consequence:
      * This namespace is the entrypoint for both clj and cljs implementations

This namespace works as a backend proxy for chosing the logging implementation.
Macros in this namespace to log are chosen from `automaton-core.log`.
Current structure is generic for logging level, as they are the same right now in sense of this proxy.
In future it may develop if needed to e.g. have the same number of macros as in `automaton-core.log`.

List of all known backend strategies

Factory generating log function

List of all known frontend strategies

It's a simple redirection to clojure tools logging
Set to log4j2 [check setup in](clojure/deps.edn)

For more information read docs/tutorial/logging.md

Simple print namespace, most likely used just temporarily.
trace -> debug -> info -> warn -> error -> fatal

Defines the possible log levels and their sequence

List all known strategies

Strategy to choose what logger is used where and when

Base strategy to statically define which logger to use

This strategy is a static one, it means it is applied at the compile time, so:
* Any evolution of that strategy requires a new deployment.
* All drop logs are not time consuming (except if the caller line makes some computation - which is the responsability of the caller)
* All selected lines could then decide on runtime if there are needed or not. For instance log4j2 logger could use its own parameters to update dynamically which one is used or not

See `automaton-core.log.strategy.static-ns-level/ns-rules` for rule definition details 

Backend monitoring live exceptions for remote enviroments (e.g. production, local acceptance, global acceptance).

Sentry backend implementation

Automaton web monitoring live exceptions for remote enviroments (e.g. production, local acceptance, global acceptance).

Sentry frontend logging.

Format code
Proxy to [zprint](https://github.com/kkinnear/zprint)

Common setup for portal

Portal server starting

Test registry elements for binary relation properties

Test registry for a protocol.

See ADR-0015

REPL component. Could be used remotely to connect on production or locally to connect a development environment

Design decision:
* This REPL is available in `automaton-core.repl` for enabling the repl for local acceptance and production
* This namespace rely on `automaton-core.configuration`, which means no log could be done before configuration is loaded

REPL entry point

Entrypoint to storage

Implementation of storage protocols in datomic

Contains datomic schema

Datomic utility functions

Protocol namespace defining what is required from persistent storage implementation.

Url management
See [lambdaisland.uri](https://cljdoc.org/d/lambdaisland/uri/1.15.125/doc/readme) for useful functions
And see the [RFC](https://www.ietf.org/rfc/rfc3986.txt) for references

Usefull datalog queries to be used with access protocol functions

Account access entrypoint functions.

Contains all schema related to user accounts

Utility function for date management

Fallback utilties

Utility functions for keywords.

Utility for map data structure

Gathers functions related to pretty printing or pretty formatting.

Manipulation of sequences

Transform a string into an id
That id are currently used and tested for React

Force arguments to comply to a protocol

Design decision
* Arguments typed can be asserted
   * Rationale:
       * By default functional programming does not require typing of arguments. But the assembly of many different components may lead to difficult debugging, as the failing will occur deep in the call stack. Without a good understanding of the implementation, the error's understanding may be difficult. So the solution is to assert the arguments type.
       * This is concept usually used in Object Oriented Programming, but Hephaistox believes OOP's principle are useful, the point is to apply it where we need it, and not everywhere as most of the OOP language requires.
       * We believe our components assembly solutions will need these assertion to robustify the code and accelerate the development cycle
   * Consequences:
      * the asserts functions below should be called by the implementations build function
      * if the argment is not compliant, it is explicitly refused and the build function returns nil
   * Limit
      * The assert is time consuming during optimization phase. So it is done only on development environment, through a macro mechanism which is skipping that assertion implementation
      * The `this` argument of a `defrecord` (i.e. the first argument) couldn't be tested in the implementation as clojure needs a valid object to be able to call the method on it.
      * As described below, this mechanism if implemented for clojure compiler only

  * Assert-protocol is not implemented on clojurescript
   * Rationale: The solution is based on `extends?` which is not compatible with clojurescript as for now (cf. [clojurescript doc](https://clojurescript.org/about/differences#_protocol))
   * Consequence:
       * This tests will only be checked during clojure test, which is not an issue if that assemblies are done in cljc side
       * All assert will return true on clojurescript
       * The `assert-protocol` function has a `:unused-binding` flag to prevent kondo warnings

Generate uuid, is a proxy to `http://danlentz.github.io/clj-uuid/`