Rename Rhesis Default model to Rhesis

[harry-rhesis]

Purpose

The Rhesis-hosted default model was named "Rhesis Default" with model_name "default", which reads oddly in the UI now that other Rhesis-hosted models exist (Polyphemus). It's being renamed to "Rhesis" with model_name "rhesis-managed" to read more cleanly, matching the updated design.

What Changed

• Renamed the onboarded model display names: "Rhesis Default" → "Rhesis", "Rhesis Default Embedding" → "Rhesis Embedding"
• Changed model_name from "default" to "rhesis-managed" for both, so the composite id becomes rhesis/rhesis-managed (was rhesis/rhesis-default)
• Updated all backend defaults (ModelSettings), SDK defaults (sdk/src/rhesis/sdk/models/defaults.py), the explorer embedding fallback lookup, chatbot app defaults, Helm chart values, and .env.example to the new composite id
• Added Alembic migration b7e3a1c9d2f6 to rename existing org rows in the model table (with a downgrade path back to the old names)
• Updated docstrings/comments referencing the old name
• Updated backend and SDK tests to match

Additional Context

• Kubernetes external-secrets keys (e.g. dev-rhesis-default-polyphemus-url) are left as-is — those are GCP Secret Manager key names for Polyphemus, unrelated to this model's identifier, and changing them needs coordinated infra work.
• Historical Alembic migrations and CHANGELOG entries that reference the old name are untouched, as historical records.

Testing

• Ran uv run pytest ../../tests/backend/services/test_organization.py ../../tests/backend/app/test_settings.py ../../tests/backend/routes/test_explorer.py ../../tests/backend/services/explorer/ from apps/backend — 358 passed, 1 skipped (pre-existing skip)
• Ran uv run pytest ../tests/sdk/models/test_model_factory.py ../tests/sdk/connector/test_serializer_integration.py from sdk — 64 passed
• Applied the new migration to the local dev database (uv run alembic upgrade head) and confirmed all 131 org rows updated: Rhesis/rhesis-managed and Rhesis Embedding/rhesis-managed, with no leftover "Rhesis Default" rows

[peqy]

Improvement: Tighten the embedding fallback and migration predicates.

1. get_default_embedding_model() now prefers a more generic name ("Rhesis Embedding")—consider ensuring it can’t accidentally select a user-created model with the same name.
2. Alembic migration matches only on name + is_protected; consider additionally matching on expected model_name/provider/model_type so upgrade/downgrade are safer against unexpected duplicates.

[peqy]

Improvement: get_default_embedding_model() now prefers the org model named "Rhesis Embedding".

If a user creates a non-protected embedding model with the same name, this will pick that one first (.first()), which seems like an easy footgun now that the name is more generic.

Fix: Consider adding models.Model.is_protected.is_(True) (and/or joining provider_type == "rhesis") to the by_name query as well, so the fallback is guaranteed to pick the system model.

[peqy]

Confirmed fix: adding is_protected.is_(True) to the org-name fallback avoids collisions with user-created models named "Rhesis Embedding". Thanks!

[peqy]

Improvement: The migration renames rows purely by name + is_protected = TRUE.

If an org ever ends up with multiple protected Rhesis models called "Rhesis" (or "Rhesis Embedding") from prior partial runs/manual fixes, the downgrade() would flip all matching rows back to model_name='default'.

Fix: Consider tightening the WHERE clauses to also include provider (join on provider_type_id → type_value = 'rhesis') and the expected model_type, or at least match on the old/new model_name values too (e.g. upgrade WHERE model_name='default', downgrade WHERE model_name='rhesis-managed').

[peqy]

Much safer with the provider_type_id (= rhesis) predicate added. Optional extra hardening: also constrain by the expected model_name (upgrade model_name='default', downgrade model_name='rhesis-managed') and/or model_type, so a future additional protected Rhesis model named "Rhesis" doesn’t get flipped on downgrade.

[harry-rhesis]

Leaving as-is for now — name + is_protected + provider=rhesis already uniquely identifies these rows given the current data model (one protected rhesis-provider model per org per type today). Adding a model_name guard would only matter for a hypothetical future protected model also named "Rhesis" with a different `model_name", so not worth the extra complexity right now. Thanks for flagging it though.

[peqy]

Makes sense — with provider=rhesis + is_protected (and given the current “one protected rhesis model per org per type” invariant), the migration scope is already pretty tight.

If you keep it as-is, one small suggestion would be to add a brief comment in the migration noting that assumption, so future us knows why we didn’t also guard on model_name/model_type. Otherwise I’m good with this.

[peqy]

Update after 13c866d:

• ✅ get_default_embedding_model() now filters is_protected, so it won’t accidentally pick a user-created model named “Rhesis Embedding”.
• ✅ Migration WHERE clauses are tightened to the rhesis provider.

Remaining (non-blocking) hardening suggestion: in the Alembic migration, also constrain upgrade/downgrade by the expected model_name (upgrade model_name='default', downgrade model_name='rhesis-managed') and/or model_type, so a future additional protected Rhesis model with the same display name doesn’t get flipped during downgrade.