Files

T

CodeWhale Agent c08f161e1f docs: add v0.8.59 triage runbook and scratch-branch integration guidance

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-06-12 09:56:29 -07:00

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.

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.

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.