feat(website, config): create a customDisplay for reference with variant information

[anna-parker]

This adds an additional custom display, similar to the custom display for length and completeness, but in this case for assigned reference and variant strain, where variant strain is a boolean based on the number of private mutations a sequence has - this is currently in use on the private virus preview and has been enabled for cchf multi-ref for testing purposes.

Screenshot

PR Checklist

• All necessary documentation has been adapted.
• The implemented feature is covered by appropriate, automated tests.
• Any manual testing that has been done is documented (i.e. what exactly was tested?) -> tested on preview

🚀 Preview: Add preview label to enable

[claude]

Claude finished @anna-parker's task in 2m 27s —— View job

---

Code Review

• Gather context and read changed files
• Review code quality and logic
• Check tests
• Post review feedback

---

The overall approach is clean. The customDisplay: variantReference type groups the reference and variant backend fields into a single UI row showing the closest reference optionally annotated with "(variant)". Propagating referenceGenomesInfo down through DataTable → DataTableEntry → DataTableEntryValue is the right design. The preprocessing change (extracting the error message into a variable before both logging and adding it to the annotation) is a nice small improvement.

One real bug to fix:

VariantReferenceComponent iterates over segmentDisplayNames (line 101), but segmentDisplayNames is only populated for segments that have an explicit displayName set in the config (see toReferenceGenomes). For any organism — including all single-segment organisms — where a segment has no displayName, the loop body never executes and the component always renders "N/A". Iterating over segmentReferenceGenomes instead avoids this. See inline comment.

The test file covers the important cases well, but there's no test that would catch the above bug — see inline comment on the test file.

[theosanderson]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a3674d37a4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[theosanderson]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 842956664f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[theosanderson]

Personally I don't find this intuitive - if I see

Closest reference: A (variant)

I would assume that the closest reference is a variant of A, rather than that this sequence is a variant. But it's not my area

[anna-parker]

Is there a different display you would find more intuitive? Also tagging @rneher as he requested this. Perhaps closest reference should be changed? We could call it L segment lineage: A (variant) would that be clearer?

[theosanderson]

I don't have a great instinct - but yes, I guess that would be clearer but then I'm not sure if that naming is actually accurate - would this use case be called a lineage in the cases we're interested in?