/CLAUDE.md

# Claude Repository Guidance

Read `AGENTS.md` first. This file exists as a compatibility instruction source
for Claude-based agents working in this repository.

## Stewardship Defaults

- Treat community PRs and issues as maintainer evidence. Inspect code, tests,
  linked issues, comments, and CI before merging, harvesting, closing, or
  deferring work.
- CodeWhale started as a DeepSeek-only harness; it's now about building the
  greatest possible coding harness with the help of an open-source community.
  Keep CodeWhale branding and every model/provider first-class — none
  privileged — and preserve legacy migration care.
- Preserve contributor credit for harvested work with authorship,
  `Co-authored-by`, `Harvested from PR #N by @handle`, and changelog/release
  notes where applicable. Keep `Co-authored-by` trailers to human contributors,
  using canonical GitHub-noreply identities from `.github/AUTHOR_MAP` — the
  `check-coauthor-trailers.py` CI gate accepts those and rejects bot/tool ones
  (Claude, codex, cursor), so use a plain commit body to note agent assistance.

## Scratch Integration Branches

- For release queues, create disposable local branches from the real landing
  branch, for example `scratch/vX.Y.Z-pr-train-YYYYMMDD`.
- Use the scratch branch to merge or cherry-pick candidate PR heads in batches
  and learn which conflicts, tests, and overlaps are real.
- Treat the scratch branch as throwaway evidence — it collects noisy merge
  commits, partial conflict resolutions, and unrelated PR interactions, so ship
  from the release branch instead.
- After the scratch experiment, move only the safe result back to the release
  branch as narrow commits or direct merges. Keep each final commit explainable
  and testable.
- A PR that is clean against `main` is not necessarily clean against a release
  branch. Test mergeability against the branch that will actually receive the
  work.
- For already approved PRs, treat approval as a strong priority signal. Still
  inspect diffs, comments, check results, and release-branch conflicts before
  landing.

## Current Release Work

- Confirm the active branch for the current release lane from the latest handoff
  and `git branch --show-current`; recent work has landed on `main` through small
  PRs rather than a long-lived `codex/...` integration branch. This repo lives on
  multiple devices, so work in whichever local checkout you have and confirm the
  branch before editing.
- Read the workspace version from `Cargo.toml`; it advances per release lane.
- Base release triage on the current GitHub release milestone named in the active
  handoff (`gh issue list --repo Hmbown/CodeWhale --milestone "<current>" --state open`)
  unless Hunter gives a newer branch/milestone.
- Work the queue in this order: release blockers, recently approved PRs, clean
  PRs with small scope, blocked PRs with obvious fixes, dirty PRs that can be
  harvested safely, then larger architecture issues.
- Prefer batching PR conflict discovery on scratch branches, then harvesting
  reviewed, credited, tested slices back into the release branch.
- Before claiming an issue is done, verify whether the branch already contains
  equivalent work. If it does, prepare the GitHub note/closure path instead of
  reimplementing it.
- See `AGENTS.md` → "Where to work right now" for build/test commands, known
  suite papercuts, and the removed-machinery guardrails (agent-only surface,
  no lifecycle/coherence systems).