novahiz 0.1.0

package/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/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/skills/novahiz-analyse/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: novahiz-analyse
+description: |
+  Step 4 of the Novahiz pipeline: understand the affected code before modifying it.
+  Five ordered phases (reconnaissance, architecture, quality, operations, synthesis),
+  backed by the code map when available. Each claim cites a real file path;
+  what could not be determined is stated explicitly.
+  Use before touching unfamiliar code, before a refactor or a migration, or to locate a bug.
+  Triggers on: "understand this code", "where is", "who calls", codebase map,
+  impact analysis, root cause, entry point.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-analyse: understand before modifying
+
+**Step 4 of 6** in the pipeline. Analysis covers what the task requires, never the entire repo. Depth over breadth.
+
+Previous step: `novahiz-task`. Next step: `novahiz-implement`.
+
+## Use the code map
+
+Before reading at random: the `code-understand` skill builds a ranked, cited map, and the `narsil` server exposes call graphs, symbols, references, and imports. A "who calls this" question is resolved with the tool, not by guessing.
+
+## Phase 1: reconnaissance
+
+- Directory tree to two or three levels.
+- Manifests first: package.json, Cargo.toml, go.mod, pyproject.toml, pom.xml, build.gradle, Gemfile, csproj, Podfile, Package.swift.
+- Build and CI: Makefile, Dockerfile, docker-compose, workflows, turbo.json, nx.json.
+- Configs: tsconfig, eslint, environment template, bundler, editorconfig.
+- Docs: README, CONTRIBUTING, ARCHITECTURE, docs directory.
+- Languages, frameworks, monorepo presence.
+
+## Phase 2: architecture
+
+- Entry points: main, index, server, routes, CLI, AppDelegate, activities.
+- Trace up to five critical paths end-to-end: route to controller to service to data to response.
+- Dependency graph between modules.
+- Dominant pattern: monolith, microservices, event-driven, hexagonal, MVC, CQRS.
+- Data layer: schemas, migrations, ORM, models, cache.
+- API surface: REST, GraphQL, gRPC, WebSocket, IPC, contracts, authentication.
+
+## Phase 3: quality
+
+- Tests: structure, frameworks, unit, integration, end-to-end, fixtures, mocks.
+- Error handling and logging.
+- Typing and runtime validation.
+- Security posture: authentication, authorization, secrets, sanitization, dependency vulnerabilities.
+- Pattern consistency, naming, duplication.
+
+## Phase 4: operations
+
+Build, CI/CD, deployment model, observability, environment management.
+
+## Phase 5: synthesis
+
+Write the synthesis after the preceding phases, never before. Each claim cites a real file path. State what you could not determine. An ASCII diagram helps for architecture.
+
+Destination: the project's documentation directory if one exists, otherwise the execution ledger. Do not invent `docs/analysis/` in a project with no such convention.
+
+## Six categories require this step
+
+`code`, `debug`, `review`, `database-supabase`, `devops`, and `data`.
+
+## Rules
+
+- Read before writing.
+- Ignore generated, vendored, and boilerplate code.
+- Do not re-document the entire repo for every task: target the useful scope.
+- An observation without a file path is worthless.
+
+## Exit
+
+The files and symbols that carry the logic, data paths, extension points, and an explicit list of remaining unknowns. This output feeds `novahiz-implement`.

