Main went red when the fast-tests quality-backfill projects (PR #1385)
landed alongside the workflow-columns stream (PR #1424) — the new test
projects were written against pre-stream code:
- TaskFieldsSection.css toggle knob used background: #fff, violating the
theme-token assertion in AgentListModal's styling-parity test; use
var(--card) per the SkillsView toggle convention
- ListView.test.tsx api mock lacked fetchBoardWorkflows (TaskDetailModal
now calls it on mount)
- chat.test.ts and routes-agent-import.test.ts @fusion/core mocks lacked
registerTraitHookImpl (engine merge-trait registers hooks at import)
- auto-merge-toggle-blank.mobile and board-mobile-initial-render used
vi.runAllTimers(), which never terminates now that sse-bus starts a
keepalive setInterval; use vi.runOnlyPendingTimers()
Both quality-backfill projects now pass fully: 7151/7151 across 414
files.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- 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>
