Symmetry and Data Augmentation by Scienfitz · Pull Request #626 · emdgroup/baybe

Scienfitz · 2025-08-21T15:01:05Z

Implements #621

New: A Symmetry class which is part of baybe Surrogates. Three distinct symmetries are included, for more info check the userguide and for a demonstration of the effect see the new example. The ability to perform data augmentation has been included for all symmetries.

I have left some initial comments on design questions that are still open or where I am kind of indifferent and just had to choose one. Feel free to leave an opinion there first so the large-scale design picture can be finalized independent of small comments.

TODO

CHANGELOG (after architecture is logged in)
Remember to compress finalized svg picture

Other Notes
Symmetries and constraints are conceptually so similar that they should probably have the same interface. The design here has been done from scratch completely ignoring the constraint interface because it is already known to be not optimal and needs refactoring.

There is no overarching shared attribute parameters or similar because some symmetries allow single and some multiple such parameters. Instead the parameters are treated like the objectives treat target(s)
Contrary to dependency constraint, dependency symmetry can only hold 1 set of dependencies. The constraint should be refactored to look the same.
There is one exception I made but I'm open to still changing it

AVHopp · 2025-08-25T07:31:31Z

@Scienfitz just to make sure - I guess since this is marked as a draft, you do not require a PR review for now, right? Is there anything else that we can assist with?

Scienfitz · 2025-08-26T15:04:57Z

@AVHopp yes exactly and it will always be like that for PR's that I open in draft: Ignore until requested or asked in any other way

Scienfitz · 2025-11-03T17:14:11Z

baybe/symmetries.py

So far this is a large monolith of a file. Large part of this is validation, so I can see how this is just split up into

symmetries

symmetries.base

symmetries.core

symmetries.validation

However this would require outsourcing the content of the validate_searchspace_context, so they would effectively become empty hulls calling a utility imported from symmetries.validation. I also like the closeness of the Raises section and the functional content to the actual class. So Im not sure if I should outsource the validations.

Agree, I would also prefer the current structure over the split that you described above. Food for thought: What about splitting as follows:

symmetries

symmetries.core

symmetries.permutation

symmetries.mirror

symmetries.dependency

Scienfitz · 2025-11-03T17:18:24Z

baybe/symmetries.py

