Init

Transforme le dossier dans lequel la session a été démarrée en un vault PARA relié à ce plugin, et le maintient ainsi : une seconde exécution ajoute ce qui manque et migre un schéma plus ancien. C'est la seule compétence qui écrit la configuration du vault, et la seule qui s'exécute sans elle.

Ce qu'elle écrit

Tout ce qui suit et rien d'autre. REPO_ROOT, PARA_DIR, PARA_ROOT tels que définis par paths.md.

Quoi	Où	Comment
les dossiers PARA	`PARA_ROOT/` + `Projects`, `Areas`, `Resources`, `Archive`, `Inbox`, `Templates`	créés s'ils manquent
les modèles de notes	`PARA_ROOT/Templates/`	initialisés depuis le plugin, seulement s'ils manquent (« Templates »)
le journal des identifiants	`PARA_ROOT/Archive/.removed-ids`	seulement son en-tête, s'il manque (`project-id.md` « Le journal »)
configuration du vault	`REPO_ROOT/.claude/para/vault.md`, `areas.md` ; `adapter.md` seulement si `TASKS` est `mcp`	depuis `config.example/` ; jamais écrasé
le bloc du plugin	`REPO_ROOT/CLAUDE.md`	entre les marqueurs uniquement (« CLAUDE.md »)
les permissions des compétences	`REPO_ROOT/.claude/settings.json`	fusionné, jamais remplacé (« Settings »)
paramètres Obsidian	`REPO_ROOT/.obsidian/app.json`, `templates.json`	fusionné (« Obsidian »)
notes et dossiers de l'utilisateur (B seulement)	de leur emplacement actuel vers les dossiers PARA	déplacés, jamais modifiés — uniquement les déplacements listés dans le plan approuvé (« Scénario B »)
aperçus de projet (B seulement)	`PARA_ROOT/Projects/PROJ-xxxx <titre>/`	nouveaux, pour un dossier que l'utilisateur a appelé projet (« Scénario B »)
la clé d'appariement dans les aperçus (C seulement)	`PARA_ROOT/Projects/`, `PARA_ROOT/Archive/`	le seul champ de frontmatter renommé, rien d'autre (`scenario-c.md`)
le fichier de planification du vault (C seulement)	`REPO_ROOT/.claude/local/planning.md`	nouveau, issu de l'ancien outillage (`scenario-c.md`)
l'ancien outillage intégré (C seulement)	`REPO_ROOT/.claude/`, `CLAUDE.md`, les docs des anciens modèles	vers la Corbeille macOS, Niveau 2 (`scenario-c.md`)

Couche de base

À lire avant d'agir, chaque fichier en tant que ../../para/<fichier>.md relatif au répertoire de base de cette compétence (et ../../config.example/, ../../lang/, ../../templates/ de la même manière) :

