[zengchuang-hw]

Governing Issue and delivery slice

Refs #152

Add a native InferRSI plugin for openJiuwen WorkSwarm v0.2.7, and attach inferrsi-workswarm-plugin-vX.Y.Z.zip alongside the Codex plugin in automatic GitHub Releases.

The desktop's native importer copies packages through a long staging path. The initial unpacked runtime failed there with Windows path-length/missing-file errors. WorkSwarm now carries the complete canonical runtime in a compact runtime/payload.zip; the host imports only short outer paths. A stdlib bootstrap verifies the payload and uses an independently verified, content-addressed per-user runtime cache before running the unchanged shared launcher in the same process.

The requester delegated the adapter, validation, PR/review fixes, Release attachment, and the subsequent desktop installation fix and local installation testing. Whole-Issue acceptance remains with the requester.

Changed artifacts and evidence

Requirement	Delivered behavior	Verification
Native installation on the affected Windows desktop	One native inferrsi/ package root; compact outer paths, complete canonical runtime/resources retained inside the payload	Final ZIP imported and installed through the running desktop backend's native RPCs in its unchanged default profile; reinstalled and installed=true confirmed
Model-visible launcher handoff	Read-only inferrsi_runtime_info returns the installed bootstrap through its model-facing renderer	Actual SDK SkillTool/locator ToolMessage.content replay; no hidden skill_directory dependency
Runtime integrity and resource lifecycle	Payload paths/hashes verified before writes; private staging and atomic cache publication; every cached byte checked before use; links/reparse points and relative cache roots rejected	16 focused cache/payload tests; concurrent first use, tampering/missing/extra files, unsafe paths, and links covered; resource/reference paths survive process exit and later calls
Versioned Release attachment	Existing Release bot builds both host ZIPs, validates each host format/version/runtime and includes both in checksums/artifact transfer/upload/attachment checks	Actual current-head build/checksum blocks replayed; wheel, sdist and both ZIPs generated and verified
Codex compatibility	Existing Codex layout and shared launcher retained	Both-host regressions; the synthetic-version Codex archive is byte-identical to the earlier 363db01 rehearsal
Publication boundary	Existing optional AI notes/provenance/fallback and isolated publisher retained; no new CI lane	Publisher shell exercised against a recording mock; no repository-code execution or API key added to the write job

Checks and dependencies

Current head: ff4302557c43e25fa3642bf4cdba08b1b70d7779; integrated main: e843b9d31cb86e1fd12d00890c89798b0bedd1fe.

• Current integration validation: retained the shared host builders and included the upstream dashboard HTML in both host archives. Windows release validation now allocates its private staging directory using the same extended-length root used for extraction and cleanup.
• Current local results: Windows / CPython 3.12.1, pytest 9.1.1, Ruff 0.15.15; imports bound to this checkout. Before the cleanup repair, the three plugin/runtime modules produced 84 passed and 1 failed (WorkSwarm archive cleanup, WinError 145, reproduced unchanged). After the repair, both host archive-installation cases plus tests/test_release.py passed 30 tests; targeted Ruff and whitespace checks passed. Both isolated dashboard-export cases passed in the preceding run; the cleanup-only change does not alter the builders or launcher. The full 85-case suite was not rerun after that repair.
• Current independent review: a separate Codex agent reviewed final tree 41893762944cfac807473aea56936074bb1d9d8c, exactly the committed tree, and found no remaining code blocker. No protected knowledge delta against the integrated main.
• Current hosted checks: all six Ready CI jobs and knowledge policy passed at this head. Earlier green checks below belong to the older head.
• Evidence boundary: the previous real WorkSwarm/desktop receipts and release rehearsal below remain evidence for b8a2cb543ceb6188197ca4acadc73493ae93450e; the native host probes were not rerun for the new integration artifact. No new desktop/LLM or campaign acceptance claim is made.

Prior-head evidence (b8a2cb543ceb6188197ca4acadc73493ae93450e)

