Hintergrundaufträge

Ein Hintergrundauftrag übergibt eine Aufgabe an deinen Pia-Server und lässt sie dort laufen: Arbeit, die dein Pia-Server für dich ausführt – auf Basis der Einträge, die du auswählst. Die Antwort kommt als Chat zurück. Er übersteht das Schließen der App, ist an keine Chat-Runde gebunden, und die Aufgabe des Clients ist es, genau zu sagen, was das Gerät verlässt, das Ergebnis abzuholen und es zurück in die verschlüsselte Ebene zu bringen.

Die Serverseite davon ist die Task Plane von Pia Mesh: Ein Auftrag wird von einem Operator ausgeführt, der dabei eine Fähigkeit betreibt, und der Client spricht nie direkt einen Operator an — nur einen Fähigkeitsnamen, den der Server für diesen Nutzer freigegeben hat.

Das ist der einzige Weg, der die Ende-zu-Ende-Verschlüsselung verlässt

Alles andere, was der Desktop-Client synchronisiert, wird verschlüsselt, bevor es das Gerät verlässt, und der Server kann es nicht lesen. Bei einem Auftrag geht das nicht: Was auch immer die Arbeit ausführt, muss lesen können, woran es arbeitet. Deshalb werden die von dir gewählten Einträge und deine Eingabe im Klartext gesendet und auf deinem Pia-Server unverschlüsselt gespeichert, solange der Lauf dauert. Deshalb steht hinter dem Senden ein expliziter Zustimmungsbildschirm statt einer einfachen Schaltfläche. Was der Server dafür garantiert und was nicht, steht im Mesh-Vertrauensmodell.

Wo die Oberfläche erscheint

Beim Laden prüft der Client GET /api/assignments/skills. Alles außer einer gefüllten Liste — keine Server-URL konfiguriert, kein Zugriffstoken, 401/403/404 oder ein leeres Array — führt zu einer verborgenen Oberfläche. Die Einstiegspunkte sind dann nicht vorhanden, nicht nur deaktiviert: Ein Server, der keine Aufträge anbietet, erzeugt einen Client, der keine Spur von ihnen zeigt.

Einstiegspunkt	Angezeigt wenn
Aufträge in der Seitenleiste	die Oberfläche verfügbar ist und sich das Fenster im Assistent-Modus befindet
Die Raketen-Schaltfläche in der Aktionsleiste des Assistent-Eingabefelds — Als Hintergrundauftrag an deinen Pia-Server übergeben	die Oberfläche verfügbar ist

Das Ergebnis der Prüfung enthält die Fähigkeiten, die den Gruppen dieses Nutzers gewährt wurden, jeweils mit ihrem Chat-Modus und ihren declaredInputTypes. Beide Einstiegspunkte öffnen denselben Zustimmungsdialog; der aus dem Eingabefeld befüllt die Eingabe vorab mit dem, was dort bereits getippt wurde, und lässt den Text des Eingabefelds selbst unangetastet, denn ein Entwurf gehört zu dem Ziel, für das sich der Nutzer entscheidet.

Was du senden möchtest

Der Dialog trägt den Titel An deinen Pia-Server senden, und alles Folgende steht auf einem einzigen Bildschirm — die Bestätigung erfolgt dort, wo die Auflistung ist, nicht eine Seite später.

• Fähigkeit — ein Auswahlfeld nur, wenn mehr als eine Fähigkeit gewährt wurde; sonst die einzige, mit Modus:, der den von der Fähigkeit deklarierten Chat-Modus zeigt (Research, Assistant). Der Modus ist der des Servers, keine Wahl: Ein Aufrufer kann einen Auftrag nicht in einen anderen Modus lenken.
• Was soll erledigt werden? — die Eingabe, Platzhalter Beschreibe die Aufgabe in deinen eigenen Worten, begrenzt auf 4 000 Zeichen.
• Zu sendende Einträge — die Auswahlliste, die nur die Eintragstypen zeigt, die die gewählte Fähigkeit deklariert hat.

Drei Zustände ersetzen die Liste, statt eine leere zu zeigen:

