GitHub conventions

Branches and PRs

Branch from the repository's authoritative base unless continuing an existing PR head. All branch operations happen inside a valid Treehouse lease acquired with scripts/treehouse-bloxclips acquire <backend|frontend|metric-scraper> --task <issue-or-slug> (the helper defaults to task/<issue>[-<slug>] and refuses a branch already held by another active lease); an existing PR head may be continued only through such a lease, never by working in a primary checkout directly. Never create an ad-hoc worktree.
Suggested names: feat/<issue>-<slug>, fix/<issue>-<slug>, test/<issue>-<slug>, docs/<issue>-<slug>.
Never force-push another person's branch or rewrite shared history.
One repository per PR. Link cross-repository counterpart PRs explicitly.
Keep commits coherent and reviewable. Do not mix formatting or unrelated cleanup.
PR title: <type>(<area>): <outcome> (#<issue>).
PR body must include Summary, Why, Scope, Verification, Data/Migration Impact, Risks/Rollback, and Links.

Inspect the complete parent/child tree; implement the leaf or explicitly bounded slice.
Before starting, check assignee, status, linked PRs, comments, dependencies, and overlapping changed paths.
Mark a packet blocked rather than duplicating existing work.
Do not close parent issues because one child or one repository finished.

No merge or deployment by an implementation worker.
No ad-hoc worktrees and no edits in primary checkouts; Treehouse leases only.
No production database commands or live financial/provider mutations.
Migrations require fresh disposable-database replay and rollback/compatibility notes.
Generated fixtures must be sanitized and contain no credentials or personal data.