Perhaps, you forgot to add an `@Incubating` annotation or `@since` in the javadoc.

2. Accept the changes.\
If you are sure that the changes are intentional, follow the steps described in the report.
This includes adding the description of the changes to the `accepted-public-api-changes.json` file, and providing a reason for each change.
You can add the changes to any place in the file, e.g. at the top.

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 asciidoc can be

          color: {{ colors.yellow }}
      - action: add-comment@v1
        args:
          comment: |
            :warning: 'There are new TODOs present in this change.  Should any be removed?'

# To simplify the automations section, some calculations are placed under unique YAML keys defined here.
# Read the "|" not as "or", but as a "pipe", taking the output of the previous command and passing it to the next command.

        setupPluginRequirements()
    }

    /**
     * Create projects and files required for plugins applied to the project (including transitively applied plugins).
     * These files are not required to run the task itself, but are required to apply the binary-compatibility plugin.
     */
    protected
    fun setupPluginRequirements() {

        assertArchivedFilesSeen("report-flaky-test-without-leftover-test.zip")
    }

    @Test
    fun `leftover files are archived when test fails`() {
        val result = run(
            ":failed-report-with-leftover:test",
            ":successful-report:test",
            ":failed-test-with-leftover:test",
            "--continue",

}

// Shared basics for all
include("basics")

// Platform: defines shared dependency versions
include("build-platform")

// Compute the identity/version we are building and related details (like current git commit)
include("module-identity")

// Code quality rules common to :build-logic and the root build
include("code-quality-rules")

// Plugins to build :build-logic plugins

    validations:
      required: false
  - type: textarea
    id: context
    attributes:
      label: Context
      description: |
        How has this issue affected you? What are you trying to accomplish? What other alternatives have you considered?
        Providing context helps us come up with a solution that is most useful in the real world
    validations:

## Status

ACCEPTED

## Consequences

* If we would have used `Closure`, we must instead use `Action<T>`, `Spec<T>`, `Callable<T>`, or `Transformer<OUT, IN>`.
* We need to ensure all APIs that are exposed in the Groovy DSL go through runtime decoration.
Runtime decoration mixes in methods that use Groovy Closures to maintain consistent behavior in Groovy DSL.

        where:
        type         | result
        'internal'   | "\"${replaceAsInternal(InternalInterface.name)}\""
        'incubating' | "\"${IncubatingInterface.name}\""
    }

    def "do not report if they are both incubating"() {
        given:
        apiClass.newClass >> Optional.of(newIncubatingBase)
        newSuper.addInterface(incubatingInterface)

        expect:
        noViolation(rule)
    }

 * - adds a new `testFixtures` source set which should contain utilities/fixtures to assist in unit testing
 *   classes from the main source set,
 * - the test fixtures are automatically made available to the test classpath.
 *
 * Configures the Project as a test fixtures consumer according to the `testFixtures` extension configuration.
 */
plugins {
    `java-library`
    `java-test-fixtures`