[RFC]: Initialize repository-backed agent workflow for afd-plugin

Start by reading AGENTS.md, CLAUDE.md, .agents/skills/run-e2e, pyproject.toml, the CI workflows, and the test layout, then review the related work in #155, #167, and #168. Done means a maintainer-reviewable adapter/profile exists, sample AFD PRs route to repository guidance, CPU-safe and hardware-gated evidence are distinguished, and the integration remains read-only without duplicating repository sources of truth.

Summary

Request to initialize a repository-backed agent workflow for afd-plugin, aligned with the repository-backed agent skills workstream in #155.

The goal is to make repository maintenance and review repeatable across AFD compatibility work, model adaptation, connector/distributed changes, hardware recipes, E2E validation, and releases.

Current repository assets

The repository already has useful sources of truth:

• AGENTS.md with patching, upstream-compatibility, and review requirements;
• CLAUDE.md, which delegates to AGENTS.md;
• .agents/skills/run-e2e;
• CPU-safe checks and hardware-gated E2E workflows.

These files should remain authoritative; agent integration should orchestrate them instead of duplicating deterministic logic.

Proposed initialization

1. Repository profile and adapter

Register vllm-project/afd-plugin as a first-class target in InferMatrixCopilot with:

• a human-reviewed repository adapter and protected-branch policy;
• an evidence-cited profile generated from the existing repository instructions, README.md, pyproject.toml, CI workflows, and test layout;
• explicit ownership paths for:
  • compatibility patches and version shims;
  • configuration and validation;
  • connectors and distributed execution;
  • model workers/runners;
  • GPU/NPU native sources;
  • unit, contract, and hardware E2E tests.

2. Initial review knowledge

The initial repository-specific review rules should cover:

• the exact vLLM/vLLM-Ascend compatibility matrix, without assuming a broad version range;
• the plugin registration and --additional-config boundary;
• upstream-first patching, marked AFD deltas, exact signature preservation, and removal/upstream plans;
• connector rank/layout, synchronization, async behavior, and cleanup;
• non-AFD isolation;
• CPU-safe validation versus GPU/NPU evidence;
• reproducible hardware/software/topology records for support and performance claims.

Version-upgrade work should remain aligned with #167 and #168, rather than baking a stale version assumption into the initial profile.

3. Thin repository-backed skills

After the underlying workflows are stable, add thin skills for:

1. aligning to the selected vLLM version;
2. adapting and validating a model;
3. creating and reviewing a hardware recipe;
4. running the complete E2E matrix;
5. preparing a mirrored-version release.

Each skill should discover inputs, invoke repository-owned scripts/checklists/tests, and report evidence. It should not reimplement build, test, or benchmark logic.

4. Safe review integration

The initial integration should be read-only by default:

• no automatic PR comments;
• no automatic pushes;
• no direct writes to main;
• canonical AFD PR URLs should route to the correct repository-specific knowledge;
• unmatched paths should be reported rather than silently treated as covered.

Acceptance criteria

• A clean checkout can be profiled without modifying the target repository.
• A maintainer can review and promote the generated adapter/profile.
• A sample AFD PR routes to the relevant compatibility, connector, runner, native-backend, and test guidance.
• The workflow distinguishes CPU-safe checks from hardware-gated evidence.
• Existing AGENTS.md, .agents/skills/run-e2e, CI, and test commands remain the source of truth.
• The first implementation does not copy the vLLM-Omni knowledge tree or create broad generated repository summaries.

Questions

1. Should the adapter and curated knowledge live entirely in InferMatrixCopilot, or should afd-plugin also add a small integration marker?
2. Which workflow should be implemented first: vLLM alignment, model adaptation, E2E execution, or release preparation?
3. For the current upgrade work, should the first profile target the exact vLLM 0.26.0 migration in #167/#168 or remain version-neutral until those RFCs settle?