Add style guideline chapter #27

PLeVasseur · 2025-04-05T23:02:13Z

use IETF RFC 2119
add stub for Guideline Lifecycle (status)
add section for deprecated guidelines
add stubbed section for Compliance (deviation process)
add mechanism for which release the guideline is relevant for
add about release to style guideline

closes #25

PLeVasseur · 2025-04-09T15:07:10Z

src/process/style-guideline.rst

+
+* ``draft``
+* ``approved``
+* ``deprecated``


Suggestion from @rcseacord to:

remove deprecated as likely tool vendors will not need to issue warnings for no longer in force guidelines

add instead a retired category on which to make the guideline no longer in force

n.b. the model for tool vendors will often be along the lines of unconditionally supporting every warning, with configuration left flexible to suit the user's prokect-level recategorization plan; so a category for rules that are no longer wanted by default is useful because for project-specific reasons users may want to re-enable those rules.

As a rule proceeds through its lifecycle, a tool vendor will not usually mirror that lifecycle in the corresponding warning: once any user is using a warning to enforce a rule that is Approved in their version of the document, that warning will generally be retained permanently because users do not change standard or language version rapidly, if at all, and usually find themselves bound to both a specific language revision and a specific Guidelines revision, independently of whether they can upgrade their tooling.

I do agree with Alex' analysis of tool vendor behavior and agree with the change to "retired".

To me "deprecated" means that something in that category is subject to removal in future. Given we have no plans to ever remove a guideline, it may be misleading whereas I could expect a rule to sit in "retired" forever.

Sounds good, I'll take up @rcseacord's suggestion then and incorporate it.

Done in commit 53c9973c643168f308300cffd5daf803f2d7f13b

src/process/style-guideline.rst

PLeVasseur · 2025-04-09T15:12:48Z

src/process/style-guideline.rst

+or in order to make a single guideline more granular and replace it with
+more than one guideline.
+
+For more, see :ref:`Guideline Lifecycle`.


todo @PLeVasseur -- flesh this in a little before next we meet to better solicit feedback.

PLeVasseur · 2025-04-09T15:17:04Z

src/process/style-guideline.rst

+
+These guidelines are not in force and **MUST** not be applied.
+
+``release``


Adding feedback here to ruminate on:

use release ranges?

earliest release may need only be as early as the first safety-certified Rust compiler

committing to a stable release plan which is not every release for now likely fine due to slower nature of compiler adoption in safety-critical

nature of using digital tools could allow for things like

having a flag to ./make.py which would compile out certain guidelines or having a toggle within the generated docs

but -- should we do this? experience with MISRA seems to indicate users may not know the version and thus having a larger blanket approach may be best and not version

handling compiler bugs usually not handled in guidelines directly, but supplementary documents such as the MISRA Compliance document for that procedure for users

Cert rather than versioning guidelines versions copies of the entire standard, does that work here?

PLeVasseur · 2025-04-09T15:18:23Z

src/process/style-guideline.rst

+
+These guidelines are not in force and **MUST** not be applied.
+
+``release``


We discussed having folks reach out to safety-certified Rust toolchain vendors about their roadmap so we can use this for guidance:

HighTec - @pellico

Ferrous Systems - @AlexCeleste

AdaCore - @AlexCeleste

PLeVasseur · 2025-04-09T15:21:28Z

src/process/style-guideline.rst

+::
+
+   .. guideline:: Avoid Implicit Integer Wrapping
+      :id: gui_xztNdXA2oFNB


Suggestions on IDs from @rcseacord (some overlap with part of #19)

something human-readable is nice

even if wanting to stick with gui_<alphanumeric-string> it may be nice to help with recalling where the guideline fits by doing something like gui_typ_<alphanumeric-string> so that users can more easily know this is in the chapter on types and traits for example

having identifiers like this will help with web searchability (yay)

I think the addition of something in the style of C++ section tags, [types.intwrap] would be human readable, and wouldn't suffer from renumbering.

Would this be covered if we had some defined things under tags like this? Such that we could have a tag underneath each guideline which denoted where it fit?

Indeed this would cover the contents of my suggestion. However, if we are trying to find a human readable identifier for the guidelines typically I would not amalgamate the tags of something to refer to it. "You're looking for a guideline on your left near the 'integral types' and 'Undefined behavior', but if you see the 'traits' you've gone too far" :)

