Update common files

Author: micronaut-build

.clineignore

@@ -0,0 +1,29 @@
+# .clineignore - Cline AI ignore file for Micronaut projects
+# This file tells Cline which files/directories to ignore for code intelligence and automation
+
+# === Build outputs ===
+build/
+*/build/
+!build/docs/
+!build/docs/**
+
+# === Dependency/Cache directories ===
+.gradle/
+*/.gradle/
+
+# === IDE/Editor/OS Metadata ===
+.vscode/
+.idea/
+.DS_Store
+*.swp
+*.swo
+*.bak
+*.tmp
+*.orig
+
+# === Tool-specific/Config artifacts ===
+*.log
+
+# === Gradle Wrappers/Binaries ===
+gradlew
+gradlew.bat

.clinerules/coding.md

@@ -0,0 +1,179 @@
+---
+description: Micronaut Development Guide
+author: Cédric Champeau
+version: 1.0
+globs: ["**/*.java", "**/*.kts", "**/*.xml"]
+---
+
+# Micronaut Project Development Guide
+
+## Project Overview
+
+This project is a Micronaut module which is part of the Micronaut Framework, a modern, JVM-based, full-stack framework for building modular, easily testable microservice and serverless applications.
+
+The description of what this project is doing can be found in the `gradle.properties` file under the `projectDesc` key.
+
+This repository does not represent an actual application; its modules are designed to be used as dependencies by applications.
+The root project MUST NOT contain any code: it is a parent project which coordinates the build and supplies documentation.
+
+⚠️ CRITICAL: DO NOT USE attempt_completion BEFORE TESTING ⚠️
+
+## Command Conventions
+
+- You MUST run all Gradle commands (except testing ones) with the quiet option to reduce output:
+    - Do NOT use: `--stacktrace`, `--info` (excessive output will not fit the context)
+- You MUST run all Gradle testing commands without the `-q` option, since that will suppress the output result of each test.
+- Gradle project names are prefixed with `micronaut-`. For example, directory `mylib` maps to Gradle project `:micronaut-mylib`.
+- You MUST run Gradle with the Gradle wrapper: `./gradlew`.
+- Gradle project names prefixed with `test-` or `test-suite` are not intended for users: they are functional tests of the project
+
+## Main Development Tasks:
+
+- Compile (module): `./gradlew -q :<module>:compileTestJava`
+- Test (module): `./gradlew :<module>:test`
+- Checkstyle (aggregate task): `./gradlew -q cM`
+    - Note: `cM` is the canonical Checkstyle runner defined in build logic to validate Checkstyle across the codebase.
+    - Note: you MUST NOT introduce new warnings. You SHOULD fix warnings in code that you have modified.
+- Spotless (check license headers/format): `./gradlew -q spotlessCheck`
+- Spotless (auto-fix formatting/headers): `./gradlew -q spotlessApply` (MUST be used to fix violations found by `spotlessCheck`)
+
+## Code style
+
+You SHOULD prefer modern Java idioms: records, pattern matching, sealed interfaces/classes, `var` for local variables.
+You MUST NOT use fully qualified class names unless there is a conflict between 2 class names in different packages.
+You MUST annotate the code with nullability annotations (`io.micronaut.core.annotation.Nullable`, `io.micronaut.core.annotation.NonNull`).
+You MUST NOT use reflection: Micronaut is a reflection-free framework tailored for integration with GraalVM.
+You MUST use `jakarta.inject` for dependency injection, NOT `javax.inject`.
+
+## Binary compatibility
+
+Micronaut projects are intended to be used in consumer applications and therefore follow semantic versioning. As a consequence:
+- You MUST NOT break any public facing API without explicit consent
+- You SHOULD run the `./gradlew japiCmp` task to get a report about binary breaking changes
+- You SHOULD reduce the visibility of members for non user-facing APIs.
+- You MUST annotate non-user facing APIs with `@io.micronaut.core.annotation.Internal`
+
+## Implementation Workflow (Required Checklist)
+
+You MUST follow this sequence after editing source files:
+
+1) Compile affected modules
+    - `./gradlew -q :<module>:compileTestJava :<module>:compileTestGroovy`
+
+2) Run targeted tests first (fast feedback)
+    - `./gradlew :<module>:test --tests 'pkg.ClassTest'`
+    - `./gradlew :<module>:test --tests 'pkg.ClassTest.method'` (optional)
+
+3) Run full tests for all affected modules
+    - `./gradlew :<module>:test`
+
+4) Static checks
+    - Checkstyle: `./gradlew -q cM`
+
+5) (Optional) If, and only if you have created new files, you SHOULD run
+  - Spotless check: `./gradlew -q spotlessCheck`
+  - If Spotless fails: `./gradlew -q spotlessApply` then re-run `spotlessCheck`
+  - You MUST NOT add new license headers on existing files: only focus on files you have added
+
+6) Verify a clean working tree
+    - You SHOULD ensure no unrelated changes are pending before proposing changes.
+    - Use `git_status` to verify the working tree:
+      ```xml
+      <use_mcp_tool>
+       <server_name>mcp-server-git</server_name>
+       <tool_name>git_status</tool_name>
+       <arguments>
+           {
+           "repo_path": "/home/cchampeau/DEV/PROJECTS/micronaut/micronaut-langchain4j" // adjust absolute path if necessary
+           }
+       </arguments>
+      </use_mcp_tool>
+      ```
+
+## Documentation Requirements
+
+- You MUST update documentation when necessary, following the project’s documentation rules in `.clinerules/docs.md`.
+- Before writing code, you SHOULD analyze relevant code files to get full context, then implement changes with minimal surface area.
+- You SHOULD list assumptions and uncertainties that need clarification before completing a task.
+- You SHOULD check project configuration/build files before proposing structural or dependency changes.
+
+## Context7 Usage (Documentation and Examples)
+
+You MUST use Context7 to get up-to-date, version-specific documentation and code examples for frameworks and libraries.
+
+Preferred library IDs:
+- Micronaut main docs: `/websites/micronaut_io`
+- Micronaut Test: `/websites/micronaut-projects_github_io_micronaut-test`
+- Micronaut Oracle Cloud: `/websites/micronaut-projects_github_io_micronaut-oracle-cloud`
+- OpenRewrite: `/openrewrite/rewrite-docs`
+
+Example (fetch docs for a topic):
+```xml
+<use_mcp_tool>
+    <server_name>context7-mcp</server_name>
+    <tool_name>get-library-docs</tool_name>
+    <arguments>
+        {
+            "context7CompatibleLibraryID": "/openrewrite/rewrite-docs",
+            "topic": "JavaIsoVisitor"
+        }
+    </arguments>
+</use_mcp_tool>
+```
+
+For other libraries, you MUST resolve the library ID first:
+```xml
+<use_mcp_tool>
+    <server_name>context7-mcp</server_name>
+    <tool_name>resolve-library-id</tool_name>
+    <arguments>
+        {
+            "libraryName": "Mockito"
+        }
+    </arguments>
+</use_mcp_tool>
+```
+
+## Dependency Management (Version Catalogs)
+
+- Main dependencies are managed in the Gradle version catalog at `gradle/libs.versions.toml`.
+- You MUST use catalogs when adding dependencies (avoid hard-coded coordinates/versions in module builds).
+
+Adding a new dependency (steps):
+1) Choose or add the version in the appropriate catalog (`libs.versions.toml`).
+2) Add an alias under the relevant section (e.g., `libraries`).
+3) Reference the alias from a module’s `build.gradle.kts`, for example:
+    - `implementation(libs.some.library)`
+    - `testImplementation(testlibs.some.junit)`
+4) Do NOT hardcode versions in module build files; use the catalog entries.
+
+You SHOULD choose the appropriate scope depending on the use of the library:
+    - `api` for dependencies which appear in public signatures or the API of a module
+    - `implementation` for dependencies which are implementation details, only used in the method bodies for example
+    - `compileOnly` for dependencies which are only required at build time but not at runtime
+    - `runtimeOnly` for dependencies which are only required at run time and not at compile time
+
+## Build logic
+
+Micronaut projects follow Gradle best practices, in particular usage of convention plugins.
+Convention plugins live under the `buildSrc` directory.
+
+You MUST NOT add custom build logic directly in `build.gradle(.kts)` files.
+You MUST implement build logic as part of convention plugins.
+You SHOULD avoid build logic code duplication by moving common build logic into custom convention plugins.
+You SHOULD try to prefer composition of convention plugins.
+
+## Key Requirements
+
+You MUST confirm all of the following BEFORE using `attempt_completion`:
+
+- Changes compile successfully (affected modules)
+- Targeted tests pass
+- Full tests for affected modules pass
+- Checkstyle (`cM`) passes
+- Spotless (`spotlessCheck`) passes (apply fixes if needed)
+- Documentation updated when necessary
+- Working tree is clean (no unrelated diffs)
+
+If ANY item is “no”, you MUST NOT use `attempt_completion`.
+While you SHOULD add new files using `git add`, you MUST NOT commit (`git commit`) files yourself.

