/papierkorb — Der Papierkorb

Hinweis: Rahmen: 00-rahmen.md. Code: packages/plugins/src/settings/client/Papierkorbschirm.tsx und PapierkorbEinstellungen.tsx · Nachweis npm run verify:papierkorb.

Wofür

Ein Ort für alles Weggetane. Sechs Papierkörbe wären sechs Orte, sechs Fristen und sechs Gelegenheiten, eine zu vergessen — Grundsatz 50 schafft genau das ab. Personen, Ereignisse, Tagebucheinträge, Gedächtniseinträge, Aufgaben und Quellen liegen hier nebeneinander, jede Zeile mit ihrer Art und ihrer Restfrist.

Diese Seite ist kein zweiter Papierkorb, sondern ein zweiter Ort für denselben (Q06, 20.09.2026). Der sichtbare Platz bleibt, wo er war: Einstellungen → Deine Daten. Dazu kommt diese Adresse, damit ein Verweis auf ihn zeigen kann — „weggetan, im Papierkorb ansehen" — und damit die Schnellsuche ihn findet. In der Hauptleiste steht er nicht: Ein Papierkorb ist nichts, was man täglich aufsucht.

Weg und Rahmen

Was man sieht

Ein Satz oben nennt die Frist („Was du wegtust, liegt 30 Tage hier"), darunter je Zeile:

Ist nichts da, steht „Der Papierkorb ist leer." — ein eigener Satz und keine leere Fläche. Auf /papierkorb steht er seit dem 29.09.2026 im gemeinsamen Leerzustand mit Eule (RL02), vorher als graue Nebenzeile; im Abschnitt der Einstellungen bleibt er eine Zeile, weil der Papierkorb dort ein Abschnitt unter vielen ist.

Tinte (seit 01.10.2026, F110). Der Leerzustand auf /papierkorb steht in der Lesetinte des gemeinsamen Leerzustands (N318). Frist, Meldung und die Nachfrage beim Leeren sind Fließtext und halten 4,5 : 1: im Abschnitt der Einstellungen auf Karton in der Lesetinte (neutral.lese), samt „Der Papierkorb ist leer.“; auf der eigenen Seite stehen sie auf dem Himmel und dort in der vollen Tinte (neutral.text), weil die Lesetinte am Abend auf bewölktem Grau nur etwa 4,4 : 1 erreicht (Guide §17). Bis dahin trugen sie die Nebentinte, 3,1 bis 3,7 : 1.

Was man tun kann

Was ein Zugang nicht sehen darf, kann er hier auch nicht wegtun, zurückholen oder löschen. Ein heikler Gedächtniseintrag trägt seinen Inhalt als Benennung; ohne memories.sensitive erscheint er gar nicht erst (19.09.2026).

Was dem Quellkalender gehört, fasst der Papierkorb nicht an (seit 23.09.2026, N169, F54). Ein Termin aus einem abonnierten Kalender (life.events.feed_id) lässt sich nicht wegtun; der Endpunkt antwortet wie bei einer fremden Zeile („nichts zum Wegtun"). Liegt doch einer hier — eine Altlast aus der Zeit davor —, erscheint er nicht in der Liste, lässt sich weder zurückholen noch endgültig löschen, und weder das Leeren noch die Frist nehmen ihn; der nächste Abgleich holt ihn zurück. Loswerden lässt sich ein Abo-Termin nur im Quellkalender oder mit dem ganzen Abonnement; ein Ausblenden einzelner Termine gehört zu E5. Im Artenverzeichnis steht das als Angabe fremd an ereignis, nicht als Sonderfall im Quelltext (Grundsatz 50).

Was allen gehört, liegt im Papierkorb seines Bereichs (seit 04.10.2026, KI58, N507). Ein weggetaner Lesepfad des Wikis steht nicht hier, sondern im Papierkorb des Wikis (wiki.md): Er gehört keinem Konto, und zurückholen darf ihn jedes Konto, das im Wiki schreiben darf. Im Artenverzeichnis ist das die Angabe geteilt an lesepfad. Eine solche Art fehlt in dieser Liste, unter den Arten und beim Leeren. PAPIERKORB_ZURUECKHOLEN und PAPIERKORB_ENDGUELTIG nehmen sie an, aber statt des Eigentümers fragen sie den Bereich über den Anschluss papierkorb.<art>.zugang; fehlt er oder sagt er nein, antworten sie wie bei einer Zeile, die es nicht gibt. Die Frist nimmt sie wie jede andere Art: Nach dreißig Tagen ist der Pfad mit seinen Schritten und dem Lesestand aller Konten weg.

Woher die Daten kommen

Fünf Wege, alle aus packages/backend/src/routes/api/papierkorb.ts und alle durch die AES-Strecke (registerEncryptedRoute, ohneRecht: 'quer' — gefragt wird nach dem Recht der jeweiligen Art):

Die drei Handgriffe teilen einen Handler (handgriff): Er prüft mit istArt, ob die Art im Artenverzeichnis ARTEN steht, und fragt über kannFuer den Rechtebaum (funktionssperre). Die Arbeit tun tueWeg, holeZurueck, loescheEndgueltig und leerePapierkorb in database/access/papierkorb.ts, hinter withUserScope. Eine Art ist dort eine Zeile Daten mit Tabelle, Besitzerspalte und Benennungsspalte:

Die Frist (FRIST_TAGE, 30) räumt raeumeAb ab, aufgerufen vom Zeitgeber runPapierkorb.ts. Verschlüsselt ist der Weg; die Benennung liest die Abfrage im Klartext aus der Spalte der Art (benennung). Bei einer Seite zählt mitgegangen die Unterseiten, bei der Kalenderkategorie halten abhängige Zeilen das Löschen auf (festgehalten, etwa life.calendar_entries). Lesepfad und Wikiseite sind als geteilt vermerkt und fehlen deshalb in der Liste dieser Seite; sie liegen im Papierkorb des Wikis (wiki.md), den der Weg WIKI_PAPIERKORB bedient.

Was fehlt

1. Kein Leeren. — behoben am 21.09.2026 (B20). Unter der Liste steht „Alle 14 endgültig löschen", mit der Zahl darin und einer Rückfrage. Die Zahl zählt, was wirklich verschwindet: Eine Seite mit fünf Unterseiten ist eine Zeile und sechs Einträge. Was bleibt: Heikle Einträge, die dieser Zugang nicht sehen darf, bleiben liegen — richtig so, aber die gemeldete Zahl sagt nicht, dass etwas übrig ist.
2. Die Seiten haben ihren eigenen Papierkorb. — behoben am 21.09.2026 (B20). personal.documents ist die siebte Art im gemeinsamen Papierkorb, mit nachfahren als Angabe im Artenverzeichnis statt als Sonderfall im Quelltext. Was bleibt: Die alte Ansicht unter /documents?a=papierkorb steht weiter da und zeigt dieselben Zeilen — sie ist jetzt eine zweite Ansicht und kein zweiter Papierkorb, aber zwei Orte sind zwei Orte. Ob sie verschwindet, gehört zu D15.
3. Kein Ablauf. — der Zeitgeber steht (runPapierkorb.ts, raeumeAb), und verify:papierkorb prüft ihn in beide Richtungen. Was neu ist: Seit dem 21.09.2026 fallen auch die Seiten darunter — bis dahin blieb eine weggetane Seite unbegrenzt liegen. Wer eine Seite wegtut, hat jetzt dreißig Tage und nicht mehr ewig.
4. Keine Angabe, wann und von wem. Die Zeile nennt die Restfrist, nicht das Datum des Wegtuns und nicht, wer es war. Bei einem geteilten Bestand ist das der wichtigere Teil.
5. Kein Filter nach Art. Bei acht Arten und vielen Zeilen ist die Liste eine Liste; ein Reiter je Art wäre der Rahmen, den andere Schirme schon haben.
6. Keine Suche. Wer weiß, wie die weggetane Person hieß, kann danach nicht suchen.
7. Keine Seitenaufteilung. fetchPapierkorb holt alles auf einmal; eine Grenze steht im Endpunkt, ein Weiterblättern nicht.
8. Kein Weg zurück an den Ort. „Zurückholen" bringt die Zeile wieder, sagt aber nicht, wohin — ein Verweis auf das wiederhergestellte Ding fehlt.
9. Keine Mehrfachauswahl. Zwanzig Zeilen zurückzuholen sind vierzig Klicks.
10. Der Schirm hat keinen eigenen jsdom-Nachweis für die Seite. PapierkorbEinstellungen.test.tsx prüft das Bauteil; Papierkorbschirm.tsx ist der Rahmen darum und ungeprüft.
11. Die Zeile einer Seite sagt nicht, welche Unterseiten mitgingen. „mit 5 Unterseiten" ist eine Zahl; welche fünf es sind, sieht man erst nach dem Zurückholen. Ein Aufklappen wäre der nächste Schritt.
12. Leeren meldet eine Zahl und keinen Bericht. „14 Einträge endgültig gelöscht" sagt nicht, welche Arten darin waren — und schon gar nicht, ob etwas liegen blieb, weil dieser Zugang es nicht sehen darf.