schalli
56c07c3581
Ein neuer Widget-Typ war an sieben Stellen einzutragen; vergass man eine, fehlte die Kachel im Katalog oder die API lehnte sie mit 400 ab. - WIDGET_TYPES/WidgetType/WIDGET_MODULE_SLUGS stehen jetzt einmal in packages/shared; Registry, Katalog und die @IsIn-Whitelist der API leiten davon ab - neun wireXWidget()-Funktionen durch ein generisches registerWidget() ersetzt (idempotent, unbekannter Typ wirft in der Entwicklung) - der Katalog fuehrt keine zweite Typliste mehr, sondern leitet sie aus der Registry ab und filtert nach Modulzugriff (fail-closed, wenn die Modulliste unbekannt ist); der Abruf von /modules/active liegt auf der Dashboard-Seite, nicht im Dialog - widget-module-map.ts liest die geteilte Tabelle statt einer Kopie, die oeffentliche Funktion bleibt unveraendert Der Katalogfilter ist Komfort (T-M1H-01) — verbindlich bleibt der serverseitige Filter in DashboardService.getWidgets. Abweichung vom Plan: apps/web hing entgegen der Planannahme noch nicht von @tessera/shared ab; die Abhaengigkeit wurde ergaenzt (Lockfile). Die Dockerfiles kopieren packages/shared bereits, der Produktionsbau von Next.js und der nest build laufen unveraendert. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
122 lines
3.8 KiB
TypeScript
122 lines
3.8 KiB
TypeScript
export const APP_NAME = "Tessera";
|
|
|
|
export interface HealthResponse {
|
|
status: string;
|
|
timestamp: string;
|
|
}
|
|
|
|
/**
|
|
* Antwort von `GET /health/version` (quick-260914-ku1).
|
|
* `channel` ist in der Praxis `beta` | `live` | `dev`; die Wahrheit der
|
|
* Version ist der Git-Tag (`git describe`), nicht eine package.json.
|
|
*/
|
|
export interface VersionResponse {
|
|
name: string;
|
|
version: string;
|
|
channel: string;
|
|
commit: string;
|
|
buildTime: string;
|
|
}
|
|
|
|
/**
|
|
* Desktop-Pakete (Phase 18, D-08): Quelle ist ausschliesslich `manifest.json`,
|
|
* geschrieben nur von `.gitea/scripts/desktop-collect.sh` im CI. `platform` ist
|
|
* ein geschlossener Wertevorrat -- eine dritte Plattform waere eine bewusste
|
|
* Erweiterung hier und an der Konstante `PLATFORMS` im API-Dienst.
|
|
*/
|
|
export type DesktopPlatform = 'windows' | 'linux';
|
|
|
|
export interface DesktopManifestFile {
|
|
name: string;
|
|
size: number;
|
|
sha256: string;
|
|
/**
|
|
* Base64-Inhalt der `.sig`-Datei des Tauri-Bundlers (minisign), geschrieben
|
|
* von desktop-collect.sh, gelesen nur von `GET /desktop/update`. Fehlt bei
|
|
* Bauten mit `--no-sign` -- dann gibt es kein Update in der App.
|
|
*/
|
|
signature?: string;
|
|
}
|
|
|
|
export interface DesktopManifest {
|
|
version: string;
|
|
channel: string;
|
|
commit: string;
|
|
buildTime: string;
|
|
/**
|
|
* SemVer-Form, die der Updater im Client vergleicht: `X.Y.Z` bei live,
|
|
* `X.Y.Z-beta.g<sha7>` bei beta (Praefix `g` Pflicht -- ein rein numerischer
|
|
* SHA mit fuehrender Null waere kein gueltiger SemVer-Identifier).
|
|
*/
|
|
updateVersion?: string;
|
|
files: Partial<Record<DesktopPlatform, DesktopManifestFile>>;
|
|
}
|
|
|
|
/**
|
|
* Antwort von `GET /desktop/update` -- das dynamische Antwortformat von
|
|
* `tauri-plugin-updater`. Die Feldnamen sind vom Plugin vorgegeben, darum
|
|
* snake_case `pub_date`. `url` muss absolut sein, `signature` ist Pflicht.
|
|
*/
|
|
export interface DesktopUpdateResponse {
|
|
version: string;
|
|
pub_date?: string;
|
|
url: string;
|
|
signature: string;
|
|
notes?: string;
|
|
}
|
|
|
|
export interface DesktopLatestFile extends DesktopManifestFile {
|
|
url: string;
|
|
}
|
|
|
|
export interface DesktopLatestResponse {
|
|
version: string;
|
|
channel: string;
|
|
commit: string;
|
|
buildTime: string;
|
|
files: Partial<Record<DesktopPlatform, DesktopLatestFile>>;
|
|
}
|
|
|
|
/**
|
|
* Dashboard-Kacheln: EINE Typliste fuer Web und API (quick-260922-m1h).
|
|
*
|
|
* Vorher stand dieselbe Liste an sieben Stellen (Union-Typ, Constraints,
|
|
* Registry, Katalog-Liste, `@IsIn`-Whitelist ...). Vergass man eine, fehlte
|
|
* die Kachel im Katalog oder die API lehnte sie mit 400 ab. Seit m1h leiten
|
|
* beide Seiten von hier ab: `apps/web/src/components/dashboard/
|
|
* widget-registry.tsx` (Registry + Katalog) und
|
|
* `apps/api/src/dashboard/dto/create-widget.dto.ts` (`@IsIn`).
|
|
*
|
|
* ACHTUNG: Dies ist der erste LAUFZEIT-Import aus `@tessera/shared` (alle
|
|
* uebrigen sind `import type`). `packages/shared` liefert rohes TypeScript
|
|
* (`main: src/index.ts`, kein Bauschritt); die API laedt es im Betrieb ueber
|
|
* das native Type-Stripping von Node 24. Deshalb darf diese Datei nur
|
|
* loeschbare Syntax enthalten — keine `enum`, kein `namespace`, keine
|
|
* Parameter-Eigenschaften.
|
|
*/
|
|
export const WIDGET_TYPES = [
|
|
'clock',
|
|
'search',
|
|
'calendar',
|
|
'note',
|
|
'calculator',
|
|
'favorites',
|
|
'stopwatch',
|
|
'picture-frame',
|
|
'xframe',
|
|
] as const;
|
|
|
|
export type WidgetType = (typeof WIDGET_TYPES)[number];
|
|
|
|
/**
|
|
* Kachel → Modul-Slug. Eine Kachel ohne Eintrag ist immer sichtbar; eine
|
|
* Kachel MIT Eintrag erscheint nur fuer Benutzer, die das Modul nutzen
|
|
* duerfen — im Katalog (Komfort, `visibleWidgetTypes`) und verbindlich
|
|
* serverseitig in `DashboardService.getWidgets` (fail-closed).
|
|
*
|
|
* Heute bewusst leer: alle neun Kacheln sind Plattform-Kacheln ohne
|
|
* Modulbezug. Die erste modulgebundene Kachel (Proxmox) traegt hier ihren
|
|
* Slug ein.
|
|
*/
|
|
export const WIDGET_MODULE_SLUGS: Partial<Record<WidgetType, string>> = {};
|