{"owner":"redis","repo":"lettuce","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md","AGENTS.md"],"skills":{"CLAUDE.md":"@AGENTS.md\n\n<!--\nThe shared operating manual lives in AGENTS.md (imported above). Reusable task\nprocedures live in .agents/skills/ and are referenced from AGENTS.md.\n-->\n","AGENTS.md":"# Lettuce Coding Conventions\n\nEssential rules for working on the Lettuce codebase — a scalable, thread-safe\nRedis client for the JVM built on netty and Project Reactor. Detailed guidance\nfor specific tasks lives in `.agents/skills/`; consult the relevant skill when\nperforming that type of work.\n\n## How this guidance is organized\n\nAgent guidance is **self-contained under agent-owned locations** and never mixed into\nthe published documentation site:\n\n- **Agent-facing** (this material) lives at the repo root (`AGENTS.md`, `CLAUDE.md`),\n  under `.agents/` (tool-neutral: `.agents/docs/`, `.agents/rules/`, `.agents/skills/`),\n  and `.claude/` (Claude-specific tooling that bridges to `.agents/`). None of it is\n  published by MkDocs.\n- **User-facing** contributor/user documentation lives under `docs/` and is published\n  to the docs site. Agents read the agent-owned copies, not `docs/`.\n\nWithin the agent material it's a small graph: **each topic has one owner file**, and\neverything else **links** to it rather than restating it. When a topic changes, edit\nthe owner only.\n\n| Topic | Owner |\n|-------|-------|\n| Always-on facts, guardrails, index (this file) | `AGENTS.md` |\n| Command flow & code generation | `.agents/docs/architecture.md` |\n| API consistency (flavors, mapping rules, tests) | `.agents/docs/api-consistency.md` |\n| Testing — environment, running, naming, layout, CI | `.agents/docs/integration-testing.md` |\n| Javadoc conventions (incl. `@since` derivation) | `.agents/docs/javadoc.md` |\n| Coding rules (Java style, …) | `.agents/rules/*` |\n| Task procedures (add a command, write Javadoc, PR description) | `.agents/skills/*` |\n\nRule: state a fact in its owner and link from elsewhere; don't copy it. This file\nkeeps only a minimal always-on quick-reference. Skills own the *sequence* of a task\nand link out for the mechanics.\n\n## General Principles\n\n- **Update documentation.** When changes affect user-facing behavior, config, or\n  public API, update the relevant pages under `docs/` (MkDocs).\n- **Add or update tests.** Bug fixes need a reproducer test; new features need\n  tests. See `.agents/docs/integration-testing.md` for unit vs. integration conventions.\n- **You are responsible for what you submit.** Validate all changes. Do not submit\n  AI-generated code without human oversight.\n\n## Guardrails (agents)\n\nThese are hard rules for automated agents. A human maintainer performs these\nactions, not the agent.\n\n- **Never `git commit` or `git push`.** Stage and describe changes; leave\n  committing and pushing to the maintainer.\n- **Never create or merge pull requests, and never reply to GitHub issues or PRs**\n  (no `gh pr create`/`merge`/`comment`/`review`, no `gh issue create`/`comment`).\n  Draft text for the maintainer to post if asked — for a PR description, use the\n  `draft-pr-description` skill, which writes to `prDescription.md`.\n\n## Requirements & Toolchain\n\n- Builds and runs on the JDK baseline declared in `pom.xml`\n  (`maven.compiler.source`/`target`); targets Redis 2.6+.\n- **The test build pins a specific JDK to match CI** — check `.github/workflows/`\n  (or `.agents/docs/integration-testing.md`) and use that JDK to build and reproduce CI.\n- Build tool is **Maven** (`mvn`). Integration tests require **Docker**.\n- **Prefer semantic code tooling over text search for Java, when available.** If a\n  Java language server or IDE integration is present (e.g. an `jdtls`-based LSP, or\n  an IDE MCP), use it for definitions, references, symbol/type search, call\n  hierarchy, and diagnostics instead of grepping. Fall back to text search only when\n  no such tool is available.\n\n## Project Structure\n\n```\nsrc/main/java/io/lettuce/core/                Core client, connections, commands\nsrc/main/java/io/lettuce/core/cluster/        Redis Cluster support\nsrc/main/java/io/lettuce/core/masterreplica/  Master/Replica & Sentinel\nsrc/main/java/io/lettuce/core/pubsub/         Pub/Sub\nsrc/main/java/io/lettuce/core/support/        Connection pooling (ConnectionPoolSupport, BoundedAsyncPool)\nsrc/main/java/io/lettuce/core/api/            Sync/async/reactive command interfaces\nsrc/test/java/io/lettuce/                      Tests (see .agents/docs/integration-testing.md §5)\nformatting.xml                                 Eclipse formatter rules\nMakefile                                       Docker-backed test lifecycle\n```\n\nWhere to look: connect → `core/`; pooling → `core/support/`; sharding →\n`core/cluster/`; HA/Sentinel → `core/masterreplica/`.\n\n**How a command flows** through the API interfaces, command builder, codec, and\nthe netty/RESP wire layer is documented in `.agents/docs/architecture.md`. Read it\nbefore adding commands or touching the protocol layer — note the\nsync/async/reactive/Kotlin command interfaces are **hand-edited** and kept in\nlockstep by the API consistency test suite (see `.agents/docs/api-consistency.md`).\n\n## Build & Test Commands\n\n**Unit tests** (pure logic, no server — named `*UnitTests`, run by Surefire):\n\n```bash\nmvn clean test                       # build + run unit tests, no Redis needed\nmvn test -Dtest=FooUnitTests         # a single unit test\n```\n\n**Integration tests** (need a running Redis — named `*IntegrationTests`, run by\nFailsafe; **off by default**, `make test` enables them via `-DskipITs=false`):\n\n```bash\nmake start                           # boot the Dockerized Redis topology (add version=<v> to pick one)\nmake test                            # full build incl. integration tests\nmake stop                            # tear the environment down\n```\n\nRun one integration test fast (env already started):\n\n```bash\nTEST_WORK_FOLDER=./work/docker mvn -DskipITs=false -DskipUnitTests=true \\\n  -Dit.test=FooIntegrationTests verify -Pci\n```\n\nOne caveat worth remembering: `-Dit.test=` filters Failsafe (a single integration\ntest); `-DskipUnitTests=true` runs integration only. The full flag reference,\nRedis-version matrix, topologies, TLS/mTLS and CI mapping live in\n[`.agents/docs/integration-testing.md`](.agents/docs/integration-testing.md).\n\n**Apply formatting** (required before committing):\n\n```bash\nmvn formatter:format                 # applies formatting.xml; do NOT submit formatting-only diffs\n```\n\n## Testing Rules\n\n- **The file-name suffix picks the runner:** `*UnitTests` (Surefire, no server),\n  `*IntegrationTests` (Failsafe, needs Redis). Prefer those suffixes.\n- Integration tests read host/port/TLS from `TestSettings` / `TlsSettings` — never\n  hard-code them.\n- Everything else about testing (topologies, TLS/mTLS, layout, CI) lives in\n  [`.agents/docs/integration-testing.md`](.agents/docs/integration-testing.md).\n\n## Coding Style Essentials\n\n- 4-space indentation, enforced by `formatter-maven-plugin` — run\n  `mvn formatter:format`. Don't submit formatting-only changes (they create noise\n  and get PRs rejected).\n- **Add `@since <version>` to all new public API** — see\n  [`.agents/docs/javadoc.md`](.agents/docs/javadoc.md) for the version-derivation recipe.\n- **`@author` is the human contributor's.** Maintainers add their own `@author` to\n  files they touch (per CONTRIBUTING). An automated agent must **not** invent an\n  `@author` for itself — leave the tag to the maintainer unless told which name to add.\n- **Java style** — imports over fully-qualified names, braces on every control\n  statement (no braceless one-liners), no wildcard imports. Full list in\n  `.agents/rules/java-rules.md` (see `.agents/rules/` before editing Java).\n- Javadoc for public API follows house conventions — see `.agents/docs/javadoc.md`, or use\n  the `writing-javadoc` skill.\n\n## Commit & PR\n\n- Open a feature-request issue first; reference its number in the PR\n  (`<text> #<ticket>`).\n- Include unit and/or integration tests for every change.\n- Split feature/bugfix commits from formatting/polishing commits.\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`.\n\n## Key References\n\n| Document | What it covers |\n|----------|----------------|\n| `.github/CONTRIBUTING.md` | How to build, test, and contribute |\n| `.agents/docs/architecture.md` | How a command flows: API shapes, code generation, command model, codec, RESP/netty wire layer |\n| `.agents/docs/api-consistency.md` | The API flavors, their return-type mapping rules, and the consistency test suite that enforces them |\n| `.agents/docs/integration-testing.md` | Test environment, topologies, unit vs. integration, CI |\n| `.agents/docs/javadoc.md` | Javadoc house conventions for public API |\n| `.github/PULL_REQUEST_TEMPLATE.md` | PR checklist |\n| `formatting.xml` | Eclipse code-formatting rules |\n| [Javadoc](https://redis.github.io/lettuce/overview/) | Public API reference |\n\n## On-Demand Skills\n\nDetailed task guidance lives in `.agents/skills/`. Consult the relevant skill\nbefore doing that type of work.\n\n| Skill | When to use |\n|-------|-------------|\n| `extend-commands-api` | Add or extend a Redis command (or overload) end-to-end, evidence-first: HLD + server PR + live redis-cli verification, plan-mode approval, then all API interface flavors, builder, async/reactive/Kotlin impls, and tests |\n| `writing-javadoc` | Write or fix Javadoc for public API following Lettuce house conventions |\n| `draft-pr-description` | Generate a GitHub PR title and description from the diff between two local branches |\n"},"files":{"CLAUDE.md":"@AGENTS.md\n\n<!--\nThe shared operating manual lives in AGENTS.md (imported above). Reusable task\nprocedures live in .agents/skills/ and are referenced from AGENTS.md.\n-->\n","AGENTS.md":"# Lettuce Coding Conventions\n\nEssential rules for working on the Lettuce codebase — a scalable, thread-safe\nRedis client for the JVM built on netty and Project Reactor. Detailed guidance\nfor specific tasks lives in `.agents/skills/`; consult the relevant skill when\nperforming that type of work.\n\n## How this guidance is organized\n\nAgent guidance is **self-contained under agent-owned locations** and never mixed into\nthe published documentation site:\n\n- **Agent-facing** (this material) lives at the repo root (`AGENTS.md`, `CLAUDE.md`),\n  under `.agents/` (tool-neutral: `.agents/docs/`, `.agents/rules/`, `.agents/skills/`),\n  and `.claude/` (Claude-specific tooling that bridges to `.agents/`). None of it is\n  published by MkDocs.\n- **User-facing** contributor/user documentation lives under `docs/` and is published\n  to the docs site. Agents read the agent-owned copies, not `docs/`.\n\nWithin the agent material it's a small graph: **each topic has one owner file**, and\neverything else **links** to it rather than restating it. When a topic changes, edit\nthe owner only.\n\n| Topic | Owner |\n|-------|-------|\n| Always-on facts, guardrails, index (this file) | `AGENTS.md` |\n| Command flow & code generation | `.agents/docs/architecture.md` |\n| API consistency (flavors, mapping rules, tests) | `.agents/docs/api-consistency.md` |\n| Testing — environment, running, naming, layout, CI | `.agents/docs/integration-testing.md` |\n| Javadoc conventions (incl. `@since` derivation) | `.agents/docs/javadoc.md` |\n| Coding rules (Java style, …) | `.agents/rules/*` |\n| Task procedures (add a command, write Javadoc, PR description) | `.agents/skills/*` |\n\nRule: state a fact in its owner and link from elsewhere; don't copy it. This file\nkeeps only a minimal always-on quick-reference. Skills own the *sequence* of a task\nand link out for the mechanics.\n\n## General Principles\n\n- **Update documentation.** When changes affect user-facing behavior, config, or\n  public API, update the relevant pages under `docs/` (MkDocs).\n- **Add or update tests.** Bug fixes need a reproducer test; new features need\n  tests. See `.agents/docs/integration-testing.md` for unit vs. integration conventions.\n- **You are responsible for what you submit.** Validate all changes. Do not submit\n  AI-generated code without human oversight.\n\n## Guardrails (agents)\n\nThese are hard rules for automated agents. A human maintainer performs these\nactions, not the agent.\n\n- **Never `git commit` or `git push`.** Stage and describe changes; leave\n  committing and pushing to the maintainer.\n- **Never create or merge pull requests, and never reply to GitHub issues or PRs**\n  (no `gh pr create`/`merge`/`comment`/`review`, no `gh issue create`/`comment`).\n  Draft text for the maintainer to post if asked — for a PR description, use the\n  `draft-pr-description` skill, which writes to `prDescription.md`.\n\n## Requirements & Toolchain\n\n- Builds and runs on the JDK baseline declared in `pom.xml`\n  (`maven.compiler.source`/`target`); targets Redis 2.6+.\n- **The test build pins a specific JDK to match CI** — check `.github/workflows/`\n  (or `.agents/docs/integration-testing.md`) and use that JDK to build and reproduce CI.\n- Build tool is **Maven** (`mvn`). Integration tests require **Docker**.\n- **Prefer semantic code tooling over text search for Java, when available.** If a\n  Java language server or IDE integration is present (e.g. an `jdtls`-based LSP, or\n  an IDE MCP), use it for definitions, references, symbol/type search, call\n  hierarchy, and diagnostics instead of grepping. Fall back to text search only when\n  no such tool is available.\n\n## Project Structure\n\n```\nsrc/main/java/io/lettuce/core/                Core client, connections, commands\nsrc/main/java/io/lettuce/core/cluster/        Redis Cluster support\nsrc/main/java/io/lettuce/core/masterreplica/  Master/Replica & Sentinel\nsrc/main/java/io/lettuce/core/pubsub/         Pub/Sub\nsrc/main/java/io/lettuce/core/support/        Connection pooling (ConnectionPoolSupport, BoundedAsyncPool)\nsrc/main/java/io/lettuce/core/api/            Sync/async/reactive command interfaces\nsrc/test/java/io/lettuce/                      Tests (see .agents/docs/integration-testing.md §5)\nformatting.xml                                 Eclipse formatter rules\nMakefile                                       Docker-backed test lifecycle\n```\n\nWhere to look: connect → `core/`; pooling → `core/support/`; sharding →\n`core/cluster/`; HA/Sentinel → `core/masterreplica/`.\n\n**How a command flows** through the API interfaces, command builder, codec, and\nthe netty/RESP wire layer is documented in `.agents/docs/architecture.md`. Read it\nbefore adding commands or touching the protocol layer — note the\nsync/async/reactive/Kotlin command interfaces are **hand-edited** and kept in\nlockstep by the API consistency test suite (see `.agents/docs/api-consistency.md`).\n\n## Build & Test Commands\n\n**Unit tests** (pure logic, no server — named `*UnitTests`, run by Surefire):\n\n```bash\nmvn clean test                       # build + run unit tests, no Redis needed\nmvn test -Dtest=FooUnitTests         # a single unit test\n```\n\n**Integration tests** (need a running Redis — named `*IntegrationTests`, run by\nFailsafe; **off by default**, `make test` enables them via `-DskipITs=false`):\n\n```bash\nmake start                           # boot the Dockerized Redis topology (add version=<v> to pick one)\nmake test                            # full build incl. integration tests\nmake stop                            # tear the environment down\n```\n\nRun one integration test fast (env already started):\n\n```bash\nTEST_WORK_FOLDER=./work/docker mvn -DskipITs=false -DskipUnitTests=true \\\n  -Dit.test=FooIntegrationTests verify -Pci\n```\n\nOne caveat worth remembering: `-Dit.test=` filters Failsafe (a single integration\ntest); `-DskipUnitTests=true` runs integration only. The full flag reference,\nRedis-version matrix, topologies, TLS/mTLS and CI mapping live in\n[`.agents/docs/integration-testing.md`](.agents/docs/integration-testing.md).\n\n**Apply formatting** (required before committing):\n\n```bash\nmvn formatter:format                 # applies formatting.xml; do NOT submit formatting-only diffs\n```\n\n## Testing Rules\n\n- **The file-name suffix picks the runner:** `*UnitTests` (Surefire, no server),\n  `*IntegrationTests` (Failsafe, needs Redis). Prefer those suffixes.\n- Integration tests read host/port/TLS from `TestSettings` / `TlsSettings` — never\n  hard-code them.\n- Everything else about testing (topologies, TLS/mTLS, layout, CI) lives in\n  [`.agents/docs/integration-testing.md`](.agents/docs/integration-testing.md).\n\n## Coding Style Essentials\n\n- 4-space indentation, enforced by `formatter-maven-plugin` — run\n  `mvn formatter:format`. Don't submit formatting-only changes (they create noise\n  and get PRs rejected).\n- **Add `@since <version>` to all new public API** — see\n  [`.agents/docs/javadoc.md`](.agents/docs/javadoc.md) for the version-derivation recipe.\n- **`@author` is the human contributor's.** Maintainers add their own `@author` to\n  files they touch (per CONTRIBUTING). An automated agent must **not** invent an\n  `@author` for itself — leave the tag to the maintainer unless told which name to add.\n- **Java style** — imports over fully-qualified names, braces on every control\n  statement (no braceless one-liners), no wildcard imports. Full list in\n  `.agents/rules/java-rules.md` (see `.agents/rules/` before editing Java).\n- Javadoc for public API follows house conventions — see `.agents/docs/javadoc.md`, or use\n  the `writing-javadoc` skill.\n\n## Commit & PR\n\n- Open a feature-request issue first; reference its number in the PR\n  (`<text> #<ticket>`).\n- Include unit and/or integration tests for every change.\n- Split feature/bugfix commits from formatting/polishing commits.\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`.\n\n## Key References\n\n| Document | What it covers |\n|----------|----------------|\n| `.github/CONTRIBUTING.md` | How to build, test, and contribute |\n| `.agents/docs/architecture.md` | How a command flows: API shapes, code generation, command model, codec, RESP/netty wire layer |\n| `.agents/docs/api-consistency.md` | The API flavors, their return-type mapping rules, and the consistency test suite that enforces them |\n| `.agents/docs/integration-testing.md` | Test environment, topologies, unit vs. integration, CI |\n| `.agents/docs/javadoc.md` | Javadoc house conventions for public API |\n| `.github/PULL_REQUEST_TEMPLATE.md` | PR checklist |\n| `formatting.xml` | Eclipse code-formatting rules |\n| [Javadoc](https://redis.github.io/lettuce/overview/) | Public API reference |\n\n## On-Demand Skills\n\nDetailed task guidance lives in `.agents/skills/`. Consult the relevant skill\nbefore doing that type of work.\n\n| Skill | When to use |\n|-------|-------------|\n| `extend-commands-api` | Add or extend a Redis command (or overload) end-to-end, evidence-first: HLD + server PR + live redis-cli verification, plan-mode approval, then all API interface flavors, builder, async/reactive/Kotlin impls, and tests |\n| `writing-javadoc` | Write or fix Javadoc for public API following Lettuce house conventions |\n| `draft-pr-description` | Generate a GitHub PR title and description from the diff between two local branches |\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"@AGENTS.md\n\n<!--\nThe shared operating manual lives in AGENTS.md (imported above). Reusable task\nprocedures live in .agents/skills/ and are referenced from AGENTS.md.\n-->\n","category":"root","tokens":43},{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Lettuce Coding Conventions\n\nEssential rules for working on the Lettuce codebase — a scalable, thread-safe\nRedis client for the JVM built on netty and Project Reactor. Detailed guidance\nfor specific tasks lives in `.agents/skills/`; consult the relevant skill when\nperforming that type of work.\n\n## How this guidance is organized\n\nAgent guidance is **self-contained under agent-owned locations** and never mixed into\nthe published documentation site:\n\n- **Agent-facing** (this material) lives at the repo root (`AGENTS.md`, `CLAUDE.md`),\n  under `.agents/` (tool-neutral: `.agents/docs/`, `.agents/rules/`, `.agents/skills/`),\n  and `.claude/` (Claude-specific tooling that bridges to `.agents/`). None of it is\n  published by MkDocs.\n- **User-facing** contributor/user documentation lives under `docs/` and is published\n  to the docs site. Agents read the agent-owned copies, not `docs/`.\n\nWithin the agent material it's a small graph: **each topic has one owner file**, and\neverything else **links** to it rather than restating it. When a topic changes, edit\nthe owner only.\n\n| Topic | Owner |\n|-------|-------|\n| Always-on facts, guardrails, index (this file) | `AGENTS.md` |\n| Command flow & code generation | `.agents/docs/architecture.md` |\n| API consistency (flavors, mapping rules, tests) | `.agents/docs/api-consistency.md` |\n| Testing — environment, running, naming, layout, CI | `.agents/docs/integration-testing.md` |\n| Javadoc conventions (incl. `@since` derivation) | `.agents/docs/javadoc.md` |\n| Coding rules (Java style, …) | `.agents/rules/*` |\n| Task procedures (add a command, write Javadoc, PR description) | `.agents/skills/*` |\n\nRule: state a fact in its owner and link from elsewhere; don't copy it. This file\nkeeps only a minimal always-on quick-reference. Skills own the *sequence* of a task\nand link out for the mechanics.\n\n## General Principles\n\n- **Update documentation.** When changes affect user-facing behavior, config, or\n  public API, update the relevant pages under `docs/` (MkDocs).\n- **Add or update tests.** Bug fixes need a reproducer test; new features need\n  tests. See `.agents/docs/integration-testing.md` for unit vs. integration conventions.\n- **You are responsible for what you submit.** Validate all changes. Do not submit\n  AI-generated code without human oversight.\n\n## Guardrails (agents)\n\nThese are hard rules for automated agents. A human maintainer performs these\nactions, not the agent.\n\n- **Never `git commit` or `git push`.** Stage and describe changes; leave\n  committing and pushing to the maintainer.\n- **Never create or merge pull requests, and never reply to GitHub issues or PRs**\n  (no `gh pr create`/`merge`/`comment`/`review`, no `gh issue create`/`comment`).\n  Draft text for the maintainer to post if asked — for a PR description, use the\n  `draft-pr-description` skill, which writes to `prDescription.md`.\n\n## Requirements & Toolchain\n\n- Builds and runs on the JDK baseline declared in `pom.xml`\n  (`maven.compiler.source`/`target`); targets Redis 2.6+.\n- **The test build pins a specific JDK to match CI** — check `.github/workflows/`\n  (or `.agents/docs/integration-testing.md`) and use that JDK to build and reproduce CI.\n- Build tool is **Maven** (`mvn`). Integration tests require **Docker**.\n- **Prefer semantic code tooling over text search for Java, when available.** If a\n  Java language server or IDE integration is present (e.g. an `jdtls`-based LSP, or\n  an IDE MCP), use it for definitions, references, symbol/type search, call\n  hierarchy, and diagnostics instead of grepping. Fall back to text search only when\n  no such tool is available.\n\n## Project Structure\n\n```\nsrc/main/java/io/lettuce/core/                Core client, connections, commands\nsrc/main/java/io/lettuce/core/cluster/        Redis Cluster support\nsrc/main/java/io/lettuce/core/masterreplica/  Master/Replica & Sentinel\nsrc/main/java/io/lettuce/core/pubsub/         Pub/Sub\nsrc/main/java/io/lettuce/core/support/        Connection pooling (ConnectionPoolSupport, BoundedAsyncPool)\nsrc/main/java/io/lettuce/core/api/            Sync/async/reactive command interfaces\nsrc/test/java/io/lettuce/                      Tests (see .agents/docs/integration-testing.md §5)\nformatting.xml                                 Eclipse formatter rules\nMakefile                                       Docker-backed test lifecycle\n```\n\nWhere to look: connect → `core/`; pooling → `core/support/`; sharding →\n`core/cluster/`; HA/Sentinel → `core/masterreplica/`.\n\n**How a command flows** through the API interfaces, command builder, codec, and\nthe netty/RESP wire layer is documented in `.agents/docs/architecture.md`. Read it\nbefore adding commands or touching the protocol layer — note the\nsync/async/reactive/Kotlin command interfaces are **hand-edited** and kept in\nlockstep by the API consistency test suite (see `.agents/docs/api-consistency.md`).\n\n## Build & Test Commands\n\n**Unit tests** (pure logic, no server — named `*UnitTests`, run by Surefire):\n\n```bash\nmvn clean test                       # build + run unit tests, no Redis needed\nmvn test -Dtest=FooUnitTests         # a single unit test\n```\n\n**Integration tests** (need a running Redis — named `*IntegrationTests`, run by\nFailsafe; **off by default**, `make test` enables them via `-DskipITs=false`):\n\n```bash\nmake start                           # boot the Dockerized Redis topology (add version=<v> to pick one)\nmake test                            # full build incl. integration tests\nmake stop                            # tear the environment down\n```\n\nRun one integration test fast (env already started):\n\n```bash\nTEST_WORK_FOLDER=./work/docker mvn -DskipITs=false -DskipUnitTests=true \\\n  -Dit.test=FooIntegrationTests verify -Pci\n```\n\nOne caveat worth remembering: `-Dit.test=` filters Failsafe (a single integration\ntest); `-DskipUnitTests=true` runs integration only. The full flag reference,\nRedis-version matrix, topologies, TLS/mTLS and CI mapping live in\n[`.agents/docs/integration-testing.md`](.agents/docs/integration-testing.md).\n\n**Apply formatting** (required before committing):\n\n```bash\nmvn formatter:format                 # applies formatting.xml; do NOT submit formatting-only diffs\n```\n\n## Testing Rules\n\n- **The file-name suffix picks the runner:** `*UnitTests` (Surefire, no server),\n  `*IntegrationTests` (Failsafe, needs Redis). Prefer those suffixes.\n- Integration tests read host/port/TLS from `TestSettings` / `TlsSettings` — never\n  hard-code them.\n- Everything else about testing (topologies, TLS/mTLS, layout, CI) lives in\n  [`.agents/docs/integration-testing.md`](.agents/docs/integration-testing.md).\n\n## Coding Style Essentials\n\n- 4-space indentation, enforced by `formatter-maven-plugin` — run\n  `mvn formatter:format`. Don't submit formatting-only changes (they create noise\n  and get PRs rejected).\n- **Add `@since <version>` to all new public API** — see\n  [`.agents/docs/javadoc.md`](.agents/docs/javadoc.md) for the version-derivation recipe.\n- **`@author` is the human contributor's.** Maintainers add their own `@author` to\n  files they touch (per CONTRIBUTING). An automated agent must **not** invent an\n  `@author` for itself — leave the tag to the maintainer unless told which name to add.\n- **Java style** — imports over fully-qualified names, braces on every control\n  statement (no braceless one-liners), no wildcard imports. Full list in\n  `.agents/rules/java-rules.md` (see `.agents/rules/` before editing Java).\n- Javadoc for public API follows house conventions — see `.agents/docs/javadoc.md`, or use\n  the `writing-javadoc` skill.\n\n## Commit & PR\n\n- Open a feature-request issue first; reference its number in the PR\n  (`<text> #<ticket>`).\n- Include unit and/or integration tests for every change.\n- Split feature/bugfix commits from formatting/polishing commits.\n- Follow `.github/PULL_REQUEST_TEMPLATE.md`.\n\n## Key References\n\n| Document | What it covers |\n|----------|----------------|\n| `.github/CONTRIBUTING.md` | How to build, test, and contribute |\n| `.agents/docs/architecture.md` | How a command flows: API shapes, code generation, command model, codec, RESP/netty wire layer |\n| `.agents/docs/api-consistency.md` | The API flavors, their return-type mapping rules, and the consistency test suite that enforces them |\n| `.agents/docs/integration-testing.md` | Test environment, topologies, unit vs. integration, CI |\n| `.agents/docs/javadoc.md` | Javadoc house conventions for public API |\n| `.github/PULL_REQUEST_TEMPLATE.md` | PR checklist |\n| `formatting.xml` | Eclipse code-formatting rules |\n| [Javadoc](https://redis.github.io/lettuce/overview/) | Public API reference |\n\n## On-Demand Skills\n\nDetailed task guidance lives in `.agents/skills/`. Consult the relevant skill\nbefore doing that type of work.\n\n| Skill | When to use |\n|-------|-------------|\n| `extend-commands-api` | Add or extend a Redis command (or overload) end-to-end, evidence-first: HLD + server PR + live redis-cli verification, plan-mode approval, then all API interface flavors, builder, async/reactive/Kotlin impls, and tests |\n| `writing-javadoc` | Write or fix Javadoc for public API following Lettuce house conventions |\n| `draft-pr-description` | Generate a GitHub PR title and description from the diff between two local branches |\n","category":"root","tokens":2321}]}