Skip to main content

Plugin Repository Acceptance

Public repository support is integrated into HyperHQ develop. The publicPluginRepositories feature remains development-only until review and an intentional release. Keep media browsing and MCP automation under their separate feature flags.

Source checks​

Run these commands from a current HyperHQ checkout:

npm run test:plugin-repositories
npm run test:plugin-repository-native
npm run test:plugin-download-install
npm run test:feature-flags
npm run test:plugin-catalog
npm run build:dev
npx playwright test -c e2e/playwright.config.ts --project=electron e2e/plugin-repositories.spec.ts

The repository tests cover source persistence, overlapping add/remove/toggle operations, official API ID reservations, independent community IDs, installed identity collisions, offline restarts, descriptor selection across Windows, Linux, macOS, x64, and arm64, strict package validation, and author tooling. GitHub and official catalog responses are deterministic fixtures. These tests leave public repositories unchanged.

The native command compiles a fixture executable and exercises canonical hash validation, safe ZIP extraction, staging, promotion, metadata, rollback, and PluginLauncher. It checks fresh install/start, hash rejection, rollback after promotion, successful update/start, saved settings, missing runtime rejection, executable permissions, shutdown, and transaction cleanup. Windows needs the .NET Framework C# compiler. Linux and macOS need cc. Missing compilers fail the test.

WSL execution proves Linux fixture filesystem and process behavior. It does not establish desktop Linux or signed packaged-HyperHQ acceptance. The Windows fixture does not test code signing or a production installer. The change adds no Windows CI runner.

The Playwright fixture uses an isolated Electron profile. It checks controller entry focus, source actions, safe release-note text, and desktop/narrow dark-theme rendering. It does not download a public package.

Packaged release checks​

Use a trusted public stable GitHub release with Windows and Linux ZIPs built through the publisher workflow. Record the HyperHQ commit and build, OS and architecture, repository URL, release tags, ZIP hashes, and results.

  1. In the intended packaged build, find the real release, install and initialize the executable, run an action, complete settings or onboarding, and restart HyperHQ.
  2. Publish the next fixture version. Check manual update and the per-source automatic-update option. Confirm saved settings and plugin-owned data survive. Start the new executable.
  3. Reject a bad hash, missing runtime, an official API ID, conflicting installed identity, wrong OS or architecture, and older version without replacing the working installation. Confirm a new community ID can install without API registration. Use deterministic tests for a persistence-failure rollback instead of corrupting a user's install.
  4. Confirm offline or rate-limited refresh keeps installed files. Confirm source removal stops updates and keeps the installed plugin. Test uninstall separately.
  5. Check controller focus, release-note text, contrast, and narrow layout in the packaged renderer. Confirm app shutdown leaves no plugin child.
  6. Run Windows and desktop Linux acceptance for each advertised architecture. Record native macOS results before advertising macOS support.

After review and release acceptance, launch the feature in a separate commit: set publicPluginRepositories.production to true, releaseStatus to released, and changelog to include; update the flag tests and add a public Release-Note: trailer. Rebuild and deploy HyperHQ using its release process. Source integration alone does not enable an existing installation.