The research pane

crates/vike-studio/src/research.rs's header names the pane in one line: the studies a user has written, the ONE button that runs one, and the runs that came out — the Studio's sibling of the Sweep pane, dispatching through crates/vike-studio-core/src/study_dispatch.rs instead of the backtest engine. It invents no second mechanism: the dispatch is a worker thread whose result StudioState::poll folds, and the outcome lands in the same centre panel a backtest's does. What a study is belongs to the research tree (studies, running a study); this page is the surface.

One list for both tiers

list_studies returns the rhai tier and the rust tier as rows of one list, differing only in a StudyTier tag, and the only match that decides how a study RUNS lives in run_study_plan. So the pane has one list, one Run button and no second surface for either tier. The tier shows as a badge because it is a fact a user acts on, and the hover says which: interpreted, compiled at run time from the folder, so a shipped binary can run it; or compiled, resolved through a registry generated at build time, so it runs only on a binary built from a checkout that held it (Rhai studies, Rust studies).

Scanning is lazy: the first frame the tool is opened reads both listings, a session that never opens it reads no directory at all, and ⟳ Rescan re-reads user_data/research/studies and user_data/runs. Everything a scan could not use renders as a red row rather than an absence — crates/vike-studio-core/src/listing.rs's rule that a run which vanishes from a list is worse than one that shows as broken.

Where it reads from

The pane resolves no path. StudyHost — the studies root <project>/user_data/research/studies, the runs root <project>/user_data/runs, a scratch directory, the producing binary's name and its commit if it can name one — is set by the binary after construction, for the same reason the store's remoteness and the backend are: a library resolves no project root. crates/vike-desktop/src/main.rs's studio_study_host derives it from the settings directory the app already resolved, honouring VIKE_USER_DATA_DIR outright, and records produced_by as vike-desktop with no commit, which its doc calls the honest answer for a binary that reaches build info only through its boot crate.

No host is the ordinary state of a binary launched from outside any project, and it is disclosed: the pane renders NO_HOST — "No project folder above this working directory, so there is nowhere to read studies from and nowhere to put a run. Launch the app from inside a project, or set VIKE_SETTINGS_DIR to name one." — and lists nothing and arms nothing. A project with no studies reads NO_STUDIES, which names the two folders a study can live in.

Recipe, window, learner

A recipe is a .toml beside the study's entry file, one named configuration, and neither runner reads it — the caller does. The Recipe picker's index 0 is (no recipe), which runs the study with no configuration and records that it had none; the rest are the folder's .toml files in name order. Selecting a different study resets the picker, because recipe 2 of one study has nothing to do with recipe 2 of another. The recipe is read when the plan is built, so a file that will not parse is refused before dispatch, with the file named beside the picker that chose it.

Window is the picked data slice's range, or "the whole store (no data slice picked)". StudioState::study_window's doc is careful that this is not a gate: a study reads whatever series it likes through its own context verbs, so the window is a fact the run records and the default its read verbs take — requiring a slice would be an invented coupling, since a backtest replays that exact series and a study does not.

▶ Run study is enabled with a study selected and nothing running; it dispatches through spawn_study and leaves a run behind in user_data/runs. When the run lands, only the runs list is re-scanned — no study folder can have changed by running one.

The runs list holds no numbers

The Runs section lists every run of every kind, newest first, each with a kind badge — the manifest's kind, the one top-level field a reader may branch on. kind_color gives three answers on purpose: a study run in the accent colour, a backtest run in the success colour, and a kind this build does not recognise in the warning colour under its own name, because kinds grow in crates that cannot see each other and "I do not know this one" is an answer a reader needs. Hover shows who produced it, when it started, and "no report on disk" when the report is missing; a footer names which runs tree the rows are about (runs on disk).

RunRow carries no metric at all, and a test holds it there over a manifest whose metrics are populated. The pane's own blurb: "Numbers live in the run, never in this list — a study's Sharpe and a backtest's are not the same measurement." crates/vike-studio-core/src/study_run.rs nests a study's metrics under detail.metrics precisely so a listing that never asked which scorer produced a number cannot render it in a shared column.

The result surface

study_result_ui is the centre panel for one study run, and it is deliberately not the backtest results pane: that renders an equity curve, a trade list and eleven event-driven metrics, and a study produces none of them. It shows the run's facts — study, produced by, started, finished, window, whether a learner was supplied, where it was saved — then a Metrics table in which a non-finite value renders as IEEE-754's own token through nonfinite_tag rather than as 0.00, because a NaN Sharpe over a fold that never traded is an observation the manifest keeps; then any artifacts by name and size; and finally STUDY_METRICS_NOTE verbatim, the sentence the library writes into every study run's manifest so that a file read alone still carries the distinction. A study that recorded nothing says so rather than rendering a gap.