qbarev/para-plugin

Archiv

Der Bereich Archive/ des Vaults: Alles Abgeschlossene oder Aufgegebene kommt hierher, und Archivieren ist immer ein Verschieben – niemals ein Löschen. Dauerhaftes Löschen ist /remove. Ein Projekt und sein Backend-Pendant werden zusammen mit seinem Ordner archiviert und wiederhergestellt.

Basisschicht

Vor dem Handeln lesen, jeweils als ../../para/<datei>.md relativ zum Basisverzeichnis dieser Fähigkeit – diese enthalten die gemeinsamen Regeln, nicht aus dem Gedächtnis wiederholen:

• ../../para/paths.md – immer, einschließlich „Sprache“: die folgenden Zeichenfolgen stammen aus lang/<SPRACHE>.md
• ../../para/find-target.md – für die Unterbefehle, die ein Ziel benötigen
• ../../para/move.md – immer
• ../../para/confirm.md – immer
• ../../para/dod.md – wenn das Ziel ein Projekt ist
• ../../para/tasks.md – wenn das Ziel ein Projekt ist: die Operationen, Paarung, Bereichsprojekte
• ../../para/note-format.md – beim Bearbeiten des Frontmatters; „Legacy-Felder“

Unterbefehle

Das erste Wort von $ARGUMENTS bestimmt den Unterbefehl. list und restore sind die einzigen Schlüsselwörter – alles andere ist das Ziel einer Archivierung, also archiviert /archive projekt c dieses Projekt. Leeres $ARGUMENTS → die drei Unterbefehle anzeigen und nachfragen.

---

<ziel> – ins Archiv verschieben

1. Das Ziel finden gemäß find-target.md, Operation „Archivieren“.

2. Wenn das Ziel ein Projekt ist:

   • Zuerst offene Aufgaben prüfen. Die Aufgaben des zugehörigen Projekts lesen (task.list, offen, mit project_ref). Wenn Aufgaben offen sind, diese auflisten und einmal nachfragen (Tier 1.5), was damit geschehen soll: sie erledigen (task.complete für jede), in ein Bereichsprojekt verschieben (task.move mit area) oder im archivierten Projekt belassen. Wo der Adapter task.complete als „nicht unterstützt“ markiert, wird stattdessen die erste Option der archive.close_in_app-Zeichenfolge verwendet, und es wird nichts dafür aufgerufen. Die Antwort vor dem Fortfahren ausführen. Unter pairing: separate hat ein ungepaartes Projekt mit einem legacy-Tasks/-Ordner keine Backend-Seite; dod.md sagt, wie seine Aufgaben geprüft werden. Unter pairing: none sind die Aufgaben die eigenen Tasks/-Notizen des Projekts und werden mit dem Ordner verschoben.
   • dod.md anwenden und jede Bedingung nennen, die nicht erfüllt ist. Diese Datei entscheidet, ob das Ergebnis abgeschlossen oder aufgegeben ist; die Begründung hier nicht wiederholen und nicht abschwächen.
   • Den gesamten Ordner mit unveränderter interner Struktur von Projects/PROJ-xxxx <titel>/ nach Archive/PROJ-xxxx <titel>/ verschieben. Der Name bleibt exakt, wie er ist: Die ID bleibt lebenslang beim Projekt, und die ID-Vergabe durchsucht Archive/, um sie reserviert zu halten (project-id.md).
   • project.archive wenn gepaart (immer, unter pairing: none; dort ein No-op). tasks_ref: im Überblick behalten – die Wiederherstellung benötigt es.
   • Legacy-Felder (status und der Rest) werden exakt so belassen, wie sie sind (note-format.md): Ein archiviertes Projekt behält seine Geschichte.

3. Wenn das Ziel eine eigenständige Notiz ist (Bereich, Ressource oder eine verirrte aus Inbox/):
   die einzelne .md nach Archive/ verschieben.

   • Bereiche sind per Definition fortlaufend und werden normalerweise nicht archiviert. Nachfragen, was gemeint war (Tier 1.5) – meist bedeutet es, dass die Notiz veraltet ist, nicht dass die Verantwortung endete.
   • Eine legacy-Aufgabennotiz innerhalb eines Projekts, das nicht archiviert wird: Das Verschieben zerstört nichts Nützliches und ist wahrscheinlich nicht das, was gemeint war – nachfragen (Tier 1.5). Aufgaben werden jetzt im Backend geschlossen.

4. Den Basisnamen auf Kollisionen prüfen vor dem Verschieben (move.md, note-format.md). Ein Duplikat macht jeden Link zu diesem Namen mehrdeutig – Tier 1.5, nachfragen statt verschieben.

