- Expand the directory-path follow-up section: PR #1428, 400 no-entry
branch, heal-on-enable in both routers
- Document the vitest fs-mock vs externalized workspace-dep trap and
the real-fs drift-guard test pattern
- Add Plugin Entry to CONCEPTS.md Plugins cluster
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Bundled fallback assertions for dependency-graph/reports now require
the bundled.js entry-file suffix instead of just containing the id
- Add route-level fallback cases for dist/index.js and src/index.ts
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Add heal block to createPluginRouter's enable handler so it matches
routes.ts (directory-path registrations re-pointed at entry files)
- Test the 400 "no loadable entry file" install branch
- Add a real-fs drift-guard test asserting the CLI and @fusion/core
copies of resolvePluginEntryPath resolve identically
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Plugins installed from Settings → Built-in Plugins registered the
manifest directory as the plugin path, but since FN-4128 the loader
requires a loadable entry FILE (Node ESM cannot import directories),
so enabling failed with "Plugin entry must be a file, got directory".
Only the CLI startup path had been migrated to entry-file resolution,
which is why CLI-auto-installed plugins worked and Settings installs
never did.
- Add resolvePluginEntryPath (bundled.js → dist/index.js →
src/index.ts) to @fusion/core; the CLI keeps its local copy (its
test fs mocks don't reach externalized core) with sync comments
both ways.
- Register the resolved entry file in both dashboard install routes;
400 with a clear message when a package has no loadable entry.
- Heal legacy directory-path registrations on enable, mirroring the
CLI's startup heal, so existing broken rows recover from the UI
without a restart.
- Route tests: assert installs register entry files, cover the
enable-route heal, and update existing install tests to the
entry-file contract.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- restore customFields on unarchive; reconcile all occupants on field-schema edits (store.ts)
- serialize per-field saves + controlled inputs in TaskFieldsSection (race fixes)
- fn_workflow_get includes layout; Array.isArray guards in validateCodeNodeSources
- per-instance graphStepActiveContext keying; rebase in instance worktree; clear run-once memo on RETHINK
- GET /api/step-parsers + registry-backed parser select (plugin parsers reachable from editor)
- translate new workflowNodes/workflowFields strings across all 5 non-en locales
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Capture the 4-list registration requirement for bundled plugins
(Settings catalog, dashboard fallback set, CLI auto-install list,
tsup staging) in docs/solutions/, and add the Bundled Plugin concept
to CONCEPTS.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Installing the Compound Engineering plugin from Settings → Built-in
Plugins failed with "Plugin manifest not found": the dashboard's
bundled-plugin fallback set (BUNDLED_PLUGIN_IDS in routes.ts) was
missing fusion-plugin-compound-engineering, so when the relative
./plugins/... path missed the server cwd, the bundled lookup was never
attempted. fusion-plugin-cli-printing-press had the same gap.
- Add both ids to the dashboard's BUNDLED_PLUGIN_IDS fallback set.
- Stage fusion-plugin-compound-engineering into dist/plugins via
bundlePluginEntry in the CLI tsup config so packaged installs can
resolve the bundled copy (every other bundled plugin already had a
staging block).
- Add route tests that actually exercise the bundled fallback (the
existing ones let cwd resolution succeed, so the fallback path was
untested).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
