PathruleKnowledge IR
Pourquoi Pathrule conserve la nature de chaque élément de connaissance (exigence, conseil ou contexte) à côté du texte rédigé par votre équipe, et comment cette autorité est préservée jusqu'à l'agent.
Une règle n'est pas une unité de connaissance. C'est un conteneur qui en accueille.
Un seul paragraphe rédigé par une personne exprime couramment plusieurs choses de nature différente à la fois : qu'une chose ne doit jamais se produire, qu'une autre doit être vérifiée, et pourquoi l'ensemble est organisé ainsi. Livrées d'un seul bloc, ces choses se réduisent à « voici un texte, merci d'en tenir compte ». Gardées séparées, elles restent trois choses distinctes, avec trois poids distincts.
Knowledge IR désigne cette forme structurée : la nature et l'autorité de chaque élément de connaissance, conservées à côté du texte rédigé par votre équipe, et non à sa place.
Types de connaissances
Chaque élément de connaissance reçu par un agent appartient à l'un de quelques types, et c'est ce type qui détermine la façon dont il est présenté.
Ce qui ne doit pas se produire. Une contrainte définie par une personne pour un périmètre donné. Elle régit les chemins auxquels elle s'applique et rien d'autre, et c'est le seul type de connaissance sur lequel le runtime peut agir, au lieu de simplement le mentionner.
Ce qui doit être vérifié. Une vérification à effectuer avant que le travail puisse être considéré comme terminé.
Ce qui a fonctionné quand ce problème s'est présenté. Une condition et le correctif qui l'a résolue. C'est un conseil : il indique à l'agent ce qui a fonctionné, pas ce qui lui est interdit.
Ce qu'il faut privilégier dans une situation donnée. Un choix préféré, accompagné des alternatives qu'il a supplantées. Il énonce la préférence sans jamais interdire l'alternative. Seule une règle peut le faire.
Comment une chose doit être faite. Une procédure ordonnée, avec ses étapes dans leur ordre d'origine, car une procédure réordonnée est une autre procédure. La plupart des procédures se trouvent dans les skills.
Ce qui est vrai et utile ici. Un fait descriptif qui change la bonne approche sans rien interdire. Le fait que la base de données derrière un module soit une réplique en lecture seule relève de ce type, et c'est pour cela qu'un agent doit passer par la file d'attente plutôt que par un insert.
Pourquoi une chose fonctionne ainsi. Le raisonnement derrière une décision. Il existe parce qu'un agent qui connaît la règle mais pas sa raison n'est qu'à un refactoring bien intentionné de la défaire.
Niveaux d'autorité
Ces types ne se valent pas, et la livraison l'indique explicitement au lieu de s'en remettre à l'ordre d'apparition dans un prompt.
| Niveau | Ce qu'il couvre | Signification |
|---|---|---|
| Exigence | Les règles, y compris ce qui ne doit pas se produire et ce qui doit être vérifié | S'impose. |
| Conseil | Correctifs passés, choix préférés, procédures, justifications, constats des agents, vos préférences personnelles | Améliore le travail. |
| Contexte | Faits qui éclairent le travail | Informe. |
Rien dans la chaîne de livraison ne peut présenter un niveau inférieur comme capable de primer sur un niveau supérieur. Les règles arrivent dans leur propre section. Les constats des agents arrivent présentés comme des conseils à vérifier. Vos préférences personnelles arrivent sous un intitulé qui indique à l'agent que les règles et les vérifications obligatoires de l'espace de travail passent en premier. Un paragraphe qui se lit avec la même force qu'une exigence est un paragraphe qui peut être suivi à sa place, et la structure existe précisément pour l'empêcher.
C'est ce que signifie concrètement « l'autorité est encodée, pas aplatie », et c'est ce qui distingue une représentation structurée d'un amas de phrases.
Documents et atomes
Vos mémoires, règles et skills restent exactement ce qu'ils sont : la surface qu'une personne rédige, modifie et dont elle discute. La forme structurée en est une représentation, pas un remplacement.
Rule document
|
+-- what must not happen
+-- what must be verified
+-- why
Un même document peut contenir plusieurs types de connaissances. C'est normal, et c'est la raison pour laquelle un conteneur et une unité ne sont pas la même chose.
L'origine des types contraignants est ce qui compte le plus. Une exigence ne provient que d'une règle définie par une personne. Une règle peut aussi porter une contrainte exécutable ; une contrainte proposée par un agent est enregistrée comme proposition et n'est pas appliquée tant qu'une personne ne l'a pas approuvée. Rien de ce qu'un modèle déduit ne devient une exigence de lui-même. Voir Proposed Knowledge.
Conflits
Deux conseils peuvent sembler valides tous les deux et pourtant se contredire. Pathrule ne confie pas ce désaccord à l'agent pour qu'il tranche.
- Constats. Lorsque deux constats enregistrés par des agents à propos du code se contredisent, les deux sont mis de côté au lieu de choisir l'un d'eux au hasard.
- Préférences. Lorsque vous enseignez une préférence qui contredit une préférence antérieure portant sur le même type de travail, la plus récente la remplace, et l'ancienne est retirée avec un renvoi vers celle qui l'a remplacée.
- Règles et préférences. Une règle l'emporte toujours sur une préférence personnelle. Voir User Intelligence.
Deux conseils contradictoires valent moins que pas de conseil du tout, et c'est la structure qui permet à Pathrule de détecter quand cela se produit.