Skip to content

feat(plugins-registry): add openfox-automate - #383

Open
theshwal wants to merge 6 commits into
co-l:developfrom
theshwal:feat/registry-add-openfox-automate
Open

theshwal wants to merge 6 commits into
co-l:developfrom
theshwal:feat/registry-add-openfox-automate

Conversation

@theshwal

@theshwal theshwal commented Sep 26, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Adds openfox-automate to the curated plugin registry.

openfox-automate is an OpenFox plugin (apiVersion 2) that autonomously
processes GitHub issues end-to-end (scan, order, spawn OpenFox sessions,
run a chain of workflows, monitor PRs). It exposes 19 settings fields,
14 RPC methods, 2 LLM tools, 3 hooks, and 1 UI panel.

Depends on #386

This PR is registry-only. It does not introduce any orchestration
surface itself; it just lists the plugin in plugins-registry.json.

The plugin speaks to the host through the new public plugin API
introduced by #386 (context.host.sessions and
context.host.workflows). It consumes the minimal PluginHost facade
and never reaches into host internals (sessionManager,
runWorkflow, launchWorkflowRun or setRunning are not exposed).
Merging this PR before #386 would leave the plugin unable to launch
sessions at runtime.

AI Models

MiniMax-M3

Plugin source

Test status (latest main HEAD d745e7e)

  • 99 unit tests passing (npm run test)
  • 16 e2e tests passing against a live OpenFox instance with the plugin
    installed (OPENFOX_E2E=1 npm test test/e2e/full-flow.test.ts).
    The e2e covers the PluginHost facade path end-to-end:
    add_issue_raw → start_issue → real host session creation in
    /api/sessions → executionStack[0].status === 'running' →
    double start_issue blocked → cancel_issue stops the host session →
    chain length matches workflows.chain. The chain-advance loop over
    workflow.execution.changed is covered by test/chain.test.ts
    (deduplication, retries, blocked, finished).
  • CI green on main: https://github.com/theshwal/openfox-automate/actions

Verification

Installed and verified end-to-end against a live OpenFox instance
running feat/plugin-orchestration-api (PR #386):

  • Local-path install: OK (POST /api/plugins/install with
    {"path":"/tmp/openfox-automate-build"})
  • All 14 RPCs return their documented shapes (health, get_queue,
    get_metrics, scan_now, …)
  • start_issue → real session creation visible in /api/sessions
  • UI panel renders with DRY RUN badge, Health check + Scan now buttons
  • Health RPC reports the new host: 'ok' field, alongside
    sessionManager and launchWorkflowRun

Checklist

  • Plugin follows OpenFox plugin v2 contract
  • Zero runtime dependencies (native fetch)
  • Plugin manifest validated by host (loaded=true, enabled=true)
  • README in English + French
  • CHANGELOG.md following Keep a Changelog
  • No modifications to OpenFox core files (only
    plugins-registry.json touched)
  • Plugin integrates via the public context.host API (PR feat(plugin-api): expose minimal session/workflow orchestration #386)
    — no internal host surfaces are imported or proxied

OpenFox plugin: scan GitHub issues, order intelligently, spawn
sessions, run a configurable chain of workflows end-to-end.

https://github.com/theshwal/openfox-automate
Capabilities: tools/settings/ui/rpc/hooks/notifications.
19 settings, 14 RPCs, 2 LLM tools, 3 hooks, 1 UI panel.
65 tests passing. Verified install via GitHub URL in OpenFox 10369.
@github-actions github-actions Bot added the enhancement New feature or request label Sep 26, 2026
@JamesDAdams

Copy link
Copy Markdown
Collaborator

I'm just wait to merge my pr before with new plugins settings and plugins icon.

Hosts that want to expose sessionManager + a runWorkflow wrapper to
plugins can now do so via pluginHost.setOpenFoxInternals(...). The
PluginContext.openFoxInternals field is resolved lazily through a
getter so plugins loaded before the setter call still see the value.

- PluginOpenFoxInternals: typed shape with sessionManager (createSession,
  setRunning) + runWorkflow(sessionId, payload).
- PluginContext.openFoxInternals?: optional field, lazy getter.
- PluginHostOptions.openFoxInternals: initial value (constructor).
- PluginHost.currentOpenFoxInternals: live slot.
- PluginHost.setOpenFoxInternals(...): update the live slot.
- src/server/index.ts: wires sessionManager facade + a runWorkflow wrapper
  that delegates to the existing task-seeded launcher so the broadcast,
  provider resolution, and stats identity stay consistent with the
  WS runner path.

Tested end-to-end with openfox-automate plugin on a live dev server
(port 10469): openFoxInternals.health RPC reports
{sessionManager:'ok', launchWorkflowRun:'ok'} after install.
CI on PR co-l#383 failed on:
- typecheck: PluginContext.openFoxInternals returned undefined but type
  was '? PluginOpenFoxInternals', rejected by exactOptionalPropertyTypes.
- lint: 'const host = this' aliased this, forbidden by no-this-alias.

Fix:
- src/plugin/index.ts: '? PluginOpenFoxInternals | undefined'.
- src/server/plugins/host.ts: drop getter + closure; snapshot as a
  regular property at createContext time. setOpenFoxInternals now
  mutates record.context.openFoxInternals so plugins loaded before
  the setter still pick up the new value.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants