ThothII/docs/reports/2026-09-12-unified-interaction-model.md

Unified interaction LLM — local implementation

Date: 2026-09-12. This change is separate from selection of the final administration/context-shelf prototype. No deployment, Gitea issue publication, or Omics Portal modification was performed.

Implemented

• One authored modelCatalog.defaults.interaction per installation, independent of workspace. The local PSD descriptor and tracked example now use zai/glm-5.3 in this field.
• One generated defaultInteraction in runtime catalog schema v2; host projections, backend settings, Pi diagnostics, Core admission and metadata-generation consumers use that value.
• Separate Pi/LiteLLM adapters remain. When Admin AI is configured, both public lists and Pi's enabled list use their intersection. Single-use entries remain inventory, not global choices. Core-only installations remain possible when no Admin model is configured. Embedding is unchanged.
• Equal legacy defaults normalize on read without rewriting the source; divergent defaults or mixed old/new fields fail with migration guidance. Generated schema-v1 catalogs must be regenerated.
• The existing Core and Database selectors now share application preferences, using complete canonical IDs, including when two providers use the same short model name.
• Explicit LLM choices are remembered in browser storage per origin/application mount and authenticated issuer/subject. Automatic defaults are not stored as explicit choices. Workspace and thinking preferences retain their existing in-memory lifetime.
• Core/description-generation activity disables the existing model controls using existing state and the shared run cache. This is not a new cross-workspace/background job subsystem.
• New sessions reject unavailable selections without fallback. Resume receives the global model (or uses the installation default when omitted), keeps the historical workspace/revision and does not overwrite the original manifest model fields. Archived/finalized sessions remain read-only.
• Pi management instructions and the configuration guide require an operator to exercise each model in both Core and Administration. There is no automatic certification flag or live probe.

PSD DeepSeek consolidation

Following explicit operator approval, the local PSD descriptor and its tracked example use one deepseek provider with native Pi and LiteLLM adapters. Both deepseek/deepseek-v4-pro and deepseek/deepseek-v4-flash are eligible for shared selection. The duplicate deepseek-metadata provider declaration is removed; historical records remain unchanged. The installation default stays zai/glm-5.3.

A value-free comparison confirmed that the existing Pi DeepSeek key and the existing DEEPSEEK_API_KEY bundle entry are identical; both source files have mode 0600. No secret file was changed. The catalog now declares secret_env / DEEPSEEK_API_KEY as the authoritative source for both paths. Pi session snapshots exclude the selected provider's old auth entry, without changing the original store or unrelated entries. Missing bundle keys fail closed instead of falling back to old Pi auth or the generic key file. Availability enumeration, credential status, and isolated provider smoke checks follow the catalog declaration as well.

Verification

• All host CLI Go packages pass go test ./....
• Backend under Node 24.16.0 after DeepSeek consolidation: 108 test files pass, 1 skipped; 1,377 tests pass, 40 skipped. Backend TypeScript check passes.
• New regression coverage checks shared DeepSeek configuration/projection, canonical Core/Admin identities, bundle-backed model enumeration, stale Pi auth precedence, missing-key refusal, preservation of the source auth store, and sanitized credential status. All credentials in these tests are synthetic; no model inference is performed.
• Full frontend run: 658 tests pass; three remaining failures concern existing administration-layout work: Workspace preprocessing region, Catalog status placement, and Sync history entry point. These controls were already being changed in the dirty worktree before this model change.
• The focused Core/Admin model synchronization test also verifies locking during Core and description-generation activity, unlocking afterward, and provider-qualified identity. It passes.
• Frontend typecheck still reports three exact option errors in the pre-existing, untracked AppShell.administration.test.tsx (lines 48, 66, 71). No new type errors are reported.
• Earlier parallel runs encountered timing-sensitive auth-helper failures; the complete backend rerun with Node 24 and two workers passes. The Homebrew node@24 path on this machine actually reported Node 25; the verified Node 24 executable is under the user's nvm installation.
• No live provider calls or full deployed Pi/LiteLLM/Omics acceptance tests were performed.
• git diff --check passes. Strict documentation build remains blocked by an existing link in the untracked plans/2026-09-10-administration-pages-spec.md pointing outside the documentation tree to the administration-review prototype README. The updated configuration guide adds no warning.

The full frontend gate is not green; this is not a deployment-ready acceptance claim. Pre-existing production UI edits and every prototype are preserved. The final collapsible global context layout, general Core/Admin admission policy and server assembly remain in the wider UI workstream.

Applying later

Use the matching host/backend release, review the installation descriptor, then apply the normal installation lifecycle to regenerate all runtime projections together. Do not deploy only the new backend against an old generated catalog. Follow the dual-path operator checklist in Installation Model Catalog.