feat(apollo-vertex): custom evaluator renderer registry for solution-tests

[RobinMennens-UiPath]

What & why

Back-port of the solution-tests custom-evaluator work from the FINS vertical solution (UiPath/fins-vertical-solution#604). Adds a custom evaluator renderer registry so a consumer can register its own evaluator result components — keyed by evaluator id — through the existing SolutionTestsConfig, without editing the registry component.

This is the frontend counterpart to the solution-test backend, where a vertical registers custom evaluators (e.g. a custom LLM-as-a-judge with a tailored prompt but the same {score, justification} output). The FE just needs to map that new evaluator id to a component — usually the existing generic card.

Changes (registry/solution-tests)

• config.ts — SolutionTestsConfig.evaluatorRenderers?: EvaluatorRenderers, defaulted in resolveConfig.
• evaluators/registry.tsx — resolveEvaluatorRenderer(id, verticalRenderers?) resolves vertical > built-in > generic fallback. Renderer-specific config is bound at registration, not threaded through the runtime call site: genericRenderer({ label }) captures a display label; makeRenderer(schema, Component, bound) spreads bound props into the component. So EvaluatorRenderer's runtime signature stays uniform as renderers gain params.
• evaluator-results-view.tsx — reads evaluatorRenderers from context and passes it to the resolver.
• evaluators/generic-evaluator-result.tsx — takes the display label as a bound prop (label ?? evaluatorId).
• constants.ts — removed the standalone EVALUATOR_LABELS table; built-in labels now live on their registry entries (single source of truth).
• index.ts — exports makeRenderer, genericRenderer, resolveEvaluatorRenderer, GENERIC_RENDERER, the evaluator-id constants, and the renderer types.

Checks

tsc --noEmit, oxlint --type-aware, and depcruise registry all pass (the 10 dep-cruiser warnings are pre-existing in shell/ai-chat, unrelated).

🤖 Generated with Claude Code

[github-actions]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (PT)
apollo-design	🟢 Ready	Preview, Logs	Jul 03, 2026, 08:43:51 AM
apollo-docs	🟢 Ready	Preview, Logs	Jul 03, 2026, 08:43:51 AM
apollo-landing	🟢 Ready	Preview, Logs	Jul 03, 2026, 08:43:51 AM
apollo-vertex	🟢 Ready	Preview, Logs	Jul 03, 2026, 08:43:51 AM

[github-actions]

Dependency License Review

• ✅ 1945 package(s) scanned
• ✅ No license issues found
• ⚠️ 2 package(s) excluded (see details below)

License distribution

License	Packages
MIT	1715
ISC	89
Apache-2.0	55
BSD-3-Clause	27
BSD-2-Clause	23
BlueOak-1.0.0	8
MPL-2.0	4
MIT-0	3
CC0-1.0	3
MIT OR Apache-2.0	2
(MIT OR Apache-2.0)	2
Unlicense	2
LGPL-3.0-or-later	1
Python-2.0	1
CC-BY-4.0	1
(MPL-2.0 OR Apache-2.0)	1
Unknown	1
Artistic-2.0	1
(WTFPL OR MIT)	1
(BSD-2-Clause OR MIT OR Apache-2.0)	1
CC-BY-3.0	1
0BSD	1
(MIT OR CC0-1.0)	1
MIT AND ISC	1

Excluded packages

Package	Version	License	Reason
@img/sharp-libvips-linux-x64	1.2.4	LGPL-3.0-or-later	LGPL pre-built binary, not linked
khroma	2.1.0	Unknown	MIT per GitHub repo, missing license field in package.json

[Copilot]

Pull request overview

Adds a configurable evaluator-renderer registry to the apps/apollo-vertex/registry/solution-tests feature so consuming verticals can register custom evaluator result components (keyed by evaluator id) via SolutionTestsConfig, without modifying the built-in registry.

Changes:

• Extends SolutionTestsConfig with evaluatorRenderers and defaults it in resolveConfig.
• Introduces a renderer registration/resolution API (makeRenderer, genericRenderer, resolveEvaluatorRenderer) with precedence vertical > built-in > generic fallback.
• Moves built-in evaluator display labels into the built-in registry entries and removes the standalone EVALUATOR_LABELS map.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
apps/apollo-vertex/registry/solution-tests/index.ts	Exports the new renderer helpers/types and built-in evaluator id constants for consumers.
apps/apollo-vertex/registry/solution-tests/evaluators/registry.tsx	Implements renderer creation/binding and resolution with vertical override support.
apps/apollo-vertex/registry/solution-tests/evaluators/generic-evaluator-result.tsx	Accepts a bound label prop (fallback to evaluator id) for the generic evaluator card.
apps/apollo-vertex/registry/solution-tests/evaluator-results-view.tsx	Pulls evaluatorRenderers from config context and passes them into renderer resolution.
apps/apollo-vertex/registry/solution-tests/constants.ts	Removes the EVALUATOR_LABELS mapping now embedded in the registry.
apps/apollo-vertex/registry/solution-tests/config.ts	Adds evaluatorRenderers to config types and applies a default {} in resolveConfig.

[github-actions]

📊 Coverage + size by package

Per-package bundle size on this PR (no JS/TS source changes detected under packages/* or web-packages/*).

Package	Coverage	New-line coverage	Packed (gzip)	Unpacked	vs main
@uipath/apollo-core	9.0%	—	43.82 MB	57.31 MB	±0
@uipath/apollo-react	34.5%	—	7.27 MB	27.60 MB	±0
@uipath/apollo-wind	40.1%	—	392.6 KB	2.55 MB	+15 B
@uipath/ap-chat	85.8%	—	43.41 MB	55.85 MB	±0

_{"Coverage" is each package's own coverage.include scope (e.g. apollo-core instruments only scripts/). "Packed"/"Unpacked" come from npm pack --dry-run and only cover built packages — "—" means not measured this run (package not affected / not built). "vs main" is the packed (gzipped) delta against the last successful main build (the package-sizes artifact from the Release workflow); "—" there means no main baseline was available this run. The baseline is main's latest build, not this PR's exact merge-base, so it includes any drift since the branch diverged. Packages with no vitest config are omitted.}