> and you can rely on it after doing initial sanity check and targeted local testing.

### Copyright and License

When updating/modifying a file, please do not make changes to the copyright header.

When creating a new file, please make sure to add a header as defined below.

#### Required Files for Copyright Headers:

- Source code files (e.g., `.java`, `.kt`, `.groovy`).

      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their

We use *Specification* and *Discovery* documents stored in Google Drive, but they present some downsides:

* They are rarely updated after creation and initial review, and then become hard to follow, especially after important decisions are made
* They are not synced with the code to reflect the eventual solution that is committed
* Google Docs is not a "code-oriented" tool, like Markdown can be
* Review in Google Docs is not as simple as a PR code review in GitHub

## Why this policy exists

There is a fundamental **asymmetry** between submitting a contribution and reviewing one: AI tools make it easy to generate and submit large amounts of code, but they do not make it equally faster for us to review it. 
This policy protects our limited review budget, allowing us to invest our attention wisely.

        "InjectOnConstructorOfAbstractClass", // We use abstract injection as a pattern
        "InlineMeSuggester", // Only suppression seems to actually "fix" this, so make it global
        "JavaUtilDate", // We are fine with using Date
        "JavaxInjectOnAbstractMethod", // We use abstract injection as a pattern
        "MissingSummary", // We have another mechanism to check Javadocs on public API

This required the Kotlin DSL to add special integration to work with Groovy closures.
This has also forced plugins written in languages other than Groovy to use Groovy types for some APIs.

When the Kotlin DSL was introduced, we made an effort to add non-Groovy equivalents for all APIs.
This has been mostly done, but there remain a few holdouts (fixing these is out of scope).

This platform does not provide special support for a particular kind of automation. This is the responsibility of other platforms. 

It is made up of 3 architecture modules:

Do not remove `null` checks on public API boundaries, even if the annotations (or rather lack of them) suggest this.
Not all client code is compiled with NullAway.
Do not make a parameter `@Nullable` just to check and throw a `NullPointerException` when it is `null`. 

## Consequences

* Classes are forced to have consistent nullability annotations.

 * remain in their original namespace. This reduces the final Gradle distribution
 * size and makes us more conscious of which parts of a library we really need.
 *
 * WARNING: if you decide to do the minification by hand, make sure that you cover all paths of loading classes:
 * reflection, dynamic loading, etc. and understand how the library works internally.
 * These changes might break things in subtle ways otherwise.
 */
val keepPatterns = mapOf(

errors.password_length = Hasło musi mieć co najmniej {0} znaków.
errors.password_no_uppercase = Hasło musi zawierać co najmniej jedną wielką literę.
errors.password_no_lowercase = Hasło musi zawierać co najmniej jedną małą literę.
errors.password_no_digit = Hasło musi zawierać co najmniej jedną cyfrę.
errors.password_no_special_char = Hasło musi zawierać co najmniej jeden znak specjalny.