novahiz 0.1.0

package/bundled-skills/migrate/cypress-mapping.md

@@ -0,0 +1,79 @@
+# Cypress → Playwright Mapping
+
+## Commands
+
+| Cypress | Playwright | Notes |
+|---|---|---|
+| `cy.visit('/page')` | `await page.goto('/page')` | Use `baseURL` in config |
+| `cy.get('.selector')` | `page.locator('.selector')` | Prefer `getByRole()` |
+| `cy.get('[data-cy=x]')` | `page.getByTestId('x')` | |
+| `cy.contains('text')` | `page.getByText('text')` | |
+| `cy.find('.child')` | `parent.locator('.child')` | Chain from parent locator |
+| `cy.first()` | `locator.first()` | |
+| `cy.last()` | `locator.last()` | |
+| `cy.eq(n)` | `locator.nth(n)` | |
+| `cy.parent()` | `locator.locator('..')` | Or restructure with better locators |
+| `cy.children()` | `locator.locator('> *')` | |
+| `cy.siblings()` | Not direct — restructure test | Use parent + filter |
+
+## Actions
+
+| Cypress | Playwright | Notes |
+|---|---|---|
+| `.click()` | `await locator.click()` | Always `await` |
+| `.dblclick()` | `await locator.dblclick()` | |
+| `.rightclick()` | `await locator.click({ button: 'right' })` | |
+| `.type('text')` | `await locator.fill('text')` | `fill()` clears first |
+| `.type('text', { delay: 50 })` | `await locator.pressSequentially('text', { delay: 50 })` | Simulates typing |
+| `.clear()` | `await locator.clear()` | |
+| `.check()` | `await locator.check()` | |
+| `.uncheck()` | `await locator.uncheck()` | |
+| `.select('value')` | `await locator.selectOption('value')` | |
+| `.scrollTo()` | `await locator.scrollIntoViewIfNeeded()` | |
+| `.trigger('event')` | `await locator.dispatchEvent('event')` | |
+| `.focus()` | `await locator.focus()` | |
+| `.blur()` | `await locator.blur()` | |
+
+## Assertions
+
+| Cypress | Playwright | Notes |
+|---|---|---|
+| `.should('be.visible')` | `await expect(locator).toBeVisible()` | Web-first, auto-retry |
+| `.should('not.exist')` | `await expect(locator).not.toBeVisible()` | Or `.toHaveCount(0)` |
+| `.should('have.text', 'x')` | `await expect(locator).toHaveText('x')` | |
+| `.should('contain', 'x')` | `await expect(locator).toContainText('x')` | |
+| `.should('have.value', 'x')` | `await expect(locator).toHaveValue('x')` | |
+| `.should('have.attr', 'x', 'y')` | `await expect(locator).toHaveAttribute('x', 'y')` | |
+| `.should('have.class', 'x')` | `await expect(locator).toHaveClass(/x/)` | |
+| `.should('be.disabled')` | `await expect(locator).toBeDisabled()` | |
+| `.should('be.checked')` | `await expect(locator).toBeChecked()` | |
+| `.should('have.length', n)` | `await expect(locator).toHaveCount(n)` | |
+| `cy.url().should('include', '/x')` | `await expect(page).toHaveURL(/\/x/)` | |
+| `cy.title().should('eq', 'x')` | `await expect(page).toHaveTitle('x')` | |
+
+## Network
+
+| Cypress | Playwright |
+|---|---|
+| `cy.intercept('GET', '/api/*', { body: data })` | `await page.route('**/api/*', route => route.fulfill({ body: JSON.stringify(data) }))` |
+| `cy.intercept('POST', '/api/*').as('save')` | `const savePromise = page.waitForResponse('**/api/*')` |
+| `cy.wait('@save')` | `await savePromise` |
+
+## Fixtures & Custom Commands
+
+| Cypress | Playwright |
+|---|---|
+| `cy.fixture('data.json')` | `import data from './test-data/data.json'` |
+| `Cypress.Commands.add('login', ...)` | `test.extend({ authenticatedPage: ... })` |
+| `beforeEach(() => { ... })` | `test.beforeEach(async ({ page }) => { ... })` |
+| `before(() => { ... })` | `test.beforeAll(async () => { ... })` |
+
+## Config
+
+| Cypress | Playwright |
+|---|---|
+| `baseUrl` in `cypress.config.ts` | `use.baseURL` in `playwright.config.ts` |
+| `defaultCommandTimeout` | `expect.timeout` or `use.actionTimeout` |
+| `video: true` | `use.video: 'on'` |
+| `screenshotOnRunFailure` | `use.screenshot: 'only-on-failure'` |
+| `retries: { runMode: 2 }` | `retries: 2` |

