Archivo

El área Archive/ del vault: todo lo terminado o archivado va aquí, y archivar es siempre un movimiento — nunca una eliminación. La eliminación permanente es /remove. Un proyecto y su par de backend se archivan y restauran juntos con su carpeta.

Capa base

Leer antes de actuar, cada uno como ../../para/<archivo>.md relativo al directorio base de esta habilidad — estos contienen las reglas compartidas, no las repitas de memoria:

../../para/paths.md — siempre, incluyendo «Idioma»: las cadenas a continuación provienen de lang/<IDIOMA>.md
../../para/find-target.md — para los subcomandos que toman un objetivo
../../para/move.md — siempre
../../para/confirm.md — siempre
../../para/dod.md — cuando el objetivo es un proyecto
../../para/tasks.md — cuando el objetivo es un proyecto: las operaciones, emparejamiento, proyectos de área
../../para/note-format.md — al editar frontmatter; «Campos heredados»

Subcomandos

La primera palabra de $ARGUMENTS elige el subcomando. list y restore son las únicas palabras clave — cualquier otra cosa es el objetivo de un archivo, entonces /archive proyecto c archiva eso proyecto. $ARGUMENTS vacío → mostrar los tres subcomandos y preguntar.

`<objetivo>` — poner en el archivo

Encontrar el objetivo según find-target.md, operación "Archivar".
Si el objetivo es un proyecto:
- Abrir tareas primero. Leer las tareas del proyecto emparejado (task.list, abiertas, con project_ref). Si hay tareas abiertas, enumerarlas y preguntar una vez (Nivel 1.5) qué ocurre con ellas: completarlas (task.complete en cada una), moverlas a un proyecto de área (task.move con area) o dejarlas dentro del proyecto archivado. Donde el adaptador marca task.complete como «no soportado», la primera opción es la cadena archive.close_in_app en su lugar, y no se llama a nada para ello. Llevar la respuesta antes de continuar. Con pairing: separate, un proyecto no emparejado con una carpeta Tasks/ heredada no tiene lado backend; dod.md dice cómo se revisan sus tareas. Con pairing: none las tareas son las notas Tasks/ propias del proyecto y se mueven con la carpeta.
- Aplicar dod.md y nombrar cada condición que no se cumpla. Ese archivo decide si el resultado es completado o abandonado; no reproducir su razonamiento aquí, y no suavizarlo.
- Mover la carpeta completa, estructura interna intacta, de Projects/PROJ-xxxx <título>/ a Archive/PROJ-xxxx <título>/. El nombre se mantiene exactamente como está: el id acompaña al proyecto de por vida, y la emisión de ids escanea Archive/ para mantenerlo reservado (project-id.md).
- project.archive cuando esté emparejado (siempre, bajo pairing: none; no operación allí). Mantener tasks_ref: en la visión general — restaurar lo necesita.
- Los campos heredados (status y el resto) se dejan exactamente como están (note-format.md): un proyecto archivado conserva su historial.
Si el objetivo es una nota independiente (Área, Recurso, o una suelta de Inbox/): mover el único .md a Archive/.
- Las áreas son continuas por definición y normalmente no se archivan. Preguntar qué se quería decir (Nivel 1.5) — normalmente significa que la nota está desactualizada, no que la responsabilidad terminó.
- Una nota de tarea heredada dentro de un proyecto que no se está archivando: moverla no rompe nada útil y probablemente no es lo que se quería — preguntar (Nivel 1.5). Las tareas se cierran en el backend ahora.
Comprobar colisiones de nombre base antes de mover (move.md, note-format.md). Un duplicado hace que cada enlace a ese nombre sea ambiguo — Nivel 1.5, preguntar en lugar de mover.
Cerrar el ciclo — solo proyectos. Antes de informar, hacer una pregunta y esperar la respuesta: la cadena archive.ask_changed. No lo que se produjo — la condición 2 de dod.md ya cubre el artefacto — sino qué es diferente ahora que ha terminado, y si valió lo que costó.