Zustand	Was der Dialog anzeigt
Die Fähigkeit deklariert keine Eingabetypen	Diese Fähigkeit arbeitet allein mit deiner Eingabe. Es werden keine Einträge gesendet, deine Eingabe jedoch schon – im Klartext.
Die Fähigkeit deklariert Typen, und du hast keine Einträge davon	Du hast keine Einträge, die diese Fähigkeit verwenden kann. Du kannst deine Eingabe trotzdem allein senden – im Klartext.
Das lokale Lesen ist fehlgeschlagen	Deine Einträge konnten nicht gelesen werden; daher können keine aufgeführt oder gesendet werden.

Der letzte Punkt ist wichtig: „Du hast keine Einträge“ ist eine Aussage über deine Daten — ein fehlgeschlagenes Lesen sagt das also, statt die Frage zu beantworten.

Unter der Liste steht eine laufende Summe — {Ausgewählt} von 20 Einträgen · {Zeichen} von 32.000 Zeichen — und die primäre Aktion Unverschlüsselt senden ist nur aktiv, wenn eine Fähigkeit gewählt ist, die Eingabe nicht leer und innerhalb ihrer Grenze ist, die Auswahl innerhalb beider Obergrenzen liegt, das Laden der Einträge abgeschlossen ist, das Bestätigungskästchen Mir ist klar, dass diese Einträge die Ende-zu-Ende-Verschlüsselung verlassen. angehakt ist, und noch nichts gesendet wurde.

Es gibt kein „diese Wahl merken“

Die Zustimmung gilt bewusst pro Auftrag. Die Menge der Einträge ist jedes Mal anders, daher wäre eine gespeicherte pauschale Zustimmung genau die Aushöhlung der Datenminimierung, die dieses Gate verhindern soll. Ein Architekturtest stellt sicher, dass keine Einstellung eine Zustimmungsentscheidung dauerhaft speichert.

Was gesendet werden kann

Das Vokabular umfasst ausschließlich vom Nutzer selbst verfasste Inhalte. Anbieter, Einstellungen, Zertifikate, Plugins und Plugin-Einstellungen gehören nicht dazu, und keine Fähigkeit hat einen Grund, sie zu lesen.

Im Dialog	Umschlag-entityType	Lokale Quelle	Was als Text des Eintrags gesendet wird
Unterhaltung	assistantChat	Assistent-Chats	Jede Nachricht als role: content, älteste zuerst
Sitzung	session	Optimieren-Verlauf	Der Originaltext und das Ergebnis, beide Hälften
Gedächtniseintrag	memory	Speicher-Tresor des Gedächtnisses	Bezeichnung und Eintrag
Aufgabe	todo	Todos	Titel und Notizen
Vorlage	template	Eigene Vorlagen	Beschreibung und Prompt

Integrierte Vorlagen sind ausgeschlossen: Sie sind clientseitige Konstanten, die nie synchronisiert werden und nicht vom Nutzer selbst verfasst sind — er kann ihrem Senden also nicht zustimmen. Die Auswahlliste bietet bis zu 50 aktuelle Einträge jedes deklarierten Typs — der Umschlag nimmt ohnehin höchstens 20 — und ein Typ, den ein neuerer Server deklariert, den dieser Build aber nicht lesen kann, trägt nichts bei, statt den Dialog scheitern zu lassen.

Obergrenzen

Der Client lehnt anhand derselben Konstanten ab, die auch der Server durchsetzt, sodass eine übergroße Auswahl nie zu einem 400 wird, mit dem der Nutzer nichts anfangen kann.

Obergrenze	Wert
Einträge pro Auftrag	20
Zeichen in einem Eintrag	8 000
Zeichen über alle Einträge hinweg	32 000
Eingabe	4 000

Ein Eintrag über der Grenze wird als nicht sendbar aufgeführt — Über der Grenze von 8.000 Zeichen für einen einzelnen Eintrag und daher nicht sendbar. — und niemals gekürzt: Ein Nutzer, der das Senden eines Eintrags bestätigt und dann nur ein Fünftel davon sendet, wurde nicht nach der Frage gefragt, die er beantwortet hat. Ein Häkchen zu viel, oder eines, das die Gesamtsumme über 32 000 Zeichen treiben würde, wird mit einem genannten Grund abgelehnt, statt still gekürzt zu werden.

Metadaten vor der Zustimmung, Inhalt danach