package/bundled-skills/migrate/selenium-mapping.md

@@ -0,0 +1,94 @@
+# Selenium → Playwright Mapping
+
+## Driver Setup
+
+| Selenium (JS) | Playwright |
+|---|---|
+| `new Builder().forBrowser('chrome').build()` | Handled by config — no driver setup |
+| `driver.quit()` | Automatic — Playwright manages browser lifecycle |
+| `driver.manage().setTimeouts(...)` | Config: `timeout`, `expect.timeout` |
+
+## Navigation
+
+| Selenium | Playwright | Notes |
+|---|---|---|
+| `driver.get(url)` | `await page.goto(url)` | Use `baseURL` |
+| `driver.navigate().back()` | `await page.goBack()` | |
+| `driver.navigate().forward()` | `await page.goForward()` | |
+| `driver.navigate().refresh()` | `await page.reload()` | |
+| `driver.getCurrentUrl()` | `page.url()` | |
+| `driver.getTitle()` | `await page.title()` | |
+
+## Element Location
+
+| Selenium | Playwright | Preferred |
+|---|---|---|
+| `By.id('x')` | `page.locator('#x')` | `page.getByTestId('x')` |
+| `By.css('.x')` | `page.locator('.x')` | `page.getByRole(...)` |
+| `By.xpath('//div')` | `page.locator('xpath=//div')` | Avoid — use role-based |
+| `By.name('x')` | `page.locator('[name=x]')` | `page.getByLabel(...)` |
+| `By.linkText('x')` | `page.getByRole('link', { name: 'x' })` | ✅ Best practice |
+| `By.partialLinkText('x')` | `page.getByRole('link', { name: /x/ })` | ✅ Best practice |
+| `By.tagName('button')` | `page.getByRole('button')` | ✅ Best practice |
+| `By.className('x')` | `page.locator('.x')` | `page.getByRole(...)` |
+| `findElement()` | Returns first match | `locator.first()` |
+| `findElements()` | `page.locator(selector)` | Use `.count()` or `.all()` |
+
+## Actions
+
+| Selenium | Playwright |
+|---|---|
+| `element.click()` | `await locator.click()` |
+| `element.sendKeys('text')` | `await locator.fill('text')` |
+| `element.sendKeys(Key.ENTER)` | `await locator.press('Enter')` |
+| `element.clear()` | `await locator.clear()` |
+| `element.submit()` | `await locator.press('Enter')` or click submit button |
+| `element.getText()` | `await locator.textContent()` |
+| `element.getAttribute('x')` | `await locator.getAttribute('x')` |
+| `element.isDisplayed()` | `await locator.isVisible()` |
+| `element.isEnabled()` | `await locator.isEnabled()` |
+| `element.isSelected()` | `await locator.isChecked()` |
+
+## Waits
+
+| Selenium | Playwright | Notes |
+|---|---|---|
+| `WebDriverWait(driver, 10).until(EC.visibilityOf(el))` | `await expect(locator).toBeVisible()` | Auto-retries |
+| `WebDriverWait(driver, 10).until(EC.elementToBeClickable(el))` | `await locator.click()` | Auto-waits for clickable |
+| `WebDriverWait(driver, 10).until(EC.presenceOf(el))` | `await expect(locator).toBeAttached()` | |
+| `WebDriverWait(driver, 10).until(EC.textToBe(el, 'x'))` | `await expect(locator).toHaveText('x')` | |
+| `Thread.sleep(3000)` | ❌ Never use | Use assertions instead |
+| `driver.manage().setTimeouts({ implicit: 10000 })` | Not needed | Playwright auto-waits |
+
+## Advanced
+
+| Selenium | Playwright |
+|---|---|
+| `Actions(driver).moveToElement(el).perform()` | `await locator.hover()` |
+| `Actions(driver).dragAndDrop(src, tgt).perform()` | `await src.dragTo(tgt)` |
+| `Actions(driver).doubleClick(el).perform()` | `await locator.dblclick()` |
+| `Actions(driver).contextClick(el).perform()` | `await locator.click({ button: 'right' })` |
+| `driver.switchTo().frame(el)` | `page.frameLocator('#frame')` |
+| `driver.switchTo().defaultContent()` | Not needed — use `page` directly |
+| `driver.switchTo().alert()` | `page.on('dialog', d => d.accept())` |
+| `driver.switchTo().window(handle)` | `const popup = await page.waitForEvent('popup')` |
+| `driver.executeScript(js)` | `await page.evaluate(js)` |
+| `driver.takeScreenshot()` | `await page.screenshot({ path: 'x.png' })` |
+
+## Test Structure
+
+| Selenium (Jest/Mocha) | Playwright |
+|---|---|
+| `describe('Suite', () => { ... })` | `test.describe('Suite', () => { ... })` |
+| `it('should...', () => { ... })` | `test('should...', async ({ page }) => { ... })` |
+| `beforeAll(() => { ... })` | `test.beforeAll(async () => { ... })` |
+| `beforeEach(() => { ... })` | `test.beforeEach(async ({ page }) => { ... })` |
+| `afterEach(() => { ... })` | `test.afterEach(async ({ page }) => { ... })` |
+
+## Key Differences
+
+1. **No implicit waits** — Playwright auto-waits for actionability
+2. **No driver management** — Playwright handles browser lifecycle
+3. **Built-in assertions** — `expect(locator)` with auto-retry
+4. **Parallel by default** — tests run in parallel, must be isolated
+5. **Traces instead of screenshots** — richer debugging artifacts

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

