MC-4207

Parked campaign plan from Elmar Telegram review of `/Users/elmar/PKA/docs/hermes-worker-orchestration-playbook.md`. Decision direction: - Do NOT replicate all Hermes role profiles from Lucienne/Mac onto Luci right now. - Implement the same operating process inside Mission Control/Luci using role abstractions backed by runtime profiles, luci-persistent, scheduled tasks, and the MC controller. - Treat `planner`, `designer`, `coder`, `qa`, `tester`, and `validator` as durable employee/role lanes. The role name is stable; the underlying runtime/model can change. - Dashboard must show where each item is in the gate sequence so Elmar can follow coder -> QA -> tester -> designer signoff -> validation without asking Telegram for every state change. Proposed acceptance criteria: 1. Role-to-runtime registry exists in MC: role, allowed runtime_profile(s), tools/capabilities, read/write permission, evidence expectations, fallback. 2. Ticket/campaign workflow supports required gates: plan, design direction, implementation, first validation, QA review, browser/user testing, designer screenshot signoff, final validation. 3. Dashboard/Workbench exposes the active gate, owning role/runtime, latest evidence packet, and next blocker/reviewer action. 4. Controller/scheduler can launch or supervise role lanes without creating separate Hermes profiles for every role on Luci. 5. Validation packet format is first-class: changed files, test commands/results, screenshots, QA/design/tester signoff, remaining risk, deploy/push/restart status. 6. Existing MC-4119 visual-redesign gates are preserved and become the reference process rather than a special case. Park until current Home/MC-4119 recovery is stable; then launch as a dedicated campaign. <!-- visual-policy:safety-v1 --> Controller safety guardrail: no live deploy, luci-dashboard restart, direct copy into main/live tree, or production runtime mutation without explicit Elmar approval. Work in a feature branch/worktree; leave deploy/restart approval to the controller/Elmar.