Tested against base 663f3b327998526a13aa31e72ad729025c18983c.

• Final Linux regression: 276 passed, covering both plugin formats, release planning/validation/publisher, cache/payload checks, persistent resource paths and mocked release-note APIs. Ubuntu 24.04 / Python 3.12 / Git 2.56. Lint (src tests tools plugins/workswarm) and whitespace checks passed.
• Hosted CI: current-head Ready checks passed complete Python 3.10/3.11 suites, both clean installations, PR references and CPU task qualification. Knowledge policy passed (not applicable to this PR delta).
• Final release rehearsal: built wheel/sdist, passed twine and sdist boundaries, executed the workflow's actual two-host packaging/validation and checksum blocks, verified all four checksums and the unchanged source tree. Synthetic local version 1.2.3; no remote tag/Release or real AI API call was made. The Codex ZIP SHA-256 remains 1d80fd9dc30a0c54c55695e746c2ff1d5eee0934af6cf078cffc9626478e2c09, identical to the pre-fix rehearsal.
• Final Windows manual-test ZIP: SHA-256 768f21b356edb8aef9d409e6b258a0fd9143566cb6d01727fb4b4cc4afe277dd, 953 canonical runtime files. This source preview reports runtime 0+unknown; version-stamped release artifacts are checked separately.
• Final native validator: official v0.2.7 quality/static/real-hot-load validation passed with zero errors/warnings, one skill and one tool.
• Final running desktop/default-profile check: used native plugin_packages.import_local/install/show/list RPCs on the already-running desktop backend. The final ZIP was reinstalled after verifying ownership of the earlier test package; all installed package bytes match the final ZIP. Installed isolated CLI, Collect, exact revision Read, stale revision rejection and persistent skills reference/resource paths passed.
• Ordinary-path lifecycle regression: the earlier compact test ZIP (SHA-256 317012b7456b5638be25ea98e4c27c446627273b2f2e145a7a1bddb711743f99) completed two import/install/uninstall cycles with an ordinary isolated data root, explicitly without an extended-length prefix. Native model-facing handoff, unload, reinstall, exact/stale reads and unrelated registry/evidence preservation passed. This is explicitly earlier artifact evidence; the final head adds cache guard/repair/IO refinements and has the final regression/default-profile checks above.
• Coverage limits: screenshot/click automation was unavailable for the desktop window. Its actual import failure was read through accessibility text; final installation was performed through the same desktop backend's native APIs. A complete click-driven UI/LLM journey and cancellation/reconnect remain unverified. No passing full Windows suite is claimed.

Independent review

Codex subagent /root/workswarm_review reviewed 363db01bd136dfb64a813c784c516f671c184935 → b8a2cb543ceb6188197ca4acadc73493ae93450e, confirmed its reviewed content matches the commit, and reported no unresolved findings. It independently passed 16 payload/cache tests, lint and whitespace checks, and verified compact-package resource/reference paths across separate processes without modifying the target cwd. Earlier independent review also covered the model-visible handoff and dual-host Release extension. This is agent review evidence, not maintainer approval or merge authorization.

Knowledge authorship declaration

Not applicable: no protected knowledge paths are changed. Signed-off commits record material agent authorship.

Remaining work and Issue closure

• After merge, the existing Release bot will attach both versioned host ZIPs on its next eligible scheduled/manual release. The Release channel remains Developer Preview.
• The cache persists after commands/uninstall so returned resource paths remain valid. Its scope, integrity checks and repair/cleanup procedure are documented; no host configuration or Windows global policy is changed.
• End-to-end desktop/LLM use, cancellation/reconnect, other host/platform installations, DSH and the usability pilot remain separate validation work.
• The three-host RFC remains open for requester acceptance. This PR makes no marketplace or model/service-performance claim and does not request merge or Issue closure.

[Dong1017]

P2: The model-facing skill_tool result does not expose the launcher directory described here.

