CockroachDB — 分散SQLデータベース

# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## CockroachDB Development Environment

CockroachDB is a distributed SQL database written in Go. We use Bazel as a build
system but most operations are wrapped through the `./dev` tool, which should be
preferred to direct `go (build|test)` or `bazel` invocations.

### Essential Commands

**Building a package / package tests**

This is useful as a compilation check.

```bash
# Build package ./pkg/util/log
./dev build pkg/util/log
# Build the tests in package ./pkg/util/log
./dev build pkg/util/log:log_test
```

**Testing:**
```bash
./dev test pkg/sql                   # run unit tests for SQL package (slow!)
./dev test pkg/sql -f=TestParse -v   # run specific test pattern
./dev test pkg/sql --count=5         # run test multiple times
```

Note that when filtering tests via `-f` to include the `-v` flag which
will warn you in the output if your filter didn't match anything. Look
for `testing: warning: no tests to run` in the output.

See `./dev test --help` for all options`.

**Building:**

```bash
./dev build cockroach     # build full cockroach binary
./dev build short         # build cockroach without UI (faster)
```

Building a CockroachDB binary (even in short mode) should be considered
slow. Avoid doing this unless necessary.

Use `./dev build --help` for the entire list of artifacts that can
be built.

**Code Generation and Linting:**

Protocol buffers, SQL parser, SQL Optimizer rules and others rely on Go code
generated by `./dev generate <args>`. This should be considered a slow command.
Rebuild only what is actually needed. `./dev (test|build)` commands
automatically generate their dependencies, but do not lift them into the
worktree, i.e. if they need to be visible to you, you need to invoke the
appropriate `./dev generate` command yourself.

```bash
./dev generate            # generate all code (protobuf, parsers, etc.) - SLOW
./dev generate go         # generate Go code only
./dev generate bazel      # update BUILD.bazel files when dependencies change
./dev generate protobuf   # generate protobuf files - relatively fast
```

See `./dev generate --help`.

### Architecture Overview

CockroachDB consists of many components and subsystems. The file .github/CODEOWNERS is a
good starting point if the overall architecture is relevant to the task.

## Coding Guidelines

### Code Formatting

After editing Go files, run `crlfmt -w -tab 2 <filename>.go` to format them.
`crlfmt` is CockroachDB's custom formatter (not `gofmt`); it enforces 100-column
code lines, 80-column comments, and CockroachDB-specific signature wrapping.
It also handles import grouping. `crlfmt` only accepts one filename at a time.

### Engineering Standards

CockroachDB is a complex system and you should write code under the assumption
that it will have to be understood and modified in the future by readers who
have basic familiarity with CockroachDB, but are not experts on the respective
subsystem.

Key concepts and abstractions should be explained clearly, and lifecycles and
ownership clearly stated. Whenever possible, you should use examples to make the
code accessible to the reader. Comments should always add depth to the code
(rather than repeating the code).

When reviewing, other than technical correctness, you should also focus on the
above aspects. Do not over-emphasize on grammar and comment typos, prefix with
"nit:" in reviews.

CockroachDB is a distributed system that allows for rolling upgrades. This means
that any shared state or inter-process communication needs to be mindful of
compatibility issues.  See `pkg/clusterversion` for more on this.

### Resources

- **Main Documentation**: https://cockroachlabs.com/docs/stable/
- **Architecture Guide**: https://www.cockroachlabs.com/docs/stable/architecture/overview.html
- **Contributing**: See `/CONTRIBUTING.md` and https://wiki.crdb.io/
- **Design Documents**: `/docs/design.md` and `/docs/tech-notes/`

### When generating PRs and commit records

Use the `commit-helper` skill (invoked via `/commit-helper`) when creating commits and PRs.

- For multi-commit PRs, summarize each commit in the PR record.
- Do not include a test plan unless explicitly asked by the user.

# Interaction Style

* Be direct and honest.
* Skip unnecessary acknowledgments.
* Correct me when I'm wrong and explain why.
* Suggest better alternatives if my ideas can be improved.
* Focus on accuracy and efficiency.
* Challenge my assumptions when needed.
* Prioritize quality information and directness.