Antes de preguntar, leer la sección project.value en voz alta — el beneficio que el usuario escribió cuando el proyecto comenzó (note-format.md, "Tres secciones sobre el resultado") — y preguntar si se cumplió con la cadena archive.expected ({value} = lo que escribieron, ej. «−5 horas de revisión a la semana»). Si la sección está vacía o ausente, hacer la pregunta tal como está, sin inventar una expectativa.

Escribir la sección project.what_changed al final del cuerpo de la visión general. Su primera línea es el resultado según dod.md — la cadena project.outcome.completed o project.outcome.abandoned ({reason} en las palabras del usuario) — luego la respuesta del usuario en sus propias palabras; no la resumas con las tuyas. Si la respuesta nombra algo que sobrevive al proyecto, eso es la condición 4 de dod.md hablando; dirigirlo a Areas/ o Resources/ en lugar de dejarlo en el archivo.

Si el usuario no quiere responder, escribir solo la línea de resultado y decir que el ciclo fue omitido. Nunca inventar el resto.
Informar: qué se movió, su nueva ruta, la línea de resultado, qué pasó con las tareas abiertas, si el proyecto backend fue archivado, alguna advertencia.

`list` — mostrar lo que hay en el archivo

Solo lectura. Nunca abrir las notas más allá de lo que se nombra a continuación.

Listar Archive/ — tanto carpetas de proyecto como archivos .md sueltos.
Para cada carpeta de proyecto, leer el frontmatter de la visión general (id, deadline) y la primera línea de la sección project.what_changed, si la sección existe.
Imprimir dos secciones en IDIOMA, cada una alfabética, con un conteo en el encabezado (las cadenas archive.list.projects y archive.list.notes). El resultado mostrado es la primera línea sin su punto para un proyecto completado, y solo la palabra antes de los dos puntos para uno abandonado (la razón no se repite); la fecha límite es la cadena archive.list.deadline; mostrado aquí con las cadenas en inglés:

**Proyectos archivados (N)**
1. PROJ-0005 Proyecto D — Completado, fecha límite 2026-09-30
2. PROJ-0007 Proyecto F — Abandonado
3. PROJ-0003 Proyecto C — sin resultado registrado
4. Proyecto antiguo — sin metadatos

**Notas archivadas (N)**
1. Alguna nota

El resultado se lee solo cuando la primera línea no vacía de la sección project.what_changed es exactamente la cadena project.outcome.completed o comienza con la cadena project.outcome.abandoned hasta sus dos puntos. De lo contrario — la sección falta, o comienza con las propias palabras del usuario, como en proyectos archivados antes de esta regla — imprimir la cadena archive.no_outcome; nunca inferir un resultado de texto libre o de un status heredado. La cadena common.no_metadata — sin frontmatter en absoluto. Un archivo vacío es una respuesta válida: decirlo claramente.

`restore <objetivo>` — traer algo de vuelta

Encontrar el objetivo según find-target.md, operación "Restaurar desde archivo".
Determinar a dónde vuelve. Un proyecto regresa a Projects/. Una nota regresa a la carpeta PARA que su frontmatter implique — area/<slug> → Areas/, resource/<slug> → Resources/. Si las etiquetas no lo dicen, o la nota es anterior a la convención, preguntar dónde pertenece. Nada se restaura a Inbox/ — no es un destino (paths.md).
Comprobar colisiones de nombre base como arriba, luego mover.
El lado de tareas — solo proyectos. project.restore con el ref. Bajo pairing: separate sin tasks_ref:, ofrecer crear el par (tasks.md «Emparejamiento»); si acepta, project.create, agregar una clave tasks_ref: y llenarla. Bajo pairing: none no hay par que ofrecer. Dejar las casillas marcadas en la sección project.dod y la sección project.what_changed como están — editarlas es Nivel 2 y raramente se desea.
Informar: qué volvió, a dónde, y el estado de su par backend.

Notas

Nunca eliminar nada aquí. Archivar es siempre un movimiento a Archive/; si el usuario quiere que algo desaparezca, eso es /remove.
Todo el texto dirigido al usuario y cada valor de frontmatter en IDIOMA; las cadenas fijas provienen de lang/<IDIOMA>.md.

qbarev/para-plugin

¿Qué es para-plugin?

Preguntar en tu IA favorita

Documentación