PLeVasseur · 2025-04-09T17:18:41Z

src/process/style-guideline.rst

+**MUST** be generated using the ``generate-guideline-templates.py`` script to ensure
+compliance.
+
+``category``


todo @PLeVasseur -- update this section with guidance that a contributor need not worry about this when initially submitting and we will discuss the right category.

Can help reduce friction of contributions.

Or perhaps guidance to strawman as "advisory" if unsure.

Done in commit 6d25a17a10dfb06ac126cf21feb9f1f34fcadcf0

AlexCeleste · 2025-04-10T00:55:22Z

src/process/style-guideline.rst

+``deprecated``
+^^^^^^^^^^^^^^
+
+These guidelines are not in force and **MUST** not be applied.


in practice this shouldn't be a MUST, users will continue to use deprecated guidelines for a variety of reasons. I would suggest mirroring the language for Disapplied status here and having no requirement rather than a negative requirement (i.e. all Deprecated are implicitly Disapplied regardless of recorded category; probably correspondingly that all Draft are implicitly Advisory regardless of recorded category)

Got it, thanks for providing the background.

I think this is addressed by 1a447262fbfc9dd573abfc4e7112869269ab863e, feel free to let me know.

AlexCeleste · 2025-04-10T00:57:25Z

src/process/style-guideline.rst

+``disapplied``
+^^^^^^^^^^^^^^
+
+These are guidelines for which compliance **SHOULD NOT** be required. No enforcement is expected, and any


I think SHOULD NOT is too strong here, this is a non-requirement rather than a negative requirement. In the original this was just "is not required". (the MAY below OTOH is exactly correct)

Thanks, will revise.

I think this is addressed by 1a447262fbfc9dd573abfc4e7112869269ab863e, feel free to let me know.

AlexCeleste · 2025-04-10T01:00:07Z

src/process/style-guideline.rst

+``tags``
+--------
+
+The ``tags`` are largely descriptive, not proscriptive means of finding commonality between


