Q & Hermes
Q Dev-Driver
Re-orienting Hermes from Alex's day-job assistant into Q, the estate's own quartermaster — role, tools, and a build-then-review pipeline.
Situation
An audit root-caused why Q (Hermes on the Tower) wasn't behaving like the estate's builder: no defined role, a pile of generic bundled skills (apple/email/social/…) with account access, an empty q_tasks backlog, and a default model weaker than Claude for code reasoning. The plumbing was healthy — q-gateway active, repos cloned, digest cron running, Hermes had already shipped a reviewed PR — but nothing oriented or drove it to be the builder.
This design re-orients Hermes into Q the quartermaster: it builds and refactors the Mallory + Hermes estate, self-reviews cheap builds with a stronger model, reports on R&D, stays PR-only unless told otherwise, and keeps the estate's model strategy tuned.
Key decisions
Clear out + re-orient
SOUL.md defines Q's job (build/refactor the estate, report on R&D — explicitly not Alex's day-job); USER.md points at docs/estate/ + AGENTS.md; non-dev toolsets (apple, social-media, email, productivity, …) are disabled via config.yaml.
Build-then-review pipeline
Per task: triage picks a builder model by complexity (cheap qwen3.7-max vs. claude-sonnet-4.6 for complex/multi-file) → build on a feature branch → a stronger reviewer model approves or requests changes (bounded retries) → PR + report.
Task sources: delegate + Q-proposes
Alex delegates via R&D as today; Q also reads the roadmap and proposes estate-improvement tasks into the backlog for approval via the existing create_tasks frame — the edge stays the sole q_tasks writer, nothing runs unapproved.
PR-only by default
Plan → build+review self-check → PR → report is the full loop; Q merges/deploys only on Alex's explicit instruction. The self-check is the quality gate on cheap builds; merge/deploy stays a human gate.
Standing model-research task
A living docs/evals/model-comparison.md (quality×cost per purpose: build/review/persona/recall/reasoning), refreshed on a cheap frequent watch + a fuller monthly/new-generation re-eval, with a check-in only when the recommendation materially changes.
Architecture
Q's role/config is version-controlled in mallory-runtime and applied to the Tower; the pipeline and model-research are Tower scripts reusing the mallory repo's existing eval harness.
evals/ harness) that keeps the builder/reviewer model tiers current and posts a check-in only on material change.Risks & guardrails
Model ids must be verified live
Bare *-latest aliases have 404'd before; tier constants hold verified OpenRouter ids with a confirmed fallback, checked again at implementation.
Round 1 hardening stays parked
This narrows blast radius (scoped role, trimmed tools) but Q still runs as alexhansford --yolo within its branch — noted, not resolved here.
Build+review retry loop needs a bound
The review-loop-back-to-build cycle on CHANGES must be capped to avoid runaway cost on a stuck task.
Delivery
Phase A — re-orient
SOUL/USER/tool-trim applied to the Tower — low-risk, reversible.
Phase B — build-then-review pipeline
estate-dev skill + q-gateway 3-pass orchestration.
Phase C — standing model-research
Script + living comparison doc + Hermes cron.
Phase D — backlog seed
Q proposes an initial task set from the roadmap; Alex approves.
Phase E — prove end-to-end
One real small estate task run through the full pipeline to a reviewed PR.
Out of scope
docs/superpowers/specs/2026-06-20-q-dev-driver-design.mdplan ·
docs/superpowers/plans/2026-06-20-q-dev-driver.md