@@ -0,0 +1,74 @@
+---
+name: novahiz-analyse
+description: |
+  Étape 4 du pipeline Novahiz : comprendre le code concerné avant de le modifier.
+  Cinq phases ordonnées (reconnaissance, architecture, qualité, exploitation, synthèse),
+  appuyées sur la carte du code quand elle est disponible. Chaque affirmation cite un
+  chemin de fichier réel ; ce qui n'a pas pu être déterminé est dit explicitement.
+  Use before touching unfamiliar code, before a refactor or a migration, or to locate a bug.
+  Triggers on: "comprendre ce code", "où est", "qui appelle", carte du codebase,
+  analyse d'impact, cause racine, point d'entrée.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-analyse : comprendre avant de modifier
+
+**Étape 4 sur 6** du pipeline. L'analyse porte sur ce que la tâche exige, jamais sur tout le dépôt. Profondeur plutôt qu'exhaustivité.
+
+Étape précédente : `novahiz-task`. Étape suivante : `novahiz-implement`.
+
+## Appuie-toi sur la carte du code
+
+Avant de lire au hasard : la skill `code-understand` construit une carte classée et citée, et le serveur `narsil` expose le graphe d'appels, les symboles, les références et les imports. Une question « qui appelle ça » se règle avec l'outil, pas en devinant.
+
+## Phase 1 : reconnaissance
+
+- Arborescence sur deux ou trois niveaux.
+- Manifestes d'abord : package.json, Cargo.toml, go.mod, pyproject.toml, pom.xml, build.gradle, Gemfile, csproj, Podfile, Package.swift.
+- Build et CI : Makefile, Dockerfile, docker-compose, workflows, turbo.json, nx.json.
+- Configs : tsconfig, eslint, modèle d'environnement, bundler, editorconfig.
+- Docs : README, CONTRIBUTING, ARCHITECTURE, dossier docs.
+- Langages, frameworks, présence d'un monorepo.
+
+## Phase 2 : architecture
+
+- Points d'entrée : main, index, server, routes, CLI, AppDelegate, activities.
+- Suis jusqu'à cinq chemins critiques de bout en bout : route vers contrôleur vers service vers données vers réponse.
+- Graphe de dépendances entre modules.
+- Pattern dominant : monolithe, microservices, événementiel, hexagonale, MVC, CQRS.
+- Couche données : schémas, migrations, ORM, modèles, cache.
+- Surface d'API : REST, GraphQL, gRPC, WebSocket, IPC, contrats, authentification.
+
+## Phase 3 : qualité
+
+- Tests : structure, frameworks, unités, intégration, bout en bout, fixtures, mocks.
+- Gestion d'erreurs et journalisation.
+- Typage et validation à l'exécution.
+- Posture de sécurité : authentification, autorisation, secrets, assainissement, vulnérabilités de dépendances.
+- Cohérence des motifs, nommage, duplication.
+
+## Phase 4 : exploitation
+
+Build, CI/CD, modèle de déploiement, observabilité, gestion des environnements.
+
+## Phase 5 : synthèse
+
+Écris la synthèse après les phases précédentes, jamais avant. Chaque affirmation cite un chemin de fichier réel. Dis ce que tu n'as pas pu déterminer. Un schéma ASCII aide pour l'architecture.
+
+Destination : le dossier de documentation du projet s'il en a un, sinon le registre d'exécution. Tu n'inventes pas `docs/analysis/` dans un projet qui n'a aucune convention de ce genre.
+
+## Six catégories réclament cette étape
+
+`code`, `debug`, `review`, `database-supabase`, `devops` et `data`.
+
+## Règles
+
+- Lire avant d'écrire.
+- Ignorer le code généré, vendoré et le boilerplate.
+- Ne pas redocumenter tout le dépôt à chaque tâche : cible le périmètre utile.
+- Une observation sans chemin de fichier ne vaut rien.
+
+## Sortie
+
+Les fichiers et symboles qui portent la logique, les chemins de données, les points d'extension, et la liste explicite des inconnues restantes. Cette sortie alimente `novahiz-implement`.

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

