novahiz 0.1.0

package/bundled-skills/novahiz-memory/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: novahiz-memory
+description: |
+  Mémoire de projet Novahiz : écriture double, dans le MEMORY.md du projet et dans une page
+  du vault Obsidian. La destination se déduit uniquement de la table de routage
+  _meta/routing.md. Frontmatter obligatoire, wikilinks, fusion plutôt que duplication.
+  Use when a complex task ends, when the user says "mets à jour la mémoire" or "sauvegarde",
+  or when a decision, une cause de bug ou une prochaine étape doit survivre à la session.
+  Triggers on: "mémoire", "MEMORY.md", obsidian, vault, sauvegarde, "note ça", routing.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-memory : mémoire double
+
+Une session se termine par une trace. Deux écritures, jamais une seule.
+
+## Où
+
+| Support | Chemin |
+|---|---|
+| Projet | `MEMORY.md` à la racine du projet courant |
+| Vault | `C:\Users\hiz\Documents\novahiz`, dossier déduit de `_meta\routing.md` |
+
+`_meta\routing.md` est la seule source de vérité pour le dossier cible. Aucune devinette : si le routage est ambigu, tu demandes.
+
+La procédure détaillée vit dans la skill `memory-save`. Charge-la et suis-la plutôt que d'écrire à main levée.
+
+## Interdits
+
+- Écrire dans `index.md`, `log.md`, `hot.md`, `.manifest.json`, `_meta\` ou `.obsidian\`. Ces fichiers appartiennent aux skills de maintenance.
+- Créer un dossier racine de ta propre initiative.
+- Deviner la destination.
+
+## Contenu attendu
+
+1. Ce qui fonctionne.
+2. Ce qui a changé, avec les fichiers clés.
+3. Ce qui reste ouvert : prochaine étape, dette technique, blocages.
+
+## Frontmatter obligatoire
+
+```
+title, category, tags, sources, created, updated, summary
+```
+
+Les tags viennent de `_meta\taxonomy.md`. La page se lie avec des `[[wikilinks]]`. Quand le sujet existe déjà, tu enrichis la page existante au lieu d'en créer une seconde.
+
+## Avant d'écrire
+
+Affiche le chemin retenu. Une écriture annoncée est une écriture vérifiable.
+
+## Pièges
+
+- Écrire la même chose dans deux pages au lieu d'enrichir la première.
+- Recopier le déroulé de la session au lieu de distiller les décisions.
+- Mettre à jour le vault et oublier le `MEMORY.md` du projet.
+- Toucher aux fichiers de maintenance depuis cette skill.

package/bundled-skills/novahiz-plan/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: novahiz-plan
+description: |
+  Étape 1 du pipeline Novahiz : décider la direction avant d'écrire du code.
+  Phase en lecture seule qui produit un plan : définition du « terminé », périmètre,
+  approche retenue, ordre de dépendances, stratégie de découpage, risques, positions des
+  points de contrôle.
+  Use when starting a feature, a refactor, a migration, or any change that spans several
+  files or whose approach is not obvious.
+  Triggers on: "plan this", "comment aborder", "par où commencer", feature, architecture,
+  migration, refactoring, changement multi-fichiers.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-plan : décider la direction
+
+**Étape 1 sur 6** du pipeline `novahiz-planner`. Aucun fichier applicatif n'est modifié ici. Le livrable est un plan.
+
+Étapes suivantes : `novahiz-clarify`, puis `novahiz-task`.
+
+## Entrée
+
+La demande est classée. Rien n'a encore été écrit.
+
+## Ouvre le registre
+
+Le plan se trace dans le registre d'exécution, pas dans une note locale :
+
+```
+novahiz_task action="new"  title="<la demande en une phrase>"
+novahiz_task action="plan" todos=[...]
+```
+
+`todowrite` donne le suivi visible, `novahiz_task` le registre durable qui survit à la compaction.
+
+## Ce que le plan contient
+
+- **Terminé, c'est quoi** : une phrase qui décrit l'état final observable.
+- **Périmètre** : ce qui entre, ce qui reste dehors.
+- **Approche retenue** : la décision, plus les options écartées avec leur raison.
+- **Ordre de dépendances** : ce qui doit exister avant quoi.
+- **Stratégie de découpage** : verticale par défaut, contrat d'abord si une interface est partagée, risque d'abord si une inconnue domine.
+- **Risques** : impact et parade.
+- **Positions des points de contrôle**.
+
+## Lecture seule
+
+Lis le code concerné, les manifestes, les conventions en place. Tu n'écris pas de code pendant cette phase, et tu ne « prépares » pas le terrain par des modifications anodines. Un plan se juge sur les réécritures qu'il évite.
+
+## Ordre d'implémentation
+
+Le graphe de dépendances se remonte : fondations, puis surface. Une API écrite avant son schéma se réécrit, un écran écrit avant son API se jette.
+
+## Stratégies de découpage
+
+**Verticale (défaut).** Une tranche traverse les couches nécessaires pour être observable de bout en bout. Livrer toute la base, puis toute l'API, puis tout l'écran laisse trois chantiers inutilisables.
+
+**Contrat d'abord.** Quand plusieurs consommateurs partagent une interface : fige les types et les signatures, puis parallélise les deux côtés.
+
+**Risque d'abord.** Quand une inconnue domine le reste : prouve le morceau dont la réussite est la moins certaine avant d'investir ailleurs.
+
+## Huit catégories réclament cette étape
+
+Le gate exige `novahiz-plan` pour `code`, `debug`, `browser`, `design-ui`, `database-supabase`, `planning`, `devops` et `data`.
+
+## Validation avant d'exécuter
+
+Un plan complexe ne part pas en exécution sur un accord supposé. Tu portes la décision structurante dans l'outil `question` du harness :
+
+```
+question({
+  questions: [
+    {
+      header: "Valider le plan",
+      question: "Le plan tient-il ? <resume en une phrase>",
+      options: [
+        { label: "Valider et executer (Recommandé)", description: "<ce qui demarre tout de suite>" },
+        { label: "Ajuster le perimetre", description: "<ce qui serait retire ou ajoute>" },
+        { label: "Renoncer", description: "rien n'est ecrit" }
+      ]
+    }
+  ]
+})
+```
+
+Le contenu du plan vit dans le chat. La question de validation vit dans l'interface. Tu ne remplaces jamais l'un par l'autre.
+
+## Passage à l'étape suivante
+
+Si des choix restent ouverts sur l'architecture, les données, le périmètre ou les tests, va d'abord à `novahiz-clarify`. Sinon, `novahiz-task` convertit le plan en tâches atomiques.
+
+## Garde-fous
+
+- Commence par la cible et la contrainte, pas par les fichiers.
+- Un plan sans ordre de dépendances reste une intention.
+- Ne remplace jamais un plan encore ouvert : même travail, mise à jour en place ; travail différent, arrêt et question.
+- Un plan dont toutes les tranches sont XL n'est pas un plan.
+- Un plan sans point de contrôle ne dit pas quand s'arrêter.
+- Ne promets rien que tu n'aies vérifié. Une direction annoncée sans lecture du code est une supposition.

package/bundled-skills/novahiz-planner/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: novahiz-planner
+description: |
+  Orchestrateur du pipeline Novahiz. CATEGORY-AWARE et BLOQUANT : aucun travail non
+  trivial ne commence sans plan écrit.
+  Le pipeline suit six étapes dans l'ordre : plan, clarification, tâches, analyse,
+  implémentation, convergence. Chaque étape a sa skill dédiée.
+  Use at the START of any request with 3+ steps, several files, or an unclear scope.
+  Triggers on: multi-step tasks, feature implementation, refactoring, debugging sessions,
+  migrations, architecture work, "plan this", "break this down", "where do I start".
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-planner : orchestrateur du pipeline
+
+Tu ouvres le travail. Toute tâche non triviale suit la même séquence.
+
+## Loi d'entrée
+
+```
+SI la catégorie n'est ni research ni general ET qu'aucune tâche n'est ouverte :
+  -> ARRÊT. Aucune édition, aucune commande.
+  -> Ouvre le pipeline, puis exécute.
+```
+
+## Le pipeline
+
+| # | Étape | Skill | Produit | Ferme quand | Écrit ? |
+|---|---|---|---|---|---|
+| 1 | Plan | `novahiz-plan` | direction, périmètre, ordre de dépendances, stratégie de découpage, risques | le plan tient et l'utilisateur l'a vu | non |
+| 2 | Clarification | `novahiz-clarify` | familles d'ambiguïté, salves de questions, décisions figées | les éléments ouverts ne changent plus ni architecture, ni données, ni tâches, ni tests, ni UX, ni exploitation | non |
+| 3 | Tâches | `novahiz-task` | tâches atomiques avec critères d'acceptation et preuve | chaque tâche a un critère et une preuve, et l'ordre tient | registre seul |
+| 4 | Analyse | `novahiz-analyse` | fichiers, symboles, chemins de données, inconnues | le périmètre utile est compris et les inconnues nommées | non |
+| 5 | Implémentation | `novahiz-implement` | incréments qui gardent le système utilisable | les tranches sont terminées et vertes | oui |
+| 6 | Convergence | `novahiz-converge` | inventaire d'intention, écart classé, restes tracés | la liste ouverte est vide ou explicitement acceptée | registre seul |
+
+Deux retours en arrière prévus : la clarification renvoie au plan quand une réponse change l'architecture ; la convergence renvoie aux tâches quand un reste apparaît.
+
+## Ce que le gate applique vraiment
+
+Le gate (voir `novahiz-gate`) ne bloque que sur les étapes de type `skill`. Dans le roadmap `code`, ce sont `novahiz-plan`, `novahiz-clarify`, `novahiz-task`, `novahiz-analyse` et `code-reviewer`. Les étapes `implement` et `converge` figurent dans `requiredSkills` mais ne refusent aucune édition.
+
+Conséquence pratique : si l'implémentation ou la convergence n'ont pas lieu, rien ne s'y oppose mécaniquement. Le pipeline tient donc aussi parce qu'il est suivi, pas seulement parce qu'il est programmé.
+
+## Lecture seule
+
+Les étapes 1, 2 et 4 ne modifient aucun fichier. L'étape 3 n'écrit que dans le registre d'exécution. L'écriture de code commence à l'étape 5.
+
+## Les 14 catégories
+
+code, debug, review, audit, test, research, browser, design-ui, database-supabase, docs-writing, planning, devops, data, general.
+
+Le pipeline complet s'applique à `code`, `debug`, `browser`, `design-ui`, `database-supabase`, `planning`, `devops` et `data`. `review`, `audit` et `test` gardent leurs étapes métier et se terminent par une convergence. `research` et `general` n'imposent aucune étape.
+
+## Étapes annexes selon la catégorie
+
+| Catégorie | Pipeline 1 à 6 | Code review | Mémoire | Audit | Next steps |
+|---|---|---|---|---|---|
+| `code` | oui | oui | oui | oui | oui |
+| `debug` | oui | oui | oui | oui | oui |
+| `database-supabase` | oui | oui | oui | oui | oui |
+| `browser` | oui | non | oui | oui | oui |
+| `design-ui` | oui | non | oui | oui | oui |
+| `planning` | oui | non | oui | oui | oui |
+| `devops` | oui | non | oui | oui | oui |
+| `data` | oui | non | oui | oui | oui |
+| `review` | étapes métier | oui | oui | oui | oui |
+| `audit` | étapes métier | non | oui | oui | oui |
+| `test` | étapes métier | non | oui | oui | oui |
+| `docs-writing` | non | non | oui | oui | oui |
+| `research` | non | non | non | non | oui |
+| `general` | non | non | oui | oui | oui |
+
+## Règles transverses
+
+- **Choix par l'interface** : toute décision posée à l'utilisateur passe par l'outil `question` du harness. Tableau interactif, options décrites par leur conséquence, option recommandée en tête. Aucune question et aucune demande de confirmation en prose dans le chat. Le chat porte le contexte et le contenu, l'interface porte les choix.
+- **humanizer** sur toute prose : textes, documentation, messages d'interface, commentaires.
+- **impeccable** sur tout ce qui touche le style visuel.
+- **Skills Supabase** (`supabase`, `supabase-postgres-best-practices`) sur la catégorie `database-supabase`.
+- **Honnêteté** : aucune exécution affirmée sans sortie réelle. Une incertitude se dit.
+- **Critique** : une demande incohérente, ambiguë, risquée ou sous-optimale se contredit, avec une alternative.
+- **Suite** : à la fin, une prochaine étape utile est proposée, même si c'est de ne rien faire.
+- **Mémoire** : la fin d'une tâche complexe passe par `novahiz-memory`.
+
+## Comportement bloquant
+
+Quand aucune tâche n'est ouverte et que la catégorie n'est ni `research` ni `general` :
+
+1. ARRÊT : aucune édition, aucune commande.
+2. ANALYSE : `novahiz_classify` puis `novahiz_roadmap` donnent la catégorie et les étapes.
+3. PIPELINE : ouvre les étapes dans l'ordre, en commençant par le plan.
+4. ÉCRIS : `novahiz_task action="new"` puis `action="plan"`, et `todowrite` pour le suivi visible.
+5. PRÉSENTE : pour une tâche complexe, montre le plan avant d'exécuter.
+6. EXÉCUTE : une seule étape `in_progress`, mise à jour en temps réel, `done` seulement avec preuve.
+7. CLÔTURE : `novahiz-converge`, puis `novahiz-audit`.
+
+## Dérogation utilisateur
+
+Si l'utilisateur dit « fais-le sans plan » ou « pas besoin de plan » :
+
+1. crée une tâche minimale d'une étape ;
+2. préviens : « Plan minimal créé. Les prochaines tâches recevront un plan complet. » ;
+3. garde la dérogation visible pour l'audit.

package/bundled-skills/novahiz-task/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: novahiz-task
+description: |
+  Étape 3 du pipeline Novahiz : convertir un plan en tâches atomiques, ordonnées et
+  vérifiables. Chaque tâche porte un objectif, des critères d'acceptation testables, une
+  preuve, ses dépendances, les fichiers qu'elle possède et sa taille (XS à XL).
+  Use when a plan must become an ordered task list, or when work must be split across
+  sessions or agents.
+  Triggers on: "découpe", liste de tâches, todo, sous-tâches, critères d'acceptation,
+  priorisation, "par quoi je commence".
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-task : découper en tâches vérifiables
+
+**Étape 3 sur 6** du pipeline. Le plan dit où l'on va ; cette étape dit par quels pas, dans quel ordre, et comment chaque pas se ferme.
+
+Étape précédente : `novahiz-clarify`. Étape suivante : `novahiz-analyse`.
+
+## Contrat de tâche
+
+Toutes les tâches prennent la même forme. Une tâche sans critère d'acceptation et sans preuve reste une intention.
+
+```markdown
+## Tâche N : <titre court, à l'impératif>
+
+Objectif : une phrase.
+Critères d'acceptation :
+- [ ] condition testable
+- [ ] condition testable
+Preuve : la commande, le test ou l'observation qui ferme la tâche
+Dépend de : #A, #B (ou Aucune)
+Fichiers concernés : chemin/a, chemin/b
+Taille : XS | S | M | L | XL
+```
+
+## Le registre refuse une étape `verify` sans preuve
+
+`novahiz_task` applique cette règle : une étape de nature `verify` ne se ferme pas sans `proof`. La preuve se décide donc au moment du plan, pas au moment du doute.
+
+| Action | Usage |
+|---|---|
+| `plan` | déposer la liste complète d'un coup |
+| `todo` | ajouter une étape (`kind` : read, edit, verify, delegate) |
+| `start` / `done` | ouvrir, fermer (`done` exige `proof` sur une étape verify) |
+| `block` | bloquer, avec `reason` |
+| `review` | réviser le plan entre deux étapes |
+| `amend` / `insert` / `drop` / `reorder` | corriger la liste sans la réécrire |
+| `signals` / `status` / `resume` | relire l'état |
+
+## Taille
+
+| Taille | Fichiers | Exemple |
+|---|---|---|
+| XS | 1 | ajouter une règle de validation |
+| S | 1 à 2 | un endpoint |
+| M | 3 à 5 | un parcours complet |
+| L | 5 à 8 | fonctionnalité touchant plusieurs composants |
+| XL | 8 et plus | à redécouper, sans exception |
+
+Redécoupe encore si le travail dépasse une session suivie, si les critères ne tiennent pas en trois puces, si deux sous-systèmes indépendants sont touchés, ou si le titre contient « et ». Ce « et » signale deux tâches collées.
+
+## Ordre
+
+- Les dépendances d'abord.
+- Chaque tâche laisse le système fonctionnel.
+- Les tâches risquées passent tôt : échouer vite coûte moins cher.
+- Un point de contrôle tous les deux ou trois pas. Il sert à prouver, puis à décider de continuer, corriger ou abandonner.
+
+## Catégories qui exigent cette étape
+
+`code`, `browser`, `design-ui` et `planning`.
+
+## Discipline
+
+- Une seule étape `in_progress` à la fois.
+- Mise à jour en temps réel, pas de complétion groupée.
+- `completed` seulement après vérification, jamais sur intention.
+- Une étape bloquée reste `in_progress` et une tâche de suivi décrit le blocage.
+- Le vocabulaire de l'utilisateur est repris tel quel : commandes, options, arguments, ordre.
+
+## Conflit de plan
+
+Avant d'écrire, regarde s'il existe un plan encore ouvert. Même travail : mise à jour en place. Travail différent : arrêt, et tu poses la décision dans l'outil `question` du harness (reprendre, remplacer, créer à côté), jamais en prose. Tu ne supprimes, n'écrases et ne renommes jamais un plan ouvert de ta propre initiative.
+
+## Rationnalisations
+
+| Rationnalisation | Réalité |
+|---|---|
+| « je verrai en avançant » | c'est ainsi qu'on obtient un enchevêtrement et du travail refait |
+| « les tâches sont évidentes » | écris-les : l'écrit révèle les dépendances et les cas limites oubliés |
+| « planifier, c'est du temps perdu » | la planification fait partie du travail |
+| « je garde tout en tête » | la fenêtre de contexte est finie, un plan écrit traverse les sessions |
+| « l'ancien plan est périmé » | les tâches non cochées portent un état qui n'existe nulle part ailleurs |
+
+## Drapeaux rouges
+
+- implémentation lancée sans liste de tâches
+- tâche « implémenter la fonctionnalité » sans critère d'acceptation
+- plan sans étape de vérification
+- toutes les tâches en XL
+- aucun point de contrôle
+- ordre de dépendance ignoré
+- plan écrasé sans confirmation