Product Backlog

LLMs can be useful when learning a new subject as they can provide additional context to the information displayed in the screen. For example, a user can ask the LLM to explain a graph or a table. It would probably be fairly straight forward to allow dumping some of the information in a format that is friendly to LLMs (.e.g./ PNG, Markdown, plain text) and then make an API call to a local or remote LLM. We could probably create a set of useful canned prompts (explain this report, explain this chart).

On a more blue skies approach, one could conceive asking the LLM for suggestions on how to act, on the basis of the analysis. This could result in suggestions for action the user could implement, or even on actions directly taken based on the LLM's suggestions. This is conceptually straightforward: the LLM could for example generate a well defined JSON with the proposed action, and the system would look for some predefined markers in the LLM output:

----- ACTION START
<JSON>
----- ACTION END

The JSON payload would describe the action:

{
    "action": "some_action_type",
    "key1": "value1",
    ....

A trivial lookup table could de-serialise the JSON and execute the action. All that is required is for the LLM to "learn" how to generate JSON compliant with the desired format, which should be quite straightforward (perhaps with the help of fine-tuning). Agents probably provide most of this infrastructure already. The key thing is to ensure all functionality in the core becomes UI agnostic such that one could bolt an NLP UI around it.

Links:

• How-to guides: Prompting
• Practical Techniques to constraint LLM output in JSON format

Much like with an IDE, where one can have multiple toolchains configured, we need to also support multiple versions of ORE. Unlike with IDEs, it may be desirable to run computations with more than one version of ORE for comparison purposes. This means we need a way to associate outputs with their ORE version. This approach does not necessarily fit the existing example code, because these have a single "output directory". However, we just need way to associate N toolchains with a given workspace or possibly component; when present, the output directory starts to reflect the toolchain configuration. For example, with CMake we use presets:

• linux-clang-debug
• linux-clang-release
• linux-gcc-debug
• linux-gcc-release

For ORE the only dimension under which variability is possible is the version. We can then have pricing engine configurations that are either the same, or possibly different:

• for a workspace;
• for a component;
• for a toolchain version.

vcpkg will support faker soon:

• #38583: [faker-cxx] add new port

When that is available, we should try to add support for it.

Copy the BOINC data model.

Links:

• wiki: DataBase
• BOINC Debian Server Guide
• wiki: BOINC Project Main
• BOINC reddit

We need to create fake data so we can explore the problem domain. This is something to work on in the future. We can use LLMs to help with the fake data, where it makes sense.

Example: