# CLAUDE.md

## Project

Bash/shell project. Customize this section with your own description, layout,
and conventions.

**Typical layout:**
- `bin/` or top-level `*.sh` — entry-point scripts
- `lib/*.sh` — sourced function libraries (no `set -e`; the caller owns the shell)
- `tests/*.bats` — bats-core tests beside the scripts they exercise

## Build & Test Commands

If the project has a Makefile, document targets here. Common pattern:

```bash
make test                  # run the bats suite
make test FILE=tests/x.bats # one file
make lint                  # shellcheck across the tree
make fmt                   # shfmt -w (if the project adopts shfmt)
```

Direct equivalents: `bats -r tests/`, `shellcheck script.sh`,
`shfmt -d script.sh` (diff), `shfmt -w script.sh` (write).

## Language Rules

See rule files in `.claude/rules/`:
- `bash.md` — code style and patterns (strict mode, quoting, `[[ ]]`, traps)
- `bash-testing.md` — bats conventions
- `verification.md` — verify-before-claim-done discipline

## Git Workflow

Commit conventions: see `.claude/rules/commits.md` (author identity,
no AI attribution, message format).

Pre-commit hook in `githooks/` scans for secrets and runs `shellcheck` on staged
shell files. Activate on a fresh clone with `git config core.hooksPath githooks`.

## Problem-Solving Approach

Investigate before fixing. When diagnosing a bug:
1. Read the relevant script and trace what actually happens
2. Identify the root cause, not a surface symptom
3. Write a failing bats test that captures the correct behavior
4. Fix, then re-run tests

## Testing Discipline

TDD is the default: write a failing test before any implementation. If you can't
write the test, you don't yet understand the change. Details in
`.claude/rules/bash-testing.md`.

## Editing Discipline

A PostToolUse hook runs `shellcheck` on every shell file after Edit/Write/
MultiEdit and blocks on a violation — read the SCxxxx code and fix it (each has a
wiki page). The hook covers `.sh`, `.bash`, and extensionless files with a shell
shebang. Formatting (`shfmt`) is recommended but not enforced by the hook, since
shell has no single canonical style; adopt one per project via `.editorconfig`.

## What Not to Do

- Don't add features beyond what was asked
- Don't refactor surrounding code when fixing a bug
- Don't leave expansions unquoted or use `[ ]` where `[[ ]]` fits
- Don't add comments to code you didn't change
- Don't commit `.env` files, credentials, or API keys — the pre-commit hook
  catches common patterns but isn't a substitute for care