5. Den Kreis schließen – nur Projekte. Vor dem Berichten eine Frage stellen und auf die Antwort warten: die archive.ask_changed-Zeichenfolge. Nicht, was produziert wurde – Bedingung 2 von dod.md deckt das Artefakt bereits ab – sondern, was jetzt anders ist, da es vorbei ist, und ob es den Aufwand wert war.

   Vor dem Fragen den Abschnitt project.value vorlesen – den Nutzen, den der Benutzer zu Beginn des Projekts notiert hat (note-format.md, „Drei Abschnitte zum Ergebnis“) – und fragen, ob er sich mit der archive.expected-Zeichenfolge bewahrheitet hat ({value} = das, was sie notiert haben, z. B. „−5 Stunden Review pro Woche“). Wenn der Abschnitt leer oder nicht vorhanden ist, die Frage wie sie ist stellen, ohne eine Erwartung zu erfinden.

   Den Abschnitt project.what_changed am Ende des Überblickstextes schreiben. Seine erste Zeile ist das Ergebnis gemäß dod.md – die Zeichenfolge project.outcome.completed oder project.outcome.abandoned ({reason} in den Worten des Benutzers) – dann die Antwort des Benutzers in seinen eigenen Worten; nicht in eigene Worte zusammenfassen. Wenn die Antwort etwas nennt, das das Projekt überdauert, spricht Bedingung 4 von dod.md; es nach Areas/ oder Resources/ leiten, anstatt es im Archiv zu belassen.

   Wenn der Benutzer nicht antworten möchte, nur die Ergebniszeile schreiben und sagen, dass der Kreis übersprungen wurde. Niemals den Rest erfinden.

6. Berichten: was verschoben wurde, sein neuer Pfad, die Ergebniszeile, was mit offenen Aufgaben passiert ist, ob das Backend-Projekt archiviert wurde, etwaige Warnungen.

---

list – anzeigen, was im Archiv ist

Nur lesen. Niemals die Notizen über das hinaus öffnen, was unten genannt ist.

1. Archive/ auflisten – sowohl Projektordner als auch lose .md-Dateien.
2. Für jeden Projektordner das Frontmatter des Überblicks (id, deadline) und die erste Zeile des Abschnitts project.what_changed lesen, falls der Abschnitt existiert.
3. Zwei Abschnitte in SPRACHE ausgeben, jeder alphabetisch, mit einer Anzahl in der Kopfzeile (die Zeichenfolgen archive.list.projects und archive.list.notes). Das angezeigte Ergebnis ist die erste Zeile ohne ihren Punkt für ein abgeschlossenes Projekt, und nur das Wort vor dem Doppelpunkt für ein aufgegebenes (der Grund wird nicht wiederholt); der Termin ist die Zeichenfolge archive.list.deadline; hier mit den englischen Zeichenfolgen dargestellt:

**Archivierte Projekte (N)**
1. PROJ-0005 Projekt D — Abgeschlossen, Termin 2026-09-30
2. PROJ-0007 Projekt F — Abgebrochen
3. PROJ-0003 Projekt C — kein Ergebnis aufgezeichnet
4. Altes Projekt — keine Metadaten

**Archivierte Notizen (N)**
1. Eine Notiz

Das Ergebnis wird nur gelesen, wenn die erste nicht leere Zeile des Abschnitts project.what_changed exakt die Zeichenfolge project.outcome.completed ist oder mit der Zeichenfolge project.outcome.abandoned bis zu ihrem Doppelpunkt beginnt. Andernfalls – der Abschnitt fehlt, oder er beginnt mit den eigenen Worten des Benutzers, wie bei Projekten, die vor dieser Regel archiviert wurden – die Zeichenfolge archive.no_outcome ausgeben; niemals ein Ergebnis aus Freitext oder aus einem legacy-status ableiten. Die Zeichenfolge common.no_metadata – gar kein Frontmatter. Ein leeres Archiv ist eine gültige Antwort: es klar sagen.

---

restore <ziel> – etwas zurückholen

1. Das Ziel finden gemäß find-target.md, Operation „Aus Archiv wiederherstellen“.
2. Herausfinden, wohin es zurückgeht. Ein Projekt kehrt nach Projects/ zurück. Eine Notiz kehrt in den PARA-Ordner zurück, den ihr Frontmatter impliziert – area/<slug> → Areas/, resource/<slug> → Resources/. Wenn die Tags es nicht sagen oder die Notiz älter als die Konvention ist, fragen, wo sie hingehört. Nichts wird nach Inbox/ zurückverschoben – es ist kein Ziel (paths.md).
3. Den Basisnamen auf Kollisionen prüfen wie oben, dann verschieben.
4. Die Aufgabenseite – nur Projekte. project.restore mit dem ref. Unter pairing: separate ohne tasks_ref: anbieten, das Paar zu erstellen (tasks.md „Paarung“); bei Zustimmung project.create, einen tasks_ref:-Schlüssel hinzufügen und ausfüllen. Unter pairing: none gibt es kein anzubietendes Paar. Angehakte Kontrollkästchen im Abschnitt project.dod und den Abschnitt project.what_changed so belassen, wie sie sind – sie zu bearbeiten ist Tier 2 und selten gewünscht.
5. Berichten: was zurückkam, wohin und der Zustand seines Backend-Pendants.

Hinweise

• Hier niemals etwas löschen. Archivieren ist immer ein Verschieben nach Archive/; wenn der Benutzer etwas entfernt haben möchte, ist das /remove.
• Alle benutzerseitigen Texte und jeder Frontmatter-Wert in SPRACHE; feste Zeichenfolgen stammen aus lang/<SPRACHE>.md.