Scala good first issues

This issue addresses inconsistencies in Comet's documentation and operator naming, particularly around the term 'native'. The goal is to establish a clear nomenclature style guide to differentiate between Rust-implemented components, operations within the Comet pipeline, and fully Rust scans, ensuring better clarity as Comet's value proposition shifts towards end-to-end Arrow-native data processing.

This issue requests the addition of comprehensive unit tests for three extension methods in `HttpResponse`: `ensureSuccess`, `toJson`, and `mapServiceError`. The tests should cover various success and error scenarios for `ensureSuccess`, different body types for `toJson`, and the rewrapping of `ServiceError` for `mapServiceError`.

The `EnvCheckPolicies` tool currently passes with an exit code of 0 even when all configured policies are skipped due to environment mismatches. This issue proposes modifying the tool to detect when all policies are skipped and instead return an exit code of 2, along with a descriptive message, to indicate that no checks were actually performed.

This issue proposes to improve the `CheckPolicies` tool by making its `--env` argument more robust. Currently, it silently accepts unknown environment names and maps them to `Prod`. The goal is to make it refuse unknown `--env` values with an error message, similar to how it handles unknown presets, and to correctly map the `dev-sandbox` alias to the `Dev` environment and the `devSandbox` policy.

This issue requests adding Scaladoc documentation to several request methods in `Llm4sHttpClient`, including details about parameters, default timeouts, and error handling. It also asks for documentation for `JsonHttpResponse` and two extension methods, `toJson` and `mapServiceError`, clarifying their behavior and parameters.

This issue requests adding Scaladoc documentation to the abstract methods of the `Tracing` contract in the `llm4s` project. The goal is to clarify the purpose of each method, its parameters, how built-in backends map to `TraceEvent`s, and the meaning of potential `Left` results. Additionally, brief comments are needed for `TracingComposer` and `TracingMode` objects.

This issue requests adding Scaladoc documentation to the `ModelRegistryService` trait and its companion object in the llm4s project. The goal is to clarify the behavior of its methods, including how model lookups are performed, error handling for searches, and the different ways to load model configurations, making the API more understandable for users.

This issue requests the addition of new tests for the `ModelRegistryService` in Scala. The tests should cover specific error paths, such as when no models are found for a given capability, mode, or provider. Additionally, tests for case-insensitive provider matching, unique provider listing, and various lookup scenarios (exact, case-insensitive, prefixed, substring, and whitespace handling) are required. The goal is to ensure the `ModelRegistryService` behaves as documented across all its functionalities.

This issue requests adding unit tests for several methods within the `Conversation` and `ToolMessage` classes in the `llmconnect` library. Specifically, it aims to test `addMessage`, `addMessages`, `filterByRole` for `Conversation`, and `findToolCallName` for `ToolMessage`, ensuring their expected behavior and immutability.

This issue requests the addition of unit tests for helper functions within `ProviderDescriptor` and setters in `ProviderConfigSpec`. The goal is to ensure these functions correctly handle missing fields, extra configurations, and authentication details, and to verify the exact error messages generated.

This issue requests the addition of unit tests for the `EmbeddingConfigSpec` class in the `llmconnect` library. Specifically, it aims to test the `resolveModel`, `resolveBaseUrl`, and `resolveApiKey` methods, as well as the `with*` setters, to ensure their precedence logic and blank value handling are correctly implemented. The tests will be placed in a new `EmbeddingConfigSpecSpec.scala` file.

This issue requests adding missing tests for setters of `RateLimitConfig` and `ContextConfig` in the `llm4s-core` library. The goal is to ensure that each setter correctly modifies only its intended field, following the pattern of existing tests for `CompletionOptionsSettersSpec`.

This issue requests adding unit tests for the `with*` setter methods of `Completion`, `TokenUsage`, and `StreamedChunk` data classes. The goal is to ensure that each setter correctly modifies its corresponding field while leaving other fields unchanged, following the pattern of an existing `CompletionOptionsSettersSpec`.

This issue proposes adding comprehensive tests for the `with*` setter methods of `ModelMetadata` and `ModelCapabilities` classes. The goal is to ensure that each setter correctly modifies only its intended field and doesn't inadvertently affect other properties, following the pattern of an existing test for `CompletionOptions`.

This issue proposes adding a new offline handoff sample to the project. The sample will demonstrate how to use agent handoffs with scripted models, making it runnable without an API key. It requires creating two agents, a triage agent and a billing specialist, each with its own scripted client to simulate handoff behavior and context preservation.

