Modes

Four worker modes, one qa role

The --type on hivectl fire picks the worker's mode; the target repo owns the per-type playbook (<app>/.claude/skills/<TYPE>/) and per-repo rules (<app>/.claude/CLAUDE.md), which the pod auto-loads.

Worker modes

feature-implementation

Build a new capability from the issue's Plan + DoD.
type:feature

bug-fix

Reproduce, fix the root cause, prove it with the DoD checklist.
type:bug

improvement

Refactor / harden / tidy without changing behavior.
type:improvement

research

Produce a findings document — no code, no PR expected.
type:research

The qa role

qa is fired separately (hivectl qa --url=<U> [--target=<ISSUE>]), runs on a browser-equipped image, and drives the running app from the outside. It never reads source. Its only writes are QA artifacts to an orphan branch qa-artifacts/issue-<N>/<ts>/* and a new type:qa-feedback issue cross-linking the target. Those feedback issues re-enter the loop as ordinary work.

Shared conventions

Every fire, every type, obeys the same contract:

ConventionRule
## Definition of DoneRequired. ≥1 verifiable - [ ] checklist line. Driver refuses to fire without one (no auto-stub).
## PlanRequired as authoritative scope. Driver may draft a ## Plan (proposed by driver) block; a human renames it to plain ## Plan to approve.
In-pod reviewA fresh claude process grades the DoD and emits REVIEW: PASS | CHANGES_REQUESTED. PASS → driver merges; CHANGES_REQUESTED → driver re-fires.
TemplatesPR body, status comments, needs-human comments, and per-type briefs all render from k8s-sandbox/image/templates/ via envsubst.
qa-feedback carve-out. For type:qa-feedback issues only, the driver drafts the DoD (one verifiable line per concrete defect), since the qa finding text already is the human intent. Every other type keeps the no-auto-stub rule.

Type labels

LabelMeaning
type:featureNew feature implementation
type:bugBug fix
type:improvementRefactor, polish, or quality work on existing code
type:researchInvestigation / write-up only; no PR expected
type:qa-feedbackFiled by the qa role; cross-links the target issue

Each issue carries exactly one type:* and one status:* label — see the lifecycle diagram.