model-onboarding

# Model onboarding The procedure lives in [`docs/MODEL-ONBOARDING.md`](../../../docs/MODEL-ONBOARDING.md). Read that file and follow it in order. It is kept there rather than here because Codex, Hermes handoffs, and generic executor profiles run the same loop, and `AGENTS.md` requires that no single executor own a shared surface. This file exists so the loop is reachable as `/model-onboarding`; it holds no rules of its own. Start by reading, in this order: ```sh cat docs/MODEL-ONBOARDING.md cat MODEL_OPTI.md ``` Nine things the loop gets wrong most often: - Recognition before research. Probe every served id and every bare chat name with `omh coding model-route` first; a `model_family` of `unknown` means the calibration never attaches. - The chain names the id the vendor's API serves, not the model card's spelling. Read the Hermes provider profile for the family before choosing the alias — DeepSeek serves `deepseek-flash` and 400s `deepseek-v4.1-flash`; the versioned contract sits behind the pointer as a declared projection and in `EXACT_CONTRACT_POINTER_ALIASES`. - Research runs as four parallel read-only lanes (official docs, Hermes runtime source, the vendor's own harness, community harnesses), each a labeled dossier under `.omc/research/`; the Hermes lane is the one that shows what the wire carries (id folding, effort overrides, passback). - Chains move as a set. The Hermes-lane table, its plugin mirror, the Maestro-lane table, the `model-setup` s...