typo "prescriptive" (assuming tags aren't negative :P)

Done in 8439b0fcc162838533defc51f9c5b09e794b93a2

vapdrs · 2025-04-10T13:59:53Z

src/process/style-guideline.rst

+
+* ``draft``
+* ``approved``
+* ``deprecated``


I do agree with Alex' analysis of tool vendor behavior and agree with the change to "retired".

To me "deprecated" means that something in that category is subject to removal in future. Given we have no plans to ever remove a guideline, it may be misleading whereas I could expect a rule to sit in "retired" forever.

vapdrs · 2025-04-10T15:39:00Z

src/process/style-guideline.rst

+::
+
+   .. guideline:: Avoid Implicit Integer Wrapping
+      :id: gui_xztNdXA2oFNB


I think the addition of something in the style of C++ section tags, [types.intwrap] would be human readable, and wouldn't suffer from renumbering.

vapdrs · 2025-04-10T15:39:50Z

src/process/style-guideline.rst

+**MUST** be generated using the ``generate-guideline-templates.py`` script to ensure
+compliance.
+
+``category``


Or perhaps guidance to strawman as "advisory" if unsure.

vapdrs · 2025-04-10T15:45:49Z

src/process/style-guideline.rst

+
+Code claimed to be in compliance with this document **MUST** follow every guideline marked as ``mandatory``.
+
+*TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.*


Just some suggestions as a starting point for these tips

Suggested change

*TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.*

Selecting this category is appropriate when any non-compliance of the guideline would result in undefined behavior

Okay -- let's bring these in to discuss in the meeting next week. Thanks for the thought starters.

vapdrs · 2025-04-10T15:48:50Z

src/process/style-guideline.rst

+
+An organization or project **MAY** choose to recategorize any ``required`` guideline to ``mandatory``.
+
+*TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.*


Suggested change

*TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.*

Just some suggestions as a starting point for these tips

```suggestion

Selecting this category is appropriate when many instances of non-compliance with the guideline would result in undefined behavior or would result in a program state the developer was not expecting.

vapdrs · 2025-04-10T15:57:08Z

src/process/style-guideline.rst

+An organization or project **MAY** choose to recategorize any ``disapplied`` guideline as ``mandatory``
+or ``required``, or as ``advisory``.
+
+*TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.*


Suggested change

*TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.*

Selecting this category is appropriate when instances of non-compliance with the guideline would possibly result in unsafe code or could cause developer confusion. There should be a sound argument as to why non-compliance with a guideline in category would be generally useful.

vapdrs · 2025-04-10T16:03:19Z

src/process/style-guideline.rst

+An organization or project **MAY** choose to recategorize any ``disapplied`` guideline as ``mandatory``
+or ``required``, or as ``advisory``.


The more wording we can just cite from an industry document like MISRA Compliance the better in my opinion. Safety critical projects, at least in the automotive space, are likely already familiar with terms and processes contained within.

Yeah, definitely agree. Tried my best to align with MISRA C 2025's definitions. Could you help me understand if there's some action you're suggesting here?

I was thinking a citation to the compliance document for more details on how recategorization works. But in general I think we can shelf my comment or resolve it, and focus on the action plan in regards to Alex's comment.

vapdrs · 2025-04-10T18:03:25Z

src/process/style-guideline.rst

+Guideline Content **MAY** contain a section titled *Exception* followed by text that that describes
+situations in which the guideline does not apply. The use of exceptions permits the description of
+some guidelines to be simplified. It is important to note that an exception is a situation in which
+a guideline does not apply. Code that complies with a guideline by virtue of an exception does not
+require a deviation.


I think a distinction should be made between "does not apply" and "is not enforced" or similar wordings. The guideline on implicit integer wrapping does not apply to this example,

let sum: f32 = f + 10.0;

because the guideline does not apply to floating point arithmetic. No exception could be written for floating point because that is outside the guideline's scope already. For the sake of example let's say we wanted to add an exception to the implicit integer wrapping guidline for adding the integer literal 1 unchecked,

let sum = i + 1;

The rule does apply here as this is unchecked integer arithmetic prone to wraparound, but there is an explicitly provided exception which makes this specific situation OK (because we said so with some good reason). I think an exception should be categorically different than us clarifying in the description of the guideline, "This guideline only applies to integer arithmetic", which sets the scope of the rule's applicability.

Suggested change

Guideline Content **MAY** contain a section titled *Exception* followed by text that that describes

situations in which the guideline does not apply. The use of exceptions permits the description of

some guidelines to be simplified. It is important to note that an exception is a situation in which

a guideline does not apply. Code that complies with a guideline by virtue of an exception does not

require a deviation.

Guideline Content **MAY** contain a section titled *Exception* followed by text that that describes specific situations where the guideline is not enforced, but would otherwise apply. The use of

exceptions permits the description of some guidelines to be simplified. It is important to note that

an exception is a situation in which compliance to the guideline is not expected. Code that complies

with a guideline by virtue of an exception does not require a deviation.

Can you help me understand how this changes the meaning? I've tried to align closely with MISRA C 2025's definitions.

In general, I agree that

a distinction should be made between "does not apply" and "is not enforced" or similar wordings.

In short I see the normative description (amplification) setting the "scope" of what does apply and what does not apply, full stop. Then the exception list would contain very specific instances of where the guideline applies, but the group agrees that it should not be enforced for some reason.

What I'm trying to prevent is the overuse of exceptions. As an exaggerated example you could instead write this guideline as "all addition shall not be used", and then provide exceptions for "float point arithmetic", "std::opts overloads", "known constant expressions", "adding zero", "operations that be statically determined to not wrap", etc.

vapdrs · 2025-04-10T18:07:48Z

src/process/style-guideline.rst

+``rationale`` ``status``
+------------------------
+
+The ``status`` option of a ``rationale`` **MUST** match the ``status`` of its parent ``guideline``.


I'm wondering why the status of the rationale is separate if it must match the parent? Wouldn't it be better to instead have a parent_id here? The same comment applies to the following example sections

This is a limitation of my knowledge. As far as I could tell in order to have a Need in Sphinx-Needs it's required to at a minimum have:

an id

a status

If we can figure out another way to do this, I'm fine with not having a status.

vapdrs · 2025-04-10T18:18:12Z

src/process/style-guideline.rst

+Rationale Content
+-----------------
+
+TODO(pete.levasseur)


Here's suggestion for kicking off this section.

Suggested change

TODO(pete.levasseur)

The rationale **SHOULD** aim to explain to a reader why the guideline is useful in the context of safety critical Rust. The target audience is someone who familiar with Rust, and assumed to have read the contents of the _ The Rust Programming Language_ book, but is otherwise unaware of, or needs to be reminded about specific problematic behaviors that the guideline is attempting to cover. The rationale **MAY** include citations to specific, trusted resources that also explain the guideline, but **MUST** be able to be read coherently without accessing those resources.

AlexCeleste · 2025-04-10T19:35:54Z

Conveniently, the MISRA C Working Group had a meeting today so we were able to discuss some of this PR and generate some additional comments for the review.

First and most importantly, the MISRA C WG doesn't see any IP-related risk with the currently proposed wording. What little has been copied so far clearly either falls under Fair Use* or are simple dictionary terms over which MISRA does not have ownership (e.g. "Amplification" sections - not a common word - which is neat for use as a header - but we certainly didn't invent it).

(* or equivalent, since MISRA itself falls under UK copyright)

Secondly, the point was made that if the goal of this document is to stay in sync with the same MRAD system and Compliance etc., copying the definitions might create a maintenance burden if we change them in the C document, Obviously the C document is paywalled so it can't be used as a definition reference, but Compliance 2020 does have (slightly differently worded) definitions that can be used, and since it's free, it can be used for definitions easily. (Compliance 2020 does refer to the C document for some terms, which is unfortunate, but this will aim to be fixed in the 2025 update) So the suggestion of the group is to "as defined in Compliance 2020" for the definitions of the terms themselves, and then add longer additional descriptions in the section for guidance for people writing new Rust rules oriented purely towards helping people pick an appropriate category. This separates the concerns a little while having a single normative definition for the actual compliance case.

We like that you're doing that for the reference to the description of a deviation process!

Thirdly, someone made an interesting point that if a GRP is used to alter the category of any given Guideline, the RFC-2119 words used in the headline and Amplification might not be as-expected. We don't actually think this is a problem, but it might be unexpected at the user end. We don't recommend changing the wording of headlines dynamically (!), but rather having some user-facing note in the intro that RFC-2119 applies "except when a rule has been recategorized, in which case ... etc".
Although MISRA C doesn't do it right now, our own stylistic preference is to use MUST for Mandatory rules and SHALL for Required rules, not because the terms or the enforcement of the rules are different, because they aren't; but just to emphasize visually where a rule originally came from (IMO several sentences in the PR might read better using SHALL but that's a purely subjective choice).

We will work to make sure that the next edition of Compliance is accessible and suitable for referencing in this way - it's already supposed to be free and language-agnostic, but we will keep Rust in mind when reviewing any updates, and ensure that minor inconsistencies like Compliance relying on any definitions from MISRA C, are completely removed. If the SCRC has any feedback about Compliance y'all want us to take into account, that would also be very welcome and will be incorporated where possible.

PLeVasseur · 2025-04-12T18:16:55Z

Conveniently, the MISRA C Working Group had a meeting today so we were able to discuss some of this PR and generate some additional comments for the review.

Thanks for sharing the feedback here! I'll go bit by bit --

First and most importantly, the MISRA C WG doesn't see any IP-related risk with the currently proposed wording. What little has been copied so far clearly either falls under Fair Use* or are simple dictionary terms over which MISRA does not have ownership (e.g. "Amplification" sections - not a common word - which is neat for use as a header - but we certainly didn't invent it).

(* or equivalent, since MISRA itself falls under UK copyright)

Great to hear! Thank you for checking into this.

Secondly, the point was made that if the goal of this document is to stay in sync with the same MRAD system and Compliance etc., copying the definitions might create a maintenance burden if we change them in the C document, Obviously the C document is paywalled so it can't be used as a definition reference, but Compliance 2020 does have (slightly differently worded) definitions that can be used, and since it's free, it can be used for definitions easily. (Compliance 2020 does refer to the C document for some terms, which is unfortunate, but this will aim to be fixed in the 2025 update) So the suggestion of the group is to "as defined in Compliance 2020" for the definitions of the terms themselves, and then add longer additional descriptions in the section for guidance for people writing new Rust rules oriented purely towards helping people pick an appropriate category. This separates the concerns a little while having a single normative definition for the actual compliance case.

Got it. Purely my own opinion at the moment follows:

I'm a fan of not reinventing the wheel if it can be helped! Plus if we were to show strong alignment with MISRA way of doing things it's my thought this could help with adoption of these coding guidelines.

Would the thought be (from your point of view or MISRA members)

write the definitions here the same as in MISRA Compliance 2020 (would like for a reader to not have to go open it)
that we make the definitions here be a pointer to MISRA Compliance 2020 for now
then when MISRA Compliance 2025 comes out (if that's the plan), to then:
- update accordingly to point to the 2025 version
- update all coding guidelines usage of definitions / terminology to align with the 2025 version

?

There's also the issue of usage of RFC 2119 that could conflict with this -- but you'd mentioned this is something you'd like to have done given the chance. Wondering how we can square those two things -- using RFC 2119 here while MISRA does not.

We like that you're doing that for the reference to the description of a deviation process!

Yay! ☺️

Thirdly, someone made an interesting point that if a GRP is used to alter the category of any given Guideline, the RFC-2119 words used in the headline and Amplification might not be as-expected. We don't actually think this is a problem, but it might be unexpected at the user end. We don't recommend changing the wording of headlines dynamically (!), but rather having some user-facing note in the intro that RFC-2119 applies "except when a rule has been recategorized, in which case ... etc".

Sorry about this, but I think the point you're making here went over my head 😅 Let's bring this into the meeting this Wednesday to discuss?

Although MISRA C doesn't do it right now, our own stylistic preference is to use MUST for Mandatory rules and SHALL for Required rules, not because the terms or the enforcement of the rules are different, because they aren't; but just to emphasize visually where a rule originally came from (IMO several sentences in the PR might read better using SHALL but that's a purely subjective choice).

Got it on the stylistic choice. See my question above on how to align these guidelines with the concepts of MISRA while still making use of IETF RFC 2119.

We will work to make sure that the next edition of Compliance is accessible and suitable for referencing in this way - it's already supposed to be free and language-agnostic, but we will keep Rust in mind when reviewing any updates, and ensure that minor inconsistencies like Compliance relying on any definitions from MISRA C, are completely removed. If the SCRC has any feedback about Compliance y'all want us to take into account, that would also be very welcome and will be incorporated where possible.

Thanks for the offer! I'll try to read over Compliance and ask others as well to see if there's something we could suggest.

PLeVasseur · 2025-04-12T18:54:58Z

By the way this build is failing due to the spec.lock being out of date with the released FLS now. Addressed in #30, which should merge before this.

plaindocs

Couple of details that spring to mind.

plaindocs · 2025-04-09T14:38:34Z

src/process/style-guideline.rst

+
+A unique identifier for each guideline. Guideline identifiers **MUST** begin with ``gui_``.
+
+These identifiers are considered **stable** across releases and **MUST NOT** be removed.


across Rust releases? or across Guideline releases?

Both I'd think.

plaindocs · 2025-04-15T14:17:50Z

src/retired-guidelines/index.rst

+Retired Guidelines
+==================
+
+.. toctree::
+   :maxdepth: 1
+
+   retired-types-and-traits
+   retired-patterns
+   retired-expressions
+   retired-values
+   retired-statements
+   retired-functions
+   retired-associated-items
+   retired-implementations
+   retired-generics
+   retired-attributes
+   retired-entities-and-resolution
+   retired-ownership-and-destruction
+   retired-exceptions-and-errors
+   retired-concurrency
+   retired-program-structure-and-compilation
+   retired-unsafety
+   retired-macros
+   retired-ffi
+   retired-inline-assembly


Is it useful to have all of these from the get go? Or should we just add as needed?

I could go either way. I'm thinking to keep them for the structure to be clear.

* use IETF RFC 2119 * add stub for Guideline Lifecycle (status) * add section for deprecated guidelines * add stubbed section for Compliance (deviation process) * add mechanism for which release the guideline is relevant for * add about release to style guideline

…nd status of retired

PLeVasseur added documentation Improvements or additions to documentation enhancement New feature or request labels Apr 5, 2025

PLeVasseur added this to [Safety Critical Rust Consortium Coding Guidelines] Work Items Apr 5, 2025

PLeVasseur commented Apr 9, 2025

View reviewed changes

src/process/style-guideline.rst Show resolved Hide resolved

PLeVasseur commented Apr 9, 2025

View reviewed changes

AlexCeleste reviewed Apr 10, 2025

View reviewed changes

vapdrs reviewed Apr 10, 2025

View reviewed changes

plaindocs reviewed Apr 15, 2025

View reviewed changes

AlexCeleste approved these changes Apr 15, 2025

View reviewed changes

PLeVasseur added 6 commits April 20, 2025 06:10

Eliminate deprecated, replace with retired

318b49c

Allow for submission of coding guideline as advisory if unsure.

b5011a1

Relate together and show differences between category of disapplied a…

d66ed9f

…nd status of retired

Fix typo proscriptive => prescriptive

250e2b9

Add content for guideline to example

69b3f7a

PLeVasseur force-pushed the feature/style-guideline-initial branch from ca10ef6 to 69b3f7a Compare April 19, 2025 21:10

PLeVasseur mentioned this pull request Apr 19, 2025

Add Rust release coverage versioning #40

Open

PLeVasseur merged commit 4b4e695 into rustfoundation:main Apr 19, 2025
1 check passed

PLeVasseur deleted the feature/style-guideline-initial branch April 19, 2025 21:22

github-project-automation bot moved this to Done in [Safety Critical Rust Consortium Coding Guidelines] Work Items Apr 19, 2025


		These guidelines are not in force and MUST not be applied.

		``release``


		Code claimed to be in compliance with this document MUST follow every guideline marked as ``mandatory``.

		TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.

	TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.
	Selecting this category is appropriate when any non-compliance of the guideline would result in undefined behavior


		An organization or project MAY choose to recategorize any ``required`` guideline to ``mandatory``.

		TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.

-*TODO(pete.levasseur): Add more tips on when this is a good choice for a guideline.*
+Just some suggestions as a starting point for these tips
+```suggestion
+Selecting this category is appropriate when many instances of non-compliance with the guideline would result in undefined behavior or would result in a program state the developer was not expecting.

		An organization or project MAY choose to recategorize any ``disapplied`` guideline as ``mandatory``
		or ``required``, or as ``advisory``.


		A unique identifier for each guideline. Guideline identifiers MUST begin with ``gui_``.

		These identifiers are considered stable across releases and MUST NOT be removed.

Add style guideline chapter #27

Add style guideline chapter #27

Conversation

PLeVasseur commented Apr 5, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PLeVasseur Apr 9, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexCeleste Apr 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PLeVasseur Apr 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlexCeleste commented Apr 10, 2025 • edited Loading

PLeVasseur commented Apr 12, 2025

PLeVasseur commented Apr 12, 2025

plaindocs left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

PLeVasseur Apr 9, 2025 •

edited

Loading

AlexCeleste Apr 10, 2025 •

edited

Loading

PLeVasseur Apr 12, 2025 •

edited

Loading

AlexCeleste commented Apr 10, 2025 •

edited

Loading