+
+    # Object variables
+    # TODO: Needs inner converter to tuple
+    copermuted_groups: tuple[tuple[str, ...], ...] = field(


This is the only exception where I did still somewhat follow the design of the corresponding constraint. Because all cosntraints share parameters this symmetry requires to specify copermuted_groups as separate attribute. But actually all the groups could be combined into a single attribute.

Instead of parameter_names=["a1", "a2"] and copermuted_groups=[["b1", "b2"],["c1","c2"]] we would have permutation_groups = [["a1","a2"], ["b1", "b2"], ["c1","c2"]]. This is certainly more lgical but maybe a bit less userfirendly if there is really just 1 group.

This would have as consequence that we need to (re)define what the parameters property even should contain or whether it should even be dropped.

In the absence of opinions this wills tay as it is.

I have to say that I find the concept of the copermuted_gourps very weird. Maybe I am misunderstanding, but isn't this the same as having multiple permutations at once? But I will ask you this in person, since I guess that this will be significantly easier to explain verbally.

its not the same because the copermuted groups are not permuted independent of the primary group, but in exactly the same way as the primary group. Imagine it like

taking an iterable (the primary group)

then get all permutations of the index of that iterable

create all permutations of the original iterable by applying all permuted indices

Now you also apply the permuted indices to other iterables (called copermuted groups)

As I wrote in my comment I would be open to get rid of the primary and copermuted groups by combining them into one single attribute, but it would have a very different interface for Symemtries as consequence (where we even have to debate whether Symmetries (and bye xtension also constraints)) can have a propert like .parameter_names and what it would mean

I now get the concept of co-permuted groups. I am not sure about whether or not we would want to combine primary and co-permuted groups. My gut feeling is that co-permuted groups will often not be really necessary for the user, so sacrificing a nicer and cleaner interface for this does not feel right to me.
Do maybe @AdrianSosic and @kalama-ai have opinions here?

Scienfitz · 2025-11-03T17:22:53Z

baybe/recommenders/pure/bayesian/base.py

+        # Validate compatibility of surrogate symmetries with searchspace
+        if hasattr(self._surrogate_model, "symmetries"):
+            for s in self._surrogate_model.symmetries:
+                s.validate_searchspace_context(searchspace)


Important: Validation so far is only part of the recommend call here in the recommenders. Validation has not been included in the Campaign yet. This is due to two factors

To properly validate the symmetries and searchspace compatibility there needs to be a mechanism that can iterate over all possible recommenders of a metarecommender. Otherwise this upfront validation already fails for the two phase recommender if the second recommender has symmetries

There would be double validation with campaign and recommend call so the context info of whether validation was already performed needs to be passed somewhere. Likely fixable with settings mechanism not yet available

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Copilot

Pull Request Overview

Copilot reviewed 27 out of 29 changed files in this pull request and generated 3 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

tests/hypothesis_strategies/symmetries.py

baybe/symmetries.py

baybe/utils/augmentation.py

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

AdrianSosic

Hi @Scienfitz, here my first batch of comments. Still need to finalize the dependency symmetry and the docs, but my github UI is getting so slow that I feel I need to submit the pending comments 😬

AdrianSosic · 2025-11-17T07:17:05Z

baybe/constraints/base.py

    eval_during_modeling: ClassVar[bool]
    """Class variable encoding whether the condition is evaluated during modeling."""

-    eval_during_augmentation: ClassVar[bool] = False


Do we need a REMOVED entry in the changelog?

imo no as it was not really used

AdrianSosic · 2025-11-17T07:21:04Z

baybe/constraints/discrete.py

+
+        return PermutationSymmetry(
+            parameter_names=self.parameters,
+            copermuted_groups=(tuple(self.dependencies.parameters),)  # type: ignore[arg-type]


why is there an explicit tuple conversion here

why do we need the type silencing

--> Neither should be required when the field converters are properly set up

I mean the attribute expects a tuple, so I am providing a tuple. Are you criticising this?

The type silence here was something that I actively tried to fix but that seems to be very hard. Now I dont remember the details tho I would have to check again

AdrianSosic · 2025-11-17T07:32:31Z

baybe/utils/conversion.py

    return tuple(x)


+def normalize_str_sequence(


The newly introduced name is misleading and the introduced type hint is wrong, because:
you introduced this function when we enabled Booleans for categorical parameters. Both name and type hint suggest that the incoming object is already a sequence of strings, which is not the case – it's more generally a sequence of "convertible to string", and right now we use it for str/bool.

AdrianSosic · 2025-11-17T08:22:00Z

baybe/surrogates/base.py

+    def augment_measurements(
+        self, data: pd.DataFrame, parameters: Iterable[Parameter]
+    ) -> pd.DataFrame:
+        """Apply data augmentation to measurements.
+
+        Args:
+            data: A dataframe with measurements.
+            parameters: Parameter objects carrying additional information (might not be
+                needed by all augmentation implementations).
+
+        Returns:
+            A dataframe with the augmented measurements, including the original ones.
+        """
+        for s in self.symmetries:
+            data = s.augment_measurements(data, parameters)
+
+        return data
+


I think we should call the dataframe measurements to be consistent with the remaining code, right?

Suggested change

def augment_measurements(

self, data: pd.DataFrame, parameters: Iterable[Parameter]

) -> pd.DataFrame:

"""Apply data augmentation to measurements.

Args:

data: A dataframe with measurements.

parameters: Parameter objects carrying additional information (might not be

needed by all augmentation implementations).

Returns:

A dataframe with the augmented measurements, including the original ones.

"""

for s in self.symmetries:

data = s.augment_measurements(data, parameters)

return data

def augment_measurements(

self, measurements: pd.DataFrame, parameters: Iterable[Parameter]

) -> pd.DataFrame:

"""Apply data augmentation to measurements.

Args:

measurements: A dataframe with measurements.

parameters: Corresponding parameter objects carrying additional information

(not needed by all augmentation types).

Returns:

A dataframe with the augmented measurements, including the original ones.

"""

for s in self.symmetries:

measurements = s.augment_measurements(measurements, parameters)

return measurements

AdrianSosic · 2025-11-17T08:42:59Z

baybe/utils/validation.py

+
+
+def validate_is_finite(  # noqa: DOC101, DOC103
+    _: Any, attribute: Any, value: float | Sequence[float]


Let's put the proper Attribute type hint here

baybe/symmetries.py

AdrianSosic · 2025-11-18T16:06:58Z

baybe/symmetries.py

+
+    # object variables
+    mirror_point: float = field(
+        default=0.0, converter=float, validator=validate_is_finite, kw_only=True


Any reason why it's kw_only? Don't think it's strictly necessary here...

Suggested change

default=0.0, converter=float, validator=validate_is_finite, kw_only=True

default=0.0, converter=float, validator=validate_is_finite

Also not 100% sure if it reasonable to assume a default here. What kind of data would be mirrored around exactly 0? Seems to me like an edge-case resp. some default that makes sense in theory but not really in pratice

huh? I think 0 is an obvious default because it will be the chosen value for all cases like only the magnitude matters which is a mirror symmetry around 0. I actually think it will be hard to find a real use case for it not being 0

True, I misread that. I will leave this thread open as there is still the question regarding the kw_only where I do not have a strong opinion on.

AdrianSosic · 2025-11-18T16:07:37Z

baybe/symmetries.py

+
+    @override
+    def augment_measurements(
+        self, df: pd.DataFrame, _: Iterable[Parameter]


df --> measurements

AdrianSosic · 2025-11-18T16:14:02Z

baybe/symmetries.py

+    A dependency symmetry expresses that certain parameters are dependent on another
+    parameter having a specific value. For instance, the situation "The value of
+    parameter y only matters if parameter x has the value 'on'.". In this scenario x
+    is the causing parameter and y depends on x.


Comment regarding terminology, here and in other docstrings: since the name is "DependencySymmetry" and we talk about the "dependent parameters":

Wouldn't make sense to call the "causing" parameter the "independent parameter" instead? Would be more consistent and also solves the problem that "causing" sort of implies a causal relationship from x to y (in the sense that x physically affects y) which is not the case

You call them "dependent" parameters, which is fine to me, but why do you then call the corresponding attribute "affected"?

AVHopp

First set of comments, only on user guide and example without having looked at the code. Like them both quite a lot, comments are mostly minor.

AVHopp · 2025-11-24T09:12:56Z

docs/userguide/symmetries.md

+Below we illustrate the effect of data augmentation for the different symmetries
+supported by BayBE:
+
+![Symmetry and Data Augmentation](../_static/symmetries/augmentation.svg)


For the left image of the DependencySymmetry, I think it would make more sense tao add some ticks to the y axis and mark the y.values in that way.

AVHopp · 2025-11-24T09:14:26Z

docs/userguide/symmetries.md

+:class: warning
+Invariant kernels will be applied automatically when a corresponding symmetry has been 
+configured for the surrogate model GP. This feature is not implemented yet.
+```


This is confusing: For me, the first sentence reads like "This is already implemented", so I would reformulate this

Since I am not (yet) fully done with the PR, maybe a suitable explanation would be "Ideally, invariant kernels will be applied automatically...."?

examples/Symmetries/permutation.py

AVHopp · 2025-11-24T09:19:18Z

examples/Symmetries/permutation.py

+# (a common way of also resulting in permutation invariance) and have multiple minima.
+# In practice, permutation invariance can arise e.g. for
+# [mixtures when modeled with a slot-based approach](/examples/Mixtures/slot_based).
+# BayBE supports other kinds of symmetries as well (not part of this example).


I would simply delete this sentence or replace it with a link to the user guide, because why mention this here?

examples/Symmetries/permutation.py

AVHopp · 2025-11-24T09:31:17Z

examples/Symmetries/permutation.py

+# We set up a constrained and unconstrained searchspace to demonstrate the impact of
+# the constraint on optimization performance.


Suggested change

# We set up a constrained and unconstrained searchspace to demonstrate the impact of

# the constraint on optimization performance.

# We set up a constrained and an unconstrained searchspace to demonstrate the impact of

# the constraint on optimization performance.

Maybe even mention the word "plain" here such that the description is closer the the code?

AVHopp · 2025-11-24T09:34:18Z

examples/Symmetries/permutation.py

+print(f"{'Without Constraint:':<35} {len(searchspace_plain.discrete.exp_rep)}")
+print(f"{'With Constraint:':<35} {len(searchspace_constrained.discrete.exp_rep)}")
+
+# We can see that the searchspace without the constraint has more points than the other


Naively, I would have expected a factor of 2 as the difference. It is clear that this factor is not met explicitly due to the diagonal to me, but I'm asking myself if we should maybe add a comment like "We can see that the searchspace without the constraint has roughly doubler the number of points compared to the unconstrained one. This is exactly what we expect, as we only model one half of the parameter triangle. Note that it is not a factor of exactly 2 due to the points on the diagonal"

AVHopp · 2025-11-24T09:45:23Z

examples/Symmetries/permutation.py

+# subplot.
+
+# BayBE can automatically perform this augmentation if configured to do so.
+# Specifically, surrogate models have the `Surrogate.symmetries` attribute. If any of


Any reason why Surrogate.symmetries is not a link?

examples/Symmetries/permutation.py

AVHopp

Incomplete, but cannot finish today

baybe/symmetries.py

AVHopp · 2025-11-24T12:15:17Z

baybe/symmetries.py

+        Args:
+            df: The dataframe containing the measurements to be augmented.
+            parameters: Parameter objects carrying additional information (might not be
+                needed by all augmentation implementations).


If this is not needed by all types/implementations, why is then not an optional argument?

right I should give it None as default

baybe/symmetries.py

AVHopp · 2025-11-24T12:28:45Z

baybe/symmetries.py

+    copermuted_groups: tuple[tuple[str, ...], ...] = field(
+        factory=tuple, converter=tuple
+    )
+    """Groups of parameter names that are co-permuted like the other parameters."""


Also, co-permuted vs. copermuted is a bit inconsistent (but I think this is the only place where we have the -

baybe/symmetries.py

AVHopp · 2025-11-24T12:56:06Z

baybe/symmetries.py

+        # The input could look like:
+        #  - params = ["p_1", "p_2", ...]
+        #  - copermuted_groups = [["a_1", "a_2", ...], ["b_1", "b_2", ...]]
+        # indicating that the groups "a_k" and "b_k" should be permuted in the same way
+        # as the group "p_k".
+        # We create `groups` to look like (("p1", "a1", "b1"), ("p2", "a2", "b2"), ...).
+        # It results in just (("p1",), ("p2",), ...) if there are no copermuted groups.


I think that this something that belongs into the docstring of the method here: It makes clear to the user what is actually happening and also demonstrates what the copermuted groups are

possible for the first part, but I disagree for the second part (text after We create...) as this merely describes how the input for the utility is crafted which is meant for the dev not the user

Ok, then please adjust the docstring and feel free to simply resolve here afterwards.

AVHopp · 2025-11-24T12:58:39Z

baybe/symmetries.py

+
+    # Object variables
+    # TODO: Needs inner converter to tuple
+    copermuted_groups: tuple[tuple[str, ...], ...] = field(


I have to say that I find the concept of the copermuted_gourps very weird. Maybe I am misunderstanding, but isn't this the same as having multiple permutations at once? But I will ask you this in person, since I guess that this will be significantly easier to explain verbally.

AVHopp

Review is still WIP, but since I won't be able to add more comments soon here is the first batch

baybe/symmetries.py

AVHopp · 2025-11-25T08:41:01Z

baybe/symmetries.py

+
+                ref_vals = set(cast(DiscreteParameter, params[0]).values)
+                if any(
+                    set(cast(DiscreteParameter, p).values) != ref_vals for p in params


Couldn't you start at params[1] here as the first comparison will be between params[0] and ref_vals which is the same?

AVHopp · 2025-11-25T08:44:54Z

baybe/symmetries.py

+            # are not considered here since technically for them this restriction is not
+            # required as al numbers can be added if the tolerance is configured
+            # accordingly.
+            if all(p.is_discrete and not p.is_numerical for p in params):


At least from what I see in this file, it seems like Symmetry can be used for all kinds of search spaces. Wouldn't we then also need to check for ContinuousParameter here whether the bounds are the same as there is no tolerance?

AVHopp · 2025-11-25T08:50:36Z

baybe/symmetries.py

+
+    # object variables
+    mirror_point: float = field(
+        default=0.0, converter=float, validator=validate_is_finite, kw_only=True


Also not 100% sure if it reasonable to assume a default here. What kind of data would be mirrored around exactly 0? Seems to me like an edge-case resp. some default that makes sense in theory but not really in pratice

baybe/symmetries.py

AVHopp · 2025-11-25T09:12:28Z

baybe/symmetries.py

+    def augment_measurements(
+        self, df: pd.DataFrame, parameters: Iterable[Parameter]
+    ) -> pd.DataFrame:
+        # See base class.


This needs a more detailed docstring as it is not obvious what kind of information parameters should carry here.

afaik the base class explains that this info is not used by all derived functions, is that not enough?

Well, but this class now uses the parameters, so in my opinion there should be an explanation on the level of this docstring that explains how this is now used in this child class.

AVHopp · 2025-11-25T13:41:25Z

baybe/utils/validation.py

+def validate_is_finite(  # noqa: DOC101, DOC103
+    _: Any, attribute: Any, value: float | Sequence[float]
+) -> None:
+    """Validate that ``value`` contains no infinity/nan.


Suggested change

"""Validate that ``value`` contains no infinity/nan.

"""Validate that ``value`` contains no resp. is not infinity/nan.

Same for the Raises

baybe/utils/augmentation.py

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Co-authored-by: Alexander V. Hopp <alexander.hopp@merckgroup.com>

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Co-authored-by: Alexander V. Hopp <alexander.hopp@merckgroup.com>

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Co-authored-by: Alexander V. Hopp <alexander.hopp@merckgroup.com>

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

AVHopp · 2025-12-15T13:39:20Z

examples/Symmetries/permutation.py

+UBOUND = 2.0
+
+
+def lookup(df: pd.DataFrame, a=1.0, b=1.0, c=1.0, d=1.0, phi=0.5) -> pd.DataFrame:


Why have these parameters as arguments? The lookup is never used in any other place and since 4/5 parameters are simply equal to 1

Scienfitz added 7 commits August 19, 2025 13:16

Remove obsolete checks

7b864f2

Add flags controlling augmentation

0755ce1

Add data augmentation to Bayesian recommenders

8f52073

Add note

8615291

Move augmentation logic to searchspace

832925d

Remove duplicate doctest

d2f756f

Add dependency augmentation

5ba4cb1

Scienfitz self-assigned this Aug 21, 2025

Scienfitz added the new feature New functionality label Aug 21, 2025

Scienfitz linked an issue Aug 21, 2025 that may be closed by this pull request

Add Data Augmentation for Invariant Contraints #621

Open

Scienfitz mentioned this pull request Aug 24, 2025

Data Input With Invariant Parameters #291

Closed

Scienfitz force-pushed the feature/invariance_augmentation branch from 00cfef8 to 5ba4cb1 Compare September 10, 2025 08:10

Scienfitz added 2 commits September 22, 2025 12:45

Merge: main

6aac456

Add shape based test

82a753b

Scienfitz force-pushed the feature/invariance_augmentation branch 3 times, most recently from bc671eb to db98f64 Compare September 25, 2025 10:32

Scienfitz added 6 commits September 25, 2025 12:38

Add example

9e80f4d

Ignore __pycache__ directory when copying example folders

903b253

Update user guide

f5dc61c

Refine example

a1a9b61

Update CHANGELOG.md

e9db037

Merge branch 'main' into feature/invariance_augmentation

0b10d91

Scienfitz force-pushed the feature/invariance_augmentation branch from db98f64 to aedafa7 Compare September 25, 2025 10:41

Scienfitz marked this pull request as ready for review September 25, 2025 11:01

Scienfitz requested review from AVHopp and AdrianSosic as code owners September 25, 2025 11:01

Copilot AI review requested due to automatic review settings September 25, 2025 11:01

Fix doc

713b734

Scienfitz commented Nov 3, 2025

View reviewed changes

Scienfitz marked this pull request as ready for review November 3, 2025 17:31

Scienfitz requested a review from Copilot November 4, 2025 08:59

Copilot AI reviewed Nov 4, 2025

View reviewed changes

Scienfitz requested a review from Copilot November 4, 2025 11:55

Copilot AI reviewed Nov 4, 2025

View reviewed changes

tests/hypothesis_strategies/symmetries.py Outdated Show resolved Hide resolved

baybe/symmetries.py Outdated Show resolved Hide resolved

baybe/utils/augmentation.py Outdated Show resolved Hide resolved

Scienfitz and others added 2 commits November 4, 2025 12:58

Fix typo in baybe/symmetries.py

dcc183c

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Fix typo in baybe/utils/augmentation.py

b46013f

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

This comment was marked as outdated.

Sign in to view

Copilot AI mentioned this pull request Nov 4, 2025

Fix max_value calculation in permutation_symmetries strategy #688

Closed

Fix calculation of n_copermuted_groups

466e6dc

AdrianSosic requested changes Nov 18, 2025

View reviewed changes

AVHopp reviewed Nov 24, 2025

View reviewed changes

AVHopp reviewed Nov 26, 2025

View reviewed changes

Scienfitz and others added 12 commits December 12, 2025 16:28

Update docstring

3ed9394

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Improve docstring language

8e01b9f

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Improve error message

9d6c94a

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Fix language

6092e37

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Improve language

5c7b977

Co-authored-by: Alexander V. Hopp <alexander.hopp@merckgroup.com>

Fix language

81d2136

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Improve error message

f397da7

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Improve language

552b8d5

Co-authored-by: Alexander V. Hopp <alexander.hopp@merckgroup.com>

Improve error message

46bb49a

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

Improve language

f137e07

Co-authored-by: Alexander V. Hopp <alexander.hopp@merckgroup.com>

Improve formatting

e59724f

Co-authored-by: Alexander V. Hopp <alexander.hopp@merckgroup.com>

Extend explanation

ae24de0

Co-authored-by: AdrianSosic <adrian.sosic@merckgroup.com>

AVHopp reviewed Dec 15, 2025

View reviewed changes

Scienfitz added this to the 0.15.0 milestone Jan 7, 2026



		def validate_is_finite( # noqa: DOC101, DOC103
		_: Any, attribute: Any, value: float \| Sequence[float]

	default=0.0, converter=float, validator=validate_is_finite, kw_only=True
	default=0.0, converter=float, validator=validate_is_finite

		# We set up a constrained and unconstrained searchspace to demonstrate the impact of
		# the constraint on optimization performance.

	"""Validate that ``value`` contains no infinity/nan.
	"""Validate that ``value`` contains no resp. is not infinity/nan.

		UBOUND = 2.0


		def lookup(df: pd.DataFrame, a=1.0, b=1.0, c=1.0, d=1.0, phi=0.5) -> pd.DataFrame:

Conversation

Scienfitz commented Aug 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AVHopp commented Aug 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Scienfitz commented Aug 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Scienfitz Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as outdated.

AdrianSosic left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AVHopp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Scienfitz commented Aug 21, 2025 •

edited

Loading

AVHopp commented Aug 25, 2025 •

edited

Loading

Scienfitz Nov 25, 2025 •

edited

Loading