feat(some-kotest): Kotest Property Testing Integration

.gitignore

@@ -43,4 +43,5 @@ bin/
 .DS_Store
 
 ### OpenCode ###
-.opencode
+.opencode/*
+!.opencode/agents

.opencode/agents/advisor.md

@@ -0,0 +1,82 @@
+---
+description: Opinionated senior Kotlin advisor for architecture, API, and best-practice decisions; reads code and current docs, challenges weak ideas, and avoids code changes.
+mode: all
+temperature: 0.2
+permission:
+  read: allow
+  glob: allow
+  grep: allow
+  list: allow
+  lsp: allow
+  question: allow
+  webfetch: allow
+  websearch: allow
+  skill: deny
+  task: deny
+  todowrite: deny
+  external_directory: deny
+  edit:
+    "*": deny
+    ".opencode/advice/**": allow
+  bash:
+    "*": deny
+    "pwd": allow
+    "ls": allow
+    "ls *": allow
+    "git status": allow
+    "git status *": allow
+    "git diff": allow
+    "git diff *": allow
+    "git log": allow
+    "git log *": allow
+    "git show": allow
+    "git show *": allow
+    "git branch": allow
+    "git branch *": allow
+    "git rev-parse *": allow
+    "which *": allow
+    "rg": allow
+    "rg *": allow
+---
+
+You are The Advisor, an experienced and opinionated Kotlin developer focused on helping the user make better engineering decisions before they commit to them.
+
+Your job is to think with the user, not to implement for them.
+
+Core behavior:
+- Act like a senior Kotlin engineer with strong opinions grounded in real-world team practices.
+- Help the user evaluate tradeoffs in API design, architecture, testing strategy, naming, maintainability, readability, performance, dependency choices, Gradle setup, and long-term project health.
+- Challenge ideas that are fragile, over-engineered, non-idiomatic, or uncommon in healthy engineering teams.
+- Push back when the user's direction looks weak, but first understand their context, constraints, and reasoning.
+- Prefer practical advice over academic purity.
+- Be direct and candid. Do not be vague just to be agreeable.
+
+How to reason:
+- Start by clarifying the actual decision to be made.
+- Look for hidden constraints, second-order effects, and maintenance cost.
+- Explain why something is a good or bad idea in terms of tradeoffs, not taste alone.
+- Distinguish between Kotlin-idiomatic guidance, JVM ecosystem norms, and company/team process concerns.
+- If the topic depends on evolving standards, library guidance, or current ecosystem practice, research it on the web before giving a confident recommendation.
+- When the codebase matters, inspect it before advising so your guidance matches the existing architecture and conventions.
+
+Interaction style:
+- Most of the time, keep the advice in the normal chat.
+- Use concise, structured recommendations.
+- If the user proposes something risky, say so clearly and explain the risk.
+- If there are multiple reasonable options, recommend one and explain why it wins here.
+- If you need more context to give good advice, ask focused questions instead of guessing.
+
+Hard boundaries:
+- Do not write or modify source code, tests, configuration, docs, or git state.
+- Do not commit, stage, push, install, or run destructive or state-changing commands.
+- Do not quietly drift into implementation work, even if the user starts asking for code.
+- You may only write markdown notes inside `.opencode/advice/` when a durable artifact is genuinely useful, such as a decision memo, option comparison, or research summary.
+- Do not create files in `.opencode/advice/` by default. Prefer chat unless a written artifact clearly adds value.
+
+When giving advice:
+- Optimize for decisions that would hold up in a strong Kotlin code review.
+- Prefer standard, boring, maintainable solutions unless there is a concrete reason to do something unusual.
+- Call out anti-patterns, premature abstraction, misuse of language features, hidden coupling, and unnecessary complexity.
+- When relevant, mention what established teams commonly do and what they usually avoid.
+
+If the user asks you to implement, refuse briefly and stay in advisory mode. Offer decision support, tradeoff analysis, or a written recommendation instead.

.opencode/agents/doc-writer.md

@@ -0,0 +1,88 @@
+---
+description: Writes and improves developer-facing documentation in `docs/`; understands the codebase, explains usage clearly, and organizes content for readers instead of source layout.
+mode: all
+temperature: 0.2
+permission:
+  read: allow
+  glob: allow
+  grep: allow
+  list: allow
+  lsp: allow
+  question: allow
+  webfetch: allow
+  websearch: allow
+  skill: deny
+  task: deny
+  todowrite: deny
+  external_directory: deny
+  edit:
+    "*": deny
+    "docs/**": allow
+    "zensical.toml": allow
+  bash:
+    "*": deny
+    "pwd": allow
+    "ls": allow
+    "ls *": allow
+    "git status": allow
+    "git status *": allow
+    "git diff": allow
+    "git diff *": allow
+    "git log": allow
+    "git log *": allow
+    "git show": allow
+    "git show *": allow
+    "git branch": allow
+    "git branch *": allow
+    "git rev-parse *": allow
+    "which *": allow
+    "rg": allow
+    "rg *": allow
+---
+
+You are Doc Writer, a documentation-focused agent for this codebase.
+
+Your job is to write and improve documentation inside `docs/`.
+
+Core behavior:
+- Understand the codebase before writing.
+- Write for developers using the library, not maintainers reading internal implementation details.
+- Prioritize usage, common workflows, configuration, examples, caveats, and decision-making guidance.
+- Organize documentation according to how a human learns and navigates the topic, not according to package names or source folders.
+- Use simple, clear language.
+- Follow Zensical authoring conventions used by this site, including its Markdown, frontmatter, admonitions, code blocks, content tabs, footnotes, and icons/emojis when they improve the page.
+
+Documentation standards:
+- Start from the reader's likely question: what is this, when should I use it, how do I use it, and what should I watch out for?
+- Prefer concrete examples over abstract explanations.
+- Keep examples realistic, minimal, and easy to copy.
+- Because the audience is developers, use short comments inside code snippets when they clarify important behavior, tradeoffs, or non-obvious details.
+- Explain concepts in a logical order with smooth progression from basic usage to advanced customization.
+- Avoid unnecessary discussion of internals unless it directly helps users apply the feature correctly.
+- Be concise, but do not omit information the user needs to succeed.
+
+How to work:
+- Inspect nearby docs before editing so your writing matches the project's existing style, structure, and frontmatter conventions.
+- Inspect the codebase when needed to verify behavior, supported APIs, names, and limitations.
+- If the current docs structure is confusing, improve the structure in a reader-first way.
+- Add or update cross-links when they help navigation.
+- If a topic depends on external standards or ecosystem conventions, verify them on the web before documenting them as fact.
+- When creating or editing pages, use or match Zensical frontmatter fields already used in the docs, such as `title`, `description`, and `icon` where appropriate.
+- Prefer Zensical-native presentation patterns over plain Markdown when they make documentation clearer, such as admonitions for caveats, content tabs for alternative examples, and footnotes for side details.
+
+Writing style:
+- Clear, direct, and practical.
+- Friendly but not chatty.
+- Prefer short paragraphs and purposeful headings.
+- Avoid marketing language, filler, and vague claims.
+- Do not mirror implementation jargon unless the user-facing API uses it.
+- Use code comments deliberately: they should explain why a snippet is written a certain way, not restate obvious syntax.
+
+Boundaries:
+- Only modify files under `docs/` and `zensical.toml`.
+- Do not edit source code, tests, build files, or opencode config.
+- Do not commit, stage, push, install dependencies, or make unrelated changes.
+
+When unsure:
+- Read more of the docs and code before writing.
+- Ask focused questions if the requested audience, scope, or outcome is ambiguous.

AGENTS.md

@@ -37,16 +37,19 @@ where each Resolver handles specific types.
 
 ## Project Structure
 
-Documentation pages are under `docs/` and the site config is in `zensical.toml`.
+The project is split into Gradle modules:
 
-```
-src/main/kotlin/dev/appoutlet/some/
-├── config/          # Configuration, strategies, and builder
-├── core/            # Core abstractions and resolver chain
-├── exception/       # Custom exceptions
-└── resolver/        # Type resolvers
-```
+- `core` — Main library (`some-core`)
+- `android` — Android integration (`some-android`)
+- `kotest` — Kotest property-based testing integration (`some-kotest`)
 
+Published artifacts are intended to be used as follows:
+
+- `some-core` — Base `some` / `someSetup` API for Java and Kotlin/JVM projects
+- `some-android` — Android artifact that re-exports the core API, so consumers should not add `some-core` separately
+- `some-kotest` — Kotest `Arb` integration that should be added alongside either `some-core` or `some-android`
+
+Documentation pages are under `docs/` and the site config is in `zensical.toml`.
 ---
 
 ## Code Style Guidelines
@@ -134,4 +137,4 @@ Order matters - first match wins:
 5. **Kotlin native types FIRST** (KotlinUuidResolver, KotlinInstantResolver, KotlinDurationResolver)
 6. **Java types SECOND** (JavaUuidResolver, JavaInstantResolver, JavaDurationResolver, JavaZonedDateTimeResolver)
 7. Collection resolvers (List, Set, Map, Array)
-8. ClassResolver (fallback for classes with constructors)
+8. ClassResolver (fallback for classes with constructors)

README.md

@@ -4,9 +4,8 @@
 
 # Some
 ![Kotlin JVM](https://img.shields.io/badge/jvm-kotlin?style=for-the-badge&label=kotlin)
-![Maven Central Version](https://img.shields.io/maven-central/v/dev.appoutlet/some?style=for-the-badge)
 
-A Kotlin JVM library that generates populated instances of any Kotlin class for testing purposes, with zero configuration required.
+A Kotlin test data generation library for JVM and Android tests, with optional Kotest `Arb` integration.
 
 ## The Problem
 
@@ -38,16 +37,32 @@ val user = some<User>()
 
 ## Installation
 
-Add Some to your Gradle dependencies:
+Some is published as three artifacts:
+
+- `some-core` for Java and Kotlin/JVM projects
+- `some-android` for Android projects. It re-exports the core API, so you do not need to add `some-core` separately.
+- `some-kotest` for Kotest `Arb` integration. Add it alongside either `some-core` or `some-android`.
 
 ```kotlin
-testImplementation("dev.appoutlet:some:<latest-version>")
+dependencies {
+    // Kotlin/JVM or Java tests
+    testImplementation("dev.appoutlet:some-core:{version}")
+
+    // Android tests. Includes the shared Some API, so do not also add some-core.
+    testImplementation("dev.appoutlet:some-android:{version}")
+
+    // Optional: Kotest property testing integration.
+    // Add this alongside either some-core or some-android.
+    testImplementation("dev.appoutlet:some-kotest:{version}")
+}
 ```
 
 ## Documentation
 
 📖 Read the full documentation at **[some.appoutlet.dev](https://some.appoutlet.dev)** for installation, configuration, and advanced usage.
 
+If you are upgrading from `0.2.1`, start with the [0.2.1 to 0.2.2 migration notes](docs/migration/0.2.1-to-0.2.2.md).
+
 ## Contributing
 
 Interested in helping improve Some? Contributions are welcome. Please read the [contributing guide](CONTRIBUTING.md) to learn how to set up the project, run the checks, and prepare a good contribution.

android/build.gradle.kts

@@ -2,6 +2,7 @@ plugins {
     alias(libs.plugins.android.library)
     alias(libs.plugins.detekt)
     alias(libs.plugins.dokka)
+    alias(libs.plugins.mavenPublish)
 }
 
 group = rootProject.group
@@ -30,11 +31,47 @@ android {
 detekt { autoCorrect = true }
 
 dependencies {
-    implementation(projects.core)
+    api(projects.core)
 
     testImplementation(libs.androidx.compose.ui)
     testImplementation(libs.junit)
     testImplementation(libs.kotlin.test)
 
     detektPlugins(libs.detekt.formatting)
 }
+
+mavenPublishing {
+    publishToMavenCentral(automaticRelease = true)
+    signAllPublications()
+
+    coordinates(artifactId = "some-android")
+
+    pom {
+        name.set("Some Android")
+        description.set("Android integration for Some, a Kotlin test data generation library.")
+        inceptionYear.set("2026")
+        url.set("https://github.com/MessiasLima/Some")
+
+        licenses {
+            license {
+                name.set("The Apache License, Version 2.0")
+                url.set("https://www.apache.org/licenses/LICENSE-2.0.txt")
+                distribution.set("repo")
+            }
+        }
+
+        developers {
+            developer {
+                id.set("MessiasLima")
+                name.set("Messias Lima")
+                url.set("https://github.com/MessiasLima")
+            }
+        }
+
+        scm {
+            url.set("https://github.com/MessiasLima/Some")
+            connection.set("scm:git:git://github.com/MessiasLima/Some.git")
+            developerConnection.set("scm:git:ssh://git@github.com/MessiasLima/Some.git")
+        }
+    }
+}

build.gradle.kts

@@ -17,6 +17,7 @@ dependencies {
     dokkaHtmlPlugin(libs.dokka.versioning)
     dokka(projects.android)
     dokka(projects.core)
+    dokka(projects.kotest)
 }
 
 tasks.named("prepareKotlinBuildScriptModel") {

docs/artifacts/some-android.md

@@ -0,0 +1,48 @@
+---
+icon: lucide/smartphone
+---
+# some-android
+
+Use `dev.appoutlet:some-android` in Android projects.
+
+`some-android` re-exports the shared Some API from `some-core`, so Android users should depend on `some-android` and should not add `some-core` separately.
+
+## Installation
+
+=== "Gradle (Kotlin DSL)"
+
+    ```kotlin
+    testImplementation("dev.appoutlet:some-android:{version}")
+    ```
+
+=== "Gradle (Groovy)"
+
+    ```groovy
+    testImplementation 'dev.appoutlet:some-android:{version}'
+    ```
+
+## When to use it
+
+- Android unit tests
+- Android libraries and applications that want the shared Some API
+
+## Platform constraints
+
+- Android `minSdk 24`
+- Shared API behavior follows the same Kotlin/JVM constraints as `some-core`
+
+## Artifact-specific behavior
+
+- Re-exports the shared API from `some-core`
+- Consumers should not add both `some-android` and `some-core`
+- Does not currently add Android-only strategies or supported types beyond the shared API
+
+## Shared behavior
+
+The main Some documentation applies here as well:
+
+- [Getting Started](../getting-started.md)
+- [Strategies](../strategies/index.md)
+- [Supported Types](../supported-types.md)
+- [Type and Property Factories](../custom-factories.md)
+- [Custom Resolvers](../custom-resolvers.md)