
TODO: TODO_08_94_42_96: split these todos into separate items or remove them

Tags:
*   FINALIZE: The feature already works but needs coverage, small qualitative improvements, documentation.
*   CLOSED: The issue is done or being tracked otherwise = no need to keep this todo, but still kept to keep in the view.
*   REGISTER: The item is not yet registered, requires new feature story (FS) entry.
*   USER_VISIBLE: Something what is visible to user (rather than just making things better).
*   DEV_VISIBLE: Something what is visible to dev (may not be visible for users as USER_VISIBLE, but helps dev).

Integration:

*   Review all locations where `.argrelay.conf.d` is mentioned - it is likely that `@/conf` has to be used there instead.
    FINALIZE

GUI bits:

*   When there is no common prefix, Tab should not work, flash command line with red color.
    REGISTER

*   When there is no common prefix, Tab should not work (do not replace current token).
    REGISTER

*   Be able to enable verbose server logging and disable it via GUI.
    Basically, this is debug flag, but set on GUI client (via GUI), not CLI client (via env var).
    REGISTER

*   Test with lots of data - run same tests against server with lots of data.
    Are there any issues with races between user input and server response?
    FINALIZE

*   Handle `help` response differently in GUI - print help.
    REGISTER

Conceptual:

*   Instead of providing positional parameter list for test cases (see those with subTests),
    introduce generic ResultAssertBuilder (or something like that) which can build expectations in any order.
    REGISTER

*   Establish some clear order for:
    *   `init_control`
    *   `search_control`
    *   `fill_control`
    *   `invoke_control`
    And how they affect `args_context`.
    REGISTER

    Plan (TODO: merge this plan with "how search works"):
    *   Implement constant number of searches (S) per `data_envelope` required:
        1. S1: Implement query of unique values at the start of the new `data_envelope` search.
        2. Consume all args after "enum search" per `data_envelope` because no other narrowed down search for this envelope can help to consume more `arg_value`-s (enum sets will only narrow down).
        3. S2: How do we call the process (to be controlled as `*_control`) when we assign implicit values? Populate singled out. This requires search for data envelopes before defaults assigned.
        4. Implement `fill_control` to provide default values.
        5. S3: Last search is to see if default values singled out envelope (or more values) - these can be colored separately from singled-out (as they singled out by defaults).
    REGISTER
    *   Try to reduce number of search requests (e.g.) file it as known issue to fix.
        REGISTER

    *   Explain mental model:
        *   Interpreter searches specific `data_envelope`-s of specific `envelope_class`.
        *   The search continues by narrowing down candidate list to one or none.
        *   If found, the search switches to next `envelope_class`.
        *   What context (list of type-value-source) is transferred from previous
            object type search to the next one is up to interpreter.

    TODO: document with examples (on how search works) for each step:
    *   TODO: `search_control`
    *   TODO: `init_control`
    *   TODO: `fill_control`
    *   TODO: `invoke_control`
    REGISTER

    ALSO:
    *   `init_control` sets values which are ensured non-overridable (by placing `arg_value` consumable to replace default).
    *   `fill_control` sets exactly the default values (when none are selected).
    Therefore, there are several views at remaining values generated at different stages:
    *    full enum set (after `init_control` is applied) - it is actually not full because `init_control` is already effective.
    *    pre-default remaining values
    *    post-default remaining values
    Full enum set is used to see if command line value can be consumed.
    Pre-default remaining values are needed to provide description (options available to override defaults).
    Post-default remaining values are those used to suggest auto-completion (and show description what is reduced by defaults).
    TODO: Basically, it is nice to compute a diff between pre and post and show it in the describe output.
    REGISTER

*   Document search logic.
    REGISTER

*   Document integration logic.
    REGISTER

Ease integration into external project:

*   There is constant need to distinguish (TODO: name it properly):
    *   argrelay_target_dir - the path to special dir (where venv is configured via relative path, artifacts generated, config files, etc.)
    *   argrelay_distrib_dir - the path to useful artifacts (where known after venv is sourced)
    TODO: Is this still a problem?
          Yes.
          *   `argrelay_inst_dir` must be the project (where `argrelay` is used itself, or where it is installed).
          *   Anything else like `argrelay_module_dir_path` obtained by running Python is package_dir
    See also: FS_29_54_67_86.dir_structure.md
    FINALIZE

*   Make yaml config composable:
    *   reduce size and chances of merging unrelated parts
    *   avoid config modification by loading other parts from known (by convention) places
    *   allow loading external config which should plug itself into existing config
    Maybe it should be possible to provide just the list of configured plugins (their loading order)
    and they will load automatically from expected location?
    Also split core server config (open ports, mongo, cache) and plugin management.
    See also: FS_83_23_99_90 client plugin config override.
    REGISTER

*   Make Git plugin a bit more useful (e.g. in addition to loading commit data, be able to switch to pre-configured Git repos).
    Use `help_hint` (FS_71_87_33_52) for selection of the repo.
    FINALIZE

*   Think of integration with `tmux` specifically, or other ways to open new shell windows in general.
    Use `tmux` integration (built-in optional feature).
    REGISTER

Extra:

*   Add version `prop_name` to the test data.
    See `TD_63_37_05_36.demo_services_data.md` - it does not have source version or source tag.
    REGISTER

*   Add test coverage reporting.
    It could be a result of `@/exe/run_max_tests.bash` or `tox`.
    REGISTER

*   Check start of mongo db server by client connection (instead of delay).
    Based on answers to this SO, there are many ways and all non-standard:
    https://stackoverflow.com/q/5091624/441652
    Simply allow to configure command to check for mongo db status
    (it could be different commands based on target system).
    Use return code: 0 = server started, 1 = wait, anything else = failure (stop).
    REGISTER