@@ -0,0 +1,75 @@
+---
+name: novahiz-audit
+description: |
+  Audit de fin de session pour Novahiz. CATEGORY-AWARE : ne contrôle que les règles des
+  catégories réellement rencontrées. S'appuie sur l'état vérifiable (registre d'exécution,
+  journal du gate, skills chargées, diff de la session) et jamais sur la mémoire de l'agent.
+  Use at the END of a session, or when the user says "audit" or "vérifie".
+  Triggers on: "audit", "vérifie", fin de session, compliance check, ce qu'on a oublié.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-audit : contrôle de fin de session
+
+Tu audites à partir de faits vérifiables. Une case cochée de mémoire ne vaut rien.
+
+## Les 14 catégories réelles
+
+code, debug, review, audit, test, research, browser, design-ui, database-supabase, docs-writing, planning, devops, data, general.
+
+`general` est la catégorie de repli. Il n'y a pas de catégorie `trivial` dans le catalogue.
+
+## Ce qui se vérifie vraiment
+
+| Contrôle | Source de preuve | S'applique à |
+|---|---|---|
+| Plan et registre ouverts | `novahiz_task status` ou `todoread` | tout sauf research |
+| Étapes de la catégorie parcourues | `novahiz_roadmap --category X` puis `novahiz_step` | tout sauf research et general |
+| Skills requises chargées | journal du gate, table `enforcement_log` | tout |
+| humanizer appliqué sur la prose | règles R1 déclenchées, ou skill chargée | docs-writing, code, audit, planning, design-ui |
+| impeccable appliqué au style | règles R2 déclenchées, ou skill chargée | design-ui |
+| Revue de code faite | étape `review` du roadmap, skill `code-reviewer` | code, review, debug |
+| Scan de sécurité | étape `scan`, skill `security-guidance` | audit |
+| Preuve sur les étapes de vérification | `novahiz_task` refuse `done` sans `proof` | tout |
+| Mémoire à jour | `MEMORY.md` plus page vault, via `novahiz-memory` | tout sauf research |
+| Aucune simulation | affirmations recoupées avec des sorties réelles | tout |
+
+## Méthode
+
+1. Récupère la catégorie primaire et les catégories rencontrées.
+2. Pour chaque contrôle applicable, cherche la preuve. Pas de preuve, pas de validation.
+3. Note `conforme`, `manquant` ou `non applicable`.
+4. Score : conformes sur applicables, en pourcentage. Sous 70 %, propose des correctifs précis. À 90 % et plus, conclus « session conforme ».
+
+## Sortie
+
+Un rapport court dans la conversation :
+
+```
+## Audit de session
+Catégories : code, test
+| Contrôle | Statut | Preuve |
+|---|---|---|
+| Registre | conforme | 6 étapes, 1 bloquée |
+| humanizer | conforme | chargée avant rédaction |
+| Revue de code | manquant | étape review non exécutée |
+Score : 67 %
+
+## À corriger
+- Lancer code-reviewer sur les fichiers modifiés
+
+## À retenir
+- ...
+```
+
+## Pièges
+
+- Cocher une règle sans preuve.
+- Inventer un journal de conformité, un fichier de session ou un script de validation : ils n'existent pas dans ce système.
+- Auditer des catégories qui n'ont pas été rencontrées.
+- Confondre absence de preuve et conformité.
+
+## Suite
+
+Ce qui se répare se répare tout de suite : relancer humanizer, lancer la revue, écrire la mémoire. Le reste est consigné pour la session suivante.

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