package/skills/novahiz-audit/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: novahiz-audit
+description: |
+  End-of-session audit for Novahiz. CATEGORY-AWARE: only checks rules for
+  categories actually encountered. Relies on verifiable state (execution ledger,
+  gate journal, loaded skills, session diff) and never on agent memory.
+  Use at the END of a session, or when the user says "audit" or "verify".
+  Triggers on: "audit", "verify", end of session, compliance check, what we forgot.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-audit: end-of-session check
+
+Audit from verifiable facts. A memory-check has no value.
+
+## The 14 real categories
+
+code, debug, review, audit, test, research, browser, design-ui, database-supabase, docs-writing, planning, devops, data, general.
+
+`general` is the fallback category. There is no `trivial` category in the catalog.
+
+## What is actually checked
+
+| Check | Proof source | Applies to |
+|---|---|---|
+| Plan and ledger open | `novahiz_task status` or `todoread` | all except research |
+| Category steps traversed | `novahiz_roadmap --category X` then `novahiz_step` | all except research and general |
+| Required skills loaded | gate journal, `enforcement_log` table | all |
+| humanizer applied on prose | R1 rules triggered, or skill loaded | docs-writing, code, audit, planning, design-ui |
+| impeccable applied to style | R2 rules triggered, or skill loaded | design-ui |
+| Code review done | `review` step in roadmap, `code-reviewer` skill | code, review, debug |
+| Security scan | `scan` step, `security-guidance` skill | audit |
+| Proof on verification steps | `novahiz_task` rejects `done` without `proof` | all |
+| Memory up to date | `MEMORY.md` plus vault page, via `novahiz-memory` | all except research |
+| No simulation | claims cross-checked with real outputs | all |
+
+## Method
+
+1. Retrieve the primary category and encountered categories.
+2. For each applicable check, look for proof. No proof, no pass.
+3. Mark `compliant`, `missing`, or `not applicable`.
+4. Score: compliant over applicable, as percentage. Below 70%, propose precise fixes. At 90% and above, conclude "session compliant".
+
+## Exit
+
+A short report in the conversation:
+
+```
+## Session audit
+Categories: code, test
+| Check | Status | Proof |
+|---|---|---|
+| Ledger | compliant | 6 steps, 1 blocked |
+| humanizer | compliant | loaded before writing |
+| Code review | missing | review step not executed |
+Score: 67%
+
+## To fix
+- Run code-reviewer on modified files
+
+## To remember
+- ...
+```
+
+## Pitfalls
+
+- Check a rule without proof.
+- Invent a compliance log, session file, or validation script: they do not exist in this system.
+- Audit categories that were not encountered.
+- Confuse absence of proof with compliance.
+
+## Next
+
+What can be fixed is fixed now: reload humanizer, run the review, write the memory. The rest is logged for the next session.

package/skills/novahiz-clarify/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: novahiz-clarify
+description: |
+  Step 2 of the Novahiz pipeline: remove ambiguities before locking the plan.
+  Two combined mechanisms: an ambiguity sweep across risk families, and batches of
+  questions ordered by dependencies (the frontier), each question numbered with a
+  recommended answer.
+  Use when the request is vague, underspecified, contradictory, or when several plausible
+  readings lead to different work.
+  Triggers on: "clarify", ambiguous, "not sure yet", fuzzy scope, missing requirements,
+  "two possible readings", open questions.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-clarify: remove ambiguities
+
+**Step 2 of 6** in the pipeline. You ask before the plan is locked.
+
+Previous step: `novahiz-plan`. Next step: `novahiz-task`.
+
+## Entry
+
+Ambiguous, contradictory, or broad enough that two readings produce two different works.
+
+## A. Sweep by families
+
+Run the request through ten risk families. Mark each `clear`, `partial`, or `missing`.
+
+1. Behavior and functional scope
+2. Domain and data model
+3. Flows and interactions
+4. Non-functional qualities: performance, load, availability, security, accessibility, internationalization
+5. External integrations and dependencies
+6. Edge cases and failure handling
+7. Constraints and tradeoffs
+8. Terminology and consistency
+9. Completion signals: what proves it is done
+10. Fill zones and placeholder values
+
+Any family left `missing` on scope, data, splitting, tests, UX, or operations becomes a question. The rest waits.
+
+## B. Frontier batches, posed in the interface
+
+Model decisions as a tree: each decision opens the ones that depend on it.
+
+The **frontier** is the set of decisions whose prerequisites are already resolved, so they can be asked now without guessing. A batch is **one call** to the `question` tool, with one entry per frontier decision.
+
+```
+question({
+  questions: [
+    {
+      header: "<short title, 30 chars max>",
+      question: "<the decision, one sentence, with its stakes>",
+      options: [
+        { label: "<recommended option> (Recommended)", description: "<concrete consequence>" },
+        { label: "<option>", description: "<concrete consequence>" },
+        { label: "<option>", description: "<concrete consequence>" }
+      ]
+    }
+  ]
+})
+```
+
+Batch rules:
+
+- **No prose questions in chat.** The interactive table is the only channel. Chat carries context, never the question list.
+- Five questions maximum, ranked by cross-impact with uncertainty.
+- Two to five options per question, mutually exclusive, each described by what it implies.
+- The recommended option goes first and carries the `(Recommended)` suffix. The interface adds a free-response option automatically: do not add "Other" or a catch-all.
+- `multiple: true` only when multiple answers can coexist.
+- A question that depends on another still-open question belongs to a later batch.
+- Each answer moves the frontier: recalculate it, then issue another call.
+- Wait for the call return before continuing.
+
+If the current harness does not expose a `question` tool, ask **one** question per turn, recommended option first, and wait. Never dump a list of questions at once.
+
+Answer everything yourself that two read files can settle.
+
+## Duty of critique
+
+If the request is inconsistent, ambiguous, risky, or suboptimal, say so and propose an alternative. Staying silent leaves an error in place.
+
+## Exit
+
+A short list: open families, questions asked, answers received, decisions locked. Move to `novahiz-task` when the remaining open items no longer change architecture, data, tasks, tests, UX, or operations.
+
+## Pitfalls
+
+- Ask a comfort question about what is already stated in the request.
+- Ask six questions when the frontier allows five.
+- Ask about style or execution detail.
+- Chain batches without re-reading answers to recalculate the frontier.
+- Write questions in prose instead of opening the interactive table.

