novahiz 0.3.7 → 0.3.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +211 -209
- package/adapters/opencode/agent/novahiz.md +1 -1
- package/adapters/opencode/novahiz.ts +7 -7
- package/dist/commands/graft.js +7 -3
- package/dist/commands/hook.js +10 -3
- package/dist/commands/inspect.js +44 -7
- package/dist/commands/task.js +15 -2
- package/dist/db.js +5 -1
- package/dist/gate-repair.js +4 -4
- package/dist/gate.js +21 -2
- package/dist/ledger.js +25 -6
- package/docs/PROVIDERS.md +6 -4
- package/install/bootstrap.mjs +21 -5
- package/install/install.mjs +1 -1
- package/install/lib.mjs +37 -5
- package/mcp/novahiz-tools/index.mjs +37 -28
- package/package.json +1 -1
- package/skills/gate/SKILL.md +4 -4
- package/src/commands/graft.ts +7 -3
- package/src/commands/hook.ts +10 -3
- package/src/commands/inspect.ts +46 -7
- package/src/commands/task.ts +13 -2
- package/src/db.ts +5 -1
- package/src/gate-repair.ts +4 -4
- package/src/gate.ts +21 -2
- package/src/ledger.ts +31 -9
package/README.md
CHANGED
|
@@ -1,392 +1,394 @@
|
|
|
1
|
-
# Novahiz:
|
|
1
|
+
# Novahiz : la boîte à outils de gouvernance des agents
|
|
2
2
|
|
|
3
|
-
> **
|
|
3
|
+
> **Couche d'application sans dépendance pour les agents de code IA** — classe les prompts, attribue des roadmaps d'exécution, bloque les éditions non sûres tant que les bonnes skills ne sont pas chargées, et persiste les décisions d'une session à l'autre — tout cela de façon déterministe, sans appel de modèle.
|
|
4
4
|
|
|
5
|
-
17
|
|
5
|
+
17 catégories, 96 skills, 11 gate rules, 7 MCP providers — tout déterministe, tout local, tout JSON.
|
|
6
6
|
|
|
7
7
|
```
|
|
8
|
-
|
|
9
|
-
│
|
|
10
|
-
│
|
|
11
|
-
│
|
|
12
|
-
│
|
|
13
|
-
│ auth
|
|
14
|
-
│
|
|
15
|
-
│
|
|
16
|
-
|
|
8
|
+
┌──────────────────────────────────────────────────────────────────────────┐
|
|
9
|
+
│ │
|
|
10
|
+
│ PROMPT UTIL. ──▶ CLASSIF. ──▶ GATE ──▶ SORTIE SÛRE │
|
|
11
|
+
│ │
|
|
12
|
+
│ « Corrige le 3 catégories 2 skills Édition bloquée │
|
|
13
|
+
│ bug d'auth » détectées manquantes tant que les │
|
|
14
|
+
│ exigées skills ne sont pas chargées │
|
|
15
|
+
│ │
|
|
16
|
+
└──────────────────────────────────────────────────────────────────────────┘
|
|
17
17
|
```
|
|
18
18
|
|
|
19
19
|
---
|
|
20
20
|
|
|
21
|
-
##
|
|
21
|
+
## Comment se déroule une session
|
|
22
22
|
|
|
23
|
-
1. **
|
|
24
|
-
2. **Roadmap** —
|
|
25
|
-
3. **Gate
|
|
26
|
-
4. **
|
|
27
|
-
5. **
|
|
28
|
-
6. **
|
|
23
|
+
1. **Classifier** — chaque prompt est noté contre 17 catégories (mots-clés déterministes, aucun appel de modèle). Le résultat porte jusqu'à trois catégories, une principale, un niveau de confiance, un **tier** (`trivial` / `lite` / `full`), et les skills que le gate attendra.
|
|
24
|
+
2. **Roadmap** — la catégorie principale sélectionne une roadmap ordonnée, et le plugin injecte sa checklist dans la session : l'agent suit plan → clarify → tasks → analyse → implement → converge au lieu d'improviser un ordre.
|
|
25
|
+
3. **Gate sur chaque écriture** — les appels `edit` / `write` / `patch` / `bash` / `shell` sont vérifiés selon la classe de fichier, les règles actives, les skills de roadmap et le contenu (tokens de placeholder) : **allow** ou **block**, en local, sans appel de modèle dans le chemin de décision.
|
|
26
|
+
4. **Gate reload, pas une impasse** — un blocage nomme exactement les skills manquantes et la règle de retry : charger chacune, rejouer l'appel une seule fois. Une skill absente de l'index installé est signalée, jamais appliquée. `NOVAHIZ_GATE=off` est la seule soupape, et elle est bruyante.
|
|
27
|
+
5. **Vérifier et converger** — les roadmaps se terminent par des étapes `verify` qui exigent une preuve ; `novahiz-converge` note le code face à la demande d'origine et transforme chaque reste en étape traçable du ledger.
|
|
28
|
+
6. **Persister** — décisions, causes racines et prochaines étapes survivent à la session via la couche mémoire (ci-dessous), et `novahiz report` boucle la boucle avec un résumé de session.
|
|
29
29
|
|
|
30
30
|
```
|
|
31
|
-
PROMPT ─▶
|
|
32
|
-
|
|
33
|
-
|
|
31
|
+
PROMPT ─▶ CLASSIFIER ─▶ ROADMAP ─▶ travail ─▶ GATE ─▶ allow ─▶ VERIFY ─▶ MEMORY
|
|
32
|
+
│ ▲ │
|
|
33
|
+
└─ tier, skills ──────│ └─ block : charger les skills nommées, retry une fois
|
|
34
34
|
```
|
|
35
35
|
|
|
36
|
-
**17
|
|
36
|
+
**17 catégories**, **96 skills**, **11 gate rules**, **7 MCP providers** — tout déterministe, tout local, tout JSON.
|
|
37
37
|
|
|
38
38
|
---
|
|
39
39
|
|
|
40
|
-
##
|
|
40
|
+
## Démarrage rapide
|
|
41
41
|
|
|
42
|
-
### Option 1 —
|
|
42
|
+
### Option 1 — En une ligne (recommandé)
|
|
43
43
|
|
|
44
44
|
```bash
|
|
45
45
|
npm install -g novahiz
|
|
46
46
|
novahiz-install --yes
|
|
47
47
|
```
|
|
48
48
|
|
|
49
|
-
`npm install -g novahiz`
|
|
49
|
+
`npm install -g novahiz` installe le CLI. Sur npm 11+, les scripts de lifecycle sont derrière une confirmation allow-scripts : la configuration est donc une seconde étape explicite. `novahiz-install` demande quels harnesses configurer (opencode et Claude Code quand leur config est présente, Codex aussi ; `--yes` accepte les valeurs détectées, `--harness claude` force une liste) — skills, plugin/agent, hooks, MCP servers, config. Puis vérifiez :
|
|
50
50
|
|
|
51
51
|
```bash
|
|
52
|
-
novahiz doctor #
|
|
52
|
+
novahiz doctor # Santé : 13 de base, 17 avec Claude Code, 19 avec impeccable
|
|
53
53
|
novahiz classify "fix the auth bug"
|
|
54
54
|
```
|
|
55
55
|
|
|
56
|
-
### Option 2 —
|
|
56
|
+
### Option 2 — Depuis les sources
|
|
57
57
|
|
|
58
58
|
```bash
|
|
59
59
|
git clone https://github.com/novahiz/novahiz.git
|
|
60
60
|
cd novahiz
|
|
61
|
-
npm install # `prepare`
|
|
62
|
-
node ./install/install.mjs #
|
|
61
|
+
npm install # `prepare` typecheck et build dist/
|
|
62
|
+
node ./install/install.mjs # ajouter --yes pour accepter les valeurs détectées
|
|
63
63
|
|
|
64
|
-
#
|
|
64
|
+
# Vérifier
|
|
65
65
|
node ./dist/cli.js doctor
|
|
66
66
|
```
|
|
67
67
|
|
|
68
|
-
>
|
|
68
|
+
> Nécessite **Node.js >= 22.18**. L'installeur installe automatiquement le CLI de chaque harness entièrement absent (`opencode-ai`, `@anthropic-ai/claude-code`, `@openai/codex`), sans bloquer.
|
|
69
69
|
|
|
70
70
|
---
|
|
71
71
|
|
|
72
|
-
##
|
|
72
|
+
## Le classifier
|
|
73
73
|
|
|
74
|
-
|
|
74
|
+
Chaque prompt utilisateur passe par le classifier. Il note les mots-clés contre 17 catégories et retient les meilleurs matchs.
|
|
75
75
|
|
|
76
76
|
```mermaid
|
|
77
77
|
flowchart LR
|
|
78
|
-
A[
|
|
79
|
-
B --> C{
|
|
80
|
-
C --> D[
|
|
81
|
-
D --> E[Top 3
|
|
82
|
-
E --> F[
|
|
83
|
-
F --> G[
|
|
84
|
-
F --> H[
|
|
78
|
+
A[Prompt utilisateur] --> B[Folding du texte<br/>minuscules + suppression des accents]
|
|
79
|
+
B --> C{Scoring mots-clés<br/>+1.0 par hit<br/>+1.5 bonus multi-mots}
|
|
80
|
+
C --> D[Classement par score + priorité]
|
|
81
|
+
D --> E[Top 3 des catégories]
|
|
82
|
+
E --> F[Catégorie principale<br/>détermine la roadmap]
|
|
83
|
+
F --> G[Skills requises<br/>union de toutes les catégories]
|
|
84
|
+
F --> H[Skills appliquées<br/>principale seulement — le gate bloque si absente]
|
|
85
85
|
```
|
|
86
86
|
|
|
87
|
-
**
|
|
87
|
+
**Exemple :**
|
|
88
88
|
|
|
89
|
-
| Prompt |
|
|
90
|
-
|
|
89
|
+
| Prompt | Catégorie principale | Confiance | Skills requises |
|
|
90
|
+
|--------|----------------------|-----------|-----------------|
|
|
91
91
|
| "fix the auth bug" | `debug` | 0.60 | novahiz-plan, novahiz-analyse, novahiz-implement, novahiz-converge |
|
|
92
92
|
| "add a landing page" | `design-ui` | 0.50 | novahiz-humanizer, ui-slop-remover |
|
|
93
93
|
| "create supabase migration" | `database-supabase` | 0.60 | novahiz-supabase, novahiz-postgres, novahiz-plan, novahiz-implement |
|
|
94
94
|
|
|
95
95
|
---
|
|
96
96
|
|
|
97
|
-
##
|
|
97
|
+
## Le gate
|
|
98
98
|
|
|
99
|
-
|
|
99
|
+
Le gate est le mécanisme d'application. Il inspecte chaque édition de fichier et décide : **allow** ou **block**.
|
|
100
100
|
|
|
101
101
|
```mermaid
|
|
102
102
|
flowchart TD
|
|
103
|
-
A[
|
|
104
|
-
B --> C{
|
|
103
|
+
A[Appel outil : edit / write / patch] --> B[Détection de la classe de fichier]
|
|
104
|
+
B --> C{Correspondance des règles}
|
|
105
105
|
|
|
106
|
-
C --> D[R13:
|
|
107
|
-
C --> F[R3:
|
|
108
|
-
C --> G[R4:
|
|
109
|
-
C --> H[R6:
|
|
106
|
+
C --> D[R13 : prompt design-ui ou fichier style ?<br/>exiger humanizer + ui-slop + ui-craft]
|
|
107
|
+
C --> F[R3 : le prompt était Supabase ?<br/>exiger novahiz-supabase + postgres]
|
|
108
|
+
C --> G[R4 : le prompt était navigateur ?<br/>exiger novahiz-browser]
|
|
109
|
+
C --> H[R6 : prompt de workflow ?<br/>exiger plan/clarify/analyse/implement/converge]
|
|
110
110
|
|
|
111
|
-
D --> I{
|
|
111
|
+
D --> I{Application de la roadmap}
|
|
112
112
|
F --> I
|
|
113
113
|
G --> I
|
|
114
114
|
H --> I
|
|
115
115
|
|
|
116
|
-
I --> J{
|
|
116
|
+
I --> J{Détection de placeholder<br/>tokens TODO / FIXME / placeholder}
|
|
117
117
|
|
|
118
|
-
J --> K["
|
|
119
|
-
J --> L["
|
|
118
|
+
J --> K["Vérif. des skills installées<br/>(manquante → signalée, non bloquée)"]
|
|
119
|
+
J --> L["Vérif. des skills chargées<br/>(manquante → BLOQUÉE)"]
|
|
120
120
|
|
|
121
|
-
K --> M{
|
|
121
|
+
K --> M{Toutes chargées ?}
|
|
122
122
|
L --> M
|
|
123
123
|
|
|
124
|
-
M -->|
|
|
125
|
-
M -->|
|
|
124
|
+
M -->|Oui| N[✅ Édition autorisée]
|
|
125
|
+
M -->|Non| O[❌ Édition bloquée<br/>liste des skills manquantes]
|
|
126
126
|
```
|
|
127
127
|
|
|
128
|
-
###
|
|
128
|
+
### Classes de fichiers
|
|
129
129
|
|
|
130
|
-
|
|
|
131
|
-
|
|
130
|
+
| Classe | Extensions |
|
|
131
|
+
|--------|-----------|
|
|
132
132
|
| `code` | `.ts`, `.tsx`, `.js`, `.jsx`, `.py`, `.go`, `.rs`, `.java`, `.kt`, `.swift`, `.php`, `.dart`, `.rb` |
|
|
133
133
|
| `design` | `.css`, `.scss`, `.html`, `.vue`, `.svelte`, `.astro` |
|
|
134
134
|
| `text` | `.md`, `.txt`, `.rst` |
|
|
135
135
|
| `config` | `.json`, `.yaml`, `.yml`, `.toml` |
|
|
136
136
|
| `data` | `.csv`, `.sql`, `.db` |
|
|
137
137
|
|
|
138
|
-
###
|
|
138
|
+
### Règles du gate
|
|
139
139
|
|
|
140
|
-
|
|
|
141
|
-
|
|
142
|
-
| R3-supabase |
|
|
143
|
-
| R4-playwright |
|
|
144
|
-
| R6-Novahiz |
|
|
145
|
-
| R7-assessment |
|
|
146
|
-
| R8-docs |
|
|
147
|
-
| R9-code-review |
|
|
148
|
-
| R10-security |
|
|
149
|
-
| R11-accessibility |
|
|
150
|
-
| R12-web-extract |
|
|
151
|
-
| R13-design-craft |
|
|
152
|
-
| R14-impeccable |
|
|
140
|
+
| Règle | Se déclenche sur | Exige |
|
|
141
|
+
|-------|------------------|-------|
|
|
142
|
+
| R3-supabase | Un chemin Supabase ou un prompt Supabase | novahiz-supabase, novahiz-postgres |
|
|
143
|
+
| R4-playwright | Une catégorie prompt navigateur, ou un chemin de test navigateur (`**/*.spec.ts`, `**/e2e/**`, `**/playwright/**`, …) | novahiz-browser |
|
|
144
|
+
| R6-Novahiz | Un prompt dans une catégorie de workflow | novahiz-plan, -clarify, -analyse, -implement, -converge |
|
|
145
|
+
| R7-assessment | Un prompt d'assessment | novahiz-assess-intake, -research, -define, -shape, -decide |
|
|
146
|
+
| R8-docs | Une édition sous `novahiz-docs/**/*.md` | novahiz-docs |
|
|
147
|
+
| R9-code-review | Un prompt de review ou un fichier de code en review | novahiz-code-review |
|
|
148
|
+
| R10-security | Un prompt d'audit ou de sécurité | novahiz-security |
|
|
149
|
+
| R11-accessibility | Un prompt design-ui ou audit | novahiz-wcag-audit |
|
|
150
|
+
| R12-web-extract | Un prompt de recherche | novahiz-web-extract |
|
|
151
|
+
| R13-design-craft | Un prompt design-ui ou un fichier style (css/scss/less/html) | novahiz-humanizer, ui-slop-remover, ui-craft-rules |
|
|
152
|
+
| R14-impeccable | Un prompt design-ui ou un fichier style (css/scss/less/html) | impeccable |
|
|
153
153
|
|
|
154
|
-
`novahiz-humanizer`
|
|
154
|
+
`novahiz-humanizer` et `ui-slop-remover` ne sont exigées que sur les tâches de design frontend (R13) ; `impeccable` se charge de la même façon (R14) pour garder les playbooks shape, critique, audit, harden et polish accessibles, et la roadmap design-ui porte une étape de vérification `impeccable detect` déterministe avant ship. `novahiz init` et `novahiz doctor` affichent les fichiers de contexte `PRODUCT.md` / `DESIGN.md` d'impeccable en lignes advisory.
|
|
155
155
|
|
|
156
|
-
###
|
|
156
|
+
### Gate reload
|
|
157
157
|
|
|
158
|
-
|
|
158
|
+
Un blocage n'est jamais une impasse. Le refus embarque une recette GATE RELOAD : charger chaque skill nommée via le loader, puis rejouer l'appel exact une fois — aucun outil alternatif, aucune écriture shell, aucun contournement d'édition. Si les mêmes skills sont de nouveau signalées manquantes, le chargement n'a pas été enregistré : exécuter `novahiz doctor`, signaler honnêtement, et s'arrêter. La seule dérogation sanctionnée est `NOVAHIZ_GATE=off` (voir Configuration), déclarée à voix haute.
|
|
159
159
|
|
|
160
|
-
|
|
160
|
+
Une skill requise absente de l'index installé n'est jamais appliquée silencieusement : le gate ajoute `required skill not in index, not enforced — run novahiz sync to realign` à ses raisons au lieu de bloquer pour toujours. Un index illisible rend le gate plus strict, jamais plus laxiste.
|
|
161
161
|
|
|
162
162
|
---
|
|
163
163
|
|
|
164
164
|
## Roadmaps
|
|
165
165
|
|
|
166
|
-
|
|
166
|
+
Chaque catégorie possède une roadmap d'exécution ordonnée. Le gate applique les étapes `skill` non optionnelles.
|
|
167
167
|
|
|
168
|
-
###
|
|
168
|
+
### Le pipeline en six étapes
|
|
169
169
|
|
|
170
|
-
|
|
170
|
+
Huit catégories (`code`, `debug`, `browser`, `design-ui`, `database-supabase`, `planning`, `devops`, `data`) partagent un pipeline — et les étapes 1 à 4 n'écrivent aucun fichier d'application : elles produisent un plan et des décisions :
|
|
171
171
|
|
|
172
|
-
| # |
|
|
173
|
-
|
|
174
|
-
| 1 | Plan | `novahiz-plan` | direction,
|
|
175
|
-
| 2 | Clarify | `novahiz-clarify` |
|
|
176
|
-
| 3 | Tasks | `novahiz-task` |
|
|
177
|
-
| 4 | Analyse | `novahiz-analyse` |
|
|
178
|
-
| 5 | Implement | `novahiz-implement` |
|
|
179
|
-
| 6 | Converge | `novahiz-converge` |
|
|
172
|
+
| # | Étape | Skill | Produit |
|
|
173
|
+
|---|-------|-------|---------|
|
|
174
|
+
| 1 | Plan | `novahiz-plan` | direction, périmètre, ordre des dépendances, stratégie de découpe, risques |
|
|
175
|
+
| 2 | Clarify | `novahiz-clarify` | les questions ouvertes, répondues, et les décisions qu'elles figent |
|
|
176
|
+
| 3 | Tasks | `novahiz-task` | des tâches atomiques, chacune avec critères d'acceptation et preuve |
|
|
177
|
+
| 4 | Analyse | `novahiz-analyse` | les fichiers et symboles qui portent la logique, et les inconnues |
|
|
178
|
+
| 5 | Implement | `novahiz-implement` | des incréments qui laissent le système fonctionnel |
|
|
179
|
+
| 6 | Converge | `novahiz-converge` | l'écart entre intention et code, en tâches restantes traçables |
|
|
180
180
|
|
|
181
|
-
Clarify
|
|
181
|
+
Clarify renvoie le travail au plan quand une réponse change l'architecture ; converge le renvoie aux tâches quand il trouve un écart. `flutter` et `expo` gardent les six mêmes étapes et insèrent leurs skills qualité autour d'implement. Le **tier** du classifier filtre la suite : `trivial` n'exécute presque rien, `lite` garde implement et converge, `full` parcourt toute la roadmap. Référence complète : [docs/ROADMAPS.md](docs/ROADMAPS.md).
|
|
182
182
|
|
|
183
183
|
```mermaid
|
|
184
184
|
flowchart LR
|
|
185
|
-
subgraph "
|
|
186
|
-
A1[advisory:
|
|
185
|
+
subgraph "Fonctionnalité (code)"
|
|
186
|
+
A1[advisory: Comprendre] --> A2[skill: Plan]
|
|
187
187
|
A2 --> A3[skill: Analyse]
|
|
188
188
|
A3 --> A4[skill: Implement]
|
|
189
189
|
A4 --> A5[skill: Converge]
|
|
190
|
-
A5 --> A6[verify:
|
|
190
|
+
A5 --> A6[verify: Vérifier]
|
|
191
191
|
end
|
|
192
192
|
|
|
193
|
-
subgraph "
|
|
194
|
-
B1[advisory:
|
|
193
|
+
subgraph "Correctif (debug)"
|
|
194
|
+
B1[advisory: Reproduire] --> B2[advisory: Isoler]
|
|
195
195
|
B2 --> B3[skill: Plan]
|
|
196
196
|
B3 --> B4[skill: Analyse]
|
|
197
197
|
B4 --> B5[skill: Implement]
|
|
198
198
|
B5 --> B6[skill: Converge]
|
|
199
|
-
B6 --> B7[advisory:
|
|
199
|
+
B6 --> B7[advisory: Prévenir]
|
|
200
200
|
end
|
|
201
201
|
|
|
202
|
-
subgraph "
|
|
202
|
+
subgraph "Schéma (database-supabase)"
|
|
203
203
|
C1[skill: Plan] --> C2[skill: Clarify]
|
|
204
|
-
C2 --> C3[skill:
|
|
205
|
-
C3 --> C4[skill:
|
|
204
|
+
C2 --> C3[skill: Inspecter]
|
|
205
|
+
C3 --> C4[skill: Charger supabase]
|
|
206
206
|
C4 --> C5[skill: Implement]
|
|
207
207
|
C5 --> C6[skill: Security]
|
|
208
208
|
C6 --> C7[skill: Converge]
|
|
209
209
|
end
|
|
210
210
|
```
|
|
211
211
|
|
|
212
|
-
|
|
|
213
|
-
|
|
214
|
-
| `skill` |
|
|
215
|
-
| `edit` |
|
|
216
|
-
| `verify` |
|
|
217
|
-
| `advisory` |
|
|
212
|
+
| Type d'étape | Ce que ça veut dire | Comportement du gate |
|
|
213
|
+
|--------------|---------------------|----------------------|
|
|
214
|
+
| `skill` | Charger une skill avant de continuer | **Bloque** si la skill n'est pas chargée |
|
|
215
|
+
| `edit` | Modifier le code | Autorisé |
|
|
216
|
+
| `verify` | Vérifier que le travail est correct | Advisory |
|
|
217
|
+
| `advisory` | Informatif | Ne bloque jamais |
|
|
218
218
|
|
|
219
219
|
---
|
|
220
220
|
|
|
221
|
-
##
|
|
221
|
+
## Ledger de tâches
|
|
222
222
|
|
|
223
|
-
|
|
223
|
+
Pour un travail qui dépasse quelques étapes, le ledger conserve le plan dans SQLite plutôt que dans la conversation.
|
|
224
224
|
|
|
225
225
|
```mermaid
|
|
226
226
|
flowchart TD
|
|
227
|
-
A["task new '
|
|
228
|
-
B --> C[Dispatch work packets]
|
|
229
|
-
C --> D[
|
|
230
|
-
D --> E[
|
|
231
|
-
E --> F{
|
|
232
|
-
F -->|N
|
|
233
|
-
F -->|N
|
|
227
|
+
A["task new 'Ajouter export CSV'"] --> B[Créer tâche + todos depuis la roadmap]
|
|
228
|
+
B --> C[Dispatch des work packets]
|
|
229
|
+
C --> D[Chaque packet = un todo<br/>propriété exclusive de fichiers]
|
|
230
|
+
D --> E[L'agent travaille les todos]
|
|
231
|
+
E --> F{Cadence de review<br/>tous les N éditions}
|
|
232
|
+
F -->|N atteint| G[Forcer une étape de review<br/>réconcilier le plan]
|
|
233
|
+
F -->|N pas atteint| E
|
|
234
234
|
G --> E
|
|
235
|
-
E --> H[
|
|
236
|
-
H --> I[
|
|
235
|
+
E --> H[Tous les todos faits]
|
|
236
|
+
H --> I[Tâche terminée]
|
|
237
237
|
```
|
|
238
238
|
|
|
239
|
-
- **
|
|
240
|
-
- **
|
|
241
|
-
- **
|
|
242
|
-
- **
|
|
239
|
+
- **Propriété exclusive des fichiers** — deux work packets ne peuvent pas éditer le même fichier
|
|
240
|
+
- **Budget d'itération** — chaque todo a un max (par défaut : 12) avant escalade
|
|
241
|
+
- **Cadence de review** — review forcée après 3 éditions de fichiers détenus par un todo ou 2 todos complétés (les éditions hors du projet de la tâche ou hors du périmètre d'un todo ne comptent pas)
|
|
242
|
+
- **Preuve obligatoire** — les étapes verify exigent une évidence avant complétion
|
|
243
243
|
|
|
244
244
|
---
|
|
245
245
|
|
|
246
|
-
##
|
|
246
|
+
## Mémoire
|
|
247
247
|
|
|
248
|
-
|
|
248
|
+
La mémoire de session est un système à deux couches : un espace de travail borné et lisible par la machine, et un carnet lisible par l'humain écrit en double.
|
|
249
249
|
|
|
250
|
-
|
|
|
251
|
-
|
|
252
|
-
|
|
|
253
|
-
|
|
|
250
|
+
| Couche | Où | Comportement |
|
|
251
|
+
|--------|----|--------------|
|
|
252
|
+
| Slots de session | `project-memory/` sous la racine du projet | `index.json` + slots de taille fixe, compact → archive → rotation |
|
|
253
|
+
| Carnet | `MEMORY.md` + page Obsidian | double écriture en fin de tâche ; le dossier du vault vient de `_meta/routing.md` |
|
|
254
254
|
|
|
255
|
-
###
|
|
255
|
+
### Slots de session — `project-memory/`
|
|
256
256
|
|
|
257
|
-
-
|
|
258
|
-
- Slots
|
|
259
|
-
- MCP
|
|
260
|
-
-
|
|
261
|
-
- `novahiz doctor`
|
|
257
|
+
- Vit sous la racine du projet : `index.json` plus `slots/`, et `novahiz init` le sème avec un slot de base.
|
|
258
|
+
- Slots de taille fixe (**8000 caractères / 200 lignes**) : un slot plein est compacté, archivé, remplacé — la mémoire reste bornée quelle que soit la durée du projet.
|
|
259
|
+
- Les outils MCP l'opèrent : `memory_init`, `memory_list`, `memory_get`, `memory_write` (append et rotation), `memory_rebuild` (réindexe depuis le markdown).
|
|
260
|
+
- C'est ici que vont décisions, causes racines et prochaines étapes quand une tâche complexe se termine.
|
|
261
|
+
- `novahiz doctor` vérifie à la fois la racine mémoire et les outils mémoire.
|
|
262
262
|
|
|
263
|
-
###
|
|
263
|
+
### Double écriture — `MEMORY.md` + vault
|
|
264
264
|
|
|
265
|
-
|
|
265
|
+
La skill `novahiz-memory` écrit l'état de clôture d'une tâche à deux endroits à la fois :
|
|
266
266
|
|
|
267
|
-
|
|
|
268
|
-
|
|
269
|
-
|
|
|
270
|
-
| Vault |
|
|
267
|
+
| Support | Destination |
|
|
268
|
+
|---------|-------------|
|
|
269
|
+
| Projet | `MEMORY.md` à la racine — ce qui marche maintenant, ce qui a changé, ce qui reste ouvert |
|
|
270
|
+
| Vault | une page Obsidian — dossier choisi **uniquement** par la table de routage `_meta/routing.md` |
|
|
271
271
|
|
|
272
|
-
|
|
272
|
+
Règles : frontmatter obligatoire (title, category, tags, sources, created, updated, summary), `[[wikilinks]]` depuis la taxonomie, et enrichir la page existante au lieu d'en créer une seconde. Routage ambigu → demander, jamais deviner.
|
|
273
273
|
|
|
274
274
|
---
|
|
275
275
|
|
|
276
|
-
##
|
|
276
|
+
## Skills installées
|
|
277
277
|
|
|
278
|
-
Novahiz
|
|
278
|
+
Novahiz livre 96 skills couvrant toutes les catégories :
|
|
279
279
|
|
|
280
|
-
|
|
|
281
|
-
|
|
282
|
-
| `code` | novahiz-code-review, code-standards, openapi-mcp-server, ... |
|
|
283
|
-
| `debug` | novahiz-analyse, ... |
|
|
284
|
-
| `review` | novahiz-code-review, novahiz-delta-review, ... |
|
|
285
|
-
| `database-supabase` | novahiz-postgres, novahiz-supabase, ... |
|
|
286
|
-
| `design-ui` | novahiz-humanizer, ui-slop-remover, ui-craft-rules, apple-ui-audit, ... | UI/UX,
|
|
287
|
-
| `docs-writing` | ... | Prose, marketing
|
|
288
|
-
| `browser` | novahiz-browser, browser-session, novahiz-web-extract, ... |
|
|
289
|
-
| `audit` | novahiz-security, package-risk-audit, llm-threat-review, ... |
|
|
290
|
-
| `expo` | expo-overview, expo-router, expo-module, expo-dev-client, ... | Expo / React Native: routes,
|
|
291
|
-
| `devops` | eas-workflows, eas-app-stores, novahiz-release, ... | CI/CD,
|
|
280
|
+
| Catégorie | Skills | Objectif |
|
|
281
|
+
|-----------|--------|----------|
|
|
282
|
+
| `code` | novahiz-code-review, code-standards, openapi-mcp-server, ... | Qualité du code, patterns, architecture |
|
|
283
|
+
| `debug` | novahiz-analyse, ... | Analyse de cause racine |
|
|
284
|
+
| `review` | novahiz-code-review, novahiz-delta-review, ... | Review structurée, rayon d'impact |
|
|
285
|
+
| `database-supabase` | novahiz-postgres, novahiz-supabase, ... | Schéma, RLS, migrations, optimisation |
|
|
286
|
+
| `design-ui` | novahiz-humanizer, ui-slop-remover, ui-craft-rules, apple-ui-audit, ... | UI/UX, hiérarchie visuelle, feel natif |
|
|
287
|
+
| `docs-writing` | ... | Prose, copy marketing, dé-IA du texte |
|
|
288
|
+
| `browser` | novahiz-browser, browser-session, novahiz-web-extract, ... | Automatisation web, captures, extraction |
|
|
289
|
+
| `audit` | novahiz-security, package-risk-audit, llm-threat-review, ... | Sécurité, conformité, vulnérabilités |
|
|
290
|
+
| `expo` | expo-overview, expo-router, expo-module, expo-dev-client, ... | Expo / React Native : routes, modules natifs, builds |
|
|
291
|
+
| `devops` | eas-workflows, eas-app-stores, novahiz-release, ... | CI/CD, déploiements, releases versionnées |
|
|
292
292
|
|
|
293
|
-
|
|
293
|
+
Lancer `npx novahiz skills --all` pour voir la liste complète.
|
|
294
294
|
|
|
295
295
|
---
|
|
296
296
|
|
|
297
297
|
## Providers
|
|
298
298
|
|
|
299
|
-
Novahiz auto-
|
|
299
|
+
Novahiz auto-enregistre les serveurs MCP externes selon la catégorie du prompt :
|
|
300
300
|
|
|
301
|
-
| Provider | Package |
|
|
301
|
+
| Provider | Package | Licence | Catégories |
|
|
302
302
|
|----------|---------|---------|------------|
|
|
303
303
|
| context7 | `@upstash/context7-mcp` | MIT | code |
|
|
304
304
|
| narsil | `narsil-mcp` | MIT OR Apache-2.0 | code, review |
|
|
305
305
|
| novahiz | local (`mcp/novahiz-tools`) | Apache-2.0 | code, planning |
|
|
306
306
|
| playwright | `@playwright/mcp` | Apache-2.0 | browser, design-ui |
|
|
307
307
|
| security | `security-mcp` | MIT | audit |
|
|
308
|
-
| cron | `scheduler-mcp` (local venv
|
|
308
|
+
| cron | `scheduler-mcp` (clone local venv) | MIT | devops |
|
|
309
309
|
| dart | `dart mcp-server` (Dart SDK) | BSD-3-Clause | code, debug, design-ui, flutter |
|
|
310
310
|
|
|
311
|
-
|
|
311
|
+
Packs de skills (installés depuis les dépôts officiels, jamais vendorés) : `flutter/agent-plugins` (25 skills), `dart-lang/skills` (15 skills), `expo/skills` (19 skills, le groupe `expo-*` seulement ; les services payants `eas-*` exclus), `pbakaus/impeccable` (1 skill, la skill design upstream `impeccable`). Voir [docs/PROVIDERS.md](docs/PROVIDERS.md).
|
|
312
312
|
|
|
313
|
-
|
|
313
|
+
Dépôts upstream et provenance complète des providers MCP et plugins opencode : [docs/PROVIDERS.md](docs/PROVIDERS.md), [docs/HARNESSES.md](docs/HARNESSES.md), [NOTICE.md](NOTICE.md).
|
|
314
|
+
|
|
315
|
+
> Note : les fichiers de `docs/` restent en anglais.
|
|
314
316
|
|
|
315
317
|
---
|
|
316
318
|
|
|
317
319
|
## Configuration
|
|
318
320
|
|
|
319
321
|
```bash
|
|
320
|
-
#
|
|
322
|
+
# Désactiver le gate (soupape d'urgence)
|
|
321
323
|
NOVAHIZ_GATE=off npx opencode
|
|
322
324
|
|
|
323
|
-
#
|
|
325
|
+
# Surcharger le répertoire home
|
|
324
326
|
NOVAHIZ_HOME=/path/to/novahiz npx novahiz doctor
|
|
325
327
|
|
|
326
|
-
#
|
|
328
|
+
# Forcer la version de node
|
|
327
329
|
NOVAHIZ_NODE=/usr/local/bin/node npx novahiz doctor
|
|
328
330
|
```
|
|
329
331
|
|
|
330
|
-
|
|
332
|
+
Voir [docs/CONFIGURATION.md](docs/CONFIGURATION.md) pour toutes les options.
|
|
331
333
|
|
|
332
334
|
---
|
|
333
335
|
|
|
334
|
-
##
|
|
335
|
-
|
|
336
|
-
|
|
|
337
|
-
|
|
338
|
-
| `novahiz init` |
|
|
339
|
-
| `novahiz doctor` | 13-check
|
|
340
|
-
| `novahiz status` |
|
|
341
|
-
| `novahiz classify <text>` |
|
|
342
|
-
| `novahiz gate` |
|
|
343
|
-
| `novahiz task new <title>` |
|
|
344
|
-
| `novahiz task status` |
|
|
345
|
-
| `novahiz task done <id>` |
|
|
346
|
-
| `novahiz report` |
|
|
347
|
-
| `novahiz skills` |
|
|
348
|
-
| `novahiz catalog <query>` |
|
|
349
|
-
| `novahiz roadmap` |
|
|
350
|
-
| `novahiz dispatch` |
|
|
351
|
-
| `novahiz sync` |
|
|
352
|
-
| `novahiz clean` |
|
|
353
|
-
| `novahiz upgrade` | Pull
|
|
354
|
-
| `novahiz version` |
|
|
355
|
-
|
|
356
|
-
|
|
336
|
+
## Commandes
|
|
337
|
+
|
|
338
|
+
| Commande | Objectif |
|
|
339
|
+
|----------|----------|
|
|
340
|
+
| `novahiz init` | Installation en une passe |
|
|
341
|
+
| `novahiz doctor` | Diagnostic de santé 13-check (14 avec `--deep` ; 17 avec Claude Code, 19 avec impeccable) |
|
|
342
|
+
| `novahiz status` | Classification + état du gate actuels |
|
|
343
|
+
| `novahiz classify <text>` | Classer un prompt |
|
|
344
|
+
| `novahiz gate` | Vérifier si une édition est autorisée |
|
|
345
|
+
| `novahiz task new <title>` | Démarrer une tâche suivie |
|
|
346
|
+
| `novahiz task status` | Avancement de la tâche |
|
|
347
|
+
| `novahiz task done <id>` | Marquer un todo complété |
|
|
348
|
+
| `novahiz report` | Rapport de session |
|
|
349
|
+
| `novahiz skills` | Lister les skills chargées ou disponibles |
|
|
350
|
+
| `novahiz catalog <query>` | Chercher dans le catalogue de skills |
|
|
351
|
+
| `novahiz roadmap` | Afficher la roadmap d'exécution |
|
|
352
|
+
| `novahiz dispatch` | Générer des work packets |
|
|
353
|
+
| `novahiz sync` | Reconstruire l'index des skills installées |
|
|
354
|
+
| `novahiz clean` | Supprimer les vieux logs |
|
|
355
|
+
| `novahiz upgrade` | Pull du dernier + rebuild |
|
|
356
|
+
| `novahiz version` | Afficher la version |
|
|
357
|
+
|
|
358
|
+
Voir [docs/CLI.md](docs/CLI.md) pour la référence complète.
|
|
357
359
|
|
|
358
360
|
---
|
|
359
361
|
|
|
360
362
|
## Documentation
|
|
361
363
|
|
|
362
|
-
|
|
|
363
|
-
|
|
364
|
-
| [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) |
|
|
365
|
-
| [docs/CLASSIFICATION.md](docs/CLASSIFICATION.md) |
|
|
366
|
-
| [docs/GATE.md](docs/GATE.md) |
|
|
367
|
-
| [docs/CATALOG.md](docs/CATALOG.md) |
|
|
368
|
-
| [docs/PLUGIN.md](docs/PLUGIN.md) |
|
|
369
|
-
| [docs/CLI.md](docs/CLI.md) |
|
|
370
|
-
| [docs/CONFIGURATION.md](docs/CONFIGURATION.md) |
|
|
371
|
-
| [docs/EXECUTION.md](docs/EXECUTION.md) |
|
|
372
|
-
| [docs/PROVIDERS.md](docs/PROVIDERS.md) | MCP
|
|
373
|
-
| [docs/INSTALL.md](docs/INSTALL.md) | Installation
|
|
374
|
-
| [docs/ROADMAPS.md](docs/ROADMAPS.md) |
|
|
375
|
-
| [docs/RULES.md](docs/RULES.md) |
|
|
376
|
-
| [docs/CONSTITUTION.md](docs/CONSTITUTION.md) |
|
|
377
|
-
| [docs/HARNESSES.md](docs/HARNESSES.md) |
|
|
378
|
-
| [docs/TOKENS.md](docs/TOKENS.md) |
|
|
364
|
+
| Fichier | Sujet |
|
|
365
|
+
|---------|-------|
|
|
366
|
+
| [docs/ARCHITECTURE.md](docs/ARCHITECTURE.md) | Design système, composants, flux de données |
|
|
367
|
+
| [docs/CLASSIFICATION.md](docs/CLASSIFICATION.md) | Fonctionnement du classifier |
|
|
368
|
+
| [docs/GATE.md](docs/GATE.md) | Règles du gate, classes de fichiers, application |
|
|
369
|
+
| [docs/CATALOG.md](docs/CATALOG.md) | Catégories, règles, providers, overrides |
|
|
370
|
+
| [docs/PLUGIN.md](docs/PLUGIN.md) | Cycle de vie du plugin opencode |
|
|
371
|
+
| [docs/CLI.md](docs/CLI.md) | Référence des commandes CLI |
|
|
372
|
+
| [docs/CONFIGURATION.md](docs/CONFIGURATION.md) | Fichiers de config et variables d'env |
|
|
373
|
+
| [docs/EXECUTION.md](docs/EXECUTION.md) | Ledger de tâches, todos, dispatch |
|
|
374
|
+
| [docs/PROVIDERS.md](docs/PROVIDERS.md) | Serveurs MCP et packs de skills |
|
|
375
|
+
| [docs/INSTALL.md](docs/INSTALL.md) | Installation et configuration |
|
|
376
|
+
| [docs/ROADMAPS.md](docs/ROADMAPS.md) | Roadmaps d'exécution |
|
|
377
|
+
| [docs/RULES.md](docs/RULES.md) | Référence des règles du gate |
|
|
378
|
+
| [docs/CONSTITUTION.md](docs/CONSTITUTION.md) | Principes du projet |
|
|
379
|
+
| [docs/HARNESSES.md](docs/HARNESSES.md) | Guide des adaptateurs de harness |
|
|
380
|
+
| [docs/TOKENS.md](docs/TOKENS.md) | Diagnostics de tokens |
|
|
379
381
|
|
|
380
382
|
---
|
|
381
383
|
|
|
382
|
-
##
|
|
384
|
+
## Philosophie
|
|
383
385
|
|
|
384
|
-
Novahiz
|
|
386
|
+
Novahiz traite les skills comme des **serrures** et le prompt comme une **clé**. Le classifier détermine quelles serrures existent. Le gate vérifie que vous avez les bonnes clés chargées. Pas de clé, pas d'édition.
|
|
385
387
|
|
|
386
|
-
|
|
388
|
+
Tout est local, déterministe et JSON. Aucun appel cloud. Aucune inférence de modèle dans le chemin de décision. Même prompt + même config = même résultat, à chaque fois.
|
|
387
389
|
|
|
388
390
|
---
|
|
389
391
|
|
|
390
|
-
##
|
|
392
|
+
## Licence
|
|
391
393
|
|
|
392
394
|
Apache-2.0
|