MC-4375

Queued from Telegram question: "do we need to do this for each runtime and for yourself maybe? How do you see this working and how does it compare to what we have." Context: - Prior ticket MC-4372 asks to make MC's simple Three Man Team model durable: Architect is design-aware; Reviewer is browser/test-aware. - Elmar is now asking whether this must be implemented per runtime/profile, also for Luci herself, and how it compares to current MC architecture. Required analysis/deliverable: 1. Inspect current MC runtime/profile architecture, worker prompts, Luci/persistent prompt path, ticket runtime prompts, WAT roles, Tessa/reviewer gates, and scheduler/worker dispatch boundaries. 2. Answer whether the Architect/Builder/Reviewer contract should be: - duplicated per runtime, - centralized in MC role/gate contracts and injected into runtimes, - applied to Luci herself / persistent orchestrator behavior, - applied differently for ticket workers, scheduler jobs, Larry, Tessa, council, and direct API/tool-less jobs. 3. Compare proposed target model with current MC implementation: - what already exists, - what exists but is scattered or implicit, - what is missing, - where stuck tickets are likely caused by missing contracts vs dispatcher/runtime bugs. 4. Recommend a concrete architecture: - one canonical role contract / checklist source, - adapter-specific injection points for Claude Code, Hermes, Codex/Gemini/Kimi/API, scheduler, and Luci persistent session, - evidence requirements by work class (code-only, UI/browser, mobile, architecture, scheduled/task-only), - minimum smoke tests including break/recovery scenarios. 5. Produce a concise user-facing comparison that Elmar can read: "central contract, runtime adapters only; yes, Luci must obey it too; no, not hand-maintained in every runtime." Acceptance criteria: - Finds evidence from code/docs, not memory only. - Produces a recommendation before implementation changes. - Names the exact files/modules/prompts that should become canonical or should be updated. - Explains how this interacts with MC-4372 and the stuck-ticket investigation. - If a clear implementation follow-up is needed, create or update the relevant ticket rather than leaving it as prose. Expected check-in: within 2 hours with recommendation and next ticket/action.