This issue requests the creation of a new runnable Java sample program that demonstrates the `FakeLlmClient`. This sample should showcase how to use the fake client for offline testing and provide a basic example of classifying tickets, without requiring any API keys or network access. A corresponding Scala specification test should also be added.

This issue requests the addition of a new sample application demonstrating the `PromptInjectionDetector`. The sample should showcase how the detector works without requiring an API key, illustrating its various features like sensitivity levels, presets, and custom patterns. It needs to show that the detector correctly identifies prompt injection attempts and handles normalized input.

This issue requests the creation of a new Kotlin guide page for the llm4s-kotlin-api library. The page should consolidate information on Kotlin coroutines, Flow, agents, and DSL usage, providing a single resource for Kotlin developers. It needs to cover installation, making a first API call, using completion options, streaming responses, and agent functionality, referencing existing documentation where appropriate.

This issue addresses outdated code examples in the project's documentation. Specifically, it requires updating calls to `Llm4sConfig.provider()` which has been refactored, and correcting the way custom tools are defined in agent examples. The changes aim to ensure that users copying code snippets from the documentation will have functional, compilable code.

This issue aims to improve the example gallery documentation by adding entries for runnable samples that are currently missing. The goal is to ensure that all available examples are discoverable by newcomers browsing the gallery, covering various categories like providers, context management, effect systems, and reliability.

This issue addresses several documentation inconsistencies on the llm4s.org website. It requires updating the User Guide index to link unlisted guides, correcting broken internal links and an example count, fixing a parent page reference for better sidebar navigation, and ensuring two specific pages are rendered correctly by adding necessary front matter.

This issue requests adding tests for several value types within the agent harness, specifically `TodoStatus`, `Todo`, `TodoList`, `Skill`, and `StoreLimits`. The goal is to ensure that their setters and wire/JSON serialization/deserialization logic function correctly and are covered by tests, as these are considered part of the upcoming 1.0 API.

This issue requires adding tests for the `with*` setters of several configuration types (`TodoConfig`, `SummarizationConfig`, `OffloadConfig`, `SkillsConfig`, `InstructionsConfig`) within the agent harness. The tests should verify that the default values are correctly applied and that each setter modifies only its intended field while preserving others. This is important because the setters are the primary way to modify these configuration types after instantiation.

This issue requires adding new tests for LLM-as-judge guardrail presets. The task involves creating a new test specification (`LLMGuardrailPresetsSpec`) that verifies the threshold, evaluation prompt, and validation logic for several presets like `highQuality`, `childSafe`, `friendly`, `professionalOrFriendly`, and `lenient`. A stub `LLMClient` will be used to ensure deterministic testing.

This issue asks to add comprehensive tests for five previously untested RAGGuardrails presets. The tests should verify the exact types and order of guardrails, their specific configurations (like thresholds and onFail settings), and for certain presets, ensure they correctly handle provided topics.

This issue requests the addition of a new test suite, `FileInfoToolSpec`, for the `FileInfoTool` in the agent-tools module. The new tests should cover various aspects of the tool's functionality, including human-readable file sizes at unit boundaries, file extension extraction rules, directory handling, and error cases like missing paths or access denied for paths outside allowed directories. It also requires investigating locale-specific formatting for file sizes.

This issue requests the addition of comprehensive tests for the `ListDirectoryTool` in the `llm4s` project. The new tests should cover various aspects like sorting, `max_entries` and truncation behavior, accurate counting of returned entries, handling of large numbers of files, file size and type detection, and error cases for invalid paths.

This issue proposes adding a new sample to the llm4s-speech project that demonstrates its offline audio preprocessing capabilities. The sample should synthesize audio, validate it, and then process it using the `AudioConverter` without requiring any external models or API keys. It also aims to showcase a validation failure scenario.

This issue requests the creation of a new sample application for the `llm4s-rag` library. The sample should demonstrate how to use the evaluation dataset features, including `InMemoryDatasetStore`, `JsonlCodec`, and `ExampleSelector`, without requiring any API keys. The goal is to provide a practical example for users who want to manage and test datasets.

This issue requests documentation updates for the LLM reranker and RAG reranking options within the vector store guide. The task involves adding a new subsection detailing the LLM reranker's functionality, its parameters, and trade-offs, and demonstrating its integration within the RAG pipeline using `RAGConfig`. The goal is to ensure users understand how to configure and utilize these reranking methods.