AI-assisted schema editing handling of references

[Logende]

In AI-assisted schema editing it is possible to select an element of the schema and only use the AI-assistance on this sub-schema to edit it. Then only the sub-schema is sent to LLM too. However, if the LLM comes up with new $defs, it will put it into this sub-schema too, not knowing there is more to the schema than this. For this case we need a utility, which detects whether the sub-schema got a $defs or definitions field generated and extracts it into the overall schema root, avoiding duplication and adjusting the name in case of duplication (e.g., by a numerical suffix which is counting up). After extraction of this definition, the new path of the definition must be known (if using the existing function to add new definitions, which already has duplication handling, it returns a Path element as return object). In the generated/edited sub-schema then all $ref to the old definitions path must be updated with the new one, based on where the definition was moved to.

[Logende]

For Schema modification requests, the utility file meta_configurator/src/utility/ai/aiEndpoint.ts is used.

The panel responsible for JSON Schema modifications via AI prompts is meta_configurator/src/components/panels/ai-prompts/AiPromptsSchema.vue. This panel extends the AiPromptsTemplate.vue. The relevant logic for you will probably happen in
meta_configurator/src/components/panels/ai-prompts/AiPromptsTemplate.vue

For example, the function in line 198 applies changes to the data/schema to a given path based on the AI response:

function processResult(
  response: string,
  validJson: boolean,
  responseObject: any,
  pathForResponse: Path
) {
  if (validJson) {
    // if the response is valid, it is applied directly
    newDocument.value = '';
    data.setDataAt(pathForResponse, responseObject);
  } else {
    // otherwise, the invalid response is shown to the user, who can try to figure out what went wrong and fix it
    newDocument.value = response;
    newDocumentPath.value = pathForResponse;
  }
}

Possibly here have a check the data.mode whether it is schema mode. If this is the case, then check if the path is not the root path (not []). If both conditions are met, this means the AI response is applied to a sub-schema.
Now write a separate function which handles the definitions post-processing (called for example postProcessSchemaModification) and detects whether the responseObject is an object and contains the key $defs or definitions. If it does, then step by step extract all the definitions into the root schema definitions. For reference on how this can be done and which existing functions we have, see meta_configurator/src/schema/schemaManipulationUtils.ts, which already has logic to detect whether definition with same name or content already exists, etc.

[Logende]

One more idea:

On schema modification AI prompts, before sending the sub-schema to modify to the LLM, import all definitions into this sub-schema, so the LLM knows which definitions already exist. However, if there exist many many definitions, it might be too much. Therefore, the following idea:

1. include all definitions in the sub-schema, which the sub-schema uses (e.g., we want to modify the Person sub-schema which already has a reference to address, then move the address definition into the person sub-schema)
2. have some configurable settings parameter/threshold of how much character count of unrelated definitions to also send to the LLM. For example a limit of 400 (arbitrary example) characters -> if the definitions do not exceed this number, include them also in the request, otherwise do not