@@ -0,0 +1,94 @@
+---
+name: novahiz-clarify
+description: |
+  Étape 2 du pipeline Novahiz : lever les ambiguïtés avant de figer le plan.
+  Deux mécanismes combinés : un balayage d'ambiguïté par familles de risque, et des salves
+  de questions ordonnées par dépendances (la frontière), chaque question numérotée avec une
+  réponse recommandée.
+  Use when the request is vague, underspecified, contradictory, or when several plausible
+  readings lead to different work.
+  Triggers on: "clarifier", ambigu, "je ne sais pas encore", périmètre flou, exigences
+  manquantes, "deux lectures possibles", questions ouvertes.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-clarify : lever les ambiguïtés
+
+**Étape 2 sur 6** du pipeline. Tu interroges avant que le plan ne soit figé.
+
+Étape précédente : `novahiz-plan`. Étape suivante : `novahiz-task`.
+
+## Entrée
+
+Demande ambiguë, contradictoire, ou assez large pour que deux lectures produisent deux travaux différents.
+
+## A. Balayage par familles
+
+Passe la demande au crible de dix familles de risque. Note chacune `claire`, `partielle` ou `manquante`.
+
+1. Comportement et portée fonctionnelle
+2. Domaine et modèle de données
+3. Parcours et interactions
+4. Qualités non fonctionnelles : performance, charge, disponibilité, sécurité, accessibilité, internationalisation
+5. Intégrations et dépendances externes
+6. Cas limites et gestion des échecs
+7. Contraintes et compromis
+8. Terminologie et cohérence
+9. Signaux de complétion : ce qui prouve que c'est fini
+10. Zones de remplissage et valeurs provisoires
+
+Une famille laissée `manquante` sur la portée, les données, le découpage, les tests, l'UX ou l'exploitation devient une question. Le reste attend.
+
+## B. Salves par frontière, posées dans l'interface
+
+Modélise les décisions comme un arbre : chaque décision ouvre celles qui en dépendent.
+
+La **frontière** est l'ensemble des décisions dont les prérequis sont déjà tranchés, donc posables maintenant sans deviner. Une salve est **un seul appel** à l'outil `question` du harness, avec une entrée par décision de la frontière.
+
+```
+question({
+  questions: [
+    {
+      header: "<titre court, 30 caracteres au plus>",
+      question: "<la decision, une phrase, avec son enjeu>",
+      options: [
+        { label: "<option recommandee> (Recommandé)", description: "<consequence concrete>" },
+        { label: "<option>", description: "<consequence concrete>" },
+        { label: "<option>", description: "<consequence concrete>" }
+      ]
+    }
+  ]
+})
+```
+
+Règles de salve :
+
+- **Aucune question en prose dans le chat.** Le tableau interactif est le seul canal. Le chat porte le contexte, jamais la liste des questions.
+- Cinq questions au maximum, classées par impact croisé avec incertitude.
+- Deux à cinq options par question, exclusives entre elles, chacune décrite par ce qu'elle implique.
+- L'option que tu recommandes passe en premier et porte le suffixe `(Recommandé)`. L'interface ajoute une réponse libre toute seule : n'ajoute ni « Autre » ni option fourre-tout.
+- `multiple: true` seulement quand plusieurs réponses peuvent coexister.
+- Une question qui dépend d'une autre question encore ouverte appartient à une salve ultérieure.
+- Chaque réponse déplace la frontière : recalcule-la, relance un appel.
+- Tu attends le retour de l'appel avant de continuer.
+
+Si le harness courant n'expose pas d'outil `question`, tu poses **une** question par tour, la recommandation en tête, et tu attends. Tu ne déverses jamais une liste de questions d'un coup.
+
+Tu réponds toi-même à tout ce que deux fichiers lus suffisent à trancher.
+
+## Devoir de critique
+
+Si la demande est incohérente, ambiguë, risquée ou sous-optimale, dis-le et propose une alternative. Garder le silence laisse une erreur en place.
+
+## Sortie
+
+Une courte liste : familles ouvertes, questions posées, réponses obtenues, décisions figées. Tu passes à `novahiz-task` quand les éléments encore ouverts ne changent plus ni l'architecture, ni les données, ni les tâches, ni les tests, ni l'UX, ni l'exploitation.
+
+## Pièges
+
+- Poser une question de confort sur ce qui est déjà écrit dans la demande.
+- Poser six questions là où la frontière en autorise cinq.
+- Interroger sur le style ou sur le détail d'exécution.
+- Enchaîner les salves sans relire les réponses pour recalculer la frontière.
+- Écrire les questions en prose au lieu d'ouvrir le tableau interactif.

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