The WorkSwarm v0.2.7 dependency pins agent-core 4fd009e. In that revision, skill_tool puts skill_directory in the structured ToolOutput.data, but sets data['content'] to the skill body and layout appendix; its own rendering note says the model receives that content rather than the other fields. The appendix's tree starts with the directory basename, not its absolute parent path. Thus, the instructed agent cannot rely on seeing the claimed absolute path in its normal tool result, so it may be unable to construct <launcher> from an external target workspace.

Please use a host-supported way for the agent to obtain the installed absolute path, and add a regression covering the model-rendered result through native skill discovery and launcher invocation, not just the structured Python result. check_workswarm_installed.py currently constructs installed / ... / inferrsi.py directly, so its passing lifecycle check does not exercise this handoff. This is a source-based finding; I did not run the desktop/LLM journey.

[Dong1017]

The pinned host exposes skill_directory as structured metadata, but renders the skill body/layout rather than that field to the model. Please provide a model-visible way to resolve the installed launcher and test the rendered host path.

[zengchuang-hw]

Addressed in f28cd29.

• The entry skill now calls the native read-only inferrsi_runtime_info tool. It derives the launcher from its installed module's __file__ and explicitly renders JSON containing success and launcher. It accepts no arguments, writes no files and executes no commands.
• The new rendered-result probe loads the package in a real DeepAgent, dispatches skill_tool and the locator through AbilityManager.execute, discards their structured results, and parses only ToolMessage.content. The lifecycle check invokes that returned launcher from an external target cwd instead of constructing installed / ....
• Verified on the pinned host: official quality/static/hot-load checks passed with one skill and one tool; both native install/uninstall cycles, model-visible handoff, argument rejection, extension unload and exact/stale reads passed. An independent replay also unpacked the same test ZIP at two different locations and invoked each correctly resolved launcher.
• All 95 Linux plugin/release regression cases passed. Current-head hosted checks are refreshing.

This verifies the model-facing bootstrap without claiming an actual desktop/LLM journey.

[Dong1017]

The specific hidden-directory finding is addressed at f28cd29. I inspected the locator, native manifest, skill instructions and rendered-result/lifecycle probes. The locator derives the launcher from its installed module and renders the path as JSON; the probe dispatches both tools through AbilityManager.execute and consumes ToolMessage.content, and the lifecycle check invokes the returned launcher from the target workspace. This addresses the original reliance on hidden skill_directory metadata.

Current-head Ready CI passed. I did not independently rerun the host replay or desktop/LLM journey; the latter remains unverified. This clears only this review finding, not acceptance of the WorkSwarm slice or the three-host RFC. Issue #152's recorded scope/ownership still needs reconciliation with the PR's delegation statement.

[agent-ci-infra-bot]

This PR adds a native openJiuwen WorkSwarm v0.2.7 plugin (manifest, entry skill, read-only launcher locator) and extends the existing release bot to build, validate, checksum and attach inferrsi-workswarm-plugin-vX.Y.Z.zip alongside the Codex ZIP. I re-ran the host-plugin/release regressions (87 passed), rehearsed both host builds through check_release.py at this head (both validate; runtime bytes identical across archives), and confirmed all hosted checks at 363db01 are green — no new defects found. Earlier finding F1 (hidden skill_directory handoff) is fixed and its code is unchanged since the confirming review; reconciling Issue #152's recorded scope/ownership with this PR's delegation statement remains a human decision.

Reviewed commit: 363db01
Coverage: Checkout: 2654 files at 363db01 in a git worktree with the repository's history

[agent-ci-infra-bot]

This PR adds a native openJiuwen WorkSwarm v0.2.7 plugin ZIP and publishes it next to the Codex ZIP from the same release workflow, version and runtime; the delta since the last reviewed head (release-packaging commit 37b0e11 plus the main merge) is limited to the release step, host-aware check_release.py validation, docs and both-host tests. Verdict: the code delta is coherent and I found no code-level defect in it — both host ZIPs built with a synthetic 1.2.3 stamp and passed check_release.py plugin --host, 114 targeted release/plugin tests passed, and ruff check src tests tools plugins/workswarm is clean; the earlier hidden-skill_directory finding (P2) is fixed and the release-extension changes do not reintroduce it. The remaining item is an ownership/authorization question for a human, recorded below.