package/skills/novahiz-converge/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: novahiz-converge
+description: |
+  Step 6 of the Novahiz pipeline: close the gap between intent and code.
+  Build the intent inventory (request, plan, acceptance criteria, ledger steps,
+  project principles), evaluate the current code state, classify each element as
+  satisfied, partial, or unsatisfied, and add remainders as traced steps.
+  Add-only: rewrite nothing, delete no step, do not touch the code.
+  Use at the end of an implementation, before declaring work done.
+  Triggers on: "is it done?", verify the feature, convergence, gap analysis,
+  "what remains", closure.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-converge: close the gap
+
+**Step 6 of 6** in the pipeline. It runs after implementation, never during.
+
+Previous step: `novahiz-implement`.
+
+## Do not confuse with audit
+
+`novahiz-converge` measures the gap between what was requested and what the code does. `novahiz-audit` measures session compliance with rules. The first is about work; the second is about method.
+
+## Intent source
+
+Intent comes from artifacts, not from your memory:
+
+- the original request,
+- the plan,
+- task acceptance criteria,
+- the execution ledger: `novahiz_task action="status"` and `action="signals"`,
+- project principles, starting with `AGENTS.md`.
+
+Build the inventory: every identified and traceable element.
+
+## Evaluation
+
+Look at the current state of the code. This is not a diff: no git, no branch, no history. You evaluate what the code does now.
+
+Classify each element:
+
+- **satisfied**: the code does what is requested, and the proof shows it.
+- **partial**: part holds, the rest is missing or unproven.
+- **unsatisfied**: nothing covers the element.
+
+A closed step without proof does not count as satisfied, even if the ledger says `done`.
+
+## Add-only writing
+
+- The only permitted writing is adding remainders to the ledger, each becoming a traced step: `novahiz_task action="insert"`.
+- You modify neither the plan, nor the criteria, nor existing steps.
+- You rename, renumber, reorder, and delete no step.
+- Acceptance of open remainders is asked through the `question` tool: accept the remainders, handle them now, or trace them for later. A remainder not explicitly accepted keeps the closure open.
+- You do not touch application code.
+
+If everything is satisfied, you touch nothing and report a clean result. An empty report is not a clean result.
+
+## Severity
+
+A violation of a MUST principle in `AGENTS.md` is the highest level and produces a remediation step. If principles are absent, state it and continue.
+
+## Closure
+
+Report three lists: what is satisfied and proven, what remains open, what could not be evaluated and why. Work is finished when the open list is empty, or when the user explicitly accepts the remainders.
+
+## Categories involved
+
+The convergence step appears in `code`, `debug`, `test`, `audit`, `browser`, `design-ui`, `database-supabase`, `docs-writing`, `planning`, `devops`, and `data`.
+
+## Pitfalls
+
+- Declare as satisfied what was never executed.
+- Confuse "the step is checked" with "the behavior exists".
+- Rewrite the plan to match the obtained result.

