Files
fusion/packages
gsxdsm 0698ce6f9c test(dashboard): restore the missing api mock export in ResearchView tests (#3239)
## What

Partial fix for **red main**. Test-only.

`ResearchView.test.tsx` has **4 failing tests on main**; 2 fail with:

```
No "fetchBoardWorkflows" export is defined on the "../../api" mock
```

The `vi.mock("../../api")` factory **replaces the whole module**, so
every import anywhere in the rendered tree must appear in it.
`fetchBoardWorkflows` reached this file *indirectly* — the task modals
ResearchView opens import it — so adding that export to product code
broke four cases that have nothing to do with board workflows.

Stubbed with the flag-OFF payload the server sends when multi-lane
boards are disabled, which is the shape these cases already assume.

## Measured

```
before: Tests 4 failed | 23 passed (27)
after:  Tests 2 failed | 25 passed (27)
lint clean; fnxc-future-dates: none added
```

## The remaining 2 are a different cause and are NOT fixed here

They fail with `Number of calls: 0` — the enrich-task and create-task
actions never fire. That is a UI-wiring question, not mock completeness.

**I checked that my stub is not responsible**, rather than assuming:
re-running with `flagEnabled: true` and a populated workflow list
produces the *same* 2 failures, so the payload shape does not gate those
affordances. Left for whoever owns that surface.

## How this was found

While establishing a clean baseline for the resolver audit. That sweep
also reported `lazy-loaded-views-docs.test.ts` red — **it now passes**,
fixed by another worker between my measurement and this PR, which is why
the count here is 3 files rather than the 4 I reported in #3236.

Still red on main, untouched by this PR:
- `src/__tests__/planning-browser-e2e.test.ts` — `expected {
totalButtons: 1, …(7) } to match object { totalButtons: 1, …(6) }`; an
assertion shape gained a field.
- `src/__tests__/register-model-routes-kimi-k3-supplemental.test.ts` —
`Test timed out in 15000ms`. Per the standing rule a timeout with no
corresponding bug in the change is a **quarantine candidate**, not
something to appease with a longer timeout; I am not quarantining it
unilaterally since it is not my subsystem, but flagging it as the shape
that rule describes.
2026-07-31 13:33:51 -07:00
..
2026-07-26 18:11:47 -07:00