CodeWhale Agent
52 lines
2.4 KiB
Markdown
52 lines
2.4 KiB
Markdown
# 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.
|
|
- Do not tag, publish, create a GitHub Release, or push release artifacts
|
|
without Hunter's explicit approval.
|
|
- Keep CodeWhale branding while preserving first-class DeepSeek model/provider
|
|
support and 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.
|
|
|
|
## Scratch Integration Branches
|
|
|
|
- For release queues, create disposable local branches from the real landing
|
|
branch, for example `scratch/v0.8.59-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.
|
|
- Do not ship the scratch branch itself. It may contain noisy merge commits,
|
|
partial conflict resolutions, and unrelated PR interactions.
|
|
- 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.
|
|
|
|
## v0.8.59 Release Work
|
|
|
|
- Base release triage on `codex/v0.8.59-release-ready` unless Hunter gives a
|
|
newer branch.
|
|
- 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 release branch already
|
|
contains equivalent work. If it does, prepare the GitHub note/closure path
|
|
instead of reimplementing it.
|
|
- For the current v0.8.59 queue, start with
|
|
`docs/V0_8_59_RELEASE_TRIAGE.md`, then refresh live GitHub state before
|
|
taking action.
|