package/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/skills/novahiz-implement/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: novahiz-implement
+description: |
+  Step 5 of the Novahiz pipeline: write code in increments that leave the system usable.
+  Cycle: implement, test, verify, commit, next slice.
+  Rules of simplicity, scope discipline, safe defaults, and reversibility.
+  Use when writing or changing code for an approved task.
+  Triggers on: implement, code, write the code, add the endpoint, build the
+  component, apply the change, make the test pass.
+license: MIT
+compatibility: opencode
+---
+
+# novahiz-implement: write in clean increments
+
+**Step 5 of 6** in the pipeline. You write what the task asks, no more, no less.
+
+Previous step: `novahiz-analyse`. Next step: `novahiz-converge`.
+
+## Increment cycle
+
+```
+implement -> test -> verify -> commit -> next slice
+```
+
+Do not start from scratch at each slice. Each slice leaves a system that compiles and whose tests pass.
+
+## Open and close the step
+
+```
+novahiz_task action="start" id="<todo>"
+... work ...
+novahiz_task action="done"  id="<todo>" proof="<command and result>"
+```
+
+`done` on a step of kind `verify` requires proof. Without proof, the step stays open.
+
+## Choose the first slice
+
+- Vertical by default: it crosses layers to be observable end-to-end.
+- Contract-first: freeze types and interfaces, then both sides advance in parallel.
+- Risk-first: prove the least certain piece.
+
+## The gate will trigger
+
+Writing code fires rules: R1-code-prose requires `humanizer` when the content carries prose (comments, messages, labels); R2 requires `impeccable` when a style file is touched. Load them before writing, not after the refusal.
+
+## Writing rules
+
+**Simplicity.** What is the simplest thing that could work? Fewer lines. An abstraction must earn its complexity. Three similar lines are better than a premature abstraction. Write the naive and obviously correct version, then optimize after proof by tests.
+
+**Scope.** Touch only what the task requires. No adjacent code cleanup, no import refactoring of other files, no deletion of an misunderstood comment, no out-of-scope feature. What you see without touching it is noted "seen but untouched" and becomes a proposal: `novahiz_task action="insert"`, never a surprise modification.
+
+**One thing at a time.** No component refactor plus build config in the same step.
+
+**Keep compilable.** The build and existing tests pass after each increment.
+
+**Safe defaults.** New behavior is opt-in, conservative value. An absent option defaults to false.
+
+**Reversible.** Additive changes, minimal modifications, rollback-capable migration, and never delete-then-replace in the same commit.
+
+## Confirm before irreversible
+
+An action that destroys data, breaks compatibility, or cannot be undone goes through the `question` tool before being launched. Options are concrete: proceed, back up first, abort. A no-rollback migration and a data deletion are in this category. The green light is asked, never assumed.
+
+## Never invent
+
+Do not write an API, function, or import whose existence you have not verified. Three real sources: the code itself, the installed version's documentation via `context7`, and the `zero-hallucination-coder` skill. A presumed symbol becomes immediate debt.
+
+## When proof is red
+
+Fix it, or block the step with `novahiz_task action="block"` and a reason. Do not mask a test by disabling it, and do not bypass a failure with a silent error block.
+
+## Categories involved
+
+The implementation step appears in `code`, `debug`, `test`, `design-ui`, `database-supabase`, `devops`, and `data`.
+
+## Exit
+
+Each increment produces the modified files, the executed proof, and its result. Move to `novahiz-converge` when the slices are complete.