../../para/paths.md — toujours : les deux racines, « Langue », l'adaptateur pour TASKS. Tout ce qu'écrit init doit être en accord avec lui.
../../para/tasks.md — les opérations, « Appairage », « Backend manquant »
../../para/adapters/mcp-generic.md — quand TASKS est mcp ; l'adaptateur pour toute autre valeur est nommé par paths.md
../../para/note-format.md — le schéma de frontmatter que les modèles doivent respecter
../../para/migrations.md — le SCHEMA actuel du plugin et comment une migration s'exécute
../../para/claude-md-block.md — le bloc pour CLAUDE.md
../../para/confirm.md — les niveaux ; le plan ci-dessous montre comment init les respecte
../../para/project-id.md — « Le journal » : l'en-tête du journal des identifiants (Étape 5.1)
../../config.example/vault.md, areas.md, adapter.md — la forme de la configuration
scénario B uniquement : ../../para/move.md (comment un déplacement conserve les liens), project-id.md (émission d'un identifiant), ../../para/thresholds.md (le seuil de vétusté des zones et « La limite de mtime »), paths.md « IGNORE »
../../lang/<LANG>.md une fois LANG connue : les chaînes init.*
scénario C uniquement, et les résidus de C lors d'une nouvelle exécution : scenario-c.md dans le répertoire de base de cette compétence — tout ce qui concerne l'ancienne disposition ; également ../../para/move.md (la Corbeille)

SKILL_DIR ci-dessous est le répertoire de base de cette compétence, tel qu'annoncé par le harnais.

Règles pour toute l'exécution

REPO_ROOT est le répertoire de travail de la session, en chemin absolu (pwd). C'est le seul endroit où le plugin prend une racine du répertoire de travail : init est ce qui l'écrit pour toutes les autres compétences. Le plan indique de quel dossier il s'agit, donc une session démarrée au mauvais endroit est détectée avant que quoi que ce soit soit écrit.
Rien n'est écrit avant le « oui » du plan. L'inspection, les questions et les sondages du backend de tâches sont en lecture seule.
vault.md est écrit en dernier. C'est ce qui marque un vault comme configuré ; une exécution interrompue ne laisse pas de vault.md et la prochaine exécution reprend depuis le début, trouvant le travail déjà fait.
Chaque étape est idempotente : créer si manquant, fusionner si présent, jamais écraser. Exécuter init deux fois de suite ne change rien la deuxième fois.
Mettez entre guillemets chaque chemin (paths.md « Règles »). REPO_ROOT peut contenir des espaces.
Langue. Jusqu'à ce que LANG soit choisie, parlez la langue dans laquelle l'utilisateur a écrit (anglais quand il n'y a rien pour se guider — un simple /para:init). À partir de là, tout est en LANG selon paths.md « Langue », y compris les questions restantes ; les en-têtes du plan et du rapport sont les chaînes init.*.

Réponses fournies à l'avance

$ARGUMENTS peut déjà contenir des réponses : la langue, PARA_DIR (« le défaut » signifie celui proposé), le backend de tâches, le modèle de Zones, dans le scénario B les réponses de tri (par dossier ou note racine, et pour les noms en double), la réponse pour l'instantané, et une approbation du plan. Prenez chaque réponse donnée et ne la redemandez pas ; demandez uniquement ce qui manque. Une réponse qui n'est pas un choix valide est redemandée, en expliquant pourquoi.

Une approbation donnée à l'avance signifie : affichez le plan, puis appliquez-le sans attendre — mais uniquement tant que chaque ligne du plan ajoute quelque chose (un dossier, un fichier, une clé, une entrée). Une ligne qui modifie ou remplace quelque chose qui existe déjà (une valeur Obsidian différente, un bloc CLAUDE.md différent, un modèle dans une migration, REPO_ROOT dans un vault.md existant) est de Niveau 2 (confirm.md) : le plan est affiché et init attend un « oui » même dans ce cas.

Les déplacements du scénario B sont de deux sortes, et ceci est l'unique déclaration de la manière dont une approbation avancée les couvre. Un déplacement que l'utilisateur a décidé dans ses propres réponses (B3, ou les réponses de tri dans $ARGUMENTS) change l'emplacement d'une note, jamais son contenu, et confirm.md place le déplacement dans le Niveau 1 : le « oui » du plan, donné alors ou à l'avance, le couvre. Un déplacement décidé par les seules règles (B2 : vers Archive/ ou Resources/) est le propre jugement de init sur les notes de l'utilisateur : il nécessite un « oui » en direct au plan qui l'affiche, même si une approbation avait été donnée à l'avance. Dans les deux cas, l'instantané est proposé avant les déplacements (Étape 4). Une question de tri répondue à l'avance n'est pas posée ; une question laissée sans réponse est posée, et rien n'est appliqué avant sa réponse, approbation ou non.

Étape 1 — Inspection

Lecture seule. Découvrez ce qu'est le dossier et nommez le scénario.

REPO_ROOT=$(pwd)
ls -A "$REPO_ROOT"
ls "$REPO_ROOT/.claude" "$REPO_ROOT/.claude/para" "$REPO_ROOT/.claude/skills" 2>/dev/null
# l'ancienne disposition intégrée (scénario C) : son dossier de config ou sa couche de base
ls -d "$REPO_ROOT/.claude/para/local" "$REPO_ROOT/.claude/para/paths.md" 2>/dev/null   # ancienne disposition
# dossiers de compétences nommés comme les anciennes compétences intégrées : signalés, jamais C seuls
for s in inbox projects areas resources archive remove vault-lint; do
  [ -f "$REPO_ROOT/.claude/skills/$s/SKILL.md" ] && echo "ancienne compétence : $s"; done
# notes : tout .md qui n'est pas sous une entrée en point de REPO_ROOT, sauf les fichiers propres au dépôt
# et les modèles (les entrées en point sont élaguées relativement à REPO_ROOT, donc un vault qui vit
# lui-même sous un répertoire en point est quand même vu)
find "$REPO_ROOT" -mindepth 1 -name '.*' -prune -o -name "*.md" -not -path "*/Templates/*" \
  ! -path "$REPO_ROOT/CLAUDE.md" ! -path "$REPO_ROOT/README.md" ! -path "$REPO_ROOT/CHANGELOG.md" -print | head -50
# un vault au-dessus de ce dossier : init a été démarré dans un sous-dossier
d=$(dirname "$REPO_ROOT")
while [ "$d" != "/" ] && [ "$d" != "$HOME" ]; do
  { [ -e "$d/.claude/para/vault.md" ] || [ -d "$d/.obsidian" ]; } && echo "vault au-dessus : $d"
  d=$(dirname "$d")
done

Arrêtez-vous avant toute autre chose quand :

REPO_ROOT est $HOME ou / — pas un vault ; dites-le.
un vault a été trouvé au-dessus — dites « exécutez /para:init depuis <ce dossier> » et arrêtez-vous ; ne configurez jamais un vault à l'intérieur d'un autre.

Ensuite, décidez, dans cet ordre, et dites ce qui a été trouvé et de quel cas il s'agit :

Configuration — .claude/para/vault.md existe → « Nouvelle exécution et migration » ci-dessous.
Scénario C — l'ancien outillage intégré, reconnu par son ancienne couche de base ou sa config uniquement (la ligne ancienne disposition ci-dessus) : son dossier de config local/ ou son fichier de couche de base paths.md dans .claude/para/. → « Scénario C ». Un dossier de compétence nommé comme l'une des anciennes compétences (les lignes ancienne compétence :) sans aucun des deux n'est pas C : passez à B ou A selon les règles ci-dessous. Dites quel dossier a été trouvé et que init le laisse tranquille ; le plan « pas fait » le nomme à nouveau. Un .claude/para/ contenant uniquement les fichiers de configuration de ce plugin (areas.md, adapter.md) et aucun vault.md n'est pas C : c'est une première exécution de init qui a été interrompue ou refusée avant vault.md. Passez à B ou A ci-dessous comme s'il n'était pas là, sauf que ces fichiers sont la configuration du vault — jamais écrasés — et une question à laquelle ils répondent déjà (question 4 pour areas.md) n'est pas reposée. L'exécution complète le reste.
Scénario B — des notes ont été trouvées (le find ci-dessus a affiché quelque chose). → « Scénario B ».
Scénario A — sinon : un dossier vide, ou un dossier contenant uniquement des fichiers non-notes (un .obsidian/ d'un nouveau vault Obsidian, un CLAUDE.md). → Étape 2.

Étape 2 — Questions

Une par une, dans cet ordre, en sautant toutes celles auxquelles il a été répondu à l'avance. Chaque question affiche ses choix et, s'il y en a un, la valeur par défaut.

Langue (LANG). Les choix sont les langues que le plugin fournit : un code avec à la fois lang/<code>.md et templates/<code>/ (paths.md « Langue ») :
```
for f in "$SKILL_DIR"/../../lang/*.md; do l=$(basename "$f" .md)
  [ -d "$SKILL_DIR/../../templates/$l" ] && echo "$l"; done
```
Dossier PARA (PARA_DIR). Valeur par défaut selon le scénario : A — PARA, un sous-dossier, pour que l'outillage et les notes restent séparés ; B — ., pour que les dossiers PARA se placent à côté des propres dossiers de l'utilisateur, sauf indication contraire du « Scénario B ». . met les dossiers PARA directement dans REPO_ROOT. Valide : . ou un seul nom de dossier — pas de /, ne commençant pas par ., pas l'un des noms de dossiers PARA eux-mêmes.
Backend de tâches (TASKS). Les choix sont todoist, files ou mcp ; le premier est recommandé. Dites en une ligne ce que chacun signifie : la boîte de réception et les projets d'une application ; des notes de tâches dans le vault, sans application ; toute autre application de tâches connectée via MCP. Ensuite sondez — « Sondage du backend » ci-dessous. Une valeur dont le sondage a échoué n'est jamais enregistrée.

Modèle de Zones (areas.md). Une question : les Zones sont-elles groupées — none, ou les noms des groupes (par exemple Travail, Maison) ? Tout le reste est dérivé et affiché dans le plan, où l'utilisateur peut le modifier :

Clé	Groupé	`none`
`GROUPING`	le nom du champ, `sphere` sauf si l'utilisateur en a nommé un (la clé des modèles d'initialisation)	`none`
`GROUPS`	les noms donnés	vide
`PLACEMENT`	`Areas/<GROUP>/<titre>.md`	`Areas/<titre>.md`
`REVIEW_GROUPING`	un bloc par groupe, les groupes sans rien à signaler supprimés	une liste plate unique
`PLACEMENT_CHECK`	le champ `GROUPING` d'une note doit nommer le dossier de premier niveau sous lequel elle se trouve	`none`
`AREA_TASK_PROJECTS`	les noms des `GROUPS`	un seul nom : la chaîne `areas.review.heading`

Sondage du backend

Le sondage est inbox.list, exécuté selon l'adaptateur pour la valeur choisie (paths.md). Il est en lecture seule ; une boîte de réception vide est un succès. Affichez uniquement le compteur, jamais les captures.

files — rien à sonder : l'adaptateur est le disque, et « Backend manquant » ne peut pas se produire (tasks.md).
mcp — exécutez maintenant les étapes 1 à 6 de adapters/mcp-generic.md. L'étape 1 ne trouvant aucun outil est un échec du sondage. L'étape 6 est le sondage lorsque l'utilisateur l'accepte et que l'application a une boîte de réception ; sinon, le plan indique que le mappage n'est pas vérifié. Les étapes 7 à 8 appartiennent au plan et à « l'Étape 5 » ci-dessous.
Toute autre valeur — exécutez inbox.list selon son adaptateur. Si les outils de l'adaptateur ne sont pas dans cette session, ou si l'appel échoue : dites-le en une ligne (tasks.md « Backend manquant »), n'enregistrez pas la valeur, et proposez files à la place — ou connectez l'application et exécutez /para:init à nouveau. N'écrivez jamais une valeur TASKS dont le sondage n'a pas réussi, et n'enregistrez jamais une valeur tout en promettant de changer plus tard.

Étape 3 — Le plan

Une seule liste de tout ce qui sera créé, fusionné ou modifié, précédée de la chaîne init.plan.heading. C'est une proposition que l'utilisateur modifie, pas une annonce : une modification crée un nouveau plan, affiché à nouveau. Il se termine par la chaîne init.plan.approve, et rien n'est appliqué avant un « oui » (ou l'approbation donnée à l'avance, dans la limite définie par « Réponses fournies à l'avance »).

Le plan nomme, dans cet ordre :

REPO_ROOT (ce dossier) et PARA_ROOT.
Les dossiers à créer, et le journal des identifiants s'il manque.
Les modèles à copier, chacun avec les modifications que « Templates » y apporte. Dans le scénario B, ici : les déplacements, les projets, IGNORE, les doublons conservés et les liens qui seront rompus (« Scénario B », « La partie B du plan »).
La configuration : chaque clé de vault.md et areas.md avec sa valeur ; pour mcp, la table de l'adaptateur (mcp-generic.md étape 7 — le « oui » du plan est le « oui » de cette table).
CLAUDE.md, .claude/settings.json, .obsidian/app.json, .obsidian/templates.json : ce qui est ajouté à chacun. Chaque valeur existante qui serait modifiée est une ligne à part entière, montrant l'ancienne et la nouvelle valeur.
Le résultat du sondage : le backend a répondu (avec le nombre d'éléments dans la boîte de réception), ou files.
Ce qui ne sera pas fait, et pourquoi (un modèle déjà présent, une valeur conservée).

Étape 4 — Instantané (B et C uniquement)

Avant d'appliquer un plan qui touche un vault existant, proposez une copie zip à côté de celui-ci — toujours demandée, le refus est accepté, une réponse donnée à l'avance est prise. Elle est demandée dans le même message que l'approbation du plan (la chaîne init.snapshot), donc l'utilisateur répond une fois :

zip_path="$(dirname "$REPO_ROOT")/$(basename "$REPO_ROOT")-backup-$(date +%Y-%m-%d).zip"
ditto -c -k --keepParent "$REPO_ROOT" "$zip_path"

Le scénario A n'a rien à sauvegarder et saute cette étape.

Étape 5 — Appliquer

...

[Suite tronquée pour la traduction]

qbarev/para-plugin

Qu'est-ce que para-plugin ?

Demander à votre IA préférée

Documentation