Die Auswahlliste liest Titel, Zeichenanzahl und Zeitstempel — nie den Inhalt. Der Text eines Eintrags wird erst gelesen, nachdem der Zustimmungsdatensatz geschrieben und das Warten auf die Festplatte abgeschlossen ist. Eine Folge davon ist sichtbar: Eine aufgeführte Größe ist einen Moment alt — sind die ausgewählten Einträge zwischen Auflisten und Senden über die Gesamtgrenze gewachsen, wird das Senden lokal abgelehnt, statt übergroß hinauszugehen. Ein zwischenzeitlich gelöschter Eintrag wird verworfen, statt ersetzt zu werden.

Was der Zustimmungsbildschirm aussagt

Drei Aussagen, wortwörtlich, denn genau um sie geht es bei der Bestätigung:

Das verlässt die Ende-zu-Ende-Verschlüsselung. Die Einträge unten werden im Klartext an deinen Pia-Server gesendet und dort unverschlüsselt gespeichert, solange die Arbeit läuft.

Der Klartext wird spätestens 72 Stunden nach dem Ende des Laufs gelöscht, ganz gleich, ob dieses Gerät das Ergebnis je abholt. Länger erhalten bleiben die Metadaten des Laufs — Status, Anzahl der Schritte und Token-Verbrauch —, die keine deiner Inhalte enthalten.

Solange er dort liegt, kann ihn jeder lesen, der Zugriff auf deinen Pia-Server hat.

72 Stunden sind ein Server-Standardwert, und der Client nennt sie als feste Zahl

Der Aufbewahrungssatz nennt 72 Stunden, weil das der Standardwert von Operators:PlaintextRetentionHours ist. Ein selbst gehosteter Server, der diesen Wert ändert, macht den eigenen Zustimmungstext des Clients in die eine oder andere Richtung falsch, und der Client hat keine Möglichkeit, das zu erkennen. Betreiber, die den Wert ändern, sollten das außerhalb der App mitteilen. Siehe Aufbewahrung.

Nach Unverschlüsselt senden meldet eine Zeile, was passiert ist:

Ergebnis	Meldung
Gestartet	Der Auftrag wurde gestartet. Seine Antwort erscheint als Chat, sobald der Lauf fertig ist.
Keine Quittung, oder eine, die nicht zur Auswahl passt	Nichts gesendet: Diese Auswahl wurde nicht bestätigt.
Über einer Obergrenze	Nichts gesendet: Die Auswahl überschreitet eine Größengrenze.
Der Server hat abgelehnt, oder war nicht erreichbar	Nichts gesendet: Dein Pia-Server hat den Auftrag abgelehnt.
Der Dialog konnte nicht abgeschlossen werden	Nichts gesendet: Der Auftrag konnte nicht gestartet werden.

Die Auftragsliste

Hintergrundaufträge listet die Läufe dieses Nutzers auf: die eigene Serverseite (GET /api/assignments, 50 Zeilen), verknüpft mit dem lokalen Journal dieses Geräts. Der Server weiß, in welchem Zustand ein Lauf ist; nur dieses Gerät weiß, was gefragt wurde und welcher Chat die Antwort enthält.

Spalte	Hinweise
Fähigkeit	Der Anzeigename der Fähigkeit aus der Fähigkeiten-Prüfung, ersatzweise ihr technischer Name
Status	In Warteschlange, Läuft, Abgeschlossen, Fehlgeschlagen, Abgebrochen — das eigene Vokabular des Servers — dazu Unbekannt für einen Wert, den dieser Build nicht erkennt
Schritte	Schritte: {n}, angezeigt, sobald ein Lauf einen genommen hat. Der Fortschritt ist eine Schrittzahl, nie ein Prozentwert: Eine einschrittige Fähigkeit läuft ehrlich einfach nur, und ein aus einer Schrittzahl erfundener Bruchteil wird zur Lüge, sobald sich die Schrittanzahl einer Fähigkeit ändert
Verstrichene Zeit	unter einer Minute, {n} Min., {h} Std. {m} Min., gemessen von der Erstellung der Zeile bis zu ihrem Abschluss oder bis jetzt

Die Zeilen kommen vom Server, daher erscheint auch ein auf einem anderen Gerät gestarteter Lauf — ohne seine Eingabe und ohne einen Chat zum Öffnen, markiert mit Auf einem anderen Gerät gestartet – Auftragstext und Antwort liegen nicht auf diesem. Sein Artefakt ging in den Chat-Speicher jenes Geräts.