@@ -0,0 +1,76 @@
+---
+name: novahiz-converge
+description: |
+  Étape 6 du pipeline Novahiz : fermer l'écart entre l'intention et le code.
+  Construit l'inventaire d'intention (demande, plan, critères d'acceptation, étapes du
+  registre, principes du projet), évalue l'état présent du code, classe chaque élément
+  satisfait, partiel ou non satisfait, et ajoute les restes comme étapes tracées.
+  En ajout seul : ne réécrit rien, ne supprime aucune étape, ne touche pas au code.
+  Use at the end of an implementation, before declaring work done.
+  Triggers on: "c'est fini ?", vérifier la feature, convergence, analyse d'écart,
+  "qu'est-ce qui reste", clôture.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-converge : fermer l'écart
+
+**Étape 6 sur 6** du pipeline. Elle tourne après l'implémentation, jamais pendant.
+
+Étape précédente : `novahiz-implement`.
+
+## Ne pas confondre avec l'audit
+
+`novahiz-converge` mesure l'écart entre ce qui était demandé et ce que le code fait. `novahiz-audit` mesure la conformité de la session aux règles. Le premier porte sur le travail, le second sur la méthode.
+
+## Source d'intention
+
+L'intention vient des artefacts, pas de ta mémoire :
+
+- la demande initiale,
+- le plan,
+- les critères d'acceptation des tâches,
+- le registre d'exécution : `novahiz_task action="status"` et `action="signals"`,
+- les principes du projet, à commencer par `AGENTS.md`.
+
+Constitue l'inventaire : chaque élément identifié et traçable.
+
+## Évaluation
+
+Regarde l'état présent du code. Ce n'est pas un diff : ni git, ni branche, ni historique. Tu évalues ce que le code fait maintenant.
+
+Classe chaque élément :
+
+- **satisfait** : le code fait ce qui est demandé, et la preuve le montre.
+- **partiel** : une partie tient, le reste manque ou ne se prouve pas.
+- **non satisfait** : rien ne couvre l'élément.
+
+Une étape fermée sans preuve ne compte pas comme satisfaite, même si le registre la dit `done`.
+
+## Écriture en ajout seul
+
+- La seule écriture autorisée est l'ajout des restes au registre, chacun devenant une étape traçable : `novahiz_task action="insert"`.
+- Tu ne modifies ni le plan, ni les critères, ni les étapes existantes.
+- Tu ne renommes, ne renumérotes, ne réordonnes et ne supprimes aucune étape.
+- L'acceptation du reste ouvert se demande par l'outil `question` du harness : accepter le reste, le traiter maintenant, ou le tracer pour plus tard. Un reste non explicitement accepté garde la clôture ouverte.
+- Tu ne touches pas au code applicatif.
+
+Si tout est satisfait, tu ne touches à rien et tu rapportes un résultat propre. Un rapport vide n'est pas un résultat propre.
+
+## Sévérité
+
+La violation d'un principe MUST d'`AGENTS.md` est le niveau le plus haut et produit une étape de remédiation. Si les principes sont absents, tu le dis et tu continues.
+
+## Clôture
+
+Rapporte trois listes : ce qui est satisfait et prouvé, ce qui reste ouvert, ce qui n'a pas pu être évalué et pourquoi. Le travail est terminé quand la liste ouverte est vide, ou quand l'utilisateur accepte explicitement le reste.
+
+## Catégories concernées
+
+L'étape de convergence apparaît dans `code`, `debug`, `test`, `audit`, `browser`, `design-ui`, `database-supabase`, `docs-writing`, `planning`, `devops` et `data`.
+
+## Pièges
+
+- Déclarer satisfait ce qui n'a jamais été exécuté.
+- Confondre « l'étape est cochée » et « le comportement existe ».
+- Réécrire le plan pour qu'il colle au résultat obtenu.

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

