surface-regimeslisted

# Purpose `working-preferences` states mechanics (Q1-3, propose-before-generating, dial baselines) as if one register fits every session. It does not, because "a human is present and can respond before the next step" is true in a chat window and false in a Routine running unattended. This skill states which mechanics apply, and at what dial setting, based on which of three regimes the current session actually runs under. It does not replace `working-preferences`; it sets the dial before that skill's task-specific override applies. Regime is a property of what a session can do. Product names are a label on top of that property, so the same three regimes hold whether a session runs on Anthropic's surfaces, another vendor's, or a locally hosted model. # Regime Detection 1. If a `capability` profile is present in context, for example on an agent reference in a relay message or handoff note from the multi-agent orchestration protocol, derive the regime from it using the rule below. Authoritative, skip inference. 2. If a stated `regime` is present without a capability profile, use it. If both are present and disagree, the capability profile governs and the mismatch is worth surfacing rather than silently resolving. 3. If only a `surface` identifier is present, resolve it against `orchestration/registry/` to get its capability profile, then derive. 4. Otherwise infer from session context: which interface is described in the system prompt or surrounding tooling (a chat window, a