Context
InferMatrixCopilot is being used with active repositories including:
vllm-project/vllm-omnivllm-project/afd-plugin
Both repositories change frequently, while InferMatrixCopilot relies on curated repository adapters and owner-scoped knowledge. This issue is intended to collect proposals for how InferMatrixCopilot should evolve with those repositories. It deliberately does not prescribe an implementation.
Current problems
1. Knowledge becomes stale
Repository behavior, interfaces, tests, documentation, and maintenance expectations change continuously. Existing InferMatrixCopilot knowledge may remain valid, become incomplete, or stop matching current code without a clear signal.
2. Repository structure and ownership drift
New files and subsystems appear, existing paths move, and ownership boundaries change. Routing that worked when a repository was initially integrated may later miss important changes or send them to the wrong component or model owner.
3. Durable knowledge is difficult to distinguish from implementation history
Most repository changes do not deserve a permanent rule. It is difficult to identify which changes establish reusable maintenance contracts and which are temporary, local, or already covered by existing knowledge. This creates risks of both missing useful knowledge and accumulating noisy or duplicated rules.
4. Multiple repositories must remain isolated
vLLM-Omni and afd-plugin share upstream concepts but have different architectures, compatibility boundaries, tests, and maintainers. Knowledge learned from one repository can be misleading if it is applied to the other without sufficient evidence.
5. Quality and maintenance cost are not yet visible
We do not yet have a clear way to assess whether knowledge remains current, whether repository changes are being covered, how accurate ownership and source references are, or how much model and maintainer effort ongoing alignment requires.
Request for proposals
Please propose how InferMatrixCopilot should address these problems.
A useful proposal should discuss:
- what repository changes should be considered;
- how potentially reusable knowledge should be identified;
- how ownership and repository boundaries should be preserved;
- how stale, duplicated, or unsupported knowledge should be detected;
- where human review is required;
- how safety and untrusted repository content should be handled;
- how the approach should be evaluated before broader adoption;
- expected operational and maintainer cost;
- alternatives and tradeoffs.
Proposals may address vLLM-Omni and afd-plugin together or recommend different approaches for each repository, but should explain why.
Related work
Context
InferMatrixCopilot is being used with active repositories including:
vllm-project/vllm-omnivllm-project/afd-pluginBoth repositories change frequently, while InferMatrixCopilot relies on curated repository adapters and owner-scoped knowledge. This issue is intended to collect proposals for how InferMatrixCopilot should evolve with those repositories. It deliberately does not prescribe an implementation.
Current problems
1. Knowledge becomes stale
Repository behavior, interfaces, tests, documentation, and maintenance expectations change continuously. Existing InferMatrixCopilot knowledge may remain valid, become incomplete, or stop matching current code without a clear signal.
2. Repository structure and ownership drift
New files and subsystems appear, existing paths move, and ownership boundaries change. Routing that worked when a repository was initially integrated may later miss important changes or send them to the wrong component or model owner.
3. Durable knowledge is difficult to distinguish from implementation history
Most repository changes do not deserve a permanent rule. It is difficult to identify which changes establish reusable maintenance contracts and which are temporary, local, or already covered by existing knowledge. This creates risks of both missing useful knowledge and accumulating noisy or duplicated rules.
4. Multiple repositories must remain isolated
vLLM-Omni and afd-plugin share upstream concepts but have different architectures, compatibility boundaries, tests, and maintainers. Knowledge learned from one repository can be misleading if it is applied to the other without sufficient evidence.
5. Quality and maintenance cost are not yet visible
We do not yet have a clear way to assess whether knowledge remains current, whether repository changes are being covered, how accurate ownership and source references are, or how much model and maintainer effort ongoing alignment requires.
Request for proposals
Please propose how InferMatrixCopilot should address these problems.
A useful proposal should discuss:
Proposals may address vLLM-Omni and afd-plugin together or recommend different approaches for each repository, but should explain why.
Related work