@@ -0,0 +1,82 @@
+---
+name: novahiz-gate
+description: |
+  Le gate d'application de Novahiz, vu du côté agent. Explique pourquoi une édition est
+  refusée, quelles skills la débloquent, et comment lire le message de blocage.
+  Le gate est implémenté dans src/gate.ts et combine deux sources : les règles
+  (catalog/rules.json) et les étapes de roadmap de type skill non optionnelles
+  (catalog/categories.json).
+  Use when an edit is refused, before a significant action, or to know which skill to load.
+  Triggers on: "le gate bloque", "missing skill", requiredSkills, enforcement, NOVAHIZ_GATE,
+  "pourquoi mon edition est refusee".
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-gate : lire et satisfaire le gate
+
+Le gate vérifie une seule chose : les skills requises par le contexte sont-elles chargées ? Si non, il refuse l'édition.
+
+## Les deux sources d'exigence
+
+**Les règles** (`catalog/rules.json`), évaluées sur le chemin, la classe de fichier, la catégorie active et le contenu :
+
+| Règle | Se déclenche sur | Exige |
+|---|---|---|
+| R1-docs | texte, data, config | `humanizer` |
+| R1-code-prose | code ou design dont le contenu porte de la prose | `humanizer` |
+| R2-style | css, scss, sass, less, styl, html, vue, svelte, astro | `impeccable` |
+| R2-styled-component | jsx, tsx dont le contenu touche au style | `impeccable` |
+| R2-design-target | catégorie `design-ui` sur un fichier de design | `impeccable` |
+| R3-supabase | chemin `**/supabase/**` ou `**/migrations/**`, catégorie `database-supabase` | `supabase`, `supabase-postgres-best-practices` |
+
+**Les étapes de roadmap** : seules celles `kind: "skill"` et non `optional` bloquent. Les étapes `edit`, `verify` et `advisory` apparaissent dans `requiredSkills` mais ne refusent rien.
+
+## Sémantique exacte (gate.ts:229-236)
+
+```
+si l'index est disponible ET que la skill n'y figure pas
+  -> unmatchedRequired : non appliquée, et signalée nulle part
+sinon
+  -> effective : appliquée
+```
+
+Trois conséquences à connaître :
+
+1. **Skill absente de l'index** (`build/installed-skills.json`, écrit au dernier `sync`) : elle cesse d'être exigée, en silence. Aucun message ne le dit.
+2. **Skill présente dans l'index mais absente du disque** : elle reste exigée et rien ne peut la charger. Blocage définitif jusqu'au prochain `sync`.
+3. **Index illisible** : tout est exigé. Le gate devient plus strict, jamais plus laxiste.
+
+## Lire un blocage
+
+```
+{
+  "allow": false,
+  "missingSkills": ["humanizer"],
+  "indexMissing": false,
+  "targets": [{
+    "path": "...", "fileClass": "text", "roadmap": "feature",
+    "matchedRules": ["R1-docs"], "reasons": ["missing skill: humanizer"]
+  }]
+}
+```
+
+`missingSkills` est la liste à charger. `matchedRules` dit pourquoi. `roadmap` dit quelle catégorie a imposé le reste.
+
+## Débloquer
+
+Charge chaque skill manquante avec `skill({name})`. Le chargement est enregistré dans la session, le gate repasse.
+
+Une skill requise devenue introuvable n'est pas un obstacle à contourner : c'est le signal que l'index et le disque ont divergé. Un `sync` les remet d'accord.
+
+## Contournement
+
+Le seul prévu par le code : `NOVAHIZ_GATE=off` (ou `0`, `false`, `no`, `disabled`) dans l'environnement, lu via `gate.envEscape`. L'utilisateur peut aussi demander explicitement de passer outre. Dans les deux cas, la dérogation se dit à voix haute et se rattrape après coup. Le jugement de l'agent n'est pas un contournement valide.
+
+## Anti-patterns
+
+- Charger une skill sans rapport pour faire taire le message.
+- Éditer en contournant, puis régulariser plus tard.
+- Supposer que l'édition est passée sans regarder `allow`.
+- Oublier `sync` après avoir ajouté ou renommé une skill.
+- Croire qu'une étape `edit` ou `verify` bloque : seul `kind: "skill"` bloque.

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