• Chat öffnen erscheint, sobald der Lauf auf diesem Gerät abgeholt wurde.
• Abbrechen erscheint, solange ein Lauf In Warteschlange oder Läuft ist. Es meldet Dein Pia-Server wurde gebeten, diesen Lauf zu stoppen., oder Dein Pia-Server hat diesen Lauf nicht gestoppt – möglicherweise war er bereits beendet., wenn der Server nichts abzubrechen hatte, oder Dieser Lauf konnte nicht abgebrochen werden. bei einem Fehler. Ein abgebrochener Lauf landet trotzdem in einem Endzustand, sein Ergebnis wird also weiterhin gespeichert und abgeholt — Abbrechen stoppt die Arbeit, gibt den Klartext aber nicht auf.
• Aktualisieren ist manuell, und die Ansicht fragt außerdem alle 10 Sekunden von selbst nach, solange sie angezeigt wird. Verlässt du die Ansicht, stoppt das Abfragen — eine Liste, die niemand ansieht, hält keine Abfrage am Leben.
• Ein fehlgeschlagenes Lesen leert die Liste nie. Es zeigt Dein Pia-Server war nicht erreichbar, diese Liste ist daher möglicherweise nicht aktuell. und lässt die Zeilen unangetastet, denn ein unbeantwortetes Lesen darf nicht als „nichts ist gelaufen“ dargestellt werden.
• Ganz ohne Läufe: Noch nichts gelaufen. Starte einen Auftrag – die Antwort erscheint hier und als Chat, sobald der Lauf fertig ist.

Wie die Antwort zurückkommt

Ein Hintergrunddurchlauf läuft ab dem App-Start und danach alle 20 Sekunden. Er liest zuerst eine zwischengespeicherte lokale Datei, sodass ein Durchlauf ohne offene Läufe nichts kostet und nie das Netzwerk anfasst — das ist keine Abfrage eines Servers, den der Nutzer vielleicht gar nicht hat. Der Durchlauf beim Start ist der eigentliche Sinn der Sache: Ein Schließen der App mitten im Lauf würde das Artefakt sonst stillschweigend verlieren, da der Server den Klartext verwirft, ob nun jemand zurückkommt, um ihn abzuholen, oder nicht.

Für jeden abgeschlossenen Lauf ist die Reihenfolge fest und keine Geschmacksfrage:

1. Den Auftrag lesen, einschließlich seines Artefakts.
2. Lokal schreiben als gewöhnlichen Assistent-Chat.
3. Erst dann POST /api/assignments/{id}/collect, was die Klartextkopie des Servers verwirft.

Collect ist unumkehrbar, daher steht es an letzter Stelle: Würde zuerst quittiert und dann das lokale Schreiben fehlschlagen, wäre das Ergebnis vernichtet, ohne dass noch etwas abzuholen wäre. Wirft das Schreiben einen Fehler, bleibt der ausstehende Eintrag erhalten, und der nächste Durchlauf versucht es erneut. Die Chat-ID wird bevor der Lauf startet festgelegt, sodass ein erneutes Abholen den eigenen Chat überschreibt, statt einen zweiten zu erzeugen.

Der Chat trägt die Eingabe als Nutzernachricht und das Artefakt als Assistentennachricht, betitelt nach der ersten Zeile der Eingabe (60 Zeichen). Ein Lauf, der ohne Artefakt endete — fehlgeschlagen oder abgebrochen — erzeugt trotzdem den Chat und nennt darin den Fehlercode oder Status des Laufs, sodass ein Ergebnis nie einfach fehlt.

Einen Chat zu schreiben ist die gesamte Neu-Verschlüsselung

Das Artefakt kehrt in die verschlüsselte Ebene zurück, indem es ein gewöhnlicher Assistent-Chat wird: Chat-Synchronisierung verschlüsselt und überträgt ihn wie jeden anderen, und der Server verweigert das Schreiben eines Klartext-Chats für ein Ende-zu-Ende-verschlüsseltes Konto. Das lässt auch ein zweites Gerät über die Chiffretext-Synchronisierung funktionieren, selbst nachdem die eigene Klartextkopie des Servers verschwunden ist.

Sobald ein Lauf gespeichert und quittiert ist, meldet der Client ihn einmal: eine dauerhafte Flow-Karte — Hintergrundauftrag, Fertig – zum Ansehen tippen oder Nicht abgeschlossen – zum Ansehen tippen — dazu eine In-App-Benachrichtigung, wenn das Assistent-Fenster im Vordergrund ist, oder eine Windows-Benachrichtigung, wenn nicht (Dein Auftrag ist fertig – die Antwort steht in einem Chat / Dein Auftrag wurde nicht abgeschlossen – im Chat steht, was zurückkam). Beide bieten Chat öffnen.

