This is good, however it’s unclear to me how to manage it in the long run. The list [0] will grow to hundreds of IDRs or more in the long run, and inevitably some will become inapplicable, contradict other IDRs, or become actively misleading when the software evolves. Since the IDRs are supposed to provide information the LLM can’t infer by itself, using the LLM to evaluate their continued applicability is likely not practical.
To effectively manage them, you’d need some sort of topical (?) index to be able to find the relevant IDRs that may need to be updated or removed. Sometimes they might be tied to a particular submodule, but many IDRs may have more crosscutting concerns.
In the end, it’s a form of documentation that needs to be maintained, instead of remaining one-offs limited to the task at hand.
This is good, however it’s unclear to me how to manage it in the long run. The list [0] will grow to hundreds of IDRs or more in the long run, and inevitably some will become inapplicable, contradict other IDRs, or become actively misleading when the software evolves. Since the IDRs are supposed to provide information the LLM can’t infer by itself, using the LLM to evaluate their continued applicability is likely not practical.
To effectively manage them, you’d need some sort of topical (?) index to be able to find the relevant IDRs that may need to be updated or removed. Sometimes they might be tied to a particular submodule, but many IDRs may have more crosscutting concerns.
In the end, it’s a form of documentation that needs to be maintained, instead of remaining one-offs limited to the task at hand.
[0] https://github.com/wlach/repo-parser/tree/main/idrs