@@ -0,0 +1,80 @@
+---
+name: novahiz-implement
+description: |
+  Étape 5 du pipeline Novahiz : écrire le code par incréments qui laissent le système
+  utilisable. Cycle implémenter, tester, vérifier, commit, tranche suivante.
+  Règles de simplicité, de discipline de périmètre, de défauts sûrs et de réversibilité.
+  Use when writing or changing code for an approved task.
+  Triggers on: implémenter, coder, écrire le code, ajouter l'endpoint, construire le
+  composant, appliquer le changement, faire passer le test.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-implement : écrire par incréments propres
+
+**Étape 5 sur 6** du pipeline. Tu écris ce que la tâche demande, ni plus ni moins.
+
+Étape précédente : `novahiz-analyse`. Étape suivante : `novahiz-converge`.
+
+## Cycle d'incrément
+
+```
+implémenter -> tester -> vérifier -> commit -> tranche suivante
+```
+
+Tu ne repars pas de zéro à chaque tranche. Chaque tranche laisse un système qui compile et dont les tests passent.
+
+## Ouvre et ferme l'étape
+
+```
+novahiz_task action="start" id="<todo>"
+... travail ...
+novahiz_task action="done"  id="<todo>" proof="<commande et résultat>"
+```
+
+`done` sur une étape de nature `verify` exige la preuve. Sans preuve, l'étape reste ouverte.
+
+## Choisir la première tranche
+
+- Verticale par défaut : elle traverse les couches pour être observable de bout en bout.
+- Contrat d'abord : fige types et interfaces, puis les deux côtés avancent en parallèle.
+- Risque d'abord : prouve le morceau dont la réussite est la moins certaine.
+
+## Le gate va se déclencher
+
+Écrire du code fait tomber les règles : R1-code-prose exige `humanizer` dès que le contenu porte de la prose (commentaires, messages, libellés), R2 exige `impeccable` dès qu'un fichier de style est touché. Charge-les avant d'écrire, pas après le refus.
+
+## Règles d'écriture
+
+**Simplicité.** Quelle est la chose la plus simple qui puisse marcher ? Moins de lignes. Une abstraction doit gagner sa complexité. Trois lignes similaires valent mieux qu'une abstraction prématurée. Écris la version naïve et évidemment correcte, puis optimise après preuve par les tests.
+
+**Périmètre.** Ne touche que ce que la tâche exige. Pas de nettoyage du code adjacent, pas de refactor d'imports d'autres fichiers, pas de suppression d'un commentaire non compris, pas de fonctionnalité hors périmètre. Ce que tu vois sans y toucher se note « vu mais non touché » et devient une proposition : `novahiz_task action="insert"`, jamais une modification surprise.
+
+**Une chose à la fois.** Pas de composant plus refactor plus configuration de build dans le même pas.
+
+**Garder compilable.** Le build et les tests existants passent après chaque incrément.
+
+**Défauts sûrs.** Nouveau comportement en opt-in, valeur conservatrice. Une option absente vaut faux.
+
+**Réversible.** Changements additifs, modifications minimales, migration avec retour arrière, et jamais supprimer puis remplacer dans le même commit.
+
+## Confirmer avant l'irréversible
+
+Une action qui détruit de la donnée, casse une compatibilité ou ne se défait pas passe par l'outil `question` du harness avant d'être lancée. Les options sont concrètes : lancer, sauvegarder d'abord, renoncer. Une migration sans retour arrière et une suppression de données en font partie. Le feu vert se demande, il ne se suppose pas.
+
+## Ne rien inventer
+
+N'écris pas d'API, de fonction ou d'import dont tu n'as pas vérifié l'existence. Trois recours réels : le code lui-même, la documentation de la version installée via `context7`, et la skill `zero-hallucination-coder`. Un symbole supposé devient une dette immédiate.
+
+## Quand la preuve est rouge
+
+Corrige, ou bloque l'étape avec `novahiz_task action="block"` et une raison. Tu ne masques pas un test en le désactivant, et tu ne contournes pas un échec par un bloc d'erreur silencieux.
+
+## Catégories concernées
+
+L'étape d'implémentation apparaît dans `code`, `debug`, `test`, `design-ui`, `database-supabase`, `devops` et `data`.
+
+## Sortie
+
+Chaque incrément produit les fichiers modifiés, la preuve exécutée et son résultat. Tu passes à `novahiz-converge` quand les tranches sont terminées.