Antwortet der Server für einen Lauf nicht mehr — die Zeile wurde gelöscht, oder das Klartext-Zeitfenster ist verstrichen —, gibt der Client ihn 7 Tage nach seinem Start auf. Dabei geht nichts verloren: Nach dem Klartext-Zeitfenster sind sowohl Eingabe als auch Artefakt ohnehin weg, es gab also nie mehr etwas abzuholen.

Zeiten und Aufbewahrung

Was	Wo	Wert
Aktualisierung der Auftragsliste	Client, nur solange die Ansicht angezeigt wird	10 s
Abholdurchlauf	Client, ab dem Start; untätig, solange nichts aussteht	20 s
Aufgeben bei einem Lauf, für den der Server nicht mehr antwortet	Client	7 Tage nach Start
Der Server verwirft Eingabe, Artefakt und Fehlertext	Server, Operators:PlaintextRetentionHours	72 Std. nach Ende des Laufs (Standard)
Ein abgeholter Lauf bleibt im lokalen Journal	Client	30 Tage
Die Server-Zeile und ihre Ereignisse werden gelöscht	Server, Operators:RetentionDays	30 Tage (Standard)

Die Aufgabegrenze des Clients liegt bewusst hinter dem Klartext-Zeitfenster des Servers, sodass ein über ein langes Wochenende geschlossenes Laptop sein Ergebnis trotzdem noch abholt — und deutlich vor der eigenen Aufbewahrungsfrist der Zeile, zu der es ohnehin nichts mehr abzuholen gibt.

Was dieses Gerät auf der Festplatte speichert

Datei	Enthält
%LOCALAPPDATA%\Pia\ConsentAudit\assignments.jsonl	Eine anhängende JSON-Zeile pro Bestätigung: Datensatz-ID, Zeitstempel, Fähigkeit, Modus, Anzahl der Einträge, Gesamtzeichenzahl, sowie pro Eintrag dessen Entitätstyp, ID und Zeichenzahl. Nur Metadaten — keine Titel, keine Inhalte
%APPDATA%\Pia\pending-assignments.json	Ein Eintrag pro hier gestartetem Lauf: Auftrags-ID, Chat-ID, Fähigkeit, Eingabe, Startzeit, und sobald vorhanden die Abholzeit

Die ausstehende Datei bleibt nach dem Abholen erhalten, statt gelöscht zu werden, denn sie ist das Einzige, das noch sagen kann, welcher Chat die Antwort eines bestimmten Laufs enthält: Die Eingabe reist innerhalb der Eingabedaten, die der Server verwirft, und die Listenansicht hat sie nie mitgeführt.

Einschränkungen

• Nichts Kopfloses kann einen Lauf starten. Der Sendepfad verlangt eine Zustimmungsquittung als Pflichtargument, und nur der Zustimmungsspeicher — der den Datensatz schreibt und auf die Festplatte wartet — kann eine solche ausstellen. Eine Quittung ist sitzungsgebunden: Eine, die den Prozess überlebt hat, in dem sie ausgestellt wurde, beweist nichts. Die Sperre ist außerdem eine Abhängigkeitsrichtung und keine Laufzeitprüfung: Ein Test stellt sicher, dass kein Hintergrund-Einstiegspunkt den Orchestrator überhaupt referenziert.
• Eine Zustimmungsentscheidung wird nie gespeichert, und eine Quittung autorisiert genau die Auswahl, für die sie ausgestellt wurde: Fähigkeit und Eintragsmenge werden erneut geprüft, bevor irgendetwas gelesen wird.
• Ein auf einem anderen Gerät gestarteter Lauf kann hier nicht abgeholt werden. Sein Artefakt ging in den Chat-Speicher jenes Geräts, und seine Eingabe war nie auf diesem hier.
• Ein abgeschlossener Auftrag kann aus der Liste heraus nicht erneut gestartet oder bearbeitet werden. Ein neuer Lauf ist eine neue Zustimmungsentscheidung.
• Nach dem Collect existiert das Artefakt nur noch im lokalen Chat. Die Kopie des Servers ist weg, und plaintextDroppedAt in der Zeile hält fest, dass sie gegangen ist.