한입만 게이트 (hanipman-gate)
한입만. Ne déverse pas tout d'un coup.
À mesure que l'IA écrit du code, le goulot d'étranglement s'est déplacé. La génération est devenue rapide, mais la compréhension est restée la même. Quand un diff de 60 fichiers tombe d'un coup, une personne abandonne la lecture attentive au bout de 3 minutes et passe à un simple survol.
Ce dépôt est un ensemble d'outils qui déplacent ce goulot d'étranglement de la discipline vers la structure. Distribué via le marketplace de plugins Claude Code.
Ce qu'il fait
Discussion de conception
│
├─ ledger decide ────────▶ Registre de décisions
│ ├ Conception courante (seulement ce qui est confirmé · remplacement atomique)
│ └ Journal de décisions (append-only · SUPERSEDED conservé)
│ │
│ current --topic uniquement (ne lit pas tout le document)
│ ▼
└─ /impl-pipeline ──▶ Découpage en slices ──▶ Délégation ──▶ /review-gate ──▶ /change-walkthrough
│ │
GREEN seulement ▼
passe Ce que l'humain lit :
"N éléments nécessitant jugement"
Trois règles suffisent.
Ne pas lire tout le document de conception en entier. Lors de la délégation, on ne passe pas le chemin du document mais seulement le texte confirmé de la décision dans le prompt. Le coût en tokens devient indépendant de la longueur du document.
Seuls les diff ayant passé la gate arrivent à l'humain. On exécute d'abord les vérifications : diagnostic, conventions, cohérence conception, dérive de scope. Le temps de relecture ne dépend plus de la taille totale du diff, mais du nombre d'éléments nécessitant un jugement.
L'état ne s'écrit pas à la main. L'achèvement d'un travail sur plusieurs dépôts est mesuré directement par des sondes en lecture seule qui interrogent l'état à distance. Si inconnu, il reste non vérifié. Mieux qu'un faux terminé.
Installation
/plugin marketplace add 5hseok/hanipman-gate
/plugin install design-pipeline@hanipman-gate
Le plugin est divisé en trois parties. Installez seulement ce dont vous avez besoin.
| Plugin | Quoi | Quand |
|---|---|---|
design-pipeline | Registre de décisions → slices → gate → guide de relecture | Conception et implémentation. C'est le cœur |
track-ledger | Mesure l'ordre de plusieurs dépôts/sessions avec des sondes | Sessions multiples ou ordre de déploiement imbriqué |
explain-aids | HTML interactif pour comprendre la conception et le diff | Quand il faut expliquer un gros changement à quelqu'un (ou à soi-même dans le futur) |
session-board | Tableau de bord de session sur une seule Artifact | Quand un document de suivi est trop lourd et qu'on veut juste voir "où en est quoi" |
Compétences
design-pipeline
| Compétence | Rôle |
|---|---|
design-workflow | Source de politique. Règles du registre, protocole de lecture, commits checkpoint, niveaux de risque |
impl-pipeline | Orchestrateur. Découpe la conception en slices et les envoie jusqu'à la gate |
review-gate | Gate automatique. Diagnostic, conventions, cohérence conception, dérive de scope |
change-walkthrough | Guide de relecture. Réorganise les modifications dans l'ordre du flux de demandes |
design-reconcile | Hygiène du registre. Déplace le contenu obsolète (ne le supprime pas) |
convention-audit | Vérification des conventions. Appelée par review-gate |
track-ledger
| Compétence | Rôle |
|---|---|
track-ledger | Création et gestion des pistes |
track-ledger-policy | Règles immuables et critères de communication entre sessions |
session-board
| Compétence | Rôle |
|---|---|
session-board | Lit le registre des sessions Claude et publie le tableau de bord sous forme d'Artifact, mis à jour à la même URL |
Pas de CLI ni de serveur. Si track-ledger semble lourd, commencez par celui-ci.
explain-aids
| Compétence | Rôle |
|---|---|
explain-design-html | Avant implémentation. Pourquoi cette direction, ce qui a été abandonné |
explain-diff-html | Après implémentation. Ce qui a changé et comment |
explain-skills-workflow | Critères pour savoir quand proposer les deux ci-dessus |
Quelques choix de conception
La gate est asymétrique. Une violation de convention est bloquée en ROUGE, mais un écart de conception n'est pas bloqué : il est transmis comme liste de points à juger. Les conventions sont basées sur des règles et donc fiables, alors que la cohérence conception repose sur le jugement du LLM et peut produire des faux positifs. Si un faux positif bloque à répétition une implémentation justifiée, l'humain finit par désactiver la gate.
Ne pas transformer un échec partiel en échec total. Le diff brut est la vérité, les livrables sont auxiliaires. Si la génération d'un livrable échoue, on signale l'échec mais on ne bloque pas la relecture.
Une slice n'est pas un commit. On sépare la frontière de relecture de la frontière de commit. L'agent peut proposer des commits, mais ne les exécute pas.
Ne pas ajouter de commentaires explicatifs. On ne laisse pas la raison du changement dans un commentaire de code. C'est le guide de relecture qui s'en charge. Les commentaires salissent le code, alors que le guide existe en dehors du code et est jeté une fois la relecture terminée.
Prérequis
- Claude Code
- Python 3 (bibliothèque standard uniquement, aucune dépendance tierce)
- git
Optionnel, mais change beaucoup la donne :
- codebase-memory MCP — Le produit clé de
change-walkthrough("code affecté mais non modifié", c'est-à-dire du code qui appelle le code modifié mais qui n'est pas lui-même modifié) nécessite de pouvoir extraire la chaîne d'appels réelle. Sans lui, cet élément est entièrement absent. gh·aws·terraform— Utilisés par les sondes de piste. Sans eux, l'étape correspondante restenon vérifiée.
Où placer le registre
La compétence ne sait pas où se trouve le registre. Elle appelle simplement ledger.
ledger current --file <task> --topic <slug> # Seulement les décisions confirmées. Ne lit pas tout le document.
ledger decide --file <task> --topic <slug> --title ... --supersedes D-3
ledger doctor # Quel backend a été choisi et pourquoi
Par défaut, le registre est du markdown dans le dépôt (.claude/design/). Si vous utilisez un coffre Obsidian,
il suffit d'indiquer le chemin dans ~/.claude/ledger.json pour utiliser vos documents existants.
{ "backend": "obsidian", "root": "/path/to/vault" }
Voir docs/adapter-contract.md pour plus de détails.
Ce qui n'est pas encore testé
Ça fonctionne sur la machine de l'auteur, mais les points suivants n'ont pas encore été vérifiés :
- N'a jamais été installé de zéro sur un environnement autre que celui de l'auteur. Le test aller-retour avec un dépôt vide en backend
markdowna été fait, mais le cycle complet d'installation et d'exécution n'a eu lieu que sur la machine de l'auteur. - Le pipeline complet n'a jamais été parcouru avec le backend
markdown. L'aller-retour avec l'adaptateur a été validé, mais le parcours completimpl-pipeline→review-gate→change-walkthroughsur un registre markdown n'a pas été exécuté jusqu'au bout. - On ne sait pas comment ce plugin est perçu sur un projet non coréen. Les en-têtes sont reconnus dans les deux langues via une map d'alias, mais le corps des compétences, les rapports de gate et l'interface du tableau de bord sont en coréen.
- On n'a jamais mesuré la réduction du temps de relecture. L'intention de conception est "proportionnel au nombre d'éléments nécessitant jugement et non à la taille totale du diff", mais il n'y a pas de données de comparaison avant-après.
Exemples
examples/ contient un jeu de documents de registre et un jeu de documents de piste. Les deux ont été créés et re-lus avec les vrais outils pour validation, donc leur format est garanti correct.
Licence
MIT. Voir LICENSE.
Nom
Hanipman (한입만). C'est ce qu'on dit quand on ne veut pas tout le plat de quelqu'un, juste une bouchée. C'est aussi ce que cet outil dit à l'agent.
gate est le mot commun aux deux systèmes. Côté pipeline, il y a review-gate, et côté piste, les étapes du registre ont un champ gate: merge / gate: apply / gate: deploy.