[imneov]

What type of PR is this?

• feature
• documentation
• install / chart

What this PR does and why

Users of a static JSON model catalog cannot add their own deployable model templates from Model Library. #73 only provides writes to an initialized writable catalog-server; it does not cover the reported installation. This adds Console-owned template creation, persistence, publication and UI, preserving existing catalog models and requiring no changes to other projects.

• Add a structured New model template sheet with optional reference-recipe copying, model identity/weights source, engine/image/chart, hardware and runtime values.
• Save immutable templates in a bounded runtime ConfigMap with resourceVersion concurrency checks. Publish exact version YAML bytes and matching v1 index digests at generation snapshot URLs.
• Serve anonymous catalog reads on a separate internal-only listener and ClusterIP Service; the normal web/NodePort listener returns 404 for those paths. Native authoring APIs use Console authentication, reset guards and explicit template/backend grants.
• Register console-local through the existing Swiss profile API, preserving original catalogs, operator-selected defaults, other YAML and comments. Saved-but-unconnected templates return 202, remain visible, cannot deploy, and have a connection retry action; ready creations return 201.
• Show original and custom cards together by default, retaining each card's real catalog for deployment. Native ownership is verified by publication location as well as name, so a foreign same-name catalog remains accessible. Adapt legacy index/entry wire responses and legacy version history alongside current responses without changing the copied Swiss UI.
• Keep contextual private registration causes and emit safe diagnostic fields while preserving stable public reason codes.

Which issue(s) this PR fixes

Fixes #64
Refs #84 (API/storage/publication design)

The issue was reopened after correcting the earlier assumption that #73 covered static catalog installations. It remains open for review and acceptance.

How it was tested

• Frontend typecheck, full suite (400 tests), Console and standalone Swiss builds. Combined with inferences: no way to turn on in-flight generation recovery (continuation_gateway) for a deployed model #63/inferences: no way to bring an existing deployment under management #65/inferences: upgrade sheet's Override YAML starts empty instead of showing the current values #66/Deploy form: hide the Monitor field until the monitor is open-sourced #76/Deploy form: merge the adaptive concurrency switch with its route options, and hide them when it is off #75: 474 frontend tests and both builds pass.
• Independent Standards/Spec review identified operator-default preservation, foreign same-name catalog shadowing, error diagnostics and module-boundary/style issues; all addressed with regression tests and fixes.
• Full Go tests, go vet ./..., scoped storage/registration/permission tests, dedicated-publication/web-404 boundary tests, and Helm config/RBAC/ClusterIP-only rendering and strict lint.
• Compiled the existing legacy Swiss dfdc4be CLI read-only from an archive. It read the actual generated index/recipe over HTTP and composed a plan.swiss/v1 plan, including a browser-generated template input. No install/apply ran.
• Browser verification used the reported installation's real 18-model catalog read-only. Template writes and plan previews were isolated locally: reference copying, check/save, a new custom card, model details, and deployment selection with catalog=console-local and the new model identifier. No real catalog, site profile or workload was modified.

Checks

• go test ./... and Go formatting
• npm run typecheck && npm test && npm run build in web/
• helm lint --strict helm/console
• User guides, architecture, chart operator documentation and example configuration updated
• No internal hostnames, IPs, registries or credentials in committed examples/screenshots

Notes for reviewers

Review #84 and docs/architecture/local-model-templates.md first. Current scope is immutable new names/versions, v1 static publication and the existing Helm deployment path; it does not download weights, supply chart packages, overwrite original static catalogs, or add v2 LLMService publication. Runtime state is bounded to about 900 KiB; full storage and duplicate names fail explicitly.

Swiss's existing profile API has no CAS. Registration preserves/rechecks current YAML and reconciles generations with bounded retries, but cannot promise a transaction against an external administrator editing that profile concurrently. Native persistence success is reported separately from connection readiness.

Release note

Model Library can create Console-managed deployable model templates alongside static catalog models, with persistent storage, internal catalog publication and explicit connection/retry states.

[aceforeverd]

already support writable catalog in #73 , what's the diff ?

Another thing, model catalog schema V1 is deprecated, any now feature should working on schema V2 only

[imneov]

Both fair. Taking them in order.

What's the diff vs #73. #73 edits a catalog that is already writable: the profile entry has to be a catalog-server (schema v2, writable: true) with a token in <profile>-secrets, and swissd proxies that server's api/v2 write calls. The installation in #64 serves a static index.json from a static host — there is no write endpoint, so the Model Library has no target there: #73's New model cannot appear and the reporter has nowhere to add their fine-tuned model. #86 aimed at exactly that case by keeping templates in Console and publishing its own catalog.

V1. Agreed, and it's worse than just legacy: a v1 catalog cannot be deployed through the LLMSvc backend (its plans must be schema v2), and the v1 legacy-response shims in #86 are the wrong thing to extend. If the Console-owned route stays, it has to publish catalog.swiss/v2 only — index-v2.json plus per-variant files pinned by path/digest — and drop the v1 compatibility layer.

The gap I missed. Console's chart still pins the swiss subchart at 0.6.3, which predates both #73's write API and schemaVersion/writable in the profile parser (it rejects those fields). 0.7.0 also vendors catalog-server in the swiss chart. So a static-catalog install can get a writable v2 catalog with no new Console code: bump the subchart, expose catalogServer, and document adding that catalog to the site profile — then #64 is covered by #73's New model for everyone.

So I'd close #86 and follow up with that much smaller chart change. Only if you want installs to get a catalog without running catalog-server would I rework #86 to v2-only. Which do you prefer?

[imneov]

Closing in favour of the writable-catalog route rather than keeping this as a second publishing stack.

swiss 0.7.0 vendors catalog-server in the swiss chart, so an installation whose own catalog is a static index can add a writable schema-v2 catalog and then use #73's New model in the Model Library. A Console-owned store publishing a v1 index duplicates that, and v1 is a dead end: deprecated, cannot be read by the swissd the chart should bundle, and cannot deploy through the LLMSvc backend.

Follow-up: #90 — bump Console's swiss subchart from 0.6.3 to 0.7.0 (the bundled 0.6.3 has neither catalog v2 nor schemaVersion/writable, so the existing Model Library features cannot work with a bundled install) and document enabling catalog-server + adding it to the site profile. That covers #64 through the existing path.

Thanks for the review — it saved a second catalog implementation.

[imneov]

Follow-up implementation: #91 (swiss 0.7.0 subchart, catalog-server documented, writable-catalog setup).