.clinerules/docs.md

@@ -0,0 +1,24 @@
+## Brief overview
+- Documentation for the Micronaut modules is primarily written in Asciidoc format, focusing on user guides, API references, and integration examples. The documentation emphasizes clarity, completeness, and practical examples to help developers integrate Micronaut modules effectively. Insights from the codebase show a focus on modular documentation aligned with subprojects, including setup instructions, usage examples, and troubleshooting tips.
+- All the files are within `src/main/docs/guide`. In that directory, there is a `toc.yml` file that is used to generate the table of contents and decide which `.adoc` files are to be included.
+
+## Development workflow
+- Write documentation in Asciidoc: Place source files in the appropriate `src/main/docs` directory.
+- Build and assemble the documentation guide: Use `./gradlew docs` from the root directory to generate HTML documentation. Since the output of this task may be huge, ignore the output and check the last process exit code to tell if it works. Otherwise, ask the user. If it works, verify the output for formatting and content accuracy.
+- Once assembled, the guide will be at `build/docs/`.
+- Include examples: Create and reference code examples from the doc-examples/ directory, ensuring they are testable and up-to-date with the latest service versions.
+- Test documentation: Run builds regularly and check for broken links or outdated information. Integrate doc checks into CI pipelines using Gradle tasks.
+- Review and update: Conduct peer reviews for new documentation or changes, ensuring alignment with coding standards and project updates.
+
+## Documentation best practices
+- Follow Asciidoc conventions: Use consistent headings, lists, code blocks, and admonitions (e.g., NOTE, TIP, WARNING) for better readability.
+- Provide comprehensive coverage: Include installation instructions, configuration details, usage examples, error handling, and performance tips for each service.
+- Use practical examples: Incorporate runnable code snippets from doc-examples/ to demonstrate real-world usage, with clear explanations and expected outputs.
+- Ensure accessibility: Use descriptive alt text for images, maintain logical structure, and avoid jargon without explanations.
+- Version control: Document version-specific changes and maintain backward compatibility notes.
+- Security and best practices: Highlight secure usage patterns, such as proper authentication and data handling.
+
+## Project context
+- Focus on Micronaut-specific integration that this project is providing, emphasizing GraalVM compatibility, annotation-driven configurations, and modular design.
+- Prioritize user-centric content: Guides should facilitate quick starts, advanced customizations, and troubleshooting for developers building Micronaut applications.
+- Align with coding guidelines: Documentation should complement code by explaining architectural decisions, such as the use of factories, interceptors, and annotation processors.