Avoid exporting the dashboard view from the reports plugin entrypoint to reduce CSS import crash risk.
- stop re-exporting ReportsDashboardView from the plugin index module
- keep the dashboard view registered through componentPath without loading dashboard-only code on import
Files changed:
plugins/fusion-plugin-reports/src/index.ts | 1 -
1 file changed, 1 deletion(-)
Fusion-Task-Id: FN-6095
Fusion-Task-Lineage: 8737a009-7466-42fd-b616-d3b89d84b6a6
The api stub from 43be32bbd silenced the fetch-rejection path but the suite
still failed on CI: the actual unhandled error is React's scheduler firing
deferred work via setImmediate after jsdom is torn down — its internal
render then dereferences `window` and throws ReferenceError. @testing-library
only auto-registers cleanup() when vitest `globals: true` is set, and this
package doesn't enable globals, so the React tree from each render() stays
mounted across teardown. Register cleanup manually in test-setup.ts so every
dashboard test unmounts its tree before the environment tears down.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ReportDetailPanel transitively calls useReportPreview, which fires fetch()
from api.ts. jsdom has no fetch, the promise rejects, and the catch handler's
setError triggers a React update after the test environment is torn down —
React then accesses window and the suite fails with ReferenceError. The
engine failures previously masked this by failing the shard before the
teardown race could surface. Mocking the api module makes the preview
resolve synchronously and keeps the suite clean.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Remove duplicate coreSetup from reports-dashboard project setupFiles.
With extends: true, coreSetup is already inherited from the root config.
Only dashboardSetup needs to be explicitly added at the project level.
Resolves CI failures where Node.js 24 caused ReferenceError: window is not defined
in non-dashboard tests that shared setupFiles with dashboard tests.
Follows the same pattern already used by fusion-plugin-roadmap: split into two
vitest projects with proper environment isolation:
- reports-dashboard: jsdom, includes src/dashboard/** tests + dashboard test-setup.ts
- reports-node: node, includes all other tests, excludes dashboard tests
No test changes — same 104 tests, same pass/fail state.
- Add reports plugin to bundled plugin resolver so it can be installed from packaged assets
- Expose reports plugin in dashboard plugin manager and server routes for one-click install flows
- Add CLI and dashboard test coverage for bundled install behavior and plugin route availability
- Update reports/plugin management/settings docs and include a changeset for @runfusion/fusion
Completes FN-3939 audit work for PR #59 residual defects by refactoring the mission execution loop in the engine (halving its complexity), adding self-healing test coverage, and wiring in task workflow route improvements. Retry and validation behavior updates are documented in the changeset and skil
Fusion-Task-Id: FN-3939
Added an approval workflow to the reports plugin comprising a state machine (`approval.ts`), share blocks logic (`share-blocks.ts`), API routes for approvals, and two new dashboard panels (ReportApprovalPanel and ShareBlocksPanel), with corresponding tests; also updated the plugin README and added a
Fusion-Task-Id: FN-3787
Fixes a tablet layout and viewport regression in the Reports view, updating the corresponding test to cover the corrected behavior.
Fusion-Task-Id: FN-3453
