Changeset 0.9.1 (#51)

This commit is contained in:
2026-02-23 13:42:23 +00:00
parent 8264aa6016
commit febcbde3d7
21 changed files with 1881 additions and 423 deletions

View File

@@ -43,7 +43,7 @@ Three Docker images support different deployment scenarios:
4. **Scope Model**: Provider configs, personas, and model settings all use a three-value `scope` column: `global` (admin-managed, visible to all), `team` (team-admin-managed, visible to team), `personal` (user-managed, visible to owner). The `owner_id` column points to the owning user or team depending on scope.
5. **Capabilities Resolution**: Model capabilities (vision, tool calling, thinking, context window) are resolved through a priority chain: catalog DB → known model table → heuristic inference. This ensures every model has capabilities even if the provider API doesn't report them.
5. **Capabilities Resolution**: Model capabilities (vision, tool calling, thinking, context window) are resolved through a priority chain: catalog DB (provider API sync, per-provider authoritative) → heuristic inference (regex patterns on model ID). No static model table — the same model can have different capabilities on different providers. The catalog is populated by auto-fetch on provider creation and manual refresh.
## Package Structure
@@ -70,7 +70,7 @@ server/
│ └── ...
├── models/models.go # Shared domain types
├── capabilities/
│ ├── intrinsic.go # Known model table + heuristics
│ ├── intrinsic.go # Heuristic detection + resolution
│ └── resolver.go # ModelsForUser() unified resolver
├── handlers/ # HTTP handlers (Gin)
│ ├── auth.go # Login, register, refresh, logout
@@ -133,9 +133,7 @@ When the system needs to know what a model can do (vision? tools? thinking?):
↓ miss
2. model_catalog DB (any provider: same model_id)
↓ miss
3. Known model table (static, curated in capabilities/intrinsic.go)
↓ miss
4. Heuristic inference (name-based: "gpt-4-vision" → vision=true)
3. Heuristic inference (name-based: "gpt-4-vision" → vision=true)
```
The `capabilities.ModelsForUser()` function combines catalog entries, team personas, and user preferences into a single unified model list for the frontend.
@@ -158,8 +156,6 @@ Single consolidated migration (`001_v09_schema.sql`) replaces the previous 21 in
2. Checks which migration files have been applied
3. Applies any new `.sql` files in order
For v0.8 → v0.9 upgrades, a future `002_v08_to_v09.sql` migration will handle the transition. Fresh installs use `001_v09_schema.sql` directly.
## Frontend Architecture
Vanilla JavaScript, no build step. Five files with clear responsibilities: