feat(plugins): coordinate managed product updates

[totalolage]

Summary

Implements the Hermes-core half of T3 Code's coherent managed Update contract, including the legacy unmanaged-to-managed bootstrap identified in follow-up review.

• parses update.mode: managed, contract, and entrypoint
• gives CLI, Plugins-page, dashboard API, and eligible plugin-owned Update routes one managed operation
• stages and validates an exact fast-forward candidate without advancing the live checkout
• executes the candidate's trusted entrypoint in a fresh isolated process against the actual installed root
• never falls back to source-only Git after a supported managed candidate is found
• reloads mounted Python routes and attests source/product identity through authenticated host IPC
• preserves coherent rollback for pre-managed installs, including installs with no service-state file
• keeps ordinary unmanaged Git plugins on exact classified git pull --ff-only behavior

Legacy bootstrap

The original draft dispatched only from the installed plugin.yaml. An older T3 checkout therefore took the generic Git path on its first update, producing a source-only state while its mounted backend remained old.

Hermes now fetches without changing the live worktree, requires clean fast-forward ancestry and matching plugin identity, validates the managed manifest and regular-file entrypoint from the exact fetched commit, and extracts staged code privately. The host then gates and drains the old route prefix before the staged worker receives the actual installed root. A legacy plugin-owned POST /api/plugins/<name>/update with no plugin-specific FastAPI dependencies enters the same transaction; dependency-bearing routes retain and execute their original dependencies.

The bootstrap authorization binds the prior commit, validated candidate history, installed root, and contract. Rollback is restricted to the prior commit. Complete accepts only a supported managed release commit within that validated fast-forward history, then derives attestation from the code and state actually mounted by every live host.

Multi-host completion failure rolls every host back before gates are released. Successful completion uses a verify-all, idempotent finalize phase so a partial gate-release failure can be retried without rolling back a coherent product.

Required T3 follow-up

T3 PR #42 was merged at 76830f00b2c30f48787702cc6971d9050a1cd0c0. Its v1 method shapes remain sufficient, but safe legacy bootstrap requires an explicit worker-operation correction now tracked in draft T3 PR #43:

1. accept a migrate operation for a staged candidate;
2. import the implementation from the entrypoint's own checkout while treating argv plugin_root as the installed mutation target;
3. make preflight support a legacy installed runtime with no canonical service-state, without mutation;
4. snapshot/derive that prior installed version and make rollback write canonical product_source_commit / product_version, restore the running service, and request host rollback attestation for that prior version.

Until that T3 follow-up lands, Hermes fails the legacy bootstrap transaction without a source-only cutover.

Validation

• managed-update, route-auth, and plugin runtime security suites: 67 passed
• managed bootstrap suite: 22 passed, including real Git/fresh-worker/HTTP remount integration
• web Vitest: 106 passed across 19 files
• web TypeScript typecheck: passed
• changed Python Ruff checks: passed
• git diff --check: passed
• paired T3 Hermes plugin suite on the follow-up branch: 78 passed (the missing migration cases above still need to be added)

Independent review rechecked multi-host recovery/finalize, release-vs-tip ancestry, exact unmanaged SHA cutover, plugin dependencies, no-state legacy rollback, and rollback binding, and found no remaining Hermes blocker.

[teknium1]

Thanks for the thorough fail-closed staging, rollback, and multi-host test work. This automated hermes-sweeper review is closing this under the standing third-party integration policy.

• The implementation hard-codes the T3 Code contract in hermes_cli/managed_plugin_update.py:394 (t3code-hermes-v1) and the accompanying plugin documentation binds the host API and state layout to T3 Code.
• AGENTS.md:797-810 requires integrations for someone else's product to ship as standalone plugin repositories, rather than creating an ongoing core maintenance dependency. This is a coupling decision, not a judgment on the quality of the work.
• Please publish the coordinated updater in the T3 Code standalone plugin repository, installed through the existing ~/.hermes/plugins/ or pip-entry-point discovery path; it can be promoted in #plugins-skills-and-skins.
• The linked T3 Code bootstrap follow-up Enable ChatGPT subscription Codex support end-to-end #43 is also still draft, as noted in the PR discussion.

---

Closed as not-planned per standing maintainer policy (in-tree-provider-integration). This is a design-direction decision, not a code-quality judgment — see the Contribution Rubric in AGENTS.md for what the project is looking for. If you believe this policy was misapplied to your change, comment here and a maintainer will take a look.