[RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152

Current state: The whole three-host goal remains unaccepted. The Codex ZIP is distributed through merged #239; actual Codex installation/lifecycle acceptance remains unverified here. PR #327 was squash-merged on 2026-11-05 at 15:27:54 UTC from reviewed head ff4302557c43e25fa3642bf4cdba08b1b70d7779 as main commit 57621339ad08bb32228bccda7d60217545316351. Its reviewed base was e843b9d31cb86e1fd12d00890c89798b0bedd1fe. The author's integration follow-up records the shared-builder/dashboard-resource integration and Windows release-validation cleanup repair. All six current-head Ready jobs and declarations passed. Amy's current-head approval is APPROVED with LGTM; it retains the disclosed Windows-only and native-host replay limits. Dong1017's same-head technical COMMENT was followed by formal APPROVED/LGTM, which also confirms the prior-head evidence wording was corrected. The merge commit's merge lane and push policy succeeded. Integration and versioned publication are now delivered: v0.1.4 Developer Preview was published on 2026-11-05 at 23:08:32 UTC (November 6 07:08:32 Asia/Shanghai), with inferrsi-workswarm-plugin-v0.1.4.zip, the Codex ZIP, wheel, sdist and SHA256SUMS. The tag resolves to 5c86eb57030c4aea50592b66451929c8cee705d6. The naturally scheduled Release run succeeded through plan/build/notes/publish, including host-ZIP validation and checksum verification. This verifies public attachment metadata and hosted checks, not a download, installed-version test or whole-three-host acceptance.

The Issue-level delegation covers the native WorkSwarm v0.2.7 adapter, dual-host Release attachment and Windows import fix/validation, excluding marketplace and whole-RFC acceptance. Historical head b8a2cb543ceb6188197ca4acadc73493ae93450e used a compact, integrity-checked runtime payload to address the affected desktop's path-length failure. The native Windows receipt reports installed CLI/Collect/revision/resource checks and two ordinary-root import/install/uninstall cycles; the prior-head technical review independently passed 16 compact-runtime tests on Linux/Python 3.12.14. These receipts remain bound to the older artifact, not the new integration. For the new head the author reports 30 affected Windows tests passed after the cleanup repair; the full 85-case set and native host probes were not rerun afterward. This synchronization reused published evidence and verified hosted status without reproducing host tests. Complete desktop UI/LLM use, cancellation/reconnect and the remaining host/platform acceptance remain unverified; no whole-Issue acceptance or model-performance result follows.
A separate Draft DSH preview #361, now at head ec99fe71f5ff55125b83a359fc4317847210edcf with base 57621339ad08bb32228bccda7d60217545316351, remains with existing contributor @zengchuang-hw. Its author records requester delegation for a structured iteration form, local/remote target configuration, SSH connection testing, existing-dashboard integration and Draft delivery. Amy's re-review at 1792257c cleared her initial six timeout, guidance, trust-boundary, connection/session-lifetime and CI-Node points, while retaining the submission/abandon lifecycle finding. Her exact-head approval at 010c9bcb now records LGTM/PASS for that final repair: owned/pending/handed-off/ambiguous delivery states distinguish definite rejection cleanup from potentially accepted sends. The prior-head 010c9bcb Ready lane succeeded: both full-check and installed-package Python versions plus PR references passed, while KV qualification was skipped for this Draft. The prior-head policy run also succeeded at 010c9bc. The author's follow-up preserves the same native-UI and real-Linux limits; this synchronization verified hosted status without rerunning those tests. The author reports two final-tree package/SSH tests including the bundled form's delivery/unmount/disconnect cases. Earlier native DSH 0.2.1-rc.5 Windows Web receipts remain bound to 1379a20b; the SSH fixture uses the real protocol but synthesizes remote command responses. Native UI after the fixes, real Linux bootstrap/benchmark execution, the vendored transport's line-by-line audit and the complete three-host workflow remain unverified. A later same-head incremental review identifies a distinct remaining pre-submission field-edit teardown issue: a failed close during connection-field edits or switching to local can discard a still-live SSH receipt, preventing cleanup/retry. The incremental re-review at 3254433f now considers that field-edit close repair addressed: inputs/receipt are retained until confirmed closure, failed cleanup remains retryable across form remount, and same-owner already-closed receipts are distinguished. It does not reopen the repaired submission/abandon finding. That review additionally asked whether a surviving client cleanup queue could lock the form after Host reload/disposal loses receipt history; it did not claim a reproduced failure. Amy's new exact-head APPROVED/LGTM at ec99fe71 now clears that concern. A typed unknown_receipt permits a second-confirmed local-record discard, with request freshness and foreign-session/error controls; it sends no automatic close request and does not assert the SSH connection or remote task stopped. The author's response supplies pinned rc.5 source evidence that client entries/modules can survive, so the repair does not assume coupled Host/client lifetimes. It also records the shared-packager integration and scoped fixture checks. At the 18:00 UTC check, all five applicable current-head Ready jobs and policy have succeeded; KV qualification is skipped for Draft. GitHub reports no merge conflicts. Native DSH browser journeys, an actual Host-restart test, real Linux execution and a line-by-line vendored SSH audit remain unverified; the lifetime evidence is source-based and fixtures synthesize remote command responses. The PR remains Draft, and remaining independent review, readiness/integration and whole-RFC acceptance stay with their existing owners. This synchronization reused published reviews and status, without new code/host testing. The original RFC's SSH/out-of-scope text is preserved; this status records the PR's bounded-delegation statement without changing accepted scope or granting execution, credential, release or installation actions.

Decision needed: The requester retains whole-goal acceptance and reconciliation of the remaining common journeys, host/version/platform matrix and undelegated slices. The WorkSwarm slice and its current approval do not settle those broader requirements.
Next action: v0.1.4 supplies the first published versioned WorkSwarm artifact; the requester and existing implementers retain the remaining host/lifecycle acceptance, separately from publication. The existing #361 author and requested reviewers retain the DSH preview's current-head repairs and review; no duplicate implementation or host test is requested. The prior integration conflict is cleared. The versioned WorkSwarm attachment is no longer pending; actual client use of this release and whole-goal acceptance remain unverified here. Preserve the historical installation-route discussion below; this update grants no new installation, publication or execution authority.

Goal and acceptance

Make InferRSI usable from Codex, DeepSeek Harness (DSH), and openJiuwen through installable host integrations. A user should describe an inference-engine task, receive relevant knowledge and an actionable preparation path, run an already authorized comparison on a prepared target, and understand its evidence without first learning InferRSI's internal directory structure or assembling every CLI invocation.

Status: Proposed for the full three-host goal. The requester has separately authorized the bounded manual-install Codex artifact slice described in §3. This does not constitute acceptance or authorization of the remaining implementation scope, authorize experiments, or establish client/usability acceptance or a published release.

Completion means a tested installation and the common journeys below work in each of the three hosts, with documented compatibility and limitations. A Codex-only release or an SDK sample is a delivery slice, not completion of this RFC.

Background and existing capabilities

Inspected InferRSI main on 2026-10-26: 65147a03. Recheck the implementation base before coding.

The operation guide already exposes knowledge research, normalized collect/read/resource, skill discovery, environment inspection, experiment preparation/execution, status and reports. Collect already has optional relevance and bounded-context views. These are capabilities to reuse, not missing subsystems to rebuild.

The current user-facing burden is connecting those operations to a task: choosing an entry point, locating the correct runtime and sources, supplying repeated arguments, interpreting incomplete results, and finding the next valid action. The proposed increment is a host-facing journey over those operations.

These are documentation/source findings, not installation or runtime validation. DSH is in developer preview. For openJiuwen, the readset establishes skills and MCP support; it does not establish a universal combined plugin-package format. Confirm the exact host, release and native packaging route in preflight. An agent-core-only SDK adapter does not by itself satisfy the user-facing openJiuwen goal.

1. Common user journeys

Keep a small set of recognizable entry workflows. Do not expose the entire knowledge library as a flat menu or load all skill bodies into every conversation.

For example: “Use InferRSI to investigate this engine's latency. Start by finding relevant knowledge and checking what is needed for a comparison.” The plugin should use available repository facts before asking for missing inputs, and should not infer approved thresholds from an optimization wish.

Starting from a target repository must not require changing the working directory to an InferRSI source checkout. A prepared runtime is still required where its commands execute. Installation must explain that dependency once; installing the host plugin does not provision accelerator runtimes, model weights or benchmark environments.

Existing-run inspection remains available when a new experiment cannot run. Missing runtime, unsupported target, no knowledge match, stale revision and failed validation must produce different, actionable outcomes.

2. Incremental architecture

flowchart TB
    C["Codex plugin"] --> W["Shared InferRSI entry workflows"]
    D["DSH native bundle"] --> W
    J["openJiuwen integration"] --> W
    W --> A["Existing CLI / Python operations"]
    A --> K["Canonical knowledge and resources"]
    A --> E["Existing runner, validators and evidence"]
    classDef existing fill:#eaf2fb,stroke:#6085aa,color:#172b4d;
    classDef proposed fill:#fff1dc,stroke:#c58b32,color:#553b13;
    class A,K,E existing;
    class C,D,J,W proposed;

Blue: existing capabilities. Orange: proposed host packages and shared entry workflows. The host agent continues to own conversation, planning and code changes; InferRSI continues to own its execution and evidence contracts.

Shared workflow and content

• Maintain reusable entry workflows in the existing canonical skill-library ownership structure. Host packages may supply small native wrappers, but must not maintain independent copies of optimization procedures, gates or knowledge.
• Generate selected release resources from canonical sources. Preserve stable identities, exact content revisions, dependency/resource closure, attribution, candidate state and validation limits.
• Use existing research and Collect semantics for discovery. Preserve explicit source selection, authority-qualified identities, byte budgets, omissions and unavailable/stale errors. No plugin-specific ranking engine or knowledge database.
• Resolve installed resources through supported package/host mechanisms. Do not assume a developer checkout path, symlink support or a particular user's home directory.

Thin host adapters

Host adapters own installation metadata, invocation conventions, workspace/runtime selection and result presentation. They invoke supported CLI/Python operations rather than reimplementing evaluation.

Prefer skills plus the existing local CLI where that completes the journey. Use native tool bindings or a small shared local MCP adapter when a selected host needs structured tool access. Settle that transport choice against the tested host versions before implementation; MCP is not a reason to introduce a second runner or a hosted service.

A structured bridge must preserve operation inputs, effects, errors and evidence identities. Read-only discovery/inspection and experiment execution remain distinguishable. Cancellation must reach the existing executor's cleanup path; a timeout or reconnect must not silently submit the experiment again. Do not add an unrestricted remote shell proxy.

Runtime and lifecycle

• Report the selected InferRSI runtime version and knowledge revision, and reject incompatible adapter/runtime combinations with a repair path. Document supported host versions and operating systems; do not claim every combination.
• Provide a documented initial setup, upgrade, disable and uninstall path through each host's supported mechanism. Preserve user configuration and existing evidence; host-global settings must not be overwritten.
• Register or configure integration resources so upgrading/disabling the plugin does not leave duplicate tools or stale executable paths.
• Reopening a conversation can inspect existing run artifacts. It does not resume or retry an interrupted experiment. Consume [RFC] Goal checkpoints: explicit progress and next actions across agent sessions #137's checkpoint interface if delivered; otherwise use existing status/report facts without claiming that proposal is implemented.

3. Delivery slices

This is an implementation sequence, not three differently defined products. If a host is blocked, retain the partial delivery and named blocker; do not remove that host from the goal or mark the whole RFC complete.

Public marketplace listing, account provisioning and a release are separate delivery decisions. A reproducible local/repository installation can establish plugin functionality without claiming public availability.

Plugin artifacts and manual installation (2026-10-31)

The current product decision is a plugin package for manual installation. Public marketplace/directory listing is deferred; preparing or submitting a public listing is outside this delivery slice.

Current default user-facing deliverable: one Codex archive. The format and number of release artifacts for the other hosts remain subject to their native requirements and tests. Maintain one canonical runtime and knowledge source, generating thin host adapters as needed. A future shared archive requires the same archive bytes to pass native installation and actual workflow checks in every claimed host/version/platform combination.

Codex package contract

• The default build target is dist/inferrsi-codex-plugin.zip, generated by python tools/build_codex_plugin.py. Its inspectable sibling directory is build output; users receive the ZIP. This default is part of the local changes pending a PR.
• Include exactly one plugin root, inferrsi/, containing plugin.json, entry skills, the bundled canonical Python runtime and required knowledge/resources, licenses/notices, and referenced assets. A marketplace catalog or an extra plugins/inferrsi/ wrapper must not be included in this manual-import archive. The explicit local-marketplace build remains a separate developer option.
• Preserve the plugin identity inferrsi and display name InferRSI. Set both author and developer display name to InferMatrix, and use the official InferMatrix website icon for the plugin logo and composer icon, packaged locally with its provenance.
• Core operations use the bundled InferRSI runtime without requiring an InferRSI source checkout or a pip install of InferRSI. Document Python 3.10+, optional dependencies, and the independently prepared target engine/device/model environment.
• Document installation by surface, enablement, first use, update/reinstall, disable/uninstall and troubleshooting. Direct account ZIP import remains an unverified hypothesis for the final artifact; it can upload/save a package and must not be equated with local marketplace installation or Developer Portal submission. Disconnected installation remains unverified. Normal Codex model connectivity is a separate requirement.

Installation surfaces and version preflight (2026-11-01 review follow-up)

Accepted the distribution-path distinction raised in review comment 6545815843. The official packaging guide documents local marketplace installation; the Developer Portal submission guide describes a separate upload/draft/review/publication path. Neither archive structure checks nor the submission guide establish an ordinary user's direct ZIP installation entry.

Current locally built review artifact: inferrsi-codex-plugin.zip, SHA-256 848b090d22777a8c4e60d42c24373a3a42bb532cf55c884d3cd657ea6c5f18a1. Archive integrity, embedded documentation and the extracted catalog path were checked; this digest does not record client acceptance.

For the documented local route, keep the delivered ZIP unchanged. Extract it into a fresh, stable <LOCAL_MARKETPLACE_ROOT>, producing <LOCAL_MARKETPLACE_ROOT>/inferrsi/. Add this separate catalog at <LOCAL_MARKETPLACE_ROOT>/.agents/plugins/marketplace.json:

{
  "name": "inferrsi-local",
  "plugins": [{
    "name": "inferrsi",
    "source": {"source": "local", "path": "./inferrsi"},
    "policy": {"installation": "AVAILABLE", "authentication": "ON_INSTALL"},
    "category": "Productivity"
  }]
}

Preserve existing catalogs/settings when integrating the entry. source.path is relative to the marketplace root; the catalog is outside the plugin and outside the single-plugin ZIP. Register that root directory, not the ZIP or its nested plugin directory:

codex plugin marketplace add "<LOCAL_MARKETPLACE_ROOT>"

Then refresh/restart the desktop client and install/enable InferRSI from the local marketplace. A compatible CLI also exposes codex plugin add inferrsi@inferrsi-local. Installation, discovery and a representative task in a new conversation in an external target repository must still be verified.

Treat Create plugin → select ZIP → install/enable as a separate hypothesis. Before documenting it as a supported route, record the actual application/build, entry point, personal/workspace audience and required permissions, OS, final ZIP digest, and observed installation/invocation results. If it is unavailable, retain the same ZIP and use the extraction/catalog route above. This review identifies a documentation/acceptance risk, not a reproduced installation failure. This follow-up performs read-only checks and archive validation; actual client installation and model invocation remain pending.

Delivery checks and current state

• Review and merge the packaging, metadata/assets, documentation and focused checks.
• Install the final InferRSI artifact through the selected local marketplace route on the recorded client/version/platform; verify the icon, author, skill discovery and invocation from an external target repository. Validate any claimed direct ZIP account-import route separately.
• Verify update/reinstall, disable/uninstall, missing-prerequisite guidance, and preservation of user configuration and evidence.
• Record the tested client version/platform, artifact digest, results and remaining limitations before describing the manual package as accepted.

The artifact and branding changes have been prepared locally, with archive/content and focused packaging checks. They are not yet a merged/published release, and the final InferRSI archive has not yet completed actual client import and workflow checks. Earlier diagnostic-package observations do not establish acceptance of this final artifact. Three-host acceptance, the usability pilot and the overall Issue completion criteria remain open.

4. Acceptance and usability evidence

Functional acceptance

• Each host can install, discover, enable and invoke InferRSI using its documented route, with tested versions and platform recorded.
• The same research/preparation task works from an external target repository; relevant sources and resource revisions remain traceable.
• Missing prerequisites and unsupported combinations return actionable guidance instead of an apparent successful setup.
• Preview remains a preview. Frozen validators/gates and execution authority are checked through existing contracts; neither is invented by the host adapter.
• A prepared synthetic CPU comparison can be executed and inspected through each host's actual workflow. Its synthetic verdict is not an engine-performance result.
• Actual host invocation covers progress, cancellation, evidence inspection and a failed/incomplete attempt; reconnecting cannot cause an implicit duplicate run.
• Exact-revision reads, candidate states and PASS / FAIL / INCONCLUSIVE semantics survive transport and presentation unchanged.
• Upgrade/disable/uninstall preserve user-owned configuration and evidence and leave no duplicate registrations or leaked child processes.
• Deliver installation, first-task, troubleshooting and compatibility guidance, with focused checks of changed adapters and required repository smoke checks.

Does it simplify use?

Use a bounded paired pilot comparing the existing documented CLI workflow with the plugin workflow, within each host where applicable. Record task, model/client settings, knowledge/runtime versions, environment and repeat policy before execution. Do not attribute differences between hosts or models solely to the plugin.

Measure time to a correct first result, manual commands/configuration edits, clarification or repair interventions, task correctness/evidence completeness, and observed model/execution cost where available. Missing usage remains unknown. Include fresh-install and existing-project cases and preserve failures, cancellations and incomplete outcomes.

Freeze task-specific criteria, budgets and any numeric usability gates in the acceptance issue/plan before the pilot. Installation success or passing adapter tests alone does not demonstrate improved usability. Reuse existing Skill Eval where applicable, but test the actual installed host integration: a runner that disables plugins cannot establish this acceptance.

No GPU/NPU experiment is required merely to prove plugin wiring. Claims about engine quality or service performance retain their separate campaign validation levels and evidence requirements.

5. Scope and constraints

In scope: three-host packaging/adapters, shared entry workflows, runtime discovery/setup guidance, progressive knowledge access, preparation and existing execution/status/report integration, troubleshooting, lifecycle handling and the bounded usability pilot.

Out of scope: another agent runtime, scheduler, conversation store, general experiment resume service, SSH dispatch/distributed execution, a broad dashboard, automatic knowledge promotion, or new default CI lanes. Transport/SDK dependencies must remain optional where possible; preserve the lightweight core install.

Campaign parameters remain issue-scoped. Keep the one-plane-per-step and freeze-before-search contracts. An ordinary experiment plan preview does not persist a frozen campaign. Plugin installation does not grant experiment, store-write or publication authority; reuse existing authorization instead of adding a separate approval workflow. Follow repository privacy/security rules for package defaults, examples, logs and pilot evidence.

Related work and ownership

• #61: agent-facing journey and usability workstream.
• #32: completed onboarding/knowledge-interface foundation; this RFC is its host-integration follow-up, not a reopening of that delivery.
• #128: reuse shipped Collect selection/context behavior; broader proposed work remains separate.
• #137: goal checkpoints and next actions; consume an accepted implementation when available.
• #143, #30, #60: task goals, plan organization and benchmark selection remain with their owners.
• #40: reuse task-efficacy evaluation contracts; plugin acceptance needs the actual host path.

Proposed by: requester; RFC drafted by Codex. Accountable implementation parent and slice owners: TBD. Goal-acceptance/closure owner: requester or an explicitly authorized delegate. The requester has authorized the manual-install Codex artifact slice in §3. Assignment of the remaining implementation slices, pilot resources/model-call budget and publication/release scope still require an accepted, bounded delegation.

Next decision: confirm the common journeys and initial host/version/platform matrix, especially the user-facing openJiuwen surface; assign the shared workflow and host-adapter slices. Report PR readiness, three-host acceptance and Issue completion separately.