* For polynull public APIs, the solution has to be decided on a case-by-case basis.

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.

        applyRule<DependencyAdditionRule>("com.google.apis:google-api-services-storage", "org.slf4j:jcl-over-slf4j")

        // asciidoctorj depends on a lot of stuff, which causes `Can't create process, argument list too long` on Windows
        applyRule<DependencyRemovalByNameRule>("org.gradle:sample-discovery", setOf("asciidoctorj", "asciidoctorj-api"))

        withModule<RemoveXmlApisRule>("jaxen:jaxen")

        } catch (JobProcessingException e) {
            assertEquals("Python Process terminated.", e.getMessage());
            assertNotNull(e.getCause());
            // Check cause message if available, otherwise just verify cause exists
            if (e.getCause().getMessage() != null) {
                assertTrue(e.getCause().getMessage().contains("Process start failed"));
            }
        }
    }

        final Exception cause = new RuntimeException("Underlying error");

        // Execute
        final InvalidQueryException exception = new InvalidQueryException(null, message, cause);

        // Verify
        assertNotNull(exception);
        assertEquals(message, exception.getMessage());
        assertEquals(cause, exception.getCause());
        assertNull(exception.getMessageCode());

        assertEquals("original query", result);
    }

    @Test
    public void test_regenerateQuery_exception_returnsFailedQuery() {
        client.setChatResponse(null); // causes LlmException

        final String result = client.regenerateQuery("test question", "original query", "no_results", Collections.emptyList());

        assertEquals("original query", result);
    }

    @Test

        Throwable cause1 = exception.getCause();
        assertNotNull(cause1);
        assertTrue(cause1 instanceof IOException);
        assertEquals("Level 1 error", cause1.getMessage());

        Throwable cause2 = cause1.getCause();
        assertNotNull(cause2);
        assertTrue(cause2 instanceof IllegalStateException);
        assertEquals("Level 2 error", cause2.getMessage());

        assertTrue(result instanceof BoolQueryBuilder);
    }

    // Test to ensure high coverage of edge cases
    @Test
    public void test_convertBooleanQuery_multipleShouldClauses() {
        BooleanQuery.Builder boolQueryBuilder = new BooleanQuery.Builder();

        // Add multiple SHOULD clauses
        for (int i = 0; i < 5; i++) {
            TermQuery termQuery = new TermQuery(new Term("field" + i, "value" + i));

### Properties in entirely new classes

When developing an entirely new class (task, extension, domain object, etc), the API should consist of managed lazy properties.

Preferably, these new classes should be 100% managed and have their implementation generated by Gradle at runtime.

This can save everyone a lot of time and frustration.

For any non-trivial change, we need to be able to answer these questions:

* Why is this change done? What's the use case?
* For user-facing features, what will the API look like?
* What test cases should it have? What could go wrong?

    @Test
    public void test_constructor_withServletExceptionWithCause() {
        // Create a root cause exception
        String rootCauseMessage = "Root cause error";
        Exception rootCause = new Exception(rootCauseMessage);

        // Create a ServletException with the root cause
        String servletErrorMessage = "Servlet error with cause";
        ServletException servletException = new ServletException(servletErrorMessage, rootCause);