Explainer and Workaround for missing abstract base class and cross-file utilization problem.

What feature would you like to see?

Description

What type of probem is happening?

Whenever codex has codebase with multiple files that has import or include directives (especially with C++, Qt + QML, and other languages too), codex tends to write code unaware of the functions or methods that are being imported by those other files and tends to write code and then re-invent the wheel as it goes. This results in codex not reusing existing code and instead trying to cram all of the helpers and functionality into a single file. As a result, codex spends a ton of time generating code that already exists.

How does this problem get resolved?

Codex should first create an internal index of methods or functions that are being imported and a brief sentence about their uses, parameters, or functionality, then when generating code, it should prioritize those functions over writing new ones if its possible to convert the existing implementation's data structures into code that fits the parameters of the already-written function.

Instead of trying to generate the entire implementation, it should first make an index or database of functions needed to fulfill the user request. Then, of those functions, , then loop through that list of imported / project functions that have not been imported but exist in the directory via the internal function database and use the small description of each function and compare it with the description of the functions needed -- if an equivalent function exists or one that has a similar operation with slightly different parameters, the codex will prompt or add import / include statements when necessary and attempt to re-use those functions by creating instances or whatever has to be done.

This can be extended to include things like abstract base classes and their methods, properties, and events. Could even store the type of implementation that each file contains so if its an inheritable class, then codex might do something like create an instance of that object or when it makes a new class definition it would inherit that class type in order to incorporate the existing features provided that it would not change the fundamental structure of the class definition.

This could be another option or feature that could be parsed out from AGENTS.md -- something like
multiple inheritance behavior, code reusing behavior, and size / complexity of internal database of project methods so that users can control to what end codex will build and track functions that exist in the codebase but not in the specific file as it would add to the context window.

Additional information

Steps to reproduce

Below you will find the necessary file structure to setup and reproduce the exact same lack of imported function tracking.

You can clearly see this missing feature by implementing the code below.

AbstractElement.qml

```import QtQuick 2.0

/ this is defined as a square already below /

Rectangle {
id: root

x: 0;
y: 0;
width: 50;
height: 50;

/* function to provide the moveTo(x,y) function for all AbstractElements created

• (this is completely ignored by codex when it generates code) */

function moveTo(x, y) {
root.x = x
root.y = y;
}

/ animation connectors that automatically interpolate changes in x and y over 300 seconds for each /

Behavior on x { NumberAnimation { duration: 300 } }
Behavior on y { NumberAnimation { duration: 300 } }

}

### main.qml

import QtQuick

/ AbstractItem.qml imported below /

import "."

Window {
width: 640
height: 480
visible: true
title: qsTr("Hello World")
}

### Codex session on highest settings

#### Prompt
`make a square and animate it moving from position (0,0) to position (100,100) over 300ms`


#### Desired response

AbstractItem {
id: root
Component.onCompleted: { root.moveTo(300, 300); }
}

#### Codex response

import QtQuick

Window {
width: 640
height: 480
visible: true
title: qsTr("Hello World")
Item {
id: root

// Animated square: moves from (0,0) to (100,100) over 300ms
Rectangle {
id: square
x: 0
y: 0
width: 50
height: 50
color: "red"

NumberAnimation on x { from: 0; to: 100; duration: 300; running: true }
NumberAnimation on y { from: 0; to: 100; duration: 300; running: true }
}
}

## Comments 
 Codex reinvents the wheel here despite having a perfectly good implementation where it could write the code in only 2-3 lines, instead it opts for writing the entire request and its complete implementation. 

## Fixes

### Situation / Environment 
Adding information about AbstractElement.qml into the AGENTS.md and explaining that it is a base class used for animating squares and explaining that it has the moveTo(x,y) function does not seem to have any impact and it still chooses to fully reinvent the wheel, however the following situation does allow it to use the abstract base class:

#### AGENTS.md

PROJECT STRUCTURE

• AbstractElement.qml - base class for creating animated squares that provides all needed helper functions to animate a red square over 300ms by creating an instance of AbstractElement then using its moveTo(x,y) function

#### Codex Prompt

`is there any way to create a square from any existing files in this project that is simple and already has all the necessary helper functions for animating a square?`

#### Codex Response

Item {
AbstractElement {
id: sq1
Component.onCompleted: moveTo(100, 100)
}
}

####  Comments
and voila, it worked - proof of abstract reasoning by utilizing a base class when the prompt included sufficient information that was also present in AGENTS.md (not sure if both are always needed for this behavior to work).  Definitive evidence that it is already capable of abstract reasoning, it just doesn't have enough information to do so with the current implementation and requires a more in-depth set of available functions to cross-reference.