[Status 01] InferRSI evolution: initialization → ac702729 (2026-10-20) #41

First cumulative status snapshot. This is a progress summary, not a new RFC, acceptance decision or execution authorization.

1. Snapshot

• Repository: InferMatrixLab/InferRSI.
• Checked: 2026-10-20, 08:38 UTC / 16:38 Shanghai.
• Edition: first, cumulative snapshot. Covers initialization including the root commit through the inspected main head, not only the latest four PRs.
• Initialization: d7af684, 2026-10-08 01:34 UTC, chore: initialize repository; verified to have no parent commits and no changed files (empty initialization).
• Head: ac702729, 2026-10-20 05:05 UTC, feat: read-only store path and knowledge CLI bridge (#32 PR 2) #39.
• Navigation: changes after initialization through head. The root is empty, so this comparison covers the subsequent repository content; initialization itself is included in the narrative.
• Bottom line: the repository has evolved from an initialized scaffold into an agent-assisted inference experiment workbench plus a traceable knowledge layer. It is not yet an autonomous optimizer, and delivered interfaces do not establish skill efficacy or universal hardware gains.

2. What changed: the evolution from init

Dates below describe integration into the repository (UTC), not when every underlying experiment or branch implementation occurred. Stages overlap and are grouped by capability rather than presented as a commit dump.

The transition is scaffold → executable experiments → sourced knowledge and lessons → explicit ownership/revisions → easier agent access. Automatic planning, patch generation, efficacy-tested skill selection and automatic experience promotion remain outside the established implementation.

3. Architecture delta

Current architecture, established over this cumulative history: an external human/coding agent drives an experiment workbench and a traceable knowledge layer. The latest usability changes extend access to that architecture rather than replacing it.

flowchart TB
    A["Human / external coding agent: goals, diagnosis, patches, permissions"]
    A --> K["Knowledge: package / checkout / candidate store"]
    A --> W["CLI + RunSpec"]
    W --> H["Harness: AB/BA, deadlines, evidence, verdicts"]
    H --> M["Model: requests, metrics, quality contracts"]
    H --> I["Infra: sources, devices, processes, artifacts"]
    M --> I
    I --> R["Prepared benchmark / validator / independent engine"]
    H --> E["Recorded evidence and reports"]
    E -. "Reviewed lessons; separately authorized updates" .-> K

• Evolution across this first edition: the scaffold acquired a concrete Harness/Model/Infra execution path and then a normalized package/checkout/store knowledge surface. The latest step added the knowledge CLI and read-only Store path.
• Current responsibility boundary: the external agent plans and changes code; shared Harness/Model/Infra modules execute and adjudicate supplied experiments. The dashed feedback path is not an automatic learning or promotion loop.
• Retained: Reference Matrix for sources and SearchSpace Matrix for resource × stage coverage. Neither is an automatic task router.
• Ownership: engines keep their runtime in their own repositories. Store Create/Update remain Python APIs for authorized candidates, not edits to package/checkout content.

See the architecture source of truth, rather than duplicating its full module inventory here.

4. Capability status

Delivery, acceptance and validation are deliberately separate.

5. Evidence and limitations

Current usability gaps

Static review of ac702729 found three bounded problems:

1. Text-mode collect drops --material content and may emit nothing for query-only no-match; full JSON preserves the envelope.
2. Checkout quickstart commands need the skills extra/PyYAML, which the base installation step does not supply.
3. The operation guide misstates legacy search no-match, mandatory context filters and mandatory resource revision.

These require a small corrective change and tests, not a Reader/Store redesign. A local-agent instruction has been prepared; no corrective implementation or PR is confirmed in this snapshot.

Refs: material output finding, install finding, operation-guide findings, successful PR-head CI.

Recorded performance outcomes across the cumulative history

• Qwen-Image B300: historical scoped accepted result, 30.60% lower latency with 44/44 pixel-identical checks; included as historical evidence, not newly reproduced for this report. Acceptance: Qwen-Image-2.1-Turbo / B300×4 campaign #3 remaining open does not negate the recorded result.
• Drama3 B300: per-concurrency target remains INCONCLUSIVE; optimization is recorded as paused. Local kernel/graph gains are not service acceptance.
• Qwen3-TTS import: source-grounded transfer candidates, not accelerator/audio-quality reproduction or per-feature speedup proof.

Recorded campaign results and conditions. This brief uses repository evidence and source inspection; it did not run new benchmarks or independently rerun the full test suite.

6. Next decisions

1. Usability acceptance: complete a bounded correction for [RFC] Agent Usability v1: onboarding, knowledge discovery and interface alignment #32, test clean installation and text/JSON outputs, then update acceptance evidence against the final revision.
2. Campaign structure: resolve [RFC] Iteration Campaign Plan: one table for model, hardware, goal, search plan and test plan #30/docs: add a campaign plan template for the plan evidence segment #31, keeping plans linked to the existing matrices and allowing justified, budgeted diagnostics.
3. Skill efficacy: refine [RFC] Skill Eval v1: revision-scoped discovery and task-efficacy evaluation #40's initial client, tasks/verifier, held-out split and budget before authorizing execution.

Separately, reconcile the already-landed deliverables in #29/#33/#35 with their owners' acceptance criteria. Do not close them solely because a commit merged. MLX remains a parallel, independently scoped workstream.