Labels: kind:task (a bounded, explicitly delegated delivery slice of RFC #152 rather than a standalone feature or defect fix)

F2 — medium, suggestion, authorization/scope — The openJiuwen slice and its automatic Release attachment are still not recorded as delegated in Issue #152

• Where: .github/workflows/release.yml:105-116 (both host ZIPs now built and attached by the scheduled Release bot) and docs/workswarm-plugin.md:8-14 (user-facing download instructions).
• Problem: the governing Issue, read through the GitHub API during this review, still carries status:proposed and its status block says "No slice owner is assigned; the recorded next step is final-artifact installation and lifecycle checks for the Codex ZIP, while the other slices wait for the requester's delegation"; its last recorded comment (2026-11-01) says parent/slice ownership is "still TBD". The statement that the requester delegated the WorkSwarm adapter and extended this PR to the Release attachment exists only in this author-written PR description; no Issue comment or linked record confirms it. The earlier maintainer reply on this PR (pullrequestreview comment 4451807476) raised the same reconciliation need and it is still open.
• Conditions: every eligible scheduled or manual release after merge; publish uploads dist/*.zip, so the new archive goes to all users on the normal channel, not to a preview lane.
• Impact: a host artifact outside the only slice [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 records as authorized (manual-install Codex) would be published and implicitly supported by the standard Release bot, which the RFC explicitly separates from per-slice acceptance.
• Fix: have the goal-acceptance owner record the delegation (and the WorkSwarm Release extension) in [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152, or keep the WorkSwarm ZIP out of the automatic Release until that slice is accepted. This is a decision for a person; it is not a code-quality blocker on the packaging changes themselves.

Reviewed commit: 363db01
Coverage: Checkout: 2654 files at 363db01 in a git worktree with the repository's history

[agent-ci-infra-bot]

This PR adds a native manual-install openJiuwen WorkSwarm v0.2.7 plugin (manifest, entry skill, read-only launcher locator) and extends the release bot to build, validate, checksum and attach inferrsi-workswarm-plugin-vX.Y.Z.zip beside the Codex ZIP. The body edit only refreshed CI status; I verified that all check-runs at 363db01 are green and that Actions runs 41631628189 and 41632031543 succeeded at that head, and I found no new code defects. Earlier F1 (hidden skill_directory handoff) is fixed and its code is unchanged since the confirming review; the separate Issue #152 delegation/ownership question remains open below. Tests: both-host plugin/release/publisher suites pass (87 passed, run after pointing TMPDIR at an exec-capable path because this container mounts /tmp noexec); the repo-wide run has 239 failures that are environment-only (git 2.39.5 lacks --no-lazy-fetch), unrelated to this diff, and I could not rerun the openJiuwen host-dependent probes because no host SDK is installed here. Relevance: current — main is still 663f3b3, the PR base. Labels: none suggested (the applicable kind:task and area:workbench are already set).

F1 — high, must-fix, model-visible launcher handoff — Fixed

• Where: plugins/workswarm/inferrsi/skills/inferrsi/SKILL.md:17, plugins/workswarm/inferrsi/tools/runtime_info_tool.py:26, tests/check_workswarm_rendered.py:57
• Status: fixed and unchanged since the confirming review at this same head. The entry skill now calls inferrsi_runtime_info({}), the locator derives the launcher from its installed module __file__ and returns success/launcher as rendered JSON, and the probe discards structured results and consumes only ToolMessage.content before invoking the returned launcher from an external target cwd.
• Not re-run here: the openJiuwen SDK is not installed in this container, so I did not execute check_workswarm_rendered.py / check_workswarm_installed.py; this status rests on the earlier evidence plus the unchanged code.

---

F2 — high, must-fix, scope/authorization — The WorkSwarm slice and its Release attachment are not recorded as delegated in Issue #152

• Where: PR body, "The requester delegated the WorkSwarm adapter, validation, PR and review fixes, and explicitly extended this PR to include the WorkSwarm Release attachment."
• Problem: The governing Issue still records only the Codex slice as authorized: "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." Its status block also says "No slice owner is assigned ... while the other slices wait for the requester's delegation," and no comment on [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 records a WorkSwarm/openJiuwen delegation. The PR's own delegation claim is therefore unverified against the artifact of record.
• Conditions: Anyone merging this PR as authorized openJiuwen delivery; docs/workswarm-plugin.md:3-6 already labels it the "openJiuwen adapter slice of RFC [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152" with three-host acceptance still separate, so this is about merge/acceptance authority, not the code.
• Impact: Merging would advance an RFC slice whose authorization exists only as a PR-body assertion, and would add a second release asset to the Release channel without a recorded decision on release scope.
• Fix: A maintainer/requester confirms in [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 (or on this PR) that the WorkSwarm adapter plus the Release-asset extension are delegated, and records the result. No code change is requested for this finding.
• Status: Still open from the earlier review round; the body edit restated the claim but added no record.

Reviewed commit: 363db01
Coverage: Checkout: 2654 files at 363db01 in a git worktree with the repository's history

[amy-why-3459]

Review at head b8a2cb54: CI is green at this head and the earlier hidden-launcher finding is fixed, but I am not approving yet.

1. Delegation for the WorkSwarm slice is not recorded in [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 (PR body, delegation statement): [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 still records only the manual-install Codex artifact slice as authorized; publication/release scope and other slices wait for an accepted delegation. This PR adds a second plugin and attaches inferrsi-workswarm-plugin-vX.Y.Z.zip to every Release. Please link the requester's delegation for the WorkSwarm adapter and its Release attachment on [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 (the bot's F2 is still open).
2. Unreviewed delta: the latest commit b8a2cb54 ("avoid WorkSwarm Windows import path limits") came after the last human review at f28cd29a and the bot review at 363db01b. Please describe what changed and how the Windows path behaviour was verified.
3. Unverified host behaviour: tests/check_workswarm_rendered.py / check_workswarm_installed.py require the openJiuwen SDK and were not re-run by reviewers. Please attach a run log at the current head on a real WorkSwarm v0.2.7 host.

[zengchuang-hw]

Thanks for the review at b8a2cb54.

1. The requester’s bounded delegation is now recorded in #152. It covers the native adapter, its GitHub Release attachment, and the Windows import fix and validation.
2. The Windows delta moves the canonical runtime into runtime/payload.zip, so the native importer only stages short outer paths. At launch, the bootstrap verifies the payload and publishes it to an integrity-checked, content-addressed cache. The earlier desktop backend run reimported and reinstalled the final ZIP and confirmed that the installed files matched it. The fresh Windows replay below exercised the same ZIP through two native install/uninstall cycles using an ordinary host data root.
3. Both requested probes exited 0 against the official WorkSwarm v0.2.7 source tag with pinned agent-core. This isolated run exercises the native APIs and the rendered ToolMessage.content handoff. Coverage limits are recorded in the log. Current-head Ready CI.

Sanitized current-head Windows run log

InferRSI PR #327 native WorkSwarm replay
Recorded 2026-11-04 Asia/Shanghai
PR head b8a2cb543ceb6188197ca4acadc73493ae93450e
Windows, CPython 3.12.1
WorkSwarm v0.2.7 source tag, commit 2aa7fea7e55fbe1edaae0d468ef666b088c76fa9
Pinned agent-core 4fd009e175515775af1d069978d833d7989d5fad

python -X utf8 tests/check_workswarm_installed.py --host-source <workswarm-v0.2.7-source> --archive <final-zip>
Exit 0. Fixture-mode warnings omitted from excerpt.
{
  "archive_sha256": "768f21b356edb8aef9d409e6b258a0fd9143566cb6d01727fb4b4cc4afe277dd",
  "runtime_version": "0+unknown",
  "content_sha256": "b995239090f8c8baf3289c2ab00264889cce84242952810368078a329762a864",
  "completed_cycles": 2,
  "checks": [
    "import",
    "install",
    "card discovery",
    "selection metadata",
    "ordinary host data root without extended-length prefix",
    "installed file hashes",
    "model-rendered skill and locator handoff",
    "native extension unload",
    "isolated launcher",
    "exact revision read",
    "stale revision rejection",
    "uninstall",
    "reinstall",
    "unrelated registry and evidence preserved"
  ],
  "not_exercised": [
    "desktop UI",
    "LLM dispatch",
    "cancellation/reconnect"
  ]
}

python -X utf8 tests/check_workswarm_rendered.py --host-source <workswarm-v0.2.7-source> --plugin <unpacked-final-package>/inferrsi --workspace <isolated-target> --result <scratch-result.json>
Exit 0. Nine staged outer files byte-identical to the final ZIP.
{
  "success": true,
  "launcher": "<installed-plugin>/skills/inferrsi/scripts/inferrsi.py"
}

[zengchuang-hw]

@amy-why-3459 @Dong1017 PTAL

[Dong1017]

Reviewed current head b8a2cb543ceb6188197ca4acadc73493ae93450e following the PTAL. No new code-level blocking finding in this pass.

• Inspected the compact-runtime bootstrap, native locator/rendered probes, shared packaging and release-validation changes. The payload keeps deep canonical paths out of host staging; the bootstrap verifies payload and cached bytes before invoking the shared launcher. The original hidden-directory finding remains addressed. Independently ran all 16 test_workswarm_runtime.py tests, passing on Linux/Python 3.12.14 against files verified to match this head's Git blobs.
• The Issue-level delegation record now describes the adapter, Release attachment and Windows import fix. The current-head Windows receipt supplies the requested native-probe results, including two install/uninstall cycles using an ordinary data root. These are author-reported host results; I did not independently rerun Windows/WorkSwarm here.
• Ready CI is passing at this head. My local run was the focused cache/payload suite, not the full regression suite. Desktop UI, LLM dispatch and cancellation/reconnect remain unverified; keep the Developer Preview limits and broader [RFC] Agent plugins: a consistent InferRSI workflow in Codex, DSH and openJiuwen #152 acceptance separate.

This is technical review feedback, not a formal approval.

[amy-why-3459]

LGTM

PR review verdict — PASS
Reviewed base e843b9d31cb86e1fd12d00890c89798b0bedd1fe and head ff4302557c43e25fa3642bf4cdba08b1b70d7779 (incremental since my previous review at b8a2cb54).

• My three earlier points at b8a2cb54 are addressed: the bounded delegation is recorded on #152, the compact runtime/payload.zip Windows-import change is explained, and the author's native WorkSwarm v0.2.7 probe log (two install/uninstall cycles) was posted for that head.
• PR-specific delta in this push (merge with main + ff43025): tools/plugin_bundle.py:108 carries the dashboard HTML inclusion rule (data/dashboard/*.html) from #319 with the same condition that was in build_codex_plugin.py, consistent with pyproject.toml package-data, so both host builders now ship it. tools/check_release.py:197-203 now creates the staging directory under the extended-length temp root on Windows so extraction and cleanup use the same path; integrity checks are unchanged and the non-Windows path is identical to before.
• All Ready checks are green at this head (full-check 3.10/3.11, installed-package 3.10/3.11, kv-task-qualification, pr-references, declarations).

Not verified by me: the Windows-only branch of check_release.py (author-reported 30 passed on Windows), and a native WorkSwarm host replay of the new payload (no new receipt claimed for this integration). Desktop UI, LLM dispatch and cancellation/reconnect remain outside this review, as stated in the PR.